Moving SMS Servers Between Domains

Scalable Management for Microsoft Windows-based Systems

Technical Paper

Click here to download a copy of this paper.

Abstract

A systematic approach for moving SMS servers from one domain to another.

Note that although the Windows Server 2003 family provides a feature that allows you to rename a domain, this feature is currently not supported by SMS.

Renaming a domain and migrating to a new domain are two different operations. The primary difference is that during a migration operation, both the current domain and the new domain must exist. To change a domain name, you must migrate to the new domain as described in this paper.

If you rename a domain that SMS sites are installed on instead of migrating to a new domain, SMS is affected as follows:

• Site-to-site communication is lost

• Sites access to Microsoft SQL Server is lost

• Remote site systems stop functioning properly

• Distribution points are orphaned

• Clients are orphaned

• SMS accounts stop functioning properly

• Administrator console security is lost

On This Page

Introduction
Moving a Member Server
Other Moves
Appendices
For More Information

Introduction

Systems Management Server (SMS) is a powerful system, and must have a sophisticated security environment with many accounts. For more information, see the SMS Security Essentials technical paper at https://www.microsoft.com/smsmgmt/techdetails/secessentials.asp.

When SMS is set up it creates its accounts in the domains that are appropriate at that time. If you later decide to change your domain model or decide to change the domain that SMS servers are members of, you must make corresponding changes to some of the SMS accounts. This technical paper describes the procedures you should follow to make those changes.

You might have SMS site servers on Windows NT 4.0 or Windows 2000 domain controllers. You might have SMS servers other than site servers, such as site systems, component servers, or stand-alone site database servers. This paper also describes moving those servers from one domain to another.

You can upgrade Windows NT 4.0 member servers to Windows 2000 Server or Windows 2000 Advanced Server after moving the site server to another domain. You can also move site servers on member servers from Windows NT 4.0 domains to Windows 2000 domains.

This paper does not cover moving clients between domains.

As with any changes made to your systems, you should test the procedures in a realistic lab simulation of your production environment before you try them in your production environment.

This paper assumes that you are using SMS 2.0 Service Pack 2 or later.

Moving a Member Server

This section describes moving an SMS site server on a Windows NT 4.0 domain member server from one domain to another Windows NT 4.0 domain.

An example of this scenario is shown in Figure 1. The SMS site server starts on a member server in the original domain, and is then moved to the destination domain. The SMS site server is also running SQL Server 7.0 for the SMS database. The domain model is the traditional single master domain model. The site server moves from the original domain to the destination master (account).

The site server is moved because the company in the Figure 1 scenario has acquired another company with computers in its own domain. That domain has been made into a resource domain (new, in Figure 1). The SMS administrators in this scenario want to use SMS to manage both resource domains, and they feel that SMS runs much better and easier if SMS has domain administrator rights on all the clients. They have decided to move the SMS site server from the original resource domain to the master domain.

This scenario and the particular domain model used are given for illustration only. The procedure outlined in this paper applies equally well regardless of the roles of the domains and the reasons for making the move. However, it is always important that the original domain trust the destination domain. That way the accounts can be moved to the destination domain and used from the original domain by the site server, even prior to its move.

If your SMS site server is on a domain controller, or if the source or destination domains are Windows 2000 domains, see the Other Moves section later in this paper.

Figure 1: The Example Scenario

Configuration Details

SMS uses the SMS Service account to run SMS services on the site server, to connect to other computers for configuration of SMS roles on those computers, and for several other purposes. The SMS Service account must have administrative privileges on all the computers that it manages. This is usually accomplished by putting the account in the Domain Admins group. This works only when the Domain Admins group is in the local Administrators group on each of the computers that SMS will manage. In Figure 1, the SMS Service account is set up in the original domain and is a member of the Domain Admins group in the original domain. All the domain controllers and member computers of that domain have the domains Domain Admins group in their local Administrators group.

During installation in the original domain, SMS created the following user accounts and groups in the original domain, in addition to the SMS Service account:

• SMS&_domain_controller_name The Client Services (non-domain controller) account. Used to run SMS client services on domain controllers.

• SMSCliToknAcct& The Client User Token account. Used to run various SMS client tasks.

• SMSInternalCliGrp A group used for the Client User Token account.

• SMSLogonSvc The SMS Logon Service account. Used to run the SMS Logon Discovery Agent on logon points.

• SMSClient_<sitecode> The SMS Client Collection account. Used by SMS clients to connect to client access points (CAPs) and distribution points.

• SMSServer_<sitecode> The SMS Server Connection account. Used by SMS site systems (such as CAPs) to access the site server.

In this list, note that the Client Services account, the Client User Token account, and the SMSInternalCliGrp group are used to support the client functions on the domain controllers. The SMS Logon Service account supports the logon point activities on the domain controllers. Only the SMS Client Connection and SMS Server Connection accounts are important to SMS site activities. The others are important to SMS client and logon point activities.

SMS also created the following accounts on the site server:

• SMSCliSvcAcct&

• SMSCliToknAcct&

• SMS Admins group

