Migrating File Servers from Windows Server 2003 to Windows Server 2012 R2


 

Introduction

If you have SMB File Servers running Windows Server 2003, you are probably already aware that the extended support for that OS will end on July 14, 2015. You can read more about this at: http://blogs.technet.com/b/server-cloud/archive/2014/08/26/best-practices-for-windows-server-2003-end-of-support-migration.aspx.

If you're still using Windows Server 2003, you should be planning your migration to a newer version right now. The easiest path to migrate an old SMB File Server would be to use a virtual machine to replace your old box and move the data to the new VM. While it is fairly straightforward to perform the migration, you do have to be careful about it, since it does mean moving data around and requires at least a little bit of down time.

I’m glad you’re reading this, since it indicates you’re taking the steps to retire your old server before it falls out of support.

 

The Steps

To test this migration scenario, I configured a 32-bit Windows Server 2003 machine (which I called FILES) and a Hyper-V virtual machine running Windows Server 2012 R2. I also configured a domain controller running Windows Server 2012 R2 and joined both machines to a single domain.

In general, here are the steps I used to test and capture the details on how to perform the migration:

  1. Configure accounts/groups in Active Directory *
  2. Configure your WS2003 box *
  3. Prepare for migration (initial data copy prior to final migration)
  4. Export the share information
  5. Changes happen after Step 3 *
  6. Rename Windows Server 2003
  7. Final data migration pass
  8. Create shares at the destination
  9. Rename the WS2012 R2
  10. Verify you are all done

Items marked with * are needed only for simulation purposes and should not be executed in your existing environment already running a Windows Server 2003 File Server.

Find below the details for each of the steps above. Note that I tried to capture the commands I used in my environment, but you will obviously need to adjust the server names and paths as required in your specific configuration.

 

Step 1 – Configure accounts/groups in Active Directory

This step creates the several users and groups for the domain that we’ll use in the script.

This step should be run from an elevated PowerShell prompt on the test domain controller running Windows Server 2012 R2.

Older Windows Server versions for the DC are fine, but I cannot vouch the PowerShell below working on all older versions.

IMPORTANT: These commands should only be used for a test environment simulation. Do not run on your production environment.

$cred = get-credential
1..99 | % { New-ADUser -Name User$_ -AccountPassword $cred.password -CannotChangePassword $true -DisplayName "Test $_" -Enabled $true -SamAccountName User$_ }
1..99 | % { New-ADGroup -DisplayName "Project $_" -Name Project$_ -GroupCategory Security -GroupScope Global }
1..99 | % { $Group = $_; 1..99 | % { Get-ADGroup Project$Group | Add-ADGroupMember -Members User$_ } }

 

Step 2 – Configure your WS2003 box

This step creates several folders and shares, with different permissions at the share and the file system level. This simulates a production environment and helps test that files, folders, shares and permissions are being properly migrated.

This step should be run from a command prompt on the test Windows Server 2003 File Server. In the script, JOSE is the name of the domain.

IMPORTANT: These commands should only be used for a test environment simulation. Do not run on your production environment.

md C:homefolder
for /L %%a in (1,1,99) do md C:homefolderuser%%a
for /L %%a in (1,1,99) do NET SHARE share%%a=C:homefolderuser%%a /GRANT:JOSEAdministrator,FULL /GRANT:JOSEuser%%a,FULL
for /L %%a in (1,1,99) do echo y | cacls C:homefolderuser%%a /E /G JOSEAdministrator:F
for /L %%a in (1,1,99) do echo y | cacls C:homefolderuser%%a /E /G JOSEuser%%a:F

md c:projects
for /L %%a in (1,1,99) do md C:projectsproject%%a
for /L %%a in (1,1,99) do NET SHARE project%%a=C:projectsproject%%a /GRANT:JOSEAdministrator,FULL /GRANT:JOSEProject%%a,FULL
for /L %%a in (1,1,99) do echo y | cacls c:projectsproject%%a /E /G JOSEAdministrator:F
for /L %%a in (1,1,99) do echo y | cacls c:projectsproject%%a /E /G JOSEproject%%a:F

for /L %%a in (1,1,99) do xcopy c:windowsmedia*.mid C:homefolderuser%%a
for /L %%a in (1,1,99) do xcopy c:windowsmedia*.mid c:projectsproject%%a

 

Step 3 – Prepare for migration

This step performs an initial data copy from the Windows Server 2003 File Server to the Windows Server 2012 R2 machine prior to the final migration.

By doing this initial copy with the old file server still accessible to users, you minimize the downtime required for the final copy. If there are issues with open files or other errors during this step, that is OK. You will have a chance to grab those files later.

You should make sure to include all the folders used for all your file shares. In this example I am assuming relevant files are in the folders called c:homefolder and c:projects.

IMPORTANT: You must use the same drive letters and the exact same paths on your new Windows Server 2012 R2 server. If you don't, the share information won't match and your migration will not work.

