Post-migration Tasks for WSUS

Article
04/09/2014

Updated: July 19, 2011

Applies To: Windows Server 2003 with SP2, Windows Server 2008 R2, Windows Server 2008 R2 with SP1, Windows Server Update Services, Windows Small Business Server 2011 Essentials

Completing the migration

Perform the following tasks to complete the Windows Server Update Services (WSUS) 3.0 SP2 migration.

Point the downstream servers to the new WSUS server
Point the WSUS clients to the new WSUS server
Restore the role if there is a migration failure
Retire the WSUS role on the source server (optional)

Point the downstream servers to the new WSUS server

If you have downstream servers in your WSUS configuration, and if the server identity on the destination server was changed, perform the following procedure to point them to the new WSUS server.

To connect a downstream server to an upstream server

In the navigation pane of the downstream WSUS Server Administration console, click Options.
Select the Update Source and Proxy Server option and then click the Update Source tab.
Select the Synchronize from another Windows Server Update Services server check box, and then type the server name and port number in the corresponding boxes.
Repeat step 1 through step 3 for additional downstream servers, if applicable. The synchronization may take anywhere from several minutes to several hours to finish.
To confirm that the downstream servers are synchronizing with the upstream server, in the WSUS Administration Console on the upstream WSUS server, click Downstream Servers. In the Status pane, confirm that the server’s Last Synchronization date is after the date that the previous steps were completed.

Point the WSUS clients to the new WSUS server

If the server identity on the destination server was changed, you must point the WSUS clients to the new WSUS destination server.

To point to the new WSUS server

Use Local Group Policy Editor to change the URL in the Specify intranet Microsoft update service policy setting to reflect the new WSUS server.
Update the Group Policy settings that are used to point WSUS clients to the WSUS server by entering the FQDN of the new WSUS server. After you have updated the Group Policy settings, WSUS clients should start to synchronize with the new WSUS server.
To make sure that WSUS clients point to the new WSUS server immediately, you must force a detection by expiring the WSUS clients’ cookie and initiating detection, which causes WSUS to update computer group membership. If you do not force a detection, it can take up to four hours for the clients’ cookies to expire and for clients to point to the new WSUS server.

To force a detection
1. Open a command prompt.
2. Type wuauclt.exe /resetauthorization /detectnow to force the detection.
Depending on the number of clients, the initial synchronization can take several minutes to several hours to finish. To confirm the synchronization is complete, in the WSUS Administration Console, expand Computers and then click All Computers. In the Status pane, click Any, and then click Refresh. Confirm that the computers that you expect to see synchronizing to this WSUS server are listed. The Last Contact Date has to be refreshed with a post-migration time stamp:

To refresh the Last Contact Date
1. Open a command prompt.
2. Type wuauclt.exe /detectnow to force detection.
3. Type wuauclt.exe /reportnow to force a report to verify that the Last Contact Date was updated.
After the clients have synchronized, confirm that clients are installing approved updates based on your WSUS configuration settings. In the WSUS Administration Console, click Reports and then click Computer Tabular Status. Select the Report Options applicable to the clients and then click Run Report. Confirm that the client computers are installing updates as expected.
To make sure that no WSUS clients are still pointed to the old WSUS server, wait a week, and then open the WSUS Administration Console on the old WSUS server. Expand Computers and then click All Computers. In the Status pane, click Any, and then click Refresh. Sort on Last Status Report. There should be no clients that have a Last Status Report date after the date step 4c (wuauclt.exe /reportnow) was completed.

Restore the role if there is a migration failure

Roll back WSUS migration on the source server
The migration process makes no changes to the source server and you do not have to therefore roll back the migration of WSUS on the source server.

Roll back WSUS migration on the destination server
Because the destination server is a new server, you do not have to roll back the migration of WSUS .

Retire the WSUS role on the source server (optional)

After you have confirmed that no WSUS clients are contacting the old WSUS server, you can uninstall WSUS.

To uninstall WSUS

On the source WSUS server, click Start, click Control Panel, and then click Uninstall a Program.
In the Programs and Features pane, select Windows Server Update Services, and then click Uninstall.
In the Remove Windows Server Update Services pane, select Database, Log Files, and Downloaded Updates. Click Next.
Click Next to start uninstalling WSUS. Be aware that as soon as you start the removal process by uninstalling you will be unable to cancel.
When the uninstall process is completed, click Finish to exit the wizard.

Troubleshooting the WSUS migration

The following list includes issues that may occur during the migration process and the resources to help resolve the problems.

Backup or restore fails. There may be SQL errors if backup or restore fails. Refer to the Issues with Backup and Restore section of the WSUS 3.0 SP2 Operations Guide for more information.

For a list of SQL Server 2005 error messages, see the SQL Server Error Messages article on MSDN.
For SQL Server 2008 troubleshooting information, see SQL Server Books Online for the individual troubleshooting sections for each data management and analysis technology on MSDN.

