- Understanding the ConfigMgr Architecture
- A WMI Primer
- Configuration Manager and WMI
- Inside the ConfigMgr Database
- Status and State Messages Overview
- Site-to-Site Replication
- Active Directory Integration with ConfigMgr
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Active Directory Integration with ConfigMgr
AD (or, more formally, Active Directory Domain Services [ADDS]) is the central information store used by Windows Server to maintain entity and relationship data for a wide variety of objects in a networked environment. It provides a set of core services, including authentication, authorization, and directory services. ConfigMgr utilizes ADDS to support many of its features.
ConfigMgr uses ADDS implicitly to support authentication and authorization through the use of computer accounts, primarily through use of the Local System account, and optionally with service accounts to perform certain operations. ConfigMgr can also use published information about its sites and services, making that information easily accessible to ADDS clients. ConfigMgr clients treat AD as a trusted location for obtaining information to confirm the identity of a site’s MPs. To take advantage of these capabilities, you must extend the AD schema to create classes of objects specific to ConfigMgr.
While it is not necessary to extend the schema for ConfigMgr operations, it is required for certain ConfigMgr features. Extending the schema greatly simplifies ConfigMgr deployment and operations. The following section discusses the process of extending the AD schema. Chapter 4 discusses the benefits and feature dependencies of the extended schema and why you might want to include schema extensions in your design.
Implementing Schema Extensions
All objects in ADDS are instances of classes defined in the ADDS schema. The schema provides definitions for common objects such as users, computers, and printers. The schema also defines attributes used to describe objects. The schema is extensible, allowing administrators and applications to define new object classes and modify existing classes for an organization’s instance of AD. The ConfigMgr schema extensions are relatively low risk, involving only a specific set of classes with specific object and attribute names that are not likely to cause conflict. However, you should test any schema modifications before applying them to your production environment.
Before actually extending the schema for ConfigMgr, run the dcdiag and repladmin commands included as part of the Domain Controller role in Windows Server. These tools validate that all domain controllers are replicating and healthy. Because it may be difficult to validate the output of these tools, output the results to a text file by using the following syntax:
dcdiag > %temp%\dcdiag.log
In the case of repladmin, the following syntax (all on one line) helps to validate the state of replication:
repadmin /replsum /bysrc /bydest /sort:delta > %temp%\repladmin.log
Review the output of the repladmin command to ensure that all domain controllers show no replication failures (that is, 0 in the Fails column). For more information on how to perform schema changes, see https://msdn.microsoft.com/library/windows/desktop/ms676929.aspx.
After you extend the ADDS schema and perform the other steps necessary to publish site information to ADDS, ConfigMgr sites can publish information to ADDS. The next sections describe the process for extending the schema and configuring sites to publish to AD, as well as the AD objects and attributes created by the schema extensions.
Tools for Extending a Schema
You can extend a schema in either of two ways:
Running the ExtADSch.exe utility from the ConfigMgr installation media
Using the LDIFDE (Lightweight Directory Access Protocol [LDAP] Data Interchange Format Directory Exchange) utility included with Windows Server to import the ConfigMgr_ad_schema.ldf LDIF file
To use all the features of ConfigMgr, you must use AD with a Windows Server 2008 or later domain functional level. All site systems must be members of a Windows Server AD domain that meets that domain functional level (though it does not need to be the same domain or in some cases the same forest). ConfigMgr clients may be joined to a workgroup or a domain. For a complete list of Active Directory support requirements, see https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-active-directory-domains.
Using ExtADSch
Using ExtADSch.exe is the simplest way to extend a schema. Simply run it with the appropriate permissions, and ExtADSch.exe creates a log file called extadsch.log, located in the root of the system drive (%systemdrive%), which lists all schema modifications it has made and the status of the operation. Following the list of attributes that have been created, the log should include the entry Successfully extended the Active Directory schema.
Using LDIFDE
LDIFDE is a powerful command-line utility for extracting and updating directory service data on ADDS domain controllers. LDIFDE provides command-line switches that allow you to specify a number of options, including some you may want to use when updating the schema for ConfigMgr.
Find detailed information about using LDIFDE at https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731033(v=ws.11) and ConfigMgr-specific instructions at https://docs.microsoft.com/sccm/core/plan-design/network/extend-the-active-directory-schema. The following example is a typical command to update the schema for ConfigMgr:
LDIFDE -i -f – ConfigMgr_ad_schema.ldf -v -j %temp%\SchemaUpdate.log
The verbose logging available with LDIFDE includes more detail than the log file generated by ExtADSch.exe. The ConfigMgr_ad_schema.ldf file allows you to review all intended changes before they are applied, or you can provide the ConfigMgr_ad_schema.ldf to your Active Directory administrators for them to review if required.
Extending a Schema
Each AD forest has a single domain controller with the role of schema master. All schema modifications are made on the schema master. To modify the schema, log on using an account in the forest root domain that is a member of the Schema Admins group.
The ConfigMgr schema modifications create 4 new classes and 14 new attributes used with these classes. The classes represent the following:
Management Points (MS-SMS-Management-Point): Clients can use this information to find a management point and confirm the identity of a management point in case the policy signing key changes (for example, during a site recovery).
Roaming Boundary Ranges (MS-SMS-Roaming-Boundary-Range): Clients can use this information to locate ConfigMgr services based on their network location.
Server Locator Points (MS-SMS-Server-Locator-Point): This legacy class is created but not used as part of ConfigMgr Current Branch schema extensions. It was used in ConfigMgr 2007 to enable clients to find an SLP and determine their assigned site. The SLP role no longer exists; its functionality has been integrated into the MP.
ConfigMgr Sites (MS-SMS-Site): Clients can retrieve important information about the site from this AD object.
Objects and attributes in the ConfigMgr schema modification are prefixed with MS-SMS, which helps minimize the risk of collisions with other custom or application-specific schema extensions. In addition, all objects and attributes in the schema have the isMemberOfPartialAttributeSet flag set to True. This flag causes instances of these objects and attributes to be included as part of the partial attribute set and marked for replication to all global catalog domain controllers in the forest. This allows a site server that is a member of a domain to advertise its existence to all clients in the forest instead of just that domain.