The procedure you use to remove Distributed File System (DFS) namespaces from the source server depends on whether the namespaces are stand-alone or domain-based. If you want to remove the namespace from the source server, you must use DFSUtil.exe.

Note

By default, DFS Namespace clients cache the list of namespace servers for 300 seconds (five minutes), so we recommend that you do not run the DFSUtil.exe remove command within five minutes of completing verification of the DFS Namespace migration. During migration, DFS Namespace clients have only the temporary server in the cache of namespace servers. Waiting five minutes after you add the destination server to the namespace allows clients to list the destination server in their cache.

Launch the DFS Management snap-in and remove the source server from all the replication groups. This step brings the configuration back to that before the migration process commenced. It is very important that this step is performed only after the identity migration is complete so that the configuration information in Active Directory Domain Services is not left in an inconsistent state.

For stand-alone namespaces, no action is required other than migrating the identity back to the source server.

For domain-based namespaces with greater than one namespace server, or if a temporary server was added to a namespace that initially had only one namespace server, do the following:

Remove destination server from the namespace.

Migrate identity and shared folder information to the source server.

Add the source server to namespace.

For domain-based namespaces with only one namespace server, where no temporary namespace server was added during migration, do the following:

Migrate identity and shared folder information to source server.

Verify the export file for the namespace that was created during migration is still available.

Delete the namespace.

Create the namespace on the source server.

Import the namespace configuration from the export file created during the migration.

Manually reset delegation permissions to the namespace.

Note

Another option to migrate domain-based namespaces with one namespace server is to temporarily add a second namespace server before the migration, and then remove the temporary server after the migration.

If no changes have been made to migrated files, folders, and shared folders on the destination server and this data has not been deleted from the source server, no additional steps to roll back data and shared folders are required.

If the migrated files, folders, or shared folders may have been modified on the destination server by the administrators or users, perform the following steps to synchronize the changes from the destination server back to the source server:

Type the following code in a Command Prompt window to copy the updated migrated data (files and folders) from the destination server back to the source server:

This command can be executed on the source server or on the destination server, and it will recursively copy updated data. Type robocopy /? in a Command Prompt window for additional copy options, including options to copy file and folder permissions.

Caution

Permissions that you set for non-default local users and groups will not copy properly and need to be created manually.

Compare the lists of shared folders and their permissions on the source server and destination server and manually synchronize any changes.

To list all shared folders and their permissions, type the following command in a Windows PowerShell session that has been opened with elevated user rights:

When some files are migrated physically and others are copied, there is a chance that the FSRM configuration is not synchronized. To remedy this, delete and create new copies of the Quota.md and Datascrn.md files.

For domain-joined machines:

If a custom action (quota notification or file management task) fails to execute with an access-denied failure and a corresponding event log, you should remove the custom action and create it on the destination server.

If the Send-SmigServerData and Receive-SmigServerData cmdlets run indefinitely without completing, your destination server might not have sufficient disk space or a large enough FSRM or NTFS quota limit to allow for data migration to finish. To determine whether insufficient disk space is preventing the data send-receive process from completing, do the following on the destination server.

Open %localappdata%/Svrmig/Log/SetupAct.log.

Review the most recent log entries. If the following exception occurs, your destination server has insufficient disk space or FSRM or NTFS quota limits to complete data migration.

Win32Exception: unable to write to FileStream: There is not enough space on the disk.

Press Ctrl+C to cancel Send-SmigServerData and Receive-SmigServerData on both source and destination servers.

Check for sufficient disk space on the destination server’s hard disk drive. If the destination server’s hard disk drive has insufficient space, do one of the following.

Clear additional space.

Identify a different hard disk drive that has sufficient space.

If the destination server’s hard disk drive, the destination path, or any folders that contain the destination path have an FSRM or NTFS quota enabled, and the quota limit does not allow for sufficient disk space to migrate data, do one of the following.

Increase the quota limit to set sufficient disk space to migrate the data. For more information about FSRM quota management, see one of the following.

If the Send-SmigServerData and Receive-SmigServerData cmdlets cannot establish connectivity, verify the following conditions and then try again:

In the Send-SmigServerData command on the source server, the ComputerName parameter correctly specifies the name of the destination server.

The Receive-SmigServerData and Send-SmigServerData commands are entered on the destination server and the source server respectively within five minutes of one another. This is the default maximum connection time-out for Send-SmigServerData and Receive-SmigServerData. You can change the maximum connection time-out for the Send-SmigServerData and Receive-SmigServerData cmdlets by modifying the following user-defined registry key on the source server and destination server.

Key: HK_Local_Machine\Software\Microsoft\ServerMigration

Value: MaxConnectionTime (REG_DWORD)

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

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

