How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr

How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr. SCCM 2007 End of Support 9th July 2019 Get Ready for Upgrade

Through this post, I’m trying to perform an impact analysis of changing the parent site of a primary site (Move a primary site in SCCM hierarchy).

How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr

This process involves two phases first one is to detach the Primary server from the Hierarchy and wait until all the objects are unlocked. The next phase is to attach the primary server back to the hierarchy but to a different parent site (central site).

Patch My PC

SCCM 2007 End of Support 9th July 2019 Get Ready for Upgrade

How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr
How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr

Introduction

In this post (Part 1), I’ll cover “how to detach primary server from its parent site”. Part 2 is available now.

I’ve 3 tier hierarchy which consists of 3 primary servers. I want to detach the “PR3 Tier 3” server from the “PR2 Tier 2” and attach the “PR3 Tier 3” server to Central Tier 1 sever.

In real world scenario, this would help to simplify your hierarchy if you’re not utilizing Tier 2 server much.

  • 1. Central Site (CEN – ACNSCCM07PRI) – Tier 1
  • 2. Child Primary Site (PR2 – ACNSCCM07PRI2) – Tier 2
  • 3. Child Primary Site (PR3 – ACNSCCM07PRI3) – Tier 3
How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr
How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr

Note: During this analysis (in each phase), I’ve tested the client (which is assigned to affected site PR3) functionality. Everything was working fine and even the advertisement created at PR2 – Tier2 site was also working fine.

 Detach Primary server from it’s parent site

As you can see in the below picture, the collections, packages, Advertisements, Software Update objects, and Operating System Objects (which are replicated down from “Tier1” and “Tier 2”) have been locked at the “PR3 Tier 3” console.

image
image
image

For testing purposes, I’ve created separate collections, packages, advertisements, etc.. at each level Tier 1, Tier 2, and Tier 3. So that it would be easy to understand after breaking the parent-child relations. Have a look at the above picture for more details.

1. To detach the Tier 3 Primary server from the hierarchy, open up the “PR3 – Tier3 site” properties –> Click on “Set Parent Site” –> Select “Central Site” –> Click “OK”.

image

Detachment is completed. Very easy right? Yes!

2. Check “Hman.log” at “PR2 – Tier2” and “PR3 – Tier3” servers for verification.

Detaching site PR3 from site PR2
Sent the actual site control image to site PR2
Processing site control file: Site PR3 File E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\hman.box\WMNUDEUJ.CT2
Update the Sites table: Site=PR3 Parent=
There is no parent site, no need to forward any site control images.

image

Hman.log at “CEN – Tier 1” server

Site PR3 is detaching from site PR2
Deleting site PR3 from the site control and sites table as a result of site PR3 detaching from site PR2.

Also, you can notice that the Sitectrl file has been modified as you can in the following picture.

image

3. Now, you need to delete the “Standard Sender Addresses” for PR2 and PR3 from “PR3 – Tier3” and “PR2 – Tier2” sites respectively.

  • Connect to PR2 site and delete the PR3 site Standard Sender Address
  • Connect to PR3 site and delete the PR2 site Standard Sender Address

4. Remove the system accounts from respective local groups (“Administrators” and “SMS_SiteToSiteConnection_PR2”) of both “PR3 – Tier3” and “PR2 – Tier2” servers.

5. Wait until all the “.SHA” file/s processing to finish. There could be separate “.SHA” files for each component however, I’ve noticed it for the components like Collection Evaluator and SMS Object replication manager. You can verify the respective log files to review the status.

Resetting update flags for collection SMSDM005
**********~Processing file PR3.SHA

This process would take time depending upon the objects (collection, packages, Adverts, Software Update and Operating system Objects, etc..) in your environment. This process will change the settings of all these objects and REMOVE the lock symbol on those objects.

image

6. Once the detachment process is finished, you’ll see all the objects at the “PR3” site server is un-locked. Have a look at the following picture for more details.

image
image

7. Verify the central server (CEN – Tier 1 Site). You would be able to see only the PR2 site, which means the PR3 site has been removed successfully from the hierarchy.

image

To be Continued….. Part 2

Author

Anoop is Microsoft MVP! He is a Solution Architect in enterprise client management with more than 20 years of experience (calculation done in 2021) in IT. He is a blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. E writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc…

3 thoughts on “How to Change Parent SCCM Site of SCCM Primary Server and Simplify Hierarchy ConfigMgr”

  1. Although your steps were documented well things don’t seem to be so easy as mentioned.
    As detaching a grandchild primary [PR3] is a one-click process the replication was not.
    Within our environment [SCCM 2007 hierarchy with tier 4 with 100,000 clients] this took more than 3 hours and had quickly raising of 100,000 replication files.
    Making the site [PR3] a stand-alone one by detaching is primary target, but will impact more necessary steps within your ‘To be Continued…..Part 2’.
    In addition central site [CEN] database will lose the reference to the elevated primary [PR3] and even worse site system roles, e.g. Distribution Points, will be deleted out of any software package and Distribution Point Groups.
    Attaching back the site [PR3] as tier 2 did last another 12 hours [Backlog of 2 GByte of replication files].
    Next we had to adjust the child primary sites [PR3] database with:
    update pkgservers set sourcesite = ” where sitecode in (”, ”, ”,…)
    and copied the content from pkgservers and pkgstatus back to the central site [CEN] database through a export|import functionality with a temp database in order to avoid duplicate keys.
    Supported way would probably be to add all missing Distribution Points back to every package, in our case n > 6000, and start an update.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.