The first two accounts support the client functions on the site server. (The site server is a client to itself.) The SMS Admins group is used to control access to Windows Management Instrumentation (WMI). The SMS Admins group is important to the use of SMS Administrator consoles, but not to SMS site server activities.

Optional Configuration Details

You have the option to use other SMS accounts. This is encouraged to ensure that you take maximum advantage of SMSs modular security. The optional SMS accounts are:

• SMS Site Address account Used for site-to-site communications. It is not needed if you have only one site. You can use any account that has access to the SMS_Site share on the remote site for this role, but it should be a unique account.

• Site System Connection account Used by the site server to connect to and manage the site systems. SMS tries to use the SMS Service account if this account is not created.

• Software Metering Service account Used to run software metering on software metering services. It is needed only if software metering is used.

• SMS Windows NT Client Software Installation account Used by SMS clients to access software on CAPs, distribution points, and possibly other servers. The SMS Client Connection account is used in this role if the SMS Windows NT Client Software Installation account is not created. If you do not want to give access to the SMS Client Connection account on other servers, you can use this account.

• SMS Client Remote Installation account Used by the site server to install SMS clients using Windows NT Remote Client Installation. If this account is not defined, SMS tries to use the SMS Service account.

If you use any of these optional accounts, they must be moved much like the SMS Service, SMS Server Connection, and SMS Client Connection accounts are moved in the following procedure. In particular, you must recreate them in the destination domain; you have to give SMS the details of the new accounts; and you have to make the new accounts effective.

For more information about SMS accounts, including the optional accounts, see the SMS Security Essentials technical paper.

To migrate an SMS site server on a member server from one domain to another domain

[ServerAccount] 
Name=destination_domain\account  
Password=secretpassword 
[ClientAccount] 
Name=destination_domain\account  
Password=secretpassword 

You can now remove the old SMS Client Connection and SMS Server Connection accounts from the original domain. Clients from the master domain or from the new resource domain can now be added to the site.

On the SMS site server, if you look at which domain the servers computer account is in, you can see that the SMS site server is still in the original domain. But all SMS accounts are now in the destination domain. SMS can now install and manage clients from both the destination domain and the new domain. SMS Object Security rights are delegated to users in the destination domain.

Now you can move the SMS site server to the destination domain. You do this by adding a computer account for the site server to the destination domain, and then changing the site server to be a member of the destination domain.

SMS is now running completely in the destination domain. You can install and manage clients from the destination and new domains.

When all clients are moved to the destination domain, it is possible to shut down the original domain. If you want to do that, you should first move any other site systems from the original domain to the destination domain (or create new site systems in the destination domain and remove the old site systems from the original domain). You should also remove the original domain from the SMS Networking Logon Discovery and Installation lists of domains and wait until SMS has removed the SMSLogon share, the SMS-related Netlogon share files, and the SMS NT Logon Discovery Agent service from all domain controllers in the original domain.

If you do not want to shut down the original domain, and you remove all the site systems from the original domain, you can remove the old SMS accounts from the original domain.

Verify that the migration steps have successfully run and that the goals have been achieved. See Appendix B for information about how to perform this verification.

Note that the procedure provided in this paper does not move all accounts from the original domain to the destination domain. Because the Client Services account is not moved, the client must be reinstalled on the site server.

You can upgrade Windows NT 4.0 member servers to Windows 2000 Server or Windows 2000 Advanced Server after moving the site server between domains.

Other Moves

Moving other SMS servers between domains have considerations that are different from moving a member server. The following sections describe those considerations.

Moving a Site Server on a Windows NT 4.0 Domain Controller

A site server on a Windows NT 4.0 domain controller cannot be moved to another domain, because a Windows NT 4.0 domain controller cannot be moved between domains. The domain controller has the security information for the original domain, and this cannot be eliminated in any way or replaced with the information for the new domain. A Windows NT 4.0 domain controller does not even have a dialog box to indicate which domain it should be moved to.

A site server on a Windows NT 4.0 domain controller could be upgraded to Windows 2000 and then moved. This is described in the next section.

Moving a Site Server on a Windows 2000 Domain Controller

A site server on a Windows 2000 domain controller can be moved, but this move is performed by demoting the domain controller to a member server, moving it, and then promoting it back to being a domain controller in the destination domain. This works if the site server accounts are all in the destination domain prior to demoting the server, as they are in the procedure previously outlined. Reinstallation of the SMS client on the domain controller is then done after it is promoted back to being a domain controller. Demotion and promotion of Windows 2000 domain controllers is done with the Active Directory Installation Wizard (DCPromo.exe).

If the server is no longer required as a domain controller, the promotion back to domain controller status can be skipped.

Moving Secondary Site Servers

The procedure in this technical paper applies equally to primary and secondary site servers.

Moving Site Systems

Moving site systems other than logon points (CAPs, distribution points, and software metering servers) between domains can be done at the same time as you move the site server. You must give the new SMS Client Connection account privileges on the CAPs, distribution points, and software metering servers, as performed in Step 6. The other steps affect the site systems automatically.

Another approach, and the one that must be used with logon points, is that you can create new site systems in the destination domain after the new accounts are in the destination domain. You can remove site systems from the original domain when they are no longer needed.

