We ran across an interesting complication during an SBS 2003 to SBS 2008 migration. We run extensive checks on our SBS 2003 servers before performing migrations and this has always served us well. You may have even heard me talk on the various tasks we undertake and tests that we run. In this case we had a local client with an SBS 2003 server that we did not install. Further the previous hardware had failed causing the server to shutdown abruptly over and over again and we had imaged this SBS 2003 server onto new hardware about a year prior. Everything seemed fine with it though and the previous year had gone smoothly with this server.

We fully patched it. We defragmented the Exchange database. We ran the BPA. We updated the NIC drivers. We fixed up a journal wrap problem. We ran dcdiag to test DNS-AD integration. We ran gpupdate. We ran repadmin to test AD sync. We ran the BPA again and it told us that the server held none of the FSMO roles. !***!&*($&#*(&$*!!!!! Yikes. We verified all of them in the GUI. We verified all them using command prompt tools and it came back as holding all of the FSMO roles. Still the BPA persisted in claiming that it did not, so we postponed the migration while we gathered our thoughts. After consulting with everyone we could think of that was an expert in AD, it was concluded that if the AD itself knew that the server held the roles and all of the usual tests came back good that the BPA must be on drugs. The migration was scheduled.

We took a backup. We took an image. We mounted the image onto our virtual server. We started and finished the migration. We migrated the mailboxes, moved the data and generally progressed through the to do list smoothly. Then we noticed the event log in the SBS 2003 server. It said that a recent DC Promo was unable to complete and AD replication was halted until it finished. Sure enough when we tried to add a user as a test, the user did not sync between the servers. AD was not replicating. Testing AD pointed to a problem with the objects in the Computer OU and DNS-AD integration tests said that it was unable to find the PDC. It claimed records were missing that were not missing. Rather than turn back to an SBS 2003 server that no one was able to determine why the BPA said didn’t hold the FSMO roles, we decided our options were to press forward to try to fix the AD or create a new domain. Since everything was working, from the user perspective, we decided we had a bit of time to work on fixing AD before our 21 day migration period was up. Work began.

Moving forward with the migration we got to the point were we decided to uninstall Exchange 2003 and attempt a demotion of the SBS 2003 server. The uninstall of Exchange 2003 went along fine. However when we tried to demote the SBS 2003 server it informed us it thought it was the last replication of DNS in active directory. Hard stop.

To troubleshoot Active Directory we checked schema version on both the server and found it was set to 44. Good but we needed them to replicate with each other. So, we deleted the connection objects on both of the servers. Went into DSSITE on both servers and told it to check replication topology.  Waited for some time and we got the connection object back. We forced replication and it was successful! Problem solved.

We thought, problem solved. Shortly thereafter we got a call from the client, Outlook was reporting Disconnected. A look at Exchange 2007 showed that all of the mailboxes were gone! But the good news was that the mailbox store was still the right size so we knew that they were in there. We just needed to connect to them. Exchange Command shell: get-mailboxdatabase |clean-mailboxdatabase  to have all disconnect mailboxes show up in the Console then in the console, go to disconnectted mailbox, right click each mailbox and choose connect.  Do this for each users mailbox and another problem solved.

Are we done yet? No, yet another issue reared it’s ugly head. Users with large mailboxes were getting a message that their mailbox was too big and they were blocked from sending or receiving email. <sigh> Look at the Mailbox size limitation in the SBS Console and it still held our settings to allows for larger mailboxes for the Standard User Role. Reapply the role. No change. Back into the Exchange Management Console we go. Here we set the mailbox size for the users directly.

No further problems have presented themselves so we believe that we have successfully migrated an SBS 2003 with AD problems over to SBS 2008. Overall it was a good learning experience for the technician involved and now we know that the BPA is never on drugs. Apparently it knows things about AD that AD doesn’t even know about itself.

—
So who wrote this blog and what do they do for a living anyway?
We’re Third Tier. We provide advanced Third Tier support for IT Professionals.
Get Support Blog Twitter Facebook LinkedIN