This was a bit tricky! We completed an SCCM upgrade for one customer from SCCM 1511 to 1602, and made use of the nice pre-production client validation feature.
This allows you to specify a collection of test systems to receive the new SCCM client, for you to validate in your environment.
After a few days of validation, we were ready to pull the trigger and upgrade everyone. This is done under Administration \ Cloud Services \ Updates and Servicing \ Client Update Options. However, when we tried to do this, it was grayed out!
Before trying to upgrade the client, I thought we should un-check the pre-production Collection box in Hierarchy Settings. This is done in Administration \ Sites\ Hierarchy Settings.
Don’t do this! If you uncheck this box, the SCCM ui will detect it, and gray out the SCCM won’t display the UX we need to promote the SCCM client to production.
Make sure that you check the Pre-production client box. If this isn’t checked, SCCM doesn’t know to show you the UI for upgrading the client across production!
Once this is done, you can go to Updates and Servicing, and click Client Update Options.
Complete this UI and SCCM will automatically uncheck the pre-production client for you as well. Thanks SCCM!
Recently for a customer, we ran into an issue in which the SCCM 1511 upgrade was hanging at the following screen.
If we open the SCCM install log file on the primary site, found at C:\ConfigMgrSetup.log, we will see the following message:
This step should only take a few minutes to complete, if you’ve waited a while, like 20 minutes for us–then go ahead and help SCCM out.
It’s trying to kill the SMS Component Manager service, and the SMS Exec service. If you’ve got a complex environment, it can take a long time to complete this step. Go ahead and stop the services manually using the task manager.
If this doesn’t work (it didn’t work for me, the services hung at ‘stopping’), you can use powershell to kill the service instead.
From the Task manager, look at the process ID for your SMS component manager service, and then run
Ever run into this issue where you can’t save a report you’re editing in the report builder?
“Failed to save report (report server URL). The sortExpression Expression for the grouping refers to the field ‘ProductName’ Report item expressions can only refer to fields within the current dataset scope’
This is a REALLY irritating one. It happens when you edit a copy of one of the in-box SCCM reports and change the columns being returned. Without us knowing it, there are a lot of settings customized that allow us to click on the top of each column to sort the rows based on our preferences.
When we change the columns returned in an apport, we need to also update the header textbox for each column.
To fix this, right click up here, and go to interactive sorting and click each <<Expr>> box, then choose’Text Box Properties’
And go to Interactive Sorting. You might notice that the value listed in the box is no longer relevant to the rows you’re returning in your report now. (Happens to me ALL the time, I always find a good starting report, then save a copy and edit (it’s so hard to get the background looking pretty!))
Especially if you edited a built-in report, you’ll need to do this for the header of each column. That means each of these guys:
With this done, you should now be able to save the report again.
My view differs slightly from my peers in that my background is in Enterprise Client Management, and I’ve been deploying SCCM since 2011 for customers into the tens of thousands of desktops and servers.
However, I also love to code, so maybe my perspective will help the concepts gel for you.
In my mind, this debate is not really about which tool is the one-true king to use in all cases, but rather about highlighting the strengths of each and noting when they should be used. I’ll also describe how you deploy operating systems using each product as well.
It’s all about the evolution of tooling
First the Earth cooled, then we got GPO
For all practical purposes, the first true large scale management tool we had for Windows systems in the modern era was Group Policy, or GPO as it is commonly truncated. This stemmed from Local Security Policy, which is a fancy GUI to control system settings via special registry keys which are locked down from general user editing. Local Security Policy could be shared among systems in a Workgroup which was a big improvement from setting the same configuration on each system. Continue reading →