According to the release notes, there are 3 registry keys that need to be added to each WorkSite Server in order to use the server-side duplication detection.  The first one disables client-side email duplicate detection:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Interwoven\WorkSite\imDmsSvc
Name: Duplicate Detection Type
DWORD Value: 2 – Disables Client-side E-mail Duplicate Detection

The second key enables the server-side detection:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Interwoven\WorkSite\imDmsSvc
Name: Server-Side Duplicate Detection
String Value: Y - Server performs duplicate detection

The third key determines the scope of the detection, and, as I’ll explain afterwards, could be the most dangerous key you could configure:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Interwoven\WorkSite\imDmsSvc
DWORD Name: Server-Side Duplicate Detection Type
Values:
0- [default] Searches for duplicates within the target folder or workspace.
1- Searches for duplicates across entire target library.
2- Disables duplicate detection.

Why might this key be dangerous?   With the right combination of supported configurations, it could spell disaster.  First, imagine you have the Email Management for Outlook installed, and have users that have linked folders within their Outlook inbox to matter Workspaces.  Next, imagine that when they linked their Outlook folders, they chose the option to keep the email in Outlook after it is filed.  Next, imagine each folder has 5,000 emails, and some of these emails have attachments that are 1 MB each.   See where I’m going with this?  Ok, well, now imagine you set that Server-Side Duplicate Detection Type registry key to 2, disabling email duplication.

With this combination, the Email Filing Service will cycle through the linked folders and file thousands of emails over and over again — until you either run out of space on your file server, or on your SQL data/log volumes.  Or until you notice that your new document number is all of a sudden 300,000 more than it was yesterday.

I contacted Autonomy about this potential situation, and they confirmed that there is no way to force de-duplication for linked folders.  I’ve submitted a new feature request for this behavior to Autonomy.  I hope they read those things.

All that being said, I have successfully performed this upgrade and enabled these features at a client.  The enhanced duplicate detection functions properly, and even adds links to the original email if a user attempts to file it to a different Workspace folder.  This is yet another step in the right direction for iManage’s email-filing capabilities.

Let’s leave those drawbacks out of the equation for now, and focus on what should be a benefit:  the ease of finding documents across the enterprise.   How could this be bad, you ask?  The Enterprise Search utilities are designed to respect the security of whatever system the content lives in.   That’s good, right?  Well, what if the documents aren’t secured in the source repository?   Some older systems make it inherently difficult to find documents with the native search interface/engine.  Since it may be difficult to find documents, users start to skip the step of securing documents.   Their thinking is, “Well, no one can find the document anyway, so why do I need to waste 45 seconds and add security to it?”.   These unsecured documents could be financial statements, HR documents, or any other content that should be secured.

Enter Enterprise Search. Once Enterprise Search is introduced, that open level of security would now be apparent to all users of the system.   This could cause headaches in the enterprise, and put a black-mark on the Enterprise Search tool — even if it’s not the Enterprise Search tool’s fault.   This is just one example of the implications of adding new ECM functionalities to an environment.   The security example here can be alleviated by scripting a security update to the source repository prior to the deployment of the Enterprise Search; essentially resolving the issue before it can become a security nightmare.

Another significant new feature in version 7 provides automatic detection and comparison of changes when attachments are sent, modified and returned through email, alerting users directly in Outlook. By identifying changed documents and launching a comparison as modified documents arrive, Workshare Professional 7 improves efficiency, making document collaboration a more seamless process.

I think attorneys will love this feature as it saves clicks and steps.   Additional performance improvements have been made in the Workshare Protect meta-data removal module.  What’s more valuable than an attorney’s time?  Kraft Kennedy is a member of the Workshare Alliance Network.

Sometimes the flashy new features and modules that plug into the old code can cause issues. Maybe they are stretching what the product can do. Who knows? Too many times have I seen new releases and service packs get caught in a seemingly long and drawn-out Beta test or QA testing. Don’t get me wrong, I am glad vendors are trying to fully test their software before a general release, but I’ve seen many estimated release dates come and go. Updates get released, then pulled back into QA.  Eventually, things usually work out.

My advice to clients is usually the following:

