Active_Directory [SOLVED]: Microsoft AD Server Migration – Two Servers Shutting Down One(Avoiding Server Demotion)

Active_Directory [SOLVED]: Microsoft AD Server Migration – Two Servers Shutting Down One(Avoiding Server Demotion)

Home Forums Active Directory Active_Directory [SOLVED]: Microsoft AD Server Migration – Two Servers Shutting Down One(Avoiding Server Demotion)

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #35917

    Anonymous

    QuestionQuestion

    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 🙁

    #35918

    Anonymous

    Accepted AnswerAnswer

    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_MACHINESYSTEMCurrentControlSetServicesNetlogonparameters
      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.

    Source: https://serverfault.com/questions/887596/microsoft-ad-server-migration-two-servers-shutting-down-oneavoiding-server-de
    Author: David Rogers
    Creative Commons License
    This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.