How to transfer activity to a new domain controller?

DNS is often the culprit. The clients need to point to a DNS server that is still up, preferably as their primary DNS server. Which means, often, old but valid DHCP leases can cause unexpected behavior if you didn't plan DHCP cutover to account for the new DNS server bring present.

We set it up so both servers are listed as DNS servers, if I do "ipconfig /all" on my PC, I get the old server listed first, then the new one, is the order relevant?  Most of our computers have reservations, so for them the lease time doesn't seem to apply, my computer has a reservation, but its still looking to the old server as its logonserver.

SHD.

Bring up your original Domain controller ASAP.

You need to transfer all of your masters of operations roles to the new server first and foremost and upgrade your forest and domain compatibility levels while you're at it, and yes definitely worth reviewing your DHCP/DNS setup (why do you only want one DC by the way) and THEN you need to remove the DC cleanly from your domain and unjoin it before removing it completely.

this is a gig or live support worthy question by the way

Yes, order matters. And DHCP reservations don't change that fact. A DHCP reservation reserves the IP address, but other scope options still apply, including DNS, default gateway (router) options, etc.

Hi Ben

The original DC is up & running, without it no-one would be getting any work done.  We're only a small setup, about 40 computers, so the one 2008 DC has been working fine for us for the last 7 years, its just getting slow, hence the upgrade to a more powerful 2012 server, and why we don't feel we need to keep the 2008 in circulation.  We did try seizing the five roles with ntsdutil, but that didn't appear to help at all, so we reversed the whole process, uninstalled AD & started again from scratch, but nothing has changed.  I've read about compatibility levels, but am unsure what that means, likewise how to unjoin the old DC from the network, is there a set process for this?

I have no idea what gig is, but if you think live support is worth a try, can I transfer the question?

a gig is a live support arrangement for a set fee, to complete a set goal that isn;t solvable within a several minutes period of time and may require the person supporting you to get access to your systems.

Live is a per minute fee for helping, when you have a complex situation and time is not of the essence you probably don;t want to use live support.

 this is several hours of guided work type of situation, which makes more sense as a gig.

That's what I'm trying to understand, how much more work is involved.  It seems like we're so close, we have the new server assigned as a domain controller, its just not being used as The domain controller when the other one shuts down.  If its general consensus that there is still many hours of work to be done, as opposed to we've just missed a couple of steps, then I'll call in the experts, but I'm still unclear how big a job this is.

Is your new DC on the same subnet as the old? Does it show up linked to a site under AD sites and services? Are your IP address ranges linked to the site?

If there weren't troubleshooting to do, 45 minutes, but you're describing a situation where something doesn;t make sense and now we're all guessing as to what it could be, without being able to interact directly.  Basically, giving you Ideas of where to troubleshoot.

  In my experience with AD Qs like this will take a while to resolve through the Q & A method, at least a few days until the right combo of gotchas has been figured out by us playing guess the possible thing that misconfigured, verses a situation where you work with someone directly to  resolve it more quickly with less guesswork

by the by you DEFINITELY need to do a normal transfer of all the roles, you can do that gracefully for all of them except schema through the MMCs, or use NTDS util to transfer the roles, normally you should only "seize" the roles in a situation where the other DC is offline and will not be coming back ever.

Schema master also need to be moved

Have you gone through your sites and services configuration?

Have you gone through your Network settings?

I do get what you mean Ben, there are a lot of places where a crucial setting could be wrong.  Jason's question about AD Sites & Services had me looking, & the old server is listed under the NTDS site settings as the Intersite Topology Generator, but I have no idea how important that is.  Nothing else has changed about the setup, same router, same IP addresses ranges, same domain name, so it seemed like we just had to find the right set of instructions to follow, but no online help is complete, they all seem to go so far, or cover only one aspect of the transfer of DC's.  So that's another question, does anyone know of a good link describing the process, then maybe we can see what we've missed.

From what you've said you already did all the normal steps we're in troubleshooting mode.

  Did you make the new DC a Global catalog Server?

  I am going ot have to go AFK for a while to look after my daughter now good luck to you.

