Microsoft System Management Server Best Practices

SMS Best Practices

SMS Best Practices discusses deployment and planning issues to help administrators avoid common problems.
  • Introduction
  • Client Discovery and Installation
  • Window NT 4.0 Domains, SMS Accounts, and Security
  • SMS Infrastructure Considerations
  • Managing Workforce Resources
  • Security Issues
  • Sizing Systems Management Server Site Servers
  • Software Distribution
  • Software Metering Strategies
  • SQL Server Strategies
  • Upgrading Previous Releases of SMS to SMS 2.0 Service Pack 2
© 1985-2000 Microsoft Corporation. All rights reserved.


Introduction

Systems Management Server (SMS) version 2.0 is a powerful management tool that is most effective when deployments and upgrades are well planned and properly executed. Toward that end, a wealth of information is available to administrators planning SMS deployments; however, because SMS touches just about every part of an organization’s computing environment, the volume of information can sometimes be overwhelming. It can also be difficult to discern exactly what information you need. Thus, the purpose of this Best Practices resource is to introduce the key issues that administrators face during deployment, suggest preferred methods, and provide links to further information.

In addition to understanding SMS, deployments require a strong understanding of Windows NT, SQL Server, and your organization’s security policies and network infrastructure. SMS deployments must be carefully planned and follow a serious project management methodology. If you have a complex environment you might consider hiring Microsoft Consulting Services to assist you in successfully deploying SMS. Alternatively, you might consider enrolling SMS administrators in SMS training courses. See the Microsoft Training & Services Web site for information on available SMS courses.

These Best Practices topics list problem areas that administrators commonly encounter during SMS deployments. By reading these topics and the resources they point to, administrators can better plan deployments and site configurations, and thus avoid common SMS deployment problems.

Best Practices stresses the importance of setting up a lab that simulates your production environment, and thoroughly testing your SMS deployment plans before implementing them in your production environment. SMS is a complex system requiring complicated access to networked resources. As an SMS administrator you can increase SMS security by using optional accounts, but you must be aware that additional testing is needed whenever unique resource access is required.

The Best Practices content is concise. This allows the reader to quickly understand SMS issues. However, this content is not intended to be exhaustive, which is why there are references and links to existing comprehensive material (such as the SMS Administrator’s Guide, technical papers, and resource kit utilities). Administrators should be familiar with all relevant materials before embarking on an SMS deployment project.

These topics are arranged and grouped by category; however, there is no suggested order in which the topics should be read. Administrators should browse the content for issues they might be considering. When reviewing a topic, it is recommended that you also review the references listed in the More Information section included with each topic in order to gain a complete understanding of the issue.

SMS Deployment Phases

The following describes the phases in a well-planned Systems Management Server 2.0 deployment plan.

Phase 1: Design

  • Define the project team.
  • Collect and collate data on your network, servers, applications, and security policies.
  • Analyze the collected data.
  • Collect and analyze business objectives.
  • Interview appropriate staff.
  • Create and document the Systems Management Server (SMS) design.
  • Review the design with project team.
  • Finalize the SMS design document.

Phase 2: Pre-Pilot

  • Define test laboratory environment and equipment.
  • Create and ratify engineering documents on your Windows NT 4.0 domain structure, SMS, and SQL Server.
  • Create the SMS laboratory which simulates your network, server, and client base.
  • If you already have SMS installed, create the laboratory to simulate your current SMS infrastructure.
  • Install or upgrade to SMS SP2 on test servers, configure the test site, and deploy test clients.
  • Collect and review inventory data, distribute and advertise software packages, and test remote tools.
  • Collect and collate deployment results.
  • Review the deployment results with the project team and make required adjustments.
  • Train support staff on SMS functionality, procedures, and client support issues.

Phase 3: Pilot

  • Install and configure all SMS infrastructure servers. Or, upgrade existing SMS and clients.
  • Create and document SMS infrastructure maintenance tasks.
  • Establish a SMS infrastructure support team.
  • Send warning message to the pilot user group.
  • Deploy SMS client to the pilot user group.
  • Check and document help desk reports.
  • Create reports to review client hardware and software inventory.
  • Review the deployment results with the project team and make required adjustments.
  • Make changes to the deployment tasks.
  • Repeat pilots with new groups refining the deployment plans.

Phase 4: Full Deployment

  • Finalize installation of SMS infrastructure servers, including logon points, client access points, distribution points, and software metering servers.
  • For new installations, deploy SMS client components by configuring client discovery and installation methods.
  • Create reports, view queries and collections to monitor the client installation process and accumulating inventory.
  • Deploy required software updates.

Phase 5: Site Maintenance

  • Refine SMS server infrastructure as required.
  • Review project team structure and make required adjustments.
  • Maintain lab to test future site design changes, software package distributions, client configuration changes, and possible future updates and upgrades for SMS site servers and clients.
  • Monitor and maintain SMS infrastructure servers.
  • Monitor and maintain SMS components installed on client computers.
  • Create, test, and distribute new applications and upgrades.
  • Create custom reports, queries, and collections.


Client Discovery and Installation

A computer is considered an SMS client when core SMS client software has been installed on it.

Site assignment is based on the site boundaries you specify in the SMS Administrator console. Client agents, such as hardware and software inventory, can be installed on assigned resources. Resources are not manageable using SMS until core components have been installed.

As the site administrator, you define which subnets clients are assigned in. You also configure which client agents are to be installed, and how those agents are configured. Discovery and assignment parameters, client agents and their configurations are all set in the SMS Administrator console for your site.


Ensure That You Have the Latest Version of DCOM Installed on Windows 95 and Windows 98 Computers.

Before installing the SMS client components on a Windows 95 or Windows 95 OSR2 computer, make sure that you have the latest version of the Distributed Component Object Model (DCOM 1.3) installed. By doing this, you can avoid issues related to Windows Management Instrumentation (WMI) on these earlier operating systems.

Windows 98 computers do not require any updates before SMS client components are installed, however it is recommended that DCOM be upgraded to the latest versions on Windows 98 computers. This is not an issue for Windows NT or Windows 2000 client computers.

Keep in mind, you should ensure that the latest service packs are installed on Windows NT and Windows 2000 client computers.

More Information

For additional information, refer to the following resources:

  • Microsoft DCOM95 for Windows 95, version 1.3 - Release Notes, EULA, and Download
  • Microsoft DCOM98 for Windows 98, version 1.3 - Release Notes, EULA, and Download
  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Support Knowledge Base


Consider Staging the Installation of SMS Clients

Once you’ve installed SMS on the site servers, you can then begin to configure the site. You have the option of configuring discovery and installation methods. Discovery methods are how SMS finds resources located on the network that might qualify to become SMS clients. The site boundaries are checked to see if a client qualifies or not. Installation methods are how SMS installs client software on clients who do qualify as SMS clients.

The various discovery and installation methods can be configured to stage the installation of SMS client components. The effect of doing so is to disperse the amount of network traffic caused by SMS client discovery and installation, and to disperse the load on the site servers that are processing inventory information for the newly installed clients as well as installing files.

It is important to note that some discovery methods cause some portions of the SMS client to be installed. The installed SMS client components are then used to determine whether or not the client qualifies for site assignment and client installation.

The following section shows possible installation objectives and methods to achieve those objectives.

Deployment Objective

Allow users to install SMS client components at will.

Methods

  • Enable Windows Networking Logon Client Installation.
  • On the Logon Settings tab, disable Modify user logon scripts.
  • Have clients run SMSman.exe (or SMSman16.exe for 16-bit clients.)

Comments

  • SMSman.exe is easily distributed to network locations, run from a Web page, or even sent as an e-mail attachment.
  • SMSman.exe locates logon points from which it can obtain SMS client components.
  • Parameters can be passed to SMSman.exe on the command line. This could be done to indicate to SMSman.exe that there is no user intervention required, or to direct it to specific logon points that may be closer on the network to the client than other logon points.
  • SMSman.exe is approximately 500 KB. Its significant size should affect your distribution plans.
  • SMSman.exe may be updated in future releases of SMS, which would require redistribution.
  • Relying on users to run SMSman.exe could result in incomplete inventory information. Computers where a user has not run SMSman.exe will not have SMS installed, and therefore will not be reporting inventory information.

Deployment Objective

Install SMS Client Components when a user logs on.

Methods

  • Enable Windows Networking Logon Client Installation.
  • On the Logon Settings tab, enable Modify user logon scripts.

Comments

  • All user profiles will be modified to run the SMS Logon Script.
  • Users tend to log on at similar times, which can impact network performance and place a load on the SMS site servers.
  • Users must log on to initiate the installation of SMS client components. This may affect deployment on servers where users seldom log on. It may also affect computers where users frequently lock their workstations, as opposed to users who routinely log off.

Deployment Objective

Install SMS client components when a user logs on, but limit the rate at which clients are installed though logon scripts.

Methods

  • Enable Windows Networking Logon Client Installation.
  • On the Logon Settings tab, enable Modify user logon scripts.
  • Use the Random Logon Tool (RndLogin.exe) to limit the rate at which clients are discovered and installed.

Comments

  • All user profiles will be modified to run the SMS Logon Script.
  • Requires editing the SMS Logon Script. A sample logon script is included with this tool, which provides examples of how to run Random Login within the logon script.
  • Users must log on to initiate the installation of SMS client components. This may affect deployment on servers where users seldom log on. It may also affect computers where users frequently lock their workstations, as opposed to users who routinely log off.

Deployment Objective

Automatically install Windows NT and Windows 2000 SMS clients.

Methods

  • Enable Windows NT Remote Client Installation.

Comments

  • Client installation files are copied from the SMS site and from a client access point (CAP). Installation takes place in the background. No user intervention is required.
  • Useful if you do not want to rely on logon scripts or the manual execution of SMSman.exe to install SMS client components. It is particularly useful when you need to install servers that rarely have a user logged on.
  • This installation method is not available for Windows 95 or Windows 98 clients.
  • You can select to install on Windows NT workstations, servers, or domain controllers.
  • By editing the registry, you can prevent SMS client components from being installed on certain computers. For specific instructions on how to do this, see Knowledge Base article "Q207729 - SMS: Excluding Computers from Windows NT Remote Client Installation".

Staging Client Deployment Using Site Boundaries

You can use IP subnets to stage deployment of the SMS client regardless of which installation method you use. If your organization’s network consists of more than one IP subnet, you can add those subnets to your SMS site boundary, one at a time. Only clients whose IP address and subnet mask evaluate into a subnet that matches one of the subnets activated in your site boundary will be installed as SMS clients. A staged deployment of the SMS client on a subnet basis can disperse the amount of traffic that SMS generates on the network.

For information about configuring site boundaries and client assignment, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 8 – "Configuring SMS Sites," the section titled "Configuring Site Assignment."

For an in-depth discussion on configuring the various discovery and installation methods, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 9 – "Discovering Resources and Installing Clients".

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 8 – "Configuring SMS Sites".
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 9 – "Discovering Resources and Installing Clients".
  • SMS 2.0 Resource Guide in the Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Support Knowledge Base


Consider the Ramifications of Dial-In Users and Client Installation

Logon discovery and installation does not function over a RAS connection that has speeds of 40 KBps or less. Editing the SMS Logon Script can modify this behavior. For information on how to do this, see the SMS Release Notes which can be found on the Systems Management Server 2.0 compact disk. Also see knowledge base article Q224388 - SMS: Slownet Determines Network Speed at Logon.

If dial-in users do occasionally visit offices and connect to your high-speed network, you might consider installing the SMS client components on these clients at this time.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server (SMS) version 2.0 Resource Guide
  • Q224388 - SMS: Slownet Determines Network Speed at Logon
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Support Knowledge Base


Save Bandwidth by Preloading Core Components on Clients

You can preload the core components of SMS 2.0 on a computer before the discovery and installation process is activated. The purpose of preloading a client is to reduce the amount of network bandwidth required by each client during the installation of the client core components.

This option is suitable for staging new computers that have images placed on them and are then installed at a client location. It is also useful for deploying a computer that will connect only with a modem.

Use the Client Preload (CLiStage.fpf) utility, which is available in the Microsoft BackOffice 4.5 Resource Kit. The Client Preload tool is an SMS Installer installation script. It is important to note the Client Preload tool only loads the core SMS client components. It does not load any client agents that may be enabled for your site.

There are important issues to consider when planning to use this tool. Each new SMS client is assigned a unique SMS identifier. CliStage.ipf uses NewUid.exe to create a new identifier on the client. If you are using programs such as Norton Ghost, you must be sure to use NewUid.exe to allocate a new SMS identifier to each computer after the ghost image is installed. NewUid.exe is a compiled SMS Installer application. You can modify NewUid.ipf to perform additional functions by using SMS Installer to modify and compile.

You will also want to ensure that computers you preload with SMS client components are preloaded with a client configuration that closely matches the client configuration of the site where the preloaded computer will be assigned. If you don’t do this, you might not be saving as much network bandwidth as you had planned.

To obtain these tools, and for information on how to use them, install the Microsoft BackOffice 4.5 Resource Kit.

You might also consider installing the latest version of the Windows Management Instrumentation (WMI) as you preload computers. When SMS installs the Hardware Inventory Client Agent (if it’s enabled for the site), SMS checks to see if WMI is on the computer. If WMI is not found, SMS installs it. You could eliminate this potential network traffic by preloading WMI on Windows 95, Windows 98, and Windows NT 4.0 SP4 clients. To obtain the latest version of WMI, see Microsoft Windows Management Instrumentation (WMI) Downloads.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server (SMS) version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Microsoft Windows Management Instrumentation (WMI) Downloads
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Support Knowledge Base
  • Q202338 - SMS: How to Pre-stage SMS Clients to Avoid Network Bandwidth Contention During Installation


