Extending the Schema in System Center 2012 Configuration Manager

Extending the Schema in System Center 2012 Configuration Manager

  • Comments 8
  • Likes

GrayAndYellowGears

Hi ConfigMgr users, Radu Tomoiaga here with some details on extending the Active Directory Schema for System Center 2012 Configuration Manager. There are a couple of topics in TechNet that reference this information which I have highlighted in the body of this article below, plus I also included some extra information and some screen shots to help you navigate the content a little easier.  Hope this information makes your AD Schema extension process smoother. 

When installing System Center 2012 Configuration Manager (ConfigMgr 2012) you have to decide whether to extend the AD Schema or not.

The Active Directory schema extensions for ConfigMgr 2012 are unchanged from those used by Configuration Manager 2007. If you extended the schema for Configuration Manager 2007, you do not have to extend the schema again for ConfigMgr 2012. ConfigMgr 2012 uses the Windows Active Directory (AD) environment to support many of the features it provides and can publish information to AD about sites and services. In this manner, the AD clients of ConfigMgr 2012 have this information easily accessible, but in order to use this feature the AD schema has to be extended in order to create the objects and the classes specific to ConfigMgr 2012. Extending the schema is not required for the installation of ConfigMgr 2012 but it is recommended.

Extending the Active Directory Schema for ConfigMgr 2012 allows clients to retrieve many types of information related to Configuration Manager from a trusted source. In some cases, there are workarounds for retrieving the necessary information if the Active Directory schema is not extended, but they are all less secure than querying Active Directory Domain Services directly. Additionally, not extending the schema might incur significant workload on other administrators who might need to create and maintain the workaround solutions such as logon scripts and Group Policy objects (GPO) for computers and users in your organization. The Active Directory schema can be extended before or after running ConfigMgr 2012 Setup, however as a best practice, it’s best to extend the schema before you run Configuration Manager 2012 Setup. You have to extend the Active Directory schema only once for the forest that contains site servers; you do not have to extend the schema again if you upgrade the operating systems on the domain controllers or after you raise the domain or forest functional levels. Similarly, if you extended the schema for ConfigMgr 2012 with no service pack, you do not have to extend the schema again for ConfigMgr 2012 SP1.

Extending the Active Directory schema is a forest-wide action and can only be done one time per forest. Extending the schema is an irreversible action and must be done by a user who is a member of the Schema Admins Group or who has been delegated sufficient permissions to modify the schema. If you decide to extend the Active Directory schema, you can extend it before or after setup. Only after the schema is AD extended and the steps needed to publish the ConfigMgr 2012 site information to AD, ConfigMgr 2012 can publish information to AD.

You can extend the AD Schema using either the extadsch.exe tool or the ConfigMgr_ad_schema.ldf file. When using the ldf file you will need to edit and configure this file. The extadsch.exe is easier to use and just needs a double click. The result of the extadsch.exe will write a log file in the root of C:\ of the computer from where the command was launched. You need to be a Schema Admin in order to make these changes and it is recommended to check with the AD administrator for permissions before extending the schema. If you need to see what happens and what changes are being made you can look at the ConfigMgr_ad_schema.ldf file.

While some Configuration Manager features depend on extending the schema, such as Network Access Protection in Configuration Manager and global roaming, there are workarounds for not extending the schema to enable other Configuration Manager features.

Four actions are required to successfully enable Configuration Manager clients to query Active Directory Domain Services to locate site resources:

· Extend the Active Directory schema.
· Create the System Management container.
· Set security permissions on the System Management container.
· Enable Active Directory publishing for the Configuration Manager site.

When extending the schema for Configuration Manager, several classes and attributes are added that any Configuration Manager site in the Active Directory forest can use. Because the global catalog is replicated throughout the forest, you must consider the network traffic that might be generated. In Windows 2000 forests, extending the schema causes a full synchronization of the whole global catalog. For Windows 2003 forests, Windows 2008 forests, and Windows 2008 R2 forests, only the newly added attributes are replicated. You should plan to extend the schema during a time when the replication traffic does not adversely affect other network-dependent processes.

You can extend the Active Directory schema for ConfigMgr 2012 by running the ExtADSch.exe tool or by using the LDIFDE command-line tool to import the contents of the ConfigMgr_ad_schema.ldf LDIF file. Both the tool and the LDIF file are located in the SMSSETUP\BIN\i386 directory of the Configuration Manager 2012 installation files. Regardless of the method that you use to extend the schema, two conditions must be met:

o The Active Directory schema must allow updates. On domains that are running Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2, by default the schema is enabled for updates. For domains that are running Windows 2000 Server, you must manually enable updates on the schema master for the Active Directory forest.

o The account that is used to update the schema must be either a member of the Schema Admins group or have been delegated sufficient permissions to modify the schema.

