Home / server / Questions / 492973
Accepted
morleyc
Asked: 2013-03-28 12:15:46 +0800 CST

Missing SYSVOL and NETLOGON after upgrade from Windows 2003 SBS to 2012 Standard

  • 772

Today we went from Windows 2003 SBS to Windows Server 2012 Standard. I did the following:

  1. Joined 2012 server to the SBS 2003 domain
  2. Installed Active Directory Domain Services (aka dcpromo) on the server
  3. Transferred all roles to new server within fsmo maintenance under ntdsutil
  4. I then removed the old Windows Server 2003 SBS server

Everything seemed to be working OK until I saw errors with group policy not appling due to missing group policy folders - on closer inspection I had no SYSVOL or NETLOGON folders!

I then ran I ran the Authoritative FRS restore procedure using the D4 flag on the new 2012 server (at this point, the 2003 SBS was already removed):

  1. In the Command box, type net stop ntfrs.
  2. Locate the following subkey in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  3. In the right pane, double click BurFlags.
  4. In the Edit DWORD Value dialog box, type D4 and then click OK.
  5. Run net start ntfrs

I checked \fkdxbsvr1\ in Windows Explorer and could now see the SYSVOL share, but still no NETLOGON share.

I saw the following eventlog error regarding a missing file in sysvol share:

Log Name:      System
Source:        NETLOGON
Date:          27/03/2013 18:40:41
Event ID:      5706
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      FKDXBSVR1.mydom.local
Description:
The Netlogon service could not create server share C:\Windows\SYSVOL\sysvol\mydom.local\SCRIPTS.  The following error occurred: 
The system cannot find the file specified.

So I created the folder called scripts under C:\Windows\SYSVOL\sysvol\mydom.local\SCRIPTS and restarted netlogon, and the NETLOGON share then appeared.

My questions are as follows:

  1. Why could netlogon not create the scripts folder during startup? I didn't read any KB about creating a folder manually, but seems to have worked - is this good or a fudge?
  2. Anything else I should check for? I need convincing that the migration is OK without any other hidden errors.
  3. What did I do wrong in the migration for the above strangeness to start happening?

Additional background information if needed

sysvol directory listing before I added scripts folder

dcdiag dump

active-directory

3 Answers

  1. I ran into this issue when upgrading from SBS 2003 to Server 2012 Standard. Both folders sysvol and netlogon were missing. What worked for me was to stop the NTFRS and Netlogon services on both partners, go to the registry as follows:

    On OLD Server

    1. Click Start, and then click Run.
    2. In the Open box, type cmd and then press ENTER.

    3. In the Command box, type net stop ntfrs.

    4. Click Start, and then click Run.

    5. In the Open box, type regedit and then press ENTER.

    6. Locate the following subkey in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

    7. In the right pane, double click BurFlags.

    8. In the Edit DWORD Value dialog box, type D4 and then click OK.

    9. Quit Registry Editor, and then switch to the Command box.

    10. In the Command box, type net start ntfrs.

    11. Quit the Command box.

    On NEW Server

    1. Click Start, and then click Run.
    2. In the Open box, type cmd and then press ENTER.

    3. In the Command box, type net stop ntfrs.

    4. Click Start, and then click Run.

    5. In the Open box, type regedit and then press ENTER.
    6. Locate the following subkey in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
    7. In the right pane, double click BurFlags.
    8. In the Edit DWORD Value dialog box, type D2 and then click OK.

    9. Quit Registry Editor, and then switch to the Command box.

    10. In the Command box, type net start ntfrs.

    11. Quit the Command box.

    Restart the services on both servers.

    The first time I did this it didn't work, because there was a folder in the sysvol\domain called DO_NOT_REMOVE. I copied the policies and scripts from that folder to the root and deleted the folder. Everything worked right after.

    • 2
  2. Best Answer

    i'm with joeqwerty you removed the old DC before Sysvol Replication has finished. i don't think that your users can log on to the domain because you do not have a Sysvol Share and so you do not have the Defualt Domain Policy and the Default Domain Controller Policy ({6AC1786C-016F-11D2-945F-00C04fB984F9} and {31B2F340-016D-11D2-945F-00C04FB984F9}). i think your clients are logged on with local cached credentials. So i think you have two ways to fix your Problem.

    1. Bring back the old DC and replicate the Sysvol to the new DC (do not manually copy it!). You can set the Bur Flags to D2 on the new DC and D4 on the old DC. Before removing the old DC be sure that the Sysvol is fully replicated. To do this you can have a look in the Windows Event Log -> File Replication Service and wait for the Event ID 13516:

      Description: The File Replication Service is no longer preventing the computer DESCARTES from becoming a domain controller. The system volume has been successfully initialized and the Netlogon service has been notified that the system volume is now ready to be shared as SYSVOL.

      Type "net share" to check for the SYSVOL share.

      After receiving this Event you can remove the old DC

    2. Manually create Sysvol on the new DC -> you will lose all your GPOs

    For a detailed How to for both ways have a look at: http://support.microsoft.com/kb/315457

    • 1

  3. On Windows 2012 R2 there was an orphaned object on DC2 inside C:\Windows\SYSVOL\staging\domain..... that wasn't present on DC1 and caused missing \HOST\netlogon and \HOST\sysvol problems on a newly joined clean DC3. So many hours wasted by such a small thing - Microsoft! Why didn't DC1 and DC2 indicate any inconsistencies in SYSVOL in the first place on DC2 and kept succesfully replicating?? I would then start troubleshooting in the right place instead of thinking it was to do with the newly joined DC3. Also, I did point to replicate only from DC1 rather than any other server eg. DC2 with a broken SYSVOL containing the orphaned folder. So, if anyone eperiences the above problems I would start cross-referencing SYSVOL contents and cleaning up any orphaned items that are missing on other DCs.

    • -1