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.

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.

As many of you may have heard, Autonomy officially released iManage 8.5 SP1 on Monday.   This has been an eagerly awaited release for months now, and firms are looking to implement this pretty quickly.    Here are the modules that have 8.5 SP1 releases thus far:

• WorkSite Server (with and without Caching)
• WorkSite Clustering Service
• WorkSite IDOL Indexer
• WorkSite Communication Server for Exchange
• FileSite, OffSite, DeskSite, Email Management for Outlook clients

Our initial review is under the fold.

Some of the good news:

• There are lots and lots of fixes in SP1 across the board.   Be sure to download the Release Notes for the iManage 8.5 SP1 Desktop clients, as that includes all the new fixes that are included in the release.
• There’s a search ranking column now available in the client.  This may not be hugely important, but it is something that iManage’s competitors have had for a while.
• Overall, the IDOL search should be more relevant and with fewer syntax confusion than previous releases
• All server modules now support Server 2008 R2 (however only the IDOL Indexer will actually run in 64-bit mode)
• For administrators, for the first time since Verity, we can now control the WorkSite Indexer services from the WorkSite Service Manager!   The WorkSite Indexer Service is designed to gracefully stop and start all the IDOL services cleanly.   We’ll have to test this one out to make sure…

And the (perhaps) not so good news:

• The Email Filing toolbar in Outlook 2007 has been updated, and (in my opinion) may cause some confusion and perhaps some eye-popping blunders.  The updated toolbar has a Delete button, which actually performs a ‘File and Delete’ operation.   I can picture it now:  an attorney gets a personal email from a client (perhaps with something embarrassing), and accidentally files it to a suggested WorkSpace because he hit the ‘Delete’ button at his Outlook toolbar.  Oops.   See below for a preview, and let me know if you agree:

• A complete IDOL Index recrawl is required to upgrade to SP1.  This will either require possibly significant index downtime, or the purchase of new hardware to build a parallel 8.5 SP1 index.

Overall, after looking through all the documentation, it looks like the benefits will outweigh all of the potential concerns. I am sure updated builds will be released, so it is important again to keep an eye on the WorkSite Technical Support page and look for updated builds and documentation.

We are testing the final release of these products in our research environment and soon production.    Just as with any other iManage release, 8.5 SP1 should be tested on non-production servers with copies of the production databases.   One of our best practice is to take a subset of the production documents and copy them to a test file share, and update the DEFSERVER key to point to your test file share location.  This way you are assured of not touching any production documents when testing your updated server.  As we learn more, we will be sure to share.

With Office 2010 being unleashed on the world, many customers are asking when their DMS products will support it.   No need to ask around, because we’ve gathered the official stances for some of the major vendors.

• WorkSite iManage 8.5: “We will look to certify/support Office 2010 within 90 days with the current 8.5 Worksite clients and later”
• Open Text eDOCS DM 5.3:  “We will release v5.3 beta this summer and the final release is scheduled to be launched in late September”
• Worldox GX2:  “Office 2010 integration files should ship within 30 – 45 days of the official general release of Microsoft Office 2010″
• Microsoft SharePoint 2010:  “Come on, we’re Microsoft.  It’ll work day one!” (Disclaimer: NOT a real quote)

So as of right now, it looks like Worldox may win the horserace to support Office 2010.  As soon as official release announcements are made, we will be sure to test functionality in our research lab.  Of course, simply supporting integration with the application doesn’t mean that the DMS product will be able to leverage any of the extra features of Office 2010, such as the Backstage view or simultaneous editing (which requires the document live on SharePoint 2010).

For those of you interested in running the iManage 8.5 IDOL Indexer, Autonomy recently released a new revision of the WorkSite Indexer Administrator’s Guide (8.5).   It is available on the iManage support site, and includes an updated Chapter 6 on “WorkSite Indexer Maintenance.”    The document goes into explicit detail on how to properly back up and restore an 8.5 IDOL index.    (Note: you must exclude the entire WorkSite Index folder structure from normal backup agents, as this could corrupt the indices).

In summary, there are 3 types of items that need to be backed up, and then restored:

1. All WorkSite Indexer configuration files (*.cfg)
2. All WorkSite Connector files (*.db)
3. All WorkSite Content index backups (the actual indices themselves)

