Can't access WSUS console from local system; can access it from another host?

Question

I have a WSUS server running on Server 2012 R2, update services 3.2.7600.226. From Server Manager, I see that WSUS has an error, and specifically when I open the errors I see "The DSS Authentication Web Service is not working" and the same thing for SimpleAuth, Client Web, API Remoting, and Reporting Web. I do have SSL enabled, the server is configured to use port 8531.

I can connect to the server through the local WSUS console, but I see 0 updates, 0 computers, etc.

Oddly enough though...I have an SCCM server which also has WSUS installed (and is a downstream WSUS server). It's a Server 2016 instance, and is using update services 10.0.14393.0. Not only can I see the first server fully after adding it to the console, I see clients and updates from it. My actual clients are successfully checking for updates from the original server; I have 243 clients checked in and happy.

Everything appears to be working with the exception of managing the WSUS server from itself.

What gives? I'm totally stumped as to what the issue could be. Does it have something to do with the server not being able trust the cert locally? Is it an update services thing...seems odd that another system can see everything but the host itself can't.

In IIS (6.1) on the WSUS server, under the WSUS admin site, I have the following:

• ApiRemoting30, bound to 443, 8530, 8531, requiring SSL.
• ClientWebService, bound to 443, 8530, 8531, requiring SSL.
• DssAuthWebService, bound to 443, 8530, 8531, requiring SSL.
• Inventory, bound to 443, 8530, 8531, NOT requiring SSL.
• ReportingWebService, bound to 443, 8530, 8531, NOT requiring SSL.
• ServerSyncWebService, bound to 443, 8530, 8531, requiring SSL.
• SimpleAuthWebService, bound to 443, 8530, 8531, requiring SSL.

The SSL cert is a requested cert from our root CA, which totally checks out. Totally valid when browsed with IE.

I followed this guide: https://technet.microsoft.com/en-us/library/bb633246.aspx?f=255&MSPPError=-2147217396

Solution

It appears I had a mismatch in my server certificate and the domain name I have been using.

I didn't mention this before, but doing "Wsusutil configuressl certificateName" did not help.

When the WSUS console opens, it attempts to connect using the hostname, and ONLY the hostname. This used to work...back in the day, our GPO pointed to the old WSUS server (predating either of these) at "http://server-wsus-desk:8530". I enabled ssl and updated that to "http://server-wsus-serv:8531". For the clients to connect, the ssl cert was for just the hostname. Somehow, this just doesn't work.

What DID work was creating a new domain cert for the FQDN (server-wsus-serv.ad.domain.org). Then I updated the GPO to point to "https://server-wsus-serv.ad.domain.org:8531". When I load the console on that host, by default, it opens up a connection to "server-wsus-serv" which does the whole "show 0 computers and updates" thing. However, I can initiate a NEW connection to the FQDN "server-wsus-serv.ad.domain.org" on port 8531, and it shows right up on both servers as you would expect. Clients connect without errors, and server manager shows no issues in the event log.

This is still not ideal though. What I ended up doing was creating an alternative certificate template on my CA that allows for multiple DNS aliases. I went to my CA, duplicated the "Web Server" template, then called it "WSUS Web Server Certificate". In the "Security" tab, add the actual WSUS server either by a group or by the computer name (you need to enable the computer object type) and give it "Enroll" and "Read" permissions. Then, go to the CA in the server manager, expand the "Certificate Templates" folder, then right click, go to "New" and select "Certificate Template To Issue." Choose your new template and click ok. Now, go back to your WSUS server, open up mmc and load the certificate snap-in for the computer account. Expand "Certificates" and "Personal" and click the "Certificates" folder. Right click in the whitespace, select "All Tasks" -> "Request New Certificate". Click "Next", "Next", then you'll see the new web certificate template with a link saying "More info is required to enroll fo rthis certificate". Click that.

In "Subject Name" select the type "Common Name" and put in your FQDN and hit Add. In "Alternative name", select the DNS type, then enter ANY other names you might use (for us, it's server-wsus-serv.ad.domain.org, server-wsus-serv.domain.org, and server-wsus-serv). Click ok, check the box next to the certificate template, then hit Enroll. Click finish, then go back into the certificate MMC snap-in, and refresh to see your new certificate. I like to double click on it and enter a friendly name like "WSUS Web Server Certificate".

Go back to IIS manager. Under the web server, select "Server Certificates" and you should see your new certificate there. Expand your sites, choose your WSUS Admin site, and edit your bindings so that the new cert is bound to 8531. Restart the site. Then, open powershell, and navigate to "C:\Program Files\Update Services\Tools" and run ".\Wsusutil configuressl server-wsus-serv.ad.domain.org" Then restart update services. I can now connect locally and remotely from both the server name AND the FQDN.

Comments

[Matthew Wetmore]

If you use the local console, attempt to add the local machine to the console as if it were remote - enter the FQDN, port, and SSL setting. Does that work?

[surfrock66]

That's what's crazy...it "connects" but shows me 0 updates and 0 computers. Using the EXACT same connection parameters from the SCCM server's WSUS console...connected and all data appears.

[Matthew Wetmore]

Have you tried PowerShell Get-WsusServer on the local machine and explored there?

[JukEboX]

@surfock66 Wow what a rebuild. Were you running WSUS without SSL before?

[surfrock66]

Yes...I came into this org in Nov. They had 2 wsus servers without ssl which both cached updates...wsus-desk for user machines and wsus-serv for servers. Desk had 300GB of storage, filled up, and fully corrupted so as to not boot, so no updates have gone out since ~2015. Our SAN is ~97% provisioned...new HW is here awaiting power. Wsus-serv (200GB) was also pretty full, but I turned off update caching, set up ssl, expanded the products it services, and pointed the clients to it. We can now decomm desk and reclaim 300GB of space...which will go straight to Exchange lol.