Jump to content


BzowK

Migrating Clients to New Domain & SCCM Site

Recommended Posts

Hey Guys / Niall -

 

So I manage an environment of ~10,000 workstations and ~900 servers on a single domain. A few months ago, we acquired a new company which has their own SCCM environment on a different domain. Finally, I am wrapping up a build of SCCM on a 3rd domain. The plan is to migrate all clients from the two old domains onto the new one.

 

I have a couple of questions about this procedure so wanted to post to get opinions...

 

1. Migrate Many Clients to New Site Prior to Domain Change

The main question is that their current plan is to migrate the domain on workstations a department at a time over a six month period. While doing so, they want to use my script to migrate each of the workstations' SCCM client while changing the domain. The last thing i want is to have 3 separate and constantly changing environments to manage, so am trying to find the best way to potentially migrate the clients from both old domains to the new one before (like few months in some cases) the domains on the workstations are changed.

 

There's currently a one-way trust between the new domain and both old ones and don't know if I can get them to make it more flexible. Basically, I'm curious what I would need to do in order to achieve the goal above. My experience tells me the below would be needed - at least in theory:

  • Add scope of system's OUs / containers in old domain to discovery on new site
  • Script executed per system to change the site of the client to the new site
  • The SCCM Network Service account to have local admin rights on all workstations (per old domain)
  • Specific DNS records modified / changed to point to the FQDN of the new primary instead of the old ones (per old domain)

Is the above all that would be required, know of any helpful posts related to this, or any suggestions / thoughts?

 

2. Migration of Packages, Applications, etc with New Source Path

I'll be moving a lot of packages and such over to the new environment, but am now using a new "master" share for the sources of all packages, applications, etc. It's simple to migrate an SCCM package from one site to a new one, but when doing so; it retains the same source path for it.

 

Does anyone know of a PowerShell script or overlooked options which would allow me to change just the first part of the source path for migrated packages when moving to the new site? If capable of copying the source content during the migration, that would be ideal; but if not copying it would still be faster than changing each manually. I'm considering simply exporting certain packages, then importing them back in. Will have to play with that a bit more to see how it would work. Suggestions?

 

All 3 sites run SCCM 2012 R2 SP1 CU4. We cannot go to current branch yet due to numerous legacy apps on workstations which don't play nice with .NET 4+. Most site servers (especially on the new environment) run Windows 2012 R2.

 

Any suggestions or comments would be appreciated. Thanks!!

Share this post


Link to post
Share on other sites

Take your pick:

https://www.verboonSPAM!/2013/05/how-to-change-the-sccm-2012-package-source-path-with-powershell/

https://blogs.technet.microsoft.com/cmpfekevin/2013/04/05/configuration-manager-powershell-changing-package-source-location/

http://blogs.catapultsystems.com/chsimmons/archive/2016/09/28/configmgr-content-source-path-migration/

Or just instantly download Nickolaj Andersen's ConfigMgr Content Source Update Tool 1.0.2

 

I have done something like that on much smaller scale (and with single domain, just site change due to Server upgrade via migration)

 

Used GPO (so I could do the change per sub-OU of workstations) to adjust local hosts file (I found by testing that I needed this - point old site IP to new site DNS name, no idea why!), and vbs script to assign new site

 

Once the GPO gets assigned to OU, on next policy refresh, workstation changes site, uses the local hosts DNS entries and on reboot it no longer exists in old site, but registers in new site

Share this post


Link to post
Share on other sites

Really useful thread here as I am currently doing this with a client on CB2002 to CB2002. I do have some questions though which I am unsure about which I am hoping someone can validate for me. I am currently doing a source hierarchy migration from 2002CB to 2002Cb in 1 forest trust with 2 domains. I done in a way so that the new site server mirrors the old one as much as possible. Apart from the server OS which is 2016 as opposed to 2012 in the old environment. 

There are 4 DPs in the source and I can see they are all eligible for re-assignment however my question is if those servers sit in the old domain but I need to move those servers in the new domain. What would be the best approach? 

I assume the only way would be to recreate those DPs in the new domain against the new site code? Is there a way to migrate DPs from source to new destination DP or is it case of introducing the new DPs in the destination hierarchy and then just ensure they have the DP role and then ensure the content is populated onto that DP before the old is decommissioned? 

Also currently the old DPs are serving PXE for OSD deployment so I believe before that is done the DHCP or switch helpers will need to point to the new DPs so that process can continue, would that be correct?

I look forward to any responses.

Many Thanks

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.