1. Wait it out a bit. Especially when that major new version or service pack gets released, don’t rush to implement unless absolutely necessary. Give it a few weeks to see if they release a “new patch” to fix issues with the old patch.
2. If you have a development or test environment, try the new release there first and really bang away at it.  If you have the time, perform some tests over a period of a couple weeks to check ongoing stability.
3. Keep an eye on any vendor support forums or social groups on LinkedIn for any feedback from the guinea pigs.

These simple steps could save you a few migraines.

In testing our pilot deployment, one issue was apparent.  The ODMA integration between Adobe Acrobat and DM was broken!  I checked the Open Text Knowledge Center on the proper steps to integrate Adobe with DM, and verified that yes, the API file is in place, and yes the PassiveODMA registry value is in place.   Upon opening a support ticket, I was informed that ODMA integration is gone with DM 5.3.  In fact, starting with DM 5.2.1 CU4, Open Text was not including the ODMA integration with Adobe.   That seemed strange, since it was working with our 5.2.1 CU5 client just fine.  Turns out that if the API file and PassiveODMA registry key are in place from a previous installation, it will still work with CU5 and CU6.   However, with 5.3, ODMA integration is no longer in the code, so if you have the API file in place, that DM menu option in Adobe is there but that does absolutely nothing.

In double-checking the release notes for DM 5.3, I found that this integration change was mentioned, but as the 4th footnote on a page — definitely not prominent.  And no mention of this change with 5.2.1 CU4  in the Knowledge Base or in the Application Note titled  “eDOCS DM 5.2.x – How to Successfully Integrate Adobe Acrobat and Adobe Reader”.

This leads to two valuable lessons for any product integrator:

1. Be sure to read all Release Notes, including footnotes!
2. Before deploying a software upgrade, deploy to a small pilot and test all integrated applications.

Regarding the Adobe integration with DM 5.3, the DM Interceptor is needed.  This is actually documented as an option in the Application Note referenced above, but is a requirement starting with DM 5.3.

To achieve optimal results when you use Outlook with Remote Desktop Services, pay attention to how you customize your Outlook configuration. For example, in Outlook 2010 you can configure Cached Exchange Mode with Remote Desktop Services.

The article is careful to mention that you’d need to have enough disk space on the server to handle each user’s OST file. Maybe this makes sense for small environments with only one Terminal Server and tidy mailboxes. I can count on less than one hand how many firms fall into that category.

Based on our experience, we recommend disabling Cached Mode on any XenApp server we put in place. At the same time, we want to allow our users to run in Cached Mode on their Windows 7 desktops. How do we achieve this?  Through the use of Loopback Policy, we can ensure that when users log in to a XenApp server, Cached Mode will be disabled.  This policy will override the settings within a MAPI profile that is roamed or flexed to the XenApp server. When the user logs back into their Windows 7 desktop, they are happily working in Cached Mode again.

This is just another example of how technology can change without much fanfare.  For many years, we never hard to worry about this situation. The mere fact that the user was logging in to a Terminal Server with Outlook 2003 meant that Cached Mode would be disabled no matter what. But with Outlook 2010 and Server 2008 R2/XenApp, a successful implementation relies on a successful configuration of the environment. You can download the Microsoft White Paper on the planning considerations of Outlook 2010 on Server 2008 R2 here.

This bug is fixed in the next update to FileSite and DeskSite, which is currently in field test.   However, if you are plagued by this, there is a workaround for now.  It involves disabling the iManage Print Logging.  This means that if documents are printed, the Document History iManage will NOT be updated with a Print Activity.  This can affect firms that track printing for cost-recovery purposes.   But this will allow users to print an individual page of a Word 2010 document successfully.    So you probably save more money on saved paper than the cost-recovery of that one page you needed to print.

The workaround is adding three registry keys.  The keys below assume a 64-bit version of Windows 7:

[HKLM\Software\Wow6432Node\Interwoven\WorkSite\8.0\ Integration\Options]
“EnableWordPrintLogging”=dword:0
“EnableExcelPrintLogging”=dword:0
“EnablePowerPointPrintLogging”=dword:0

