Windows File Server Migration with Robocopy

Windows File Server Migration with Robocopy

Are you facing the challenge of migrating your file server to another server and wondering how to copy your files with all their permissions intact seamlessly? Look no further – the answer lies in the powerful tool called Robocopy. In this guide, “Windows File Server Migration with Robocopy” we will delve into the intricacies of file server migration using Robocopy, exploring step-by-step processes and addressing common concerns.

Understanding Robocopy and Its Role in File Server Migration

What is Robocopy and How Does it Work?

Robocopy, short for Robust File Copy, is a command-line utility built into Windows operating systems. It is designed to efficiently copy and migrate files, directories, and even entire folder structures. The tool is known for its versatility, robustness, and ability to handle complex file copy operations.

Why Use Robocopy To Migrate Data From One Server to Another?

When it comes to migrating files from one server to another, Robocopy stands out as the preferred choice. Its speed, reliability, and the ability to copy files with their NTFS permissions make it an indispensable tool for professionals managing IT environments. Whether you’re dealing with a large file transfer or intricate directory structures, Robocopy ensures a seamless migration process.

Step-by-Step Guide For Successful File Server Migration

Migrating data from one server to another can be a big job, but it doesn’t have to be a headache. In this part, we’ll walk through the important steps to make sure your file server migration goes smoothly.

Step 1: Setting Up the New Server with a Smart Prefix

To initiate a smooth file server migration, the first step is to create a new server that will seamlessly replace the existing one. You have the flexibility to choose any name for the new server, and here’s a handy tip: consider adding a prefix like “a” or “new” to the existing server name. For instance, if your current file server is LDNFileSrv01, you might name the new one LDNFileSrv01a or LDNFileSrv01new.

However, it’s important to note that the specific name you choose for the new server isn’t crucial at this stage. During the cutoff phase, the server will be renamed to match the original file server name, ensuring a smooth transition without any impact on your file server identity. This simple trick simplifies the entire migration process, making it more straightforward and hassle-free.

Step 2: Listing All Folders and Their Shares

Now that your new server is ready, the next step is to take note of all the folders and their respective shares that you plan to migrate. You can easily find this information in the Server Manager Dashboard. Navigate to “Server Manager,” then go to “File and Storage Services” and click on “Shares.”

Alternatively, you can access this data through the Computer Management MMC Console by going to “Shared Folders” and selecting “Shares.” This step ensures that you have a clear overview of what needs to be migrated, making the transition smoother and more organized.

Step 3: Initiating the Initial Data Copy using Windows RoboCopy

Now, let’s get the initial copy rolling with the added benefit of preserving NTFS permissions and ensuring ongoing synchronization. Execute the following command on the new server:

robocopy \\LDNFileSrv01\d$\Userdata D:\Userdata /E /ZB /COPYALL /MIR /DCOPY:DAT /R:2 /W:2 /NP /ETA /log+:d:\logs\UserDataInitialSync.log

This command not only copies the data from the existing server (\LDNFileSrv01\d$\Userdata) to the new server (D:\Userdata) but also ensures the transfer of NTFS permissions.

The /MIR switch ensures synchronization by mirroring the source. For instance, if a file is deleted on the existing server, the next run of this command removes it from the new server, maintaining a synchronized file structure. Keep an eye on the log file at d:\logs\UserDataInitialSync.log to monitor the progress and address any potential issues in this crucial migration phase. Explore Robocopy switches and examples for more insights.

Step 4: Establishing Scheduled Sync for Ongoing Data Harmony

To maintain a synchronized and up-to-date file server, the next crucial step is to set up a scheduled task on the new server. This task will execute the Robocopy job at regular intervals—be it nightly or weekly, depending on your specific needs. Here’s how you can do it:

  1. Create a Batch File: Save the same Robocopy command from Step 3 into a batch file (a file with a .bat extension). This ensures that your synchronization process is consistent and easy to manage.
  2. Schedule the Task: Use the Windows Task Scheduler to set up a recurring task. Configure it to run the batch file at the desired frequency, aligning with your data update requirements. For instance, you might choose to run the task every night to capture daily changes.
  3. Incremental Sync Until Cutoff: The beauty of this approach is that the scheduled task performs incremental synchronization. It continuously updates the new server with changes from the existing server, reducing the workload and ensuring that the final sync on the cutoff day is swift and efficient.

