SCCM 2012 R2 Software Updates (WSUS) Install – Windows Server 2012 R2

Ok, so I get lots of questions internally about this.. and to be quite honest it can be a pain, more so on Windows Server 2012 due to the new version of the WSUS engine.

This recipe is tested and working on Windows Server 2012, and SCCM 2012 R2 – CU4

From Server Manager select “Local Server” and then Manage > Add Roles and Features

Next > Next > Select your server from the pool > Next >

Under roles tick “Windows Server Update Services“:


add the required features:1

When configuring the Role Services, Uncheck “WID Database” and check “Database” instead:

4 - check Database

Next you will have to chose the location to store the Content:

5 create sources

For this you will have to create a new directory.. I recommend locally, and then share with “Everyone”:

7 sources share

8 share perms

Once shared enter the directory location like follows:

9 enter folder

When specifying the “DB Instance”, type in the server name and ensure you click “Check connection” – (Do not specify localhost)

10 enter instance hit check

Hit install:

11 hit install but no post config

Once the configuration is complete, DO NOT click “Launch Post-Installation tasks” .. either via this screen:

12 close

Or “Server Manager

13 will configure via cmd

Once you have your WSUS server in this state, it is ready to have the Software Update role added with SCCM, and then the WSUS instance captured and configured by SCCM.

Now normally at this stage I would perform the post configuration of the WSUS instance manually, and then install the Software Update Point role in SCCM after.. however its useful to see what sort of errors you can receive from a non working or poorly functioning implementation.

So lets install the Software Update Point role in SCCM… This is done via the Primary Site server, or your CAS (if applicable)

From the SCCM Console, browse to “Administration”


Select the primary site server, and choose “Add Site System Roles”



Hit Next


Again, Next

Choose the “Software update point” role, and hit Next


This part is critical.. select the radio button for the Windows Server 2012 option, like so:

6 select 8530

Hit Next


Again, Next


Again, Next

With little bother, the role should start installing properly


It would be wise to check this though, you can view the status of this installation by browsing the SUPSetup.log, within the logs directory:

10 check role setup

Looks fine doesn’t it.. but wait, check WSUSCtrl.log:

11 error loop

These errors will loop forever, so lets perform the post-configuration I mentioned earlier

Open up an administrator Command Prompt and navigate to:

C:\Program Files\Update Services\Tools\

Run the following command:

WsusUtil.exe postinstall SQL_INSTANCE_NAME=servername CONTENT_DIR=driveletter:\directory

Like so:

12 post config

Finally we need to configure the WSUS ports to use 8530 and 8531 to match our SUP role configuration.. otherwise the WSUS role on the server will run via Port 80 (default)

To do this, perform the following command from the same prompt:

WsusUtil.exe usecustomwebsite true

13 usecustom


You should now be syncing correctly, but do check the wsusCtrl.log:

14 should now sync

All done.. hope it helps!


I have found that the WSUS site in some cases tends to fail and stop working all together.. a fix for this is to implement some changes to the Application Pool.

From Server Manager select “Local Server”

Click “Tools” and then select “Internet Information Services (IIS) Manager


Right click on “WsusPool” , and select “Advanced Settings

Now make the following changes:


Rapid-Fail Protection – Enabled = False

Recycling – Private Memory Limit (KB) = 8388608        

(Set this to something healthy.. I went with 8GB)



After a reboot this should stabilise the Application Pool and keep SUP syncing nicely!



Windows Deployment tools (ADK) Install – SCCM 2012 R2 PS

When installing an SCCM 2012 R2 on a Primary site, one of the many requirements is the Windows Deployment tools component:

adk install

I always forget to install this first, and the other components such as USMT… Not quite sure it should be required ALL the time in a multi Primary Site environment, as many companies use a shared boot image with pre-integrated drivers, but hey-ho its quite easy to implement.

Simply download from the above URL and run the installer (its quite a large install so stick it on a large volume:


Click Next


Click Next


Click Accept


Ensure that the above options are selected… You might not need the USMT Tool, but its only small so grab anyway.

5 could take a while

Grab a coffee whilst the files are acquired


That’s it, no reboots or anything required usually.


Setting software deadline behaviour – SCCM Clients

Had a requirement recently to control how the SCCM client handles software updates and other deployments at deadline time… Its often hard to strike a balance between efficient patching, and keeping users happy with minimal popups, notifications and restarts etc.

I tend to lean towards the ruthless approach where possible, so I have configured WSUS updates to deploy with a deadline… This however causes some problems with laptop users who like to show off their PowerPoint skills in boardrooms without interruption.

A good way to prevent this is to utilise “Presentation mode” state within the SCCM client… this will prevent unwanted interruptions during this time:


Again this is something that can be set by the user, however it can also be scripted using powershell:



Setting Business Hours – SCCM Clients

So whilst bearing the sole burden of deploying software and configurations to multiple sites and users within different time zones, It would make sense to do this with some level of control and expectation.

I have yet to receive confirmation on actual working hours for all of these members of staff so its pretty hard to decide on maintenance windows within SCCM.. My solution for the time being is to utilise the SCCM client side functionality to dictate the working hours:


This functionality to me at least  provides a level of transparency, and flexibility should we decide in future to allow staff to dictate how and when deployments can occur, thus minimising any dramas.

So the image above is how the SCCM client is set by default upon installation… In order to put something more sensible in here we either need to instruct the users to update it themselves, or atleast populate the data with something more fitting.

This can be scripted, so I have done this via powershell:


Using this script, I have now set the values for all clients to be:


Another good reason for using PowerShell in this case is that you can implement the code into SCCM compliance.. More on that in another post


SCCM Distribution Point Binding Bug

So I had to reinstall the primary site server the other day due to a multiple issues with management framework…

When adding DP’s back to the newly reinstalled estate I found that they could not communicate with the PS via https… when investigating on the DP’s directly, I found the following entries within its IIS website bindings:


Looks like re adding the site server as a Distribution Point involves some form of scripting of the binding values?

Either way the entries were invalid, and cannot even be entered in manually within the format above… naturally this caused the site to fail.

Moral of the story?

Probably a good idea to perform a remote clear down of a DP’s configuration if you plan to reinstall it… I think next time I will temporarily reassign all DP’s to an alternative Primary Site, before re-assigning them back!