Image: Photodisc Blue		 



Slam the Door on E-Mail Retention Woes
A law firm IT director finds KVS Enterprise Vault effective

Erica Meyer Greathouse
Legal Tech Newsletter
02-28-2005



Like most of you in IT -- OK, maybe all of you -- we at Cox, Castle & Nicholson struggled mightily with many concerns surrounding e-mail retention. The paramount question was: "Now that e-mail has become ubiquitous and constant, how do we ensure client-related mail becomes a part of the client record?"

Ancillary, but no less vexing, questions arose:

  • How do you keep timekeepers from receiving constant "Your mailbox is over its limit" messages without giving them unlimited mailboxes? (What limit short of unlimited would not result in that message? And the corruption and other risks of an unlimited mailbox are well-documented, given that Exchange is a truly terrible database.)

  • How do you eliminate reliance on the notoriously fragile and unreliable PST format?

  • How do you improve searching (Outlook, after all, does not permit searching attachments, and is painfully slow to search message content)?

  • How do you eliminate redundant message storage?

  • How do you create collaboration, considering the stew of issues any solution would have to address in order to be effective?

    In the spring of 2001, we happily rolled out new desktop hardware with Outlook 2000 integrated with Hummingbird's PowerDOCS 3.5.1, believing we had found the solution to our e-mail woes. We figured a simple drag-and-drop into the proper DOCS library, familiar profiling (the e-mail integration automatically set the e-mail's subject line as the doc title, and mailbox name as author, saving lots of typing), combined with the ability to secure sensitive mail, would provide the answer to managing the unmanageable.

    We quickly found, however, the Achilles heel we had not considered. We had already discovered in our test environment that timekeepers would need to be taught to set profile defaults (e.g., set client and matter number), so that multiple e-mails could be profiled quickly. However, we had not considered the fact that even with profile defaults set, the timekeeper had to click "OK" for each e-mail profiled. For a busy timekeeper trying to save potentially hundreds of e-mails per day, this simply wasn't workable and was soon abandoned by virtually everyone.

    So, by the summer of 2002, the hunt was on for a product that would allow the firm to address all the issues outlined above and require little to no intervention on the part of the timekeeper. Perhaps your firm is a large, corporate-type entity where a directive can be issued from on high and all will follow it, so your IT department can craft its solutions based solely on technical merit. Ours, in contrast, is a firm that prides itself on the freedom of attorneys to practice as they see fit, within reason, so any solution that would require much investment in timekeeper time would be ignored, and the expense thus a waste. However, because our IT department is extremely lean, we must also ensure our solutions are technically sound. We just don't have the staff for constant troubleshooting and user hand-holding.

    FINDING KVS ENTERPRISE VAULT

    We investigated everything then on the market. We considered upgrading DOCS, since its newest e-mail integration offering was considerably more robust, but, unfortunately, we had to rule it out on two counts. Hummingbird's DM 5 required more workstation horsepower than we had to offer, so the cost to implement would be astronomical (don't forget, we'd upgraded all the hardware only a year earlier).

    Plus, our experience with Hummingbird had made us quite cautious; a product needed to be in release for at least a year before it would be stable enough for us to roll out. What is now Interwoven's iManage was quite stable, and its e-mail integration was both robust and well seasoned, but again, the cost to migrate was prohibitive. So, we turned to e-mail-only solutions, such as EAS (Exchange Archive Solution). Many of you currently use this product, and by most counts, successfully.

    However, at the time we reviewed it, and I'm not sure if this has changed, its support was via e-mail only. We thought relying on e-mail support for e-mail problems was counterintuitive, especially given the now mission-critical nature of e-mail; however, the EAS model was otherwise exactly what we wanted. After much investigation, a tour of a firm already using the product, and a presentation to our Tech Committee, we settled on KVS Enterprise Vault.

    The Enterprise Vault addressed all the concerns listed near the top of this article, with the added bonus of significantly compressing e-mail message storage (the original message is replaced by a pointer to a SQL database referencing its Vault location).

    But it didn't offer the ability for timekeepers to collaborate within teams (more about this later). The Vault uses the powerful Alta Vista search engine for searching, performing everything from a simple "sender/subject line" search through full Boolean wildcard searching, and also offers the ability to categorize messages for auto-purge after their retention period had expired -- for example, messages categorized as "transactional" could be retained for 10 years; messages categorized as "estate" could be retained indefinitely, while messages categorized as "admin" could be retained for only three years.

    However, ours being a firm where the concerns of the transactional practice ("if we keep everything in perpetuity, we can prove we sent/didn't send it/them/those") often override those of the litigation practice ("if e-mails follow our document retention policy, let the other side prove we sent/didn't send it/them/those"), we ultimately elected to categorize all e-mail as "business" with a retention period of "forever." This may change down the line, as timekeepers become comfortable with the Vault and as case law becomes more defined regarding e-mail retention/destruction, but is currently the policy.

    REGARDING COLLABORATION

    The out-of-the-box solution provided two methodologies: The user could either auto-Vault messages once the mailbox reached a certain threshold relative to "full," or the user could proactively Vault. However, messages were, by default, awarded the same permissions they had in Exchange. So, rights anyone had to a timekeeper's Exchange mailbox also applied to mail in the Vault -- which meant some assistants could view mail in their timekeepers' Vaults, but virtually no one else in the firm could see any of the mail. Certainly, giving everyone rights to everyone else's Exchange mailboxes wouldn't fly. There was much debate on the Tech Committee as to the necessity of collaborative tools at all; most seemed to feel no one would use them even if they existed, and the fact the Vault won't save multiples of the same message, but rather gives a pointer to the same message if saved multiple times, addressed our concern about redundant storage. One partner, however, was adamant, and so we approached KVS about customizing the Vault to allow a shared archive.

    This process proved far more arduous than we had anticipated, but after nine months of wrangling, first with a KVS-approved integrator who abandoned the project midstream, and then with KVS's integration services directly, we had a workable solution.

    A script was provided that, when run against a user's mailbox, creates three folders:

  • The first folder, called "Vaulted -- Not Shared," allows a user to proactively imitate the native functionality of the Vault (this folder is not actually necessary, as auto-archived mail is also Not Shared, but allows the user to organize mail in subfolders outside his main inbox to cut down on "inbox clutter," as well as adopt subfolder names as additional search criteria). The reason auto-archived items are Not Shared by default is to avoid sensitive e-mail, such as personnel matters, being shared through the inaction or negligence of a user. There is currently no way to set this option by user. If this was an option, it would certainly enable better collaboration on the part of most timekeepers, exempting only a few. However, it would also be preferable to allow selective sharing by team, rather than firm wide, so the solution isn't perfect either way.

  • The second folder, entitled "Vaulted -- Shared," allows the user to create named subfolders and send mail to the Vault that is subsequently searchable by everyone in the firm. While this isn't ideal -- it would, obviously, be preferable for users to be able to assign permissions for their team only -- given that a user would have to know for what to search, it's unlikely people will really be snooping around the Shared archive unnecessarily.

  • The third folder is for mail that needs to be held only temporarily (e.g., directions to a firm event, or a luncheon invitation from a colleague) and is called "Not Vaulted." This last, critical, folder allows a user to place mail that he never wants to wind up in the Vault, as this folder is exempt from the auto-archiving process (a user could proactively Vault items in this folder, but why would he?).

    Where the litigators and our executive director prevailed was in disallowing the ability of end-users to delete items from the Vault. The Executive Committee agreed that the integrity of the client record might be compromised by, say, sabotage on the part of a departing timekeeper, and sensibly saw that allowing users to perform even what might be considered benign deletions could result in the appearance they were trying to hide something.

    We in IT were concerned that a user would delete from the Vault, not remember having done so, and blame the technology -- not a concern in the Outlook/Exchange-only environment, where a user's entire mailbox might be compromised, but individual items don't typically "disappear." Items are actually safer in the Vault environment, where there is a period before backups have completed where mail exists in both Exchange and the Vault, but allowing end-user deletions does away with this safeguard (and, of course, one can never recover when one wants to, only when one would prefer not to).

    Additionally, we found during testing that some timekeepers, not liking the idea of the Vault's seeming permanence, and not understanding that "deleted" mail would only truly be deleted if removed from all sources (e.g., both sender and recipient's workstations, all servers, BlackBerries, etc.), continued to save mail in PSTs. We therefore used a combination of registry hacks and Group Policy Objects to disable users' ability to create PSTs and migrated all existing PSTs to the Vault. By default, these migrated PSTs were not shared, as there exists no mechanism for migrating to a location other than the user's default Vault.

    CAN STILL HIT LIMITS

    It's important to note that both the Vault pointers and the Not Vaulted folder continue to contribute to overall mailbox size, so it is possible that eventually a timekeeper's mailbox would be over limit even if every e-mail were Vaulted, given our limit of 150 MB for timekeepers' mailboxes. We have found that, while timekeepers are initially concerned about having "instant access" to the pointers to mail in their inboxes, they quickly become comfortable with the robust searching and delete the pointers with some regularity.

    Pre-Vault, we prohibited sending of e-mail once the user's threshold had been reached, because we found simply getting annoying "Your mailbox is over its limit" messages weren't sufficient to force them to clean up their mailboxes. However, we quickly found the same Exchange mechanism that prohibits sending e-mail also prohibits Vaulting (both proactive and automatic) of items, making it necessary for users to delete items to get below their threshold -- a direct contradiction of what we were trying to accomplish. So, we disabled the "prohibit send" feature. It's not really an issue anyway; once a timekeeper's mailbox reaches 70 percent of limit, items start auto-vaulting, thus theoretically keeping them from receiving "mailbox over limit" messages.

    Two caveats about this, however. First, the language in the Vault's administration console seems to imply the threshold should be set according to percent of full and of course only works if the mailbox has a limit. However, we found the threshold setting actually refers to percent free -- quite a difference. We initially set this figure to 70 percent, but found that all but 30 percent of timekeepers' mail was being Vaulted, which gave them no opportunity to move items into Shared, Not Vaulted, or even Not Shared subfolders. So, since we want auto-vaulting when the mailbox reaches 70 percent of limit, or about 87 Mb, this figure is now set to 30 percent. Those who receive a large volume of e-mail, or e-mails with large attachments, however, are well advised to proactively Vault, as a few large e-mails can quickly put them over the limit, and the Vault cannot be used as a remedy for "over-limit" messages. We only run the Archiving service at night because if a timekeeper attempts to proactively Vault while the service is running, an error is generated, which we thought was counterproductive to getting them to be proactive throughout the day. Therefore, once a user receives the "over-limit" message, he's pretty well stuck until that evening.

    We found one final vagary. Despite what KVS's tech support told us, it's important that the software versions on the server and workstation match. If they don't, we found that items sent to Vault were "pended" in perpetuity, meaning both that they existed in Exchange and Vault, and that some actions can't be performed on them. Once we had all workstations updated to the latest version, this problem disappeared. This information will obviously be helpful in planning future upgrades.

    Finally, although we've given staff access to search, and save items in, the Shared Vault, no non-exempt staff has his own Vault. We determined it was highly unlikely any client-related mail would come directly to a staff member (even assistants) without also being copied to a timekeeper, so there's no need for staff to have their own Vaults.

    Moreover, in examining the overall storage issue, we found we had a lot of staff storing non-business mail (such as jokes) in PSTs, so we disabled their ability to create PSTs. Prior to doing so, we advised them to clean out any non-business mail from PSTs and all remaining messages stored in PSTs were migrated to the Shared Vault. Going forward, staff who need to save business-related mail that should not be shared are to do so in DOCS; as this is a one-off process, the volume concerns that the timekeepers had with DOCS aren't an issue. Assistants have the same access to their timekeepers' Vaults that they have to their mailboxes (eg, those who have full rights in Exchange also have them to the Vault; those who have no rights in Exchange have none to the Vault), except they are unable to Vault on behalf of the timekeeper regardless of Exchange permissions.

    AND THE RESULT?

    So, are we happy? In retrospect, we would have insisted on rolling out the Vault's native functionality right away, with the "Shared" enhancement to follow. As it turns out, even the partner who so vociferously championed the Shared Vault admitted he doesn't use it, as it's too time-consuming to assess each e-mail as to whether or not it should be Shared, so our users unnecessarily endured an additional 9 months of e-mail agony. I don't say that to disparage the attorneys; on the contrary, I wonder how they keep up at all, what with all the extra work "timesaving" technology has added to an already crushing workload.

    And, as with all new initiatives, the Vault posed a steep learning curve for both IT (as is often the case with vendors' tech support, we frequently felt we were showing KVS how their product works) and our "test pilots." Once all the bugs were worked out, however, we've found it takes little maintenance on our part and very little intervention from the user. One attorney told me it's the best thing that's happened to him since he met his wife (and yes, they're quite happily married).

    Erica Meyer Greathouse is director of information technology at Cox, Castle & Nicholson LLP in Los Angeles, one of the nation's largest firms specializing in the real estate industry. For the 10 years preceding her first Technology Director position, at Weston Benshoof, she was president and principal of a technology consulting firm specializing in the legal industry.

    Subscribe to the Legal Tech Newsletter.