By implementing this scheduled task strategy, you not only keep your data in sync but also optimize the time required for the ultimate cutoff synchronization. It’s a proactive measure that contributes to a seamless and controlled file server migration process.

Step 5: Seamless Transition of Share Permissions

In this pivotal step, our focus is on the seamless transition of share permissions from the existing server to the new one. Follow these simple actions to guarantee a smooth transfer:

1. Export Share Permissions Registry Key:

Execute the command below on an administrative command prompt to export share permissions from the old server: 

reg export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares\ shareperms.reg /y

2. Copy and Apply on the New Server:

Transfer the exported registry key file to the new server and double-click on it to apply the copied share permission values.

3. Reboot the Server:

Perform a server reboot to ensure that the applied share permissions take effect.

4. Verify Permissions After Reboot:

After the reboot, check the shared folders to confirm that all permissions have been successfully applied.

Depending on your server environment, especially if there have been multiple changes to share permissions, it’s advisable to perform this task on the day of the cutover. This ensures that the most up-to-date share permissions are captured and applied to the new server, maintaining a consistent access control structure

Step 6: Smooth Cutover and Server Transition

As you approach the final stages of your file server migration, follow these steps to ensure a seamless cutover from the old server to the new one:

  1. Restrict User Access: Temporarily restrict user access to the server to prevent any further changes during the cutover process.
  2. Last Incremental Sync: Perform the last incremental synchronization to ensure that all data is up-to-date on the new server.
  3. Rename the Existing Server: Add a prefix, such as “OLD,” to the existing server’s name. For example: Rename-Computer -NewName "LDNFileSrv01OLD" -Restart
  4. Rename the New Server: Remove the previously added prefix from the new server’s name to maintain consistency: Rename-Computer -NewName "LDNFileSrv01" -Restart
  5. Power Off the Old Server: Power off the old server to complete the cutover.
  6. Verification Check: After the cutover, thoroughly check and ensure that everything is functioning correctly on the new server. Confirm user access, shared folders, and overall server performance.

By meticulously following these steps, you conclude the migration process, ensuring minimal downtime and a smooth transition from the old file server to the new one

Conclusion: Mastering Windows Server File Migration

Congratulations on successfully moving your files to the new server! Your smart strategy and use of tools like Robocopy made the transition seamless. By carefully planning the server setup and renaming, you’ve shown great understanding. Now, with the new server up and running smoothly, you’ve done a fantastic job ensuring a reliable and updated environment.

Share your love
Asif Syed
Asif Syed

I am a System Engineer with 15+ years of hands-on experience in Microsoft technology. My expertise lies in creating and optimizing Microsoft-based systems, delivering efficient solutions aligned with business goals.

2 Comments

  1. Hi!
    Nice article!
    Here the situation is not very easy…our shares are on different disks (9 hard drivers) and the destination server has only one hard disk…Permissions/registry key will be a nightmare…
    Any suggestion?

  2. Hi Michele!

    Certainly! NTFS permissions are seamlessly handled by Robocopy scripts, regardless of disk location.

    When dealing with share permissions, the crux lies in editing the exported registry key, which comprises two significant components: the share location and the share permissions. By adjusting the first piece, which denotes the share location, to map it to the new destination, you can seamlessly apply share permissions

    1. Adjusting Share Locations: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares” in the registry. Here, you’ll find entries corresponding to the locations of your shares. By modifying the hex(7) values associated with each share, you can effectively map them to their new locations on the destination server.

    2. Preserving Share Permissions: The “Security” subkey under “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares” contains the security permissions for each share. Do not make any changes to these values.

    By carefully adjusting these registry keys, you can ensure that share mappings and permissions are accurately transferred to the destination server. Do perform a test in dev/test environment before making any changes in production.

    I hope this simplifies your migration process!

Leave a Reply

Your email address will not be published. Required fields are marked *