In my case the customer has required to install a new CAS to PRI infrastructure, as the old one was to be decommissioned.
Once the Setup and creation of the SQL environment is finished you ask yourself how to integrate all the clients and servers under the new umbrella.
Now according to Microsoft there are several options : https://docs.microsoft.com/en-us/sccm/core/clients/deploy/deploy-clients-to-windows-computers
All fine till there, but what if the customer had WMI Corruption Incidents with the rollout of the SCCM Agent in the past and you discover servers are still using an agent with Version 1000 or 1007 ?
—Test, Test and Test again—
Comparison of 1711 to 1007 :
As in the case of WSUS I cannot see any difference between the versions, not even a colour difference.
Tested Updates, application and package deployment and reports.
The tests revealed that compared to v1711, the very old version is still working flawlessly, so all I had to do was go inside the CM Agent and click on Find Site ( on the Servers side as on the Workstation side there is usually no real impact, automatic upgrade is fine):
Naturally, it will also need the Boundary Groups to be configured properly. So you remove the subnet from the old Site , drink a coffee and than add it to the new Site.
As soon as you have done that, the Find Site button will throw the following message:
In the following Minutes inside the SCCM Console ,the client will be assigned a Question Mark ,as it is starting to communicate with the agent.
You can test if all went well by initiating a Start-> Remote control of the Server. If the option is configured and it connects, it seems to be on the right track.
You can script the click of the Find Site button ,once the Boundary Groups are adjusted and add several clients in the script execution, that way you can do many at the same time and no intrusive action is executed on the clients ( Again test the Script properly before deploy).
Now this possibility is not the usual admin way ,but in the several scenarios I have used it had 0 Incidents associated.
Once the Old CM Agents have been assigned the New Site and your Production environment is up again, you can make a selection of Collections or a selection of Clients that is safe to upgrade to CM version 1711, insert them in a script or deployment and launch the Ccmsetup. The Ccmsetup needs usually to be on an open share so your script does not need special treatment from network or security, makes things easier).
Once you scripted your way to upgrading all your CM agents you can monitor the status and percentage of your windows updates and many more with the default reports. You can also build custom reports in case of exotic business needs.
Do not forget to monitor the status of your agents ( active or inactive as often as possible).
Inside the CM Console -> Monitoring check at least daily if Syte Sync is ok and if all components are green.
My next article will be about how to block an update via SCCM and WSUS as the March and April 2018 Updates from Microsoft seem to set all updated clients to DHCP and there is still no fix in sight