First Hand Experience with Upgrade (Part 4 of 4)

The final step of the upgrade process was to decommission all the old servers. The first thing I did was power off all the old servers to make sure nothing else in the environment was still referencing them. I had my friend test everything that they would normally do both locally and remotely (VPN, OWA, etc.). We immediately encountered failures with VPN so I took a look at that component and found that the old DC was being referenced. Once I updated that setting, VPN worked just fine. We left all the old servers off for 5 ½ days with no other issues. My friend turned the old DC and old Exchange Server back on around lunch time on Friday in preparation for the decommissioning on Saturday.

The old File & Print and Application servers were easy to decommission as we just had to leave them off and delete their computer accounts. When I tried to decommission the Exchange server, I ran into 2 issues.

1. Two public folder instances were still showing as being in the Public Folder database.
2. The primary database supposedly still had a user mailbox in it.

I verified that the Exchange 2010 server did indeed have replicas of all the Public Folder instances as well as owned the Public Folder hierarchy. As far as Exchange 2010 was concerned, it was in full control of the entire PF structure. I also took a closer look at the Mailbox Database on the 2003 server and saw no mailboxes other than the system ones. After spending about 3 hours examining the Exchange environment, I noticed a test mailbox showing up in the list of mailboxes located on the old server. Further research (I asked my friend), revealed that my friend had created a test mailbox in the hopes of doing some testing when we encountered the problem moving three of the mailboxes. The wonderful thing about Exchange 2003 is that the mailbox is not actually fully created until you log into it with a client (not OWA). My friend forgot about it so we deleted the mailbox and the user and that took care of problem number two.

I tried everything I could think of to delete the ghost instances of the Public Folders on the 2003 server, but had no success. I went down the path of last resort and stopped all the Exchange services, then used ADSIEDIT to delete the Public Folder database out of the Configuration Container. I restarted all the Exchange services and voila, the PF database no longer showed up as being mounted. At this point, I was able to uninstall Exchange 2003 using the proper methods.

We also hit a small roadblock running dcpromo on the old DC to remove the domain controller role. The wizard complained that it could not move the final configuration information to one of the other DCs. I verified once again that all FSMO roles had been moved to the new DCs so I knew it wasn’t that. Once again, a little more digging and questioning of my friend and I found he had uninstalled the DNS role from the old DC to try and help me out. I immediately went to the IP settings on the old DC and changed the DNS entry to point to the new DNS server. For some reason, I had to reboot the server before dcpromo was successful.

At long last, all the old stuff was removed and we were now fully functional on the new infrastructure!!! A process I thought would take no more than a few weekends ended up taking a lot longer than that – OMG!

This was definitely a good experience for me as I don’t get to do this very often and I’m definitely out of shape on this type of work. I’m also glad I don’t have to do this on a regular basis and I now do feel the pain of all those IT Pros who do have to deal with this in an ongoing basis.

Harold Wong

Comments

• Anonymous
  February 18, 2011
  The comment has been removed