Syncronization Failure BUG - Underlying connectin closed Issue/FIX

Discussion in 'Update Services' started by JB, Jun 28, 2005.

  1. JB

    JB Guest

    ISSUE
    I was receiving the errror below which was driving me nuts.

    2005-06-28 14:38:14.515
    UTC Warning wsusservice.132 WebServiceCommunicationHelper.ProcessWebServiceProxyException ProcessWebServiceProxyException
    found Exception was WebException. Action: Retry. Exception Details:
    System.Net.WebException: The underlying connection was closed: Unable to
    connect to the remote server. ---> System.Net.WebException: The underlying
    connection was closed: The proxy name could not be resolved, verify correct
    proxy configuration.
    at System.Net.HttpWebRequest.CheckFinalStatus()
    at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
    at System.Net.HttpWebRequest.GetResponse()
    at System.Net.Connection.TunnelThroughProxy(Uri proxy, HttpWebRequest
    originalRequest, Socket& socket)
    --- End of inner exception stack trace ---
    at System.Net.HttpWebRequest.CheckFinalStatus()
    at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult)
    at System.Net.HttpWebRequest.GetRequestStream()
    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)
    2005-06-28 14:38:23.515
    UTC Error wsusservice.132 WebServiceCommunicationHelper.ProcessWebServiceProxyException ProcessWebServiceProxyException
    found Exception was WebException but Retry Limit Exceeded. Action: No Retry,
    Fail. Exception Details: System.Net.WebException: The underlying connection
    was closed: Unable to connect to the remote server. --->
    System.Net.WebException: The underlying connection was closed: The proxy name
    could not be resolved, verify correct proxy configuration.

    TROUBLESHOTING
    1. I confirmed that the proxy was functioning.
    2. DNS resolution was correct.
    3. Network connectivity was available.
    4. I could browse via IE using this proxy (someserver.mydomain.com)

    There was no reason this shouldn't work. I searched with no resolution.
    So I'm luck enough to have Identify Black Box at my disposal (The most
    incredible software product I've ever used).

    What I found through blackbox is that the WSUSService does not use the fully
    qualified name from the proxy configuration on the options page. Black Box
    showed this:

    Execute DNS Query someserver for record type 1 with query option 0x14000000
    wsusservice.exe:932:2680 mswsock.dll Jun 28 12:44:33.379141 0.001280

    What bothered me is that IE can use a FQDN for proxy settings, but WSUS
    cannot. (Nice consistency) Even more troubling is that the field is
    actually checked for something like http://someserver and warns you to remove
    http://.

    Sounds like an undocumented feature due to a developer assumption. Anyone
    think this should be filed as a bug?

    FIX:
    So the fix for my environment was to add the domain the domain suffix search
    list on the network settings. For this example you would add mydomain.com.
    As soon as this was done I was able to sync.

    I can't imagine that I'm the only one supporting multiple DNS namespaces
    with one WSUS server. More importantly this was not the case with SUS 1.0.

    Hope this helps someone with the same issue and that someone from MS sees
    it.
     
    JB, Jun 28, 2005
    #1
    1. Advertisements

  2. Yep... true.... discussed a couple of times in this group in the past couple
    of weeks now.
    Different proxy clients/engines.
    What does that check, and what warning are you talking about?
    Nope. The form http://internalservername has been the standard naming
    conventing for /intranet/ resources since there was TCP/IP on Windows.
    The DHCP server should already be providing your internal domain name as a
    default suffix for all resolutions. If DHCP/DNS/AD are configured correctly,
    the following two commands should produce exactly the same results:

    nslookup internalservername

    nslookup internalservername.mydomain.com

    If they don't, then the DHCP/DNS is misconfigured, and a number of things
    will not function correctly in that environment.
    I think you're a rare occurrence. Most organizations do not support multiple
    domains in their AD environment, and if they do have multiple domains,
    they've probably deployed multiple WSUS servers

    If you were supporting multiple DNS namespaces with the same WSUS
    installation, I would expect that you've configured host headers on the
    server to support those multiple namespaces.

    However, it is still incumbent on the /client/ to properly resolve a given
    URL to the correct IP Address, and to place the correct URL in the HTTP
    Header sent to that web server. To fault /WSUS/ is to misunderstand what
    functions reside with what services and machines. WSUS is merely a passive
    web services server just sitting around waiting for a client to query it for
    services.
    Things change... products grow up....
    if WSUS were the same as SUS 1.0/1.1, it would have been called SUS 1.5.
    :)
     
    Lawrence Garvin, Jun 28, 2005
    #2
    1. Advertisements

  3. JB

    JB Guest

    Every other client/engine out of Microsoft has supported FQDNs.
    The web form in the WSUS configuration where you specify the proxy for
    syncronization. Try typing in http://someserver for your proxy and it will
    throw a MsgBox warning at you.
    NO! That's the standard form for WINS resolution in a LAN. NOT a global
    company with International sites.
    Yeah... because we all use DHCP for our WSUS server, and I didn't see that
    AD was a requirement for WSUS.
    NO they shouldn't necessarily. internalservername and
    internalservername.mydomain.com are completely different based on your suffix
    and what resource you are trying to reach. You can have server1.mydomain.com
    and server1.mydomain2.com. If you get the same results for both of those
    NSLookup queries than you have a problem.
    Any organization with multiple sites, development teams, QA testing, etc
    will have multiple domains and Forests if they want to protect their
    production resources. Who else do you think would request chaining WSUS
    servers.
    NO. No need for host headers. Do you know what a host header is?
    The client does correctly resolve a FQDN. I don't use WINS b/c it doesn't
    work.
    , and to place the correct URL in the HTTP
    That's why it was originally called SUS 2.0
    Before you comment next time try to understand a little bit about an
    infrastructure that's larger than a couple of servers sitting it a closet
    supporting more than 10 users.

    This posting was originally made to help out people who may be dealing with
    an envrionment larger than what I could host on one VM server. WSUS was done
    to support a distributed infrastructure with these types of complexities.
     
    JB, Jun 30, 2005
    #3
  4. It's not a question of "support" but a question of "response". If IE sees a
    dot in the URL, it automatically assumes the URL is an external resource and
    treats is accordingly. This has ramifications for both proxy issues as well
    as Internet zone security issues.

    Using a local name (e.g. http://wsusservername) avoids the issue with the
    request being incorrectly routed to a proxy server or handled as an
    untrusted resource.
    Ahh.... don't use a proxy, so I hadn't encountered that, but .. shucks...
    that makes sense. A proxy server is not an HTTP resource, it's just a
    hostname on the network to direct traffic at.
    Not necessarily. That form will work in a network with WINS and NetBIOS
    entirely disabled. If the DNS client is properly configured it SHOULD search
    the local domain suffix for all non-FQDN requests.
    AD is /NOT/ a requirement for WSUS... heck a /domain/ is not even a
    requirement for WSUS, but admittedly the two make using the product a heck
    of a lot easier.
    If I'm a client in "mydomain.com", and I issue a request to
    "internalservername", it's perfectly reasonable and expected that the suffix
    of MY home domain will be added to the hostname provided, and a resolution
    to internalservername.mydomain.com will be returned.
    Sure you can.. but that has absolutely nothing to do with the scenario under
    discussion.

    You can even /search/ both suffixes... but only ONE will produce a response,
    even if both exist, because one domain will be searched before the other.
    The /order/ of the domain suffixes searched should be appropriate for the
    domain location of the host initiating the query. If my machine is in
    mydomain1.com, but I also need to access resources in mydomain2.com, and
    there happens to be a machine with the same name in both domains -- if I
    send traffic to just 'server1', I'd definitely want MY server1 to respond
    before any other domain's server1. Choosing the search order of the suffixes
    is how that situation is handled, and thus, MY client always gets
    server1.mydomain1.com whenever 'server1' is used. If I want to talk to
    server1.mydomain2.com, then I need to use the FQDN to get to the external
    domain.
    Unless it's a dual-homed machine. :)
    I think you might go back to Active Directory Design 101 and recall that the
    /recommended/ AD design is to design as flat as possible. Where many
    organizations may have needed multiple domains with NT, the actual /need/
    for multiple domains with AD is significantly less. There's a natural
    tendency to build domains in environments such as you describe, but that's
    not to say that those organizations /should/ have a flatter domain structure
    with more reliance on sites and OUs.

    As for /chaining/ WSUS servers... that scenarios is intended to support
    multisite organizations who have large numbers of clients on specific sites,
    and the cost of maintaining a local machine is less than the cost of
    supporting the client traffic across the WAN connection.

    Regardless... there's nothing in the chaining scenario that implies anything
    about domain structure. In fact, WSUS could care less whether there are
    domains or AD in place, since all clients talk to WSUS anonymously.
    There's no need for insults or insinuations.
    I didn't say anything about correctly resolving the FQDN, I merely said that
    the /client/ was responsible for converting the given textual URL to the
    correct IP Address. The format of the URL is irrelevant to that point.
    Actually... infrastructures that large are more properly targeted with SMS.

    If you look at the positioning between WSUS and SMS, you'll find that while
    WSUS is encroaching on the enterprise patch management space, the product is
    really not designed for use in that size of organization.

    For starters, the default datastore is WMSDE, and the configuration of a
    back-end SQL Server is difficult, at best. Furthermore, WSUS does not
    support front-end load balancing or clustering, and it's ability to
    effectively function with a back-end SQL cluster is marginal, at best. Those
    two points alone ought to be clue enough as to where the practical limits of
    WSUS is with respect to the size of organization that can be supported
    effectively.

    Simply stated, WSUS is designed for an organization that can support up to
    500 systems per server, and that doesn't require a large number of
    distributed servers to support several thousand systems.
     
    Lawrence Garvin, Jul 1, 2005
    #4
  5. JB

    JB Guest

    Look Lawrence, the original point of this post is that the use of a proxy is
    WSUS is not implemented correctly. If I enter a resource as
    server.mydomain.com than it should ask resolve for server.mydomain.com. It
    should NOT TRUNCATE what I entered in the field. If the choice is to
    truncate the field than I should get a warning about it. Its that simple.

    Nothing in the WSUS Documentation mentions using a shortname.

    -- BEGIN SNIP --
    Configure WSUS to Use a Proxy Server
    If you use a proxy server on your network, use the WSUS console to configure
    WSUS to use the proxy server. This is necessary in order to synchronize the
    server with Microsoft Update.
    To specify a proxy server for synchronization
    1. On the WSUS console toolbar, click Options, and then click
    Synchronization Options.
    2. In the Proxy server box, click Use a proxy server when synchronizing, and
    then enter the server name, and port number (port 80 is the default) of the
    proxy server in the corresponding boxes.
    3. If you want to connect to the proxy server under specific user
    credentials, click Use user credentials to connect to the proxy server, and
    then enter the user name, domain, and password of the user in the
    corresponding boxes. If you want to enable basic authentication for the user
    connecting to the proxy server, click Allow basic authentication (password in
    clear text).
    4. Under Tasks, click Save settings, and then click OK when the confirmation
    box appears.

    -- END SNIP --
     
    JB, Jul 1, 2005
    #5
  6. Apparently we've been having two different conversations, and it appears to
    be my fault.

    I was working under the impression that we were talking about the /client/
    communicating with the WSUS server, not the /WSUS/ server talking to the
    /proxy server/.

    I've looked back at the thread, and I have no idea how I got that
    impression, so I apologize for the confusion.

    All of my comments with regards to short names are relevant to the WUServer
    and WUStatusServer values that are configured for use by the WUA. Those
    values need to be short names, because, if not, the client (read: the IE
    HTTP engine), interprets a FQDN URL as an external resource, and routes the
    request to the proxy server. That has been problematic for some people who
    have proxy servers configured, and were using FQDN values in their policies.

    As for the WSUS server's proxy configuration settings, my original response
    about it being discussed before was inaccurate - what was discussed before
    was the /client/ issue with the WUA not using the FQDN. Having said that, it
    probably would suit us both to do our best to "erase" the past few messages
    and start over with this conversation, so that I'm sitting on the same train
    track that you are. Again, this misunderstanding is my fault, because of an
    erroneous assumption I made about the topic.

    And.. having said all of that, I would be interested in knowing why the
    domain suffix is stripped from the field prior to being resolved. I suspect
    there's a valid reason for it., but I admit, I don't know what it is, and
    I've obviously not encountered it since I'm not using a proxy server on my
    perimeter.

    One semantical note about the cited docs, though. The statement I read is:
    "...then enter the server name, and port number..", and I'd have to say,
    that generally, in terms of Windows networking, the phrase "server name"
    rarely means FQDN. However, I do agree, it's a weak point in the
    documentation, and it probably ought to be enhanced with better text or a
    graphical example.
     
    Lawrence Garvin, Jul 2, 2005
    #6
  7. JB

    JB Guest

    Apparently we've been having two different conversations, and it appears to
    This explains a lot. :)
    I can understand how this happens, but a properly configured Internet
    Explorer shouldn't have this problem. This goes back to my DNS name space
    comments. If "Bypass proxy server for local addresses" is enabled and the
    FQDN or properly wildcarded DNS Name space is set in the Proxy Bypass
    (*.mydomain.com or *.mydomain.*) then WSUS will bypass the proxy and go
    directly after the WSUS server.

    This is why I consider it a bug... or as I like to sarcastically refer to
    them... "undocumented features". I haven't gone back to find the underlying
    cause since I got it to work. I can try to examine a bit deeper, but again I
    have it in the Appsite BlackBox logs as clear as day. Other applications
    take an FQDN and ask for proper resolution, but WSUS does not. Could it be
    unfinished input checking on the form? Maybe. I may try inputing the proxy
    server as an IP address. This should eliminate the DNS query. Either way
    its undocumented and that's a problem.

    Whatever I find out I'll post.
     
    JB, Jul 6, 2005
    #7
  8. JB

    JB Guest

    OK. I'll try to keep this concise, yet provide enough detail.

    I went back, removed the domain suffix from the Network settings on my WSUS
    server. Checked via PING and NSLOOKUP that I could resolve
    myproxy.mydomain.com. This was successful. I went to WSUS, and tried to
    syncronize and it failed. Confirmed via Appsite Black Box that its in fact
    only executing a query for myproxy, not myproxy.mydomain.com.

    Shut down the MSDE instance on the WSUS server. Proceeded to copy the MDF &
    LDF files to a SQL server. On the SQL server I attached to these files and
    brought up the MSDE database so I could interrogate. Sure enough I found the
    following (I used a SQL Script backup to show all details):

    ------ BEGIN SQL SCRIPT --------------
    CREATE TABLE [dbo].[tbConfigurationA] (
    [ConfigurationID] [int] IDENTITY (1, 1) NOT NULL ,
    [LastConfigChange] [datetime] NOT NULL ,
    [DssAnonymousTargeting] [bit] NOT NULL ,
    [IsRegistrationRequired] [bit] NOT NULL ,
    [MaxDeltaSyncPeriod] [int] NOT NULL ,
    [ReportingServiceUrl] [nvarchar] (1024) COLLATE
    SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [ServerID] [uniqueidentifier] NOT NULL ,
    [AnonymousCookieExpirationTime] [bigint] NULL ,
    [SimpleTargetingCookieExpirationTime] [bigint] NOT NULL ,
    [MaximumServerCookieExpirationTime] [bigint] NOT NULL ,
    [DssTargetingCookieExpirationTime] [bigint] NOT NULL ,
    [EncryptionKey] [varbinary] (128) NOT NULL ,
    [ServerTargeting] [bit] NOT NULL ,
    [SyncToMU] [bit] NOT NULL ,
    [UpstreamServerName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CI_AS
    NOT NULL ,
    [ServerPortNumber] [int] NOT NULL ,
    [UpstreamServerUseSSL] [bit] NOT NULL ,
    [UseProxy] [bit] NOT NULL ,
    [ProxyName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [ProxyServerPort] [int] NOT NULL ,
    [AnonymousProxyAccess] [bit] NOT NULL ,
    [ProxyUserName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT
    NULL ,
    [ProxyPassword] [nvarchar] (728) COLLATE SQL_Latin1_General_CP1_CI_AS NOT
    NULL ,
    [HostOnMu] [bit] NOT NULL ,
    [HandshakeAnchor] [nvarchar] (64) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
    ) ON [PRIMARY]

    ----------- END SQL SCRIPT ------------

    Interesting enough are the following fields
    UseProxy, ProxyName, ProxyServerPort

    These contained the correct information including my fully qualified server
    myproxy.mydomain.com so we can conclude that the webinterface for WSUS
    correctly wrote it to the database. Its the actual syncronization that
    either reads out of the DB incorrectly or passes it to DNS incorrectly.
    Without debug symbols I can't tell. We'll leave this to Microsoft. There is
    a debug print that occurs from the service which eventually ends up in the
    log file which makes me think its read corrrectly from the database.

    Debug print: "2005-07-11 18:32:02.687
    UTC\tInfo\twsusservice.342\tWebServiceCommunicationHelper.GetProxyConfiguration\tUse Proxy: myproxy.mydomain.com:8085\r\n

    What really aggravates me are two other fields in the table:
    ReportingServiceURL, and ServerID. This contains a microsoft URL and some
    guid that I guess corresponds to my server. (I searched the registry and
    can't find a match to what's in the table but the XML tags it as the SID).

    After this sync falls down the wsusservice.exe is able to correctly lookup
    my proxy and resolve it to the correct IP and then successfully send the
    failure off to Microsofts Reporting Service. All of this happens without
    ever telling me it did this in either the event log or via popup.

    At this point I would classify this as a big fat stinking bug. The
    WSUSService can use the proxy correctly to report errors to Microsoft, but it
    can't use it correctly to syncronize.

    I'd love to hear from the developer who slung the Sync code. I'd guess this
    is a very simple mistake. Who knows... with the reporting service maybe they
    got enough information to find me?
     
    JB, Jul 11, 2005
    #8
  9. JB

    JB Guest

    BUMP

     
    JB, Jul 26, 2005
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.