IMPORTANT: This migration process only works if you only use domain accounts and domain groups for your permissions. If you are using local accounts for the file share or file system permissions, the permissions will not be migrated by ROBOCOPY.

In case you’re not familiar with ROCOBOPY, here are the details about the parameters used:

      /e – Copy subdirectories, including empty ones
     /xj – Exclude junction points
    /r:2 – 2 retries
    /w:5 – 5 second wait between retries
      /v – Verbose output for skipped files
     /it – Include tweaked files (identical size/timestamp, but different attributes)
  /purge – Delete destination files/directories that no longer exist in source
/copyall – Copy data, attributes, timestamps, security (ACLs), owner, auditing info

Run this step at the Windows Server 2012 R2 server from an elevated command prompt.

md C:homefolder
ROBOCOPY /e /xj /r:2 /w:5 /v /it /purge /copyall
\FILESc$homefolder c:homefolder

md c:projects
ROBOCOPY /e /xj /r:2 /w:5 /v /it /purge /copyall
\FILESc$projects c:projects

 

Step 4 – Export the share information

This step exports the share information from the registry of the Windows Server 2003 machine. This will include share names, share path and share security (ACLs). There are more details on this export procedure at http://support.microsoft.com/kb/125996.

This command should be run from a command prompt on the test Windows Server 2003 File Server.

IMPORTANT: This migration process only works if you only use domain accounts and domain groups for your permissions. If you are using local accounts for the file share or file system permissions, the permissions will not be migrated by this registry export.

reg export HKLMSYSTEMCurrentControlSetServicesLanmanServerShares c:export.reg

 

Step 5 – Changes happen after Step 3

This step simulates changes being applied to the files after the initial copy in step 3. Since some time will pass between steps 3 and 6, we expect that users will still be making changes to their files and adding new files. This simulated step makes sure the command are able to property capture those changes.

This step should be run from a command prompt on the test Windows Server 2003 File Server.

IMPORTANT: These commands should only be used for a test environment simulation. Do not run on your production environment.

for /L %%a in (1,1,99) do xcopy c:windowsmediar*.wav c:homefolderuser%%a
for /L %%a in (1,1,99) do xcopy c:windowsmediar*.wav c:projectsproject%%a

 

Step 6 – Rename Windows Server 2003 (***DOWNTIME STARTS HERE***)

This step asks you to rename the Windows Server 2003 computer and reboot it. This will mark the beginning of downtime for your File service.

Since Windows Server 2003 did not ship with a command-line option to perform this operation, use the GUI to manually rename the machine from FILES to XFILES. This assumes that FILES is the name of the existing file server (users access data using \FILES<sharename>) and XFILES is an unused name in your network. At this point, your FILES file server will become unavailable.

If you want to automate this step, download the Support Tools from http://www.microsoft.com/en-us/download/details.aspx?id=15326 and use the command below from the Windows Server 2003 machine:

NETDOM RENAMECOMPUTER /NEWNAME XFILES /REBOOT /FORCE

 

Step 7 – Final data migration pass

This step copies the changes in the shares (changed files, new files) after the initial copy. Since this happens after the system is renamed and rebooted, there should be no more users in the system and there should be no further problems with files being in use during the copy.

We’re using the same parameters as before and ROBOCOPY will basically copy just what changed since the initial copy. If the initial copy was not too far back, you will have fewer changes and this step will be shorter.

IMPORTANT: Since this is the last copy, you should watch for any failures and repeat the copy until there are no issues with any files you care for.

Run this from the Windows Server 2012 R2 server from an elevated command prompt.

ROBOCOPY /e /xj /r:2 /w:5 /v /it /purge /copyall \XFILESc$homefolder c:homefolder
ROBOCOPY /e /xj /r:2 /w:5 /v /it /purge /copyall
\XFILESc$projects c:projects

 

Step 8  – Create shares at the destination

This step imports the share configuration from the Windows Server 2003 system, using the file you created on step 4.

Run this from the Windows Server 2012 R2 server from an elevated command prompt.

reg import \XFILESc$export.reg

 

Step 9 – Rename the WS2012 R2

In this step, the Windows Server 2012 R2 system is renamed to the same name as the old Windows Server 2003 system and the migration is done.

As soon as the system is rebooted, the clients will be able to access the file shares in the new system and the downtime ends.

Run this from the Windows Server 2012 R2 server from an elevated PowerShell prompt.

Rename-Computer -NewName FILES -Restart -Force

 

Step 10  – Verify you are all done! (***DOWNTIME ENDS HERE***)

At this point, you migration is complete and you’re basically using these commands to verify that the shares were properly migrated. The commands also sample the permissions in some of the shares and folders to verify that portion worked as well.

Run this from the Windows Server 2012 R2 server from an elevated PowerShell prompt.

