Swapping Site Hardware Using Windows NT Backup
|
On This Page
 | Skills Required for SMS Maintenance and Recovery Procedures |
| Determining Backup Requirements |
| Performing Site Backup |
| Setting Up the New Site Server |
| Working with Remote SQL Server Installations |
This document covers the very specific case in which a Microsoft® Systems Management Server 2.0 (SMS) site is still running, but the site server must be moved to another computer. This situation becomes necessary when, for example, the current hardware shows signs of imminent failure, the organizational hardware standards change, or the site requires a more powerful server.
If both the computer on which the site server is running and the computer to which the site server is to be moved use the same or very similar hardware, you can run an image backup. Hardware differences between the two computers must be small enough to allow the new computer to boot and to allow hardware drivers to be updated after the Windows NT backup is restored to the new computer. The backup must include the Security Accounts Manager (SAM) database, if applicable; the registry; and all operating system, Microsoft SQL Server, and SMS files with sufficient security permissions to avoid problems after the restore procedure.
If your hardware is too dissimilar to support an image backup restore, run the Backup SMS Site Server task. Then run a new site server installation and give the new hardware exactly the same name as the old hardware. Next, restore the backup to the new computer on top of the new site server installation. By default, the Backup SMS Site Server task does not back up package distribution points or package sources. To back up the package distribution points or the package sources, you must customize the backup control file, or you must use some other backup tool.
You can encounter synchronization problems in recovery due to activities that occurred between the time of backup and the time of system failure. If the backup is out of date and out of synchronization with other site servers, site systems, and clients, a full restore might not be possible. The procedures in this document ensure that all access to the site server is disabled before you run the backup, thereby eliminating resynchronization problems. Repairing synchronization issues that result from activity that occurs between the time of backup and the time of restore is outside the scope of this document; in such a case you must run a full site recovery by using the SMS Recovery Expert.
The procedures in this document are based on a hardware swap that you do with the site server in a primary site. The only significant difference in the backup requirements between a primary site and a secondary site is that a secondary site does not have a SQL Server database that must be backed up or restored, nor does it have an automated site backup task. If you do not run an image backup of the secondary site, you can use the backup control file from a primary site as a template to back up the site components on a secondary site.
Skills Required for SMS Maintenance and Recovery Procedures
To complete the SMS maintenance and recovery procedures successfully, you must know how to perform detailed, manual tasks on local and remote computers. Sometimes these tasks use Resource Kit tools for the operating system, SMS, and SQL Server. In many cases, you must manipulate critical data on live sites directly. For example, you might need to:
| • | Configure the operating system, work with the file system, and edit the registry. |
| • | Configure operating system security, including accounts, services, shares, trusts, permissions, rights, organizational units, domains, forests, and policy templates. |
| • | Configure SQL Server, restore databases, and update SQL Server tables with queries. |
Warning: Failing to complete the procedures successfully can cause site operations to fail, corrupt site data, or even corrupt data at multiple sites. Microsoft recommends that only an experienced administrator perform maintainenance and recovery procedures. For help with these procedures and guidance through the recovery process, contact Microsoft Product Support Services.
Determining Backup Requirements
SMS creates a default set of shares and access permissions during installation. However, additional shares might have been created following installation, and access permissions might have been modified. Prior to moving an SMS site server to a new computer, you must identify all shares on the current computer and determine access permissions assigned to those shares.
Default Systems Management Server Shares and Permissions
The following table shows the default shares and permissions. The share names are based on a site with a site code of NEW.
| Share Name | Resource | Permissions |
SMSPKGD$ | D:\SMSPKGD$ | Everyone: Full Control |
CAP_NEW | D:\CAP_NEW | Everyone: Full Control |
Cinfo | D:\SMS\Cinfo | Everyone: Full Control |
LicMtr | C:\Swmtr | Everyone: Full Control |
SMS_NEW | D:\SMS | Everyone: Full Control |
SMS_SITE | D:\SMS\inboxes\despoolr.box\rec | Everyone: Full Control |
SMSLOGON | D:\SMSLOGON | Administrators: Full Control |
| Everyone: Read |
Share and Directory List
During the restore process, the site fails if you do not place all site components on the same drive letters as they were on the old site server. Use the list of shares and the drive/directory locations recorded in Shares.txt to ensure that the backup includes all drives related to SMS on the site server being swapped.
Perform the following steps to determine the locations for SMS shares and directories and their access permissions.
To create a list of shares, directories, and access permissions:
1. | Open Command Prompt and run the following command: net share >\shares.txt The shares.txt file is created at the root of the drive where you run the command. | ||||||||||||
2. | Edit shares.txt to record drive and directory locations for the following:
Note: If the drive on which the site server files are located has previously run low on space, SMS might have created another package share on another drive. If packages have been shared individually, the site can include many package shares in many locations. | ||||||||||||
3. | Record the access permissions that are assigned to each directory and share that was identified in Step 2. Note: This step is particularly important if the access permissions have been modified from the default access permissions. |
Performing Site Backup
To move the site server to a new computer successfully, you must first isolate the site server during the entire backup and restore processes.
Isolating the Site
To avoid synchronization problems, you must isolate the site server completely before you start a backup.
The following procedure stops and disables SMS site services, which prevents data from being written to the site during the backup process. Disabling these services also ensures that they are backed up in this state and are not accidentally restarted by a reboot during the restore process. This procedure also stops and disables WMI so that the system cannot start it and SMS Administrator consoles cannot use it. In addition, this procedure deletes permissions to default SMS shares and any other shares that SMS has created. Deleting these permissions prevents write access to current data.
Note: This procedure applies to sites with local installations of SQL Servers only. If your site uses a remote installation of SQL Server, see "Working With Remote SQL Server Installations" at the end of this document.
To isolate the site server:
1. | If you plan to use the Backup SMS Site Server task to back up your site server, enable this task. |
2. | In the Services dialog box, stop and disable all SMS services, except for the SMS_SITE_BACKUP service. |
3. | Stop and disable the Windows Management Service so that it cannot be started. |
4. | Delete permissions to the default SMS shares and any other shares that SMS has created. Shares and permissions are listed in the Shares.txt file you created in the previous section of this document. |
Secondary Site Isolation Issues
Typically, the only way one site can initiate a task on another site in an SMS hierarchy is by copying files to the SMS_SITE share. However, a primary site that is the parent of a secondary site can initiate tasks, such as upgrading the secondary site, without copying files to the SMS_SITE share. Because of this parent-child relationship between a primary site and a secondary site, disabling the SMS_SITE share on a secondary site does not provide as much protection during a hardware swap or recovery operation as it does on a primary site.
If a secondary site remains on the network during the hardware swap, and if there is any possibility that a site upgrade of a secondary site is scheduled during the hardware swap or secondary site recovery, you should also stop the SMS_SITE_COMPONENT_MANAGER and SMS_EXECUTIVE services on the parent site of the secondary site. Doing so prevents the parent site from interfering with the secondary site. If you cannot afford to make the parent site unavailable, and you don't want the risk of the upgrade operation interfering with the hardware swap or the recovery operation, you must completely isolate the secondary site during the hardware swap or recovery operation by disconnecting it from the network.
Backing Up and Shutting Down the Current Site Server
There are two ways to back up a site server. You can perform a full image backup by running Windows NT backup or a third-party backup utility. Alternatively, you can back up individual components of an SMS site by running the Backup SMS Site Server task. The instructions for performing each type of backup is described below.
To use Windows NT backup:
1. | If you're using Windows NT backup, or any other backup utility that can create a complete image backup, shut down all SMS services on the site server. |
2. | Run a full image backup of Windows NT, SQL Server, and SMS including all security information and drives. Note that drives are listed in the Shares.txt file you created in the previous section of this document. |
3. | Store the backup on a server other than the site server. |
4. | Turn off the site server. |
To use the Backup SMS Site Server task:
1. | Run the Backup SMS Site Server task by starting the SMS_SITE_BACKUP service on the site server. If you have not enabled the backup, enable it through the SMS Administrator console in \Site Settings\Database Maintenance\Tasks\. After the site control file is updated, you can run the backup immediately by starting the SMS_SITE_BACKUP service. Be sure to back up all package sources and shares because these are not included in the default settings for the automated Site Server Backup task. You must enable the Backup SMS Site Server task before you stop the site services. |
2. | Store the backup on a server other than the site server. |
3. | Turn off the site server. |
Setting Up the New Site Server
The new site server must have the same machine name and domain name as the original site server. Windows NT must be installed on the new server to run the software that restores the backup image. Neither SQL Server nor SMS have to be installed prior to the restore process if a full image backup is restored.
Restoring a Full Image Backup
The full backup image should include all the Windows NT, SQL Server, SMS, and account data previously described. SMS benefits from restoring a full Windows NT backup, because related bits of information are spread throughout Windows NT, SQL Server, and all the different drives on the system. A full backup captures all these bits so they can be restored exactly as they were on the original server.
To restore a full image backup:
1. | Restore the full backup to the new site server. For information about restoring a backup, see the documentation for your backup utility. |
2. | Verify that SMS, SQL Server, and all other data directories are restored to the same drive letters as were used on the original site server. Warning: If the drive letters are changed, the restore will fail. |
3. | Modify drivers to accommodate any hardware differences between the original site server computer and the new computer. |
4. | Reboot the computer and ensure that all the hardware is functioning correctly with the updated drivers. |
5. | Restore the permissions on the SMS shares. |
6. | In the Services dialog box, start all SMS services and reset them to Automatic except for the SMS_SITE_BACKUP and SMS Hardware Inventory Agent service, which must remain Manual. |
7. | In the Services dialog box, enable WMI and set it to Automatic. |
8. | Reboot the new site server and ensure that the client processes start in the usual sequence. |
After you have set up the new site server, place the old site server on a private network and change its machine name to prevent a conflict with the new site in case both computers ever run on the same network.
Restoring a Site Components Backup
Refer to the SMS Recovery Expert for instructions about how to restore a backup of SMS site components. Ensure that the new site server is isolated during the entire restore process. Because the new site server setup creates shares that use the same names on the same server name as the original site server, the site server will not remain isolated if it is set up on the network. Before you run the site server setup, the computer must be removed from the network or placed on a private network that other SMS site system roles do not have access to.
Notes:
| • | If the original site server used a site service account from a user domain, and it was not a backup domain controller in that domain, setup fails when it tries to validate the site service account, because the new site server is not on the network. |
| • | Services also fail to start if setup runs with the /NOACCTCHECK parameter. In this case, run the new site server installation with a local account in the local administrators group that has the "Logon as a service" user right enabled for it. This step allows the site server to start after setup is completed and to finish configuring itself before it is shut down for restoring the backed-up site components. After the restore is completed and all the shares and services have been enabled, you can run site reset on the new site server to change the site service account name to the name that was in use when the backup was run. |
| • | If the site server remains isolated, you need to complete only the Prepare, Rebuild, and Restore steps in the Recovery Expert. If the site server does not remain isolated, you must also complete the repair steps in the Recovery Expert. |
Working with Remote SQL Server Installations
After an SMS site server is isolated as described in earlier sections, it can no longer interact with its SQL Server. Be sure to stop the SMS_SQL_MONITOR service on SQL Server for the site server being swapped so that it does not interfere with the site server hardware swap. A remote installation of SQL Server can be left running or halted after the site server is isolated. You might want to leave SQL Server running to enable access to other databases that might be installed on the server and to avoid disruptions for help desk personnel who are using SMS remote access tools such as remote control.
If you move the remote SQL Server to new hardware, follow the same procedures to isolate the current SQL Server. This includes stopping all SMS_SQL_MONITOR services running on the current site server and resetting them to Manual on the Services dialog box. You should also disable and stop WMI to prevent the site provider from interfering with the database during the hardware swap. If other remote SMS site systems are installed on this SQL Server, you must also isolate their services and shares. Unless the SQL Server is placed on a private network where no SMS site system roles can access it, all sites sharing the SQL Server being swapped must have their SMS_SITE_COMPONENT_MANAGER service and their SMS_EXECUTIVE service stopped to prevent any process from accessing the databases.
Note: You must run the SMS upgrade on all site servers sharing the swapped SQL Server after the swap is complete to restore their site provider and their SMS_SQL_MONITOR.
If the SQL Server remains isolated, activity cannot cause the different data components of a site to get out of sync during the hardware swap. For this reason, only when you swap site server hardware for a remote SQL Server can you restore the site files alone, or the SQL Server database alone—without restoring both.