Update Services not going to local server

  • Thread starter Paul Bergson [MVP-DS]
  • Start date

P

Paul Bergson [MVP-DS]

I have defined a gpo to set the following two attributes:

Computer Configuration \ Policies \ Administrative Templates \ Windows
Components \ Windows Update

Configure Automatic Updates = Enabled
Automatic Updating = 5 - Allow local admin to choose setting

Specify intranet microsoft update service location
update service = wsus.x.y
statistics server = wsus.x.y


I have gone into the registry and verified that:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer
= wsus.x.y
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer
= wsus.x.y

To verify that the system is hitting the internal server, I ran WireShark
and noticed that WU never hits my internal wsus server. Instead it appears
to be going externally.

Does anything appear incorrect in how I have the system configured? Am I
missing a policy setting? Any other things to sniff to try and track down
what is going on?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
 
Ad

Advertisements

P

Paul Bergson [MVP-DS]

I statred to think about this, maybe what I am expecting is incorrect. If I
open a browser and point it to http://update.microsoft.com/windowsupdate, is
this the same as allowing WU to run? This doesn't seem logical, since I
don't see it redirect so it shouldn't be hitting the internal server.

I'm now thinking this is working correctly I am just testing incorrectly.

Feedback?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
 
M

MowGreen

Since I don't know which NG you'll see this from Paul, I've x-posted it
to the WSUS NG and left the other x-posts:
news://msnews.microsoft.com/microsoft.public.windows.server.update_services

MowGreen
===============
*-343-* FDNY
Never Forgotten
===============

banthecheck.com
"Security updates should *never* have *non-security content* prechecked"
 
L

Lawrence Garvin [MVP]

Paul Bergson [MVP-DS] wrote:

Hi Paul!

The most likely cause for this is either UseWUServer is set to false
(dword:0x0) in the registry, or there are conflicting values configured in
the registry (and not overridden by your GPO) causing the WUAgent to ignore
the configured values in the registry and use its internal defaults (which
is to use AU).

Incidentally, verifying that the client system is hitting the internal
server can be done without packet sniffing, and truly, a more authoritative
source is that:
1. A client which successfully connects with a WSUS server will be listed in
the All Computers node of the WSUS console with a Last Contact Date
representative of the actual contact.
2. The WindowsUpdate.log records all WUAgent activity, in extensive detail,
including every contact with every webservice available on the WSUS server.

While I've not tested this, it's also possible that the AUOptions=5 policy
setting is not causing the WUAgent to reread its configuration on the policy
refresh and is still operating under the locally configured AU settings.
Restarting the AU service will force the WUAgent to re-read the current
registry settings and respond to the configured WSUS preferences.

In general, to verify the configuration of the client:
a. Use GPRESULT or RSOP to verify that the configured WSUS GPO is actually
being applied.
b. Validate all registry values in the ~\WindowsUpdate policy keys, as
matching the configured or desired policy settings, particularly as relates
to values corresponding to "Not Configured" policy settings.
c. Restart the AU service and inspect the configuration values being
recorded in the WindowsUpdate.log at service startup.





--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
 
P

Paul Bergson [MVP-DS]

My question now is, if I pull up WU in a browser where does the client
connect to? Microsoft or my internal server? I think Microsoft is there a
way to point internally?

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.

Lawrence Garvin said:
Paul Bergson [MVP-DS] wrote:

Hi Paul!

The most likely cause for this is either UseWUServer is set to false
(dword:0x0) in the registry, or there are conflicting values configured in
the registry (and not overridden by your GPO) causing the WUAgent to
ignore the configured values in the registry and use its internal defaults
(which is to use AU).

Incidentally, verifying that the client system is hitting the internal
server can be done without packet sniffing, and truly, a more
authoritative source is that:
1. A client which successfully connects with a WSUS server will be listed
in the All Computers node of the WSUS console with a Last Contact Date
representative of the actual contact.
2. The WindowsUpdate.log records all WUAgent activity, in extensive
detail, including every contact with every webservice available on the
WSUS server.

While I've not tested this, it's also possible that the AUOptions=5 policy
setting is not causing the WUAgent to reread its configuration on the
policy refresh and is still operating under the locally configured AU
settings. Restarting the AU service will force the WUAgent to re-read the
current registry settings and respond to the configured WSUS preferences.

