How to Change SCCM Parent Site of a SCCM Primary Server and Simplify Hierarchy Part 2

2

This post is continuation of my previous post “How to : Change Parent Site of a Primary Server and Simplify Hierarchy”. Moving a primary site in SCCM hierarchy involves two phases . First one is to detach the Primary server from the Hierarchy and wait until all the objects are unlocked. The second phase is to attach the primary server back to hierarchy but to a different parent site (central site).

Note – https://www.anoopcnair.com/sccm-2007-end-of-support-9th-july-2019/

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

In Part 1, I’ve already detached PR3 site from PR2 site. In this post, I’ll go through the steps which we need to follow to attach primary server (PR3) back to CEN site (central site in the hierarchy).

image

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 advertisement created at PR2 – Tier2 site was also working fine.

Attach Primary server back to hierarchy

I’ve already detached PR3 and all the objects are un-locked. Need to perform following steps to make sure that PR3 site is successfully attached to CEN (central) site.

image

1. Add the system account of Central server (CEN) and Primary server (PR1) to respective local groups (“Administrators” and “SMS_SiteToSiteConnection_CEN”).

2. Now, I need to create the “Standard Sender Addresses” for CEN and PR3 on “PR3 – Tier3” and “CEN – Tier1” sites respectively.

  • Connect to PR3 site and create CEN site Standard Sender Address
  • Connect to CEN site and create PR3 site Standard Sender Address

3. To attach PR3 site (previously this was a Tier 3 Primary server more details at Part 1) back to hierarchy, open up the “PR3 – Tier3 site” properties –> Click on “Set Parent Site” –> Select “Report to parent site” :: “CEN” –> Click “OK”.

image

Attachment is completed. Very easy right? Yes !

4. Check “Hman.log” at “PR3 – Tier2” and “CEN – Tier1” servers for verification.

Attaching site PR3 to site CEN
Creating a new CT6 file to send to the Parent Site

image

Hman.log at “CEN – Tier 1” server

Update the Sites table: Site=PR2 Parent=CEN
Successfully forwarded CT7 file to child site PR3.

Also, you can notice that Sitectrl file has been modified according to add back the parent site information back.Checkout “BEGIN_SITE_DEFINISION” section.

image

5. Lets the site process all the “.SHA” file/s. There could be separate “.SHA” files for each components. However, I’ve noticed SHA file process for the components like Collection Evaluator and SMS Object replication manager. You can verify the respective log files to review status.

Resetting update flags for collection SMSDM005
**********~Processing file PR3.SHA
Deleted site attachment file E:\Program Files (x86)\Microsoft Configuration Manager\inboxes\COLLEVAL.box\PR3.SHA

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

image

6. Make sure that all the objects from “CEN – Tier1” site have been replicated down to “PR3” site server and those replicated objects are locked. Have a look at following picture for more details.

Note: the objects replicated from Tier 2 won’t get locked again. Those objects would stay un locked.

image

7. Verify the central server (CEN – Tier 1 Site). You would be able to see PR2 and PR3 sites under CEN Tier1 site. Hence, we’ve eliminated Tier 3 level in this hierarchy.

image.png

2 COMMENTS

  1. Hi Anoop,
    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.

  2. We too had similar issues with the content no longer being distributed, although the files were present. We chose to trigger replication and saturate our network for 2 days. In hind-sight, we should have a step in there to use the package pre-stage utility on the PR3, so that when you tell CEN to replicate to it, the files are already there.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

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