The same password is entered on the source server and destination server.

The source server and destination server are available on the same subnet:

On the destination server, in a Command Prompt window, type ipconfig and note the Subnet Mask value.

On the source server, in a Command Prompt window, type ipconfig and note the Subnet Mask value.

Ensure that the Subnet Mask values are the same on the source server and destination server.

Port 7000 is open on the source and destination server, and they are not in use by another application.

To check if port 7000 open, in a Command Prompt window, enter the command:

If a migration cmdlet fails, and the Windows PowerShell session closes unexpectedly with an access violation error message, look for a message similar to the following example in the %localappdata%\SvrMig\Logs\setuperr.log file.

This failure occurs when the server cannot contact domain controllers that are associated with domain users or groups who are members of local groups, or who have rights to files or shares that are being migrated. When this happens, each domain user or group is displayed in the GUI as an unresolved security identifier (SID). An example of a SID is S-1-5-21-1579938362-1064596589-3161144252-1006.

To prevent this problem, verify that required domain controllers or global catalog servers are running, and that network connectivity allows communication between both source and destination servers and required domain controllers or global catalog servers. Then, run the cmdlets again.

Before you run Export-SmigServerSetting, Import-SmigServerSetting or Get-SmigServerFeature again, remove all unresolved domain users or groups who are members of local groups from the server on which you are running the cmdlet.

Before you run Send-SmigServerData or Receive-SmigServerData again, remove all unresolved domain users or groups who have user rights to files, folders, or shares on the migration source server.

All Windows Server Migration Tools cmdlets return results as objects. You can save result objects, and query them for more information about the settings and data that were migrated. You can also use result objects as input for other Windows PowerShell commands and scripts.

The Import-SmigServerSetting and Export-SmigServerSetting cmdlets in Windows Server Migration Tools return results in a list of MigrationResult objects. Each MigrationResult object contains information about the data or setting that the cmdlet processes, the result of the operation, and any related error or warning messages. The following table describes the properties of a MigrationResult object.

Property Name

Type

Definition

ItemType

Enum

The type of item being migrated. Values include General, WindowsFeatureInstallation, WindowsFeature, and OSSetting.

ID

String

The ID of the migrated item. Examples of values include Local User, Local Group, and DHCP.

Success

Boolean

The value True is displayed if the migration was successful; otherwise, False is displayed.

DetailsList

List <MigrationResultDetails>

A list of MigrationResultDetails objects.

Send-SmigServerData and Receive-SmigServerData cmdlets return results in a list of MigrationDataResult objects. Each MigrationDataResult object contains information about the data or shared folder that the cmdlet processes, the result of the operation, any error or warning messages, and other related information. The following table describes the properties of a MigrationDataResult object.

Property Name

Type

Definition

ItemType

Enum

The type of migrated item. Values include File, Folder, Share, and Encrypted File.

SourceLocation

String

The source location of the item, shown as a path name.

DestinationLocation

String

The destination location of the item shown as a path name.

Success

Boolean

The value True is displayed if the migration was successful; otherwise, False is displayed.

Size

Integer

The item size, in bytes.

ErrorDetails

List <MigrationResultDetails>

A list of MigrationResultDetails objects.

Error

Enum

Errors enumeration for errors that occurred.

WarningMessageList

List <String>

A list of warning messages.

The following table describes the properties of objects within the MigrationResultDetails object that are common to MigrationResult and MigrationDataResult objects.

Property name

Type

Definition

FeatureId

String

The name of the migration setting that is related to the item. Examples of values include IPConfig and DNS. This property is empty for data migration.

Messages

List <String>

A list of detailed event messages.

DetailCode

Integer

The error or warning code associated with each event message.

Severity

Enum

The severity of an event, if events occurred. Examples of values include Information, Error, and Warning.

Title

String

Title of the result object. Examples of values include the physical address of the network adapter for IP configuration, or the user name for local user migration.

This command runs the Import-SmigServerSetting cmdlet with several parameters specified, and then saves result objects in the variable ImportResult.

After the Import-SmigServerSetting cmdlet completes its operations, return the information contained in the result object by typing a command in the following format $VariableName, and then press ENTER.

This command returns information contained in the result objects that were returned by Import-SmigServerSetting in the example shown in step 1. The following is an example of the output that is displayed by calling the ImportResult variable:

Each line of the preceding example is a migration result for an item that was migrated by using the Import-SmigServerSetting cmdlet. The column heading names are properties of MigrationResult objects. You can incorporate these properties into another command to return greater detail about result objects, as shown by the examples that follow in steps 3 and 4.

To display a specific property for all result objects in the list, type a command in the following format $<VariableName>| Select-Object -ExpandProperty<PropertyName>, and then press ENTER. The following is an example.