Using an LDIF file to extend the Active Directory schema instead of the ExtADSch.exe tool provides greater transparency about the changes being made to the Active Directory schema and also makes it easier to diagnose any problems encountered during the schema extension process.

You can use the LDIFDE command-line utility to import directory objects into Active DirectoryDomain Services using LDAP Data Interchange Format (LDIF) files. For greater visibility of the changes being made to the Active Directory schema than the ExtAdSch.exe utility provides, you can use the LDIFDE utility to import schema extension information using the ConfigMgr_ad_schema.ldf file is included on the Configuration Manager installation media in the .\SMSSETUP\BIN\i386 directory.

Extending the Active Directory Schema for Configuration Manager Using the LDIFDE Command Line Utility

The following procedure can be used to extend the Active Directory schema for Configuration Manager by importing schema extension information stored in the ConfigMgr_ad_schema.ldf file using the LDIFDE command line utility.

To extend the Active Directory schema using the ConfigMgr_ad_schema.ldf file

1. Create a backup of the schema master domain controller’s system state using the NTBACKUP utility.

2. Disconnect the schema master domain controller from the network.

3. Open the ConfigMgr_ad_schema.ldf file, located in the \SMSSETUP\BIN\I386 directory of the Configuration Manager 2012 installation files and edit the file to define the Active Directory root domain to extend. All instances of the text DC=x in the file must be replaced with the full name of the domain to extend.

For example, if the full name of the domain to extend is named widgets.microsoft.com, all instances of DC=x in the file should be changed to DC=widgets, DC=microsoft, DC=com.

4. Use the LDIFDE command-line utility to import the contents of the ConfigMgr_ad_schema.ldf file into Active Directory Domain Services.

For example, the following command line will import the schema extensions into Active Directory Domain Services, turn on verbose logging and create a log file during the import process:

ldifde –i –f ConfigMgr_ad_schema.ldf –v –j <location to store log file>.

5. To verify that the schema extension was successful, you can review the log file created by the command line used in step 3.

6. If the extension procedure was successful, reconnect the schema master domain controller to the network and allow it to replicate the schema extensions to the global catalog servers throughout the Active Directory forest.

7. If the schema extension procedure was not successful, restore the previous system state using the NTBACKUP utility to reverse the schema extension actions before reconnecting the schema master domain controller to the network.

Using ExtADSch.exe to extend the Active Directory schema for Configuration Manager

You can extend the Active Directory schema by running the ExtADSch.exe file located in the SMSSETUP\BIN\I386 folder on the Configuration Manager 2012 installation media. The ExtADSch.exe file does not display output when it runs, however it does generate a log file in the root of the system drive called extadsch.log which will indicate whether the schema update completed successfully or if any problems were encountered while extending the schema.

When using the extadsch.exe tool you will get in the log file the following message if everything was OK:

Successfully extended the Active Directory schema.

When using ExtADSch.exe to extend the Active Directory schema for Configuration Manager, you should be aware of the following limitations.

o It is not supported to run the ExtADSch.exe utility locally on Windows 2000–based computers. To extend the Active Directory schema locally on a Windows 2000–based computer, the ConfigMgr_ad_schema.ldf file should be used.

o When extending the Active Directory schema by running ExtADSch.exe from a Windows Vista workstation, you must be logged in with an account with local administrator permissions on the workstation for the extadsch.log to be created in the root of the system drive.

To extend the Active Directory schema using ExtADSch.exe

1. Create a backup of the schema master domain controller’s system state using the NTBACKUP utility. To start the NTBACKUP utility, click Start, click Run and type ntbackup.

2. Ensure that you are logged on to the schema master domain controller with an account that is a member of the Schema Admins security group.

3. Run extadsch.exe, located at \SMSSETUP\BIN\I386 on the installation media, to add the new classes and attributes to the Active Directory schema.

4. Verify that the schema extension was successful by reviewing the extadsch.log located in the root of the system drive.

5. If the schema extension procedure was unsuccessful, restore the schema master's previous system state from the backup created in step 1. This will reverse the schema extension actions before reconnecting the schema master domain controller to the network.

Attributes and Classes Added by the Configuration Manager Schema Extensions

When you extend the Active Directory schema for ConfigMgr 2012, the following attributes and classes are added to Active Directory Domain Services:

Attributes:

cn=mS-SMS-Assignment-Site-Code

cn=mS-SMS-Capabilities

cn=MS-SMS-Default-MP

cn=mS-SMS-Device-Management-Point

cn=mS-SMS-Health-State

cn=MS-SMS-MP-Address

cn=MS-SMS-MP-Name

cn=MS-SMS-Ranged-IP-High

cn=MS-SMS-Ranged-IP-Low

cn=MS-SMS-Roaming-Boundaries

cn=MS-SMS-Site-Boundaries

