Patching Rings for Windows 10

Here is a chart showing the patching cadence of the different rings.

Deployment ring Servicing channel Deferral for feature updates Deferral for quality updates Example
Preview Windows Insider Program None None A few machines to evaluate early builds prior to their arrival to the semi-annual channel
Targeted Semi-annual channel (Targeted) None None Select devices across various teams used to evaluate the major release prior to broad deployment
Broad Semi-annual channel 120 days 7-14 days Broadly deployed to most of the organization and monitored for feedback
Pause updates if there are critical issues
Critical Semi-annual channel 180 days 30 days Devices that are critical and will only receive updates once they’ve been vetted for a period of time by the majority of the organization

Resolving: Service Manager (SCSM) 2016 not displaying Reports via Console

If you are here is because you have deployed your 2012/2016 environment and you realize that your Reports are not visible/accessible via the SCSM Console.


On the Management Server saw this error under the Operations Manager Log.
Source: Console Operations
Event ID: 33569
Cannot connect to SQL Reporting Services Server.  Message= An unexpected error occured while connecting to SQL Reporting Services server: System.Net.WebException: The request failed with HTTP status 401: System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)at Microsoft.EnterpriseManagement.Reporting.ReportingService.ReportingService2005.FindItems(String Folder, BooleanOperatorEnum BooleanOperator, SearchCondition[] Conditions at Microsoft.EnterpriseManagement.Reporting.EnterpriseReporting.FindItems(String searchPath, IList`1 criteria, Boolean And)at Microsoft.EnterpriseManagement.Reporting.EnterpriseReporting.FindItems(String itemPath)at Microsoft.EnterpriseManagement.Reporting.EnterpriseReporting.FindItem(String itemPath, ItemTypeEnum[] desiredTypes) at Microsoft.EnterpriseManagement.Reporting.EnterpriseReporting.GetFolder(String path) at Microsoft.EnterpriseManagement.Reporting.EnterpriseReportingGroup.Initialize()at Microsoft.EnterpriseManagement.Reporting.ServiceManagerReportingGroup..ctor(DataWarehouseManagementGroup managementGroup, String reportingServerURL, String reportsFolderPath, NetworkCredential credentials) at Microsoft.EnterpriseManagement.Reporting.ServiceManagerReportingGroup..ctor(DataWarehouseManagementGroup managementGroup, String reportingServerURL, String reportsFolderPath)  at Microsoft.EnterpriseManagement.UI.SdkDataAccess.ManagementGroupServerSession.TryConnectToReportingManagementGroup()  Remediation = Please contact your Administrator.



If you are getting this error is because you haven’t registered the SPN’s and delegated the appropiate permissions to Service Manager and Reporting Services.

Open Command Line as administrator on the Management Server

Run the following commands:

This command will set the appropriate SPNs that are needed for SCSM and SSRS.

Setspn -A HTTP/  DOMAIN\SCSMServiceaccount

To list the SPNs
Setspn –L DOMAIN\SCSMServiceaccount


SCSM MP migration that will break your install

I ran into some MP’s that after importing into a new environment found out the hard way will break your install.

User Roles
Linking Framework
Service level objects

Sadly there is nothing documented at MS to advise against importing these, And the system will actually let you import them. However if you do import them, you will get unexpected results. For instance, when I imported the SLO MP, my system would not allow me to create a AD connector.  I had to actually open a case with MS to undo the damage caused by importing these MPs.


Always keep your critical apps up to date

First a little bit of background.  My current project has me working at a federally regulated power company. (We’ll call them PowerBiz for anonymity sake) They are also publicly traded and accept credit cards so to say they have to be secure is an understatement.  They use a product called Bit9 as part of their protection strategy.

Bit 9 is a great product that is used for application white listing.  However it is a resource hog and a bit difficult to work around unless constant care and feeding is performed.  Part of that care and feeding is to keep it on the latest patch level as well as keep it “right sized” for your environment.

Now I have been fighting with getting a Win10 1803 image built for PowerBiz. As part of that build process PowerBiz wants to make sure that Bit9 is implemented the instant the image is laid down. to accomplish this, PowerBiz has set up their capture process to include the Bit9 parity agent installation and synchronization. This way there is never an instance of a computer being on the network without Bit9 installed. This is great saves me the trouble of having to build in wait steps to my imaging process. Not a problem Right? Wrong! as it turns out, PowerBiz is on an older version of Bit9. 7.2.3 to be exact. This version does not support 1803 much less even 1703. In order to bring it to a supported state, the Bit9 infrastructure would have to be raised to 7.2.4. Due to hardware constraints and the possible lack of knowledge regarding making hardware adjustments in a virtual environment, the bit9 infrastructure is not right sized for the current load and therefore would be directly impacted by patching.  This means in summary that PowerBiz is not going to be updating their environment until they can go through the process of building out a NEW environment

Having said all that, the troubleshooting to discover the above was a bit painful.  Nothing was being written in the SMSTS logs other than the task sequence failing with an obscure error code.  However this error code led me to the true source of logging used in the “configure Windows” step, the Setup.etl logs.  These logs though difficult to translate were a goldmine of information.  I had to first translate these from the .etl to something a little more readable.  this is where the command  tracerpt setup.etl -of csv came in handy.  This command converted the etl into 2 files, dumpfile.csv and summary.txt.  The first file is where I found the gold.  I did a quick search for the word “error” and came up with the following entries:



“(c0000022): Failed to open child key: [Bit9]”


“(c0000022): Failed to process reg key or one of its descendants: [\REGISTRY\MACHINE\SOFTWARE\WOW6432Node]”


“(c0000022): Failed to process reg key or one of its descendants: [\REGISTRY\MACHINE\SOFTWARE]”

These entries or variants of the were repeated numerous times in the setup.etl logs.

This find led me to a discussion with the Bit9 SME who followed up with Carbon Black to find out the above mentioned support status.

Long story short.  Keep your critical applications updated so that they are always under support as well as allow support of OTHER critical applications.


Windows 10 OSD Error: Windows Could Not Finish Configuring The System

I have been hitting this error for several days now and finally came across the resolution.

I came across this very unexpected error message when my VM rebooted right after the Apply Operating System action while running a task sequence to install a custom Windows 10 image with an answer file:


Long story short, the clue to resolving this lies in the setuperr.log file in the C:\Windows\Panther\UnattendGC directory. Since I was using a VM I simply attached the .vhdx disk using Disk Management and browsed to this directory to take a look. This is what the contents of the setuperr.log looked like in my case:clip_image004_thumb1

[Shell Unattend] ProductKey: ‘XXXXX-XXXXX-XXXXX-XXXXX-XXXXX’ installation failed (0xc004f050)

I ended up having to remove the entire <ProductKey></ProductKey> entry from the unattend.xml answer file to resolve this problem. Simply removing the product key within the opening and closing brackets didn’t cut it. I had to remove the entire line from the answer file and add the product key to the task sequence instead (in the Apply Windows Settings step).

[windeploy.exe] Failure occured during online installation. Online installation cannot complete at this time.; hr = 0x80004005

The resolution to this one is plain weird. If you have a space in the value within the <RegisteredOrganization> </RegisteredOrganization> and <RegisteredOwner></RegisteredOwner> entries in the unattend.xml file Setup will stop in its tracks when attempting to apply the answer file after the Apply Operating System action. I ended up having to remove “Me, Myself and IT” and settling with “EMENEYE” instead.

[windeploy.exe] Setup.exe failed, returning exit code [0x1f]

This one must’ve been related to one of the above error messages since after having made the above changes to the answer file I had no other problems.

Your mileage may vary but this is the process I went through to resolving this problem. I hope someone somewhere finds this useful.

Manual removal of SCCM client

If you need to remove the client you can do so fairly easily by running ccmsetup.exe /uninstall.  Ccmsetup should exist on all clients, usually under the windows folder.  In the event that the command line doesn’t work here is a list of things I usually check and remove to manually clean-up all the traces of the client so I can try a fresh install.


1. SMS Agent Host Service

2. CCMSetup service (if present)

3. \windows\ccm directory

4. \windows\ccmsetup directory

5. \windows\ccmcache directory

6. \windows\smscfg.ini

7. \windows\sms*.mif (if present)

8. HKLM\software\Microsoft\ccm registry keys

9. HKLM\software\Microsoft\CCMSETUP registry keys

10. HKLM\software\Microsoft\SMS registry keys

11. root\cimv2\sms WMI namespace

12. root\ccm WMI namespace

13.  In Task Scheduler library, under “Microsoft” delete the “Configuration Manager” folder and any tasks within it.

14. In the Machine Certificate store delete any certs under the SMS\certificates folder