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.

But the real reason for this post is that Update 4 sets the database schema version as 8.51 (all previous releases of 8.5 had set the schema version as 8.50).  This value is listed as the MHVERNUM column in the MHGROUP.VERINFO table of the WorkSite database.   For those of you looking to migrate from an environment with WorkSite Indexer 8.2 SP1 P2 (Verity), there is a compatibility problem with this change.   Although Indexer 8.2 SP1 P2 was released in order to support iManage 8.5 servers for a transitional period, the 8.2 Indexer services fail to start when the database has been upgraded to the 8.5 Update 4 schema.   Autonomy’s workaround for now is to modify the MHVERNUM value and set it to 8.50.  This can be done by executing the following SQL query:

UPDATE MHGROUP.VERINFO SET MHVERNUM = ’8.50′

This will allow the Index services to start, but will cause problems launching the iManage Database Administration (DBAdmin) program.   In order to get that to launch, I had to change the MHVERNUM back to ’8.51′.    Autonomy has informed me that they plan on releasing a fix to the 8.2 Indexer executable “very soon”.    Just something to be aware of when setting up a transition environment from 8.2 to 8.5.  You will want to stick with 8.5 Update 3 until the patch for the 8.2 Indexer is released.