I would check the following, Firewall enabled (y/n), FSMO roles, AD sites and Services, DNS  and Directory Service test.

FSMO roles

Command: netdom query fsmo

http://www.elmajdal.net/win2k8/Transferring_FSMO_Roles_in_Windows_Server_2008.aspx

Directory services Test

repadmin /replsum /errorsonly
repadmin /showrepl
repadmin /replsummary
dcdiag /test:replications
dcdiag /test:netlogons
dcdiag /fix

Other then that Brian is right you should either open a gig or live chat an expert. As it could be  anything configuration wise that is causing your issue.

Thanks Jason, I'll work my way through those queries & tests.  We did originally do the seizing of FSMO roles (though in hindsight we should have transferred them), but were still no further ahead, so reversed the process & now netdown query shows they are all still pointing at the old server.  What's the relevence of the firewall being enabled, it is, but isn't everyones?

I'm referring to windows firewall. Most clients do not enable it as it causes more headaches then its worth. This will really depends on if your using internal / external firewalls to protect your network.

Our windows firewall is definitely on, always has been on both DCs.  Can that impact the operation of the controllers?

No it will not impact the operations as long as its allowing AD specific ports to be accessed.

Thanks Ben, that's a really helpful list to work through.   I can confirm is the both DC are Global Catalogs, but after that item 6 "make sure both DCs are in the same site and that site has your local subnet in it" doesn't seem to match what I'm seeing.  I know the process for transferring the FSMO roles, though we did them all five at once, so that's all do-able in the order you've given.  I can see we haven't done the changes in ADUC, that's still pointing at the old server.  And when I get to ADDT,  the Operations Master option, on both servers is still set to the old server.  Thanks again, that's going to be incredibly helpful.  Frustratingly its going to be 12 days before we can get exclusive use of the servers again to be able to reboot at will, but I think you've got us looking in the right direction.

Resolving the AD sites and services issue is pretty simple.

open Ad sites and services
1. Right click on the subnets folder, click new subnet.  Type ip address (example 172.16.1.0/24) link to site with DC's. Reboot any machines located in the subnet added.

Restarting the DC is a technicality, don't let it hold you up from performing these operations, you can do the restart at the end or in 12 days if needed.  Make the changes sooner thana later.

  However what is causing you to need to wait 12 days..?

 I understand you have an issue with losing access to the internet (see below for my thoughts on the reasons and how to fix) but even if the reboot dropping the internet couldn't you just wait until after most of your users leave the office and spare 10 minutes to reboot the server in the evening?

what else is the DC doing that you couldn't reboot it in say the evening?

The only other Idea I have on why you might hesitate to reboot the DCs I have is that you are using them for more roles than is really recommended; File Server?  RRAS?  -- What other roles are you sticking on your DCs that you haven't mentioned?

The fact that you lose the internet when the new DC is turned off and some of your other comments lead me to believe you are only putting one new DC into place and only have the new DC configured in the DNS settings provided by DHCP or statically assigned to servers and devices..

These steps will resolve the issue with the traffic to the internet stopping when the DC goes down.

