In an announcement today, World Software Corporation — makers of the Worldox document management system — shared the news that their latest release now supports Office 2010.   According to my notes here, this makes them the first DMS vendor in the legal space to officially support integration with Office 2010.

There are a few caveats.  At this point, only 32-bit Office 2010 is supported.  No word yet on 64-bit support, but they say it’s coming.   You also need to be running the latest version, Worldox GX2, and you should contact Worldox support to download the updated integration files.

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.

After installing the Office Web Apps, the first thing you’ll notice is a few new options when accessing the context menu of a document in SharePoint 2010.  The new options include View in Browser, Edit in Browser, and Edit in Microsoft Word.

SharePoint 2010 with Office Web Apps

Clicking on Edit in Microsoft Word will simply launch the version of Word that you have installed locally on your workstation.  But what if you don’t have Word installed?  What if you are on a hotel kiosk computer or a netbook?  In that case, you can click on Edit in Browser to access the Word 2010 Web App.  This will open the document for editing with your browser.  This is designed to work in IE, Firefox, and Safari; but will require the SilverLight plug-in to be installed for the best user experience.

The look and feel of the Word 2010 Web App is quite impressive.  There are navigation links across the top of the browser that can take you back to Client or Matter sites if you have those.  There is also the Office Ribbon Bar built right-in, and a link to launch the document with the locally installed Word client.    Tired of working with the current browser window?  Simply click the Pop-Out icon, highlighted in red in the upper right of the document, to open a new browser window without all the other browser toolbars cluttering the view.

Word 2010 Web App

Until Office 2010 is officially released, you will need to edit the document in the browser using the Word 2010 Web App if you want to take advantage of the simultaneous editing feature.    It will also be interesting to see which other features of the full Word 2010 product Microsoft incorporates into the Web App — Document Comparison?  Track Changes?    We’ll keep our ears to the wall.

Security is always a concern in a law firm, and is especially important in the legal department of a corporation. Lawsuits sometimes include the company’s co-workers, competitors, or other sensitive information, where certain matter information needs to be completely hidden from all but a few matter assignees. Securing documents or DMS folders is often simply not enough protection.

Does the system hide the matter from appearing when doing a table look-up on a search form? Does it hide the matter when accessing the matter table via the DMS web module? For some cases, you want to hide the actual matter itself, so users won’t even know it exists.

Vendors have been known to describe their products as having Ethical Walls, when in reality these products only provide security at the document or folder-level. The matter itself can still exposed on a look-up table.  One possible workaround to this is giving these secured matters a very general description of “Secure” without exposing any matter details.  However, this severely limits the ability of users to perform a matter-name search for the secured matters they are assigned to.

Worldox GX2 has a built-in Ethical Wall that is just what it says it is. Worldox’s Ethical Wall feature is solid and will actually hide the matter itself from even appearing. The only downside with the current version is that it requires a lot of hands-on maintenance to set up the proper rules. Maybe in a future release it can be synced to some external security database? A consultant can dream…

When looking at Ethical Wall solutions, you want to make sure that all doors are closed to the matter information. The last thing you want is to purchase an Ethical Wall and then find out it’s an Ethical Window.

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.

A couple weeks ago I blogged about the XML patent infringement that Microsoft had to deal with.  As mentioned in that post, they’ve released new code that removes some of the custom XML functionality that was built into the Office 2007 system, and brings them into patent compliance.

We’ve just heard that there is at least one vendor whose product is now basically non-functional due to the code change.   This sort of problem can result in products needing to be completely re-engineered to work with the new XML limitations.

Organizations who have already implemented or are looking to implement Office 2007 should reach out to any third-party vendor who would be integrating with the Office 2007 XML format to determine compatibility with the new rules.  In addition, any custom code that has already been written would need to be tested and possibly re-written if any issues come up.

Kraft Kennedy has worked with numerous third-party vendors that integrate with Office 2007.  If you find yourself in a tough spot due to this issue, let us know and we can help walk you through the process of finding the right solution.

As you may have read, a judge recently upheld a court ruling which bans Microsoft from selling Word 2007 after January 11, 2010, due an XML patent infringement.  That was yesterday.

Today, Microsoft announced that they have released a patch which corrects the patent infringement, bringing the Office 2007 code under compliance:

The 2007 Microsoft Office OPK Master Kit Download, available on Microsoft’s OEM Partner Center, strips Word and other Office programs of custom XML editing capabilities.

“The following patch is required for the United States,” Microsoft said in a message on the site.

The 2007 Microsoft Office OPK Master Kit Download (12.9 MB) can be found at the Microsoft OEM Partner Center.  The site also says:

After this patch is installed, Word will no longer read the Custom XML elements contained within DOCX, DOCM, or XML files. These files will continue to open, but any Custom XML elements will be removed. The ability to handle custom XML markup is typically used in association with automated server based processing of Word documents. Custom XML is not typically used by most end users of Word.

Pretty quick turnaround, but I have a feeling they were working on this for a while…