8.1core Client errors 80072EE2 against local WSUS; OK from Microsoft Server.

Question

//alpha is our patched 2008R2 WSUS Server 3.0 SP2, its Registry says InstallType 1, VersionString 3.2.7600.226. It has Hotfixes installed: 2720211, 2734608, 2938066(3.2.7600.274). Serves updates fine for our domain-joined PCs.
We are in a remote South Pacific island and are very bandwidth constrained, so for 7HomePremium & 8.1core machines we run WSUS Client Manager for Workgroups ver 1,1 2012 https://wsusworkgroup.codeplex.com/ to set them to get Updates from our local WSUS.
This works (on all, I believe) except on brand new 8.1core laptops (ie they need lots of Updates), that can fail with error 80072EE2. I believe Ive seen this several times and with a new 8.1core laptop on the bench, I want to get to the bottom of it.
On the Client:  "You receive updates managed by your System Admin." I go "Check for Updates" get "Checking for Updates" for 20? secs before the 80072EE2. Ran Microsoft FixIt / WSUS Client Troubleshooter, same. Avira Antivirus,
same if its realtime protection is disabled. No other antimalware running. Computer is not showing in any of the Computer Groups in WSUS Server. Ran Lawrence's Solarwinds Diagnostic Tool for WSUS Agent, Agent Config Settings "good" but Server Connectivity
fails with "WSUS Server Connectivity: unable to connect to the remote server" "connect failure caused by a network infrastructure fault making Windows Update unavailable to the client". 8.1 Desktop on same LAN switch gets updates from WSUS
fine.
Updates from Microsoft Servers work; I accepted 17, which is all the actual "Updates" incl the 8.1 Update (ie not Security Updates,NET,Office etc), retest & local WSUS still error 80072EE2. Turned off Windows Firewall, same. Many reboots.
If client webbrowses to  http://alpha/selfupdate/wuident.cab  it is offered this .cab.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate - WUSServer, WUStatusServer with & without port #, these all error:
http://alpha:8530
http://alpha.domainname.local:8530
http://alpha.domainname.local:80
http://alpha.domainname.local  <left it like this.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU  UseWUServer  1
ControlPanel - WindowsUpdates - Install Updates Automatically.
wuauclt.exe /resetauthorization /detectnow  waited 8 mins, same.
Regarding  http://technet.microsoft.com/en-us/library/cc720439%28v=ws.10%29.aspx
In Server Manager - IIS Im not seeing any websites. (me not very good with IIS). If there is no site and WSUS uses one, how are all our other clients successfully updating?   Must be, the webrowse to \Selfupdate works. Im wondering how the client
authenticates. Want to check IIS logs but C:\Windows\System32\LogFiles\W3SVC1 no exist; C:\inetpub\logs is empty; C:\Windows\System32\LogFiles\HTTPERR\httperr3.log  has entries from yesterday but not today, & none for this clients IP address.
Server Manager - Roles - Web Server - Health & Diagnostics - not installed. explains lack of logs.
Roles - Security - Windows Authentication - installed, Basic Authentication not installed. Installed it, same, uninstalled it.
Not sure where to go from here. I want to look harder at the association between WSUS & IIS esp re authentication, but Im not seeing a way at it.

Answer 1

We are in a remote South Pacific island and are very bandwidth constrained
Timeout errors from the client are generally networking issues. By all rights, if you're on a bandwidth constrained site, then you probably should have a local (replica) WSUS server, so those clients don't have to make WSUS connections across your bandwidth-constrained
connection.
In Server Manager - IIS Im not seeing any websites. (me not very good with IIS). If there is no site and WSUS uses one, how are all our other clients successfully updating?
If client webbrowses to  http://alpha/selfupdate/wuident.cab  it is offered this .cab.
Well, if there's no v-root for "WSUS Administration", then the port 8530 suffix is incorrect, and possibly the WSUS resources are actually IN the Default Web Site. We know, factually, that there's a /selfupdate folder in the Default Web Site because
you successfully accessed it with a browser, but that's not necessarily significant, because on a WSUS v3 server there is always a /selfupdate v-dir in the Default Web Site. It does tell us, however, that the browser can at least get to the right server.
The question is: Where is *WSUS* installed. Your use of port 8530 implies that there should be a "WSUS Administration" v-root. If it's not there, you've probably found a root cause.
Another observation... in the browser you used the short name, which ostensibly resolved correctly within the domain.local DNS zone. However the WUA is configured to use the FQDN. You should check that the client is properly treating that as a FQDN, and
not trying to append another suffix.
I'd ask the more mundane question: Why aren't you using the simple hostname in the WUAgent configuration anyway? And if you do: Do the timeout errors go away? Usually when I see people using FQDNs to get to internal (local) resources, that suggests something
is not right with the DNS .. and a not right DNS can cause timeout issues trying to find inaccessible or non-locatable resources.
Do nslookup alpha and nslookup alpha.domain.local both return the same results when run on this client?
If the client was actually getting TO the WSUS server using an invalid port number, it should be receiving an  HTTP 404 error from the WSUS Server. But it's not. It's timing out, either waiting for a response that might be that HTTP 404 never arriving,
or waiting for a response that's never going to come because the connection was never made.
I'd suggest (once you actually find the WSUS v-root), to inspect the IIS logs on the WSUS server and see if it's actually getting any inbound traffic from those clients.
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.