For SQL Server 2008 R2 troubleshooting information, see SQL Server Books Online for the individual troubleshooting sections for each data management and analysis technology on MSDN.
Role installation fails on the destination server. There may be errors in the setup log file. Refer to the Issues with Setup section of the WSUS 3.0 SP2 Operations Guide.
Client/server communication errors occur if clients cannot migrate to the new server and cannot install updates, or both. Refer to the following sections of the WSUS 3.0 SP2 Operations Guide: Issues with Client Computers Not Reporting and Issues with Client Computer Self-Update.

For a complete list of WSUS error codes, see Windows Update Codes.

Troubleshooting cmdlet-based migration

The Windows Server Migration Tools deployment log file is located at %windir%\Logs\SmigDeploy.log. Additional Windows Server Migration Tools log files are created at the following locations.

%windir%\Logs\ServerMigration.log
On Windows Server 2008 and Windows Server 2008 R2: %localappdata%\SvrMig\Log
On Windows Server 2003: %userprofile%\Local Settings\Application Data\SvrMig\Log

If migration log files cannot be created in the preceding locations, ServerMigration.log and SmigDeploy.log are created in %temp%, and other logs are created in %windir%\System32.

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.

FatalError [0x090001] PANTHR Exception (code 0xC0000005: ACCESS_VIOLATION) occurred at 0x000007FEEDE9E050 in C:\Windows\system32\migwiz\unbcl.dll (+000000000008E050).  Minidump attached (317793 bytes).

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.

If connections between either the source or destination servers and the domain controllers or global catalog servers cannot be restored, do the following.

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.

Viewing the content of Windows Server Migration Tools result objects

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

Result object descriptions

The Windows Server Migration Tools Import-SmigServerSetting and Export-SmigServerSetting cmdlets 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 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 share 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 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 both 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 NIC physical address for IP configuration, or user name for local user migration.

Examples

The following examples show how to store the list of the result objects in a variable, and then use the variable in a query to return the content of result objects after migration is complete.

To store a list of result objects as a variable for queries

To run a cmdlet and save the result in variable, type a command in the following format, and then press Enter.

$VariableName= $(Cmdlet)

The following is an example.

$ImportResult = $(Import-SmigServerSetting -FeatureId DHCP -User all -Group -Path D:\rmt\DemoStore -force -Verbose)

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 has completed its operations, return the information contained in the result object by typing a command in the following format, and then pressing Enter.

**$**VariableName

In the following example, the variable is named ImportResult.

**$**ImportResult

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.
```
           ItemType  ID                              Success  DetailsList
           --------  --                              -------  -----------
          OSSetting  Local User                         True  {Local User, Loc...
          OSSetting  Local Group                        True  {Local Group, Lo...
     WindowsFeature  DHCP                               True  {}
```
Each line of the preceding sample 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 examples in step 3 and forward.
To display a specific property for all result objects in the list, type a command in the following format, and then press Enter.

$<VariableName>| Select-Object -ExpandProperty <PropertyName>

The following is an example.

$importResult | Select-Object -ExpandProperty DetailsList
You can run more advanced queries to analyze result objects by using Windows PowerShell cmdlets. The following are examples.
- The following command returns only those details of result objects that have the ID Local User.
  
  $ImportResult | Where-Object { $_.ID -eq "Local User" } | Select-Object -ExpandProperty DetailsList
- The following command returns only those details of result objects with an ID of Local User that have a message severity equal to Warning.
  
  $ImportResult | Where-Object { $_.ID -eq "Local User" } | Select-Object -ExpandProperty DetailsList | ForEach-Object { if ($_.Severity -eq "Warning") {$_} }
- The following command returns only the details of result objects with an ID of Local User that also have the title Remote Desktop Users.
  
  $ImportResult | Where-Object { $_.ID -eq "Local Group" } | Select-Object -ExpandProperty DetailsList | ForEach-Object { if ($_.Title -eq "Remote DesktopUsers") {$_} }

More information about querying results

For more information about the cmdlets that are used in the preceding examples, see the following additional resources on the Microsoft Script Center Web site:

For more information about Windows PowerShell scripting techniques, see What Can I Do With Windows PowerShell? - Scripting Techniques on the Microsoft Script Center Web site.

Additional references

For complete information about how to install and use WSUS, see the following WSUS 3.0 SP2 resources on Microsoft TechNet:

WSUS 3.0 SP2 Deployment Guide

This guide describes how to deploy Windows Server Update Services (WSUS) 3.0 SP2.
WSUS 3.0 SP2 Operations Guide

This guide describes how to manage Windows Server Update Services 3.0 SP2.
WSUS 3.0 SP2 Release Notes

The Release Notes provides release-specific information about Windows Server Update Services 3.0 Service Pack 2 (WSUS 3.0 SP2)
WSUS 3.0 SP2 Step By Step Guide

This guide provides instructions for installing WSUS 3.0 SP2 by using either Windows Server Manager or the WUSSetup.exe file.

Share via