Move a file share to a new server using Robocopy

Robocopy is a command line tool that has been around for years, but is still really useful today. It is part of the Windows Server Resource Kit Tools. You will need to install these in order to use the robocopy command. Essentially it is a tool for copying files from one location to another, but with some significant extra advantages over the standard xcopy command. The main advantages that I can see are these:

  • The ability to copy NTFS permissions, if you want to
  • The ability to skip files that have been copied previously, provided that they have not changed

For the reasons above it is still ideal for using when you want to quickly migrate the contents of a file share to a new server. To do this first set up the new file share on the new destination server, making sure the share and NTFS permissions match those that are configured on the old share on the old server.

Next enter the following command in a new batch file, where OLDSERVER is the old file server name, and OLDSHARE is the old share name, and NEWSERVER is the new server name and NEWSHARE is the new share name:


The command basically tells robocopy to copy the contents from the UNC path of the old share, to the UNC path of the new share. The /S and /E tell robocopy to copy any subdirectories, and empty directories. In this example the /COPY:DATS tells robocopy to copy the Data, Attributes, Timestamps and Security information. There are a couple of other elements that you can also copy if you want. To copy everything use /COPY:DATSOU or alternatively /COPYALL. Here is a list of all the flags you can use with the /COPY: part of the command:

D – Data

A – Attributes

T – Timestamps

S – Security i.e. NTFS permissions

O – Owner information

U – Auditing information

The beauty of this solution is that you can run this script during the day, when users are on the system to do the initial copy which depending on how much data is in the share could take a while (that said, this is obviously not a good idea if you are copying the contents to a remote server over a slow WAN link). Then out of hours you can run the script again, but this time it will only copy any files which have changed since the last copy making the copy process a lot quicker. Then all you need to do is change the path for any drive mappings you have in your login script, or group policy preferences, to point to the new file share on the new server. When your users come in the following day, they will will be blissfully unaware that the data has been relocated.

Robocopy has other uses too, and various other options check the help information for more details using:

robocopy /?  


Event 12 Time-Service and the PDC Emulator Role

After moving the PDC emulator FSMO (Felixible Single Operation Master) Role to a new Domain Controller, you will see the following event in your System event log:

Event ID: 12 Source: Time-Service

Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the AD PDC emulator for the domain at the root of the forest, so there is no machine above it in the domain hierarchy to use as a time source. It is recommended that you either configure a reliable time service in the root domain, or manually configure the AD PDC to synchronize with an external time source. Otherwise, this machine will function as the authoritative time source in the domain hierarchy. If an external time source is not configured or used for this computer, you may choose to disable the NtpClient

Event ID: 12 Source: Time-Service

This is due to the fact that the new server hosting the PDC Emulator role is still set to sync time from another Domain Controller within your domain (i.e. through Domain Hierachy). The PDC emulator should be set to sync time with a highly reliable external time source, as it acts as the authoritative time source for your domain. This helps to ensure that time synchronisation between the servers and computers in your network is always accurate.

In order to resolve this event there are two steps. The first is to set the new PDC emulator to sync time with an external time source. The are many time (NTP) servers  available on the Internet. The NTP Pool Project is an excellent service which provides as accurate time service for all geographical areas.

You can use the w32tm command to set your new PDC emulator to sync with an external ntp server. On your new PDC Emulator run the following command:

w32tm /config /manualpeerlist:”,0x1,0x1″ /syncfromflags:manual /reliable:yes /update

Notice that in the /manualpeerlist part of the command the and servers have been specified. Please choose whichever external time source you prefer to use.

Restart the time service on the new PDC Emulator by running the following commands:

net stop w32time

net start w32time

The second step is to set the old PDC emulator back to syncing time through the domain hierachy. To do this you need to use the w32tm command again, but with different parameters. Run the following command on the server that used to act as your PDC Emulator:

w32tm /config /syncfromflags:domhier /reliable:no /update

Finally, restart the time service on the old PDC Emulator by running the following commands:

net stop w32time

net start w32time

You may find that some of your existing domain controllers show Event 129 Source: Time-Service in the logs after making this change. The specific error is:

NtpClient was unable to set a domain peer to use as a time source because of discovery error. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The entry is not found. (0x800706E1)

This is due to the fact the domain controllers are still trying to use the old PDC Emulator as their time source. You can quickly rectify this by running the command:

w32tm /resync /rediscover

If you want to verify the time source that a domain controller is using run the command:

w32tm /query /source