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.

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.

• The Autonomy Control Center - a web app intended to simplify management of the IDOL components, particularly in a multi-server environment
• Changes to the Active Content engine that improve query performance
• Improvements to the Deployment Tool that allow more granular control when deploying various IDOL components
• A shift of Eduction processing from the IndexTask component in IDOL to the WorkSite Ingestion Service
• Automatic restarting of the WorkSite Connector during the initial crawl if the service dies before the first crawl is complete

These, as well as a full list of resolved issues and enhancements, can be found in more detail in the “WorkSite Indexer Release Notes (8.5 SP2)” on Autonomy’s support website.  We’ve been excited to get our hands on the new releases and have been working on deploying them over the past few days.  The WorkSite Indexer has thus far been deploying without any trouble.

The Universal Search server, on the other hand, has proven to be a little more difficult.  We’ve discovered a bug (confirmed by Autonomy) with deploying multiple WorkSite content engines that causes the deployment process to stop with the message “null” followed by “Deployment process incomplete”, as shown below:

Short of attempting to deploy with 1 WorkSite content engine and creating the additional content engines manually, this brings the deployment of IUS 8.5 SP2 to a screeching halt.  Autonomy has identified this as a high priority issue and expects to have a resolution out in the very near future.  We’ll be keeping our eyes out for the updated release, and will provide a more in-depth review as we spend some time with the new features.  Stay tuned…

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.

NOTE: Adobe Acrobat Reader X includes a feature called Protected Mode that limits an application’s access to registry and file systems. This feature is enabled by default. Because WorkSite Integration requires full access to the local machine, you must disable this feature.

The feature can be disabled from the General Preferences in Adobe Reader X, and should be included into your MST transform package.

Regarding Update 2, there are a handful of issues resolved, but one in particular stands out to me because I’ve already witnessed it.   From the Release Notes:

NT-26001: When dragging an e-mail to a WorkSite folder using Outlook 2010 with Cached Exchange Mode disabled, the user receives the following error; ‘Cannot move the items. The item cannot be moved. It was either already moved or deleted, or access was denied.’

This can easily be avoided on Windows 7 desktops simply by enabling Cached Mode (which is a good idea for a number of reasons that you should already know about, so I won’t get into them).  However on XenApp servers, where Cached Mode is not available, this can be an annoying bug.  The email does in fact get filed, but the error just isn’t pretty at all.   If you are planning an Office 2010 roll-out with iManage, this update is a must-have.

These are all well and good, but most firms have some third-party applications that provide advanced features sets.  There’s WorkShare Compare and pdfDocs CompareDocs to name a few that have direct integration with iManage; and most template packages include integration into iManage for automatic stylized document footers.    In these instances, you may want to hide or disable the iManage integration with native Office 2007/2010.

iManage 8.5 SP2 allows you to make these customizations through the modification of XML files on the client workstation, but you need the client customization documentation to do it.  No, I mean, you REALLY need the documentation in PDF form, because the XML files are attached to the iManage 8.5 SP2 Client Customization PDF.   The files are:  ExcelIntegrationCustomUI_20xx.xml, PowerPointIntegrationCustomUI_20xx.xml, and WordIntegratioCustomUI_20xx.xml, where 20xx is either 2007 or 2010.    Save the versions of the files you need, rename each appropriately and remove the “_20xx” from the name of the file (i.e., WordIntegrationCustomUI.xml).

Now that you have your files, create a %ProgramFiles%\Interwoven\WorkSite\IntegrationCustomUI folder and place your files within.    Edit the XML file in a text editor to remove the buttons/items as needed.  For example, to delete the Compare and Merge WorkSite Documents button in Word, delete (or comment out) the text highlighted in red below from the WordIntegrationCustomUI.xml file:

<group id=”WordWorkSiteMailMergeGroup2″ getLabel=”getLabel” getVisible=”getVisible”>
<button id=”WordWorkSiteMailMerge2″ getLabel=”getLabel” onAction=”OnActionWordButton” size=”large” image=”merge2_32″ getSupertip=”getSuperTip”/>
</group>
<group id=”WordWorkSiteReviewGroup2″ getLabel=”getLabel” getVisible=”getVisible”>
<button id=”WordWorkSiteCompareMergeDocuments2″ getLabel=”getLabel” onAction=”OnActionWordButton” size=”large” image=”compare32″ getSupertip=”getSuperTip”/>
</group>
<group id=”WorkSiteHelp” getLabel=”getLabel”>
<button id=”WordWorkSiteAbout” getLabel=”getLabel” onAction=”OnActionWordButton” size=”large” image=”about32″ getSupertip=”getSuperTip”/>
</group>

Save your file, close and re-launch Word, and that button is gone.  It works pretty well, and I don’t think too many customers even know that this is customizable.

Update 1 is more modest, with only one notable new feature and several stability enhancements to the Email Filing Service (EFS).   According to the release notes:

Email Filing Server allows clients to permanently delete e-mail messages from user mailboxes once filed in WorkSite.

Now, I’m not sure how many organizations are comfortable with any other product permanently deleting emails, but I guess if one is so inclined…    The bug fixes are all focused on the EFS module, and how it handles multiple threads and email duplication detection.

I am currently working on installing this into my lab, and I will be sure to share any bugs I uncover.  One quick thing to note is that it requires a full uninstallation and reinstallation.   This is not just an upgrade, so keep that in mind.

After some troubleshooting, we eliminated the former, and discovered the latter.  The conflict occurs when Summation 2.9 is installed on the workstation  (Not sure yet if the newly released Summation 3.1 is any better).   One workaround is to utilize server-side filing for email management.  However, if you do not have WorkSite Communicaton Server, then the following registry key can be set to resolve the conflict:

HKEY_LOCAL_MACHINE\SOFTWARE\Interwoven\Worksite\8.0\FileSite

DWORD: CreateUnicodeMessageFile

VALUE: 0

Using the 8.5 SP1 (and above) Deploy Tool, you can now choose whether to include the Active Content Engine (ACE) in your deployment.  Nice improvement over the first iteration where the entire ACE implementation was a manual process.   There’s also an option to perform an Initial Indexing procedure.  From the Indexer Administrator’s Guide:

Initial Indexing- Select this option to build a pre-configured deployment package for the initial build of the index. With this setting enabled, the WorkSite Indexer is optimized to index a large dataset quickly; the Active Content engine is not used with this option enabled. This option is strongly recommended to decrease the time it takes for WorkSite Indexer to complete the initial index build. After the initial index has been created, deselect this option, regenerate the configuration files and apply them to run WorkSite Indexer in normal mode.

The thing to be aware of with this option is that documents weren’t committed until the entire crawl was complete.  So users were unable to get full text results during the initial build –  much like the first release of the 8.3 Indexer (driven by the Vivisimo engine).  If you are building this index in parallel with a production indexer, then users aren’t affected.

The other thing for you to keep in mind is that even though 8.5 SP1 P1 was released after the 8.5 SP1 Incremental Update, you still need to apply the Incremental Update to your environment.  Autonomy has informed me that the Incremental Update will be included in a P2.   No word on when that is to be expected, however.

In summary, the 8.5 SP1 P1 install and deployment is much slicker and automated than the previous 8.5 IDOL indexer releases.  The integration of the ACE into the Deploy Tool is a nice feature.  The Initial Index feature is nice, as long as you know the potential user impact during the crawl.