<i>Product Review:</i> KVS's Enterprise Vault Slams the Door on e-Mail Retention Issues

Like most of you ' okay, all of you ' we 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 like how to 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 to eliminate reliance on the notoriously fragile and unreliable PST, how to improve searching (Outlook, after all, does not permit searching attachments, and is painfully slow to search message content), how to eliminate redundant message storage, and how to effect some manner of collaboration, contributed to 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. 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 (eg, 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 (except possibly the biggest rainmakers) 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, of course), 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 because we just don't have the manpower for constant troubleshooting and user hand holding.

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's Enterprise Vault.

The Enterprise Vault (the Vault) addressed all the concerns listed in the first paragraph 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 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 (presumably to be re-categorized for destruction following the decedent's death), while messages categorized as “admin” could be retained for only 3 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.

Now, regarding collaboration. The out-of-the-box solution provided two methodologies; either auto-Vaulting of 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 9 (count 'em ' 9) 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, 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 (eg, 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?).

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. For our part in IT, we 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 (eg, 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 is 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% 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%, but found that all but 30% 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% of limit, or about 87 Mb, this figure is now set to 30%. 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 (that on the server), 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?

WHEW! 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)!

Like most of you ' okay, all of you ' we 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 like how to 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 to eliminate reliance on the notoriously fragile and unreliable PST, how to improve searching (Outlook, after all, does not permit searching attachments, and is painfully slow to search message content), how to eliminate redundant message storage, and how to effect some manner of collaboration, contributed to 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. 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 (eg, 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 (except possibly the biggest rainmakers) 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, of course), 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 because we just don't have the manpower for constant troubleshooting and user hand holding.

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's Enterprise Vault.

The Enterprise Vault (the Vault) addressed all the concerns listed in the first paragraph 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 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 (presumably to be re-categorized for destruction following the decedent's death), while messages categorized as “admin” could be retained for only 3 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.

Now, regarding collaboration. The out-of-the-box solution provided two methodologies; either auto-Vaulting of 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 9 (count 'em ' 9) 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, 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 (eg, 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?).

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. For our part in IT, we 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 (eg, 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 is 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% 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%, but found that all but 30% 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% of limit, or about 87 Mb, this figure is now set to 30%. 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 (that on the server), 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?

WHEW! 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)!