Share via

File Services Migration: Migrating the File Services Role

  • Article

Applies To: Windows Server 2008 R2

Migrate File Services

Perform the following tasks to migrate the File Services server role.

  • Freeze administration configuration

  • Export settings

  • Migrate local users and groups to the destination server

  • Migrate data

  • Migrate the source server identity

  • Configure DFS Replication on the destination server

  • Import settings to the destination server

Freeze administration configuration

Administrators must stop all configuration changes to the file server components on the source server before starting migration. When the migration begins, you must not make any configuration changes to the source server other than those that are required for the migration (for example, no links can be added to a Distributed File System (DFS) Namespace after migration starts until the migration’s success is verified).

Prepare a Windows PowerShell session for migration cmdlets

Important

Before you can use any of the following Windows PowerShell cmdlets for migration on the source server or destination server, ensure that the Windows Server Migration Tools snap-in has been added to each Windows PowerShell session. You can do this by using either of the following two methods.

  • Open a custom Windows PowerShell session in which the Windows Server Migration Tools snap-in has already been added. To do this, click Start, point to Administrative Tools, point to Windows Server Migration Tools, right-click Windows Server Migration Tools, and then click Run as administrator.

  • Add the Windows Server Migration Tools snap-in to an existing or new Windows PowerShell session that has been opened with elevated user rights by running the following command:

    Add-PSSnapin Microsoft.Windows.ServerManager.Migration

Note

You should add the snap-in only once to each Windows PowerShell session.

Following is a list of Windows Server Migration Tools cmdlets. The Windows Server Migration Tools snap-in must be added to your Windows PowerShell session to run any of these cmdlets.

  • Export-SmigServerSetting

  • Import-SmigServerSetting

  • Get-SmigServerFeature

  • Send-SmigServerData

  • Receive-SmigServerData

Export settings

Export the following settings from the source server to the destination server. Settings include Server Message Block (SMB), Offline Files (also known as called client-side caching or CSC), DFS Namespaces, DFS Replication, File Server Resource Manager (FSRM), and Shadow Copies of Shared Folders.

BranchCache for Network Files server key

The following procedure applies only if the source server is running Windows Server 2008 R2.

Note

