Recently I wrote about Transparent Windows Workstation Domain Migration. Through some unfortunate circumstances (can you say “array controller failure”) I came to realize, that the process to re-join a workstation to a re-built domain is almost identical.
In case of this situation I had fortunately backed up all the data very well, and virtually nothing was lost (except for a ~week’s worth of time in rebuilding the system) as the result a hardware failure. I had also backed up the Windows 2003 Server (Standard edition) system state, but elected not to use it because the hardware had changed sufficiently (I chose not to use the same kind of array controller in the restored system) so that restoring the registry as a part of the system state restore would have likely messed things up. As a result the newly created fifteen or so user accounts were no longer in touch neither with the restored Exchange 2003 mailboxes (even though the user names matched), nor with the workstations that were seemingly on the correct domain because the unique user IDs, or SIDs, had changed.
To re-join the workstations to the re-built domain forest (i.e. one that was not restored from the system state backup), you need to un-join them first, either by joining a workgroup (name doesn’t matter, you can call it just a generic “WORKGROUP”, the point is to leave the domain), or by using a free Unjoin utility. Then restart, and proceed with my Transparent Windows Workstation Domain Migration instructions. The only thing of note is that the user profile name after re-joining the domain is likely going to be of format username.DOMAIN.000, unless the original profile folder name lacked the domain suffix, in which case you’ll find the newly created profile at username.DOMAIN. Either way it may be a good idea to restore the original profile folder name as described in steps 15-16 of the Transparent Windows Workstation Domain Migration instructions.
What about the disconnected Exchange 2003 accounts, you say? Before I started the restore I blocked SMTP port (25) at the firewall to prevent mails from being received during the restore (DynDNS Mailhop Backup MX service is utilized to buffer arrived emails while the server is unavailable), then backed up the mail that had accumulated in last two days (since the server was restored to service) using ExMerge to be appended to the restored mailbox store. Obviously, restore overwrites anything arrived since the restore took place.
I found lots of good information on the web about how to accomplish this (most notably, once again, an article at Petri IT Knowledgebase: How can I recover a deleted mailbox in Exchange 2000/2003) once I had realized that the Administrator has to have Send As / Receive As privileges for the mailbox store(s) being restored (and if you’re not using the system admin account, the appropriate privileges must be delegated to that account), and that the mailbox store(s) must be unmounted before NTBACKUP restore is started (NTBACKUP wants to mount them, so if the restore fails to start for some of the many potential reasons and you retry, you’ll need to unmount the mailbox stores again first), and that “This Database can be overwritten by a restore” must be checked in mailbox store > Properties > Database, and that “Last Restore Set” must be selected in NTBACKUP (or else you’ll get an error “.. it is a database restored from a backup set on which hard recovery was not started or did not complete successfully”, and you have to issue a command line command eseutil /cc [path to directory containing Restore.env that was created during the restore to a log folder you selected] after restore has been completed), assuming, of course, that you’re not restoring incremental sets in which case you want to check the “Last Restore Set” when restoring, well, the last restore set. 🙂 If NTBACKUP restore fails, don’t expect any kind of information, other than “failed” and perhaps some rather cryptic error message under “Report”. Application events (in Event Viewer) generally yield better clues as to what’s not right. Also note that the process is somewhat different for Exchange 2007 as described in this MS TechNet article.
Overall, I must say the mailbox restore process wasn’t really that straightforward and certainly not enjoyable, and I came to wonder on multiple occasions through the process whether this really was the easiest way Microsoft could have implemented it, or whether the process was intentionally designed to be so convoluted that generally only the people with MCSE know it by heart (after having prepped for the exam, that is 😉 ).