Active Directory Planning

In the Preplanning section of this book, you collected information about how Active Directory is used within your organization. If you are not using Active Directory, you should skip this planning step.

Complete the Active Directory Planning worksheet contained in the Deployment Planning workbook file. There are three key questions that you must answer as part of this step.

Using Your Active Directory Sites to Define Your SMS Site Boundaries

Because Active Directory sites are based on physical network segments, the recommended method of defining your SMS site boundaries is to base them on your Active Directory sites. This allows SMS administrators to split or combine IP boundaries based on logical, not physical, criteria. One advantage to using Active Directory sites as SMS sites is that subnet changes or additions made within an Active Directory site do not require additional configuration in SMS 2003. Subnet changes are automatically reflected within your Active Directory site boundaries for SMS. Remember that Active Directory discovery methods can only be used to discover clients whose site boundaries are defined by Active Directory site names.

Managing SMS Sites Across Multiple Forests

Be aware that a single SMS site cannot span multiple Active Directory forests, although it can span multiple domains within a single forest. You must install an SMS 2003 primary site server in each Active Directory forest. All SMS site systems must be in the same Active Directory forest as the SMS site server. For general information about multiple forest considerations, download the white paper, Windows 2000/2003: Multiple Forests Considerations. Be aware of limitations across forests and considerations in the following areas when you design your SMS hierarchy:

• Communications within an SMS site

• Site-to-site communications

• Client communications

• Secure key exchange

Communications within an SMS site

Communication between an SMS site server and its site systems is not supported across forests. This includes communications between the SMS site server and the SMS site database server. Plan your site design so that for each site, the SMS site server, including the SMS site database server, and all site systems and SMS clients are within the same forest.

Site-to-site communications

Site-to-site communications have limitations across forests. A child primary site in one forest can attach to a parent in a different forest. A child secondary site cannot attach to a parent in a different forest. Data is sent up the hierarchy from a child primary site to its parent site. For site-to-site communications to work, the SMS addresses at the sending site must have access to the receiving site and vice versa. If one or more of the forests is running in Windows 2000 Active Directory mixed mode or if Microsoft Windows Server™ 2003 Active Directory is using the interim domain functional level, you must specify user accounts as addresses for site-to-site communications to work.

Windows Server 2003 and site communications

Communications across forests work in SMS if the following conditions are met:

• You are using the Windows Server 2003 family.

• The forest functional level is set to Windows Server 2003.

• SMS is running in advanced security mode.

• The forests are configured with a transitive trust.

The forest functional level can be set to Windows Server 2003 only if all of your domain controllers are running an operating system in the Windows Server 2003 family. If the forest functional level is set to Windows Server 2003, then creating additional accounts is not required for SMS site-to-site communications to work. For more information about forest functional levels, see the Windows Server 2003 family documentation.

Client roaming across Active Directory forests

Without Active Directory, client roaming is limited to regional roaming (roaming to lower level sites in the SMS hierarchy). With Active Directory, Advanced Clients can perform global roaming within the forest of their assigned site (roaming to higher level sites or sibling sites across the hierarchy).

If the SMS hierarchy is distributed among multiple Active Directory forests, the Advanced Client cannot roam outside the forest that contains the client’s assigned site unless WINS is enabled. In this scenario, WINS is required for the client to locate the resident management point. If WINS is enabled, roaming Advanced Clients can communicate with resident management points to receive distribution-point location information. For information about roaming, see Chapter 2: “Understanding SMS Sites” in the Microsoft Systems Management Server 2003 Concepts, Planning, and Deployment Guide. Also, view the animation Roaming in SMS 2003 or read the white paper Configuration and Operation of Advanced Client Roaming, both available from the SMS 2003 Product Documentation Web site https://www.microsoft.com/smserver/techinfo/productdoc.

Secure key exchange