1. 1st: On the DCs themselves In the Network connection settings for each:
2. 1.1 Make sure both DCs have statically assigned IP Addresses.
3. 1.2  Statically assign itself as the primary DNS and the other DC as the secondary DNS.
4. 2nd: On the Dcs themselves In the DNS server on each DC
5. 2.1 Set the external DNS providers you use to forward requests to the internet
6. 2.2  (You can use the ones provided by your ISP and/or any/all of these: 4.2.2.1   4.2.2.2   8.8.4.4   8.8.8.8 - just make sure you use at least two)
7. 3rd: For ALL statically assigned servers and devices
8. 3.1 Change the DNS settings 2012 Primary 2008 secondary
9. 3.2 set the connection specific DNS Suffix for each to be your 'domain.extention (IE Contoso.local)
10. 4rth: Change DHCP settings for all your other clients (DHCP has a lot more options worth checking):
11. 4.1 Have DHCP set the 2012 R2 DC as primary and the 2008 R2 DC as secondary DNS Entry.
12. 4.2 Set the connection specific DNS to your 'domain.ext' (IE contoso.local) is setup in the "Connection-specific DNS entry" (here is how for DHCP: https://technet.microsoft.com/en-us/library/dd572752(v=office.13).aspx)
13. 4.3 Set Option 42 to be the IP of the new 2012 DC (this is NTP, and mostly going to be useful to the systems and devices which are not in the domain)

Following the steps above should stop the issue with the traffic to the internet stopping when the DC goes down.

Additionally, once you have moved the PDC Emulator to the new 2012 DC run the following:

 W32tm /config /manualpeerlist:time.windows.com /syncfromflags:manual /reliable:yes /update
 W32tm /resync /rediscover

Select allOpen in new window

Then on the old DC, run the following:

 w32tm /config /syncfromflags:domhier /update
 W32tm /resync /rediscover

Select allOpen in new window

Now then:
As per best practices, you should always have at least two DCs.  This allows you redundancy to be able to reboot one at will without affecting your entire network so long as you have things configured along the basic best practices.

With only one DC, if you bring it down then you lose DNS, logon is impaired, and if it's down permanently you'll end up having to re-create the entire domain from scratch.

  (A DC for your size network does not need to be a powerful machine a spare old desktop with 4 GB (or 2 in a real pinch) can easily serve your needs for a secondary machine and take over for the other machine when rebooting.

Sites and Services

• - make sure both DCs are in the same site (usually people in a small network just use "Default-First-Site")
• - make sure the site contains the subnet that includes your DCs and that includes all of your client systems (desktops/laptops etc) (Jason mentioned details in his comment)
• - make sure that the NTDS under each server shows a replication item pointing to the other server.

Thanks Ben, I've always been wary of making any serious changes to servers during working hours for fear of impact on users, but as you say, reboots can always wait.  The delay is partly due to use, the new DC is a file server, & many of our staff work far more than just regular office hours, which is terribly dedicated of them, but frustrating for me.  And the other reason for the delay is my availability, & that of the consultant who helps me, & who helps a lot of other companies.  That said, we're really looking forward to working our way through your list, & I appreciate the second list of instructions for preventing the loss of internet access while a server is down, that's always been a pain, especially now our email is cloud-based.  I think your comments about having more than one DC are right, we had planned to retired the old server, but if I can find a place to stow it out of the way, then it can stay put as the backup - a potential server crash has always been our weak point.

Well we've finally had a chance to have another crack at it & everything has gone as text book, except for the bit where we want to dcpromo the old server, it keeps saying there isn't another DC to transfer to.  From what we can see the AD Users & Computers keeps resetting to the old server.  If we go & change Active Directory Domain Controllers & chose the new server, it does it & then a few seconds later it changes back to the old one (you can see the server name in the top line on the screen).  So we're figuring something is wrong with AD, but we did everything by the book.  Several places mention running adprep to update the AD environment for migration, but we also find places that say this isn't necessary when moving to Server 2012 R2, so that's the only step we haven't done, all the AD settings were transferred across when we installed AD on the new server.  Why might it keep resetting to the old server?

Check event logs. Use dcdiag to make sure both DCs are healthy. Make sure DNS on both machines are ONLY ppointing to DCs...preferrably the new one.

oh, whoa whoa whoa whoa whoa!  You never ran forestprep and AD prep?

These are NOT optional steps! (And they need to be done PRIOR to joining the DC)

So now we HAVE to remove the new DC (from being a DC not a member server) run those and start again.

1. Make sure ALL of your FSMO roles are moved back to the OLD DC.
2. Remove the new DC (DCpromo back to a member server.
3. Remove any references to the DC that linger in the Sites and services or the _msdtc of the domain.
4. Run Forest prep
5. Run Domain prep
6. DCPromo the New DC back into the domain and set up the roles again.
7. DCPromo the new DC to the domain
8. Setup and configure all roles and make sure the Server has pro0peper DNS records created and is created in Sites and services in the correct site and they have a replication topology between them
9. in CMD run: "repadmin /replsummary" to make sure all is well

Once completed start from the top of my last list of steps and work your way down.

Hmm, I recall 2012 R2 may automatically run these when DCpromoed though... Now that I think on it about to enter the tunnels to GCT so I can;t check, but if so then I guess that's moot, although I still ran ADPrep and Forest prep when I did this myself..

ALSO....this isn;t a SMALL BUSINESS SERVER 2008 Domain is it?

2012 And later prep automatically as needed. And prom otong a member server to a domain controller would not succeed if this had failed the errornwould have been immediate and obvious. So yes, it presumably succeeded, which is why I didn't mention it in my troubleshooting response.

As for SBS,  it wouldn't matter. Promoting a new DC works exa city the same way, as does transferring FSMO roles and denoting the AND server. The only wrinkle SBS adds is that it cannot continue to run as a member server. Bit it demotes just fine.

My apologies for not updating the situation sooner & thank you for the comments, its very confusing as to whether or not AD needs preping.  We ended up solving the problem when we found a post about domain demotion - https://community.spiceworks.com/topic/106110-demoting-a-domain-controller - right down the bottom there's a comment about a registry entry to do with sysvol & netlogon sharing, we tried that & it fixed things.  We have no idea how that setting came to be wrong, but one lesson we've learnt is that doing the whole process in stages is not such a flash idea, it really needs to be done from start to finish in one go.  The job ended up taking a lot longer than expected so we had to rush off in the end, hence I didn't update.

With the intention of keeping the old SBS 2008 server as a backup, we haven't actually removed it or shutdown, but now I'm wondering if that might have been a good idea.  This morning I have quite a mix of users using the old & new servers as logon server, seems to be mostly Win 10 ones that aren't switching over automatically, but a reboot usually fixes it.  I'm wondering if Cliff's comment about not running as a member server applies here, because it is an SBS server.

That's quite Okay.

  You can have both the 2008 R2 SBS and Windows 2012 R2 DCs in the same domain, but a Windows Small business server can;t be a member server if you demote it, then it can only be a stand-alone server in a workgroup separate from your domain.

  Yet more reason to keep the server around as-is.

Logon servers are served out in a round robin type method, your DCs are i the same site, having either as your logon server is normal expected behavior.

That's interesting, I assumed that all computers got updated say every 6 hours, so they'd all have been updated 12 hours after the changeover.  The only problem its causing is that the main printers are now attached to the new server, so the devices still logging on to the old one aren't able to print until I add the printers.  And this is probably my fault for not having set the group policy correctly, there's lots of aspects of running a server that I still struggle with.  Thanks to everyone for all the help & patience in getting me this far.

You should be deleting a user's printers and mapping them again at every login either using GPO or a login script.

Both the DCs can be a print server though if you want.

I like the sound of that, I do get myself into a tiz with printers.  So I thought I'd go & look at the Group Policy settings, & while I can see a Printer Mapping policy that got created a while ago, I can't edit it, says "The system cannot find the path specified."  From what I can see this seems to relate to security settings on SYSVOL shares.  Unfortunately SYSVOL on the old server is now empty, so I can't see what it should be set to, but I'm suspicious as this is where we had our final problems last night, so maybe our registry patch wasn't quite all it should be.  Argh, why do things never go as smoothly as we'd like them to!  At least my users are working & I'm able to fix printer issues as they come up.

This screams AD and NTFRS replication problems, what were the results on the reason /replsummary ??

  Have you guys been looking through your event logs?

  The sysvol should never be empty on a running DC, and everything that was in the sysvol in one should be in the other!

  This may mean the only place these policies live is the local machines that last loaded them.

  check the sysvol and netlogon shares on both DCs, I suggest logging in yo each as your domain admin and browsing the local file system to check their contents.

make sure all users have these shares as accessible they are hoe the computers copy GPOs locally.

check your event logs though you might have a long standing issue of tombstoned files kicking around and causing replication issues...was this domain long standing?  ie has it been upgraded from others in the past or was it built fresh on that 2008 machine?

 There are some scenarios where your domain can basically be a zombie, like if you had an old DC past tombstones life and then removed the good one and added a new one, or if you did a non-authoritative restore of your domain controller.

where are all of your fsmo roles currently being held?

FSMO roles are on the new server.  The replsummary comes back with nothing (though I do remember seeing results in it last night).  The event log is chocker with Group Policy errors dating back to pretty much when we demoted the old server last night.  In the new Windows\Sysvol folder looks like the domain name folder is supposed to be there, but its actually under windows\sysvol\sysvol, I don't know if there's then supposed to be a policies folder as the event log error implies, but there isn't one.  Dcdiag tests of netlogons & replications both come back with permissions errors.

I never had many group policies & I still have the headings showing to remind me what they were, so losing them isn't huge, I just need to be able to recreate them.

Thanks Ben , you've been a mine of information & I appreciate the many efforts you've made.  I wish I knew where we went wrong, but things are as they are & we're trying to fix each problem one at a time, going back is not an option.  We have managed to recreate the default domain policies (phew) & can delete the now broken ones, so its just a matter of recreating them.  I'm not entirely convinced that all is well with AD, but one problem at a time.  

If things becoming really dire, how do we go about open support cases with Microsoft, its not something I've ever done before & thought them all but un-contactable.

okay, that is all good news, and reduces the likelyhood the issue is a corruption of AD entirely, and more likely limited to NTFRS problems.

I suspect these are rooted in whatever security permissions you had to change to get the domain controller to DC promo down.

I take it you have no backups to grab the policies off of the DCs.

 Client systems store their copies of the group policies under: [b]C:\WINDOWS\system32\GroupPolicy[\b]

  You *might* be able to copy them back if you can match the guids.

Still my thought is generally to get on a client machine and run the Resultant Set of Policies (RSOP) MMC by opening the MMC and adding the RSOP feature in, targeting the local system and running it, then using that as a reference to create a new GPO that has appropriate missing settings.

don't delete any of the other GPOs without first seeing what their links were in AD and creating a list (say in excel) of which GPOs applied to which computers so you know where you want to try to run RSOP to try to catch them all.

also now most of the systems could be missing some of all of the original domain's settings, so try a few and see if you can fine anything before you might give up.

scripts are run directly from the \netlogon\ share so you have lost those permanently if you have no backups of them.

You may also want to check AD to see what scripts are mentioned on any users as a login script in case that may help you find old copies on a file server or other location that might be a backup.

instead of RSOP you could also try tuning the gpresult.exe command with verbose output to html and then use the html as your guide in creating the new copies of the GPOS

Contacting MS has always been relatively easy actually, and not terribly expensive for their basic level of support, at around $300, although due to abuse they are less helpful for basic support than they were 15 years ago, I recall when they used to follow the issue down the rabbit hole and get different related groups involved at the drop of a hat to fix a problem like this, but now the reps are obviously being driven to see the areas of support as separated, so GPO and AD, for instance are going to be seen as two very separate areas of support.

https://support.microsoft.com/en-us/help/13948/global-customer-service-phone-numbers

your most recent post seems less likely that AD is corrupted in any way, so that is good, but I think you need more dedicated support and at your availability, to double-check the health of your domain which MS should be able to do with you handily in the course of an hour's call

Hey matavai,

  Thanks for the feedback, I'm glad I've been helpful!

  Please take a little time to Endorse any of the comments which you found to be helpful. :)

Thanks!

Not entirely out of the woods but we would never have gotten this far without these helpful contributors.  My only comment for anyone else doing the process is to do it all in one go, not in stages like we did.  We've probably spent about 10+ hours on this, when it should have only taken 2 or 3, be really sure in advance of everything that needs to be done, & have a backup of your whole C: drive of the server you're moving off.