ConfigMgr 2012 Windows Update Client Process

This is a high-level view of the Windows Update process from a ConfigMgr clients view utilizing a SUP (Software Update Point).

The Software Update process from the ConfigMgr client


Following the flow

After refreshing machine policy, kick off the Software Update Scan. We can then see the Software Update Scan Cycle has started via the WUAHandler.log (C:\Windows\CCM\Logs\WUAHandler.log)


The Windows Update Handler initiates the Windows Update service against the ConfigMgr SUP. (C:\Windows\WindowsUpdate.log)


After the scan is completed, we then run the Software Update Deployment Evaluation Cycle. Use the UpdatesDeployment.log to view this process (C:\Windows\CCM\Logs\UpdatesDeployment.log)


The Content Access Service finds the content on the CMPRI-MATTSLABS Distribution Point and downloads it


Update Deployment attempts to install updates, Service Window Manager blocks the installation (C:\Windows\CCM\Logs\UpdatesDeployment.log)


Service Window Manager blocking the installation (C:\Windows\CCM\Logs\ServiceWindowManager.log)


And when the window opens, the updates should install. Check the UpdatesDeployment.log


Also, the WindowsUpdate.log success


And reboot if required (and scheduled)



Update: An ex-colleague reached out to me to add some extra info around the process for the SCEP update trigger. As my SCEP knowledge isn’t the greatest, it’s something I’ll be sure to remember and very helpful for the community.

The key difference that I can see is that the SCEP definition update initiates from the AntiMalware Policy configuration, not from the EndPoint client settings where I expected to see it, or the from Software Updates Schedule client setting.  As opposed of course to Software Update scanning and installation as per your post.  Also triggering a manual SCEP definition update is only done from the SCEP client and not the SCCM client actions from what I’ve seen so far.

Collection Commander add on

Install updates waiting in Software Center


Deploying Adobe Flash Player (currently with SCCM2012 (Current Branch) previously removing all old versions.

I have been managing software deployments and updates/patching with SCCM 2012 (latest version 1607) in our organization with about 5300 workstations in the production environment. We have 3rd party software (Shavlik) installed to manage software updates, but I noticed that it is not always perfect for situations where multiple major versions of the software is installed. During my testing I tried to deploy Adobe Acrobat Reader DC to replace Reader 11 and Adobe Flash Player replace older versions of Flash (we had some old ones like 13, 15, 18, 21, 22).  After the patches deployment, I noticed that it will bring up the patch level to the current one , given it’s been approved and downloaded in Shavlik. In other words, it will not upgrade the major version of the product ( from Adobe Reader 11 to DC , or from Flash 18 to 23). Configuring SCCM application with just plain .msi installer also doesn’t remove older major versions of the Flash players.

So, I had to come up with the solution to remove older version and install new one during deployment process.

I decided to use powershell script to handle that installation/upgrade process, and then deploy it within an application (not the package or Task Sequence).

Here are two scripts I used to deploy (ActiveX and Plug-in):



I also have mms.cfg file (config file that disabled Auto-updates) in the same folder:

I created my source directory for this application and placed all files in there.

After downloading .msi installer files from Adobe distribution site into the same source directory on your network source location I  had 5 files in the same folder:xDX7V4.bmp

Once all files are ready, I created 2 applications: one for Adobe Flash Player ActiveX (for IE), and second one for Adobe Flash Player Plug-In ( for Firefox, etc.) .

For each application, I started Create Application Wizard and followed all steps pointing to correct location, and the .MSI installer (for …Active_x.msi or …Plugin.msi in the directory above). After its completed, I just modified  Application Catalog, User Experience, and Requirements (not to deploy on Windows 8.x or Windows 10 for ActiveX – Plug-In version can be deployed to Windows 8.x and 10) and Programs of the Deployment Type to start correct .ps1 scripts with powershell.

Here how ActiveX app properties look like:


You can use your favorite search engine to look for and download Icon for you application to be displayed in the Software Center.


Here is how my Deployment type looks like:




As for the Installation program I have this command:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -WindowStyle Hidden -ExecutionPolicy Bypass -file .\Install_Flash_ActiveX.ps1

( Keep in mind, If your company policy for powershell execution is set for signed or remote signed, make sure to modify the install command to reflect that and sign those PS script files).

And for uninstall program: msiexec /x {6E6D2BB7-B844-4842-B62D-0A7F0AA7884E} /q (that code could change if you have different version of the installer .msi file or different language) – just browse to that .msi file during creation of the Application wizard to get correct code auto-generated here.

Detection Method was automatically generated during the Create Application Wizard too.




In the Requirements tab I limit deployments only to those 3 Operating Systems: Windows XP, Vista, 7.

Adobe Flash Player ActiveX cannot be installed on Windows 8.x and Windows 10 with .msi installer. They should be upgraded with Windows Update.

You can specify Application Supersedence, If you have older versions of the Flash Player deployed with SCCM. Please note that this selection is irrelevant to which version will be uninstalled with the script. It will just mark this application as superseding one of those older versions you might have deployed prior. When you deploy that script , you don’t have to worry about making sure that “Uninstall Program” of your old Applications Types works.  Powershell script checks for all older versions of the apps, uninstalls them then installs new version.


After application is created, distribute content to your Distribution points, retire old versions of the Adobe Flash Player applications and deploy your new Application. Also, If you install Flash Player during OS Deployment, don’t forget to update your Task Sequences to install your latest applications.

P.S. I use those powershell scripts with some minor modifications to deploy other software. It captures return code of the .msi installer and passes it the SCCM. Some installers (not those for Adobe Flash players described above) require computer reboot. By modifying return codes (which is passes on the script end), depending on that return code in the Application Deployment Type properties you can configure to let SCCM handle reboots during deployment configuration.

Feel free to use those scripts and techniques in your deployments. and let me know If you have better ways deploy those upgrades of older apps.

VBScript – Uninstall application with name using registry (Add/Remove Programs)