Excluding Specific Clients From Installation

If you have enabled Network Discovery and Windows NT Remote Client Installation, and you need to exclude particular clients or a list of clients from the installation of SMS, you can do so by directly editing the Registry of the SMS Site Sever. (As always, use extreme caution when editing the Registry.)

It is important to note that this does not prevent SMS components from being installed if a user who has an SMS logon script set in their profile, or if a user runs SMSman.exe. You need to use other methods to prevent these events from happening. For example, you could create a specific user that does not have the SMS logon script set in the user profile, and allow only this account to log on at the computer where you do not want SMS installed.

For specific instructions on how to do this, see Knowledge Base article "Q207729 - SMS: Excluding Computers from Windows NT Remote Client Installation."

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • SMS 2.0 Resource Guide in the Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Support Knowledge Base
  • Q207729 - SMS: Excluding Computers from Windows NT Remote Client Installation


Removing SMS From a Client

If you must remove the SMS core components from a client computer for any reason, there are several utilities you can use to accomplish this task.

  • SMSMan /U (/Q)

    The preferred method of client component removal when the SMS client is fully functional.

    The SMSMan utility is also used to remove the SMS client from a computer. You must run it with the /U switch to indicate the uninstall. The addition of the /Q option can be used to make the uninstall process "quiet" and unseen by the user. The SMSMan file is executed from a network share or a local source.

  • 20CLICLN.BAT

    The preferred method of client removal if the SMS client is not functioning properly.

    The 20CliCln.bat utility can be obtained by installing the SMS 2.0 Support Tools. To install these tools, run Support.exe from the Support folder on the SMS 2.0 SP2 installation CD. Executing this file is a hands-off approach to remove the SMS client from a single computer.

  • Site Boundaries

    The site boundaries typically contain a list of IP subnets of groups of computers and network segments that belong to the SMS site. Removing any of the IP subnets within the network boundary list causes the clients within the IP subnet to be uninstalled from the site. However, SMSuid.dat and SMSMan.exe will remain on the computer.

None of these utilities remove all traces of SMS from the computer. In most cases, it is advantageous for SMSuid.dat and SMSCfg.ini to remain on the computer. These files are created on client computers when SMS is first installed. They contain an identifier unique to that computer which is used to identify the computer within SMS. Should SMS client components be reinstalled after being removed, the computer retains its original unique ID if those files are left intact. The result is that the reinstalled client is re-associated with its inventory history.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 9 – "Discovering Resources and Installing Clients"
  • SMS 2.0 Resource Guide in the Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Support Knowledge Base


Troubleshooting Client Installation

If a client fails to install, check assignment, disk space, and permissions. Some issues that may arise while installing client computers include:

  • Installation not enabled. You may find that discovery is running, but the client is not installed. This is usually because the installation method is not enabled.
  • Client not assigned. If the client computer is on a separate subnet from the site server, then be sure to add that subnet to the site boundaries. Otherwise, the client will not be assigned and the installation process will simply stop.
  • Lack of disk space on the client computer. The SMS client installation process checks for 30 MB of free space on the client. Installation stops if 30 MB of free disk space is not found. SMS does not consume 30 MB of disk space on a client, but to ensure a clean install, the installation routines look for this much space.
  • Lack of permissions on a computer running Windows NT. The installation method must use an account with administrator privileges. Either the local user has administrator privileges on the client computer, or the installation method uses an installation account that has administrative privileges on the client computer.
  • If the %temp% environment variable is incorrectly specified, SMS will not install.

SMS processes create log files which detail successes and failures. Log files provide an excellent method of determining where problems were encountered. You should review SMS log files found in the %systemroot%\Ms\Sms\Logs folder on client computers. CliCore.log should be reviewed first, because Clicore.exe should the first SMS process to run on the client computer. Next check for WN_Logon.log, which logs events recorded by Windows Networking Logon Discovery and Client Installation. If you have run SMSman.exe to manually install the SMS client, check WN_Manual.Log. These are the logs to start with when troubleshooting client installation. There are more log files found in the Logs folder that can assist in your troubleshooting efforts.

You must fully understand how SMS functions to troubleshoot effectively. For a beginning discussion on how SMS functions, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 1 – "Introducing Systems Management Server Version 2.0," the section titled "Understanding How SMS Functions."

For updated system flow charts, including troubleshooting tips, see the SMS 2.0 Resource Guide in the Microsoft BackOffice 4.5 Resource Kit.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 1 – "Introducing Systems Management Server Version 2.0"
  • SMS 2.0 Resource Guide in the Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Support Knowledge Base


Windows NT 4.0 Domains, SMS Accounts, and Security

Microsoft Systems Management Server (SMS) 2.0 is highly dependent on Microsoft Windows NT and Windows NT security. SMS uses Windows NT file sharing to communicate between sites, between site servers and site systems, and between clients and site servers.

If you have used Windows NT, then you should already be familiar with the basics of Windows NT security, including the concepts related to accounts, groups, and domains. However, there are a number of subtleties in Windows NT that, if relevant to your SMS implementation, can be critical to the success of your project.

SMS Setup automatically creates accounts that provide minimal security. Depending on your domain model and security needs, you might want to specify additional accounts to maximize security. Some accounts are required for site functionality; others are recommended for greater security. If your network uses multiple Windows NT domains, then you will need to ensure that SMS accounts have required access in all domains.

You should set up a lab environment where your organization’s network infrastructure is simulated. Optional accounts, multiple domains issues, locked-down client issues, and software distribution should all be thoroughly tested before being implemented on your production network.


Read the SMS Security Essentials Whitepaper

The SMS Security Essentials whitepaper is the most important single resource regarding SMS and security. This comprehensive resource describes how SMS deployments are affected by the security policies of your organization, and how SMS can be configured to accommodate the most secure of networks.

The whitepaper contains information administrators must understand in order to effectively deploy SMS 2.0. The SMS Security Essentials whitepaper discusses how the various Windows NT domain models will affect your deployment plans for SMS. It discusses the SMS security model, how SMS creates accounts for its use, and how you can create your own accounts to increase security within your organization. It also contains tables that describe the various accounts created by SMS, and their uses.

The SMS Security Essentials whitepaper is a must read for administrators planning SMS deployments for their organizations, as well as for those who have already deployed SMS and are looking for ways to increase security.

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


Plan the SMS Site Domain Before Installing

After an SMS server is installed in a domain, it cannot be moved to a different domain. It must be uninstalled from the original domain and then reinstalled in the new domain.

For this reason, it is important that your security planning is complete, and that your Window NT domain model is implemented before you install any SMS servers.

SMS can be installed into any existing Windows NT domain that may already exist in your organization, or a new SMS domain could be created. You must ensure that your SMS deployment considers the domain model in place at your organization, and that all SMS requirements for resource access are satisfied.

To fully understand the implications of selecting which domain SMS is installed into, read the SMS Security Essentials whitepaper. The paper provides insight into how SMS accesses resources on the network and how the different domain models will affect your deployment plans.

You should set up a lab environment where your organizations network infrastructure is simulated. Optional accounts, multiple domains issues, locked-down client issues, and software distribution should all be thoroughly tested before being implemented on your production network.

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


Review Security When SMS is Installed in a Resource Domain

By default, SMS security is set up in the master domain. When installing SMS, the master domain account that is used to log on to a server in the resource domain must have administrative rights in both the master domain and resource domain. Rights and privileges must then be configured for the resource domain. The master domain\Domain Users group must be added to the Users group in the resource domain and to the Users group on every client access point (CAP) installed on a member server in the resource domain. This allows users that log on to the account domain to access the CAPs in the resource domain. Users that log on to the resource domain cannot access CAPs in the master domain unless the Guest account is enabled.

You should set up a lab environment where your organization’s network infrastructure is simulated. Optional accounts, multiple domains issues, locked-down client issues, and software distribution should all be thoroughly tested before being implemented on your production network.

For detailed information on configuring SMS in a multiple domain environment, see the SMS Security Essentials whitepaper.

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


Create Additional SMS Client Remote Installation Accounts

The SMS administrator can create and designate multiple accounts as alternate SMS Client Remote Installation Accounts. These accounts can be used by the Client Configuration Manager to install SMS client software on Windows NT computers. These accounts are not created by default, but configuring them is recommended for greater security. If it does not exist, or if none of the specified accounts have administrator privileges on the client, then the SMS Service account is used.

By minimizing the use of the SMS Service account, you reduce the chances of that account being compromised. You can regularly change the password for the SMS Remote Client Installation accounts if required, or cycle through the accounts, disabling one and enabling others.

Note

  • Changing the SMS Service account password is not recommended.

For information on how to configure an SMS Client Remote Installation account, see the SMS Security Essentials whitepaper, Part 4 – “Planning, Implementing, and Using SMS Security.”

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • SMS Release Notes for SMS 2.0 Service Pack 2
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


Create Multiple SMS Client Network Connection Accounts.

A common problem for sites has been lockouts occurring on the SMSCliToknAcct& account. This account is used for a number of functions on the SMS client; if locked out, this account essentially disables the client computer's SMS client functionality. Many administrators enable account lockout in addition to their password expiration policies. SMS can handle both these situations, but administrative intervention is required.

It is recommended that the administrator have multiple SMS Client Network Connection accounts. This practice helps to keep new and active accounts available, thus the client should not get locked out. There is also an associated update, or hotfix, you can apply to prevent lockouts and orphans.

For further information on this issue, see Knowledge Base article Q231399 - SMS: SMSCliToknAcct& and/or SMSCliSvcAcct Accounts Locked Out on Site Systems or Domain.

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page
  • Q244410 - SMS: Smsapm32 Uses SMSCliToknAcct& to Search Mapped Drives Listed in the Path


Consider Creating Optional Accounts

The accounts created by SMS Setup provide minimal security. By default, the SMS Service account is used for many SMS processes. In many cases, a less powerful account can be used in place of the SMS Service account. The SMS Service account is a highly privileged account that you might not want to propagate throughout your environment. To increase security on your network, you should create new accounts and configure SMS to use them in place of the SMS Service account.

For a detailed discussion of how and when the SMS Service account can be replaced, see the SMS Security Essentials whitepaper, Part 4 – “Planning, Implementing, and Using SMS Security.” Search for the section titled “Optional Accounts.”

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


Do Not Change Accounts That Are Automatically Maintained by SMS Processes

When SMS is installed, SMS Setup creates a number of accounts required for the operation of your SMS site. As these accounts are created, randomly generated and encrypted account passwords are created. You should not attempt to change passwords for accounts created by SMS Setup.

If you manually change accounts, the related processes will not run successfully.

For a detailed list of SMS accounts that should not be changed, see SMS Security Essentials whitepaper, Part 4 – “Planning, Implementing, and Using SMS Security.” Search for the section titled “Managing SMS Account Password Changes.”

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


In General, Change Passwords, Rather Than Accounts, to Maintain Security.

Your security policy might dictate changing accounts or passwords on a regular basis. When working with SMS accounts, change the password of an existing SMS account rather than adding new accounts or deleting old ones, with the following exceptions:

  • SMS Client Connection account
  • SMS Service account, if this account is shared by more than one site
  • SMS SQL Server account, if this account is shared by more than one site
  • Software Metering Service account, if this account is shared by more than one software metering server

For these accounts, do not change current passwords. Instead, you must create new accounts for these roles. When the new accounts have been configured on all SMS site servers, use the SMS Administrator console to modify the accounts SMS services will use.

For a detailed list of SMS accounts that should not be changed, see SMS Security Essentials whitepaper, Part 4 – “Planning, Implementing, and Using SMS Security.” Search for the section titled “Managing SMS Account Password Changes.

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


SMS Infrastructure Considerations

When planning your SMS sites, you should start by designing the infrastructure (boundaries, hierarchy, and connectivity) and then consider special issues that pertain to your organization, such as supporting multiple languages, upgrading from earlier versions of SMS, interoperability, and NetWare environments. Your SMS design should provide the ability to scale as your organization grows.


Review Your Current Infrastructure

Having accurate information about your physical network infrastructure and the business issues that influence your network operations is critical to many of the decisions you make as you design and plan for your SMS deployment. The locations, types, and number of site servers deployed are greatly influenced by network topology.

You should also document what you want SMS to accomplish for you. A clear understanding of how you want to install and modify SMS to suit your organization's needs is an integral part of the design process.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Product Support Services Knowledge Base


Consider the Administrative and Network Advantages of Multiple Sites

When designing a site hierarchy, consider the administrative needs of your organization and the physical nature of your network.

An SMS site hierarchy is a collection of one or more SMS sites related to each other by parent-child relationships. The hierarchy provides a means of extending and scaling SMS support across a wide variety of organizational structures. A single site is the easiest to configure and manage, but there are several circumstances in which it is beneficial to set up multiple sites in an SMS hierarchy. Data flow and administration ability is of primary importance. It is important during this design phase to consider why, or if, you might need additional sites. The answer might fall into one of the following categories:

  • Network performance with some clients. Slow network connectivity between the site server and some of the clients might indicate a need to set up those clients in their own site.
  • Number of resources. If there are more resources than can be supported by a single site using the SMS features you have chosen, you should consider the creation of additional sites.
  • Features required by users. You might have groups of users that require different features of SMS.
  • International considerations. You might consider installing an international version of SMS in the same hierarchy that contains an English version or other international version.
  • Number of sites. If a hierarchy plan becomes large, you might need to add an additional layer of primary sites to help manage and organize the large number of sites that report to the central site.
  • Corporate structure. In some cases, the politics of an organization can play a role in site definition. There might be multiple system administration groups within an organization that that require administration of their own resources.
  • Domain structure. Your existing domain model might dictate the use of certain discovery methods, or you might choose to organize or reorganize your domain model to be easier to use with the SMS architecture.

