none
New WSUS install does not respond to clients over ports 8530 or 8531

    Question

  • I've recently installed WSUS on a Server 2012 machine, and am struggling to get it to respond to requests from other hosts. I cannot get it to respond to any host in any manner, except for requests from itself.

    My setup is as follows:

    • WSUS installed on a Server 2012 domain controller, DC01.
    • Other roles installed include AD CS, AD DS, DNS, IIS, and Print Services.
    • WSUS is using all default settings.
    • The firewall has inbound and outbound exceptions for ports 8530 and 8531

    A bit of information about what's happening:

    • IIS will respond over port 80. I can open a Web browser from my workstation and connect to http://dc01/. If I attempt to connect to http://dc01:8530 (which I know should not work, but should respond with a 403 error), it times out. Identical behavior is observed over port 8531 with https.
    • IIS will respond with a 403 if I make this same connection in a browser on DC01, it will work if I connect using either the loopback IP or hostname, but will time out if I attempt to make the connection using the server's local IP (IPv4).
    • If I try to connect from my workstation using the WSUS configuration snap-in, I get an error: The remote server could not be contacted. Please verify that IIS on the server is correctly configured and is running.
    • If I try to connect from DC01 using the WSUS configuration snap-in, it works correctly.
    • The above is true for both http (8530) and https (8531).
    • IIS logs show inbound connections from my workstation and show that IIS is responding with a 200. However, Wireshark running on DC01 shows three attempts by my workstation to open a connection -- three SYN packets, one initial attempt then two identical retries -- over a period of about ten seconds, with no responses from DC01. If IIS is responding, the responses are getting lost sometime before they hit the NIC.
    • Bindings in IIS are correct, 8530 for http and 8531 for https.

    Given that everything works fine when making a local connection, I think I can safely assume that WSUS itself is running properly, and the issue is related to IIS. Nonetheless, in the hopes of this simply being a failed install, I have uninstalled and reinstalled both IIS and WSUS multiple times. (One thing to note, though I doubt it's related: WSUS consistently fails to set the path for the local update cache, failing the post-deployment configuration. I have to manually edit the UpdateServices-Services.xml file to include the path for the local cache. Everything goes fine after I do that.)

    I'm pretty stumped on this, and would happily accept any help. Thanks!


    Thursday, January 02, 2014 4:15 PM

Answers

  • I've recently installed WSUS on a Server 2012 machine, and am struggling to get it to respond to requests from other hosts. I cannot get it to respond to any host in any manner, except for requests from itself.

    My setup is as follows:

    • WSUS installed on a Server 2012 domain controller, DC01.
    • Other roles installed include AD CS, AD DS, DNS, IIS, and Print Services.

    Fundamentally you have two issues here:

    • The first is the question of co-existence between WSUS and AD CS.
    • The second is whether this machine was a DC before, or after, you installed WSUS.

    With Windows Server 2003 systems, running 'dcpromo' after installing IIS (and WSUS) would break IIS (and thus WSUS). With Windows Server 2012, installing WSUS with the AD DS role present results in a broken WSUS installation (if not an outright installation failure). This is because on a WS2012 Domain Controller, there are GPO restrictions on "Log On As A Service" which impact the ability of certain LOCAL accounts to do so ... one of which being the Network Service which is required for WSUS and another local use account, which is used for WID.

    Regarding ports and IIS -- WSUS is designed to work on port 8530 by default on a Windows Server 2012 box. It can also be made to work on port 80, but you have to use the correct utilities and procedures to make that change. As for your observation that "port 6000" seems to be a cutoff.... I'll (re)direct your attention to the installation of Active Directory Certificate Services, which I suspect is a contributing factor, and in general firewall configuration rules -- which are probably the most likely culprit on the port range of 6000+ (not including 8530 which I promise you is open by a rule explicitly created by/for WSUS).

    So, here's my suggestion:

    1. Install the WSUS role first.
    2. Install the AD DS role if you must (but Domain Controllers should not also be web or application server).
    3. Install the AD CS role elsewhere.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, January 03, 2014 9:53 PM

All replies

  • Firstly - there's a WSUS forum here where you'll get better help.  Maybe a staff member here can move the thread for you?

    In the meantime, I'll try help.

    If the WSUS server is appearing as a client of itself in the WSUS control panel, then I think that means that all the elements of WSUS/IIS are working properly. I'd suspect firewall.

    On the other clients, are they correctly receiving the url for WSUS?  (check in c:\%windir%\Windowsupdate.log)

    Assuming you are sending those setting to the clients using Group Policy - does that GP contain both the hostname AND the port?   (I guess that this is all fine, since the WSUS server is reporting in as a client of itself in the panel, just checking)

    To confirm that you can get to IIS - try browsing to http://wsusservername/iuident.cab   If that file downloads, then all is well.

    Are you using a Microsoft or 3rd party firewall?  Have you tried disabling it on the WSUS server, and a test client and running wuauclt /detectnow on a client?


    Thursday, January 02, 2014 5:38 PM
  • Totally missed the WSUS forum. Thanks for the note. I'll wait and see if someone can move the thread, and then re-post if not, though I do suspect this is an IIS issue rather than a WSUS issue, given that WSUS seems to work fine from the server -- I just set up the GPO for WSUS for testing purposes now, approved several updates, and DC01 (the WSUS server) was able to find the approved updates when I had it check for new updates. Everything seems to work fine as long as I'm on the server, and nothing seems to work when I'm on any other machine.

    I've tried with the firewall disabled on both the client machine and the server, to no avail. The only firewall in use on either machine is the default Windows firewall -- both on the Server 2012 machine and on the Windows 8 workstation I'm using as a test client.

    iuident.cab 404s, as it does not exist. That said, given that it 404s from both DC01 and from other machines, I don't think this is the root of my problem.

    Thursday, January 02, 2014 6:24 PM
  • Okay, further troubleshooting shows that if I manually change the WSUS port number to 80, it works fine. It also works on 808. It does not work on 8530, or any other ports above that number which I tried.

    If I move the default site to 8530, it also fails to work.

    Friday, January 03, 2014 6:09 PM
  • And, after more punching in number after number, I've determined that port 6000 is the cutoff. This is an IIS issue, not a WSUS issue, as it happens with any IIS site. It happens on two Server 2012 machines that I've tested now (one physical one virtual), and happens specifically with ports 6000 or above -- any IIS site on that port or higher will simply not respond.

    I'm probably going to just change WSUS to use a lower port as a workaround, here. If anyone runs across this post and has a real solution, though, I'd be happy to hear it.

    Friday, January 03, 2014 6:27 PM
  • I've recently installed WSUS on a Server 2012 machine, and am struggling to get it to respond to requests from other hosts. I cannot get it to respond to any host in any manner, except for requests from itself.

    My setup is as follows:

    • WSUS installed on a Server 2012 domain controller, DC01.
    • Other roles installed include AD CS, AD DS, DNS, IIS, and Print Services.

    Fundamentally you have two issues here:

    • The first is the question of co-existence between WSUS and AD CS.
    • The second is whether this machine was a DC before, or after, you installed WSUS.

    With Windows Server 2003 systems, running 'dcpromo' after installing IIS (and WSUS) would break IIS (and thus WSUS). With Windows Server 2012, installing WSUS with the AD DS role present results in a broken WSUS installation (if not an outright installation failure). This is because on a WS2012 Domain Controller, there are GPO restrictions on "Log On As A Service" which impact the ability of certain LOCAL accounts to do so ... one of which being the Network Service which is required for WSUS and another local use account, which is used for WID.

    Regarding ports and IIS -- WSUS is designed to work on port 8530 by default on a Windows Server 2012 box. It can also be made to work on port 80, but you have to use the correct utilities and procedures to make that change. As for your observation that "port 6000" seems to be a cutoff.... I'll (re)direct your attention to the installation of Active Directory Certificate Services, which I suspect is a contributing factor, and in general firewall configuration rules -- which are probably the most likely culprit on the port range of 6000+ (not including 8530 which I promise you is open by a rule explicitly created by/for WSUS).

    So, here's my suggestion:

    1. Install the WSUS role first.
    2. Install the AD DS role if you must (but Domain Controllers should not also be web or application server).
    3. Install the AD CS role elsewhere.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, January 03, 2014 9:53 PM
  • Lawrence, thanks for the information. The server I've been using primarily to test this actually needed to be demoted so I could move it from eval to a fully-licensed copy of Server 2012 anyway, and after demoting it and re-installing WSUS it works great.

    As for the port 6000 cutoff -- it's not a firewall issue. As noted, the firewall is completely disabled. Unless disabling the firewall in Server 2012 does not actually disable the firewall in Server 2012, I'm pretty confident in this fact. Demoting and reinstalling WSUS seems to have fixed it, though. I also uninstalled AD CS, so it's possible that AD CS was somehow causing this issue, as well, per your suggestion. I'll be moving AD CS to another server.

    Thanks again for your help!


    Monday, January 06, 2014 6:30 PM
  • I spoke too soon. As soon as I re-promoted this server back to a domain controller, WSUS reverted back into its previous state.
    Monday, January 06, 2014 7:02 PM
  • I spoke too soon. As soon as I re-promoted this server back to a domain controller, WSUS reverted back into its previous state.

    Yes.. there's a second part to this which I re-encountered a few hours after I wrote this reply, and meant to come back and follow up on...

    When promoting a WS2012 machine to a Domain Controller, it now invokes a policy that prevents local accounts from using LogOnAsAService. Not really sure why Microsoft did that.. as it directly affects this account known as NT AUTHORITY\NETWORK SERVICE which a whole bunch of stuff runs with.

    Go to Security Policies, find the "Log on as a service" policy setting in User Rights Assignment, and add the NT AUTHORITY\NETWORK SERVICE account (for WSUS), and the NT SERVICE\MSSQL$MICROSOFT##WID (for WID).


    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile: http://mvp.microsoft.com/en-us/mvp/Lawrence%20R%20Garvin-32101
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, January 07, 2014 12:37 AM
  • Thanks for the response, again. I added the items to the GPO you suggested -- though I found that local machines had NT SERVICE/Any Service added already, and the account you suggested adding was rejected by the editor. I also mistakenly removed the IIS account(s) from the locally-defined version of this setting by overriding it with a domain-wide GPO, and had to re-add those accounts. (I believe I re-added the correct account, IIS_IUSRS, but I'm not 100% sure on that. Once I added IIS_IUSRS, I was able to connect to WSUS again.)

    Unfortunately, we're back in the same place. I re-demoted the DC and uninstalled WSUS to make sure, and after installing the WSUS role, I was able to access it from remote machines until I re-promoted the machine to DC status. Currently, I've got NT SERVICE/ALL SERVICES, NT AUTHORITY/NETWORK SERVICE, DefaultAppPool, and Classic .NET AppPool all allowed to log on as a service. If there are any accounts I'm missing, maybe that's related. But, as it stands, it stopped working again the moment I promoted it.

    I do have a spare IIS VM that's not going to be a domain controller and is only used for intranet sites. I might just install WSUS on that and save myself the headache.

    Tuesday, January 07, 2014 5:49 PM
  • Sounds like the best solution James.
    Wednesday, January 08, 2014 1:36 PM