locked
Downstream WSUS server fails to sync with upstream server. RRS feed

  • Question

  • I have a Windows 2012 R2 WSUS server A, all set up and in use.

    I'm trying to convert one of our other organization WSUS server B (2008R2)  from standalone so that it's a downstream server of Server A.

    When I change the upstream source to Server A, and select "this server is a replica", and then select "Synchronize" I get an error:

    InvalidOperationException: Client found response content type of 'text/html', but expected 'text/xml'.
    The request failed with the error message:
    --
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
    <title>500 - Internal server error.</title>
    <style type="text/css">
    <!--
    body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
    fieldset{padding:0 15px 10px 15px;}
    h1{font-size:2.4em;margin:0;color:#FFF;}
    h2{font-size:1.7em;margin:0;color:#CC0000;}
    h3{font-size:1.2em;margin:10px 0 0 0;color:#000000;}
    #header{width:96%;margin:0 0 0 0;padding:6px 2% 6px 2%;font-family:"trebuchet MS", Verdana, sans-serif;color:#FFF;
    background-color:#555555;}
    #content{margin:0 0 0 2%;;}
    .content-container{background:#FFF;width:96%;margin-top:8px;padding:10px;;}
    -->
    </style>
    </head>
    <body>
    <div id="header"><h1>Server Error</h1></div>
    <div id="content">
     <div class="content-container"><fieldset>
      <h2>500 - Internal server error.</h2>
      <h3>There is a problem with the resource you are looking for, and it cannot be displayed.</h3>
     </fieldset></div>
    </div>
    </body>
    </html>

    --.
    at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetAuthConfig()
       at Microsoft.UpdateServices.ServerSync.ServerSyncLib.InternetGetServerAuthConfig(ServerSyncProxy proxy, WebServiceCommunicationHelper webServiceHelper)
       at Microsoft.UpdateServices.ServerSync.ServerSyncLib.Authenticate(AuthorizationManager authorizationManager, Boolean checkExpiration, ServerSyncProxy proxy, Cookie cookie, WebServiceCommunicationHelper webServiceHelper)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.SyncConfigUpdatesFromUSS()
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

    I'm fairly certain this is the key, but Googling about hasn't provided an answer. Suggestions?

    Friday, February 6, 2015 6:40 PM

Answers

  • I have resolved this problem. Here's how:
    I backed up WSUS and IIS.
    I removed the WSUS role.
    I removed the changes to web.config.
    I deleted the WSUS website from IIS.
    I reenabled the WSUS role.

    That recreated the IIS site, and still maintained my WSUS config (since, I presume, it didn't delete the database).

    Everything began working. I suspect (as suggested by Mr. Garvin) that one of the security "fixes" was preventing the IIS server from correctly serving the pages.

    Tuesday, February 10, 2015 3:06 PM

All replies

  • When I change the upstream source to Server A, and select "this server is a replica", and then select "Synchronize" I get an error:

    InvalidOperationException: Client found response content type of 'text/html', but expected 'text/xml'.

    IIS is not configured correctly on your upstream server.

    It is returning a TEXT/HTML response to the server synchronization webservice call that should be returned as TEXT/XML.

    What else is installed on the upstream server other than the WSUS role?


    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, February 6, 2015 7:29 PM
  • The upstream server was built explicitly to be a wsus server and nothing else.  In IIS there is the default web site (80), and the wsis administration site (8530 http, 8531 https). all the defaults

    Then it had the solarwinds patch manager installed on top. SW support says this is a WSUS issue.


    Friday, February 6, 2015 7:36 PM
  • SW support says this is a WSUS issue.

    Oh, I totally agree with SW support on that point. :-)

    This is very definitely an IIS issue.

    Answer me this though... when you installed Patch Manager, did you also install the WEB CONSOLE on this server?

    Bottom line, something has misconfigured your IIS installation and now it's returning incorrectly formatted responses to the webservice requests being sent by the downstream server attempting to sync.

    With respect to your explicit reference to port 8531 and HTTPS... have you actually configured/enabled SSL on this WSUS server? or is that just a mention because it's listed in the bindings?


    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, February 6, 2015 11:54 PM
  • I  mostly listed 8530-/8531 because they're listed in the bindings. I don't believe SSL is actually up and working; my installation notes explicitly say, TBD.

    Server A has been up and running for months successfully, delivering both PM and WSUS updates to computers.  I don't know if it having been working for workstations is useful diagnostically?

    Hmm, did I install the web console? My installation notes only indicate that I performed the Express Install of PM. To be honest, I don't know. The PM docs say the console would be on port 8787. netstat -a doesn't show the server listening on 8787, and telnet doesn't show the port as open.

    When I set up WSUS, I did also perform the Microsoft recommended security steps on a WSUS server: http://technet.microsoft.com/en-us/library/dd939800%28v=ws.10%29.aspx

    Reviewing that, it looks like I needed to add the new Server B to my web.config file (which I had not done):

        <authorization>
               <allow users="DOMAIN\SERVERA, DOMAIN\SERVERB" />
        </authorization>

    I can't test that until the server owner comes back next week.

    Rick

    (If PM installing the web console broke IIS, I'm going to be back to it being a PM problem!).

    Saturday, February 7, 2015 7:32 AM
  • When I set up WSUS, I did also perform the Microsoft recommended security steps on a WSUS server: http://technet.microsoft.com/en-us/library/dd939800%28v=ws.10%29.aspx

    You know those are for IIS6 running on Windows Server 2003? I know it says it applies to newer systems, but those (unfortunately) are merely tags added to the document at each revision cycle (the most recent having been the major rewrite of that document in July, 2011). It absolutely does not apply to Windows Server 2012 and newer, though. Nonetheless, those settings may work. Nobody really knows.

    I'll also note that you're the only person I know of in ten years who has actually done this, so it's possible that you're going to encounter some unknown issues.

    Reviewing that, it looks like I needed to add the new Server B to my web.config file (which I had not done):

        <authorization>
               <allow users="DOMAIN\SERVERA, DOMAIN\SERVERB" />
        </authorization>

    I would definitely say that's a problem. :-)

    (If PM installing the web console broke IIS, I'm going to be back to it being a PM problem!).

    If you did an Express Install then you did not install the Web Console, that requires an explicit installation effort.

    The Patch Manager web console runs on top of SolarWinds' Orion application platform. There are known coexistence issues between WSUS and the Orion platform. Custom configurations can be implemented to make them coexist, but they do not coexist by default. I'm pretty sure this is clearly documented in the Patch Manager Administration Guide.

    But even if you had installed the Web Console... it would still be an *IIS* problem. :-)


    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.



    Saturday, February 7, 2015 1:44 PM
  • A little depressing that someone with your breadth of exposure finds that no one implements Microsoft's security recommendations.

    The only setting I can see in the Security document that could even possibly screw this up would be this:

    To remove header extensions for HTTP requests

    1. On the Start menu, point to Programs, point to Administrator Tools, and then click Internet Information Services Manager.

    2. Expand the local computer node and expand Sites.

    3. Click Default Web Site.

    4. Under HTTP Features, right-click HTTP Response Headers, and then click Open Feature.

    5. Select the row that contains the name X-Powered-By, with the value of ASP.NET, and then click Remove. When you are prompted to confirm the action, click Yes.

    And that's only on the default web site, not the WSUS one.

    Monday, February 9, 2015 6:59 PM
  • Ok, I think I see, at least, why I'm getting a text/html instead of text/xml.

    Whatever request is going to the web server isn't working. (500 - Internal Server Error). That of course then returns the "500 - Server Error" message, which is html (explaining the text/html). So that's a symptom, not the problem. I issue the Synchronize command from the downstream server, it issues whatever call it is to the upstream server, that call fails, and the upstream server returns a 500 message, and the log then shows text/html instead of text/xml.

    Now I just have to figure out how to debug the server error!

    Monday, February 9, 2015 7:27 PM
  • I have resolved this problem. Here's how:
    I backed up WSUS and IIS.
    I removed the WSUS role.
    I removed the changes to web.config.
    I deleted the WSUS website from IIS.
    I reenabled the WSUS role.

    That recreated the IIS site, and still maintained my WSUS config (since, I presume, it didn't delete the database).

    Everything began working. I suspect (as suggested by Mr. Garvin) that one of the security "fixes" was preventing the IIS server from correctly serving the pages.

    Tuesday, February 10, 2015 3:06 PM