cn=MS-SMS-Site-Code

cn=mS-SMS-Source-Forest

cn=mS-SMS-Version

Classes:

cn=MS-SMS-Management-Point

cn=MS-SMS-Roaming-Boundary-Range

cn=MS-SMS-Server-Locator-Point

cn=MS-SMS-Site

The Active Directory schema extensions might include attributes and classes that are carried forward from previous versions of the product but not used by ConfigMgr 2012. For example:

o Attribute: cn=MS-SMS-Site-Boundaries

o Class: cn=MS-SMS-Server-Locator-Point

After the schema has been extended with the classes and attributes that are required for Configuration Manager, create a System Management container in the System container in each site server's domain partition in Active Directory Domain Services. Because domain controllers do not replicate their System Management container to other domains in the forest, you must create a System Management container for each domain that hosts a Configuration Manager site.

Although each domain maintains its own System Management container in the domain partition, the Configuration Manager information is published to the global catalog for the forest. This makes the information for each site publishing to Active Directory Domain Services available to every client in the forest regardless of domain membership.

Configuration Manager does not automatically create the System Management container in Active Directory Domain Services when the schema is extended. The container must be created one time for each domain that includes a Configuration Manager primary site server or secondary site server that publishes site information to Active Directory Domain Services.

Use ADSI Edit to create the System Management container in Active Directory Domain Services.

To manually create the System Management container

1. Log on as an account that has the Create All Child Objects permission on the System container in Active Directory Domain Services.

2. Run ADSI Edit, and connect to the domain in which the site server resides.

3. Expand Domain <computer fully qualified domain name>, expand <distinguished name>, right-click CN=System, click New, and then click Object.

4. In the Create Object dialog box, select Container, and then click Next.

5. In the Value box, type System Management, and then click Next.

6. Click Finish.

After you have created the System Management container in Active Directory Domain Services, you must grant the site server's computer account the permissions that are required to publish site information to the container. The site server computer account must be granted Full Control permissions to the System Management container and all of its child objects. If you have secondary sites, the secondary site server computer account must also be granted Full Control permissions to the System Management container and all its child objects.

You can grant the necessary permissions by using the Active Directory Users and Computers administrative tool or the Active Directory Service Interfaces Editor (ADSI Edit). To apply permissions to the System Management container by using the Active Directory Users and Computers administrative tool, complete the following steps:

1. Click Start, click Run, and then enter dsa.msc to open the Active Directory Users and Computers administrative tool.

2. Click View, and then click Advanced Features.

3. Expand the System container.

4. Right-click System Management, and then click Properties.

5. In the System Management Properties dialog box, click the Security tab.

6. Click Add to add the site server computer account and grant the account Full Control permissions.

7. Click Advanced, select the site server’s computer account, and then click Edit.

8. In the Apply onto list, select This object and all child objects.

9. Click OK

To apply permissions to the System Management container by using the ADSI Edit console

1. Click Start, click Run, and enter adsiedit.msc to open the ADSIEdit console.

2. If necessary, connect to the site server's domain.

3. In the console pane, expand the site server's domain, expand DC=<server distinguished name>, and then expand CN=System. Right-click CN=System Management, and then click Properties.

4. In the CN=System Management Properties dialog box, click the Security tab.

5. Click Add to add the site server computer account and grant the account Full Control permissions.

6. Click Advanced, select the site server’s computer account, and then click Edit.

7. In the Apply onto list, select This object and all child objects.

8. Click OK.

When Configuration Manager site information is published to Active Directory Domain Services, Configuration Manager clients can automatically detect server locator points and management points without generating Windows Internet Name Service (WINS) traffic. If Configuration Manager site information is not published to Active Directory Domain Services, you might have to add Configuration Manager site role information in WINS manually.

After you enable a Configuration Manager site to publish site information, you can verify that the site information is published to the Active Directory Domain Services by using the Active Directory Users and Computers administrative tool or the Active Directory Service Interfaces Editor (ADSI Edit).

You can also verify that hierarchy manager has created the site code object by reviewing the hman.log file, and you can verify that site component manager has created the management point and server locator point information by reviewing the sitecomp.log file.

Verifying That Site Information Is Published to Active Directory Domain Services by Using Active Directory Users and Computers

Use Active Directory Users and Computers to verify that the site and related information is published to Active Directory Domain Services when you do not need to confirm the values that are associated with the individual Configuration Manager Active Directory classes and attributes.

To verify that site information is published to Active Directory Domain Services by using Active Directory Users and Computers

1. Click Start, click Run, and enter dsa.msc to open the Active Directory Users and Computers administrative tool.

2. Click View, and then click Advanced Features.

3. In the console pane, expand the System container.

4. Click the System Management container.

