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.
We had an interesting issue the other day. After an upgrade to Exchange 2007 and Office 2007 users reported that they were unable to create an Out Of Office message. When attempting to do so, Outlook would claim that the Exchange server was unavailable. It was a real mystery since the Exchange server was available; they were sending and receiving email just fine. A further clue presented itself when we found that this issue only effected users on the Terminal Server. Users working from Desktop computers did not experience this problem.
During our investigation of the problem we noticed that on the terminal server Outlook was also unable to resolve the autodiscover record while on the desktops they were. We weren’t sure of the link between these two clues but pushed forward to resolve the autodiscover issue. We verified that all of the autodiscover records were correct.
We resorted to Internet research and found 1 conversation thread where someone noted that autodiscover was unable to resolve when you have a proxy server and the browser is not configured to exempt the internal domain from the proxy. This was indeed the problem. This business did run a proxy server. The browser in the terminal server did not have the exemption for the local domain, while the desktop browsers did because they were being autoconfigured by a local firewall client. Once this entry was made, Out Of Office and Autodiscover worked.
So, the solution to why users are unable to use Out Of Office in Outlook 2007 is that the Internal domain is not listed in Internet Explorer as exempt from proxy.
Thank you Steve Holland for getting the word out on this. Doing a Microsoft migration from SBS 2003 to SBS 2008? Download the latest (as of this blog post) migration help file to your SBS08 box BEFORE you start.
Second in the Mark Stanfill EBS 2008 tweet series (check out his TMG series here), we have Mark's latest on Rules for Successful Replacement Mode. As before, I'll be updating this post with new tweets as Mark sends them out. Be sure to check back for updates.
#EBS08 New Series - Mark's Rules for Successful Replacement Mode - MR4SRM. RM = replacment mode.
#EBS08 MR4SRM Rule #1 - Make a complete server backup first. No exceptions.
#EBS08 MR4SRM You need 2 functional EBS servers for Replacement Mode. If not, restore one server from backup.
#EBS08 MR4SRM Always back up CALs on Mgmt server before RM.
#EBS08 MR4SRM Mgmt server needs CALs reinstalled or restore post RM.
#EBS08 MR4SRM All servers are going to need patching. Expect many reboots, considerable time.
#EBS08 MR4SRM Security & Msg can pull updates from WSUS rather than MU. Deselect optional updates during RM. Critical updates come from MU
#EBS08 MR4SRM All DCs need to be online and contactable before RM.
#EBS08 MR4SRM Make sure IIS is healthy, started, listening on port 808 for /remoting directory on all servers before RM.
#EBS08 MR4SRM Management Server restore - repair all SCE clients underAdministration node.
#EBS08 MR4SRM RM on Messaging obviously does not restore mailboxes & PFs. Make backups first - online, offline, PSTs. Belt and suspenders.
#EBS08 MR4SRM To get Security Server to report back to SCE after RM - "net stop fweng /y", repair SCE client, restart services
#EBS08 MR4SRM Remove UM (if present) from Exchange before RM of Messaging Server to avoid setup failure.