When response on a parent site is degraded to unacceptable levels, you might consider creating additional levels in the hierarchy. These issues should be identified in a lab test environment. As a guideline, if you have 50 sites or more reporting to a single site, consider setting up another level in the hierarchy. However, it is server performance, number of clients per site, and administrative issues that are the true factors for considering additional sites in the hierarchy.

Based on the network information you have documented regarding your organization, you should plan the various sites and server roles that are required for your SMS deployment.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page


Configure Senders for Intersite Communication

During the design phase, remember that when there is more than one site in a hierarchy, methods for the sites to communicate up and down the hierarchy must exist. SMS sites communicate with each other using networks, senders, and addresses.

A sender is an SMS component that uses an existing network to communicate with other sites. A sender also provides a robust, reliable, fault-tolerant transfer mechanism to send data between connected sites.

An address consists of the site code to contact and the name of the server to connect to. A set of two addresses allows two sites to connect to each other. You can configure addresses to use specific senders for site-to-site communication. However, there can only be one instance of a specific sender on each site system, as well as only one address to a single site using a specific sender type. For example, an SMS site server can only have one Standard Sender address that connects a primary site to a child site. However, there can also be a RAS Sender configured with one address from the primary site to the same child site or another Standard Sender address configured to communicate with a different child site.

You can have multiple addresses for a site, but each one has to use a different type of sender. For example, you may want to use the Standard Sender or an ISDN RAS Sender for connectivity between two SMS sites. You may also want to use the Courier Sender to send large packages to child sites connected by slow or unreliable links.

Some SMS customers report that configuring a RAS Sender over slower network links may prove more reliable than a Standard Sender. This may be due to the smaller packet sizes used with the RAS Sender and error recovery mechanisms. However, you should include tests of this nature in your SMS lab to determine which senders and addresses work best for your organization’s needs and structure.

For an in-depth discussion on configuring senders and addressing sites, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 8 – "Configuring SMS Sites," the section titled “Configuring Site Communications.”

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 8 – "Configuring SMS Sites"
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page


Design Site System Roles Carefully

During the design phase, remember that some site system roles can be moved after installation, but others cannot.

As your organization's needs change and expand, you might find that your original site hierarchy design reduces performance to unacceptable levels. If this occurs, you might be able to increase the performance of your site by moving and assigning site system roles to additional computers.

The following table describes the site system roles that can be moved from one computer to another.

Site System Role | Can the role be moved?
CAP | Yes
Distribution point | Yes
Logon point | No
Site database server | Yes, if the role is moved between remote computers running SQL Server, or from a local server to a remote server.
Site server | No, you cannot move the site server to another computer. However, you can move the site server to another domain, or you can restore the site server to a different computer with the same server name.
SMS Administrator console | Yes
Software metering database server | Yes
Software metering server | Yes

Moving the SMS Site Database

During original site setup, you can choose either a local or a remote computer running SQL Server on which to create the SMS site database. If you selected to install the site database on a remote computer, the SMS site database can be moved to another (remote) computer running SQL Server. However, the SMS site database cannot be moved from a remote computer running SQL Server to the site server.

You should decide before running Setup whether or not to put the SMS site database on the site server computer. For example, you might choose to keep the SMS site database on the site server so that only one computer needs to be maintained for these two roles. Microsoft performance testing shows that SMS performs best when the site database is on the site server computer.

Many Locations With a Small Number of Clients and No Local Site Server

Depending on your organization, you might have many geographically dispersed sites with a small number of clients at each site, without a local site server.

SMS assumes LAN-based connectivity within a physical site hierarchy. Customers that deploy SMS without a local site server, client access point (CAP), or distribution point at these small locations risk not being able to control or reduce the amount of network traffic flowing through the slow link connection.

It is not advisable to deploy clients to remote locations without locally-based site servers, CAPs, and distribution points. SMS was not designed to work in this scenario. It hasn't been tested extensively in this scenario. Customers who must deploy a small number of SMS clients in a site without a local site server should understand the risks that are involved.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • SMS 2.0 SP2 Release Notes (both Readme.htm and Readme_operations.htm)
  • Microsoft Systems Management Server Version 2.0 Swapping Site Server Hardware technical paper
  • Microsoft Systems Management Server Version 2.0 Swapping Site Server Hardware technical paper


Enable Logging

To assist in troubleshooting problems within your site, you should enable logging in your site. Before you can use SMS logging, you must first enable logging through SMS Service Manager. Within Service Manager, you can specify which components are logged and also set the log file size. To monitor site-to-site communications, specify that the applicable components be logged to one log file.

To enable logging

  1. In Site Database, in Tools, right-click SMS Service Manager, point to All Tasks, and then click Start SMS Service Manager.
  2. When the Service Manager window appears, expand Components, and then click the desired component.
  3. In the right pane, right-click the component, click Logging, select the Logging enabled check box, and then configure the logging settings. You can view the log files contained in the %systemroot%\SMS\logs directory.

You want to be careful when logging is enabled because this action can cause some performance degradation depending on the number of components that have logging enabled on the site server.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page


Proactively Monitor Network Performance

SMS generates substantial network traffic because of constant communication between servers and clients within a site. Slower links degrade performance and might require a different site design or approach.

You should ensure that a fast, reliable, and efficient network connection exists between all the resources in the site, including the site server, the site database server, site systems, and computers running the SMS Administrator console. There is limited ability to schedule or control traffic within the site. Most intrasite traffic is generated when SMS components communicate with the remote server. Some polling intervals and schedules can be set to control some of the traffic, but not all of it.

Use monitoring tools, such as Network Monitor, to view the events on the network. This can help you detect a problem before it becomes widespread, or allow you to make necessary site changes during the testing phase of your deployment.

For an in-depth discussion on the use of Network Monitor, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 16 – "Using SMS for Network Maintenance".

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page


Connect Sites Using Fast Reliable Links

It is recommended that sites should be connected by fast, reliable, and efficient links. A common problem involves implementing a single SMS site that spans over slow, unreliable, or congested WAN links. When determining the quality of a network link, it is important to consider the following:

  • Line quality
  • Bandwidth availability
  • Average and peak load

When clients install SMS client software, they do so from a CAP. When multiple CAPs exist for a site, the client selects a CAP randomly from its list in the Registry. If the selected CAP happens to reside across a WAN link, the client installation, configuration update, and data transfer processes use that link.

When the client attempts to run an advertised program, the process of selecting an available distribution point is similar to selecting a CAP. It is usually selected randomly. If the selected distribution point is over a WAN link, and the advertised program is large (for example, Microsoft Office 2000), then the WAN can be congested, especially when multiple users attempt to run the advertised program simultaneously. These are two reasons why it is important that sites are contained within high-bandwidth networks.

If your existing network connections have the following characteristics, then you can support a CAP:

  • Error free
  • Reliable
  • Not saturated with network traffic before any SMS load is added
  • Has no built-in delay from satellite links or overloaded routers

If your existing network connections have the following characteristics, then the site will experience problems with a CAP:

  • High rate of packet errors
  • Unreliable
  • Is already saturated with network traffic before any SMS load is added
  • Has long delays between the CAP and site server because of overloaded routers

SMS requires a fast, reliable, and efficient link for all processes that interact between CAPs, distribution points, and site servers. The recommended design is to always have an SMS site at the end of a WAN link. This can be a secondary site, which requires fewer resources than a primary site.

It is better to have a secondary site server share the workload with an existing server than to have clients connect over slow links.

You can Use PerfServ.exe and SetSMSSvr.exe utilities in the Microsoft BackOffice 4.5 Resource Kit to specify the distribution points and client access points that clients will use. However, these utilities are useful only after the SMS client software has been installed, which might have occurred over the WAN link.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page
  • Microsoft Product Support Services Knowledge Base
  • Q236325 – SMS: How to Obtain and Install Systems Management Server 2.0 Service Pack 2


Slow Client Connectivity and Mobile User Issues

SMS supports bandwidth management and checkpoint restarts between SMS sites, but not between a client and its site systems.

You can designate software advertisements as not mandatory over slow links, which is good when you have some users that connect over a slow network link, but it also limits software distribution to only those users with high-speed links. As a result, SMS does not efficiently manage clients that connect to the client access point, distribution point, or logon points over a slow or unreliable link.

This affects the functionality of the following: software distribution, remote control, SMS client installation, upgrading, the 30-day verification cycle, checking for updated components, checking for advertisements, reporting inventory, software metering, and so forth. This is because all of these features might consume all available bandwidth, especially on slow links.

With SMS 2.0 Service Pack 2 (SP2), you can designate a client to not upgrade to SP2 automatically by using the Client Upgrade Control Tool (CliUpgrade.exe). This can be beneficial when a site has many dial-up users that visit the local network only occasionally. It is preferable to delay the upgrade of SMS to a time when the client is connected via the local network rather than having the client upgrade over a dial-up connection. CliUpgrade.exe is included with the SMS Support Tools. To install the SMS Support Tools, run Support\Support.exe from the SMS 2.0 SP 2 compact disc.

Many third-party partners have released products that work with SMS 2.0 that address specific issues related to slow client connectivity and mobile user management issues.

More Information

More information regarding third-party partners is available from the SMS Management Partners Web site at
http://www.microsoft.com/isapi/redir.dll?prd=SMS&Ar=Mgmt_partners

Use the Client Travel Mode Tool (CliTravl.exe and ChkTravl.bat) from the Microsoft BackOffice 4.5 Resource Kit, to set and check the travel mode options on the client via a command-line tool. This is useful in situations where clients might move from site to site within the enterprise and the user should not be bothered with a dialog box each time the client tries to join a new site. Keeping travel mode active is valuable in preventing the SMS client from uninstalling itself when it is temporarily not a member of any site. However, in travel mode the default setting is to prompt the user when site assignments change.

High Traffic Domains

There is a negative impact on performance when an SMS site is installed on a domain controller within a busy domain. You should consider the benefits of installing SMS on to a domain controller within a resource domain where there is no need to process logon requests.

Alternatively, consider installing SMS on to a member server, since a member server does not store the domain database. As a result, it does not process logon requests. Another benefit of member servers is the ability to create local SMS accounts that provide a higher level of security for the administrator.

The boundaries of a site determine which client resources SMS assigns to a particular site. Site boundaries consist of complete IP subnets or IPX networks. There is no ability to limit specific addresses within the subnet or network to a site.

Common reasons for installing multiple sites are:

  • Network Performance. When links that connect different physical locations within your organization are slow, you should consider establishing different SMS sites on each side of the slow links.
  • International Considerations. When SMS client computers or SMS administrators are using different international configurations and settings, you might want to install multiple SMS sites to accommodate language preferences.
  • Features required by users. If multiple groups of clients require conflicting SMS feature configurations, you would need to separate them into different SMS sites because you can configure client settings on a site-wide basis only.
  • IS administrative structure. When multiple IS (Information Services) administrator groups require restricted access to resources, each group might need its own SMS site. Each of those sites can be configured as children of a parent site where a central administrator can retain control of all child sites.
  • Number of resources. Although SMS 2.0 is scalable and can manage a large number of users, you might want to divide the number of managed resources and assign them to different SMS sites.

When the network link between the proposed site server and some clients is slow, consider developing a multi-site hierarchy. It is better to have a secondary site server sharing the workload on a server with other processes than to have clients connect over a slow link.

Windows Network Discovery is not limited to searching for resources within the SMS site boundaries. Windows Network Discovery scans the network regions defined in the Windows Network Discovery Properties dialog box and produces discovery data records (DDRs) based on discovered IP devices. DDRs are stored in the SMS site database. The devices that are within the site boundaries are then assigned to the site, whereas the devices that are outside of the site boundaries are marked as unassigned. Note that the SMS site database of the site initiating the discovery is the one that has the stored DDRs. If Windows Network Discovery is initiated from a secondary site, the DDRs are stored in its parent site.

You can use the Load Site Boundary Tool (Sitebndy.exe) from the Microsoft BackOffice 4.5 Resource Kit to import site boundaries from a text file. This tool is helpful if you have many subnets to add to the site boundaries.

More Information

For additional information, refer to the following resources:

  • Q200344 - SMS: Defining Site Boundaries in Systems Management Server 2.0
  • Microsoft Systems Management Server 2.0 Administrator's Guide
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Windows NT Resource Kit
  • Systems Management Server - Home Page
  • Microsoft TechNet - Home Page


Managing Workforce Resources

A common problem area for SMS installations is the assignment of workforce resources. All too often, insufficient resources are allocated to the SMS deployment team. Staffing after SMS has been deployed is another area where clients tend to assign too few resources to properly support SMS.

In smaller sites, a single person may fill various SMS roles. Larger organizations might assign several people for certain roles. The size and complexity of your organization’s SMS site hierarchy defines the workforce requirements.


Assemble Your SMS Team

There are several roles and responsibilities to be assigned and delegated for your SMS deployment project. The size and complexity of your organization’s SMS site will determine if roles are assigned to multiple individuals, or if a single individual can fulfill multiple roles.

SMS requires a good understanding of the Windows operating system, Windows NT security, and Microsoft SQL Server. Also desirable are team members who are familiar with your organization’s network infrastructure and security policies.

