SCCM 2012 migration – a few tips

Last month I started our migration from WSUS to SCCM 2012. I plan on taking a good 3 months to slowly migrate our 200 servers over. We are in no hurry and I want to make sure I have everything set up correctly. Here are a few specific gotchas I ran across this last week.


 

First of all, here are my migration steps – they are very simple:

1. Move the Server object from our ‘Servers’ OU to a sub-OU called ‘Migrated’. I have a GPO tied to this OU that sets the following:

  • delete reg key: HKLM\software\policies\microsoft\windows\windowsupdate\TargetGroup
  • delete reg key: HKLM\software\policies\microsoft\windows\windowsupdate\TargetGroupEnabled
    • NOTE: both of these are settings related to WSUS. we don’t want to wipe out everything for WSUS because SCCM utilizes some of these settings and we don’t want Group Policy overwriting them! This is the bare minimum to get it working and should be all you need.
  • Add local admins: computer account of SCCM server and service account for client push

2. Add the Server object to the appropriate AD group (for maintenance window)

  • We are using maintenance windows for patch deployments. I found it easiest to create a security group for every maintenance window (MW). In SCCM, they are tied to query based collections that have the MW set.

3. Wait! (be patient as GPO has to run and the client has to be installed. this will typically take anywhere from 10 min to 2 hours depending on your settings)

*I also have client push enabled.

Once you have a few things configured and set up prior to the migration, you can see that the migration is quite quick and simple! One more thing to


 

Now for the gotchas.

#1:   I originally set up system discovery to target the ‘Servers’ OU. This was to weed out the computer objects because we are not putting them in SCCM (don’t ask why!). I found out that I should instead target the sub-OU ‘Migrated’. This is because once a server is discovered and client push is enabled, SCCM will try to push the client once and hour for up to a week. After that it will stop trying! You will have to either manually push it or delete the object and wait for it to be redisovered.

I found it easier to just change the system discovery to target the sub-OU instead that way the machines wont make it into the SCCM console until I move them to my migration OU. I then deleted all of the servers that didn’t have the client yet then re-ran the discovery

*Once the migration is complete, be sure to move all servers back to the original OU, adjust the GPO, and change the discovery back to the top level OU.

#2:   With software updates, I decided to use the model of sending out updates once a month. but I also have a software update group full of ‘baseline patches’. This contains every patch (based on our filters) deployed PRIOR to us switching to SCCM. I have this set as a static deployment to a collection called ‘All Servers’.

What I realized is if we have a new server and it automatically has the client installed, if we forget to add it to a MW (or don’t get to it fast enough), that machine will take those updates and install them ASAP (they are set to install ASAP, but with MWs the machine will wait; without a MW, it installs within 24hrs)

What I did instead, was create a collection that contained all of my MW collections. I then changed the deployment on the ‘baseline updates’ to target this collection. This ensures that servers added to SCCM won’t get any patches until they are added to a maintenance window!

baseline

akers8806

Leave a Reply

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