The first two can be configured as simple robocopies of the production *.cfg and *.db files into a similar backup folder structure.    The third can be scheduled by updating each WorkSite Content *.cfg file to include particular options in the [Schedule] section.  The key thing to remember about the WorkSite Content is that the backup will be just about as large as your production WorkSite Content, so you would want to either make sure there is enough local hard drive space or available space on an accessible SAN LUN to store the backup copy as it is put onto tape.  This is something that needs to be considered when estimating the storage requirements of the system.

To restore the index from the backup, you need to ensure that the *.cfg files are in place.  If they are not, then copy these from your backup location into the appropriate production folders.  The next step is to restore the appropriate WorkSite Connector *.db files.     These aren’t really database files, but rather a timestamp to tell IDOL from which document modification date to start rebuilding the index.  For example, indexing all documents that were modified after 5pm last Tuesday.   Unfortunately, the timestamp looks like gibberish to the human eye, if you ever have to modify it.   From the Administrator’s Guide:

If no db file back up exists from the same time as the index data back up, the timestamp of the Connector db file can be manually modified to coincide with the time of the index data to be restored.

The WorkSite Connector db time should always be set to a time immediately before the index data back up in order to ensure that the WorkSite Connector begins indexing from a time that is synchronized with the index data. Setting the date time too early can result in unnecessary re-indexing and therefore impact disk space as well as performance; setting the date time too late can result in a gap of new content and edits that is not indexed.

For reference, the timestamp value stored in the WorkSite Connector db file is in EPOCH format (time since 12:00 a.m. January 1, 1970 in milliseconds). For example, a timestamp of “1256942003000″ in the file translates to “22:33 UTC October 30th, 2009″ in a standard date notation.

Figuring out how many milliseconds after midnight on January 1, 1970?  That sounds pretty daunting.  But there are conversion tools available online to help with this.     After each *.db file is in place, each WorkSite Content engine would need to be restored using the /DREINITIAL command pointing to the backed up Index.  

Further details are available in the documentation, but the key takeaway is to avoid using Backup Exec or a SAN snapshot and expect a healthy restored index.  There are special steps that need to be taken to ensure a reliable backup.

I recently performed an upgrade from iManage 8.2 to iManage 8.5 Update 4.    Update 4 was released on January 14th and resolves several issues regarding service stability and wildcard searching.  It adds support for the new WorkSite FileShare, iManage Workflow Manager, and iManage Digital Safe.  I plan on blogging about these modules soon, so keep an eye out for that.

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.

One of the most overlooked pieces of technology in law firms is PDF creation.    Yet it’s also one of the most important to an end user.  It needs to be simple, stable, and usually needs to integrate well with a DMS system.

With iManage, you have three main choices.  Do you A) use the built-in “Convert to PDF/Send as PDF” utility function, B) find a third-party tool with full integration, or C) use the native Save As PDF option available in the Word 2007 Office Button.

Let’s start with option C: the native PDF function in Word (see below), and let’s assume we want to convert an iManage document #12345v1 to a PDF.

Native Word 2007 Save As PDF

When choosing the Save As –> PDF option natively, Word will prompt to save the PDF locally.  By default, the location will be the same location as the original Word file was saved.  In the iManage world, this is in the NRPortbl directory, and the filename of the original Word document is 12345_1.DOCX.  Unless the user changes the Save location or filename, the converted PDF will live in the NRPortbl directory as 12345_1.PDF.   This is bad.   When the PDF is opened while the Word document is still open, the PDF will display as if it were already in iManage, due to the 12345_1.PRF file in the NRPortbl directory, which is supposed to be for the original Word document (12345.DOCX).   The problem is that the 12345_1.PRF file indicates that the iManage file is associated with the WORDX application, so when trying to save the PDF file into iManage, it will get confused and ask to create a new version of the Word document.  In addition, it will set the application to be WORDX (as specified in the PRF file), so after it’s saved into iManage, it won’t be associated with the ACROBAT application.  Not good at all.   For these reasons, we recommend disabling the native Save As PDF function in Word.