For a discussion on the roles required for an SMS deployment project, see the Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization," the section titled "Personnel and Time Requirements."

Although written for SMS 1.2, also see the Microsoft Systems Management Server Deployment Project Plan (version 1.2). Many of the issues are still relevant to properly staffing your SMS 2.0 deployment team.

More Information

  • Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server Deployment Project Plan (version 1.2)
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Misconceptions and Misunderstandings


Assign Dedicated SMS Administrators

SMS is a powerful and complex system that touches almost every component in your network: servers, client computers, and the network. You should assign and dedicate several resources as SMS administrators while your organization is learning how to use SMS and how it affects servers, client computers, and the network.

SMS administrators should be dedicated fulltime to the support and operation of SMS. As you grow more comfortable with the product, you might be in a position where the number of dedicated SMS administrators can be reduced. SMS administrators should be trained in the Windows NT operating system, SQL Server, SMS, and thoroughly understand your network environment.

A good reference point for SMS administrator staffing is to look at how your organization may have staffed support for Microsoft Exchange. Most often there are several Exchange administrators, due to the complexity and exposure of e-mail systems within organizations. SMS requires the same level of support to deploy and run SMS effectively.

More Information

  • Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server Deployment Project Plan (version 1.2)
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Misconceptions and Misunderstandings


Document Standards and Procedures

It can be advantageous to delegate SMS functions, such as the creation of new sites in the hierarchy, logon points, distribution points, client access points (CAPs), new queries, collections, software packages, and advertisements. SMS sites are best managed when a consistent approach is used when naming new SMS objects, such as sites, servers, queries, collections, and reports.

You should also document how and why those new objects were created, as well as who created them. This information is beneficial in avoiding duplication of effort and determining which team members might need additional instruction in SMS site management.

More Information

  • Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization"
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Misconceptions and Misunderstandings


Train Helpdesk Staff to Become Familiar with SMS Functions and Capabilities

Helpdesk staff should be provided materials and training that familiarize them with the SMS Administrator console: the site hierarchy, navigation of Microsoft Management Console (MMC), remote tools, generating reports, running queries, resource explorer, and tracking software deployments. Sufficiently trained helpdesk staff get the most benefit from the tools and functionality SMS provides.

Helpdesk staff do not have to be Microsoft SQL Server experts, but it is beneficial if they are familiar with Windows NT, SMS, and the corporate network environment.

Helpdesk staff should also have documented procedures for escalating SMS issues to the central SMS team.

You might consider training offered by Microsoft. For information on training programs available from Microsoft, see
Microsoft TechNet - IT Training & Certification

More Information

  • Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server Deployment Project Plan (version 1.2)
  • Microsoft TechNet - IT Training & Certification
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Misconceptions and Misunderstandings


Create a Plan for Resolving Issues at Remote Sites

Remote sites may not have onsite SMS personnel ready to address SMS-related issues. You should ensure clients at those sites have documented procedures that describe how to report and escalate issues to the SMS team.

Consider finding some who works at a remote site and who has fairly good computer skills. In the unlikely event SMS-related issues cannot be resolved remotely, this person can be the contact for the SMS team that is working to resolve the issue.

More Information

  • Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization"
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Misconceptions and Misunderstandings
  • Microsoft Systems Management Server Deployment Project Plan (version 1.2)


Centralize the Development and Management of Software Packages

Application developers and third-party software vendors usually do a good job of creating setup programs. However, creating packages for distribution to wide audiences may be a task best limited to a small, focused group who are familiar with SMS and software distribution tools. Most setup programs do not take network bandwidth or user-rights into consideration. They often assume the setup program is being run from a local CD-ROM drive, and that the user has sufficient rights and privileges for the installation to be successful. Setup programs often let users customize the installation, choose installation directories, and select which components get installed and which do not.

In an SMS environment, the SMS team may not want to give users the option of customizing software as it is installed. The SMS team should address issues presented by the organization’s security policies. As an example, the SMS team may want to create and distribute a package that installs regardless of the permissions and rights assigned to the logged-on user.

SMS software distribution works best when a common style of installation is consistent for most packages, allowing users to become familiar with the software distribution routine.

Other benefits of this approach to managing software distributions through SMS include ensuring that packages are scanned for viruses and that packages are thoroughly tested within the framework of SMS distributions.

More Information

  • Microsoft Systems Management Server 2.0 Administrator's Guide – Chapter 3 "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server Deployment Project Plan (version 1.2)
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Misconceptions and Misunderstandings


Security Issues

Before you implement Systems Management Server (SMS), it is recommended that you do an in-depth analysis of your environment to determine how you will use SMS. You should especially consider issues that could affect security. This includes analyzing the security risks that might be relevant to SMS and assessing the organizational and technical environment that SMS will run in.

SMS is extremely flexible when customizing it to fit into an organization’s security model. However, complexities surrounding possible network configurations require that thorough tests be performed to ensure your SMS design plans allow SMS to function securely within your network’s framework. You must test issues regarding the Windows NT domain model used in your organization. Your decision on which domain SMS is installed in will also require thorough testing. Also, you must test any optional accounts you create and any permissions delegated to support staff.


Read the SMS Security Essentials Technical Paper

The SMS Security Essentials technical paper is probably the most important single resource regarding SMS and security. This comprehensive resource describes how SMS deployments are affected by the security policies of your organization and how SMS can be configured to accommodate the most secure networks.

The technical paper is exhaustive in supplying information administrators must understand in order to effectively deploy SMS 2.0. The SMS Security Essentials technical paper discusses how the various Windows NT domain models affect your deployment plans for SMS. It discusses the SMS security model, how SMS creates accounts for its use, and how you can create your own accounts to increase security within your organization. The document also contains tables that describe the various accounts created by SMS, and their uses.

The SMS Security Essentials technical paper is a must read for administrators planning SMS deployments for their organizations, as well as those who have already deployed SMS and are looking for ways to increase security.

More Information

For additional information, refer to the following resources:

  • Domain Models and Windows NT Server Directory Services
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • Systems Management Server - Home Page


Review Your Organization’s Current Security

You should consider your organization’s security policies when you develop SMS security policies. You should also consider the particular issues and risks that a computer management system introduces. Your SMS security policies must reflect your organization’s tolerance for security risk, which is often governed by the nature of your organization’s business and its culture.

SMS 2.0 is implemented with a combination of technologies. Those technologies provide a rich security environment for SMS. You must understand the security details of each technology in order to understand their relationship to SMS and how they might affect access to or from SMS. These technologies include:

  • Windows NT security
  • SQL Server security
  • Windows Management Instrumentation (WMI) security

For an in-depth discussion on SMS security issues, see the SMS Security Essentials technical paper.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Document Your SMS Security

Documented policies and procedures are beneficial for any system, but they are especially appropriate for computer security systems. By documenting your organization’s computer security policies and the procedures that you will use, all relevant staff and managers can have an opportunity to review those policies and procedures in a systematic way. This ensures that any missing details are added, any weak points are strengthened, and any unnecessary parts are removed. This also gives all staff the opportunity to be fully aware of the policies and procedures. Thus, in the future, there will be no question about whether an abuse of a system was due to ignorance of those published security policies and procedures.

It is useful to keep a set of documentation for each SMS site in your hierarchy. The documentation should include details, such as the name of the domain where SMS was installed, any optional accounts created and what their purpose is, and any changes to rights and permissions required for SMS accounts. You should also document the rights and permissions granted to support staff that allow them to use SMS.

For an in-depth discussion on SMS security issues, see the SMS Security Essentials technical paper.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Password Settings for Created Accounts

All SMS account passwords are encrypted, either by Windows NT or SMS. Also, account passwords that SMS creates are randomly generated. Encryption of all SMS passwords and the random generation of passwords that SMS creates maximizes security because it results in strong passwords that are not exposed. For this reason, and to minimize the potential for account lockouts, always leave the accounts' Password never expires option enabled for SMS accounts, and do not change the passwords on accounts that are managed by SMS.

In all cases, if you choose to modify the accounts used by SMS, you must conduct tests in your SMS lab to ensure the changes you plan to make do not introduce any unforeseen problems. SMS is extremely flexible when customizing it to fit into an organization’s security model. However, the complexities surrounding possible network configurations require that thorough tests be performed whenever SMS accounts are changed.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Consider Minimizing Use of the SMS Service Account

To minimize the use of the SMS Service account, create and specify accounts in addition to those created by SMS Setup. You can use these additional accounts to increase security by granting privileges on a more granular basis, thus minimizing the risk to all SMS processes if the security of a single account is breached. However, these additional accounts also increase the administrative workload required to plan for and manage security-related tasks.

The following are optional accounts that you can specify in place of the SMS Service account, to maximize security:

  • Site System Connection (Windows NT, NetWare NDS, or NetWare Bindery)
  • SMS Site Address (for parent-child sites)
  • Client Connection (Windows NT, NetWare NDS, or NetWare Bindery)
  • SMS Windows NT Client Software Installation
  • SMS Client Remote Installation
  • SQL Server (for both SMS and the software metering databases so that sa is only used for system administration)

In all cases, if you choose to modify the accounts used by SMS, you must conduct tests in your SMS lab to ensure the changes you plan to make do not introduce any unforeseen problems. SMS is extremely flexible when customizing it to fit into an organization’s security model. However, the complexities surrounding possible network configurations require that thorough tests be performed whenever SMS accounts are changed.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Limit Physical Access

The higher the privileges of an SMS account and the greater the number of processes accessed by the account, the more important it is to limit physical access to the computer that the account runs on or is used from.

When you plan the physical location of the site server, client access points (CAPs), distribution points, and logon points, consider the accounts running on each computer and the privileges granted to those accounts. For example, if your CAPs and logon points are located in a smaller branch office that has minimal security, you should take additional steps to restrict physical access to those computers.

You should restrict physical access to the site server computer and the computer that is running SQL Server. Also, limit access to the SMS Service account and the SQL Server account to as few administrators as possible.

It's important to follow these precautions because the SMS Service account and the SQL Server account have site-wide access. By restricting access to these accounts, you minimize the number of times you must change SMS passwords to provide the appropriate level of security.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Use NTFS Security to Maximize Security

When you design your sites, you should remember that CAPs, logon points, and distribution points require NTFS partitions. This is so that NTFS security can be used to secure the SMS file structure from unauthorized users.

You must also ensure when configuring security on files and folders that SMS processes have access where required.

Consider replicating your network environment and testing changes to share and NTFS file level permissions to ensure no service interruptions are introduced due to those changes to security.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Use the Security Rights Item in the Administrator Console

With SMS 2.0 Service Pack 1 (SP1) and later, the SMS Administrator console includes context-sensitive menu options. You can use these to clone specific accounts or to manage users. (This includes adding, removing, or modifying all rights for a specific user.) These options greatly simplify security rights management.

Users who do not have permissions for various object type classes or instances do not see those objects in their Administrator console. Users who have partial permissions for Administrator console items see only those items for which they have permissions.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Configure SQL Server to Use Standard Security

Copy the sa account to another name (such as SMSsa), provide a strong password for this account, and do not publicize it. Use this account when you are setting up SMS. You should restrict the use of the sa account.

SQL Server administrators, including SMS administrators who need to access SQL Server, must have appropriate privileges through their personal privileged accounts. This creates accountability.

Standard security mode for SQL Server requires that a Windows NT account and password be supplied when connecting to the database. In integrated security mode, the user attempts to connect to SQL Server based on the user's network ID. Mixed mode means the user can connect using either standard or integrated security modes. By implementing standard security, you can better manage who has access to the SMS site database. However, standard security does require a higher level of administrator intervention.

If you choose to use either integrated or mixed security modes, you should audit which user accounts have administrative privileges on the computer running SQL Server. Failure to do so might compromise the security of the SMS SQL Server database.

For additional information on SQL Server, see
Microsoft Servers - Learning Resources for IT Professionals - SQL Server 7.0 - Microsoft BackOffice.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Install SMS on Member Servers of a Domain

Installing SMS on domain controllers is not recommended. Instead, consider installing SMS on member servers. This allows you to put SMS accounts in the local Security Accounts Manager (SAM) database, rather than in the domain SAM database. If you choose to implement strong security for your domain accounts, SMS remains unaffected. For example, if your security policy dictates that all passwords must expire on a regular basis, the SMS accounts that exist within the local account database of a member server would be unaffected.

When you plan your SMS deployment, you should test the security model used in your organization, and determine how SMS is best installed into that structure. SMS is extremely flexible when customizing it to fit into an organization’s security model. However, the complexities surrounding possible network configurations require that thorough tests be performed.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Create a Single SMS Service Account

Use this single account as the service account for all sites. Make the SMS Service account a local Administrator account on the site servers; do not make it a member of the Domain Admins group. If there are sites in other non-trusting domains, set up an SMS Service account for each of these domains.

Using a single SMS Service account helps to minimize the number of accounts required for SMS, and therefore minimizes your password management tasks. However, it does increase security risks because if the account is compromised at one site, it is compromised at all sites. Also, if you need to change the account password for one site, you will have to reset all sites.

In all cases, if you choose to modify the accounts used by SMS, you must conduct tests in your SMS lab to ensure the changes you plan to make do not introduce any unforeseen problems. SMS is extremely flexible when customizing it to fit into an organization’s security model. However, the complexities surrounding possible network configurations require that thorough tests be performed whenever SMS accounts are changed.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Monitor and Audit SMS Security

