Migrate Windows Server 2003 File Servers using Windows Server Migration Tools

Posted on March 4, 2015 by Russell Smith in Windows Server 2003 with 0 Comments

In this Ask the Admin, I’ll show you how to migrate a Windows Server 2003 file server using migration tools in Windows Server 2012 R2.

The File Server Migration Toolkit was superseded in Windows Server 2012 by the Windows Server Migration Tools, so if you’re planning to migrate Windows Server 2003 file servers to Windows Server 2012 or later, all the tools you need are built into the target server.

The Windows Server Migration Tools can be used to migrate small datasets, up to 100 GB in size. If you need to migrate larger amounts of data, Microsoft recommends using the built-in version of the Robocopy command-line tool. The migration tool uses HTTPS to securely transfer files between servers, so isn’t necessarily suitable for very large datasets. This article is primarily intended for those migrating from Windows Server 2003, but the source file server can be running Windows Server 2003 Service Pack 2, or any version through to Windows Server 2012.

Prepare the Target and Source File Servers

Before you can start a migration, you’ll need to install the Windows Server Migration Tools on the target server (contososrv3). In Windows Server 2012 R2, log in as a local administrator, open a PowerShell prompt, and run the command below to install the tools:

Once the migration tools are installed, you’ll need to create a migration package that can be deployed and registered on the source Windows Server 2003 server (contososrv4). Before you can use the migration tools on Windows Server 2003, install .NET Framework 3.5, and then the Windows Management Framework Core 2.0, which includes PowerShell 2.0. For more information on how to do this, see Migrate Active Directory from Windows Server 2003 to 2012 R2: Migrate DHCP, Remove Server 2003, and Raise Functional Levels on the Petri IT Knowledgebase.

If you ran SmigDeploy from a command prompt to register the tools, a PowerShell prompt automatically opens where the migration snap-in is registered. If you want to open a PowerShell prompt at any other time, you need to register the migration snap-in manually. This applies to both source and target servers:

Export Local Users and Groups

The first task is to migrate any local users and groups from the source file server (contososrv4). The –User parameter can also be set to Enabled to export all enabled users or Disabled to export all disabled users.

Export local users and groups (Image Credit: Russell Smith)

Export local users and groups (Image Credit: Russell Smith)

You’ll be prompted to enter a password, which is used to protect the exported data. Now switch back to the target server (contososrv3) and import the local users and groups, replacing contososrv4 in the –Path UNC with the name of your source server. When prompted, enter the password for the migration file:


Migrate Data

Now we’re ready to migrate the data from source to target. Before we can run the Receive-SmigServerData and Send-SmigServerData cmdlets, we need to open a connection to the PowerShell console in Windows Firewall. Run the New-NetFirewallRule commands below on the target server to open inbound TCP and UDP ports temporarily:

If your source server has PowerShell 3.0 or higher installed, you can use the two New-NetFirewallRule commands above to open the necessary ports. Otherwise and in the case of Windows Server 2003, use the two netsh commands below:

Start the migration of data (Image Credit: Russell Smith)

Start the migration of data (Image Credit: Russell Smith)

On the target server in a PowerShell prompt, type Receive-SmigServerData, press ENTER and type a password. This sets up the server to listen for an incoming connection from your source server, and the password will be required when you run Send-SmigServerData on the source server.

On the source server, run the following command in a PowerShell prompt, replacing contososrv3 in the –ComputerName parameter with the name of your target server, and the UNCs in the –SourcePath and –DestinationPath parameters as appropriate:

If you look at the new folders on the target server that have been migrated from the source, you should see that the security and share permissions match exactly with those on the source file server.

The migration results (Image Credit: Russell Smith)

The migration results (Image Credit: Russell Smith)

Microsoft recommends that once the initial migration of data is completed, users should be forcibly disconnected from the source file server and all changes to data on the source is frozen. To stop users from connecting, run the command below on the source file server:

Now run Receive-SmigServerData again on the target server, and the Send-SmigServerData command above on the source server to migrate any changes that might have occurred on the source server.


Once the migration has completed, delete the firewall rules for the PowerShell console by running the commands below. Use the Remove-NetFirewallRule cmdlet for servers with PowerShell 3.0 (or later) installed, and use netsh for Windows Server 2003.


Tagged with , ,