5. In the results pane, verify that the site object, the management point and server locator point, and boundary information have been published for each site in the domain that has publishing enabled:

SMS-Site-<site code>
SMS-MP-<site code>-<site system server name>
SMS-<site code>-<Active Directory site name or subnet>

Verifying That Site Information Is Published to Active Directory Domain Services by Using the ADSI Edit

Use ADSI Edit to verify that the site and related information is published to Active Directory Domain Services and confirm the values that are associated with the individual Configuration Manager Active Directory classes and attributes.

To verify the creation of the site code object

1. Click Start, click Run, and enter adsiedit.msc to run ADSI Edit.

2. If necessary, connect to the site server's domain.

3. In the console pane, expand the site server's domain, expand DC=<server distinguished name>, expand CN=System, and then click CN=System Management.

4. In the results pane, right-click CN=SMS-Site-<site code>, and then click Properties.

5. Verify that the following attributes appear:

Attribute Property

Syntax

Value

msSMSAssignmentSiteCode

Case-Insensitive String

<site code>

msSMSRoamingBoundaries

Case-Insensitive String

<Active Directory site name or subnets>

msSMSSiteCode

Case-Insensitive String

<site code>

If the site object is not published or contains incorrect data, review the hman.log file in the <ConfigMgrInstallationPath>\Logs folder to identify the failure.

To verify the creation of the management point information

1. Click Start, click Run, and enter adsiedit.msc to run ADSI Edit.

2. If necessary, connect to the site server's domain.

3. In the console pane, expand the site server's domain, expand DC=<server distinguished name>, expand CN=System, and then click CN=System Management.

4. Verify that for each management point there is a CN=SMS-MP-<site code>-<management point computer name> object.

5. Right-click CN=SMS-MP-<site code>-<default management point computer name>, and then click Properties.

6. Verify that the following attributes appear:

Attribute Property

Syntax

Value

msSMSDefaultMP

Boolean

TRUE

msSMSMPName

Case-Insensitive String

<default management point computer name>

msSMSSiteCode

Case-Insensitive String

<site code>

If you do not have an object published for each management point, or if the information for the default management point is not correct, review the Sitecomp.log file in the <ConfigMgrInstallationPath>\Logs folder to identify the failure.

More information on how to configure AD Publishing

What’s New in Configuration Manager: http://technet.microsoft.com/en-us/library/gg699359.aspx

Determine Whether to Extend the Active Directory Schema for Configuration Manager: http://technet.microsoft.com/en-us/library/gg712272

Decide If You Should Extend the Active Directory Schema: http://technet.microsoft.com/en-us/library/bb694066.aspx

How to Extend the Active Directory Schema for Configuration Manager: http://technet.microsoft.com/en-us/library/bb633121.aspx

How to Extend the Active Directory Schema Using an LDIF File: http://technet.microsoft.com/en-us/library/bb632388.aspx

How to Extend the Active Directory Schema Using ExtADSch.exe: http://technet.microsoft.com/en-us/library/bb680608.aspx

How to Create the System Management Container in Active Directory Domain Services: http://technet.microsoft.com/en-us/library/bb632591.aspx

How to Set Security on the System Management Container in Active Directory Domain Services: http://technet.microsoft.com/en-us/library/bb633169.aspx

How to Verify That Site Information Is Published to Active Directory Domain Services: http://technet.microsoft.com/en-us/library/bb693614.aspx

Radu Tomoiaga | Support Engineer

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

App-V Team blog: http://blogs.technet.com/appv/
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
Operations Manager Team blog: http://blogs.technet.com/momteam/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

The Forefront Server Protection blog: http://blogs.technet.com/b/fss/
The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Awesome post, thanks so much Radu ;)

  • any update on when we can get SP1 for SCCM2012?

  • clear and helpful post ...very useful ...thanks a lot

  • ldifde supports substitution for the generic DC=x within the ldif file,

    ldifde option

    -c FromDN ToDN  Replace occurences of FromDN to ToDN

                   If either FromDN or ToDN ends with #attributeName, the

                   attribute value will be looked up in rootDSE and used to

                   replace #attributeName.  See example for "Macro expansion

                   in DNs".

    personally I'd not be editing the ldif file at all as this can cause problems and breaks hash checks

  • Anybody knows how the numeric values for MS-SMS-Ranged-IP-Low and MS-SMS-Ranged-IP-High CN's in LDAP are calculated? Obviously, they derive somehow from the IP range boundaries defined in the SCCM Console.

  • Found the ldifde.exe. This should help out.

  • We have installed Microsoft System Center 2012 R2 Configuration Manager 2008 R2 64bit OS. but getting error client computers have ever contacted the server and WSUS Synchronization failed Event ID : 6703

  • On the most recent Windows Server 2012 R2 Update "This object and all child objects" changes to read "This object and all descendant objects"