Windows NT security auditing is a powerful method for monitoring security. In order to enable Windows NT security auditing, you must use User Manager, select the appropriate computer or domain, and then set the appropriate audit policies. To adjust the audit policies, use the Audit option in the Policies menu of User Manager.

Enabling failure events is sufficient for most purposes. Enabling success events provides many details on SMS activity, but it also consumes considerable computer resources.

After you have enabled Windows NT security auditing, watch the security event log for events that are related to SMS. Check closely any failures that involve SMS accounts or resources.

More Information

For additional information, refer to the following resources:

  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – “Creating Your SMS Security Strategy”
  • Microsoft Security Home Page
  • Microsoft Systems Management Server version 2.0 Resource Guide
  • Windows NT Server 4.0 Technical Details


Sizing Systems Management Server Site Servers

The hardware required to adequately and reliably provide System Management Server (SMS) services largely depends on the functions that the server will provide. To efficiently determine the server's hardware requirements, you should first define the server's functionality, review reference material from Microsoft, and perform tests simulating expected loads.


Review the Administrator's Guide and the Resource Guide

A good starting point in determining hardware requirements for your primary site servers is to read Chapter 3, "Planning for SMS in Your Organization," in the Microsoft Systems Management Server Administrator's Guide.

You should also read Chapter 2, "Designing Your SMS Site Hierarchy and Running the Pilot Project," in the Microsoft Systems Management Server Resource Guide, which is found in the Microsoft BackOffice 4.5 Resource Kit. This chapter includes results from Microsoft's scalability lab testing, indicating what size computer is needed to handle certain types of loads. Other helpful subjects in this chapter include information on using specific tools to analyze performance and adjusting servers to improve system performance.

The Resource Guide also contains tables that you can use as a starting point for sizing your site systems. For more information, see the section titled "Estimating the Number of Clients and Objects" in Chapter 2 of the Resource Guide.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Read the SMS Server Sizing in an Organization Technical Paper

The Microsoft Systems Management Server 2.0 Server Sizing in an Organization technical paper can serve as a guideline on how to go about sizing SMS servers required for your organization. The paper uses a fictitious company illustrating the issues and resolutions used to fit SMS into their organization.

When trying to determine your hardware requirements and site design, this paper is a good starting point in realizing the issues and complexities faced by most organizations when planning an SMS deployment.

More Information

  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization


Check the Hardware Compatibility List

Before you install Windows 2000 or Windows NT on a computer, check the HCL to determine whether the computer is certified by Microsoft as Windows NT compliant and that the computer hardware is listed in the HCL.

SMS runs successfully on a variety of host systems. There are no SMS-specific reasons to run SMS on hardware certified by Microsoft. However, if you do require the assistance of Microsoft Product Support Services, they may insist that your hardware be certified by Microsoft before they can assist in resolving your issue.

For the latest information, see
Q131303-Latest Windows 2000/Windows NT Hardware Compatibility List (HCL)

More Information

For additional information, refer to the following resources:

  • Microsoft Windows Hardware Compatibility List
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page


Plan Your Hard Disk Resources Wisely

Within the site servers, you can usually add memory as required, and perhaps additional processors, but it is difficult to add free disk space to the disk subsystem if you have planned poorly.

Available disk space is impacted by the size of growing SMS site databases, software distribution packages, hardware and software inventory files, and any files that you may be collecting.

If you plan your site server disk space requirements accurately, you should not find yourself in a situation requiring the removal and reinstallation of a site server, simply to increase the server’s disk resources.

You might consider hardware-based small computer system interface (SCSI) Redundant Array of Inexpensive Disks (RAID) controller disk subsystems that support dynamically expanding disk volumes by adding disks to an existing array of hard drives. SCSI disk subsystems can provide other benefits as well, including caching features, enhanced throughput, and fault tolerance. While SMS site servers do not require RAID controllers, they do provide measurable advantages.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Consider Using SCSI RAID Disk Subsystems

Hardware-based SCSI RAID controllers provide redundancy in the event of disk failure. Moreover, they can also improve system performance when implemented. Many SCSI controllers provide read/write caches that can greatly reduce CPU usage during times of stressed load. SCSI RAID controllers also spread read/write operations across multiple disks, and thus improve disk access times.

The following is a good SCSI implementation plan for a site server:

  • Channel 1 - 4 volume RAID5 array for the SMS SQL Server database.
  • Channel 1 – 2 volume RAID1 array for the Windows NT System Files, the SQL Server Master database, and the systems virtual memory paging file.
  • Channel 2 – 6 volume RAID5 array for SMS.
  • Channel 2 - 2 volume RAID1 array for the SMS SQL Server transaction log (Write cache disabled).

Medium-sized primary sites (1,000 — 5,000 clients) might see disk I/O as a bottleneck. Large primary sites (20,000 — 50,000 clients) might see disk I/O as a bottleneck. For these reasons, you should separate hardware volumes and channels for performance with a SCSI RAID controller.

While the use of high-end SCSI controllers and disks is highly recommended, your budget limitations might prevent the feasibility of this. However, SMS works perfectly well on current integrated device electronic (IDE) drives. While IDE drive subsystems are not as recoverable, they can perform adequately.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Host the Site Server Database on the Site Server

Performance is better if the SMS site server and SQL Server are on the same computer, provided the computer has sufficient memory, CPU capacity, and disk I/O capacity to handle it. Running SQL Server on a remote computer benefits your organization only if SQL Server is being used for other applications.

If you must have SQL Server installed on a remote computer, you should analyze the intervening network connection to ensure that a high-availability, high-bandwidth network connection is in place. You might consider installing a second network interface card (NIC) in both the site server and the computer running SQL Server, and then dedicating this second card for communications between the site server and the computer running SQL Server.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Consider a Software Metering Database Server

Software metering can have an impact on the performance of your site server. If you plan to maintain your software metering database on a computer other than the site server, you must install SQL Server on the computer that will host the software metering database before installing SMS 2.0. By default, SMS Setup automatically installs the Software Metering Server Service on the server running Windows 2000 or Windows NT that hosts the software metering database.

If you choose to use your site server as a software metering server, you might consider adding additional processing and memory resources to your configuration.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Create Multiple Logon Points, CAPs, and Distribution Points

Any SMS site server where the SMS Executive service is run defines a “component server.” Distribution points and client access points (CAPs) do not classify as component servers because neither of these roles requires the SMS Executive service to be installed and running. It is important to note, however, that site servers (servers where the SMS Executive service is running) can also serve the CAP and distribution point roles.

In SMS 2.0, it is not usually necessary to move components from the site server to component servers. However, it is good practice to configure all domain controllers as logon points, and to create multiple CAPs and distribution points.

By placing additional CAPs and distribution points on the network, you are effectively spreading the load of these functions, as well as providing redundancy in the event one of these systems should fail.

You need to be aware that SMS clients select CAPs and distribution points randomly. If your site spans slow network links, you might find some clients connecting to servers across those slow links even though there are other servers located on the high-speed network.

The Back Office Resource Kit utility called Set Preferred CAP and Distribution Point (Prefserv.exe) can be used to specify the preferred CAP and distribution point for a client. For information regarding this tool, see the following Knowledge Base articles:
Q205406: Client Access Point and Distribution Point Selection
Q235873: Specifying Preferred Servers in Systems Management Server 2.0

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Q205406: Client Access Point and Distribution Point Selection
  • Q235873: Specifying Preferred Servers in Systems Management Server 2.0
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Reduce the Frequency of Hardware and Software Inventories

You can reduce the load on your clients, network, CAPs, and site servers by reducing the frequency of software and hardware inventories. However, reducing inventory frequencies requires you to balance your inventory reporting requirements and acceptable server load. Effects of different inventory frequencies should be tested during your pilot phase.

Also, by phasing the rollout to clients, you can reduce the impact of processing inventory data. Note that when you enable software or hardware inventories, the default simple schedule causes all inventories to be taken at midnight on the scheduled day. SMS inventories computers the day they are installed as clients. By default, SMS schedules these computers to conduct another inventory 7 days later. By staggering the number of clients installed over a few days, you are also staggering the number of clients taking and reporting inventory information on subsequent inventory days. This condition exists in SMS 2.0 Service Pack 2 (SP2) as well.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Install Secondary Site Servers Where Slow Network Links Exist

Clients communicate regularly with logon points, CAPs, and distribution points. It might be that some potential SMS clients are located in networks that do not have high-speed connectivity with the site server, logon points, CAPs, and distribution points.

A secondary site server placed on the remote side of the network, close to those low-bandwidth clients, can solve this problem. If budget limitations are an issue, consider installing secondary site servers on resource servers that might be providing other services. It is better to have clients connect to local site servers that share the load than to have them connect to site servers over slow or saturated network links.

A secondary site server does not require the same resources as a primary site server, because they do not have SQL Server installed locally. For this reason, secondary site servers might be able to share the workload with servers already located close to clients.

If you plan on using this configuration, you should test the impact of applications other than SMS on the secondary site server, as well as the impact that SMS may have on other applications.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Conduct Pilots Simulating Expected Load

To ensure that your servers can handle expected SMS loads, you should review and conduct tests based on Chapter 11, "Configuring and Populating Pilot Sites," in the Microsoft Systems Management Server Resource Guide. This chapter provides extensive information about simulating SMS loads.

Chapter 14, "Using SMS 2.0 Tools—Part 2," is a good supplement to Chapter 11, and even discusses a tool — SMS Console Load Simulation Tool — which simulates the activity of a number of SMS administrators using SMS and the site server.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Clustered Site Servers

Site servers installed on clustered servers is not supported on current releases of SMS 2.0. Microsoft is working to provide support for clustered site servers in future releases of SMS.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Server Sizing in an Organization
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 2 - "Designing Your SMS Site Hierarchy and Running the Pilot Project"
  • Microsoft BackOffice 4.5 Resource Kit
  • Systems Management Server - Home Page
  • Microsoft Windows Hardware Compatibility List


Software Distribution

SMS 2.0 provides a powerful, flexible environment for the distribution of software throughout your organization. A solid infrastructure must be in place before beginning the software distribution process. Software packages may require elevated privileges on the client computer when installing, and they may require access to network resources other than the installation directory. Distributing packages to distribution points may have security implications. This is certainly true when NTFS partitions are used or when multiple domains exist within your organizations network.

For these reasons, software distribution should be strenuously tested in a lab environment that simulates both your SMS infrastructure and the security context in which the package will run on client computers.

Windows 2000 Active Directory services offer the ability to distribute software using group policies. This is the only area where some overlap between Windows 2000 and SMS 2.0 exists. On these pages you will find a discussion of that overlap, and how to decide which software deployment strategy best fits your organization.


Place Distribution Servers Close to Clients and Consider Multiple Distribution Points

Installing software on clients can cause significant amounts of network traffic as the setup program installs files on the client computers. Setup programs may sometimes fail to complete when files take excessively long to install on clients. To reduce the risk of incomplete installations, and to minimize elapsed time to install software, you should ensure that all clients have distribution servers available across high-availability, high-bandwidth network links.

You can also improve distribution server response by placing additional distribution point servers on the network to spread the load among multiple computers. The SMS Advertised Program Manager randomly selects distribution points from the list of available distribution points for the clients’ site. This selection process provides redundancy if a computer serving as a distribution point fails. The remaining distribution point servers can provide the service until the failed server is restored. You should also consider the additional administrative tasks that may be introduced by adding distribution point servers.

The Back Office Resource Kit utility called Set Preferred CAP and Distribution Point (Prefserv.Exe) can be used to specify the preferred client access point (CAP) and distribution point for a client. For information regarding this tool, see the following Knowledge Base articles:
Q205406: Client Access Point and Distribution Point Selection
Q235873: Specifying Preferred Servers in Systems Management Server 2.0

More Information

For additional information, refer to the following resources:

  • Q205406: Client Access Point and Distribution Point Selection
  • Q235873: Specifying Preferred Servers in Systems Management Server 2.0
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Systems Management Server


Ensure Site Servers and Distribution Points Have Sufficient Free Disk Space

Within a single site, when you choose distribution points for your software distribution, and the package contains source files, SMS copies the package source files to the distribution point uncompressed.

When a distribution point in a child site is first added to a package's distribution point list, the package source files are compressed and sent to the child site's site server. On the child site server, the source files are then decompressed and copied to the specified distribution points in that site. Compressed source files are kept at the parent and child sites. If a new distribution point in that site is specified for the package, the child or parent site server again decompresses the package source files and copies them to the new distribution point.

This may result in a disk space requirement of up to 3 times the size of the package source files, if the source files are kept on a site server where the package is created and distributed. A child site server receiving a package may require up to 2 times the size of the package: the compressed version, plus the uncompressed version to be copied to distribution points. Servers acting as distribution points require only enough free disk space to hold one copy of the uncompressed package source files.

The package distribution process stops when insufficient disk space problems are encountered.

Sufficient disk space must exist at the following locations:

  • The site server where the package is created.
  • Any site servers that receive the package.
  • Specified distribution points.

Disk Space Requirements Explained

The following table describes how to estimate disk space requirements on SMS site servers and distribution points when creating and distributing a package through SMS

Table 1

Server Usage | Disk Space Requirement Calculation
Site server where package is created, and is also a distribution point for the Package. | Disk_Space_Required = Size_Of_The_Package + Decompressing_Temp_File + Compressed_Package
Site server where the package is created, and is not a distribution point for the package, but does have at least one distribution point below it in the SMS hierarchy. | Disk_Space_Required = Decompressing_Temp_File + Compressed_Package
Distribution point on a server that is not also a site server. | Disk_Space_Required = Size_Of_The_Package

