1stbyte.com

Greg Fischer
6/15/07

I used Exchange 2000 on Windows 2000 for this, 2003 might be a little different. Obviously, you need to make sure you have the backups in the first place, this assumes you have done this, and we will only focus on recovery. Also, this is intended for Small businesses with only 1 Exchange server and some, just a little, tolerance for downtime. You maybe can apply some of this in a large organization, but probably not.

Using NTBackup (online data):

(work in progress)

OLD Server: Felix
NEW Server: Ruphus

1. Setup a new server as Ruphus. This can be in the same domain and exist with the old server, BUT you will not be able to reconnect the user mailboxes on the new server. That’s a different story and I have not tested procedures for it. We are going to assume the old server is Gone, bye-bye, toast! Also, see notes on seting up a test domain controller and network for full recovery. But at this point, you should have a new Windows server up and running, a DC or not.
2. Install Exchange, install SP’s on Ruphus.
3. Open System Manager, delete the Felix from the Exchange site. (will give warnings, but ok)
4. At this point, we do not have all the configuration from the old server, and for the purposes of this guide, we are not going to bother and assume you can setup your SMTP and other items from memory. In a very large Exchange environment, this might not be possible though, but this guide is intended for those of us with only 1 Exchange server on a small network.
5. On Ruphus rename the old mailbox and public store databases, and/or create new databases that have the same “exact” logical names as were on Felix. (in System Manager, browse to Servers, and find your public and mailbox stores. Right click and select Rename.)
6. Run NTBackup, go to Restore, and find your Felix Information Store database, check the mailbox stores listed. (and log files, which will probably be an option)
   1. Click Start Restore.
   2. Select Ruphus as the server
   3. Select a temp directory, in my case I used the large D: drive. (d:\temp)
   4. Check the boxes (I think, Last set, and Mount db’s?)
   5. Start recovery.
7. Reboot, and make sure your stores mount.
8. Now, if you have setup a new server on a test network OR your old server is toast and you are trying to recover a new server, then you will need to reconnect the mailboxes to the user accounts. For this you will use a tool called, “mbconn.exe”. On your exchange cd, under: SUPPORT\UTILS\I386
   Find the mbconn.exe and run it. (a gui)
9. In here, you connect to Ruphus, and select the store you want to reconnect mailboxes. It should display all the orphaned mailboxes. Then you go to Action, Preview All, and select the AD container with your user accounts, and select OK. I should put green checkmarks next to the mailboxes that it matches to. Then you go to Action, and Apply.
   Re-apply this to any leftover mailboxes if they are in different OU’s. For example, you might have users in Accounting, or Marketing OU’s. Each will Preview and Apply separately until you have reconnected all of them.
   NOTE: You probably wont be able to reconnect a few items, like System Attendant mailbox, as they are created new on Ruphus. Also, you will need to do this procedure for each mailbox store separately.
10. Check Recipient Update Services in Exchange and set the properties accordingly, they will be set to the old server and domain controllers. Tell the objects in RUS to rebuild.
11. Dare I say, “login as a user and see if Outlook works” … ?

Using Offline Database:

Coming later…

Notes on setting up a DC

In my case, I wanted to have a test network, and also a way to do fast recovery of the network on a new server that is offsite. Instead of recovering a DC and AD, I just installed a new server on my existing domain. I made sure it had BASIC drives, not DYNAMIC! And then I setup the server as a backup DC. Make sure you select it as a Global Catalog too! Also, make sure DNS is setup and configured on it!

So, at this point, I had a new DC, GC, DNS server, acting as a backup on my domain. I went in the AD sites and services, and performed a manual replication in the NTDS settings for each server. I also made a ghost image of this server, so I can make a step back, and/or do this again for backup procedures. Keep in mind, once you move ahead though, you’ll probably need to do all this again each time you want a current snapshot of AD for recovery. So what I would do is, setup a basic Win2k load NOT joined to the domain with all the service packs and IE updates, and even Office (I find usefull), and all your utilities you need. (don’t forget the Adminpak!) Then, make a ghost of this server, before doing the join and DCpromo.

Now, we’ve got our replicated server. Lets shut it down, and set it up on the new testing network. (MAKE SURE!!! You cannot communicate with the old one, make them physically separate!) And once removed and setup on the new network, you will need to manually delete this newly dcpromo’d server from your existing network. (see below)

AT this point, we need to sieze all the roles, and make this server the master of the domain. So, look it up online, run the ntdsutil command program and seize all the 5 FSMO’s. Then, go into DNS and remove anything regarding the old servers. (don’t’ forget the server properties listing the old ones as Name servers too) And also, in _msdc SRV records, remove the old servers. After all that, you might need to go in to ADSIEdit (in the adminpak) and find the old servers and delete them in the CN=Configuration container. And if necessary, go in the AD Computers and in Domain Controllers, and delete the servers. And one more… Go into AD sites, and delete the NTDS replication entries and servers. Whew! I think that’s it! You should have a single DC on a test network. This all takes only minutes once you do it a couple times, so it’s not that bad. The hardest part is remembering the ntdsutil command, which you need to lookup online. Just verify that the new server actually holds all the FSMO roles.

We should have a new server all ready to go on the testing/recovery network! All user accounts and settings intact! And now we can begin Exchange!

All these years and I’ve never known how to determine what the “master browser” was on my networks. How many times do you see those event log errors about “such and such is not the master browser” or “unable to get a browse list”. Not that I know how to fix all that, but at least I can find out WHAT THE MASTER IS in the first place!

There’s a cool utility called: browstat

Run from command line. There is one stupid thing though, you need to determine your Netbios transport first. To do that, run: net config rdr

C:\>net config rdr

Computer name                        \\MYSERVER

Full Computer name                   myserver.yourdomain.com

User name                            administrator

Workstation active on

        NetbiosSmb (000000000000)

        NetBT_Tcpip_{0FCE584B-9B98-4D26-A241-1A070D06767A} (00188B3A1EE6)

        NetBT_Tcpip_{F55EF45C-33E5-4842-A4AC-8DFF82D07B76} (00188B3A1EE8)

Software version                     Windows 2000

Workstation domain                   YOURDOMAIN

Workstation Domain DNS Name          YOURDOMAIN.com

Logon domain                         YOURDOMAIN

COM Open Timeout (sec)               0

COM Send Count (byte)                16

COM Send Timeout (msec)              250

The command completed successfully.

So you can see… what a mess! You need this:

NetBT_Tcpip_{0FCE584B-9B98-4D26-A241-1A070D06767A}

And to get your master browser run this:

browstat getmaster NetBT_Tcpip_{0FCE584B-9B98-4D26-A241-1A070D06767A} YOURDOMAIN

It should return something like: Master Browser: MYSERVER

You can also run: browstat status YOURDOMAIN
This will list all kinds of useful info, including your transports.  It shows your backup servers, as well as your master browser.