In general, to verify the configuration of the client:
a. Use GPRESULT or RSOP to verify that the configured WSUS GPO is actually
being applied.
b. Validate all registry values in the ~\WindowsUpdate policy keys, as
matching the configured or desired policy settings, particularly as
relates to values corresponding to "Not Configured" policy settings.
c. Restart the AU service and inspect the configuration values being
recorded in the WindowsUpdate.log at service startup.





--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
 
L

Lawrence Garvin [MVP]

My question now is, if I pull up WU in a browser where does the client
connect to?

When you pull up MU/WU in a brower, that connection is *always* to
Microsoft.com.
I think Microsoft is there a way to point internally?

WSUS does not provide a web-based client-side UI. It's strictly a
corporate-level implementation of "Automatic Updates", albeit with a larger
catalog of products.

To initiate a client-side detection against the WSUS Server, run the
command: wuauclt /detectnow.
In addition, on Vista and later systems, you can target the scan against the
WSUS server using the WUApp in Control Panel. If you click on "Check for
updates" in the task pane, the scan will be executed against the WSUS server
on a WSUS-enabled client, or against MU otherwise; you can force the scan to
be run against MU on a WSUS-enabled client by clicking on the link in the
main pane that says "Check online for updates from Microsoft Update"


--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
 
Ad

Advertisements

P

Paul Bergson [MVP-DS]

This is exactly what I was looking for.

Thank-You!

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
 
P

Paul Russell

The browser will load update.microsoft.com but the actual binding of the WUA
agent will be to which ever service it is registered for.

In this case, WSUS managed means updates will come from WSUS ... so the
browser experience will be a falsetto of what is truly going on under the
covers since the activeX is trolling over WUA.

--
thanks
..paul

/*++

Paul Russell

--*/
 
Ad

Advertisements

L

Lawrence Garvin [MVP]

Paul Russell said:
The browser will load update.microsoft.com but the actual binding of the
WUA agent will be to which ever service it is registered for.

In this case, WSUS managed means updates will come from WSUS ... so the
browser experience will be a falsetto of what is truly going on under the
covers since the activeX is trolling over WUA.

I'm sorry, Paul, but this is not a true statement, and the proof is logged
in the WindowsUpdate.log when such an event occurs.

If you want unequivocal proof, however, just pull the plug on the WSUS
Server and watch the WUA trip happily along downloading from WU -- oblivious
to the fact that the WSUS server has gone away. Only when the WUA executes
the next regularly scheduled "WSUS" detection will it log errors that it
cannot connect.

Furthermore, if what you say were true, it would be *impossible* to install
updates from Microsoft Update in a WSUS environment unless the *content*
were actually physically present on the WSUS Server -- where would the WUA
get the content from? Since I have routinely used MU to download and install
service packs (because I don't generally keep SP content on my WSUS server),
I can empirically attest to the fact that the WUA will happly detect and
acquire content from =WU/MU=, irrespective of the setting of the UseWUServer
registry value, and regardless of whether the content is even synchronized
to that WSUS server.

For the sake of convenience,though, here's a scan against WU/MU just
performed on my WSUS-configured Windows 7 system by clicking on "Check for
updates from Microsoft Update", and then immediately after reran a detection
against my WSUS server. (Note: I have declined any "RC" updates on my WSUS
server, and currently I have =zero= updates on the WSUS Server reported as
"Needed" by this system.)

Results from WU:
2009-10-30 00:43:08:318 1116 11c4 PT + ServiceId =
{7971F918-A847-4430-9279-4A52D1EFE18D}, Server URL =
https://www.update.microsoft.com/v6/ClientWebService/client.asmx
2009-10-30 00:43:31:361 1116 11c4 Agent * Found 50 updates and 63
categories in search; evaluated appl. rules of 1090 out of 1520 deployed
entities

Results from WSUS:
2009-10-30 00:43:41:312 1116 11c4 PT + ServiceId =
{3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://sbs2003r2:8530/ClientWebService/client.asmx
2009-10-30 00:43:50:749 1116 11c4 Agent * Found 0 updates and 61
categories in search; evaluated appl. rules of 574 out of 794 deployed
entities

Note also that the number of categories (WU: 63; WSUS: 61), the total number
of updates in the catalog (WU: 1520; WSUS: 794), and the number of updates
actaully evaluated (WU: 1090; WSUS: 574) is different in every case, and
scanning against WU identified =50= applicable updates.

--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)

My Blog: http://onsitechsolutions.spaces.live.com
Microsoft WSUS Website: http://www.microsoft.com/wsus
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Top