Skip to main content

Setting Up a Separate WSUS to Work with SCCM Environment

Sometimes I feel thick-headed.

This is especially true, sometimes, with SCCM — but c’mon, it’s SCCM, so it comes with the territory.

The issue I was having was that I didn’t quite understand what the role a separate WSUS server would play in an SCCM environment. I thought it would be configured something like this:

sccmWsus1

I didn’t quite understand how the WSUS server worked with the SCCM environment. I knew SCCM managed WSUS, but it didn’t make sense to me how. Why wouldn’t I just configure WSUS and SCCM on the same box if I had to have the WSUS role already on the same system? This setup would cause the WSUS role on the SCCM primary site to be managed, but it tried to get updates from a WSUS that wasn’t doing anything, and I would have to manage updates from it, PLUS manage the updates in SCCM for deployment.

This seemed ridiculous to me, and super-redundant. Well, that’s because it is ridiculous and super-redundant.

In reality, it should be something like this:

sccmWsus2

Basically:

  • WSUS console is installed on SCCM Primary Site
  • WSUS server has the WSUS role installed, but nothing else
  • No group policy configured for the WSUS server to point to an internal box
  • In SCCM, configure the WSUS server as a ‘Site System’ with the Software Update Point role configured.
  • Your software updates for WSUS then get their updates from Microsoft, unless you haveĀ another WSUS upstream server.
  • Then all updates come from the WSUS server.
  • Note: if you’re running a single SCCM server, the WSUS can be installed on it as well, you just need to make sure you have beefy server.

I kind of feel like a bonehead for this, but hey, I get it now!

More info on the process here (although my setup is a little different):

Installing a remote Software Update Point in SCCM 2012 R2

(Update 20190702 – Made a note to clarify that the role can also be installed on single servers if desired).

How to Find the Microsoft Store GPO in Server 2012 and 2012 R2

Edit (02/15/16): I learned recently that a better approach is to just copy the Administrative Templates from group policy on a workstation and copy it into your AD administrative templates. Not as ridiculous, but still annoying.

This is probably one of the most ridiculous things I’ve encountered.

If you’re a system administrator, you sure as hell don’t want to deal with the Microsoft Store for your image deployments. It’s a superfluous piece of software that’s imposed on us, and Microsoft doesn’t give any tools during the deployment to get rid of it.

They make it even more difficult in a very asinine way to get the GPO you need to manage the Store.

In order to get the Store GPO, you have to install the ‘Desktop Experience’ feature.

Why Microsoft decided to do this is beyond me. Why would do I have to install a piece of bloat on my servers in order to get the GPO to manage the Microsoft Store?

Then you can go to Computer Configuration > Administrative Templates > Windows Components > Store.