October 15th, 2020
January 24th, 2020
Starting SCCM build 2002 Microsoft have introduced a new feature called Orchestration groups. You can find information about Orchestration groups here: https://docs.microsoft.com/en-us/mem/configmgr/sum/deploy-use/orchestration-groups.
The principal of Orchestration groups work is: you arrange several machines in a cluster, set an order and during the maintenance window SCCM deploys software updates in a pre-set order. There is also a possibility to run pre- and post-execution PowerShell script on each member.
However what Microsoft have overlooked is that if you are using Windows Defender as your primary Antivirus solution and distribute updates using ADR, Orchestration group would also consider Windows Defender updates as Windows Updates and because Windows Defender updates ADR is set to override the maintenance window, the next Windows Defender update will trigger Orchestration group in the following fashion:
- Windows Defender update triggers Orchestration group on Node 1 or Set 1.
- Orchestration group executes pre-deployment script on Node 1 or Set 1.
- Windows Defender update is deployed.
- There is no maintenance window so security updates are not deployed.
- Orchestration group timeout has expired and the group goes to ‘Failed’ state.
This issue is repeatable and was reported to Microsoft.
August 21st, 2019
During the scheduled SCCM CB uplift we have observed the following issue: after the uplift SCCM Administration console started to crash on very specific property pages, i.e. Windows Updates client settings or scheduling regular OS image file servicing. Before the crash the console was giving us .NET errors saying that specific properties of WMI objects were not found.
The specifics of our environment is that we have SMS Provider installed on two redundant Management Point role servers and no SMS provider on the site server. Turns out that during the uplift SCCM does not update the smsprov.mof file on standalone SMS Providers.
The workaround is as follows:
- Verify whether or not <SCCM install dir>\bin\x64\smsprov.mof file is the same on the primary site server and on every standalone SMS provider server
- If and most likely not, replace smsprov.mof file on standalone SMS provider servers with the newer smsprov.mof found on the Primary Site Server.
- Compile smsprov.mof on each SMS Provider server with the command mofcomp smsprov.mof.
May 8th, 2019
When you are planning for SCCM uplift to the build 1906 you must note that starting version 1906 SCCM client requires SHA-2 code signing support. What does that mean for you? It means that if your managed environment still have Windows 6.x OS systems (Windows 7, Windows 2008 and Windows 2008 R2), these systems require SHA-2 code signing support enabled. But do you really need to raise a change request and update legacy systems which are sooner or later will be decommissioned? There is another option. As you know SCCM client has ‘forward’ compatibility with newer infrastructure. That means that even older clients will work with SCCM 1906 but with the limited functionality. Microsoft call that feature ‘Extended Interoperability’ (EI). The following clients are recommended EI clients:
- 1902 (5.00.8790)
- 1802 (5.00.8634)
- 1606 (5.00.8412)
I have selected the version 1902 as EI client for my environment which still contains a number of Windows 2008 R2 systems. To get my EI client in SCCM console I have selected both 1902 and 1906 updates for download. I need 1902 only as a source of EIC. The client binaries can be found in EasySetupPayload\<Configuration Manager 1902 Package GUID>\SMSSETUP\CLIENT. You have to copy all these files to the separate location because after the uplift to version 1906 this location will disappear. Then you have to create a collection for all your Windows 6.x OS systems and exclude this collection from the upgrade: Now you have to upgrade the SCCM client on Windows 6.x systems by any mean. The client ver. 1902 will be capable to perform the main functionalities: software deployments, software updates and hardware inventory. The question is: would you be able to deploy the EI Client using SCCM. The answer is: yes! Package your EI client. Add a one-line cmd file to your package:
CCMSETUP.EXE /noservice /IgnoreSkipUpgrade /skipprereq:silverlight.exe SMSSITECODE=<site code> /source:%~dp0
Keep in mind that all your legacy systems must be in excluded from the automated client upgrade. /IgnoreSkipUpgrade switch will override this setting. Another important thing to know is that if the client version is older than the infrastructure version, ccmsetup exit code will be 7 instead of 0. However I have noticed that you don’t have to capture this exit code because your SCCM Client will be shut down and reinstalled. Application deployment cycle will detect the presence of the upgraded client during the next poll.
December 5th, 2017
One of the most annoying problems on the SCCM client is when several applications stuck in ‘Waiting for install…’ state for days. Sometimes the reason for that is that one application is not distributed to the Distribution Point and for some reasons in SCCM build 1710 and older it blocks entire queue and does not allow other applications to install even though they are downloaded.
Here are 3 simple steps which would allow to identify the problem.
1. Identify that at least one application cannot be downloaded. For that go to SCCM client cache folder. There should be outdated .BDRTEMP folder:
2. Go to ContentTransferManager.log Look for the suspended job. Trace the log to find the corresponding ContentID
3. GoTo AppDiscovery.log and identify the application name by ContentID
Check if that application was correctly distributed.
December 5th, 2017
Sometimes when you try to download a new SCCM update in Updates and Servicing node it may stuck indefinitely in “Downloading” state. When you check dmpdownloader.log you may see the following error:
ERROR: Failed to download redist for 0f11caa4-7f7f-454b-96d6-75f427d015ce with command /RedistUrl http://go.microsoft.com/fwlink/?LinkID=857597 /LnManifestUrl http://go.microsoft.com/fwlink/?LinkID=854716 /RedistVersion 201706 /ProxyUri http://companyproxy:81/ /ProxyUserName CONTOSO\SCCM_Admin /ProxyUserPassword 3082018F06092A864886F70D010703A08201803082017C020102318201303082012C0201028014A8 /NoUI “\\SCCM01.contoso.com\EasySetupPayload\0f11caa4-7f7f-454b-96d6-75f427d015ce\redist”
This error is not very descriptive however it indicates the problem with SCCM prerequisites download. Additionally when you go to Program Files\Microsoft Configuration Manager\EasySetupPayload folder you would see both 0f11caa4-7f7f-454b-96d6-75f427d015ce folder and 0f11caa4-7f7f-454b-96d6-75f427d015ce.cab file. The code may be different depending on the upgrade.
The root cause of this issue is your firewall or proxy or something else which blocks specific files from downloading assuming this is a security threat. The workaround is:
Go to 0f11caa4-7f7f-454b-96d6-75f427d015ce\SMSSETUP\BIN\X64 ad copy SetupDL.exe to the computer with has unprotected access to Internet. Run SetupDL.exe <Destination folder>. Once download is completed, copy all files and folders structure to 0f11caa4-7f7f-454b-96d6-75f427d015ce\redist folder and run updates check or (better) restart SMS_EXECUTIVE service. SCCM will detect your files and 0f11caa4-7f7f-454b-96d6-75f427d015ce.cab file should disappear.
If you do not have “clean Internet” running SetupDL.exe output would at least give you an indication what file cannot be downloaded. In that case download ConfigMgr.Manifest.cab and ConfigMgr.LN.Manifest.cab using links from the error message above (/RedistUrl http://go.microsoft.com/fwlink/?LinkID=857597 and /LnManifestUrl http://go.microsoft.com/fwlink/?LinkID=854716), unpack both cab files, open .xml manifest files in Notepad and download every missing prerequisite file individually using HTTP links from the manifest files.
Just a quick note. You may miss several SCCM branches and are still on version 1602 or 1606 of SCCM. Despite stated by Microsoft direct upgrade from Branch 1602 to 1706 is not possible. The maximum version you can upgrade from Branch 1602 is 1702 (even though you can see versions 1706 and above in the manifest file). So the actual upgrade would be three steps process: from 1602 to 1702, download 1706 and from 1702 to 1706. Same applies to the branch 1606.
Keep this in mind when planning for SCCM upgrade.