Compressed Package File Notes

When is compressed package deleted?

If Always obtain files from source directory is enabled, then the compressed package is deleted after it is decompressed to distribution points, and sent down to all reporting sites.

If Use compressed copy of source files is enabled, then the compressed package is not deleted until the package is deleted.

What kind of compression ratio is obtained?

Package compression ratios are roughly 75%. Actual compression ratios are highly dependent on the type of file being compressed. For example, text and database files will gain approximately 25% compression ratio.

How many temporary decompressing files might exist at one time?

There can only be as many temporary decompressing files on the site server as the number of threads software distribution is allowed. This option can be configured using the SMS Administrator console.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Systems Management Server


Establish Firm Control Over the Software Distribution Process

The administration of software packages requires setting standards for how packages are developed, how they are tested, how they are distributed, and how distributions are monitored. The administrator should put procedures in place to ensure packages are developed according to standards, that testing and signoff procedures are being followed, and that the software distributions are managed in a controlled fashion.

Establish Package Standards

SMS packages and advertisements are most successful when a strict set of rules for the development and testing of them is in place. Clients more readily accept package advertisements when a pattern of the software distribution process becomes familiar to them.

A series of poorly tested programs, or packages installations that appear radically different from others, can cause users to distrust the SMS software distribution process.

Providing a framework for software package and advertisement developers and managers to follow should streamline the package development process, making life easier for developers, clients, and the SMS administrator.

Rigorously Test All Packages

SMS is the delivery mechanism for software distribution. SMS makes the installation files available on distribution points and launches a command line to begin the installation process. SMS cannot ensure that your programs will run after you distribute them. You must set up a lab environment and test your software packages before you finalize your software distribution. The lab environment should include resources that allow you to simulate your organization’s infrastructure (network, site hierarchy) as well as client desktop configuration (the various operating systems, service pack levels, and software already installed).

The following tests must be done to ensure a successful software deployment:

  • Test the programs by running them at a test computer.
  • Test the distribution itself by creating a test package, then have SMS copy the package to the distribution points. Create a test advertisement, and then execute the program commands you previously tested on the development computer from a client.
  • Do a sample distribution of the tested packages to a child site and execute the program commands on a client of the child site.

Rigorous testing should go beyond testing the package and conducting your lab tests. For distributions going to thousands of clients, rigorous testing could involve 100’s of test computers. Such elaborate testing facilities may be beyond many project budgets, both in time and money. An alternative used by many successful organizations is to begin the package distribution process by advertising to a small client group. If all goes well, advertise the package to a moderately larger audience, and continue this process until the package is distributed. The idea here is to widen the distribution in chunks, stopping and correcting any problems as they are encountered.

Ensure Security Issues Are Tested

A user may not have sufficient privileges to install software on their client computer. In addition, software can be advertised to systems rather than users, in which case the systems security context must be considered. Some software requires administrative permissions to install and start services. In these cases, you might configure the program to run with administrative permissions by using a local administrative account. This option could also fail if the advertised program requires access to network resources other than the local computer or the distribution point folder from which it is executed.

The Advertised Programs Manager can be configured to use the SMS Windows NT Client Software Installation account to support advertised programs on Windows NT clients that require a special security context.

You must create the SMS Windows NT Client Software Installation account manually. Because this account is used to gain access to network resources required by the programs that are part of a package, you should:

  • Create the account as a domain account.
  • Give the account the rights needed to access the required network resources.
  • Thoroughly test packages to ensure security requirements are met.

For information on how to specify the SMS Windows NT Client Software Installation account, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software," the section titled "Optional Configuration of the Software Distribution Component."

Create a Master Package Location

The SMS administrator should store all packages ready for distribution in a managed network location. All packages and advertisements should be created from the managed network location. This ensures that packages have gone through the proper testing procedures and that no further changes are made to package source files without the SMS administrator’s knowledge. For information on securing who has permission to distribute software, see Using SMS Object Security to Control the Use of SMS Features.

In addition, it is extremely important that anti-virus software is installed on the servers where packages are stored (the managed network location, as well as all distribution points). Virus lists should be routinely maintained on these source locations to minimize the threat posed by computer viruses.

You must ensure this master source location is accessible to the site server where the SMS package is created. The SMS processes that compress and distribute packages through your SMS hierarchy must be able to access package source files.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Systems Management Server
  • SMS Security Essentials
  • Using SMS Object Security to Control the Use of SMS Features


Consider SMS Installer to Develop Software Packages

SMS Installer is a utility included with SMS 2.0. SMS Installer allows a package developer to install a package on a computer that represents the client base. SMS Installer compares the changes made to the computer before and after installation, and creates a self-extracting executable (*.exe). This single executable file can then be distributed through the SMS hierarchy and made available to clients. When run on client computers, the SMS Installer executable creates and installs files and directories, and makes required changes to the Windows registry. The result is the user now has the package installed.

SMS Installer packages can also improve package status reporting by creating Management Information Format (MIF) files. Software distribution programs can generate MIFs to supply information about the success or failure of their execution on 32-bit clients.

SMS Installer is best suited to setup programs that do not use Microsoft Windows Installer technology. Windows Installer applications record the source location from which their Setup was launched, and retain this information for Windows Installer features such as “Install on first use,” or “automatic file repair.” In addition, Windows Installer applications may contain logic for removing older versions of a package. The removal of previous versions is difficult for SMS Installer to script. A SMS Installer self-extracting executable intended for distribution to a wide audience impacts this function of Windows Installer applications. SMS Installer can still be used as a “wrapper” program to initiate a Windows Installer setup, when complexities in the package require that.

For more information on using SMS Installer, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0."

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Q168776 - SMSINST: Using the Repackager Successfully
  • Windows Installer Features
  • Support WebCast: Upgrading Windows Installer-based Applications
  • Deploying Windows Installer Setup Packages with Systems Management Server 2.0


Consider Using the Distribute Software Wizard

The Distribute Software Wizard simplifies the complete software distribution process. With this wizard, you can accomplish all the steps needed to distribute software. More advanced SMS administrators may choose to create and manage package creation and advertisement using the SMS Administrators console once they become familiar with the steps necessary. You can use this wizard to do the following individual software distribution-related tasks:

  • Create a package and program manually
  • Create a package and program from an existing package definition
  • Specify package source file options
  • Specify distribution points for the package
  • Select an existing target collection
  • Create a new collection
  • Add a resource to a new or existing collection of resources
  • Create an advertisement

For an example of how to use the Software Distribution Wizard, see Knowledge Base article Q247949: How to Create a Simple Test Advertisement.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Q247949: How to Create a Simple Test Advertisement
  • Systems Management Server


Monitor the Health and Status of Packages and Distribution Points

Package Status provides a summary report of the health of packages and distribution points in your site. In many organizations, administrators distribute multiple packages concurrently to multiple destinations. Package Status allows you to monitor when packages arrive at distribution points. A package must arrive at a distribution point before a client can access, install, or run an advertisement.

For information on reporting package status, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software," the section titled “Monitoring and Maintaining Software Distributions.”

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Systems Management Server


Consider Time Zones and Time Settings

If you advertise your software package to run at a predetermined time, by default, the program runs at that time within the client's time zone unless you set the package to run at Greenwich Mean Time (GMT). When you create advertisements, consider the effect of time zones on your advertisement. Later, when you monitor a distribution, remember to adjust the time that you expect the distribution to be complete if you have not specified GMT times.

Also, be sure to synchronize the time settings on your site servers, distribution points, and clients, especially if distributions are set to run immediately.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Systems Management Server


Windows 2000 and SMS 2.0 Software Distribution

IntelliMirror is a feature included as part of Windows 2000. When combined with Remote OS Installation, they provide a base set of change and configuration management features for IT administrators to manage their Windows 2000 Professional users through centrally administered policies.

The only area of overlap in Windows 2000 and SMS 2.0 SP2 is in application deployment and upgrades.

The IntelliMirror and Remote OS Installation solutions provide a base set of management features that are available with the Windows 2000 platform. SMS 2.0 adds centralized hardware and software inventory, remote diagnostic tools, software metering, support for clients running Windows NT, Windows 95, or Windows 98, and enhanced software deployment features that will be attractive to or required by customers with advanced requirements.

Advanced software deployment can be characterized by a need to deploy software with the following capabilities:

  • WAN-sensitive distribution
  • Inventory-based targeting
  • Status reporting
  • Scheduled installations

If your organization has advanced software deployment requirements, SMS 2.0 provides features and functionality that may be better suited to your advanced requirements than IntelliMirror.

SMS is an excellent platform to keep applications and operating systems up-to-date by distributing service packs and product updates, as required. SMS is also useful when deploying operating system upgrades (such as upgrading Windows NT 4.0 to Windows 2000). However, if you are planning to format the hard disk of a client and install a completely new operating system, SMS is probably not the mechanism to use.

For an in-depth discussion on SMS 2.0 software deployment in a Windows 2000 environment, see Software Deployment Using Windows 2000 and Systems Management Server 2.0.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 11 – "Managing Collections and Queries"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 12 – "Distributing Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 13 – "Creating Self-Extracting Files with SMS Installer 2.0"
  • Using Systems Management Server to Deploy Windows 2000
  • Understanding the Value of IntelliMirror, Remote OS Installation, and Systems Management Server
  • IntelliMirror, Remote OS Installation, and Underlying Management Technologies
  • Systems Management Server
  • Using Systems Management Server to Deploy Windows 2000
  • Software Deployment Using Windows 2000 and Systems Management Server 2.0
  • Automating Windows 2000 Deployments with Sysprep


Software Metering Strategies

Software metering provides the ability to track, record, and report software usage within an SMS site. You can use online mode to provide real-time control of software usage based on license availability.


Install Software Metering Servers Before Enabling Software Metering Client Agents

To avoid client error messages referencing registry entries, you should install a software metering server before enabling the Software Metering Client Agent. When the client agent is installed, registry entries are created that provide a list of software metering servers that are available.

If a client agent is enabled before any software metering servers are created, these registry entries will not be there, causing the client agent to produce error messages when starting.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering
  • Q198706 - Software Metering Components on the Client


Install Additional Software Metering Servers

Clients require fairly quick response from software metering servers. This is especially true when clients are in online mode. To ensure that clients receive a quick response, you should consider installing additional software metering servers.

Software meters servers do not have to be high-end servers. They are not required to run SQL Server. Software metering servers maintain a local database. The SMS site server forwards usage statistics from the software metering servers to the software metering database server.

Software metering servers, however, benefit from additional physical memory and fast disk subsystems. How many additional software metering servers you will need depends on your requirements and your network infrastructure. You should create a lab environment simulating your production network and load, and test your software metering environment to best determine your requirements.

See Knowledge Base article Q263023 – SMS: Information on Scaling Software Metering.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering
  • Q198706 - Software Metering Components on the Client


Configure the Software Metering Service Account

Software metering servers get user group membership details from domain controllers. This fails when software metering servers are set up with the default Software Metering Service account, unless the software metering server is a domain controller. This is because the software metering account is created as a local Administrator account only. To avoid this problem, ensure the software metering account is a member of the Domain Administrators global group.

Use the SMS Administrator console to change the Software Metering Service account and password. Do not use User Manager in Windows NT, or Active Directory Users and Computers in Windows 2000. The SMS Administrator console changes the password for both SMS and the domain.

For information on how to configure the Software Metering Service account, see the Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy," the section titled “SMS Remote Site System Service Accounts.”

For a complete understanding of SMS accounts and security issues, see the SMS Security Essentials technical paper.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 4 – "Creating Your SMS Security Strategy"
  • SMS Security Essentials
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering
  • Q198706 - SMS: Software Metering Components on the Client.


Consider Using Offline Mode Software Metering Clients

Use software metering clients in online mode only if you must have the ability to shut down programs or prevent applications from starting when licenses are not available.

In offline mode, the Software Metering Client Agent forwards usage data to the software metering server on a periodic basis. Offline mode is for passive monitoring of software license usage. In offline mode, you can deny the usage of programs by setting the permitted hours of usage to 0 hours per day.

In online mode, every request to start a non-excluded program requires that the client agent contact the software metering server. You can use online mode to actively control and manage software access for users, user groups, or computers. Online mode operates in real time. When you configure software metering, select the Force real-time license verification check box to turn on online mode.

You should be aware that online mode significantly reduces the number of clients that an SMS software metering server can support. Servers that support clients running in online mode must be able to support peak usage requirements. Servers that support clients running in offline mode only need to process backlogs in reasonable amounts of time. You should expect to deploy additional software metering servers if online mode is enabled.

In online mode, it is much more critical that the software metering server is not connected to the clients by a slow or unreliable link. It is important to remember that in online mode, every request to start a program requires that the client agent contact the software metering server.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering
  • Q198706 - Software Metering Components on the Client


Calculate Trends Before Enforcing License Limits

When licensing new products, the Do not enforce license limits for this product until a trend has been calculated check box is selected by default. When selected, SMS software metering does not issue denials until a trend has been calculated, which takes 7 days for standalone applications, and 14 days for suite applications.

If you clear this check box, a large number of requests might be denied because license balancing is not fully functional until a trend has been calculated. If this option is not enabled, denials might start immediately since you are enforcing licensing before trends have been calculated.

Calculating trends allows the license balancing functionality of SMS to determine which software metering servers require the most licenses, which software metering servers require the least, and then move licenses from server to server accordingly. Until trends have been set, license balancing has no information on which to move licenses around, which may result in license denials.