Next, let’s look at option B:  Finding a third-party tool with full integration.   A lot of people think that Adobe is the best choice for PDF creation/integration with a DMS. However, the integration with iManage is rather weak.   Sure, you can Save to WorkSite and Open From WorkSite, but that’s about it.  And that’s only from Acrobat itself.  What about from Word?   Acrobat has it’s own Ribbon bar in Word 2007 (see below), however this doesn’t integrate with iManage at all.   There is no ability to save as a new version or a new related document in iManage. 

Word 2007 Acrobat Ribbon Bar

In fact, clicking the Create PDF button here will cause the same NRPortbl issues we had with the native Word 2007 Save As PDF option.    Unless the user changes the location or filename of the converted PDF, problems are bound to occur.   For these reasons, we recommend disabling the Acrobat Add-in in Word. 

So what third-party tools do provide full integration?  One is pdfDocs by DocsCorp.  DocsCorp actually announced in a press release that their integration is out of the box and shows up as long as it detects the iManage 8.5 client during the install.   The added functions are very useful, and available both in the iManage client itself, as well as in the Ribbon bar in Word 2007.   Below is how the integration looks from the iManage 8.5 client:

iManage pdfDocs Integration

Native iManage PDF Utility

 

When choosing Convert to PDF, there will be a prompt asking whether to save the PDF as a new version of the original Word document, or as a new document that is related to the original.

As you can see, there are a lot of things to think about when introducing a PDF creation utility into an environment with a DMS.  The cleanest way would probably be to obtain a product with full integration.  The next best thing is probably to use iManage’s native Convert to PDF function in combination with an Adobe PDF printer.   But in the end, you must decide what would be easiest for your users to adopt, and would be most stable in your environment.

Autonomy iManage and OpenText eDocs both have protocol handlers for SharePoint, which enable the SharePoint Enterprise Search engine to index documents stored in the DMS, while keeping the documents in the DMS.  Many people haven’t been aware of this and thought you had to migrate all of the documents into SharePoint to search them, or to use an enterprise search engine provided by the DMS vendor.  However, these protocol handlers can provide the best of both worlds by allowing you to continue managing documents in the current DMS, while taking advantage of Microsoft’s FAST enterprise search indexer to index the DMS content, SharePoint content, file shares, web sites, Exchange public folders, and other enterprise systems.  Security trimming is preserved by the protocol handler, so users will never see documents in the DMS that they don’t have access to.  The protocol handlers both support Microsoft Office SharePoint Server 2007.

More information on the OpenText eDocs SharePoint integration and protocol handler can be found here:

http://www.opentext.com/download/livelinkdownload.html?path=product/microsoft/ot-clmsp-edocs-po.pdf

More information on the iManage SharePoint protocol handler can be found in their partner portal, by filtering the list of products to “SharePointProtocol Handler.”  Note that you need a partner login account to download the documentation and release notes.

http://worksitesupport.interwoven.com/WorkSite/scripts/portal.aspx

Both vendors also offer a comprehensive set of web parts to drop into a SharePoint environment to view and manage their documents from within a SharePoint site.

Recently, Kraft Kennedy became one of the first integrators in the industry to complete an implementation of iManage 8.5 GA in production at a law firm.   This particular firm is taking advantage of the predictive Email Filing and Email Management capabilities of FileSite 8.5 GA and the WorkSite Communication Server 8.5 GA, complete with OffSite for offline access and the iManage 8.5 IDOL Indexer handling search requests.

After the initial roll-out of the GA release, there were several issues that appeared, and were confirmed with Autonomy iManage technical support.  The first issue involved security inheritance, and manifested itself when saving documents into folders with specific users or groups added to the permission ACLs.   In these instances, the document would simply inherit the default security of the folder (Public, View, Private), ignoring any additional ACLs.  The second issue regarded Outlook stability, where toggling between a WDS-integrated Outlook search and the Inbox would result in a crash of Outlook.  This crash was fairly common, since users tend to search their mail items daily.   The third issue was more cosmetic, but annoying nonetheless.  When disregarding a draft email, the message remained in the Drafts folder of Outlook.  Again, not earth-shattering, but annoying to have to see Drafts (15) in your mailbox after a few days.

In the past couple weeks, Autonomy has released WorkSite Server 8.5 Update 2, along with the FileSite/DeskSite/OffSite/EMM 8.5 All Languages release  (you will know if you are running the All Languages release of the iManage client software because the build number will be 8.5.200.x).     We are happy to report that this back-end and client update neatly addresses and resolves all three of these issues, in addition to several others.    Outlook is more stable, and there is no longer any issues with security inheritance.   If anyone is hesitant about moving to iManage 8.5, rest assured that the latest release appears to be stable and functions as advertised.

