We help IT Professionals succeed at work.

Move From SBS2003 to Server 2008 R2. FSMO and DNS Issues

TechSteward asked
Long question...
I was moving a SBS 2003 Domain to a Server 2008 R2 Domain. I wanted to reuse the physical SBS server by erasing it and making it the new PDC. I setup a new server in a hyper v machine, then made it a DC and transfered the FSMO roles to it. I then waited about 24 hours for all things to migrate. Then, i forgot to check that before i erased and setup the new server on the old box. After a few hours i was having some funky dns issues and found a warning in the DNS Log Event ID: 4013 Source: DNS which says: " The DNS Server is waiting for the Active Directory Domain Services (AD DS) to signal that the initial syncronization of the driectory has been completed. The DNS server service cannot start until the initial syncronization is complete... .... ... This event will be logged every two minutes until the AD DS has signaled that the intial sycronization has successfully completed".
At this point i tried to do a number of things manually to fix the funky DNS issues i was having, all to no avail. I couldnt even get that DC to connect to the internet or to the DC in our second office which is connected via VPN. The DC in the second office now thinks its master is the new 2008 Server.
So i restored my backup of the SBS 2003 server and which made everything work for file access and printing and the like for Monday morning when staff arrived. However this morning the sbs2003 server started getting this error: Event ID: 1012 Source: SBCore which states: "Multiple domain controllers running Windows Server 2003 for Small Business Server have been detected in your domain. This computer will shut down in 30 minutes unless you remove all but one of these from the domain." This is because the two domain controllers think they are the master now. And i cannot reassign the FSMO roles to the old server. I did use the ntdsutil to run the seige commands from the sbs server but this doesnt appear to help. That server say's it seiged them but both servers still think they are the master and the DC in our second office still sees the new server as its operations master. All local clients are authenticating against the new DC instead of the SBS server. I have tried to demote the new server but get the message that "You did not indicate that this Active Directory domain controller is the last domain controller for the domain "mydomain.local". However, no other Active Directory domain controllers for that domain can be contacted. Do you want to proceed anyway?" I am hestiant to say yes to that as I fear this will make nobody be able to authenticate to the domain and access resources.
I am wondering if the following is a good option or if someone can point me in a direction.
Is it possible to transfer the zones for DNS from the SBS 2003 to the Server 2008 machine? and if so how? I am fairly sure this is the only thing I'm missing to make things work right. Then I could erase the old machine again and install Server 2008 R2, add it to the domain and make it the PDC again.
Thoughts? Questions? Sarcasm? Tongue Lashing?
All are welcome.
Thanks In advance.
Watch Question

Distinguished Expert 2018

As long as you restored the SBS 2003 server, you *should* be fine. Here is what I'd do:

I am also concerned about this: "I did use the ntdsutil to run the seige commands from the sbs server but this doesnt appear to help." You don't want to seize the roles FROM the SBS server. You want the SBS server to seize the roles *from* the second server. So here is what I'd do.

1) Run ntdsutil on the SBS server and seize all roles.
2) Shut down the second server for 24 hours and monitor client reports to ensure logins are still being processed.
3) Assuming logins work (and they should) power up the second server. Force a demotion.
4) Use ntdsutil to clean up any metadata referencing the second server from all domain controllers still in place (including the VPN branch office).

You should now be in a consistent state and can re-attempt your migration process.

If you work on this stuff long enoughg you're going to find yourself holding the smoking, crumbling remains of a precious information artifact in your trembling fingers as you shout Nooooo!!.........

Never happened to me of course. ;-)

I think the reason your domain needs the old DC is the DNS failure on the 2008 R2 machine.
If it does not start then all sorts of Domain systems will fail.

This KB looks relevant.

I'll continue reading...

More to follow...

Point 6 may help..

6.Change the startup value for the DNS server service to manual if booting into a known bad configuration

If booting a domain controller in a configuration known to cause the slow OS startup discussed in this article, set the service startup value for the DNS Server service to manual, reboot, wait for the domain controller to advertise, then restart the DNS Server service.

If the service startup value for DNS Server service is set to manual, Active Directory does not wait for the DNS Server service to start.


@cgaliher :
 I see how i worded that wrong now, When i said i ran it from the sbs i meant i seiged it to the sbs. Now when goto active directory users and computers and right click on active directory users and computers and connect to the sbs server then check the operations master it sees itself as the operations master and holds all the roles. When i connect to the vpn or the hyper-v DC's they both see the hyperv DC as the operations master and holding all the FSMO roles.
 When I try to change the roles via the gui the only option it gives me to change the role holder or op master to is the VPN DC not the sbs server. Its almost like there are two separate domains of the same name on the network but because all the users exist on both the machines behave properly as long as they are both on.

Now I'm thinking that since the sbs server has all the correct data maybe I need to demote the other two, turn off the hyper-v, remove the VPN DC from the domain and rejoin the domain and promote it again. Convoluted but should at least get me back to square one. Yes? I am a little concerned that since the hyper-v is handling logins that removing that will mass the clients all up. when i removed it today temporarily my laptop still authenticated against it via a cahced login. or at least it said the logon server was the hyper v machine via the "set" command. But when accessing a network drive it would not authenticate me based on the fact the server i authenticaed from was no longer online.

@tardisrepairman reading through that stuff now. Thanks.

Distinguished Expert 2018

The steps I outlined give you a process to safely test, demote, and then clean up your environment. The key there being "safely." You can surely demote your other servers, but if you do so now without doing test shutdowns you may make things worse. Slow and steady, follow my four point suggestions, and you'll be back at the beginning, safely, ready to redeploy.



oh... ok... fine... slow and steady it is... I'll do this and hopefully wont have to update this till late tomorrow with a message that it all works.



Well, No luck. the sbs server does see itself as the master and owns all the roles but all the machines are logging into the server on the vpn instead of the sbs server. The sbs server is still shutting down every hour because it thinks there is another DC in the network. The sbs sever and the VPN server are not replicating and the VPN server still sees the hyper v server as the master and holder of all roles.

Distinguished Expert 2018

At this point I'd have to look at it.
Looks like the problem was the restore from backup. My Backup was not active directory aware. I had to force demote the SBS server and then promte it again after cleaning the metadata out of the second DC

Thanks for all your suggestions.


When making my backup before my whole process i used Acronis Enterprise, which i have always used. The problem was i did a disk clone which apparently isnt active directory aware and so when the restore was done the usn for active directory was different than the active directoy in the domain and thus prrevented the SBS machine to be written to or read from.