Making an existing Exchange 2003 environment "read only" for users

Question

As a result of political details I won't get in to, and related to a current e-mail migration project from four different legacy mail systems to a new hosted environment, where no user data is being migrated and users are being actively prevented from sending mail into the new environment from the old environment, the following request has come up.

Once the new system is production, we would like to facilitate user access to the legacy environments. This will allow continuity of information contained in e-mail (e. g. day one on new system, users can send a new message as a reply to a message visible in the old system). We would like to do this in a read-only fashion, to ensure that no changes are occurring as a result of user actions in the legacy environment. (This "lock" of the old environment is related to e-discovery concerns from the legal department.)

For the purposes of this question, the legacy environment of interest is an Exchange 2003 environment, with Outlook and OWA access available. Users have Outlook 2003 profiles today that work against the legacy environment.

We have thought of some hack answers - like scripting out changing permissions on every user mail folder to prevent changes - but don't think there's a "good" answer to this problem. Specifically, we're worried about changing one's own information (e. g. deleting e-mails), and about intraorganization e-mail (e. g. user in Exchange organization e-mails to another user in the organization, despite being told not to do that).

The environment is approximately 15 TB at the moment, so the idea of exporting everything to PSTs and giving users access to those was discussed but discarded as unfeasible.

Is there a "good" way to do this that we haven't thought of? I'm aware that the basic underlying question is akin to asking, "how do we stop this mail system from doing any mail traffic?" I'm not saying this is a reasonable request. I'm just doing due diligence to find out if it's possible in a sane way.

Thanks!

p.s. just to forestall questions on this, we don't expect 100% prevention of user information forwarding as there are too many ways for it to happen - we're just preventing as best as we can and stating as policy that they can't do it other ways. Not my decision - just following orders. The proposed migration plan is not a discussion point at this juncture - it's just finding out if one piece of it is at all reasonably doable.

p.p.s. the legacy systems include Notes as well so I'm going to ask the same question again with Notes as the source. It didn't feel right to make those two into one question.

Edit: Just to be 100%, preventing send/receive is part of this, but so is maintaining the integrity of the existing data, e. g. preventing deletion of an existing item.

Second edit: to the point about "you can't, let them do whatever, just tell them not to" line of thinking, I'm wondering if we could just up the dumpster window to the window where they have access to legacy, then know everything exists SOMEWHERE even if they do it and then delete it. Part of the pushback coming from the legal side is that they don't want to have to search a whole ton of backups. (No, there's no archive in the old system, and yes, the new system has archiving, and yes, that means some of this is a stupid line of thinking, but as I said, I'm forced to ask the questions. I'm just looking to make sure no one on here says "oh, here's an easy way - blah blah blah" and the technical implementation team doesn't get burned. Due diligence and somewhat CYA.)

Edit 3: OK, so I just spoke with my boss and there was an interesting idea brought up. If we do as discussed below in one of the answers and grab a presnapshot, then prevent all mail flow, we don't care about deletes, because the snapshot has everything in it of value. There's no way to "add" something discoverable because of broken mail flow. So maybe that's close enough. If we disable the MTA service, will that stop intradatabase mail flow? Is that a reasonable plan of attack for getting to a "known good" discovery state while still allowing data access?

Answer 1

Rather than lock down your legacy system if the "main" concern (you've listed a few) is e-discovery and avoiding a potential loss of information in the legacy system, take a full backup of your legacy system and keep it offline. If users decide to delete information in the legacy system, you will always be able to restore it from backup (along with slapping their wrist in some way telling them no). If there is a need to review the legacy system with any frequency, you can create a duplicate Exchange environment (along with AD and keeping it off the prod network) that you can review if necessary. You will probably have to do this anyway if anyone asks any questions about missing mail.

Exchange 2003 allows you to set mailbox limits that you can use to prevent send and receive of new mail as well, but this would not prevent deletion of existing mail.

EDIT (since my comment got long-winded): You should prioritize your needs with management/legal guidance. If e-discovery is the primary concern, and an absolute necessity, the only way you are going to be able to guarantee a static system for e-discovery purposes that will hold up in a legal sense is to take a full backup of the legacy system and keep it offline. Adding various "technical" measures to prevent data modification will only add to the complexity of the situation and is very likely not a legally-sound solution. Never, ever bring the backup online. If you need a backup to look at later for anyone messing with their old e-mail, take 2 backups, but always keep 1 of them 100% offline and locked up, only available to a very small number of people with documented access controls until the e-mail backup is needed by a subpoena or some other legal reason. Encrypting the backup is also a good idea.

If e-discovery "would be nice", but having a read-only "active" legacy system is more important, I can only recommend PSTs for everybody and shutting down the legacy system. As much of a PITA as it will be to create them I still think that is easier than trying to lock-down your existing system and keep it running. You can keep duplicate PSTs to compare with if there is a question of somebody deleting something and it won't be possible to use the legacy system to send mail since it is decommed. You could also import it into the new system if you ever decide to. I realize that is 30 TB of data to hold onto, but that is the price you pay for data availability and nonrepudiation...

Answer 2

There is no "sane" way to do what you're looking for. You will need to change permissions on all the mailboxes to prevent users from being able to delete / modify items, etc.

I would think that, from an eDiscovery perspective, you would end up with a cheaper and more trustworthy solution in just backing-up the current system and restoring it "under glass" on some virtual machines. You could keep the VMs offline unless a discovery request came in. If it did, you could spin them up on whatever hardware was necessary to facilitate the discovery at a reasonable speed. I'd break the mailbox databases into several smaller "chunks" (a couple of TB each, say) so that you can bring a portion of the eDiscovery environment online w/o having to bring up all 15TB.

That leaves you with the current legacy Exchange environment that the users can "run wild" in. You don't have to make any changes to it to prevent users from making modifications.

If you don't need any mail flow between any of the mailbox servers in the legacy environment you can just stop the SMTP services on the machines. That'll stop mail flow dead.

Edit:

You mentioned the dumpster in your edit so I'll speak to that (now that I'm in the right mind-set re: your retention and discovery concerns on the legacy data). Users can empty their dumpsters so setting the dumpster interval for a long interval doesn't help. (I've had a number of users at Customer sites figure out how to show the dumpster for arbitrary folders and then delete items from the dumpster-- then later beg for them to be restored from backup. Nice trick, guys...) They can also modify items and re-save them, too, and the dumpster doesn't help with that, either.

You could configure a journal recipient on each mailbox store such that during the "legacy coexistence" period any new messages sent intra-organization would be journaled. That still wouldn't help with users being able to modify items already in their mailboxes.

Edit 2 (responding to @MikeBaz edit 3):

Stopping the MTA service, unfortunately, won't stop email delivery within the Information Store. A better idea would be to prevent all recipients from receiving email from any other valid recipients. You could do this by setting the authOrig attribute of each recipient to the DN of some object (say a "Contact" object with an made-up email address) that will never send them email. This will prevent each recipient from being able to receive email from any other recipient (except this bogus "Contact" object).

Between doing that and preventing any outbound SMTP from flowing in or out of the legacy organization (by stopping the SMTP virtual servers or firewalling them) you'll end up with a completely isolated legacy organization.

Answer 3

It's been a while since I've used exchange 2003, but I remember that you can put vbscripts into exchange. Could you put a script on all the mailboxes which would prevent sending of email?