Last week, the Washington Post reported that the White House has lost an entire year's worth of Al Gore's (and his staff's) email. Evidently, daily backups neglected to include the vice president's email for more than a year because of what has been called a technical configuration error (TCE). It's too bad that Microsoft can't use the TCE excuse when providing email files to the Department of Justice (DOJ). I bet Al Gore's email is much juicier than Bill Gates'.
Putting humor aside, the incident brings up the growing dilemma of email retention policies (and the effects of procedural and operational errors on an email system). Many companies probably would like to see email retention policies set to zero based on Microsoft's experience with the DOJ. In some cases, however, organizations have specific government regulations (such as Securities and Exchange Commission—SEC—requirements and sunshine laws) that require them to retain email. In other cases, organizations might simply want to set their own rules about email retention based on business requirements. Regardless of the motivation, there doesn’t seem to be a good solution for this growing problem.
The poor-man's approach lets companies retain email using Exchange’s message-journaling features and tools such as the archive agent. However, this solution is not very elegant for large organizations. Vendors such as K-Vault Systems and others have tried to fill this space but some things are still missing. K-Vault leverages Microsoft SQL Server, Message Queue Server (MSMQ), and search engine technology (based on AltaVista) to provide a solution that allows policy-based archival to SQL Server and rapid recovery mechanisms. Although the product is functional, it requires a lot of extra pieces (such as SQL Server), isn’t very scalable, and might introduce new problems (e.g., what to do with the data once it's in SQL Server). CommVault Systems' Galaxy product can also help with the problem. Although not specifically designed for email retention, Galaxy has capabilities, such as mailbox-level and item-level recovery, that make it useful for this purpose. The truth is, no single solution provides all the functionality you need for an effective email retention strategy but, depending on your organization's requirements, a combination of these products might suit you.
Longer term, email retention is an area that Microsoft must tackle directly in Exchange Server. Exchange Server 2000 might make this easier with its capability for transport and store-based events; however, we still need some core functionality in Exchange Server that addresses this problem, which is only going to get bigger.
Register
I always wonder why Microsoft does not provide a policy service (like the online defrag service) for the public and private store that allows an Exchange service to automatically move a message from the users private mailbox in the private store to a 'mirrored' mailbox in a second private store (without somehow breaking single-instance-storage).. This store could have the ability then to mark messages (similar to tombstone) as 'cold-storage ready', so a tape backup system such as Veritas could come along and migrate the message body and most of the headers to tape.. When a user needs a message that's stored on tape, they double-click the header and get some type of body informing them the message is off-line. The tape backup system needs to be re-written to operate like the web browser -- Make this tape backup system your default backup system.. Then, define a standard language/commands for Exchange to signal to the backup service system (i.e. Veritas remote Exchange agent) that a message recall is required. The backup system would schedule a new restore job with a high priority, alpha-page/e-mail the backup administrator requesting the correct media to be inserted, and voila.. It's restored.. For the enterprise that has a robotic tape system, the message could be restored automatically in a few minutes. For the rest of us, whenever the administrator could get around to locating and inserting the tape. Windows 2000 has a service similar to this for regular files. Mainframes and mini's have (S/390 and AS/400) cold-storage to an art. Microsoft just needs to figure out how to best integrate it into Exchange.
In my opinion, to be the enterprise player, to be in the glass house with SUN and HP, Microsoft MUST fix this problem and others. SQL is a great product. Exchange 5.5 is good but has a lot of changed needed (thank goodness for Exchange 2000). IIS is a great platform. SNA is good. The other Back-office stuff requires a lot of rewriting to become more open (we see this happening with the new ISA server) so 3rd parties can greatly expand upon the core functionality.
I knew a person at Tinker Airforce Base in Oklahoma City (with Exchange 5.0) that had a terrible time dealing with keeping government contract information in Exchange for 5 or 10 years while simultaneously dealing with the information store size limitation. What about banks making 30 year mortgages? I keep hearing "Corporations need a policy to delete all e-mail older than.." In my opinion, the only reason for this policy is so we can turn a blind eye to the fact that we can't properly do the reverse. Microsoft told me to archive to the desktop.. what kind of solution is that? Put sensitive data onto the desktop where you loose all control over it's security, retention, and restorability. I might as well delete it now so there isn't a false expectation that it can be recalled when needed.
Marcus Sutliff October 19, 2000