If you’re looking to build a Production or Lab environment for ConfigMgr (MECM/SCCM) and trying to follow step-by-step tutorials from MVPs such as PrajwalDesai, Anoop C Nair and System Center Dudes, you will need to perform the following:
- Extend AD Schema
- Create System Management container
- Delegate permissions to System Management container for all SCCM site servers
But first, let’s get into the importance of the AD System Management container and what it’s used for.
What is the AD System Management container used for?
When you extend the Active Directory schema for Configuration Manager, it allows the SCCM site servers and management points to publish data which will be useful for clients in your Active Directory domain.
Some of the benefits of doing this include:
- simplify the process of deploying and setting up clients
- allows clients to efficiently locate resources like content servers and additional services that various CM roles provide
You will only have to extend your AD Schema once for Configuration Manager / MECM / SCCM. This means if you’ve done it already in the past for older versions of MECM (e.g. SMS 2007), you won’t need to perform it again.
Also, Microsoft recommends that you extend your Active Directory schema for Configuration Manager, but it’s not required.
➡ Publishing and the Active Directory schema – Configuration Manager | Microsoft Learn
➡ About schema extensions – Configuration Manager | Microsoft Learn
What’s in the System Management container and where can I find it?
The secure location Microsoft is referring to is the System Management container located in the Active Directory Users and Computers console for your domain.
Launch ADUC > expand your domain torontoit.co > expand System > select System Management. Here you will find all entries/records produced by Configuration Manager.
This container should already exist if you have MECM/SCCM installed in your environment, as it is required in order to extend your AD schema.
Prior to building your CM site, you will need to manually create the System Management container using ADSI Edit console and assign the SCCM site server computer accounts with Full Control permissions to parent object and all child descendent objects.
Once you complete the CM site installation, an active site will populate this container with different objects and object attributes mostly relating to Site, Management Point, Server Locator Point and Boundary Information.
- mSSMSSite
- mSSMSManagementPoint
- mSSMSServerLocatorPoint
- mSSMSRoamingBoundaryRange
How to do I check if AD Schema has been extended for MECM/SCCM?
If you’ve already extended AD Schema and want to verify or validate the configuration, you can perform the following step-by-step tasks.
NOTE: This specific section of this post is completely written by John Clyburn from Microsoft, who wrote an excellent TechCommunity blog article that may not exist one day as others have been deleted in the past, so I decided to paste his amazing work here.
1. Open the Run dialog box by selecting Start, Run.
2. In the Run dialog box, type [schmmgmt.msc] then press [Enter].
Verify mSSMSSite Class
1. Expand the Active Directory Schema tree by clicking on the + symbol in the left pane.
2. Select the Classes folder to display the classes in the right pane.
3. From the right pane, locate the mSSMSSite class icon.
4. Right-click mSSMSSite icon and select Properties from the pop-up menu.
5. From the mSSMSSite Properties screen, select the Attributes tab.
6. From the Attributes tab, verify the following attributes in the Optional area of the screen.
| cn |
| mSSMSAssignmentSiteCode |
| mSSMSHealthState |
| mSSMSRoamingBoundaries |
| mSSMSSiteBoundaries |
| MSSMSSiteCode |
| mSSMSSourceForest |
| serviceBindingInformation |
Verify mSSMSManagementPoint Class
1. From the right pane, locate the mSSMSManagementPoint class icon.
2. Right-click mSSMSManagementPoint class and select Properties from the pop-up menu.
3. From the mSSMSManagementPoint Properties screen, select the Attributes tab.
4. From the Attributes tab, verify the following attributes in the Optional area of the screen.
| cn |
| dNSHostName |
| mSSMSCapabilities |
| mSSMSDefaultMP |
| mSSMSDeviceManagementPoint |
| mSSMSMPAddress |
| mSSMSMPName |
| mSSMSSiteCode |
| mSSMSSourceForest |
| mSSMSVersion |
Verify mSSMSServerLocatorPoint Class
- In the right pane, locate the mSSMSServerLocatorPoint class icon.
- Right-click mSSMSServerLocatorPoint class and select Properties from the pop-up menu.
- From the mSSMSServerLocatorPoint Properties screen, select the Attributes tab.
- From the Attributes tab, verify the following attributes in the Optional area of the screen.
| cn |
| dNSHostName |
| mSSMSMPName |
| mSSMSSiteCode |
| mSSMSSourceForest |
Verify mSSMSRoamingBoundaryRange Class
- In the right pane, locate the mSSMSRoamingBoundaryRange class icon.
- Right-click mSSMSRoamingBoundaryRange class and select Properties from the pop-up menu.
- Right-click mSSMSRoamingBoundaryRange class and select Properties from the pop-up menu.
- From the Attributes tab, verify the following attributes in the Optional area of the screen.
| cn |
| mSSMSAssignmentSiteCode |
| mSSMSRangedIPHigh |
| mSSMSSiteRangedIPLow |
| mSSMSSiteCode |
| mSSMSSourceForest |
Verify SCCM Attributes in Active Directory Schema Snap-In
In the left pane, click the Attributes folder. From the right pane, verify the following SCCM attributes are listed.
mSSMSAssignmentSiteCode
mSSMSCapabilities
mSSMSDefaultMP
mSSMSDeviceManagementPoint
mSSMSHealthState
mSSMSMPAddress
mSSMSMPName
mSSMSRangedIPHigh
mSSMSRangedIPLow
mSSMSRoamingBoundaries
mSSMSSiteBoundaries
mSSMSSiteCode
mSSMSSourceForest
mSSMSVersion
Verify DOMAIN Replication to Domain Controllers
- Login to another domain controller.
- In the elevated Command window, type [adsiedit.msc].
- In the ADSI Edit window, right-click on the ADSI Edit node icon.
- From the pop-up menu, click Connect to…
- In the Connection Settings screen, in the Select a well known Naming Context, select Schema and click Ok.
- From the ADSI Edit screen, expand Schema under the replication partner.
- Select the Schema folder.
- In the right pane, click the Class column to display the classSchema entries.
- Verify the following four SCCM schema classes are listed:
MS-SMS-Management-Point
MS-SMS-Roaming-Boundary-Range
MS-SMS-Server-Locator-Point
MS-SMS-Site
Create the System Management Container
The System Management container is used to grant SCCM Permissions to Publish to the Active Directory. Each SCCM site requires explicit permissions to publish to the Active Directory. Child sites do not inherit permissions to the System Management container. Advanced clients use SCCM published information in active directory to find DPs, SLPs, and MPs.
Configuration Manager does not automatically create the System Management container in Active Directory Domain Services when the schema is extended. The container needs to be created once for each domain that includes any Configuration Manager site server that will publish site information to Active Directory Domain Services.
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.
In an Active Directory environment, the client queries Active Directory for a resident management point. It does this by searching the Active Directory global catalog for a site code, which has been registered (by a site server) with a matching Active Directory site name or IP address range.
NOTE: Remember that you create system management container one time in each domain that has a primary or secondary site. This will be used to publish data to Active Directory.
1. Logon to domain controller with an account that has permissions to create an Active Directory container.
2. Open the elevated command prompt.
3. Type adsiedit.msc, then press Enter.
4. Select Start, Run.
5. In the Run box, type adsiedit.msc.
6. Right click ADSI Edit and click Connect to.
7. On the Connection Settings window, the Name should be Default Naming Context. Click OK.8. From the left pane, expand the Default naming context, expand Domain container <DC=YourDomainName,DC-COM>.
9. Right-click on CN=System.
10. Select New–Object from the pop-up menu.
11. From the Create Object screen, select container, then click Next.
12. From the next Create Object screen, in the Value text field type:
a. System Management.
13. Click Next.
14. Click Finish.
15. From the ADSI Edit screen, expand the CN=System node and visually verify that CN=System Management has been created.
16. Close the ADSI Edit screen.
Set Security on the System Management Container (Manually)
After you create System Management container, you must delegate SCCM server full permissions on System Management container.
For each site to create its site object, the System Management container must exist. The SCCM site server computer account must be granted full rights to the System Management container. After the site has generated its Active Directory site object, full rights to the Systems Management container can be removed and full permissions set only to the site object and all child objects, such as Management Points and Server Locator Points. Any time a secondary site is installed, the parent site will again need full permissions to the Systems Management container in order to create the secondary site’s site object.
Note: The SCCM Site server computer account will retain full control permission after the site object has been created to support the creation of subsequent SCCM secondary sites.
Note the ConfigMgr prerequisite checker displayed a warning when Verify site server permissions to Publish to Active Directory. Note the warning can be ignored. This is a warning, not an error, I’ve seen it on most of my SCCM installation. The setup application has no way to know if the site server can or cannot write to AD, so it throws the warning so you the admin should go and check to be sure. Confirm that the permissions are set promperly using a AD Group or the Site server compter account (It doesn’t matter which you use) and AD publishing works fine.
NOTE: You can grant the site servers computer account Full Control permission to the System container in Active Directory Domain Services, which results in the site server automatically creating the System Management container when site information is first published to Active Directory Domain Services. However, it is more secure to manually create the System Management container.
NOTE: It is always recommended to delegate and provide permissions to an AD security group which eases future maintenance and provides access to all SCCM computer objects as opposed to providing each computer account access one-by-one. Consider this for step 8 below.
- Logon to Domain Controller and launch Active Directory Users and Computers.
- From the Active Directory Users and Computers screen, select Advanced Features from the View menu.
- In the left pane, expand the Domain node (e.g., domain.com).
- Expand the System container.
- Right-click on the System Management container and select Properties from the pop-up menu.
- From the System Management Properties screen, select the Security tab.
- Click Add.
- In the Select Users, Computers, or Groups screen, type SCCMServer (insert your SCCM server name) in the Enter the object names to select text box.
- Click Check Names to verify the typed entry.
- Click OK.
- In the Permissions for SCCMServer, click the Full Control checkbox in the Allow column.
- Click the Advanced button.
- From the Advanced Security Settings for System Management screen, select SCCMServer.
- Click Edit.
- From the Permission Entry for System Management screen, click the Apply to: dropdown box.
- From the dropdown list, select This object and all descendant objects.
- In the Permissions pane under the Allow column, verify the Full Control checkbox is checked.
- At the Permission Entry for System Management screen, click OK.
- At the Advanced Security Settings for System Management screen, click OK.
- At the System Management Properties screen, click OK.
- Close the Active Directory Users and Computers screen.
Alternative Method of setting Permissions for System Management Container:
Launch Active Directory Users and Computers.
Click View and click Advanced Features.
Expand System, right click System Management and click Delegate Control.
On the Welcome page, click Next.
Click Add.
NOTE: It is always recommended to delegate and provide permissions to an AD security group which eases future maintenance and provides access to all SCCM computer objects as opposed to providing each computer account access one-by-one.
On select users, computers or groups window click on Object Types and check for Computers as object types. Click OK.
Type the name of the primary site server computer account (SCCMServer) and click OK.
This add primary site server computer account
Click Next.
On the Tasks to Delegate page, click Create a custom task to delegate. Click Next.
On the Delegae Control Of page, Select This folder, existing objects in this folder and creation of new objects in this folder.
Click Next.
On the Permission page, Select General, Property Specific and Creation/deletionof specific child objects.
Under Permissions, click Full Control. When you check the box Full Control, all the other permissions get checked automatically.
What happens next?
The number of objects in the container will depend on your ConfigMgr environment.
For example, if you have 1 x Management Point, then you should have only 1 x mSSMSManagementPoint object in this container.
To verify that SCCM is publishing to the System Management container for each domain, check hman.log and you’ll see entries such as “Publishing site objects in AD Forest xxxx“.
What becomes problematic here is if your organization had older sites in the environment that were not cleaned up or decommissioned correctly. As a result, you will see objects with Site Codes which are different than your site code.
So, how do I know what to delete and what to keep?
Many confuse extending the AD schema and the System Management container as the same thing which isn’t the case. If you are no longer using ConfigMgr, the System Management container can be deleted. Plain and simple.
If you are still using ConfigMgr and only wish to cleanup the System Management container, keep reading.
➡ Scenario: You have 1 x Site Server (SCCM01) with Site Code TOR which acts as a Management Point and Distribution Point. You have 3 more servers configured as Distribution Points (DP01, DP02 and DP03).
➡ Example: Considering the scenario described above, in the screenshot below you will see that there are 5 extra Management Point (mSSMSManagementPoint) and Site (mSSMSSite) objects. They have different site codes because they are older sites which no longer exist and were not decommissioned correctly.
Name: SMS-Site-TOR
Type: mSSMSSite
Name: SMS-MP-TOR-YourPrimarySiteServer.torontoit.co
Type: mSSMSManagementPoint
Name: SMS-SLP-TOR-ServerLocatorPoint
Type: mSSMSServerLocatorPoint
*** if you’re missing this object, chances are you’re running a newer version than SMS 2007 / SCCM 2012
Name: SMS-TOR-12345678-123456789
Type: mSSMSRoamingBoundaryRange
Active Directory – System Management container Cleanup Process
➡ Step 1. You can remove all objects that are not related to the active CM site and do not have your active CM site code in the object name. Any site objects will be repopulated if accidentally deleted. As a precaution, you can move them to a Test OU for 1 month and purge. Keep in mind that you’ll need the right permissions to delete or move these objects.
➡ Step 2. Remove permissions for decommissioned Site servers that have access to ConfigMgr SQL database. Check to see if old site information exists by running the following queries:
select * from SC_SiteDefinition
select * from Sites
select * from SysReslist
Optional:
➡ Step 3. Remove old Site servers from AD Security Groups (find all the groups they’re a part of, and remove)
➡ Step 4. Remove AD computer objects and DNS entries for any old Site servers that have already been powered off and decommissioned. Otherwise, follow your organization’s decommission process.
➡ Step 5. Verify that your GPO for WSUS Intranet Service Location is set to Microsoft’s Best Practice (Not Configured). The ConfigMgr agent is expected to take over the GPO settings for clients. It’s also important to consider Dual Scan and any other rules you wish to put in place.