Printable View
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!
[[ 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...pdate_services
In your newsreader:
news://msnews.microsoft.com/microsof...pdate_services
]]
BTTNext wrote:
> 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!
> BTTNext wrote:
>> 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! :)
--
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/pro...awrence.Garvin
On Thu, 4 Dec 2008 22:13:52 -0600, "Lawrence Garvin \(MVP\)"
<lawrence@news.postalias> wrote:
>> BTTNext wrote:
>>> 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...eferences.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.
>
>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! :)
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
"DaveMills" <DaveMills@newsgroup.nospam> wrote in message
news:n2fhj45iutj6if01lk15m0l855131v9fvl@4ax.com...
>>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.
> 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.
> 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.
> 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.
--
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/pro...awrence.Garvin
On Fri, 5 Dec 2008 09:43:43 -0600, "Lawrence Garvin \(MVP\)"
<lawrence@news.postalias> wrote:
>"DaveMills" <DaveMills@newsgroup.nospam> wrote in message
>news:n2fhj45iutj6if01lk15m0l855131v9fvl@4ax.com...
>
>>>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"
>
>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.
>
>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.
>
>> 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.
>
>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.......
>(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.
>
>> 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.
>
>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.
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.
>
>> 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.
>
>So, in the end, while it *might* be useful... it might also be very
>dangerous.
How?
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
"DaveMills" <DaveMills@newsgroup.nospam> wrote in message
news:qe8kj4tvivd021ko39ece4b1er956fp7sv@4ax.com...
>>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.
>>
>>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.
>>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.
>>(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.
>>
>>> 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.
>>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.
> Yes the application has to be Group Policy aware.
And WSUS/WUA is not. :-)
>>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!
>>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.
--
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/pro...awrence.Garvin