WSUS group policy won't go away

[PA Bear [MS MVP]]

[[ So you're in the right pew but wrong church. Forwarded to WSUS newsgroup
(microsoft.public.windows.server.update_services) via crosspost as a
convenience to OP.

On the web:
http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.windows.server.update_services

In your newsreader:
news://msnews.microsoft.com/microsoft.public.windows.server.update_services
]]

So I have this machine which was once part of a domain with a group policy
pointing WU to a specific WSUS server. After removing the machine from the
domain, and assigning it to a workgroup, it still shows "Managed by your
system administrator", which forces me to click "Check online for updates
from Microsoft Update".
How do I go about solving this problem? I've already tried gupdate /force,
didn't do anything.
Thanks a lot for your help!

[Lawrence Garvin (MVP)]

So I have this machine which was once part of a domain with a group policy
pointing WU to a specific WSUS server. After removing the machine from the
domain, and assigning it to a workgroup, it still shows "Managed by your
system administrator", which forces me to click "Check online for updates
from Microsoft Update".

This is really an Active Directory/Group Policy question, and it's merely
manifesting as a WSUS issue.

This is *normal* behavior of a machine disjoined from a domain.

Group Policies set registry values. Registry values are STATIC.
Unless some other policy undoes those registry values, they don't change.

This is how Group Policies continue to function on notebook computers even
while the user has it at home.

How do I go about solving this problem? I've already tried gupdate /force,
didn't do anything.

Configure Local Policy. Set "specify intranet update server location" to
DISABLED.

Alternatively, reset the registry value "UseWUServer" to dword:0x0
(DISABLED)
in the registry key
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

and REBOOT.

Ideally, you should create a special OU in your AD organization called
"Pending Removal" or some such moniker. Configure duplicates of all existing
policies for this OU, except with all settings reversed (e.g. if the WSUS
policy enables UseWUServer, then the policy for this OU disables
UseWUServer). When a machine becomes marked for removal from the domain,
move the machine to this OU, wait 2 hours for the regular policy refresh,
then disjoin the machine from the domain. Voila! No left-over group policies
on the machine! :)

[DaveMills]

On Thu, 4 Dec 2008 22:13:52 -0600, "Lawrence Garvin \(MVP\)"

Post by Lawrence Garvin (MVP)

So I have this machine which was once part of a domain with a group policy
pointing WU to a specific WSUS server. After removing the machine from the
domain, and assigning it to a workgroup, it still shows "Managed by your
system administrator", which forces me to click "Check online for updates
from Microsoft Update".

This is really an Active Directory/Group Policy question, and it's merely
manifesting as a WSUS issue.
This is *normal* behavior of a machine disjoined from a domain.
Group Policies set registry values. Registry values are STATIC.
Unless some other policy undoes those registry values, they don't change.

I'd not thought about this before. Many GPO settings are removed when the policy
no longer applies. This was quite a well stated feature (by Microsoft) for W2K
(over NT policies). An exception was Security Policy. I have never looked at how
this is implemented but it must require support from the application.

The following blog summa rises this behavior (ignoring the GPP stuff)
http://blogs.technet.com/grouppolicy/archive/2008/03/04/gp-policy-vs-preference-vs-gp-preferences.aspx

So why exactly is the GPO policy not removed for WSUS settings? It must be a
specific design decision of the development team. One that may have been better
to have been "remove when the GPO falls out of scope" like most of the policy
settings. I understand the reason for making security setting operate
differently e.g. password length not resetting to zero etc. But for WSUS not
removing the settings and going back to Windows Update servers actually
decreases security.

Post by Lawrence Garvin (MVP)
This is how Group Policies continue to function on notebook computers even
while the user has it at home.

How do I go about solving this problem? I've already tried gupdate /force,
didn't do anything.

Configure Local Policy. Set "specify intranet update server location" to
DISABLED.
Alternatively, reset the registry value "UseWUServer" to dword:0x0
(DISABLED)
in the registry key
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
and REBOOT.
Ideally, you should create a special OU in your AD organization called
"Pending Removal" or some such moniker. Configure duplicates of all existing
policies for this OU, except with all settings reversed (e.g. if the WSUS
policy enables UseWUServer, then the policy for this OU disables
UseWUServer). When a machine becomes marked for removal from the domain,
move the machine to this OU, wait 2 hours for the regular policy refresh,
then disjoin the machine from the domain. Voila! No left-over group policies
on the machine! :)

[Lawrence Garvin (MVP)]

Post by DaveMills

