Home / server / Questions / 887596
Accepted
David Rogers
Asked: 2017-12-12 13:51:49 +0800 CST

Microsoft AD Server Migration - Two Servers Shutting Down One(Avoiding Server Demotion)

  • 772

I have two servers, one old AD server (server A) and a brand new server (server B). I am trying to migrate from old to new so I setup my second server following these instructions and add the second server as a domain controller within the same domain.

So, everything is wonderful in serverland, both servers are on the old domain and are configured as domain controllers. Now I would like to shut off Server A (eventually will be decommissioned, but I would like to keep it as a backup for now). So I disable AD replication on server B and adjust the DNS settings so that server B no longer points at server A:

Server B DNS Configuration

Then I shut off server A. Suddenly(on server B) I cannot access the AD's configuration either through "Active Directory Users and Computers" or "Active Directory Administrative Center". I get various derivations of:

Fun Errors

Naming information cannot be located because: The RPC server is unavailable

Fun Errors

Cannot connect to any domain. Refresh or try again when connection is available.

Fun Errors

The following Domain Controller could not be contacted: 127.0.0.1. The specified domain either does not exist or could not be contacted.

So it seems like its working(I can login with domain credentials, third party applications utilizing AD seem to work), but I can't access anything. Am I missing something here, I don't see why server B doesn't just detect itself as the new AD server. I thought there is no longer a magical "Primary" AD server. Most people on the internet recommend demoting the old AD server, but I'd rather not in this case. Is it possible to complete the AD migration without demoting the old server?

Update 1

After update FSMO roles as @KatherineVillyard suggested I get most of the same errors, but in the "Active Directory Administrative Center" I get one new one that is interesting, when you select "Change domain controller" I get:

enter image description here

Cannot find an available server in the DEV domain that is running the Active Directory Web Service (ADWS).

This is interesting as I checked and I'm sure the service is running on my new box. I wonder if the issue is DNS related. I already tried re-adjusting the network settings and rebooting the server. Often times with these types of issues it seems that I'm just throwing things against the wall and seeing what sticks :(

Update 2

I have tried a great many things, however it seems that I can reproduce the issue by shutting down server A by merely just disabling the NetLogin service on Server A. Once this service on server A stops responding you no longer have access to that domain(similar type errors thrown) through any of the snap-in controls on either server.

I also noticed something funny, when you run the following command on server B:

nltest /DSGetDC:MYDOMAINHERE

You get the following(assuming netlogin is running on both servers):

DC: \\(SERVER A)
Address: \\(SERVER A IP ADDRESS)
Dom Guid: XXXX
Dom Name: (MYDOMAINHERE)
Forest Name: (MYDOMAINHERE)
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name...

Another thing I notice on the new server(B) is that if you run("dcdiag /test:advertising") you get the following message(no issues on the old server(A)):

Testing server: Default-First-Site-Name\(Server B)
Starting test: Advertising
Warning: DsGetDcName returned information for \\(Server A).(MYDOMAINHERE), when we were trying to reach (Server B).
SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
......................... (Server B) failed test Advertising

This really strikes me as an issue with some sort of DNS configuration on the new server(B), but I've removed every single reference to server A in server B's DNS Manager and rebooted the server. This whole thing is a bit of a black box, where does "DSGetDC" pull this information? The "(DNS) server", which should be server B, which shouldn't have any reference to server A, clearly I'm missing something here :(

domain-name-system

2 Answers

  1. There's not a "magical Primary AD server" but there are FSMO roles. I'm fairly certain, based on the information that you've provided, that Server A holds one or all of the FSMO roles.

    You probably want to bring Server A back up, gracefully transfer all of the FSMO roles to Server B, and take it back down. This article tells you how to do that with PowerShell. In case of link rot, here's the main gist:

    Find the current masters:

    Get-ADForest example.com| ft DomainNamingMaster, SchemaMaster
Get-ADDomain example.com | ft InfrastructureMaster, PDCEmulator, RIDMaster

    Load the Active Directory powershell module:

    Import-Module ActiveDirectory

    You can move the roles based on name or role number. 

    Move-ADDirectoryServerOperationMasterRole "Server B" –OperationMasterRole 0,1,2,3,4

    or

    Move-ADDirectoryServerOperationMasterRole "Server B" –OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

    If this fails, add -force to the end, as in 

    Move-ADDirectoryServerOperationMasterRole “dc2” –OperationMasterRole 0,1,2,3,4 -force

    You can also use the GUI if you prefer.

    • 6
  2. Best Answer

    I gave up :(

    I gave it to a coworker to figure out, what we eventually discovered is that the issue was related to the "DFSR SYSVOL replication". We demoted and re-promoted the new server(B) to attempt to clear out any invalid configuration. Then we followed the resolution to the issue is detailed in the following post. Turns out, after running the steps in Scenario 1 and 2 that the registry key "SysvolReady" was set to zero on the new server(B).

    (In case of link rot)

    To resolve the issue, perform all steps below in the order described, using an elevated CMD prompt while running as a Domain Admin:

    Scenario 1:

    1. Determine which security group policy is applying this setting to the DCs by running on the PDCE:

      GPRESULT.EXE /H secpol.htm

    2. Open secpol.htm in a web browser then click "Show All". Search for the entry "Manage Auditing and Security Log." It will list the group policy that is applying this setting.

    3. Using GPMC.MSC, edit that group policy to include the group "Administrators".

    4. Allow AD and SYSVOL replication to converge on all DCs. On the PDCE, run:

      GPUPDATE /FORCE

    5. Log off the PDCE and log back on, in order to update your security token with the user right assignment.

    6. Run:

      DFSRMIG.EXE /CREATEGLOBALOBJECTS

    7. Allow AD and SYSVOL replication to converge on all DCs. On the PDCE, run:

      DFSRDIAG.EXE POLLAD

      DFSRMIG.EXE /GETMIGRATIONSTATE

    8. Validate that some or all of the DCs have reached the 'Prepared' state and are ready to redirect. At this point you can proceed with your migration normally. See the More Information section below migration best practices.

    Scenario 2:

    1. Determine which security group policy is applying this setting to the DCs by running on the PDCE:

      GPRESULT.EXE /H secpol.htm

    2. Open secpol.htm in a web browser then click "Show All". Search for the entry "Manage Auditing and Security Log." It will list the group policy that is applying this setting.

    3. Using GPMC.MSC, edit that group policy to include the group "Administrators".

    4. Allow AD and SYSVOL replication to converge on all DCs. On the affected DC, run:

      GPUPDATE /FORCE

    5. Restart the DFSR service on that DC.

    6. Validate that the DC now shares SYSVOL and NETLOGON, and replicates SYSVOL inbound.

    "warrenw note 5/3/2013"

    1. Manually share the sysvol - Edit this registry value - Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\parameters
      Value SysvolReady = 1

      run net share to make sure the sysvol is shared out.

    2. Open the policy and add the user or group to the ""manage auditing and security log" user right.

    3. Run gpupdate force.

    We think the failure to replicate and netlogin state registry key was the crux of the issue, but there was a great number of other more minor things that we attempted, these could also be a factor in the resolution. Hopefully, however, this post will be of assistance to someone in the future.

    • 1