Another limitation across forests is that there is no secure key exchange by way of Active Directory across forests. For more information about domain trusts, forest trusts, and key exchange, see Scenarios and Procedures for Microsoft Systems Management Server 2003: Security.

Extending Your Active Directory Schema for SMS

In planning your SMS 2003 deployment, for organizations using Active Directory, it is important to decide whether or not to extend the Active Directory schema for SMS. In Active Directory, extending the schema is not a reversible action. If you choose to extend the Active Directory schema, you must decide whether to do it before, during, or after setup. Determine who the Active Directory administrator is and what permissions are needed to perform the schema extension.

You extend the Active Directory schema to publish SMS objects in Active Directory. If you do not extend the schema, SMS cannot publish objects, and the following features are not available for Advanced Clients in SMS:

• Global roaming

• Automatic site assignment where the server locator point is not specified

Although SMS 2003 Setup prompts you to extend the schema, you can extend schema before, during, or after you run setup.

Note

If you do not extend the Active Directory schema for SMS, your server locator point and management points are not published to Active Directory, and you must manually register the server locator point (and any management points that are operating in a Network Load Balancing cluster) in WINS.

If you choose to extend the Active Directory schema during setup, be aware that you perform this task only once per Active Directory forest, and the logged-on user who is running SMS Setup must have administrative credentials. When you extend the schema, the global catalog is replicated throughout the forest, so you must consider the network traffic that might be generated as a result. You might plan to extend the schema during a time when the replication traffic will not adversely affect other network dependent processes.

After you extend the schema, you must grant SMS permissions to publish objects to the schema. If you are using standard security, you must grant permissions to the SMS Service Account. If you are using advanced security, you must grant permissions to the SMS site server’s computer account. For information about extending the Active Directory schema for SMS and granting permission to SMS to publish objects, see the white paper “Active Directory Schema Modification and Publishing for Systems Management Server 2003”.

Important

Before you enable any Active Directory Schema changes in a Windows 2000 domain, you must enable the option to allow the schema to be extended. This does not apply to the Windows Server 2003 domains. For more information about the Active Directory schema, see the Microsoft Windows 2000 Distributed Systems Guide in the Microsoft Windows 2000 Server Resource Kit. Also, see Microsoft Knowledge Base article 216060 at https://support.microsoft.com.

If you have multiple domains in your forest, and multiple independent SMS hierarchies, although the schema is extended for the entire forest, each domain maintains its own System Management container in Active Directory in its own domain partition. A domain controller does not replicate its System Management container to other domains in the forest. However, the System Management information from each domain is published to the global catalog for the forest. When SMS clients use automatic site assignment, the global catalog returns information for all sites in the forest, regardless of the domain or site hierarchy affiliation. This means that if two sites, installed in separate domains in the forest, have overlapping site boundaries, the client could potentially be assigned to the wrong site. This is one reason that an overlapping site boundary is not recommended.

Important

Each SMS site requires explicit permissions to publish to Active Directory. Child sites do not inherit permissions to the System Management container.

In addition, SMS clients that roam within the forest might be directed to a management point outside the site to which they are assigned and that cannot provide the content the client requires. Advanced Clients receive site assignment based on the boundaries for the site. The Advanced Client sends a request for automatic site assignment to a global catalog server. If there is more than one SMS site associated with that boundary, the global catalog could return any site associated with that boundary. Domain membership is irrelevant in this scenario. Each domain maintains its own System Management container in the domain partition and this container is not replicated to other domains in the forest. However, the System Management information is published to the global catalog, making it available to every client in the forest regardless of domain membership. This is another reason that overlapping site boundaries are not recommended.

Important

The number of properties and values that can be stored in a single object in Active Directory is limited. If your SMS 2003 site contains more than 400 boundaries of any kind, new boundaries cannot be stored in Active Directory, and a status message error is generated by SMS Hierarchy Manager. SMS 2003 SP1 mitigates this limitation by publishing an additional site object for every 350 site boundaries.