For those with access, more information on these updates can be found in the WorkSite 8.5 Resource Center at the iManage technical support web site.

In my previous post, I discussed ways of bringing the legal user community into the matter centric design process. That’s only the first battle. Once attorneys are able to visualize the concept behind the organizational folders of a matter centric WorkSpace, they may want the structures to mimic what they are used to — especially if they’ve never used a DMS before. They may want to stay within their comfort zone. And these may be the most powerful voices in the Firm.

Usually, what they are used to is an inconsistent, multi-level directory structure with custom folders containing perhaps a handful of specifically categorized documents each. This kind of structure makes sense when the only way of finding a document is by knowing which folder it’s in — as is the case without a DMS. In this scenario, you wouldn’t want to scroll through hundreds or thousands of documents in a folder. Rather, if you can limit the number of documents in a folder to a handful, then it is easier to find the document you need. This is what leads to the numerous directory levels and (in my humble opinion) overly specific classifications.

In the DMS world, there are much better ways of finding documents. The obvious option is the full-text search, which will provide efficient results (given the user properly knows how to perform a full-text search). In addition to the search, folder lists can be sorted and filtered based on any metadata column, and the WorkSite Miner is a nice utility to carve up the contents of a folder into more manageable groups.

iManage offers two levels of classification for documents — the Class (which generally corresponds to a WorkSpace folder) and it’s child Subclass. As the designer of the WorkSpace structure and metadata, you may get requests for numerous Subclasses. There are two main disadvantages of using Subclasses. First, requiring the Subclass adds dreaded extra clicks and keystrokes to each save action. If the Firm decides on using Subclasses, it is a best practice to make them required. If they are optional, they lose all value. There’d be no guarantee that searching for the “Loan Agreement” Subclass will return all loan agreements. This leads to the second key disadvantage — it will prevent the proper update of metadata when dragging-and-dropping documents from one WorkSpace folder to another, since it is up to the user to select a Subclass when saving into a folder.

So how do we get attorneys to accept not using Subclasses? Make sure they grasp all the different ways documents can be identified, sorted, filtered, and found in the system. Perhaps bring up the idea of a naming convention for the description of documents. Or perhaps make a deal — try it without Subclasses for six months, and then the issue can be re-evaluated. Chances are they will appreciate the ease of simply saving into a WorkSpace folder, and agree that there is no need for Subclasses. After all, less is more.

So you’ve decided to implement Matter Centricity at your firm.  Whether you are using Autonomy iManage (formerly Interwoven), Open Text eDOCS (formerly Hummingbird), or another Document Management System (DMS), the basic idea behind Matter Centricity is the same — to present virtual Redwelds for each matter, with folders to categorize and classify documents within.  Couldn’t be simplier!

But in order to design these virtual Redweld structures (iManage calls these “WorkSpaces”), input is needed from each Practice Area or department of the firm.  Since many of the users have no idea what Matter Centricity is, and some may not have any idea what a DMS is to begin with, it can be difficult to obtain the information needed to design a structure.

Here are a few tips to get the message across:

• Give a high-level 20-minute presentation prior to your WorkSpace design discussions with a user group.  Provide some screen captures to display a sample structure.  Briefly discuss how they would interact with the structure on their desktop environment. Even with this presentation, it is hard for some people to grasp the concepts and visualize the structure
• Take notes during the presentation and the following design discussion.  Try to identify those users who are having a more difficult time.  Notes are also very helpful when following up with certain attorneys or administrative assistants.  The user will appreciate that you remembered their comment from the discussion.
• Create some sample structures in a lab environment, based on the initial input of the user groups.  Invite some of the people who had a hard time understanding the concept and demonstrate how to save and access documents from the structure.  Hopefully this will help them along and their ideas can be included as well.

Using these tips, the hope is not only that the users better understand the concept in general, but also have a better idea of how their input for the design will be translated into technology and their daily work process.

In future posts, I’ll discuss how to interpret all this input and combine it with iManage and Kraft Kennedy’s best practices.