Results 1 to 7 of 7

Thread: WSUS group policy won't go away

  1. #1
    BTTNext Guest

    WSUS group policy won't go away

    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!

  2. #2
    PA Bear [MS MVP] Guest

    Re: WSUS group policy won't go away

    [[ 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!



  3. #3
    Lawrence Garvin \(MVP\) Guest

    Re: WSUS group policy won't go away

    > 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


  4. #4
    DaveMills Guest

    Re: WSUS group policy won't go away

    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.

  5. #5
    Lawrence Garvin \(MVP\) Guest

    Re: WSUS group policy won't go away

    "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


  6. #6
    DaveMills Guest

    Re: WSUS group policy won't go away

    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.

  7. #7
    Lawrence Garvin \(MVP\) Guest

    Re: WSUS group policy won't go away

    "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


Similar Threads

  1. Replies: 2
    Last Post: 17-12-2013, 09:10 PM
  2. Using local group policy to override domain group policy
    By Nickason in forum Active Directory
    Replies: 3
    Last Post: 28-09-2011, 04:20 AM
  3. Replies: 3
    Last Post: 07-10-2009, 02:12 PM
  4. Group policy for WSUS
    By troy in forum Active Directory
    Replies: 2
    Last Post: 25-08-2009, 09:39 PM
  5. Group Policy -> Missing Group Policy settings
    By Jeroen in forum Active Directory
    Replies: 3
    Last Post: 24-07-2007, 11:00 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Page generated in 1,711,665,956.05073 seconds with 17 queries