|
|
It seems to me that the best way to add a client to WSUS is through Group
Policy. But I found that this only partially worked.
I followed the instructions for "point your client computer to your WSUS
server" which was to set GPO > Computer Configuration > Administrative
Templates > Windows Components > Windows Update > Specify intranet Microsoft
update service location to the URL of the WSUS server. I did this for only
one computer.
This procedure did add the computer to WSUS, but the WSUS console continued
to say that the computer had not reported.
When I ran WSUS Client Diagnostics Tool, it told me that "WUStatusServer"
and "WUServer" were not set through Policy. On a hunch, I opened the local
security policy on the client computer and changed "Specify intranet
Microsoft update service location" from "Not configured".
Now the client computer appears to be fully functional in WSUS. However,
shouldn't I be able to do this through Group Policy if I want to do the same
for all computers in the network?
|
|
Cam wrote:
[Quoted Text] > Now the client computer appears to be fully functional in WSUS. However,
> shouldn't I be able to do this through Group Policy if I want to do the same
> for all computers in the network?
Of course. Either the group policy for WSUS wasn't configured properly, or you
have an issue with group policy itself.
Post the full results of the WSUS client diagnostic tool. You should also check
in the registry to see whether the group policy got applied properly. This
documentation will help:
<http://technet2.microsoft.com/WindowsServer/en/library/75ee9da8-0ffd-400c-b722-aeafdb68ceb31033.mspx?mfr=true>
Harry.
|
|
|
[Quoted Text] > Post the full results of the WSUS client diagnostic tool.
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 running. . . PASS
Wuaueng.dll version 7.0.6000.374. . . . . . . . . . . . PASS
This version is WSUS 2.0
Checking AU Settings
AU Option is 2 : Notify Prior to Download . . . . . . . PASS
Option is from Control Panel
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
WUStatusServer is not set through Policy
WUServer is not set through Policy
UseWuServer value is missing. . . . . . . . . . . . . . FAIL
GetAUSettingsRegistry(true,pszUseWu,&dwUseWu) failed with hr=0x80070002
The system cannot find the file specified.
> You should also check
> in the registry to see whether the group policy got applied properly. This
> documentation will help:
>
> <http://technet2.microsoft.com/WindowsServer/en/library/75ee9da8-0ffd-400c-b722-aeafdb68ceb31033.mspx?mfr=true>
When I check HKLMACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate,
the WUServer and WUStatusServer are not there. (It's not that they are blank
or incorrect; they are just not there at all.) When I set the correct
settings in Local Computer Policy, then the registry entries are present and
correct.
|
|
Cam wrote:
[Quoted Text] > When I check HKLMACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate,
> the WUServer and WUStatusServer are not there. (It's not that they are blank
> or incorrect; they are just not there at all.)
OK, that seems clear enough; your group policy isn't being applied. Check that
the computer is in the OU the group policy applies to, that the group policy is
enabled, that the computer section of the group policy is enabled, that group
policy permissions don't block access from the computer, and whatever else I've
forgotten; look in the system and application event logs for any messages about
group policy errors; doublecheck that the WSUS settings in the group policy are
correct, i.e., the same settings that work in local policy.
The gpresult command-line tool will show you what group policy objects the
computer is trying to apply, and with the /v flag will try to show the policy
itself (it sometimes crashes on my system).
Harry.
|
|
|
[Quoted Text] > OK, that seems clear enough; your group policy isn't being applied. Check
that
> the computer is in the OU the group policy applies to, that the group policy is
> enabled, that the computer section of the group policy is enabled, that group
> policy permissions don't block access from the computer, and whatever else I've
> forgotten; look in the system and application event logs for any messages about
> group policy errors; doublecheck that the WSUS settings in the group policy are
> correct, i.e., the same settings that work in local policy.
I have confirmed all of this. Computer is in the OU. GP's link is enabled.
GPO's status is enabled. GP permissions do not list computers; the user has
"Read" and "Apply Group Policy" permission. Local and DC event logs show no
GP errors.
The GPO settings look correct. The only 3 settings in the GPO are:
Computer Config > Admin Templates > Win Components > Win Upd
Configure Auto Updates = Allow local admin to choose
update service location = http://<computername> (for both)
> The gpresult command-line tool will show you what group policy objects the
> computer is trying to apply, and with the /v flag will try to show the policy
> itself (it sometimes crashes on my system).
gpresult gave some additional info. The condensed output is:
COMPUTER SETTINGS
The following GPOs were not applied because they were filtered out
WSUS
Filtering: Not Applied (Unknown Reason)
How to diagnose the unknown reason for not applied?
|
|
[crosspost to microsoft.public.windows.group_policy added]
Cam wrote:
[Quoted Text] > The GPO settings look correct. The only 3 settings in the GPO are:
> Computer Config > Admin Templates > Win Components > Win Upd
> Configure Auto Updates = Allow local admin to choose
Have you gone into the control panel and configured it? I've never used this
setting so I don't know quite how it works; it might be worth trying one of the
other settings (mode 2 would be harmless for testing purposes) just in case this
helps.
> GP permissions do not list computers; the user has
> "Read" and "Apply Group Policy" permission.
If the computer account doesn't have permission, the computer policy won't be
applied. This permission is usually granted via "Authenticated Users"; does
"Authenticated Users" have "Apply Group Policy" permission?
> gpresult gave some additional info. The condensed output is:
> COMPUTER SETTINGS
> The following GPOs were not applied because they were filtered out
> WSUS
> Filtering: Not Applied (Unknown Reason)
>
> How to diagnose the unknown reason for not applied?
I presume this refers to group policy WMI filtering, which I'm not familiar
with. Are you using the Group Policy Management Console to manage your group
policy? If you click on "Group Policy Objects" the list of GPOs will show
whether WMI filtering is active; what does it say?
At this point you might get better advice from
microsoft.public.windows.group_policy since your problem probably isn't
WSUS-specific. I've crossposted.
Harry.
|
|
|
[Quoted Text] > > The GPO settings look correct. The only 3 settings in the GPO are:
> > Computer Config > Admin Templates > Win Components > Win Upd
> > Configure Auto Updates = Allow local admin to choose
>
> Have you gone into the control panel and configured it? I've never used this
> setting so I don't know quite how it works; it might be worth trying one of the
> other settings (mode 2 would be harmless for testing purposes) just in case this
> helps.
The GPO was set to 5 (local admin decide) and the client was set to notify
but don't download. I changed GPO to 2 and forced update. No immediate change.
> > GP permissions do not list computers; the user has
> > "Read" and "Apply Group Policy" permission.
>
> If the computer account doesn't have permission, the computer policy won't be
> applied. This permission is usually granted via "Authenticated Users"; does
> "Authenticated Users" have "Apply Group Policy" permission?
Actually it didn't. I set "Authenticated Users" to have "Apply Group Policy"
and again, no immediate fix.
> > gpresult gave some additional info. The condensed output is:
> > COMPUTER SETTINGS
> > The following GPOs were not applied because they were filtered out
> > WSUS
> > Filtering: Not Applied (Unknown Reason)
> >
> > How to diagnose the unknown reason for not applied?
>
> I presume this refers to group policy WMI filtering, which I'm not familiar
> with. Are you using the Group Policy Management Console to manage your group
> policy? If you click on "Group Policy Objects" the list of GPOs will show
> whether WMI filtering is active; what does it say?
The "WMI Filter" column reads "None" for all GPOs.
|
|
|
[Quoted Text] > > gpresult gave some additional info. The condensed output is:
> > COMPUTER SETTINGS
> > The following GPOs were not applied because they were filtered out
> > WSUS
> > Filtering: Not Applied (Unknown Reason)
> >
> > How to diagnose the unknown reason for not applied?
>
> I presume this refers to group policy WMI filtering, which I'm not familiar
> with. Are you using the Group Policy Management Console to manage your group
> policy? If you click on "Group Policy Objects" the list of GPOs will show
> whether WMI filtering is active; what does it say?
The "WMI Filter" reads "None" for all GPOs.
|
|
Cam wrote:
[Quoted Text] >> If the computer account doesn't have permission, the computer policy won't be
>> applied. This permission is usually granted via "Authenticated Users"; does
>> "Authenticated Users" have "Apply Group Policy" permission?
>
> Actually it didn't. I set "Authenticated Users" to have "Apply Group Policy"
> and again, no immediate fix.
I think this is your problem. It probably needs "Read" access as well as "Apply
Group Policy"; at least, that's the default setting.
After granting "Read" access, wait ten minutes, then use the gpupdate command
line tool to refresh group policy, then see what gpresult says.
Harry.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:ev6Ikj$wHHA.1164[ at ]TK2MSFTNGP02.phx.gbl...
[Quoted Text] >> The GPO settings look correct. The only 3 settings in the GPO are:
>> Computer Config > Admin Templates > Win Components > Win Upd
>> Configure Auto Updates = Allow local admin to choose
>
> Have you gone into the control panel and configured it?
You *cannot* configure a WSUS environment from the Control Panel alone.
You can configure the behavior of the WUA vis-a-vis how/when to
download/install, but in order to tell the WUA that it's using a WSUS Server
instead of the Microsoft Automatic Updates service, you must either
configure Local Policy or edit the registry to set the UseWUServer,
WUServer, and WUStatusServer registry values.
The AUOption #5 is merely to allow delegation of the how/when of
download/install to a local Administrator, but the other settings in the GPO
must still be properly set, specifically the "Specify intranet Microsoft
update services location" policy, which is what sets UseWUServer=dword:0x1
and the URLs for WUServer and WUStatusServer.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] > The AUOption #5 is merely to allow delegation of the how/when of
> download/install to a local Administrator, but the other settings in the GPO
> must still be properly set, specifically the "Specify intranet Microsoft
> update services location" policy, which is what sets UseWUServer=dword:0x1
> and the URLs for WUServer and WUStatusServer.
Yep, he's already done that. I'm right in thinking that "Configure Automatic
Updates" and "Specify intranet Microsoft update services location" are the only
two policy items that *must* be set? (In fact "Configure Automatic Updates"
isn't actually needed either, is it - provided of course the control panel is
used instead.)
The problem appears to be that his group policy wasn't being applied at all, as
the result of incorrect security permissions on the GPO.
Harry.
|
|
Perhaps I can offer a suggestion if you still can't get this to work. Based
on the "WSUS"; "Filtering: Not Applied (Unknown Reason)" report from
gpresult, the problem is not the settings inside the GPO by something about
the GPO environment is preventing the client from applying the GPO at all.
Are there any other GPOs applied to this client, if so, does gpresult
indicate a problem with any of them?
Check the Event Logs for entries relating to DNS client, GroupPolicy.
What version of Windows is the client running?
When the GPO is applied correctly, any settings made by gpedit or Control
Panel, Windows Update on the client will be overriden by the GPO.
Perhaps a fresh start might help.
1. create a brand new GPO
2. Do Not change anything except the actual settings the GPO is to push to
the client computer - that is Do Not change Security Filtering, WMI
Filtering or anyting on the Delegation tab
3. open the GPO in GPO Editor
4. in Computer Configuration, Adminstrative Templates, Windows Components,
Windows Update, set:
Specify intranet Microsoft update service location Properties: Enabled
in both text boxes, key http:// followed by the unqualified name of
the server running WSUS (e.g. http://wsusserver)
Configure Automatic Updates: Enabled
Configure automtic updating: 2 - Notify for download and notify for
install (you can always change this later)
Schedule install day: 0 - Every day
Scheduled installl time: 21:00
Reschedule Automatic Updates scheduled installations: Enabled
Wait after sytem starup (minutes) 1
Automatic Updates detection frequency: Enabled
Check fro updates at the following interval (hour): 1
Allow Automatic Updtes immediate installation: Enabled
Allow non-administrators to receive update notifications
5. Link the GPO to the OU containing the (test) client computer - ensure the
Link is Enabled and NOT Enforced
6. "delete" (unlink) the old (WSUS) GPO from the OU
7. if the domain has multiple domain controllers, wait for the changes to be
replicated
8. restart the client computer (not strictly necessary, but probably the
simplest thing to do)
9. logon to the client using a domain user account that is an administrator
on the client
10. run the command - gpresult /v
Does the new GPO show up inside COMPUTER SETTINGS; Applied Group Policy
Objects? You should also see several lines that say "GPO: WSUS
Configuration" etc. (unfortunatly, gpresult doesn't group all the settings
for a GPO togerther in its report, so the ones relating to the WSUS
configuration will be intermingled with other GPO settings).
--
Bruce Sanderson MVP Printing
http://members.shaw.ca/bsanders
It is perfectly useless to know the right answer to the wrong question.
"Cam" <Cam[ at ]discussions.microsoft.com> wrote in message
news:70E3BE25-72A0-403F-88DC-134048D538A5[ at ]microsoft.com...
[Quoted Text] >> > gpresult gave some additional info. The condensed output is:
>> > COMPUTER SETTINGS
>> > The following GPOs were not applied because they were filtered out
>> > WSUS
>> > Filtering: Not Applied (Unknown Reason)
>> >
>> > How to diagnose the unknown reason for not applied?
>>
>> I presume this refers to group policy WMI filtering, which I'm not
>> familiar
>> with. Are you using the Group Policy Management Console to manage your
>> group
>> policy? If you click on "Group Policy Objects" the list of GPOs will
>> show
>> whether WMI filtering is active; what does it say?
>
> The "WMI Filter" reads "None" for all GPOs.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:uBaaeZDxHHA.4652[ at ]TK2MSFTNGP05.phx.gbl...
[Quoted Text] > Lawrence Garvin (MVP) wrote:
>
>> The AUOption #5 is merely to allow delegation of the how/when of
>> download/install to a local Administrator, but the other settings in the
>> GPO must still be properly set, specifically the "Specify intranet
>> Microsoft update services location" policy, which is what sets
>> UseWUServer=dword:0x1 and the URLs for WUServer and WUStatusServer.
>
> Yep, he's already done that. I'm right in thinking that "Configure
> Automatic Updates" and "Specify intranet Microsoft update services
> location" are the only two policy items that *must* be set? (In fact
> "Configure Automatic Updates" isn't actually needed either, is it -
> provided of course the control panel is used instead.)
Once any group policy is applied that affects that particular key, the
Control Panel interface is disabled.
The only way a person could set the Configure Automatic Updates settings via
the Control Panel is if *NO* other policy were applied, thus your believe
that he'd already set the WSUS URLs is, I believe, incorrect.
> The problem appears to be that his group policy wasn't being applied at
> all, as the result of incorrect security permissions on the GPO.
Quite likely. (Which also means there were no URLs set, so the WUA was
detecting via AU, not WSUS.)
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
>
> Harry.
|
|
Lawrence Garvin (MVP) wrote:
[Quoted Text] >> Yep, he's already done that. I'm right in thinking that "Configure
>> Automatic Updates" and "Specify intranet Microsoft update services
>> location" are the only two policy items that *must* be set? (In fact
>> "Configure Automatic Updates" isn't actually needed either, is it -
>> provided of course the control panel is used instead.)
>
> Once any group policy is applied that affects that particular key, the
> Control Panel interface is disabled.
Unless you've chosen option 5 (as he originally did) I assume? Otherwise, how
would option 5 work?
> The only way a person could set the Configure Automatic Updates settings via
> the Control Panel is if *NO* other policy were applied, thus your believe
> that he'd already set the WSUS URLs is, I believe, incorrect.
Well, he'd set them in the group policy; of course, since the group policy
wasn't being applied ... :-)
Harry.
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:umt$o%23PxHHA.3696[ at ]TK2MSFTNGP03.phx.gbl...
[Quoted Text] >>> Yep, he's already done that. I'm right in thinking that "Configure
>>> Automatic Updates" and "Specify intranet Microsoft update services
>>> location" are the only two policy items that *must* be set? (In fact
>>> "Configure Automatic Updates" isn't actually needed either, is it -
>>> provided of course the control panel is used instead.)
>> Once any group policy is applied that affects that particular key, the
>> Control Panel interface is disabled.
> Unless you've chosen option 5 (as he originally did) I assume? Otherwise,
> how would option 5 work?
Good point. Yes, I believe in that case the dialog would stay enabled.
Thanks for the correction!
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://www.microsoft.com/wsus
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
|