ConfigMgr: System Management Container Cleanup

If you’re looking to build a Production or Lab environment for ConfigMgr (MECM), and are following step-by-step tutorials from guru’s such as PrajwalDesai, Anoop C Nair and System Center Dudes, chances are you will be asked to create the System Management container, and assign permissions to the ConfigMgr computer account.

What is the AD System Management container used for?

When you extend the Active Directory schema for Configuration Manager, you introduce new structures to Active Directory that are used by Configuration Manager sites to publish key information in a secure location where clients can easily access it which provide benefits such as:

  • 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

Reference: https://docs.microsoft.com/en-us/configmgr/core/plan-design/network/extend-the-active-directory-schema

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 MMC under your Domain (e.g. torontoit.co) > System > System Management. Prior to building your CM site, you would manually create the System Management container using ADSI Edit MMC (if it doesn’t exist already) and provide permissions to the CM site server computer account.

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

Reference: https://docs.microsoft.com/en-us/previous-versions/system-center/configuration-manager-2007/bb693614%28v%3dtechnet.10%29

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 only have 1 x mSSMSManagementPoint object in this container.

What becomes problematic here is if your organization had older sites in the environment that were not decommissioned correctly. As a result, you will see objects with previous Site Codes in this container.

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

System Management 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.

Leave a Reply

Your email address will not be published. Required fields are marked *