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:
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:
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):
(Update 20190702 – Made a note to clarify that the role can also be installed on single servers if desired).