Logon points are created in the destination domain when you enable Logon Installation or Logon Discovery. They are removed when you disable Logon Installation and Logon Discovery.

When you create a new distribution point, you must also add it to the appropriate distribution point group or add the distribution point to the relevant packages, and then refresh the distribution of the packages.

Moving Other Servers

Moving SMS components servers (such as sender servers) or computers running SQL Server that are separate from the SMS site server is not supported.

Appendices

Appendix A: Resetting an SMS Site

For SMS to use a new SMS Service account, you must perform a site reset for the site. The following procedure is the most common way to perform a site reset.

1. On the SMS site server, run SMS Setup.exe.

2. Click Modify or reset the current installation, and then click Next until you reach the section of the setup wizard for setting the SMS Service account.

3. Enter the new SMS Service account details, including its domain. Ensure that the new SMS Service account has administrative privileges on the computers to be managed by SMS (possibly by putting it in the Domain Admins group of the account domain). Also, ensure that it has administrative privileges on the SMS site server, and has Log on as a service right on the site server.

Another common method to run a site reset is to set the SMS Service account in the SMS Administrator console.

1. In the SMS Administrator console, navigate to Systems Management Server \Site Database\Site Hierarchy\<site code>.

2. On the Action menu, click Properties.

3. On the Accounts tab, change the account.

4. Close the dialog box and wait until the changes have propagated through your SMS site.

The SMS Security Essentials paper has additional details about site resets.

Appendix B: Verifying the Move

Now that you have completed the procedure to move your SMS server from the original domain to the destination domain, you should verify the success of the procedure. To do so, check the following:

Verify site server functionality.

• Check whether Site Status messages are frequently updated. If not, check whether the SMS services at the SMS site server are started. If not, check whether there is a logon failure and correct the user and password information. If the problem still exists, check the status of each SMS component.

• Ensure that logging is enabled on the site server by using SMS Service Manager, and then review the SMS logs for SMS Site Component Manager and SMS Executive (Sitecomp.log and SMSexec.log, respectively). Ensure that no errors are occurring.

Verify CAP permissions.

• Try to connect to the CAP from the client by mapping a drive to the CAP share. Specify the SMS Client Connection account when mapping the drive. Check that the SMS Client Connection account is in a group or groups that have access privileges to all CAPs. Verify that the domain trusts are functional, if you are using accounts from different domains.

Verify that clients are being discovered after running a discovery method.

• In the SMS Administrator console, navigate to Site Database \ Collections \ All Systems. All Windows client systems must show up.

Verify that clients are being installed after running a client installation method.

• Check all clients to ensure they have a Systems Management icon in Control Panel.

• Double-click the icon and check the Components tab for Installation Status of each component. The status must be INSTALLED. The status of each component should show the appropriate build number for the version of SMS that you are running. For example, for SMS 2.0 SP2, the version is 2.00.1493.2013. Note that Windows Management has a different version, depending on the operating system in use or the version of WMI that you deployed.

• Check the logs in %systemroot%\ms\sms\logs for errors. The log files must not contain critical errors.

Verify the client functionality from an SMS Administrator console

• Ensure that a hardware and software inventory have been taken at the client, and have had time to be processed at the site server. Then view the hardware and software inventory data. Inventory data should be present and match the client computer.

• Use Remote Tools to remotely manage some clients.

• Create a simple software package, for example Notepad.exe, distribute it, and advertise it to the clients. The advertised program should run successfully.

Verify the client functionality at individual clients

• Upgrade Site Configuration by clicking the Update Configuration button in Control Panel\Systems Management. If the update fails, as indicated in the CCIM32.log, the SMS client might not have sufficient permission to access the CAP. If the clients are in a different domain from the CAPs, check whether all necessary trusts are up and running and whether the CAP server has the necessary Domain User groups in its local User group. Also ensure that the SMS Service account has administrative privileges on the CAP.

Verify hierarchy connections

• Check whether the address accounts have full control on the SMS\Inboxes\despoolr.box\receive directory at the receiving SMS sites. Verify that domain, account, and password information specified in the addresses at the send site is still valid.

More verification

• Check that the SMS Service account has administrative privileges on every computer you want SMS to manage, unless you are using optional SMS accounts to provide SMS services (in which case those accounts require the privileges).

• Check that the SMS Service account has Log on as a service right on the SMS site server.

• Verify that the SMS Object Security rights in the SMS Administrator console have all been copied from administrator accounts in the original domain to the destination domain, if appropriate.

• Ensure the original domain has been removed from the Windows NT Logon Discovery and Installation methods domain lists.

• Verify the SMS Client Connection accounts from the original domain are removed from the site and that the clients are successfully using the new accounts. Check sample client logs to ensure that client activities are being performed normally.

For More Information

For more information about SMS, see the SMS Web site at https://www.microsoft.com/smsmgmt/default.asp, and Microsoft TechNet at https://technet.microsoft.com/sms/bb676797.aspx. The SMS Security Essentials technical paper is available at https://www.microsoft.com/smsmgmt/techdetails/secessentials.asp