This procedure, which is used to migrate the seed value that is used by the BranchCache™ for Network Files component, enables data that was stored in branch office locations by using BranchCache to be used after the file server is migrated from the source server to the destination server.
For information about how to migrate a BranchCache host server, see the BranchCache Migration Guide (https://go.microsoft.com/fwlink/?LinkID=139091).

To migrate BranchCache for network files settings from the source server

  1. In your Windows PowerShell session, collect data from the source server by running the Export-SmigServerSetting cmdlet as an administrator. This step runs the Export-SmigServerSetting cmdlet with all parameters from a single command line. The Export-SmigServerSetting cmdlet parameters can collect all source BranchCache feature data in a single file (Svrmig.mig), or you can run the Export-SmigServerSetting cmdlet multiple times by using one or more parameters to collect and store data in multiple Svrmig.mig files.

    For more information, see the section "Prepare for Migration" in File Services Migration: Preparing to Migrate.

    Review the following dependencies before you run the command.

    • When you run the Export-SmigServerSetting cmdlet, you are prompted to provide a password to encrypt the migration store data. You must provide this same password to import data from the migration store.

    • The path parameter can be to a folder that is empty or one that contains data. The actual data file in the folder (Svrmig.mig) is created by the Export-SmigServerSetting cmdlet. Therefore, the user does not have to specify a file name.

    • If the path is not a shared location that the destination server can read, you must manually copy the migration store to the destination server or a location that the destination server can access.

    • If a migration store location already exists and you want to rerun the Export-SmigServerSetting cmdlet, you must move the Svrmig.mig file from the migration store location and then store it elsewhere, or rename or delete the Svrmig.mig file first.

  2. On the source server, type the following, and then press ENTER, where <storepath> is the path that will contain the Svrmig.mig file after this step is completed. An example of the path is \\fileserver\users\username\branchcachestore.

    Export-SmigServerSetting -featureID BranchCache -Path <storepath\BranchCache> -Verbose

Group or local policy specific to server message block and Offline Files

Most server message block (SMB) and Offline Files settings are migrated as part of shared folder migration. The remaining settings that affect the server are set through group or local policies. This section describes how to inventory SMB and Offline Files settings that are controlled by Group Policy.

Server message block

Determine the policy settings that affect the SMB server. The SMB settings are controlled by Group Policy settings or local policy settings. If Group Policy object (GPO) is applied, these policies override the local settings. First, determine if the settings are controlled by a GPO, and then determine local settings for anything that is not controlled by the GPO.

To determine if a GPO is applied to the source server

  1. Run the following command in a Command Prompt window to open the Resultant Set of Policy snap-in.

    rsop.msc

  2. In the snap-in tree pane, click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, and then click Security Options.

  3. Note in the SMB data collection worksheet in File Services Migration: Appendix B: Migration Data Collection Worksheets any Group Policy setting that affects the following Microsoft® network server settings:

    • Microsoft network server: Amount of idle time required before suspending a session

    • Microsoft network server: Digitally sign communications (always)

    • Microsoft network server: Digitally sign communications (if client agrees)

    • Microsoft network server: Disconnect clients when logon hours expire

    On source servers that are running the Server Core installation option of the Windows Server 2008 R2 operating system, run the gpresult command to review Group Policy settings (for more information about gpresult, type gpresult /? at a command prompt.)

Note

For any setting that is controlled by Group Policy, you must apply the same GPO to the destination server, or you can set the local policy of the destination server for the same behavior.
For any setting that is not controlled by Group Policy, use the following procedure to determine the local policy setting. Note the local policy setting in the SMB data collection worksheet in File Services Migration: Appendix B: Migration Data Collection Worksheets.

To determine local policy settings

  1. Type the following in a Command Prompt window to open the Local Group Policy Editor snap-in.

    gpedit.msc

  2. In the snap-in tree pane, click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, and then click Security Options.

  3. Note the following settings for Microsoft network server:

    • Microsoft network server: Amount of idle time required before suspending a session

    • Microsoft network server: Digitally sign communications (always)

    • Microsoft network server: Digitally sign communications (if client agrees)

    • Microsoft network server: Disconnect clients when logon hours expire

    On source servers that are running the Server Core installation, run the secedit command to export and review local policy settings (for more information about secedit, type secedit /? at a command prompt.)

Offline Files

Note

This section only applies to source servers that are running Windows Server 2008 R2. Previous operating system releases do not have Offline Files settings that affect the server.

Determine the policy settings that affect the Offline Files server. The Offline Files settings are controlled through Group Policy or local policy. If Group Policy is applied, then these policies override local settings. First, determine if the settings are controlled through Group Policy, then determine the local settings for anything that is not controlled by using Group Policy.

To determine if Group Policy is applied to the source server

  1. Run the following command in a Command Prompt window to open the Resultant Set of Policy snap-in.

    rsop.msc

  2. In the snap-in tree pane, click Computer Configuration, click Administrative Templates, click Network, and then click LanMan Server.

Note

If no policies are set, the preceding path won't exist. If the path does not exist, skip to the procedure To determine local policy settings. If the path exists and policies are found, go on to the next step.

  1. Note in the Offline Files data collection worksheet in File Services Migration: Appendix B: Migration Data Collection Worksheets any Group Policy settings that control the Hash Publication for BranchCache setting.

    On source servers that are running the Server Core installation option, run the gpresult command to review Group Policy settings (for more information about gpresult, type gpresult /? at a command prompt).

For any setting controlled by Group Policy, have the same Group Policy apply to the destination server, or you can choose to set the local policy of the destination server to get the same behavior.

For any setting not controlled by Group Policy, use the following instructions to determine the local policy setting.

To determine local policy settings

  1. Run the following command in a Command Prompt window to open the Local Group Policy Editor snap-in.

    gpedit.msc

  2. In the snap-in tree pane, click Computer Configuration, click Administrative Templates, click Network, and then click LanMan Server.

  3. Note in the Offline Files data collection worksheet in File Services Migration: Appendix B: Migration Data Collection Worksheets the value of the Hash Publication for BranchCache setting.

    On source servers that are running the Server Core installation option, run the secedit command to export and review local policy settings (for more information about secedit, type secedit /? at a command prompt).

DFS Namespace configuration

Procedures in this section describe how to migrate DFS Namespaces from the source server to the destination server.

Before the migration of the namespace begins, you can inventory the namespaces that are hosted on the source server for tracking purposes. You can do this by using the DFS Management console or DFSUtil.exe.

The following procedure (To inventory DFS Namespaces by using the DFS Management Console) applies only to computers that are running at least the Windows Server 2003 R2 version of the Windows Server operating system. For computers that are running Windows Server 2003, you can perform a DFS Namespace inventory by using DFSUtil.exe as described in To inventory DFS Namespaces by using DFSutil.exe.

You can also perform a DFS Namespace inventory from a client computer that is running Windows Vista® or Windows® 7 by using the DFS Management Console that is part of Remote Server Administration Tools (formerly known as the Administrative Tools Pack).

To inventory DFS Namespaces by using the DFS Management Console

  1. Under DFS Management in the left pane, right-click Namespaces.

  2. Select Add Namespaces to Display.

  3. In the dialog box that is displayed, select Server from the Scope options.

  4. Type the name of source server and click Show Namespaces.

  5. Select all namespaces listed in the list box and click OK.

  6. Right-click the first namespace listed in the left pane.

  7. Select Properties.

  8. On the General tab, check the Type field. The type of namespace that is hosted on the server is described here. Possible values are stand-alone, domain-based (Windows Server 2000 mode), and domain-based (Windows Server 2008 mode).

  9. In the case of a domain-based namespace, click the Namespace Servers tab to identify the number of servers that host the namespace.

  10. Repeat steps 7 through 10 for the remaining namespaces listed in the left pane.

To inventory DFS Namespaces by using DFSutil.exe

  1. Open a Command Prompt window and type the following command to list the namespaces that are hosted by the source server, in which SourceServer represents the name of the source server.

    DFSUtil.exe server <SourceServer>

  2. Identify the namespaces (DFS roots) listed for the source server.

  3. Type the following command, list the namespace properties for the first namespace identified in step 2:

    DFSUtil.exe root <\\SourceServer\Namespace>

  4. Identify the namespace type; possible values are stand-alone root, domain root (domain-based namespace in Windows 2000 Server mode), domainV2 root (domain-based namespace in Windows 2008 mode).

  5. Identify the DFS folders present in the namespace in each of the Link Name items displayed.

  6. In the case of domain-based namespaces, identify all the namespace servers by typing the following command:

    DFSUtil.exe root <\\Domain\Namespace>

  7. Identify the namespace servers that host the namespace in each of the Target items displayed under Root Name.

  8. Repeat steps 3 through 7 for the remaining namespaces on the source server.

Considerations for namespaces

Is the namespace stand-alone or domain-based? If the namespace is stand-alone, see the following section in this document:

Stand-alone namespaces.

If the namespace is domain-based, consider the number of namespace servers for each namespace. For more information, see the following sections in this document:

Domain-based namespaces with more than one namespace server

Domain-based namespaces with one namespace server

Stand-alone namespaces

Complete the following procedure to export a stand-alone namespace configuration.

To export the namespace configuration to an export file

  1. On the destination server, open a Command Prompt window.

  2. Type the following to export the standalone namespace to a file (where filename represents the exported file), and then press ENTER.

    DFSUtil.exe root export <\\SourceServer\Namespace> <Filename>

Domain-based namespaces with more than one namespace server

For more than one namespace server, remove the namespace server from the namespace by using DFSUtil.exe.

To remove the namespace server from the namespace

  1. On the destination server, open a Command Prompt window.

  2. Type the following command, and then press ENTER.

    DFSUtil.exe target remove <\\SourceServer\Namespace>

Domain-based namespaces with one namespace server

There are two options that you can use in this scenario: Export the namespace settings or add a temporary server to the namespace.

To export namespace settings

  1. On the destination server, open a Command Prompt window.

  2. Type the following (where filename represents the file containing settings for export), and then press ENTER.

    DFSUtil.exe root export <\\Domain\Namespace> <Filename>

Note

For each namespace, there must be a different file name to export settings.

  1. Repeat step 2 for each namespace for which the source server is a namespace server.

You can use either of the following two options if a temporary server can be added to the namespace. This provides the ability to maintain the namespace online while the migration progresses. If this is not possible, follow the steps in To remove the namespace server from the namespace instead.

To add a temporary server to the namespace by using the DFS management console

  1. In the left pane, select the namespace to be migrated.

  2. Click the Namespace servers tab.

  3. Select Add Namespace Server.

  4. In the <fieldname> field, type the name of the temporary server, and then click OK.

The temporary server will be added to the namespace.

To add a temporary server to the namespace by using DFSUtil.exe

  1. Create a shared folder for the namespace on the temporary server with the same permissions as on the source server.

  2. On the destination server, open a Command Prompt window.

  3. Type the following command, and then press ENTER.

    DFSUtil.exe target add <\\TemporaryServer\Namespace>

The temporary server will be added to the namespace.

After the namespace settings are exported or a temporary server is added to the namespace, the namespace source server can be removed from the namespace as described in To remove the namespace server from the namespace.

Inventory advanced registry keys

This section describes the process for determining if there are any settings that have been applied to the DFS Namespace component on the source server. These settings are stored in the registry and set or viewed through the dfsutil.exe tool. To inventory these settings, run the following commands from the destination server:

DFSUtil.exe server registry DfsDnsConfig <SourceServer>

DFSUtil.exe server registry LdapTimeoutValue <SourceServer>

DFSUtil.exe server registry SyncInterval <SourceServer>

Note the setting for any registry modification. Registry keys that have not been modified display a value similar to the following:

<KeyName> does not exist in the Registry.

DFS replication configuration

Perform an inventory of the replicated folders on the source server by using the “DFS Replication Data Collection Worksheet” in File Services Migration: Appendix B: Migration Data Collection Worksheets to obtain information about the following items:

  • Replication groups that the source server is part of.

  • Folders that are replicated on the source server and the local file path to these replicated folders.

  • Connections between the source server and the other replication member servers. It is important to understand the replication topology that has been configured and understand the connections to the server that is being migrated.

  • Quotas configured for the staging folder.

FSRM configuration on the source server

When you migrate FSRM, remember to use the same drive letters for the destination server volumes as for the source server. This is required because FSRM migration requires that the drive letter remains the same.

  1. Stop the FSRM File Services.

    Run the following command in Windows PowerShell as an administrator.

    Stop-Service -name "srmsvc","srmreports"

  2. Export the FSRM configuration.

    To run the export command in Windows PowerShell, type the following, and then press ENTER.

    Export-SmigServerSetting -FeatureID FS-Resource-Manager -Path <storepath\FSRM> -Verbose

  3. For each volume, get the configuration files by running the following commands in the Windows PowerShell session.

    1. Stop the file screen driver. Type the following, and then press ENTER.

      fltmc detach datascrn <VolumeLetter>:

    2. Stop the quota driver. Type the following, and then press ENTER.

      fltmc detach quota <VolumeLetter>:

    3. Add administrator Read permissions to "<VolumeLetter>:\System Volume information\SRM" folder and the following child objects:

      • takeown /F "<VolumeLetter>:\System Volume Information" /A /R /D Y

      • cacls "<VolumeLetter>:\System Volume Information" /T /E /G Administrators:F

      • attrib -S -H "<VolumeLetter>:\System Volume Information\*" /S /D

    4. Copy the following files from the SRM folder to an external storage device:

      • Quota.xml

      • Quota.md

      • Datascrn.md

      • DataScreenDatabase.xml

    5. Start the file screen driver. Type the following, and then press ENTER.

      fltmc attach datascrn <VolumeLetter>:

    6. Start the quota driver. Type the following, and then press ENTER.

      fltmc attach quota <VolumeLetter>:

  4. Restart the FSRM File Services. Type the following, and then press ENTER.

    Start-Service -name "srmsvc","srmreports"

  5. Configure scheduled reports.

    FSRM reports and classification rule configurations are dependent on the drive letters and mount points. Any drives or mount points on the source server that are used by report or classification rule configurations must be available on the destination server or the configurations must be updated during import.

    To configure scheduled reports, follow step (a). However, if you are migrating from Windows Server 2003, follow step (b).

    • To configure scheduled reports on all servers except Windows Server 2003, run the following commands in a Windows PowerShell session on the source server that was opened with elevated user rights.

      • To get a list of all the task names associated with storage reports: storrept r l

      • For each task name listed run the following command on the source server: schtasks /query /tn:"TASKNAME" /xml > "TASKNAME.xml"

    • To configure scheduled reports when you migrate from Windows Server 2003:

      • On the source server, do the following:

        • Open File Server Resource Manager.

        • In storage report management, for each report task, note the report task, target, and schedule.

      • On the destination server, after you import the file server resource manager configuration, do the following:

        • Open File Server Resource Manager.

        • In Storage Report Management, for each report task, edit the report task properties.

        • On the Schedule tab, manually add the appropriate schedule for the report.

  6. Configure scheduled file management tasks. This step applies only to source servers that are running Windows Server 2008 R2.

    1. To display a list of all task names associated with file management tasks, type the following command on the source server in a Windows PowerShell session opened with elevated user rights:

      (new-object -com Fsrm.FsrmFileManagementJobManager).EnumFileManagementJobs()

    2. For each entry listed, locate the task element, and then type the following command:

      Schtasks /query /tn:"TASK" /xml > "TASK.xml"

Shadow Copies of Shared Folders

The following procedures describe how to migrate shadow copy settings.

To migrate shadow copy settings

  1. Open Windows Explorer on the source server to view shadow copy storage locations and the creation schedule.

Important

This procedure applies to shadow copies for a server running the full installation option of Windows Server. If your source server is running the Server Core installation option of Windows Server, skip this procedure and follow the instructions in the following section: To migrate shadow copies in a Server Core installation.

  1. For each volume on the source server, right-click the volume, select Configure Shadow Copies.

    On source servers that are running Windows Server 2003, right-click the volume, click Properties, and then click the Shadow Copies tab.

  2. Click Settings, and note the location and size of the shadow copy storage.

  3. Click Schedule and note the details for the snapshot creation task.

To migrate shadow copies in a Server Core installation

  1. Log on to the computer that is running a Server Core installation remotely as follows:

    1. Click Start, point to Administrative Tools, and then click Computer Management. (You may need to open Control Panel to open Administrative Tools, depending on your Start menu configuration.)

    2. In the Computer Management snap-in pane, right-click the top node, and then click Connect to another computer.

  2. Type the computer name, and then click OK.

  3. Expand System Tools, right-click Shared Folders, click the All Tasks tab, and then click Configure Shadow Copies.

  4. For each volume on the source server, right-click the volume, select Configure Shadow Copies, click Settings, and note the location and size of the shadow copy storage.

  5. Click Schedule, and then note details for the snapshot creation task.

Migrate local users and groups to the destination server

Before migrating data and shared folders, or completing your migration of the FSRM configuration, you must migrate local users and groups. Export local users and groups from the source server, and then import local users and groups to the destination server.

Important

If the source server is a domain member server, but the destination server is a domain controller, imported local users are elevated to domain users, and imported local groups become Domain Local groups on the destination server.
If the source server is a domain controller, but the destination server is not, Domain Local groups are migrated as local groups, and domain users are migrated as local users.

Export local users and groups from the source server

On the source server, export local users and groups to a migration store (as shown in the following example) in a Windows PowerShell session that has been opened with elevated user rights.

Export-SmigServerSetting -User All -Group -Path <storepath\UsersGroups> -Verbose

You can use one of the following values with the -user parameter:

  • Enabled: Specify to export only enabled local users.

  • Disabled: Specify to export only disabled local users.

  • All: Specify to export enabled and disabled local users.

For more information about the attributes of local users and groups that can be migrated, see the Local User and Group Migration Guide (https://go.microsoft.com/fwlink/?LinkID=128751) on the Microsoft Web site.

You are prompted to provide a password to encrypt the migration store. Remember this password, because you must provide the same password to import from the migration store.

If the path is not a shared location that is accessible to the destination server, you must manually copy the contents of the migration store folder to the destination server or a location that is accessible to the destination server.

Import local users and groups to the destination server

On the destination server, import local users and groups from the migration store to which you exported the users and groups in Export local users and groups from the source server, as illustrated by the following example. Use a Windows PowerShell session that has been opened with elevated user rights.

Import-SmigServerSetting -User All -Group -Path <storepath\UsersGroups> -Verbose

You can use one of the following values with the -user parameter:

You are prompted to provide the same password that you provided during export to decrypt the migration store.

Migrate data

Important

Migrating data from source servers that are running Windows Server 2008 and newer releases of Windows Server requires that TCP port numbers 7000 and 7001, and UDP port number 7000, are open. On source servers that are running Windows Server 2003, the Server Migration program must be allowed by the firewall. For more information about how to open these ports, before you continue with data migration, see File Services Migration: Appendix A: Optional Procedures.

To migrate data, you can copy file data or physically move it, for example, by attaching the storage drive from the source server to the destination server. If you copy the data, follow the copy data migration steps in the following section.

If you physically move the data, follow the steps described in the Physical data migration section later in this document.

Data copy migration

If you are planning a two-phase data copy migration as described in the previous section, note that if files have been deleted on the source server between the start of the first copy and the start of the final copy, copies of the deleted files might have already transferred to the destination server. So if a file is deleted between the two copy processes, the file might still be available on the destination server after the migration is complete. If this is unacceptable in your enterprise, perform data and shared folder migration in a single phase, and disconnect all users before starting migration.

To copy data and shared folders and migrate all data without disconnecting users

  1. Verify that the destination path has sufficient disk space to migrate the data. If NTFS or FSRM quota management is enabled on the destination server disk drive, verify that the NTFS or FSRM quota limit allows for sufficient free disk space to migrate data. For more information about FSRM quota management, see one of the following.

    For more information about NTFS quota management, see one of the following.

  2. Ensure that you have completed the migration of local users and groups.

    Send-SmigServerData and Receive-SmigServerData cmdlets must be run on the source and destination server within five minutes of each other. By default, Send-SmigServerData and Receive-SmigServerData time out if a connection cannot be established within 300 seconds (five minutes). This maximum connection time-out for the Send-SmigServerData and Receive-SmigServerData cmdlets is stored in the following registry key, which is user-defined.

    Key: HKEY_LOCAL_MACHINE\Software\Microsoft\ServerMigration

    Value: MaxConnectionTime (REG_DWORD)

    Data: Between 1 and 3600 (represents connection time-out, in seconds)

    If a value larger than 3600 is specified, 3600 seconds (1 hour) is used as the maximum connection time-out.

    For information about how to create a Windows Registry key, see Add a Registry Key (https://go.microsoft.com/fwlink/?LinkId=147298) on the Microsoft Web site.

  3. Use the following command to run the Receive-SmigServerData cmdlet on the destination server. Use a Windows PowerShell session that is running with elevated user rights.

    Receive-SmigServerData

Note

All output for the Send and Receive operations occurs on the source server only. The destination server will appear to be done before the operation has completed.

  1. Use the following command to run the Send-SmigServerData cmdlet on the source server to migrate data and shared folders. Use a Windows PowerShell session that is running with elevated user rights.

    Send-SmigServerData -ComputerName <DestinationServer> -SourcePath d:\users -DestinationPath d:\shares\users -Recurse -Include All -Force

The destination data location does not have to be the same as the source location, and you can change it, if desired.

Note

The LanMan Server service restarts automatically on the destination server for shared folder migration to complete.
Data that is transferred is encrypted automatically. You are prompted to enter a password to encrypt the transferred data on the source server, and the same password to decrypt the received data on the destination server.

After the first data copy is finished, you must freeze the source server and all data changes.

To disconnect users and migrate new or updated files

  1. Make sure that users are notified that they should stop using the source server at this time to prevent any possible data loss. You can run the following command to list all the currently open files to determine the potential impact of performing this step.

    net file

  2. Disconnect all users from the source server by stopping the LanMan server service.

    Stop-Service LanmanServer -force

    Stopping the LanMan Server service invalidates all open remote files to the shared folders on the source server, which can lead to potential data loss. It is best to perform this step when the fewest users are expected to access files on this server.

  3. Use the following command to run the Receive-SmigServerData cmdlet on the destination server. Use a Windows PowerShell session that is running with elevated user rights.

    Receive-SmigServerData

  4. Use the following command to run the Send-SmigServerData cmdlet on the source server to migrate data and shared folders. Use a Windows PowerShell session that is running with elevated user rights.

    Send-SmigServerData -ComputerName <DestinationServer> -SourcePath d:\users -DestinationPath d:\shares\users -Recurse -Include All -Force

  5. If your scenario requires migrating reparse points, hard links, and mount points, recreate them on the destination server by using the mklink command for reparse points and hard links, and using the mountvol command for mounted volumes. For more information about these commands, enter mklink /? or mountvol /? in a Windows Command Prompt.

It is important to maintain the same destination path that you used during the first copy of data and shared folders. The cmdlets transfer files, folders, and shared folders only if they do not exist on the destination server, or if there is a new version on the source serve.

Physical data migration

The next sections describe data migration by physically moving external drives or logical unit numbers (LUNs).

Using disk drives or LUNs to migrate data from the source server to the destination server

You can migrate data from the source server by moving the disk drives. Or, if your data resides on a LUN storage device, you have the option of moving the file server data by masking the LUNs from the source server and unmasking them on the destination server.

For the ideal migration, make sure that you maintain the same mapping of the volume letters (for example, drive D) and the volume IDs (see the following explanation) so that relevant data and application information remains as consistent as possible during the move.

Warning

You should not move a disk drive or LUN if it contains bothdata and the operating system.

Benefits of physical migration:

  • For large amounts of data, this is a faster operation.

  • You maintain all data on the disk drive, such as hard links and mount points

  • Shadow copies are preserved if the shadow copies are on the migrated disk drive.

Potential issues to be aware of:

  • Permissions for local users that are not default computer accounts (such as local administrators) will be lost even if the same user name is used when creating the user account on the destination server.

  • Encrypted files (EFS) cannot be migrated.

  • Encrypted volumes (from BitLocker™) cannot be migrated.

  • Remote Storage cannot be migrated.

  • When you are physically migrating disk drives that have FSRM quotas enabled on them, it is a best practice to dismount the drive gracefully to avoid marking the quotas as dirty. Otherwise, unnecessary scans may occur later.

To migrate data by physically moving the disk drive or by masking and unmasking the LUNs

  1. Collect information on the source server.

    1. Note the volume drive letter and volume label for each data volume that you would like to move to the destination server.

    2. On the source server, export the volume GUID paths by exporting the following registry key to a file: HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices. To do this, open the Registry Editor (regedit.exe), browse to the registry key, right-click the registry key, and clicking Export.

    3. Open Notepad and copy the exported.reg file. Remove all entries that are in the following form: \DosDevices\D:. Save the.reg file (all remaining entries should be in the following form: \??\Volume{ef93fe94-5dd7-11dd-961a-001e4cdb4059}).

  2. Prepare the destination server.

    1. Use disk management (diskmgmt.msc) to make sure that the volume letters for the data volumes are available (if there is a volume letter that is currently assigned to an existing volume on the destination server, change the volume letter for that volume.)

    2. To import the volume GUID paths into the destination server, copy the.reg file that you created previously, and then double-click that file to update the destination server.

      HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices key

  3. Move the disk drives or LUNs from the source server to the destination server.

    1. On the source server, remove the disk drives or unassign the LUNs by using Storage Manager for storage area networks (SAN). (To open Storage Manager for SANs, click Start, click Administrative Tools, and then click Storage Manager for SANs.)

    2. For each LUN: On the destination server, attach the disk drive or assign the LUNs by using Storage Manager for SANs. (To open Storage Manager for SANs, click Start, click Administrative Tools, then click Storage Manager for SANs.)

      To assign a LUN:

      1. In the console tree, click LUN Management.

      2. In the results pane, select the LUN that you want to assign.

      3. In the action pane, click Assign LUN.

      4. Follow the steps in the Assign LUN Wizard.

    3. On the destination server, use disk management (diskmgmt.msc) to map the appropriate volume drive letter and volume label to the volume on the LUN.

    4. If the source servers or destination servers are running the Server Core installation, remotely connect to the computer that is running the Server Core installation, and then complete all tasks that are listed previously in step 3.

      To log on to a computer that is running the Server Core installation, click Start, point to Administrative Tools, and then click Computer Management. (You might need to open Control Panel to open Administrative Tools, depending on your Start menu configuration.) In the Computer Management snap-in tree pane, right-click the top node, and then click Connect to another computer. Enter the computer name, and then click OK.

  4. If any files or folders on the migrated drive use local users or local groups permissions (except default users and groups), re-create these permission. Note that all domain users and groups permissions will remain intact, assuming that the source server and the destination server are members of the same domain.

Note

You can use the icacls command to modify file and folder permissions (type icacls /? in a Command Prompt window for details). Type this command in a Windows PowerShell session or a command prompt that has been opened with elevated user rights.
The list of the default users and groups is available in the topic Default User Accounts and Groups (https://go.microsoft.com/fwlink/?LinkId=149889) on the Microsoft Web site.

Migrate shared folders

If any of the folders on the migrated drive were shared on the source server, and they must be shared on the destination server, the following steps explain how to migrate shared folders.

  1. If any of the migrated shared folders use local users and group permissions, ensure that you have completed the migration of local users and groups.

    Send-SmigServerData and Receive-SmigServerData cmdlets must be started on the source server and the destination server within five minutes of each other. By default, Send-SmigServerData and Receive-SmigServerData operations terminate if a connection cannot be established within 300 seconds (five minutes). The maximum connection time-out for the Send-SmigServerData and Receive-SmigServerData cmdlets is stored in the following registry key, which is user-defined.

    Key: HKLM\Software\Microsoft\ServerMigration

    Value: MaxConnectionTime (REG_DWORD)

    Data: Between 1 and 3600 (represents connection time-out, in seconds). If a value larger than 3600 is specified, 3600 seconds (one hour) is used as the maximum connection time-out.

    For information about how to create a Windows Registry key, see Add a Registry Key (https://go.microsoft.com/fwlink/?LinkId=147298) on the Microsoft Web site.

  2. Open port 7000 on the source server and destination server (if this has not already been done).

    For information about how to open a port in Windows Firewall, see File Services Migration: Appendix A: Optional Procedures.

  3. On the destination server:

    1. Open a Windows PowerShell session with elevated user rights.

    2. Enter the following command:

      Receive-SmigServerData

  4. On the source server:

    1. Open a Windows PowerShell session in Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. On computers that are running Windows Server 2008 or Windows Server 2008 R2, the Windows PowerShell session must be opened with elevated user rights.

    2. Enter the following command:

      Send-SmigServerData -ComputerName <DestinationServerName> -SourcePath <SourcePath> -DestinationPath <DestinationPath> -Recurse -Include Share -Force

Note

The <SourcePath> value specifies the local path on the source server that contained the shared folder before the drive was migrated. Shared folder information is not stored on the data drive, so do not be concerned that the drive no longer resides on the source server.
The <DestinationPath> value specifies the local path on the destination server that contains folders that were previously shared on the source server. Unless the root drive letter or the folder structure has been changed on the migrated drive, <SourcePath> and <DestinationPath> values should be the same.
During shared folder migration, permissions for local users and groups and domain users and groups are migrated—no manual remapping is required.
LanMan Server service automatically restarts on the destination server, and the shared folders migrate.

DFSR migration

If you physically migrated data, clean-up the Distributed File System Replication (DFS Replication) configuration state, which is stored on the migrated volume:

  1. To clean up volumes (for each physically migrated volume)

    1. Navigate to the path <volume>\System Volume Information.

Note

This is a hidden system folder. To view this folder: in Windows Explorer, in the Folder Options dialog box, select the Show hidden files check box, and clear the Hide Protected operating system files check box. Also ensure that local administrators are granted Full Control of the folder. 

2.  Delete the DFSR folder and all content in the folder.  
      
3.  Revert any security permissions modifications that you made to perform the migration process.  
      
4.  Repeat this process for all physically migrated volumes.

  1. To clean up replicated folders (for replicated folders on physically migrated volumes)

    1. Navigate to the root of a replicated folder.

    2. Delete the DfsrPrivate folder and all subfolders.

    3. If the Staging path for the replicated folder is not located in the default location, remove the staging folder and all content in the staging folder.

Note

The default location for the Staging path is in the DfsrPrivate folder, and this step is not required if the path is at the default location. 

4.  If the Conflicts and Deleted path for the replicated folder is not located in the default location, remove the Conflicts and Deleted folder and all content in the Conflicts and Deleted folder.

Note

The default location for the Conflicts and Deleted path is in the DfsrPrivate folder, and this step is not required if the path is at the default location.

Use the inventoried information that you collected for the source server to detect all replication groups to which the source server belongs. Add the destination server as a member server to all these replication groups.

Migrate the source server identity

You need to rename the source server and migrate its previous identity to the destination server. You might also need to migrate the source server IP address to the destination server.

Rename the source server

Rename the source server to a temporary name.

Migrate IP address

When a static IP address is used on the source server, it is recommended that the IP address be migrated from the source server to the destination server. This is because client computers locally cache the IP address that is associated with a server name. Client computers will still attempt to access the source server even if it has been renamed.

When the server IP address is not migrated, you must stop the LanMan Server service on the source server. This is done to prevent users from accessing shared folders on the source server after they have been migrated to the destination server. Open a Windows PowerShell session with elevated user rights, and then run the following cmdlet:

Stop-Service LanmanServer -Force

For more information on IP address migration, see https://go.microsoft.com/fwlink/?LinkId=128513

Rename destination server

Rename the destination server to the name that was originally used for the source server.

Configure DFS Replication on the destination server

Configuration of DFS Replication on the destination server is determined by whether you migrated the data by copying or physically moving it

If you migrated the data by copying it

Follow this procedure to add a replication connection between the source server and the destination server for each replication group on the source server:

  1. Click Start, point to Administrative Tools, and then click DFS Management.

  2. In the console tree, under the Replication node, select Add Replication Groups to Display, enter the name of the source, and then click Show Replication Groups. Select all of the replication groups that are displayed, and then click OK.

  3. For each replication group, do the following:

    1. Click the replication group, and then click New Member. The New Member Wizard appears. Follow the instructions in the wizard to add the destination server to the replication group by using the information from question #2 in the DFS Replication Data Collection Worksheet (File Services Migration: Appendix B: Migration Data Collection Worksheets).

    2. In the console tree, under the Replication node, right-click the replication group that you just added the destination server to, and then click New Connection.

    3. Specify the source server and destination server as sending and receiving members, and specify a schedule so that the connection is always enabled. At this point, the replication is one-way.

    4. Select Create a second connection in the opposite direction to create a second connection for two-way replication between the sending and receiving members.

If you migrated the data by physically moving it

Follow this procedure to add a replication connection between the destination server and the closest server to the destination server other than the source server:

  1. Click Start, point to Administrative Tools, and then click DFS Management.

  2. In the console tree, under the Replication node, select Add Replication Groups to Display, enter the name of the source, and then click Show Replication Groups. Select all of the replication groups that are displayed, and then click OK.

  3. For each replication group:

    1. Click the replication group, and then click New Member. The New Member Wizard appears. Follow the instructions in the wizard to add the destination server to the replication group by using the information from question #2 in the DFS Replication Data Collection Worksheet (File Services Migration: Appendix B: Migration Data Collection Worksheets).

    2. In the console tree, under the Replication node, right-click the replication group that you just added the destination server to, and then click New Connection.

    3. Specify the destination server as the sending member, and then specify any other server except the source server as the receiving member. Specify the schedule to use for the connection. It is recommended that you select a server that has a good network connection to the destination server as the receiving member.

    4. Select Create a second connection in the opposite direction to create a connection for two-way replication between the sending and receiving members.

Note

The folder does not begin to replicate immediately. The new DFS Replication settings must be replicated to all domain controllers, and each member in the replication group must poll its closest domain controller to obtain these settings. The amount of time this takes depends on Active Directory Domain Services (AD DS) replication latency and the polling interval (60 minutes) on each member.
The dfsrdiag /pollad command can be used to force DFS Replication on the source server and destination server to poll AD DS and retrieve the latest configuration information instead of waiting for the next normal polling interval which could be up to 60 minutes.
After DFS Replication on the destination server polls AD DS, it begins to replicate the folders that it configured, and it performs an initial synchronization. Event ID 4102 (MSG_EVENT_DFSR_CS_INITIAL_SYNC_NEEDED) is registered in the event log on the destination server for each replicated folder.
During initial sync, DFS Replication downloads all files in the replicated folders from the source server and builds up a local copy of the database per volume. This process can be time consuming. It is possible to speed up the initial sync by preseeding the data from the source server onto the destination server (from the backup that was taken prior to commencing migration).
When the initial sync completes, event ID 4104 (MSG_EVENT_DFSR_CS_INITIAL_SYNC_COMPLETED) is registered for each replicated folder on the destination server. Monitor each replicated folder on the destination server, and check to ensure that all of them have completed the initial sync.

Import settings to the destination server

Follow the procedures in this section to import settings to the destination server.

Note

If the source server is not running Windows Server 2008 R2, the first procedure in this section does not apply. (This procedure is used to migrate the seed value that is used by BranchCache for the Network Files component, and it enables data that is stored in BranchCache on the source server to be used after it is migrated to the destination server. For information about how to migrate a BranchCache host server, see the BranchCache Migration Guide (https://go.microsoft.com/fwlink/?LinkID=139091).

To set up BranchCache for Network Files migration on the destination server

  1. On the destination server, open a Windows PowerShell session with elevated user rights. To do this, click Start, click All Programs, click Accessories, right-click Windows PowerShell, and then click Run as administrator.

  2. Type the following command, where storepath is the available path that contains the Svrmig.mig file, and then press ENTER.

    Import-SmigServerSetting -featureid BranchCache -Path <storepath\BranchCache> -Force -Verbose

Group Policy or local policy specific to server message block and Offline Files

Use a Group Policy object or a local policy on the destination server to change the settings to the same values as the source server. These settings are recorded in the SMB and Offline Files data collection worksheets in File Services Migration: Appendix B: Migration Data Collection Worksheets.

For more information about Group Policy, see the Windows Server Group Policy TechCenter (https://go.microsoft.com/fwlink/?LinkId=149892).

To import server message block settings

  1. Do one of the following:

    • If the policies are set by using Group Policy osbjects, use the Group Policy editing tools to apply appropriate policies to the destination server.

    • If the policies are set by using a local policy, do the following:

      1. On the destination server, click Start, click Run, type gpedit.msc the following in the Open text box, and then press ENTER to open the Local Group Policy Editor snap-in.

      2. In the snap-in tree pane, click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, and then click Security Options.

  2. Use a Group Policy object or a local policy to set the following settings to the same values as noted in Export settings. Set the destination server settings to the same values as were noted on the source server for the following settings:

    • Microsoft network server: Amount of idle time required before suspending a session

    • Microsoft network server: Digitally sign communications (always)

    • Microsoft network server: Digitally sign communications (if client agrees)

    • Microsoft network server: Disconnect clients when logon hours expire

Note

For any setting that is controlled by Group Policy, you must have the same Group Policy object apply to the destination server, or you can set the local policy of the destination server to get the same behavior. 

On destination servers that are running the Server Core installation, run the **secedit** command to change local policy settings (for more information about **secedit**, type **secedit /?** at a command prompt).

Note

The following procedure applies only if the source server is Windows Server 2008 R2.

To import Offline Files settings

  1. Do one of the following:

    • If the policies are set by using Group Policy, use the Group Policy editing tools to apply appropriate policies to the destination server.

    • If the policies are set by using local policy, do the following:

      1. On the destination server, click Start, click Run, type gpedit.msc in the Open text box, and then press ENTER to open the Local Group Policy Editor snap-in.

      2. In the snap-in tree pane, click Computer Configuration, click Windows Settings, click Administrative Templates, click Network, and then click LanMan Server.

  2. Use a Group Policy object or a local policy to set the destination server policy settings to the same values as the source server settings for BranchCache hash publication.

    On destination servers that are running the Server Core installation, run the secedit command to change local policy settings (for more information about secedit, type secedit /? at a command prompt).

DFS Namespace configuration

Complete the configuration of namespaces on the destination server. The procedure you use depends on whether you want a stand-alone or a domain-based namespace.

Stand-alone namespaces

Domain-based namespaces with more than one namespace server

Domain-based namespaces with one namespace server

Stand-alone namespaces

If you want a stand-alone namespace, you must first create the namespace on the destination server. You can do this by using the DFS Management Console, or the DFSUtil.exe command-line utility.

To create the namespace on the destination server

  1. Do one of the following:

    • On the destination server, open the DFS Management console, and create the namespace by using the same name as on the source server.

    • On the destination server, in a Command Prompt window opened with elevated user rights, type the following, and then press ENTER.

      Dfsutil.exe root addstd <\\DestinationServer\Namespace>

To import a namespace configuration from the export file

  1. On the destination server, in a Command Prompt window opened with elevated user rights, type the following (in which filename represents the file name into which you exported namespace settings from the source server in To export the namespace configuration to an export file), and then press ENTER.

    Dfsutil.exe root import set <filename> <\\DestinationServer\Namespace>

Domain-based namespaces with more than one namespace server

If you have more than one domain-based namespace server, you can add namespace servers to your destination server by using the DFS Management Console or the DFSUtil.exe command-line utility.

To use the DFS management console

  1. Select the namespace being migrated in the left pane.

  2. Click the Namespace servers tab in the right pane.

  3. Select Add Namespace Server.

  4. In the dialog box that opens, type the name of the destination server, and then click OK.

The destination server is added to the namespace.

To use DFSUtil.exe

  1. On the destination server, open a Command Prompt window.

  2. Type the following command, and then press ENTER.

    DFSUtil.exe target add <\\DestinationServer\Namespace>

Domain-based namespaces with one namespace server

This section applies only if a temporary server was not added to the namespace. If you added a temporary server to the namespace as part of your export process, see Domain-based namespaces with more than one namespace server.

To create the namespace on the destination server

  1. Do one of the following:

    • In the DFS Management Console on the destination server, create the namespace with the same name that was used on the source server.

    • Type the following command at a command prompt, and then press ENTER.

      Dfsutil.exe root adddom <\\DestinationServer\Namespace>

To import a namespace configuration from the export file

  1. On the destination server, open a Command Prompt window.

  2. Type the following command (in which filename represents the export file names you created in To export namespace settings). Run this command for each of the namespaces for which the source server was a namespace server.

    DFSUtil.exe root import set <Filename> \\DestinationServer\Namespace

Note

For each namespace, there must be a file name from which settings are imported.

To manually reset delegation permissions on the namespace

  1. On the destination server, open the DFS Management Console.

  2. Set the permissions that you inventoried in DFS Namespace configuration. When complete, close the DFS Management Console.

If any advanced registry keys were configured on SourceServer, use DFSUtil.exe to configure DestinationServer to have the same registry key settings. Run the following commands on the destination server to set the advanced registry keys.

To set advanced registry keys

  1. On the destination server, open a Command Prompt window.

  2. Run the following commands to set the advanced registry keys by using DFSUtil.exe.

    • DFSUtil.exe server registry DfsDnsConfig set <DestinationServer>

    • DFSUtil.exe server registry LdapTimeoutValue set <Value> <DestinationServer>

    • DFSUtil.exe server registry SyncInterval set <Value> <DestinationServer>

FSRM configuration on the destination server

When you are migrating FSRM, remember to use the same drive letters for the destination server volumes as for the source server. This is required because FSRM migration requires that the drive letter remains the same.

  1. Stop the FSRM File Services.

    Open a Windows PowerShell session with elevated user rights, and then run the following command:

    Stop-Service -name "srmsvc","srmreports"

  2. Type the following in the Windows PowerShell session, and then press ENTER.

    Import-SmigServerSetting -FeatureID FS-Resource-Manager -Path <storepath\FSRM> -Force

Note

If the Windows features that you are migrating have not been installed on the destination server, the Import-SmigServerSetting cmdlet installs them as part of the import process, along with any Windows features that they depend on. Some Windows features might require that you restart the destination server to complete the installation. After restarting the computer, you must run the cmdlet again with the -Force parameter to complete the import operation.
Importing FSRM settings to the destination server replaces any global FSRM configuration information that is already on the destination server.

  1. Set the configuration files for each volume.

    Type the following commands in a Windows PowerShell session, and then press ENTER.

Note

Running the following commands on a clean computer returns an error message. It is safe to ignore this error message. 

1.  Type the following code to stop the file screen driver:  
      
    
        fltmc detach datascrn <VolumeLetter>:

2.  Type the following code to stop the quota driver:  
      
    
        fltmc detach quota <VolumeLetter>:

3.  Add administrator Write permissions to the "\<VolumeLetter\>:\\System Volume information\\SRM" folder and the following subfolders:  
      
    
      - takeown /F "\<VolumeLetter\>:\\System Volume Information" /A /R /D Y  
          
      - cacls "\<VolumeLetter\>:\\System Volume Information" /T /E /G Administrators:F  
          
      - attrib -S -H "\<VolumeLetter\>:\\System Volume Information\\\*" /S /D  
          

4.  Copy the following files from the external storage to the SRM folder:  
      
    
      - Quota.xml  
          
      - Quota.md  
          
      - Datascrn.md  
          
      - DataScreenDatabase.xml  
          

5.  Type the following code to start the file screen driver:  
      
    
        fltmc attach datascrn <VolumeLetter>:

6.  Type the following code to start the quota driver:  
      
    
        fltmc attach quota <VolumeLetter>:

  1. Restart the FSRM File Services.

    Type the following in a Windows PowerShell session, and then press ENTER.

    Start-Service -name "srmsvc","srmreports"

  2. Configure scheduled reports and file management tasks.

    For each scheduled report, you need to create a scheduled task on the destination server.

Note

FSRM Reports and classification rule configurations are dependent on the drive letters and mount points. Any drives or mount points on the source server that are used by report or classification rule configurations must be available on the destination server or the configurations must be updated during import. 

After you have an eXtensible Markup Language (XML) file for each task, copy them to the destination server and run the following command in a Windows PowerShell session on the destination server for each task:  
  

    schtasks /create /xml:"TASKNAME.xml" /tn:"TASKNAME"

Shadow Copies of Shared Folders

Apply the same settings from the source server to the corresponding volumes on the destination server.

To migrate shadow copy settings for Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2

  1. To configure shadow copies, click Start, click Computer, and then for each volume on the destination server that had shadow copies configured on the source server, right-click the volume and select Configure Shadow Copies.

  2. Click Settings and verify that the location and size of shadow copy storage matches the settings from the source server.

  3. Click Schedule and verify that the details for the snapshot creation task match the settings from the source server.

To migrate shadow copy settings for a Server Core installation

  1. Log on to the destination server that is remotely running the Server Core installation by doing the following:

    1. Click Start, point to Administrative Tools, and then click Computer Management. (You might need to open Control Panel to open Administrative Tools, depending on your Start menu configuration.)

    2. In the Computer Management snap-in tree pane, right-click the top node, and then click Connect to another computer.

  2. Enter the computer name, and then click OK.

  3. Expand System Tools, right-click Shared Folders, click the All Tasks tab, and then click Configure Shadow Copies.

  4. For each volume on the destination server that had shadow copies configured on the source server, right-click the volume, select Configure Shadow Copies, click Settings, and verify that the location and size of shadow copy storage match the settings from the source server.

  5. Click Schedule, and verify that these details for the snapshot creation task match the settings from the source server.

See Also

Concepts

File Services Migration Guide
File Services Migration: Preparing to Migrate
File Services Migration: Verifying the Migration
File Services Migration: Post-Migration Tasks
File Services Migration: Appendix A: Optional Procedures
File Services Migration: Appendix B: Migration Data Collection Worksheets