Post by Lawrence Garvin (MVP)
Group Policies set registry values. Registry values are STATIC.
Unless some other policy undoes those registry values, they don't change.

I'd not thought about this before. Many GPO settings are removed when the policy
no longer applies.

Many are.... except those that involve registry settings.

Settings that directly configure system, account, or UI behavior at the
moment of policy application would not be retained (e.g. an
application-publishing policy)

Many security settings aren't actually applied at the machine, they're
applied in the AD database, thus there would be no machine-level retention
of those settings on a non-domain connected computer.

Post by DaveMills
This was quite a well stated feature (by Microsoft) for W2K
(over NT policies). An exception was Security Policy. I have never looked at how
this is implemented but it must require support from the application.
So why exactly is the GPO policy not removed for WSUS settings?

Because of what I just stated. The GPO policy for WSUS, among others, is
implemented to configure the registry, not to directly affect the behavior
of the system. The registry is static.

Regardless of what was originally described as to the behavior of Group
Policies, I would hope that it's an obvious fact that there's no way a
machine would "know" it was suddenly "not subject to" a Group Policy, and
undo the change.

And, merely setting a policy back to "Not Configured", even on a machine
that remains in the domain, does not 'undo' previously applied policies, it
merely ceased to continue to enforce them. One would have to actually know
which setting(s) needed to be explicitly reversed in order to undo a policy.
(e.g. for WSUS/WUA, it would have to be known that only the "Specify
intranet Microsoft update services location" should be DISABLED, rather than
merely Not Configured.

Post by DaveMills
It must be a
specific design decision of the development team. One that may have been better
to have been "remove when the GPO falls out of scope" like most of the policy
settings.

How would you determine "when the GPO falls out of scope". Would you want a
non-LAN connected notebook to suddenly not honor policy because the user is
logged on at home to a cached domain credential?

Remember, also, the WSUS/WUA GPO is a *machine* policy, not a user policy.

Now, yes, perhaps it would be useful if there were some automagic way for
AD/GP to 'undo' applied group policies when a machine is removed from the
domain -- but that also presumes:
[a] that the machine is being disjoined from the machine itself (not after
the fact, say when a machine is stolen, destroyed, or simply dies from old
age), and
[b] imposes some sort of 'decision-making' on the process to determine how
to reverse the policy application.

Post by DaveMills
I understand the reason for making security setting operate
differently e.g. password length not resetting to zero etc. But for WSUS not
removing the settings and going back to Windows Update servers actually
decreases security.

Since WSUS is not a domain-based service, but merely uses Group Policy as a
means to distribute configuration settings, is it necessarily a good thing
that a machine suddenly have it's update source reconfigured, merely because
it was disjoined from a domain.

So, in the end, while it *might* be useful... it might also be very
dangerous.

[DaveMills]

On Fri, 5 Dec 2008 09:43:43 -0600, "Lawrence Garvin \(MVP\)"

Post by Lawrence Garvin (MVP)

Post by DaveMills

Post by Lawrence Garvin (MVP)
Group Policies set registry values. Registry values are STATIC.
Unless some other policy undoes those registry values, they don't change.

I'd not thought about this before. Many GPO settings are removed when the policy
no longer applies.

Many are.... except those that involve registry settings.

Yes these are the ones the "tattoo the registry"

Post by Lawrence Garvin (MVP)
Settings that directly configure system, account, or UI behavior at the
moment of policy application would not be retained (e.g. an
application-publishing policy)

Then you need to explain the setting "Uninstall this application when it falls
out of the scope of management" and explain why if the setting is enabled an
application published to the domain (or OU) will be uninstalled when the machine
leaves the domain.

Post by Lawrence Garvin (MVP)
Many security settings aren't actually applied at the machine, they're
applied in the AD database, thus there would be no machine-level retention
of those settings on a non-domain connected computer.

They are applied at the machine where the object resides. Thus a password length
restriction is applied to AD if the policy is applied to the DC and to the local
accounts if it is applied to the workstations.

Post by Lawrence Garvin (MVP)

Post by DaveMills
This was quite a well stated feature (by Microsoft) for W2K
(over NT policies). An exception was Security Policy. I have never looked at how
this is implemented but it must require support from the application.
So why exactly is the GPO policy not removed for WSUS settings?

Because of what I just stated. The GPO policy for WSUS, among others, is
implemented to configure the registry, not to directly affect the behavior
of the system. The registry is static.
Regardless of what was originally described as to the behavior of Group
Policies, I would hope that it's an obvious fact that there's no way a
machine would "know" it was suddenly "not subject to" a Group Policy, and
undo the change.

But it is aware. Try setting up a policy to disable the Run command for a user,
when the policy is deleted the run command comes back.

Post by Lawrence Garvin (MVP)
And, merely setting a policy back to "Not Configured", even on a machine
that remains in the domain, does not 'undo' previously applied policies, it
merely ceased to continue to enforce them. One would have to actually know
which setting(s) needed to be explicitly reversed in order to undo a policy.

Read the blog I referenced - para 1. not Tattoo.......

Post by Lawrence Garvin (MVP)
(e.g. for WSUS/WUA, it would have to be known that only the "Specify
intranet Microsoft update services location" should be DISABLED, rather than
merely Not Configured.

Post by DaveMills
It must be a
specific design decision of the development team. One that may have been better
to have been "remove when the GPO falls out of scope" like most of the policy
settings.

How would you determine "when the GPO falls out of scope". Would you want a
non-LAN connected notebook to suddenly not honor policy because the user is
logged on at home to a cached domain credential?

This is not out of scope, the machine has not left the domain it has just lost
contact.

Post by Lawrence Garvin (MVP)
Remember, also, the WSUS/WUA GPO is a *machine* policy, not a user policy.
Now, yes, perhaps it would be useful if there were some automagic way for
AD/GP to 'undo' applied group policies when a machine is removed from the
[a] that the machine is being disjoined from the machine itself (not after
the fact, say when a machine is stolen, destroyed, or simply dies from old
age), and
[b] imposes some sort of 'decision-making' on the process to determine how
to reverse the policy application.

Yes the application has to be Group Policy aware. Although the new GPP can
remove a policy setting even for a non GPO aware application but it can only
reset the registry to its default value not to a previous configuration set by a
user.

Post by Lawrence Garvin (MVP)

Post by DaveMills
I understand the reason for making security setting operate
differently e.g. password length not resetting to zero etc. But for WSUS not
removing the settings and going back to Windows Update servers actually
decreases security.

Since WSUS is not a domain-based service, but merely uses Group Policy as a
means to distribute configuration settings, is it necessarily a good thing
that a machine suddenly have it's update source reconfigured, merely because
it was disjoined from a domain.

If the setting was made by a GPO then why not unmake the setting when removing
the GPO. If the setting was not made by a GPO then there is no GPO setting to
undo.

The WSUS setting are at
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
The key point here is they are under the "Policies" sub key. It is normal for
settings here to not be applied when the GPO no longer applies. I do not know
the mechanism for this. Registry settings not under the Policies sub key always
"tattoo" the registry.

Post by Lawrence Garvin (MVP)
So, in the end, while it *might* be useful... it might also be very
dangerous.

How?

[Lawrence Garvin (MVP)]

Post by DaveMills

Post by Lawrence Garvin (MVP)
Settings that directly configure system, account, or UI behavior at the
moment of policy application would not be retained (e.g. an
application-publishing policy)

Then you need to explain the setting "Uninstall this application when it falls
out of the scope of management" and explain why if the setting is enabled an
application published to the domain (or OU) will be uninstalled when the machine
leaves the domain.

I can't.. off the top of my head.. never actually used the option. :-)

A couple of possibilities occur to me, using basic reasoning...

One is that the feature only works if the machine is being modified from
within the Active Directory admin environment (e.g. being moved to another
OU, thus falling out of scope, or being removed from the domain).

Then it occurs to me that it's also reasonable that removing a machine from
the domain, at the machine's console, should be able to facilitate this as
well, since there is communication between the machine and DC at that
moment. Presumably something in the code that executes when a machine is
removed has a hook that looks at such uninstallation requirements.

However, such features can never be guaranteed to be effective:
Consider a machine being managed in the AD console that's powered off.
What happens if the next time the machine is powered on, it's not
connected to the network?
Consider a machine being removed from AC that's powered off.
What happens when the machine is powered on? The machine can no longer
authenticate with the DC, so it's not going to get any "new" policies --
including those that might be intended to uninstall software.
Consider a machine that's simply unplugged and physically moved to another
domain, or sold, or given away.
How could that machine ever get information on future behavior? At the
point of disconnection, the machine is still a viable, active member of the
domain.

The point is, those type of policies (app publishing, etc.) occur as a
direct result of communication and queries that occur during machine
authentication at power up, and during machine policy refreshes.

Post by DaveMills

Post by Lawrence Garvin (MVP)
Many security settings aren't actually applied at the machine, they're
applied in the AD database, thus there would be no machine-level retention
of those settings on a non-domain connected computer.

They are applied at the machine where the object resides. Thus a password length
restriction is applied to AD if the policy is applied to the DC and to the local
accounts if it is applied to the workstations.

Exactly my point.... and policies for =local= accounts are created by
=LOCAL= security policy and will travel with the machine in perpetuity --
until the OS is installed or the policy removed. But =DOMAIN= policies are
only effective if there's some way to cache the policy configuration on the
machine. If this involves a registry setting, then that registry setting is
not going anywhere until something tells it to change. If there's some other
way to cache settings on a local machine, that would be a consideration --
I'm not immediately aware of any. Thus, in the absence of some sort of
"local memory", those other policies can only be applied if there's active
communication between the machine and the DC.

Post by DaveMills

Post by Lawrence Garvin (MVP)
Regardless of what was originally described as to the behavior of Group
Policies, I would hope that it's an obvious fact that there's no way a
machine would "know" it was suddenly "not subject to" a Group Policy, and
undo the change.

But it is aware. Try setting up a policy to disable the Run command for a user,
when the policy is deleted the run command comes back.

Exactly! This is a policy applied during Domain Account LOGON and lives for
the duration of the account. Take the policy away, and it's no longer
applied. But let's not be naive here... that setting can just as easily be
changed by that Domain User if they have local Admin access. All it takes is
firing up the Local Security Policy Editor and changing the policy. It'll
last as long as the time duration to the next user policy refresh.

These behaviors are no different than how we know WSUS to behave, the
primary example being "Remove access to all Windows update features". It's a
registry setting. It's permanent -- unless/until somebody 'edits' the
setting on the local machine. Poof! the policy is gone -- but only
temporarily -- the policy will reset at the next policy refresh event.

Post by DaveMills

Post by Lawrence Garvin (MVP)
(e.g. for WSUS/WUA, it would have to be known that only the "Specify
intranet Microsoft update services location" should be DISABLED, rather than
merely Not Configured.

Post by DaveMills
It must be a
specific design decision of the development team. One that may have been better
to have been "remove when the GPO falls out of scope" like most of the policy
settings.

As noted previously "remove when the GPO falls out of scope" requires an
*active* communications channel between the machine and the DC, and this
would be handled as a normal part of the policy refresh cycle (90 mins +/-
30 mins).

But it's all premised on the idea that the machine is powered on and
communicating with the Domain Controller. If that communication channel is
broken, then there's nothing that can be done to affect configuration
changes on that machine unless that machine is powered back up in that
domain and can successfully authenticate as a member of the domain.

Post by DaveMills

Post by Lawrence Garvin (MVP)
Remember, also, the WSUS/WUA GPO is a *machine* policy, not a user policy.
Now, yes, perhaps it would be useful if there were some automagic way for
AD/GP to 'undo' applied group policies when a machine is removed from the
[a] that the machine is being disjoined from the machine itself (not after
the fact, say when a machine is stolen, destroyed, or simply dies from old
age), and
[b] imposes some sort of 'decision-making' on the process to determine how
to reverse the policy application.

Yes the application has to be Group Policy aware.

And WSUS/WUA is not. :-)

Post by DaveMills

Post by Lawrence Garvin (MVP)
Since WSUS is not a domain-based service, but merely uses Group Policy as a
means to distribute configuration settings, is it necessarily a good thing
that a machine suddenly have it's update source reconfigured, merely because
it was disjoined from a domain.

If the setting was made by a GPO then why not unmake the setting when removing
the GPO. If the setting was not made by a GPO then there is no GPO setting to
undo.
The WSUS setting are at
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
The key point here is they are under the "Policies" sub key. It is normal for
settings here to not be applied when the GPO no longer applies. I do not know
the mechanism for this.

The mechanism for this is that *something* removes those keys/values from
the registry!

Post by DaveMills

Post by Lawrence Garvin (MVP)
So, in the end, while it *might* be useful... it might also be very
dangerous.

How?

By inadvertently disconnecting a machine from it's intended update source,
resulting in a machine not getting updates.

While some policies might be desirable to reverse themselves if they're
unlinked from an OU or SITE, or some client-side features might be desirable
to reverse if the machine falls out of the domain scope, I don't think that
a standalone application (WUA) designed to talk to an anonymous service
(WSUS) is such a scenario where configurations should automagically
disappear just because the machine has been removed from the domain.