Kraft & Kennedy, Inc. provides technology and strategic consulting services to law firms, corporate legal departments and financial services firms. We can help you analyze, plan, implement and manage business and technology solutions to optimize your organization's functionality and processes.
Autonomy (HP) recently released WorkSite Server 8.5 SP1 Update 6, with a new enhanced server-side email duplication detection technology. Previously, the FileSite client would evaluate duplicates based on the MSG_ID value from Exchange. This often caused problems with forwarded messages, or certain Outlook forms that share a MSG_ID. Update 6 enables server-side duplicate detection based on the message send date and message subject, in addition to the MSG_ID. So this now means that forwarded messages are NOT duplicates, and would also be filed – a little something to keep in mind when it comes to expected storage on your file servers and indexers. More emails will be filed with the new algorithm.
While I was on vacation, there was some big news in Legal IT: HP announced their purchase of Autonomy for $10.2 Billion in cash. First of all, that’s a lot of cash, and with ATMs allowing a max of only $2,000 cash to be withdrawn per day, it will probably take a while for the deal to finalize. All kidding aside, this is just another shake-up in the long list of shake-ups along both the iManage as well as PC DOCS/DM/eDOCS lines. Like other major announcements, it will take time to see any real changes in the marketplace. I do wonder though if this will make iManage customers feel smaller, as they are now under an even larger umbrella. I’m not quite sure what to make of it yet, but look forward to finding out more about it at ILTA 2011 in Nashville, TN. Please see our ILTA post for details on where we’ll be and what we’ll be up to at the conference this week!
In working with iManage 8.5 SP2 Update 2 and Update 2a, we’ve identified a bug when printing page ranges with Word, Excel and PowerPoint 2010. The problem is that if a user goes to File –> Print, and chooses a Print Range (a single page, or “Pages 2-4”, for example), the ENTIRE document will print. This is REALLY annoying (and wasteful) for documents that can have 100s of pages.
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.
Last Friday, Autonomy released Service Pack 2 of their WorkSite Indexer 8.5 and iManage Universal Search (IUS) Server 8.5. In addition to several resolved issues, Service Pack 2 introduces some much anticipated enhancements, including:
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…
Recently, a client of ours with Exchange 2010 asked a question. “How does Autonomy iManage’s Email Management work with Exchange 2010 Archive Mailboxes?” A great question. Kraft Kennedy has implemented the WorkSite Communication Server (WCS) and Email Filing Service (EFS) at several Exchange 2010 sites over the past year, but to this point, hadn’t come across a firm looking to leverage the built-in mail archiving functionality of Exchange 2010. So we asked Autonomy how their EFS would handle it. There was no mention of this functionality in any Release Notes, Install Guide, Admin Guide, or knowledge base tech note. After being escalated to a product manager, we were informed that this functionality had not been part of any testing or QA for the 8.5 line of EFS.
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.
Continue reading…
Recently, Autonomy released the 8.5 SP2 Update 2 versions of iManage FileSite, DeskSite, OffSite, Email Management for FileSite, and Email Management for Outlook. The key new feature is support of Adobe Acrobat Reader X. However, due to a new feature of Reader X, a configuration change within the Reader application is needed. From the Release Notes:
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.
iManage 8.5 SP2 clients come with some really great integrations into Office 2007/2010 out of the box. As you probably know, Office 2007 introduced a pretty nice native document comparison function that makes small firms think twice about WorkShare Compare. iManage provides the ability to use the native Office 2007/2010 document comparison engine for documents living in WorkSite. It also allows the user to manually insert a WorkSite Footer into the document.
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.
Continue reading…
Last week, Autonomy iManage quietly released Update 1 for the WCS for Exchange 8.5 SP1. Service Pack 1, which was released earlier in the year, included many features that made the infrastructure and design of WCS more efficient. Namely, the ability to connect a WCS to multiple Exchange mailbox servers. This was a major issue with the initial release of WCS 8.5 for firms with distributed Exchange environments but a centralized DMS. It wasn’t even worth going down that road until WCS 8.5 SP1 was released.
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.
We’ve seen this issue occur at a few implementations, and felt we should share if anybody else is experiencing it. When using iManage 8.5 and performing a client-side filing of email, users may receive the cryptic message: “Unable to retrieve email from Exchange or a conflict exists”
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\FileSiteDWORD: CreateUnicodeMessageFileVALUE: 0
After running into a couple issues with the iManage IDOL 8.5 SP1 release in our production environment, I was able to complete the index build using the 8.5 SP1 P1 release that was released last week. Our initial errors were found in our Content Engine logs referring to a lack of free disk space, even though we had successfully had our IDOL 8.5 (pre-SP1) index on the same volume earlier. In any case, I added some space and then recrawled using 8.5 SP1 P1. I’ve read some similar reports on user forums, so if you have a smaller volume for your IDOL indexer, just keep this in mind.
Continue reading…