For information on troubleshooting license balancing, see Knowledge Base article Q210202: Software Metering Servers Not Balancing Licenses Correctly.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q210202: Software Metering Servers Not Balancing Licenses Correctly


Consider Increasing the Configuration Polling Interval to Reduce Network Traffic

By default, every 4 hours (240 minutes), software metering clients download settings from the software metering server, including a list of all excluded programs. This is also when the offline log file is sent from the client to the software metering server. Unless the list of excluded programs or the software metering settings are changed often, you can reduce some network traffic caused by software metering. You should consider setting the polling interval to 480 minutes or longer. However, if you are making regular changes to the software metering settings and do not want to increase the polling interval, make sure the network bandwidth is sufficient.

You should test different polling configuration intervals in a lab environment before making changes to your production network.

The configuration polling interval is configured by editing the properties of the Software Metering Client Agent.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering


Schedule Data Summarization

The software metering database will continue to grow unchecked unless data summarization is enabled. Data summarization condenses detail records in the database based on the age and granularity that you specify. The detail records are then deleted.

Data summarization displays a general record of programs used over the selected period. Because the detail records are deleted, you should choose a level of summarization that is appropriate for your requirements.

Data summarization is configured when editing the properties for the Software Metering component configuration.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering


Register and Exclude Programs to Reduce Client and Network Load

When a program is started, the Software Metering Client Agent first checks to see if the program is excluded. The configuration polling interval determines when the list of excluded programs is downloaded to clients. If the program is on the excluded programs list, then the program simply starts. In this case, no network bandwidth is utilized. If the program is not on the excluded programs list, the Software Metering Client Agent records the usage for clients in offline mode, and sends this usage information to the software metering server on a specified schedule.

Clients in online mode attempt to directly connect the software metering server to request a license. By excluding registered programs, you can significantly reduce network traffic, particularly for clients in online mode.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering
  • Q198706 - Software Metering Components on the Client


Locate Software Metering Servers Close to Clients

Software metering clients communicate regularly with their software metering servers. This is especially true with clients in online mode, which must contact the software metering server when any non-excluded program is started. Clients connected to the software metering server by a slow, saturated, or unreliable link can experience delays.

You can avoid this issue by placing a computer on the client LAN and designating it as a software metering server. This computer must only meet the minimum server requirements for SMS site systems. The following are the minimum recommendations for a software metering server:

  • Computer with an Intel Pentium 200 or later processor (Pentium III 500mhz recommended)
  • Microsoft Windows NT Server 4.0 (Service Pack 4 or later)
  • 128 MB of RAM (256 MB recommended)
  • 1 GB of available hard disk space
  • VGA or higher resolution monitor

For more detail on scaling software metering servers, see Q263023 – SMS: Information on Scaling Software Metering.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering
  • Q198706 - Software Metering Components on the Client


Consider RAM and Disk on Software Metering Servers

Tests show that software metering servers do not benefit much from high-end or multiple CPU configurations. They do benefit, however, from addition physical memory and fast disk subsystems.

Software metering clients can be configured to operate in one of two modes: online or offline. If you configure SMS clients to run in online mode, you must provide software metering servers that have sufficient capacity to respond in real time. For clients running in offline mode, the software metering server capacity must be sufficient enough to process, in a timely manner, a backlog of metering usage information.

Reporting requirements are a key element in determining what an acceptable backlog is. If you require software usage statistical reports on a bimonthly basis, then a backlog of one week would be acceptable. If daily usage statistic reports are required, then very little backlog is acceptable.

The following are the minimum recommendations for software metering servers:

  • Computer with an Intel Pentium 200 or later processor (Pentium III 500mhz recommended)
  • Microsoft Windows NT Server 4.0 (Service Pack 4 or later)
  • 128 MB of RAM (256 MB recommended)
  • 1 GB of available hard disk space
  • VGA or higher resolution monitor

You can use the following guidelines to determine how many software metering servers you will require per site. These guidelines apply only to software metering servers that handle clients that are running in offline mode. These guidelines also assume that you are using a fast network.

1,250 clients | 1 software metering server
5,000 clients | 4 software metering servers
10,000 clients | 8 software metering servers
20,000 clients | 16 software metering servers
40,000 clients | 32 software metering servers

Software metering servers that handle clients running in online mode require significantly more servers. In order to determine how many more servers, you need to set up a stress test in your lab simulating expected loads.

Note

  • NetWare and Alpha-based servers cannot perform the software metering role.

For more detail on scaling software metering servers, see Q263023 – SMS: Information on Scaling Software Metering.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 14 – "Metering Software"
  • Microsoft Systems Management Server 2.0 Resource Guide, Chapter 22 – "Software Metering Flowcharts"
  • Microsoft BackOffice 4.5 Resource Kit
  • Microsoft Support Knowledge Base
  • Q263023 – SMS: Information on Scaling Software Metering


SQL Server Strategies

The definition of a Systems Management Server (SMS) primary site server includes a SQL Server SMS site database. The SQL Server SMS site database can be located on the same computer as the primary SMS site server, or it can be located on another computer where SQL Server is installed. A site server running Microsoft SQL Server cannot host multiple SMS site databases, but it can host databases for other applications. If SQL Server is not installed on a site server, the server running SQL Server can host multiple SMS site databases, as well as databases for other applications.

SMS site servers communicate constantly with the database. Testing shows that sites perform best when the site server and the site database are hosted on the same computer.

When designing your SMS site, you have several options on how to install the server where SQL Server is installed, and is hosting the SMS site database.

SMS 2.0 provides support for both SQL Server 6.5 and SQL Server 7.0 or later.


Use Microsoft SQL Server 7.0 or Later

SMS 2.0 supports both SQL Server 6.5 SP4 and SQL Server 7.0 and later.

If you are upgrading SMS 1.2 sites to SMS 2.0, then SQL Server 6.5 with service pack 4 (SP4) is acceptable. SQL Server 6.5 should NOT be upgraded to SQL Server 7.0 or later before upgrading all your sites to SMS 2.0 SP2.

Because SQL Server 7.0 offers performance and operational improvements, SQL Server 7.0 or later is the better choice for new installations. The SMS site database at a central site can become quite large, and the online backup, automatic query analyzer, and statistics update features are likely to reduce the maintenance time required by SQL Server 7.0 or later.

Although not specifically required by SMS 2.0, it is highly recommended that the latest service pack for SQL Server 7.0 be applied to the computer where the SMS database resides. The latest service packs may improve security or provide other benefits not directly required by SMS 2.0.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base
  • Q199249 - How to Configure SQL Server User Connections for SMS 2.0


Configure Standard Security Instead of Integrated or Mixed

Standard security mode for SQL Server requires that a Windows NT account and password be supplied when connecting to the database. In integrated security mode, the user attempts to connect to SQL Server based on the user's network ID. Mixed mode means the user can connect using either standard or integrated security modes. By implementing standard security, you can better manage who has access to the SMS site database. However, standard security does require a higher level of administrator intervention.

If you choose to use either integrated or mixed security modes, you should audit which user accounts have administrative privileges on the computer running SQL Server. Failure to do so might compromise the security of the SMS SQL Server database.

For additional information on SQL Server, see Microsoft Servers - Learning Resources for IT Professionals - SQL Server 7.0 - Microsoft BackOffice.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base
  • Q199249 - How to Configure SQL Server User Connections for SMS 2.0


Keep SQL Server on the Primary Site Server

SMS and SQL Server communicate constantly. Running SQL Server on a remote computer benefits your organization only if SQL Server is being used for other applications. If you must have SQL Server installed on a remote computer, you should analyze the intervening network connection to ensure that a high-availability, high-bandwidth network connection is in place. You might consider installing a second network interface card (NIC) in both the site server and the computer running SQL Server, and then dedicating this second card for communications between the site server and the computer running SQL Server.

You can significantly increase the performance of SMS if the SMS site database is installed on the same computer that performs the SMS site server role, provided that computer has enough processing power to accommodate both roles.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base
  • Q199249 - How to Configure SQL Server User Connections for SMS 2.0


Designate SQL Server for SMS Use Only

The SMS site database can be hosted on the same computer where the SMS site server is installed; in fact, this configuration is recommended.

The computer running SQL Server, which is hosting the SMS database, can also host other non-SMS databases. SMS and the computer running SQL Server perform best when no other applications are competing for system resources on the computer running SQL Server or the SMS site server.

A badly implemented SQL Server database can experience considerable processing hits when processing queries, updating tables with indexes, or performing other non-SMS related functions. In addition, other applications, which require a large amount of system resources, can adversely affect the site server. SMS requires constant communication with the computer running SQL Server. The performance of other applications is impacted if the applications are trying to access the same computer running SQL Server. This is an area best tested in a lab environment where stress is placed on SMS, SQL Server, and any other applications that might share the computer running SQL Server.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support


Install SQL Server Manually

SMS can automatically install SQL Server for you, if you have the SQL Server installation files on a compact disc or on a shared network location.

To achieve optimum performance, manually install SQL Server, tune as required, and then create the SMS site database and log devices on different disks or RAID arrays prior to installing SMS.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base
  • Q199249 - How to Configure SQL Server User Connections for SMS 2.0


Consider Placing the Software Metering Database on Another Computer

There is a difference between the software metering database server and software metering servers. The software metering database server updates the software metering SQL Server database with statistics gathered by software metering servers. Software Metering Client Agents connect to software metering servers, which, on a schedule, provide usage data for the site server to process into SQL Server.

Software metering can have an impact on the performance of your site server. If you plan to maintain your software metering database on a computer other than the site server, you must install SQL Server on the computer that will host the software metering database before installing SMS 2.0. SMS Setup automatically installs the Software Metering Server Services on the server running Windows NT that hosts the software metering database.

If you choose to use your site server as a software metering server, you might consider adding additional processing and memory resources to your configuration.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base
  • Q199249 - How to Configure SQL Server User Connections for SMS 2.0


Use SCSI RAID Disk Subsystems

Configuring your site servers with RAID disk controllers can achieve significant performance gains. Much of the I/O processing is transferred from the CPU to the RAID controller. This way, I/O operations can be spread among multiple disks that comprise single logical drives. You should make sure that the SMS site database transaction log is on a separate SCSI channel, and that write caching has been disabled so as to ensure system recoverability.

While SCSI devices can provide performance enhancements and increase fault-tolerance, SQL Server runs well on IDE controllers and disks.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base


Adjust SQL Server User Connections

SMS requires at least 50 user connections. Any additional Administrator consoles require an additional 5 connections per simultaneous Administrator console.

Increasing this value can require additional memory because each user connection consumes a portion of available memory. For this reason, configure the user connections setting for SQL Server for only the amount of SMS Administrator consoles that could simultaneously be connected to your site databases.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base
  • Q199249 - How to Configure SQL Server User Connections for SMS 2.0


Consider a Parent Site for Reporting Purposes Only

If SMS is used to produce a large number of reports, and this reporting seems to be impacting system response, consider configuring a “grand-parent” site. The grand-parent site would not have any clients of its own, but would have one or more child sites. The child sites could be a single “central” site, or various child sites in your hierarchy. All clients are assigned to the child sites, and inventory information passed from clients to their sites would flow up the hierarchy. Depending on your SMS site design, information could flow first to a central site and then to the grand-parent site, or it could flow directly from child sites to the grand-parent site. Reports could then be generated from the grand-parent site, reducing any impact on active SMS sites. An advantage of this option is that as you add sites, they can be placed logically in your SMS hierarchy so that the new sites inventory information is reported to the grand-parent site.

Response to the SMS Administrator console can be impacted if reporting is done from the SMS site database. Clients, however, should not notice any performance degradation caused by SQL Server performance because all client communication to the SMS site servers is handled though logon points, client access points (CAPs), distribution points, and software metering servers. If these components have been installed on non-site server systems, reporting functions cause no noticeable delays to clients.

More Information

For additional information, refer to the following resources:

  • Microsoft Systems Management Server 2.0 Administrator's Guide, Chapter 3, "Planning for SMS in Your Organization"
  • Microsoft SQL Server 7.0 Performance Tuning Guide
  • Tuning SQL Server 6.5 for Optimal Performance
  • Microsoft SQL Server Home Page
  • Microsoft SQL Server Support
  • Microsoft Product Support Services Knowledge Base


Upgrading Previous Releases of SMS to SMS 2.0 Service Pack 2

If you have already deployed SMS in your organization, there are some points to be aware of before upgrading your sites to SMS 2.0 Service Pack 2 (SP2). This information describes these points and directs you to more comprehensive information that you should become familiar with before beginning your site upgrades.

The topics provide information on issues surrounding SMS 2.0 SP2 upgrades. Much of the content is specific to clients upgrading from SMS 1.2 to SMS 2.0 SP2. However, it is recommended that you review all topics and consider how they might apply when upgrading earlier versions of SMS 2.0 to SMS 2.0 SP2.

The order of the links is not intended to suggest project plans or priority. Each topic should be reviewed, and the corresponding links and reference material should be read to gain a complete understanding of the issues involved.

The issues important to you will depend on which versions of SMS you are upgrading, and which versions of SQL Server you intend to upgrade.


Plan for Earlier Configurations that are No Longer Supported

There are configurations SMS 1.2 supports that cannot be upgraded to SMS 2.0. For these configurations, consider one of the following options:

  • Upgrade the clients to an operating system that SMS 2.0 supports. (This option applies to MS-DOS and OS/2 clients only.)
  • Maintain one or more SMS 1.2 sites in your site hierarchy to support these clients.

