Modernizing your Infrastructure with Hybrid Cloud – Server 2003 Migrating File Sharing Services to Server 2012 R2 – Part 29

Welcome to today’s article in the “Migrating your Infrastructure with Hybrid Cloud” series.  Not to sound like a broken record but I’m going to assume that some folks did not want or need to read yesterday’s article so I’m going to cover the basic “WHY” discussion one more time here.  If you read yesterday’s article then you will want to skip down to the Migration Considerations section of the article.

Server 2003 was a great server operating system there is no doubt!  Well, in today’s article we tackle migrating the file services from those older 2003-based servers to Server 2012 R2.  Its funny, we think of 2003 as an old OS, because now-a-days we are starting to think of Server 2012 as an older operating system.  After all Server 2012 R2 came out in 2013, and we will surely see something newer come out in the next year or so if the trend continues.  July 14th, 2015 is the drop dead date for support, and as of today, there are roughly 300 days left of Server 2003 support left.  What does that mean?  To put the end of support into perspective, in 2013, 37 critical updates were released for 2003 Server, however when we pass that drop dead date for support, no further critical updates will be released.  Calling into Microsoft and third party vendors for technical issues will come at a premium.  No support also means your server will be out of compliance.  For those in the medical or financial industry you know this term all too well.   No compliance means that if you were to be audited for government and private compliancy regulations, you would fail if a Server 2003 system exists in your data center.  A further meaning for out-of-support would be that most third party application vendors will end support for those applications currently running on these legacy hosts.  Therefore, your operating costs will go up as you try to figure out what may be wrong with the unsupported systems when issues arise.  So now that we understand what the no-support drop dead date means, lets look at our options.

Migration versus Upgrade

At a high level, my opinion for migration versus upgrade is this:  just migrate.  Please.  If your system is working extremely fast on 32 bit Server 2003 10 years after the OS release, I would be quite surprised.    Your customers or end users deserve better plus chances are that those systems are on legacy hardware and have most likely experienced some type of hardware outage.  Be it a hard drive failure, system board, memory stick, you name it, something has most likely happened during the life of the server.  It’s time to let it go (queue the Frozen music).  It’s time to get some newer hardware or an Azure subscription then grab a Server 2012 R2 machine (physical or virtual) and migrate those critical workloads over. In order to upgrade a server from 2003 to 2012 R2 you will need to evaluate the software and roles in which that server is running.  Fear not, if you are running Server 2003 64 bit, and you are running on hardware with specs at 2012 R2 levels, then feel free to go through the upgrade process to 2008 then 2012.  While this would be supported I highly recommend against it unless you have some physical server restriction (like not having one present!).

Migration Considerations

There are a few things to consider here.  First, if the environment has DFS, then we simply need to add the target 2012 R2 server to the DFS service and allow replication to occur.   Second, if you have a large number of non-DFS based shares that need migration then a robocopy combined with a reg key import might be the best way.  Third, if you have a few shares to migrate then perhaps using the Server Migration Tools will be your best bet.  So let’s start with the DFS migration method:

DFS Migration Method

On the target machine while in Server Manager, make sure that you have established your permanent IP addresses on the proper NICs then let’s run the DFS Namespace Service installation by jumping into the Add Roles and Features wizard.

From the DFS Management interface on the source machine add in the new server as a DFS target by right clicking the Namespace and adding the new 2012.  You might want to consider pre-staging the target as large data filled shares may take a long time to complete the initial replication.  So either pre-stage or wait for replication to finish before allowing users to connect to that server.

Once replication has completed you can now remove the old 2003 server from the Namespace and decommission the server if so desired. For more information on DFS in Server 2012 R2 check out this link: https://technet.microsoft.com/en-us/library/jj863566.aspx

If your only curious as to the updates made to DFS check out this link: https://technet.microsoft.com/en-us/library/dn281957.aspx

Robocopy and Registry Key Export/Import Method

This method at first glance may look like a hack job but it is actually the way we have been migrating shares and data for years, so it is proven to work nearly 100% of the time and is quite efficient.  The design of migration is handled in two operations.  First, we need to perform a copy of the share folders, subfolders, data and permissions to the new target server.

First make sure you stop the lanmanserver on the source server to insure the data doesn’t change during the process.

On the source server at an elevated command prompt type in the following command: net stop lanmanserver –force  <enter>

Now we are ready to issue the copy of the data.  So let’s walk through the Robocopy command line required to move the data, first we will identify the source server shares directory then we will identify the new target’s shares directory, then we will add some switches.  The /E option for grabbing empty directory, and /Z option to allow for restarting the process in case it gets interrupted,  then the /Sec option to grab all of the security attributes, finally we add /xf to insure that we grab the time stamps and other information with an asterisk on the end to make sure we grab all files.

Robocopy  <replace with your source directory d:\shares>  <replace with your target \\targetserver\e$\shares>  /E  /Z  /Sec /xf  *