Get-SmbShare
Get-SmbShareAccess Share23
Get-SmbShareAccess Project9
Get-Acl c:homefolderuser23 | Format-List Path, AccessToString
Get-Acl c:projectsproject9 | Format-List Path, AccessToString

 

Conclusion

I highly recommend that you setup a test environment before trying this on your production Windows Server 2003 File Server. You test environment should also mimic your production environment as closely as possible. This way you can learn details about the procedure and customize the scripts to the details of your environment.

Good luck on your migration!

Comments (19)

  1. JoseBarreto says:

    @Дмитрий

    FSMT is a good tool, but it is not supported with Windows Server 2012 or Windows Server 2012 R2.

  2. JoseBarreto says:

    @CyperBit – This could work, but there are concerns with partition alignment and 8.3 naming issues inherit to old LUNs or VHD files. In that case, you can skip the rocobopy steps and just use the registry steps to move the file server configuration forward.

  3. JoseBarreto says:

    @rseiler

    While I have not tested this with SBS2003, this will likely work on all variations of Windows Server 2003, but as usual please test before using.

    Regarding the use of virtual machines with large amounts of data, that is common practice these days. I have seen huge virtual machines using lots of data that perform really well. All the way up to large SQL Server used for data warehousing. You only need
    to size the VM (memory, virtual processors, networking, virtual disks) and the host (memory, physical processors, networking, storage) properly.

  4. JoseBarreto says:

    @Mario

    Yes. These instructions will work fine with either side being physical or virtual. A physical Windows Server 2003 going to a virtual Windows Server 2012 R2 is one the most common cases, alongside both being virtual machines.

  5. rseiler says:

    1) Does this apply to SBS2003R2 as well?
    2) I think I understand the value in using a VM, but are they really designed as the repository of several hundred GBs of data. This would be the result of your Step 3 in our case. Wouldn’t a VM become incredibly unwieldy at that size?

  6. JoseBarreto says:

    @Steve These instructions are only good for standalone file servers. Our cluster migration tools unfortunately do not go that far back, so you would need to go to 2008 R2 first, before you can go from 2008 R2 to Windows Server 2012 R2. For 2003 to 2008
    R2, see
    http://blogs.technet.com/b/kaitling/archive/2011/03/09/clustered-file-share-migration-windows-server-2003-to-windows-server-2008-r2.aspx. For 2008 R2 to 2012 R2, see
    http://technet.microsoft.com/en-us/library/dn530781.aspx

  7. Steve says:

    And if the 2003 Server is a cluster and we want him to migrate to a new cluster?
    Thanks for the Awesome Blog

  8. CypherMike says:

    What if 2003 is already a VM and all the data resides on a secondary data .vhdx. Can’t we just attach it to the new one? Also what in the above process changes if the server is 2008 R2, if anything?

  9. Mario Rodriguez says:

    Would this steps work from a 2003 physical to a w2k12 r2 vm?

  10. Komsak says:

    Thank you for Article 
    it-korat

  11. DDS says:

    What if the server is an VM 2003 server and all the data resides on attached raw luns ??? Can i just attach the raw lun's to the new server ????

    —–

    @DDS

    Detaching and re-attaching LUNs can replace the copy phases on items 3 and 7.
    My only concern is that using old LUNs might carry forward issues with short file names and misaligned partitions, which I mentioned in another comment.

    Jose Barreto

  12. Grant says:

    This continues to be a hot topic as many 2003 servers need to be migrated/decommissioned.

    I’ve successfully used FSMT on migrating Server 2000-2008R2 file servers to 2012 R2, in the past. However, FSMT failed on the last stage for me when I used it yesterday. In this one instance, FSMT migrated all the files and their security settings, but not all the share permissions (possibly due to nested shares or my manual tweaking of the XML file).

    I reviewed this article as a possible alternative method, but the warnings contained give me the impression it’s experimental and not necessarily a reliable method? I wish I could have more confidence in it. For now, I’ll stick with FSMT and try to master it.

  13. Dennis Aston says:

    Are there any considerations going from a 2003 R2 Fileserver to a 2012 R2 with a DFS setup? I have increased my staging quota from the standard 4GB to 50 for this but if I am moving 250GB of data whats the fallout when it breaks that 50 GB? Will it make another pass later and pick it up or should I take some manual steps?

  14. Cloud-Ras says:

    Thanks 🙂
    This guide gave me som inspiration to one of our problems of moving fileserver role from Win2008R2 to 2012R2.

    1. Gautham says:

      Hi,
      Has some body have any guide or document on how to migrate DFS cluster which is on 2008 r2 to standalsone 2012 r2 server? Basicallt our plan is to remove cluster and keep as a standalone.

  15. Colin Anksh says:

    Too much complexity and I’m not getting it. It feels like hacking or something. I started to look for something simple. Then my friend suggested me to use GS Richcopy. This software solved almost all problems of mine.Its simple to use and provides many features. This is the best software I have seen so far. Try it maybe it could help you too!

Skip to main content