WSUS Clients in a DMZ
Dummy
I have clients in the DMZ that currently get their updates directly from
Microsoft.
I now want to manage their updates via WSUS 3.0 Sp1 from within the local
lan. The firewall used to seperate the dmz from the internal lan is
Checkpoint. The dmz is a class C network. The internal is using a private B
network class.
I am publishing WSUS on port 8530.
On the Checkpoint FW I have allowed ports 80,443 and 8530 bidirectional
between the wsus server and the dmz clients. The dmz clients have the WSUS
ip address FQDN is in their local hosts file.
Does clients require NETBIOS to communicate with the WSUS server? Netbios
over TCP is disabled on the dmz clients.
The clients are getting the updates but it fails on reporting back. WSUS
server states that it has not reported yet. The clients are in the correct
target group.
There are no traffic blocked reported in the checkpoint logs.
part of the windowsupdate log with the errors.
2009-03-28 08:49:03:015 1036 138c AU AU setting next detection timeout to
2009-03-28 06:54:52
2009-03-28 08:49:03:015 1036 138c AU Setting AU scheduled install time to
2009-03-28 14:00:00
2009-03-28 08:49:08:015 1036 1314 Report REPORT EVENT:
{6DDEB895-6973-4702-8B90-87F63935E961} 2009-03-28 08:49:03:015+1300 1 147
101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success
Software Synchronization Windows Update Client successfully detected 0
updates.
2009-03-28 08:49:08:015 1036 1314 Report REPORT EVENT:
{476349D5-1F09-4D7C-92A4-42B3440B200D} 2009-03-28 08:49:03:015+1300 1 156
101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success
Pre-Deployment Check Reporting client status.
2009-03-28 09:02:06:968 1036 1314 Report Uploading 2 events using cached
cookie, reporting URL =
http://wsusupdate.envbop.net:8530/ReportingWebService/ReportingWebService.asmx
2009-03-28 09:03:07:500 1036 1314 Misc WARNING: Send failed with hr =
80072ee2.
2009-03-28 09:03:07:515 1036 1314 Misc WARNING: SendRequest failed with hr =
80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes
used : <>
2009-03-28 09:03:07:515 1036 1314 Report WARNING: Failed to upload events to
the server with hr = 80072ee2.
2009-03-28 09:03:07:515 1036 1314 PT + Last proxy send request failed with
hr = 0x80072EE2, HTTP status code = 0
2009-03-28 09:03:07:515 1036 1314 PT + Caller provided credentials = No
2009-03-28 09:03:07:515 1036 1314 PT + Impersonate flags = 0
2009-03-28 09:03:07:515 1036 1314 PT + Possible authorization schemes used
=
2009-03-28 09:03:07:515 1036 1314 PT WARNING: ReportEventBatch failure,
error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status
code = 200
2009-03-28 09:03:07:515 1036 1314 Report WARNING: Reporter failed to upload
events with hr = 80072ee2.
Any help appreciated.
Lawrence Garvin [MVP]
news:OJAM2uxr...@TK2MSFTNGP05.phx.gbl...
> I am publishing WSUS on port 8530.
> On the Checkpoint FW I have allowed ports 80,443 and 8530 bidirectional
> between the wsus server and the dmz clients.
Unless you've specifically enabled SSL for communications between clients
and your WSUS Server, neither port 443 (nor 8531, which would have been the
correct port to configure in this instance) is not needed.
Also, the rule does not need to be bi-directional. ALL traffic is initiated
by the client (i.e. from the DMZ) and received by the server, thus, the only
requirement is for ports 80 and 8530 to be open from the DMZ to the Internal
network. (Of course, port 80 may have already been open from Internal-to-DMZ
if you have web resources published in the DMZ that need to be accessible to
internal users.)
> Does clients require NETBIOS to communicate with the WSUS server?
No. All communication with the WSUS server is performed over HTTP which is
exclusively a TCP connection.
> The clients are getting the updates but it fails on reporting back.
> http://wsusupdate.envbop.net:8530/
> ReportingWebService/ReportingWebService.asmx
> 2009-03-28 09:03:07:500 1036 1314 Misc WARNING:
> Send failed with hr = 80072ee2.
> 2009-03-28 09:03:07:515 1036 1314 Report WARNING:
> Failed to upload events to the server with hr = 80072ee2.
The 0x80072ee2 code is a timeout error; typically manifested when the WSUS
Server (usually the database service) is overloaded, and the WUA doesn't get
the expected response(s) within the time frame expected. This could also be
a manifestation of the Checkpoint prioritizing the traffic -- particularly
if you've enabled any QoS features.
However, it is somewhat odd getting timeouts on the reporting, when
everything worked correctly on the detection/downloads... or did it? The
provided log snippet shows =zero= updates being detected, so that data is
inconclusive. Are you certain that these machines are detecting/downloading
from the WSUS Server?
I'd suggest checking the IIS logs to see if this specific call at 3/28
9:03:07am local was received by the IIS server.
Also, the Checkpoint logs indicating the creation and teardown of the
session may also be helpful.
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
Dummy
From the IIS logs
2009-03-27 19:44:18 W3SVC59563924 172.16.x.x HEAD /selfupdate/wuident.cab
0903271948 8530 - 192.146.x.x Windows-Update-Agent 200 0 0
2009-03-27 19:44:18 W3SVC59563924 172.16.x.x HEAD
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0903271948 8530 - 192.146.x.x
Windows-Update-Agent 200 0 0
2009-03-27 19:44:18 W3SVC59563924 172.16.x.x GET
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0903271948 8530 - 192.146.x.x
Windows-Update-Agent 200 0 0
2009-03-27 19:44:21 W3SVC59563924 172.16.x.x POST
/SimpleAuthWebService/SimpleAuth.asmx - 8530 - 192.146.x.x
Windows-Update-Agent 200 0 0
2009-03-27 19:44:21 W3SVC59563924 172.16.x.x POST
/ClientWebService/client.asmx - 8530 - 192.146.x.x Windows-Update-Agent 500
0 0
2009-03-27 19:44:21 W3SVC59563924 172.16.x.x POST
/ClientWebService/client.asmx - 8530 - 192.146.x.x Windows-Update-Agent 200
0 0
2009-03-27 19:44:21 W3SVC59563924 172.16.x.x POST
/SimpleAuthWebService/SimpleAuth.asmx - 8530 - 192.146.x.x
Windows-Update-Agent 200 0 0
2009-03-27 19:44:21 W3SVC59563924 172.16.x.x POST
/ClientWebService/client.asmx - 8530 - 192.146.x.x Windows-Update-Agent 200
0 0
2009-03-27 19:44:21 W3SVC59563924 172.16.x.x POST
/ClientWebService/client.asmx - 8530 - 192.146.x.x Windows-Update-Agent 200
0 0
2009-03-30 00:58:08 W3SVC59563924 172.16.x.x HEAD /selfupdate/wuident.cab
0903300102 8530 - 192.146.x.x Windows-Update-Agent 200 0 0
2009-03-30 00:58:08 W3SVC59563924 172.16.x.x HEAD
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0903300102 8530 - 192.146.x.x
Windows-Update-Agent 200 0 0
2009-03-30 00:58:08 W3SVC59563924 172.16.x.x GET
/selfupdate/WSUS3/x86/Other/wsus3setup.cab 0903300102 8530 - 192.146.x.x
Windows-Update-Agent 200 0 0
But there is nothing for the reporting part.
WSUS Client Diagnostics Tool
Checking Machine State
Checking for admin rights to run tool . . . . . . . . . PASS
Automatic Updates Service is running. . . . . . . . . . PASS
Background Intelligent Transfer Service is not running. PASS
Wuaueng.dll version 7.2.6001.788. . . . . . . . . . . . PASS
This version is WSUS 2.0
Checking AU Settings
AU Option is 4: Scheduled Install . . . . . . . . . . . PASS
Option is from Policy settings
Checking Proxy Configuration
Checking for winhttp local machine Proxy settings . . . PASS
Winhttp local machine access type
<Direct Connection>
Winhttp local machine Proxy. . . . . . . . . . NONE
Winhttp local machine ProxyBypass. . . . . . . NONE
Checking User IE Proxy settings . . . . . . . . . . . . PASS
User IE Proxy. . . . . . . . . . . . . . . . . NONE
User IE ProxyByPass. . . . . . . . . . . . . . NONE
User IE AutoConfig URL Proxy . . . . . . . . . NONE
User IE AutoDetect
AutoDetect not in use
Checking Connection to WSUS/SUS Server
WUServer = http://panakeia.envbop.net:8530
WUStatusServer = http://panakeia.envbop.net:8530
UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
VerifyWUServerURL() failed with hr=0x80072ee2
The operation timed out
I'll do further investigation and let you know.
Cheers
"Lawrence Garvin [MVP]" <lawr...@news.postalias> wrote in message
news:u98845zr...@TK2MSFTNGP05.phx.gbl...
Lawrence Garvin [MVP]
> Checking Connection to WSUS/SUS Server
> WUServer = http://panakeia.envbop.net:8530
> WUStatusServer = http://panakeia.envbop.net:8530
> UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
>
> VerifyWUServerURL() failed with hr=0x80072ee2
It looks like the core issue is the selfupdate on port 80 isn't working.
You're getting timeouts trying to access the selfupdate feature. If
selfupdate doesn't work, then *nothing* will work.
Please confirm that you can access the WSUS Server on port 80 from a machine
on the DMZ by browsing to this URL:
http://panekeia.envbop.net/selfupdate/iuident.cab
You should get a File Open|Save dialog when browsing to that URL.
Also, of particular interest is why this machine is trying to obtain the
client from the ~\X86\Other folder. What OS is running on the client machine
represented by this logfile and CDT?
Could you confirm that the address identified as 192.146.x.x in your
logfiles is the actual client, and not an IP Address assigned to the
Checkpoint server?
Finally, in scenarios such as these, it's necessary that the WSUS Server
know how to route traffic to the 192.146.x.0 subnet. Generally if the
interface to the DMZ is the same interface to the Internet, and that
interface is the Default Gateway, then it should work. But if the network
does not match this basic configuration, you may be encountering routing
errors on the trip back from the WSUS Server to the client.
Dummy
"Lawrence Garvin [MVP]" <lawr...@news.postalias> wrote in message
news:eof7dOTs...@TK2MSFTNGP05.phx.gbl...
> "Dummy" <du...@someco.com> wrote in message
> news:ujPjujOs...@TK2MSFTNGP05.phx.gbl...
>
>> Checking Connection to WSUS/SUS Server
>> WUServer = http://panakeia.envbop.net:8530
>> WUStatusServer = http://panakeia.envbop.net:8530
>> UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
>>
>> VerifyWUServerURL() failed with hr=0x80072ee2
>
>
> It looks like the core issue is the selfupdate on port 80 isn't working.
> You're getting timeouts trying to access the selfupdate feature. If
> selfupdate doesn't work, then *nothing* will work.
>
> Please confirm that you can access the WSUS Server on port 80 from a
> machine on the DMZ by browsing to this URL:
>
> http://panekeia.envbop.net/selfupdate/iuident.cab
>
> You should get a File Open|Save dialog when browsing to that URL.
Yes I do. (correct spelling of server)
but this timesout
http://panakeia.envbop.net:8530/SimpleAuthWebService/SimpleAuth.asmx
even though it shows in the IIS logs.
>
> Also, of particular interest is why this machine is trying to obtain the
> client from the ~\X86\Other folder. What OS is running on the client
> machine represented by this logfile and CDT?
Windows Server 2003 SE SP2. Its a VM
>
> Could you confirm that the address identified as 192.146.x.x in your
> logfiles is the actual client, and not an IP Address assigned to the
> Checkpoint server?
Yes the IP address is that of the actual server. Its 192.146.150.196
>
> Finally, in scenarios such as these, it's necessary that the WSUS Server
> know how to route traffic to the 192.146.x.0 subnet. Generally if the
> interface to the DMZ is the same interface to the Internet, and that
> interface is the Default Gateway, then it should work. But if the network
> does not match this basic configuration, you may be encountering routing
> errors on the trip back from the WSUS Server to the client.
Routing works as the wsus server also monitors the servers in the DMZ.
I use RDP from the WSUS server to this dmz server. Also we push sql data out
to the dmz for web content.
The firewall has 4 nics - internal, internet and 2 DMZs. The class C network
is split
into 3 subnets. This has been working correctly for the past 4 years.
The DMZ machine is in a workgroup of its own.
Cheers
Lawrence Garvin [MVP]
>> Please confirm that you can access the WSUS Server on port 80 from a
>> machine on the DMZ by browsing to this URL:
>>
>> http://panekeia.envbop.net/selfupdate/iuident.cab
>>
>> You should get a File Open|Save dialog when browsing to that URL.
>
> Yes I do. (correct spelling of server)
> but this timesout
> http://panakeia.envbop.net:8530/SimpleAuthWebService/SimpleAuth.asmx
> even though it shows in the IIS logs.
Have there been any 'configurations' or 'reconfigurations' of ASP.NET or the
.NET Framework v2 on this IIS server?
It would seem you're only getting timeouts on webservices, not on raw file
transfers.
Check all of the WSUS IIS app resources and make sure they're all configured
to use the WSUSPool application pool.
>> Also, of particular interest is why this machine is trying to obtain the
>> client from the ~\X86\Other folder. What OS is running on the client
>> machine represented by this logfile and CDT?
>
> Windows Server 2003 SE SP2.
Okay, I researched this a bit. This is the correct folder for this OS. (I'd
forgotten that MS changed up the folder tree between the v5.8 and v7.x
clients.)
--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Dummy
All solved now.
There was a CheckPoint SmartDefense rule that was droping all non standard
ports used by HTTP without any logging or warning so never picked it up
first.
Thanks for your help.
Cheers
"Lawrence Garvin [MVP]" <lawr...@news.postalias> wrote in message
news:%23Z0V3PX...@TK2MSFTNGP02.phx.gbl...