Upgrading clients to supported platforms may not be feasible, in which case you must maintain an SMS 1.2 site in your hierarchy to service these SMS clients.

Configurations that may have upgrade issues include:

  • MIPS processor-based computers
  • Microsoft LAN Manager domains
  • The OS/2 operating system
  • SMS 1.2 SQL Server queries (can be recreated after an upgrade)
  • MS-DOS version 5.0 or later (without Microsoft Windows)
  • IBM OS/2 2.11
  • Macintosh System 7.x
  • Program Group Control (not available in SMS 2.0)

For detailed upgrade information, see the Systems Management Server Version 1.2 to 2.0 Upgrade technical paper, the Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0,” and the SMS Release Notes.

More Information

For additional information, refer to the following resources:

  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Systems Management Server 2.0 Administrator's Guide - Chapter 6, "Installing SMS 2.0 Sites," the section "Preparing SQL Server"
  • How to Use Writeqdf.exe from the BackOffice Resource Kit 1


Apply Windows NT and SQL Server Service Packs

You must ensure that all sites and systems have had the latest service packs applied before beginning your site upgrade process.

Your site servers, and other Windows NT servers running SMS 2.0 server components, must run Windows NT Server 4.0, SP4 or later. The SMS 2.0 compact disc includes SP4 for Windows NT 4.0. The site server should be backed up before the upgrade. Also, make sure to update your emergency repair diskettes.

Any site database computers running SQL Server version 6.5 should have SQL Server 6.5 Service Pack 4 or later installed before upgrading. Do not upgrade SMS 1.2 sites to SQL Server 7.0 prior to the upgrade. Be sure to backup your SQL Server site database before your upgrade.

While not specifically required, it is recommended that computers running SQL Server 7.0 should have the latest service packs applied before initiating your SMS upgrades.

If you have SQL Server installed on an SMS 1.2 site server, and that site server’s SQL Server hosts the databases for multiple SMS 1.2 sites, you must move all but one of the SQL Server databases to other servers. SMS 2.0 site servers cannot share SQL Server with other sites when SQL Server is installed on the site server.

Do not upgrade SQL Server 6.5 to SQL Server 7.0 or later before all SMS 1.2 sites have been upgraded to SMS 2.0 SP2. SQL Server 7.0 introduced incompatibilities between SQL Server 7.0 and SMS 1.2.

More Information

For additional information, refer to the following resources:

  • Systems Management Server Home
  • Microsoft SQL Server Home
  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • SMS Release Notes
  • Windows NT Service Packs
  • SQL Server Service Packs
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Systems Management Server 2.0 Administrator's Guide - Chapter 6, "Installing SMS 2.0 Sites", the section "Preparing SQL Server"
  • Q158864 - How to Obtain Systems Management Server 1.2 Service Pack 4
  • Q178295 - How to Obtain SQL Server 6.5 Service Pack 4
  • Q194146 - SMS: Nordic SQL Server Sort Order Causes Inventory Problems


Apply SMS Service Packs and Updates

All SMS 1.2 site servers should be upgraded to Service Pack 4 for SMS 1.2 before upgrading to SMS 2.0. If you plan to maintain one or more SMS 1.2 site servers in your hierarchy, update them to SMS 1.2 SP4 before you proceed with the SMS 2.0 installation, even if you intend to upgrade those sites to SMS 2.0 in the near future. This service pack helps the clients remain silent during the upgrade.

You must apply certain updates to all your existing SMS 2.0 sites (with or without SP1) before you add or upgrade any SMS 2.0 SP2 sites to your site hierarchy. The updates you must apply depend on whether the site requiring the update is running SMS 2.0 (no service pack) or SMS 2.0 SP1. The required updates are available on the SMS 2.0 SP2 compact disc, in the \SMSQFE directory.

See the Deploying Systems Management Server Service Packs technical paper for information regarding SMS service packs.

More Information

For additional information, refer to the following resources:

  • Systems Management Server Home
  • Deploying Systems Management Server Service Packs
  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • SMS Release Notes
  • SMS 1.2 Service Pack 4
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Q261931 - SMS: Required Hotfixes Before Installing SMS 2.0 SP2
  • Q158864 - How to Obtain Systems Management Server 1.2 Service Pack 4
  • Q261931 - SMS: Required Hotfixes Before Installing SMS 2.0 SP2
  • Q268803 - SMS: Problems Upgrading SMS 2.0 to Service Pack 2 with the Web Patch
  • Q258682 - SMS: List of Bugs Fixed in Systems Management Server 2.0 Service Pack


Do Not Upgrade SMS 1.2 Sites to SQL Server 7.0 or Later Prior to the Upgrade

Architectural changes in SQL Server 7.0 introduce incompatibilities between SQL Server 7.0 and SMS 1.2.

Install SQL Server 6.5 SP4 before you proceed with SMS 2.0 installation. When you have completed the upgrade of SMS to SMS 2.0 SP2, you should then upgrade your SMS 2.0 site databases to SQL Server 7.0 or later.

More Information

For additional information, refer to the following resources:

  • Systems Management Server Home
  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • SQL Server Service Packs
  • SMS Release Notes
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”


Prepare SMS 1.2 Sites

Upgrades of SMS 1.2 sites to SMS 2.0 are most efficient when the SMS 1.2 sites are optimized before the upgrade process.

SMS 2.0 Setup attempts to remove SMS 1.2 components from helper servers. It may be beneficial to move components from helper servers back to SMS 1.2 site servers before an upgrade. By doing this, you can eliminate problems that may result from helper servers being unavailable during the upgrade process.

SMS 2.0 SP2 Setup removes all files below the SMS folder. Save any custom files or collected files under the SMS folder to another location before running the upgrade.

An SMS 1.2 site database may contain information about resources that no longer exist, or may contain redundant information. There are tools that should be run on your SMS 1.2 sites before upgrading to SMS 2.0.

More Information

For additional information, refer to the following resources:

  • Systems Management Server Home
  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Installation and Configuration - Chapter 5, "Configuring a Site," from the SMS 1.2 documentation set.
  • Q192859 - SMS: SMS 1.2 SP4 Includes SMSIDDUP, DATDUPC, and DATDUPCL


Backup Site Servers, Computers Running SQL Server, and Distribution Points

Be sure to backup your SMS sites and databases before performing your upgrade. In addition to these backups, update your SMS site and hierarchy documentation. Although performing additional backups increases the overall time it takes to upgrade your sites, current backup materials and documentation will be invaluable if errors occur during the upgrade process.

Update your documentation after a successful upgrade with any site setting changes made, any component servers that are installed, as well as the date and time the upgrade for the site was performed.

It is also good practice to perform a site backup immediately after a successful upgrade. For additional information on backing up an SMS site, see SMS online Help.

For information on what to document and backup, see the Systems Management Server Technical Details page at Systems Management Server Technical Details.

If you find yourself in a recovery situation, Microsoft Product Support Services can provide assistance.

More Information

For additional information, refer to the following resources:

  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Systems Management Server 2.0 Administrator's Guide – Chapter 18 "Maintaining SMS Systems"
  • Support WebCast: Systems Management Server 2.0 Backup and Recovery
  • Systems Management Server Technical Details
  • Systems Management Server - Home Page
  • SMS 2.0 Issues and Resolutions: Design Pitfalls and Health Checks
  • Microsoft TechNet - Home Page


Remove SMS 1.2 Client Components Before Upgrading

If you are upgrading from SMS 1.2 to SMS 2.0 SP2, SMS automatically removes and upgrades any SMS components that have been installed on clients. However, you can avoid problems that may arise from some clients failing to upgrade automatically by removing SMS client software before your upgrade. This ensures that no client component files are locked open when SMS tries to upgrade.

Client software is most easily removed by clearing the Package Command Manager, Program Group Control, Remote Troubleshooting, and MIF Entry Program check boxes in the Clients dialog box.

SMS 1.2 clients receive the new settings the next time they run SMSLS or RUNSMS. You should do this at least a couple of days in advance of performing your site upgrade. You may have to manually run RUNSMS.bat on client computers that do not get logged off and back on at regular intervals (such as servers).

More Information

For additional information, refer to the following resources:

  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • SMS Release Notes
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”


Create Program Group Control Equivalent Functionality

Program Group Control (PGC) is a feature of SMS 1.2 that allows you to place short cuts to network-shared applications on client desktops.

If you are currently using PGC to provide SMS 1.2 clients with shortcuts to network applications that are run from a server, and you want that feature to continue without interruption for your users, you can set up equivalent functionality using the SMS 2.0 architecture and feature set.

If your SMS 1.2 site relies on PGC functionality, plan to replace the site with a new SMS 2.0 site rather than upgrading. If you upgrade, the programs provided via PGC will be unavailable to clients from the time you begin the upgrade until the time you have set up the functional equivalent of PGC in your upgraded site.

More Information

For additional information, refer to the following resources:

  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, "Upgrading from SMS 1.2 to SMS 2.0," the section "Providing Program Group Control Functionality"
  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Systems Management Server 2.0 Administrator's Guide – Chapter 18 "Maintaining SMS Systems"


Perform Your Site Upgrades

Before upgrading to SMS 2.0 SP2, you should have already accomplished the following processes:

  • Applied appropriate SMS, Windows NT, and SQL Server service packs.
  • Made all required changes to your SMS hierarchy.
  • Saved all custom files from below the SMS folder to a temporary location.
  • Removed duplicate SMS IDs from the SQL Server database.
  • Run SQL Server database maintenance routines, and ensured sufficient SQL Server free space exists.
  • Backed up your site servers and SQL Server databases.
  • Ensured the site server is sufficiently sized for SMS 2.0.
  • Ensured SQL Server databases, transaction logs, and the tempdb are sufficiently sized for the upgrade.
  • Removed SMS 1.2 client agents and remote control from client computers.

You are now ready to begin upgrading your SMS 1.2 SP4 sites to SMS 2.0 SP2. Upgrade your sites with the following rules in mind:

  • Upgrade from the top of the hierarchy down. Meaning, upgrade the highest-level parent sites, and then move down the tree one level for your next set of upgrades.
  • If you are upgrading SMS 2.0 to Service Pack 2, and if logon points are shared between sites, it is recommended that you upgrade the senior site before you upgrade the other sites that are sharing the logon points. A senior site is responsible for updates to user profiles, scripts, and logon point files. By default, senior sites are elected based upon site code and version.
  • To identify the senior site, see Knowledge Base article Q235726 SMS: How to Specify Senior Site for WinNT Logon Point Management in a Single Domain with Multiple Sites. Also, be sure to review the Deploying Systems Management Server Service Packs technical paper.
  • If the SMS Provider is shared among sites, when the first of those sites is upgraded, select the option to also upgrade the SMS Provider. When additional SMS sites are upgraded with the same version of SMS, do not upgrade the SMS Provider.
  • Upgrade the SMS site before you upgrade the SMS Administrator console on computers other than the site server.
  • You can use the SMS 2.0 Administrator console to upgrade any SMS 1.2 child secondary site and to view the following properties for any SMS 1.2 child site:
    • Site code
    • Site name
    • Site version
  • You cannot use the SMS 2.0 Administrator console to perform these tasks:
    • Change SMS 1.2 child site properties
    • Attach or detach an SMS 1.2 child site
    • Delete an SMS 1.2 child site

To administer an SMS 1.2 child site, you must maintain a copy of the SMS 1.2 Administrator on an installation of Windows NT that does not have the SMS 2.0 Administrator console installed.

More Information

For additional information, refer to the following resources:

  • SMS Release Notes
  • Systems Management Server Version 1.2 to 2.0 Upgrade
  • Systems Management Server - Home Page
  • Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0”
  • Systems Management Server 2.0 Administrator's Guide - Chapter 6, “Installing SMS 2.0 Sites”
  • Q268803 - SMS: Problems Upgrading SMS 2.0 to Service Pack 2 with the Web Patch
  • Q258682 - SMS: List of Bugs Fixed in Systems Management Server 2.0 Service Pack
  • Q261931 - SMS: Required Hotfixes Before Installing SMS 2.0 SP2
  • Q235726 - SMS: How to Specify Senior Site for WinNT Logon Point Management in a Single Domain with Multiple Sites


Upgrade SQL Server 6.5 AFTER Upgrading Your Sites

After successfully upgrading your SMS 1.2 SP4 sites to SMS 2.0 Service Pack 2, upgrade SQL Server 6.5 to SQL Server 7.0 or later.

You must run the SQL Server Upgrade Wizard, which is included with SQL Server 7.0 or later, to upgrade your SMS site database.

Warning

  • If you plan to upgrade from SMS 1.2 to SMS 2.0 and also upgrade from SQL Server 6.5 to SQL Server 7.0 or later, read the SMS 2.0 SP2 Release Notes entry "DO NOT Upgrade to SQL Server 7.0 Before Upgrading to SMS 2.0: Printed Documentation Error."

For detailed upgrade information, see the Systems Management Server Version 1.2 to 2.0 Upgrade technical paper and the Systems Management Server 2.0 Administrator's Guide - Chapter 5, “Upgrading from SMS 1.2 to SMS 2.0.”

More Information

For additional information, refer to the following resources:

  • Systems Management Server Home
  • Microsoft SQL Server Home
  • SMS Release Notes
  • SQL Server Service Packs
  • Q178295 - How to Obtain SQL Server 6.5 Service Pack 4
  • Q194146 - SMS: Nordic SQL Server Sort Order Causes Inventory Problems


Copyright

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2000 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Visual FoxPro, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies or products mentioned herein may be the trademarks of their respective owners.