iManage’s desktop applications – whether it’s FileSite, DeskSite, or Email Management – are each closely integrated into the Microsoft Office suite. WorkSite acts as a gate-keeper so that multiple people do not start making changes simultaneously to the same document, resulting in lost work when one overwrites the other. This gate-keeping is accomplished with a check-out and check-in paradigm.
The integration is so thorough that a person generally never needs to be aware of checking out a document to modify it, or of checking the document in when finished.
In Word, just do a File | Open, choose the intended document from the workspace, and start your editing. Save your changes in the usual way then close Word, and voila: checking out and checking in have occurred without your knowledge.
Bumps in the road
A couple of things can interfere with this smooth progress: I’ll explain next what the most common causes are, and where to collect more information.
The likely culprits
The most likely causes of a document failing to check-in when a user’s “done” with it:
- Something interfering with the local working copy of that file
- An integrated application (e.g. Word) not having properly connected to the WorkSite database when first launched in this session.
Local working copy
The iManage desktop applications keep a working copy of edited documents on that user’s machine. The NrPortbl, /NetRight, and NRTEcho folders need to be exempt from anti-virus scans. The file-level locks caused by a anti-virus scanner can interfere with the iManage integration’s processes that determine the checkin-checkout lifecycle.
You can also refer to iManage’s “Anti-Virus Exclusions with 8.5” document for a full list of server-side anti-virus exclusions.
Incomplete connection to WorkSite
A handful of reasons can cause an application to break its integration ‘contract’ with WorkSite. The results all boil down to the same symptom: FileSite, DeskSite, or the in-application integration are not able to mark the document as checked-in when they are supposed to. You can determine the particular trigger by gathering details about what your person was most recently doing when the document ended up stuck in the checked-out state.
- Integrated applications – e.g. the Microsoft Office Suite – can cause stuck check-outs by being launched or changed to ‘local-only’ mode. This could happen if a laptop user launches Word when outside the firm’s network, for example, and deliberately doesn’t login to WorkSite. Other causes can be other macros, customizations, or add-ins that interfere with the document closing and checking-in process. If it’s a one-time problem, you can prevent further stuck items by closing down all copies of that application, and then making sure to re-launch it with an active WorkSite session.
- Shutting down or logging out without closing what you’ve opened from WorkSite. Sometimes Windows’ logout or shutdown processes interfere with iManage’s tracking of the checkin-checkout lifecycle. Make sure to close those open documents individually, then deal with your Windows session.
- Orphaned non-integrated applications. A non-integrated application, such as Acrobat Reader, does not talk to iManage. Instead, the FileSite (or DeskSite) process watches the file status to determine when the person has stopped viewing it. If the person quits FileSite while Reader still has that file open, FileSite isn’t able to complete its responsibility – updating WorkSite when the file’s closed.
- Issues with Citrix or incorrect (local) application installation settings. There are more detailed conflicts that can happen in a Citrix environment, or if an application’s properties are not properly configured. Refer to the iManage documentation for more details about this.
There are a few iManage tech notes that cover these topics in much greater detail, as well as some handy troubleshooting check-lists. Go download these from the iManage support site, or contact me if you’d rather watch over my shoulder as I troubleshoot the problem in your environment.