Remember, drive letters need to match here or you will run into trouble.  Now that the data has moved we need to export the registry share information.  The command line for exporting the registry key is here:

reg export HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares  <replace with target server name \\server\shares\migration\shares.REG> <enter>

This next step is critical. We need to remove some of the shares listed inside the export file like the entries for Public, print$, Default, and any other shares no longer needed at the target machine. Once the registry key is exported and cleaned up, we should then import the registry key to the new target server then restart the file sharing services on the target machine.

From an elevated command prompt issue the following commands:

reg import “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares”  <replace with your migration path \\server\share\migration\shares.REG> <enter>

net  stop  lanmanserver  <enter> net  start  lanmanserver  <enter>

Validate that the shares are setup correctly and responding properly, it’s time to make some DNS changes or if you have any inclination that the hard-coding of UNC paths in older applications, it might be a good idea to rename the target server to match the legacy server’s name once the legacy server has been decommissioned.

Server Migration Tools Installation

Before we step through migrating applications, services, and data from 2003 to 2012 we need to dig into the options that Server 2012 brings to the table.  Server 2012 comes with a feature named Server Migration Tools which automates a good bit of the migration for the standard foundation services like DHCP, and other services.   The Server Migration tools that come with Server 2012 provide support for the following previous OS scenarios, while we are zeroing in on Server 2003 it is important to note that many other scenarios are covered:

So we have a 2012 R2 server accessible on the network, and we are ready to migrate some workloads.  First we need to prepare the source 2003 server with the following items completed prior to beginning the migration.  Since this is a domain controller source machine that might require some downtime to get ready for the migration tools installation so plan accordingly.

1) Minimum 23 Megabytes of disk space available for the Migration Tools package. 

2) Microsoft .Net Framework 2.0 needs to be installed

3) Windows PowerShell 1.0 or later installed.

On the 2012 R2 box, lets install the feature called Server Migration Tools.  This can be done via the Add Roles and Features wizard, or via PowerShell commands.  To save time, open up a PowerShell prompt as Administrator, then enter the following command, noting that the server name listed in this example should be replaced with your target machine’s name:

Install-WindowsFeature   Migration   –ComputerName   server2012r2  <enter>

You should see that this installs successfully.

Now lets open up a command prompt as Administrator and enter in the following command, and change the directory to the Migration Tools directory: cd   \Windows\System32\ServerMigrationTools  <enter> In the next line, substitute the architecture(Amd64 or X86) and OS type(WS03 or WS08) as applicable as well as the path to a share already made with proper permissions for copying over the migration tools package:

smigdeploy  /package  /architecture  Amd64  /OS  WS03  /Path  \\server\share\migtools

Now on the 2003 source machine let’s copy or cut that package over to the C: drive where it must be run from locally.  The folder you are looking to copy from the share is most likely named  SMT_ws03_amd64 unless you chose a different OS and architecture type.  Open a command prompt and change directory to the SMT_ws03_amd64 directory.

Execute the following command: smigdeploy.exe  <enter>

Now you should see a PowerShell window launch and are ready to get started using the tools to migrate some shares.

 

Migrating File Share with Server Migration Tools

The final choice available to us for migrating share information would be to utilize the Server Migration tools to move one share at a time.  This might be quite helpful in situations where the source server only has a few primary shares or if you are moving share data across an unencrypted network, since the Server Migration tool will encrypt the data during the process.  There are few requirements that are file share migration specific.

• The target 2012R2 machine need to have both UDP and TCP port 7000 open for communication.
• Utilize the same drive letters for the shares during the migration process.
• Be sure to have joined the domain first and have installed the File Sharing role on the target server.
• Of course verify that you have the proper amount of disk space available.

Now again if you read yesterday’s article and already installed the Server Migration tools on both the source and target machine then skip ahead, but just in case, here are the instructions again. First things first, shutdown the lanman or file sharing service on both the source and target server, you do not want end users accessing and changing data on the shares before the migration is complete. C:\migrationtools\SMT_ws03_amd64> Send-SmigServerData  -ComputerName  <Replace with your target server name>  -SourcePath  <drive letter>:\<shares folder>  -DesitnationPath  <target server drive letter>:\<shares folder>  -Recurse  -Include  All  -Force

You will be prompted with a password prompt, enter in a password so that the data is encrypted and press <enter>

On the target 2012 R2 server from an elevated command prompt, traverse to the migration tools directory then issue the following commands: Receive-SmigServerData

You will be prompted for the password entered above, enter the password and press <Enter> net  stop  lanmanserver <enter> net  start  lanmanserver <enter>

That’s it, you have successfully migrated one share using the server migration tools. In Summary, we hope you’ve found this article helpful.  For more articles in our series check out our landing page here:

And if you want more step by step along with additional information please check out the Microsoft Virtual Academy Jumpstart on Migration found here: https://www.microsoftvirtualacademy.com/training-courses/migrate-legacy-windows-server-to-2012-r2-and-microsoft-azure