If enabling this workaround, remember to remove these keys after deploying and testing the next client version in order to re-enable print logging.

One such topic that tends to come up is DMS consolidation.   Firms are able to work in a distributed environment, and nothing is “broken” in that setup.  But the experience can be enhanced.  Consolidation can provide a number of advantages including:

• One location for all firm-wide matter-related documents and email in an iManage MCC or eDOCS Dynamic View environment
• One location to manage retention policies for archiving
• Easier cross-office collaboration and searching
• Less backend infrastructure to maintain, such as middle tier servers, indexers, SQL databases, file shares

This sounds amazing, but remember that any DMS consolidation project requires a big backbone of non-DMS equipment and technology.  There’s the WAN connection bandwidth & latency, WAN acceleration devices, and redundant and highly available storage, database, and application server systems.   These foundations should be in place in order for a DMS consolidation project to stand on it’s own successfully.  Notice how we haven’t even started discussing the number of DMS servers, indexers, and the redundancy of those systems.

Beyond the infrastructure requirements, Firms can also be hesitant about consolidation for DMS-related reasons such as document number changes, document history preservation, long migration time-lines, and high consulting costs.   All of these concerns can be mitigated through our use of technology together.

Now is the time to start thinking about how your global Firm can collaborate and manage your enterprise content in a more efficient way.  The first step is ensuring your infrastructure can handle it.

Taking advantage of our Kraft Kennedy research lab, within a day I was able to connect our research iManage 8.5 system to our Exchange 2010 environment, and enabled the Archive Mailbox for my test account.     And for the first time in the history of mankind (I can only assume), tested the functionality.   Below you will find a brief summary of the environment and tests performed.

Environment

• Exchange 2010 SP1 with multiple mailbox servers behind a dedicated CAS array
• iManage WCS 8.5 SP1 Update 1
• iManage WorkSite Server 8.5 Sp1 Update 3
• Outlook 2010 with FileSite 8.5 SP2 Update 2 and EMM for FileSite 8.5 SP2 Update 2

Tests and Results

The first thing to know about the Archive Mailbox is that by default, there are no folders within (besides a Deleted Items folder).  If retention or archive rules are configured in the environment, a folder structure could be copied from the Active Mailbox to the Archive Mailbox.   For the purpose of my testing, I used a variety of folder types and drag/drop filing operations.

My first test was simply creating a folder within the Archive Mailbox, and placing an email into that folder.  I then dragged this to a Workspace folder, and the EFS back-end successfully filed the email.   1 for 1.

My next test was to create a folder in the archive, and then link that folder to a Workspace folder.  I then dragged an email from the Archive mail folder into the linked Archive Folder, and EFS successfully filed the email.  2 for 2.   I then took an email from my Active Mailbox inbox and dragged into the Linked Archive Folder.   3 for 3.  Hey, things are looking pretty good.

My last test of the day is when I started feeling a little brave.  It was time to put on the “What would an attorney do?” hat, and tried the following:   I created a Linked folder in my Active Mailbox.  I then dragged this entire folder into the Archive Mailbox.    I then tried dragging an email into this folder.  No go.  Here’s what I noticed:  although the folder icon still appeared to be a “Linked” folder, the Properties -> File to WorkSite tab had lost the association.  After re-configuring the folder to file to the proper Workspace, functionality was restored.

This behavior could also be mimicked by a backend archive rule as it archives an active mailbox folder.  Even if the link to iManage was reconfigured, the Exchange message-class should still indicate that the email has been successfully filed into WorkSite, so there shouldn’t be any duplicates.   I think the action item for Autonomy would be to see if it’s possible to change the folder icon back to a regular Outlook folder if the link to iManage is broken.

All in all, I must admit I was rather surprised at how much worked.  Part of why it works can be explained by Microsoft’s TechNet:

In Exchange 2010 SP1, when you assign Full Access permissions to a mailbox, the delegate to which you assign the permissions can also access the user’s personal archive.

So, as long as your EFS service account has the proper permissions to the user’s Active Mailbox, it will also have permissions to the Archive.    Thank you, Microsoft!   This whole experience also demonstrates the value of  a well-maintained research sandbox in your environment.