SMS 2003 and WINS

The Windows Computer Network Browser service (browsing) is required if SMS is running in standard security mode or if some SMS clients are running the Legacy Client. If your SMS hierarchy is not within an Active Directory environment, or if the Active Directory schema is not extended , your server locator point and management points cannot be published to Active Directory and you must manually register the server locator point (and any management points operating in a Network Load Balancing cluster) in Windows Internet Name Service (WINS). For more information, see the section “Manually Add SMS Site System Roles in Windows Internet Name Service” in Appendix G later in this guide.

SMS 2003 also requires WINS if any one of the following is true:

• SMS is running in standard security mode.

• SMS 2.0 child sites are in your hierarchy.

• Some SMS clients are Legacy Clients.

• The Active Directory schema has not been extended for SMS.

• Your SMS hierarchy is distributed across multiple Active Directory forests, or you have workgroup clients.

You can disable browsing and WINS if all of the following are true:

• Active Directory is implemented in your environment.

• The Active Directory schema is extended for SMS and each SMS site is publishing to Active Directory.

• All SMS clients are Advanced Clients.

• No secondary sites are in Windows NT 4.0 domains.

• No secondary sites are in a forest that is different from the forest of their parent site.

• No SMS 2.0 child sites exist.

• SMS is running in advanced security mode.

*SPAn SMS 2003 SP1 site configured for advanced security does not require Windows Internet Name Service (WINS), provided that all clients are Advanced Clients residing in one forest and Active Directory has been extended with each SMS site publishing identity data to Active Directory. In this configuration, DNS is used for name resolution, and Active Directory is used for locating SMS services. When using DNS, SMS only uses the short computer name rather than fully qualified domain names (FQDNs).This means that in multiple domain environments SMS clients must be configured with a DNS search suffix as part of their TCP/IP configuration if they need to resolve SMS server names outside their local domain.. When configuring the DNS search suffixes, include each domain suffix of all your SMS servers.

Note

Even if you are using DNS for name resolution, computers in a workgroup still require WINS to locate SMS services (server locator points and management points).

Important

Active Directory® schema extension is required and each SMS site must publish to Active Directory when using DNS for name resolution. This enables Advanced Clients to find their default management point and also permits clients to roam.

SMS 2003 SP2 introduces the following changes regarding the use of FQDNs:

• SMS 2003 SP2 client systems can locate management points and distribution points using the Fully Qualified Domain Name (FQDN) rather than by NetBIOS name only. On the General tab of the Site System Properties dialog box for the management point or distribution point, you can select Specify a Fully Qualified Domain Name to configure the site server name to be published to Active Directory.

• In the Sender Properties dialog box, instead of the previously required 15-character NetBIOS computer name, you can now enter an FQDN value for site server name.

However, a minor update to the SMS specific schema extensions is required to support the publication of the FQDN for SMS site systems, in particular management points. This change is backward compatible with SMS 2003 RTM and SP1 sites and should have no impact on those infrastructures.

The following table describes the changes:

After the schema is extended, management point (mSSMSManagementPoint) instances published to Active Directory include the dNSHostName attribute, by default set to the SMS MP Name (the site system computer name). If a fully qualified host name is specified for the site system properties, the dNSHostName is populated with it instead. Note that the dNSHostName is a pre-existing attribute already available in Active Directory.

After modifying Active Directory to allow schema updates, this schema change can be performed by running

extadsch.exe

from the SMS 2003 SP2 CD. A log in the root of the system drive called extadsch.log will indicate that the schema update completed successfully. You can use the Active Directory Schema MMC add-in to view the properties of the mSSMSManagementPoint class. On the Attributes tab, the attribute dNSHostName is is displayed in the Optional list box. This means that the SMS Site Component Manager can successfully publish it to Active Directory. For more information about exntending the Active Directory Schema, see Extending the Active Directory Schema in Appendix G of this guide.

*SP