Re: local GPO question

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Darren Mar-Elia (dmanonymous_at_discussions.microsoft.com)
Date: 08/03/04 

Date: Mon, 2 Aug 2004 18:55:45 -0700

Thanks Mark. I had understood that turning off Fast logon optimization in XP
was equivalent to setting foreground synchronous processing, but it sounds
like what you're saying is that is not the case--but rather that it is just
waiting for the network stack to start up? Its a bit confusing because in KB
305293 it says at the end,
**********************************
"Note that Windows XP clients support Fast Logon Optimization in any domain
environment. To turn off Fast Logon Optimization, you can use the following
policy setting:
Computer Configuration\Administrative Templates\System\Logon\ Always wait
for the network at computer startup and logon

When this policy is enabled, a Windows XP client behaves in the same manner
as a Windows 2000 client at both system startup and at user logon"
*************************************

But is this saying that GP processing for both machine startup and user
logon are done synchronously when fast logon is disabled, or just that both
events wait for the network stack to start first? (actually I guess it's
machine startup that needs to wait for the stack, since once its started,
the user logon shouldn't care)

Thanks! 

-- 
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com
"Mark Renoden [MSFT]" <markreno@online.microsoft.com> wrote in message
news:eQe2jROeEHA.2544@TK2MSFTNGP10.phx.gbl...
> Hi
>
> My understanding was that this policy setting is specific to Windows XP
and
> Windows Server 2003.  By default, these operating systems don't wait for
the
> network stack to become active before presenting the user with the logon
> dialog.  This allows for a faster logon.  The thing here is that user (and
> computer) policy can't process until the network stack comes up and a DC
is
> contacted.  By enabling the setting we've been discussing, the OS waits
for
> the network stack before presenting the logon dialog.  This ensures that
> policy is processed at logon.
>
> This is slightly different to the Windows 2000 version that Darren is
> talking about.  In Windows 2000, the OS always waited for the network but
> the settings mentioned by Darren determined whether the policy was
processed
> before the logon dialog (for computer settings) and before the desktop
> appeared (for user settings) or if policy processing could occur
> simultaneously to these events.
>
> Kind regards
> -- 
> Mark Renoden [MSFT]
> Windows Platform Support Team
> Email: markreno@online.microsoft.com
>
> Please note you'll need to strip ".online" from my email address to email
> me; I'll post a response back to the group.
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>
>
>
>
> "Darren Mar-Elia" <dmanonymous@discussions.microsoft.com> wrote in message
> news:O%23gY5kLeEHA.1732@TK2MSFTNGP09.phx.gbl...
> > Mark's right that you can set the "Always wait for the network at
> > computer startup and logon" policy within any GPO--local or AD-based.
> > However, this policy does also exist in Win2K--its just called something
> > different. First off, note that all this policy in XP (and 2003) is
doing
> > is
> > telling group policy to run synchronously during foreground processing
> > (computer startup and logon). In XP (and maybe 2K3 as well--not sure),
the
> > default is to do foreground processing Asynchronously, which causes some
> > "unexpected behavior" for certain policy (e.g. folder redirection). In
> > Win2K, the default is to do foreground processing synchronously in the
> > first
> > place, but if you really want asynchronous processing, its available
> > within
> > two separate policies under Computer Configuration|Administrative
> > Templates|System|Group Policy. Specifically the Apply Group Policy
> > asynchronously for computers during startup (and for users during logon)
> > policy items.
> >
> > Now in terms of managing local GPOs remotely, there is no easy 'batch'
> > mechanism for doing this other than manually copying files around or
using
> > a
> > 3rd party product like Full Armor's GPAnywhere, but you can
interactively
> > manage a remote local GPO simply by opening a blank MMC snap-in, loading
> > the
> > GP editor snap-in and browsing to the remote machine as you load the
> > snap-in.
> >
> >
> > -- 
> > Darren Mar-Elia
> > MS-MVP-Windows Management
> > http://www.gpoguy.com
> >
> >
> >
> > "Mark Renoden [MSFT]" <markreno@online.microsoft.com> wrote in message
> > news:%23KjkcwBeEHA.1356@TK2MSFTNGP09.phx.gbl...
> >> Hi Jeff
> >>
> >> This information is inaccurate.  This policy setting is available at
the
> >> domain level or at the level of any OU.  The confusion may have come
> >> about
> >> because it's not a Windows 2000 setting.  If you were creating the
policy
> >> from a Windows 2000 DC, you wouldn't see this setting by default.
> >> Windows
> >> XP and Windows Server 2003 have this setting in their appropriate .adm
> >> files.  If you create and manage the policy from one of these operating
> >> systems, you won't have an issue.
> >>
> >> You can't manage local GPO's remoted (afaik).
> >>
> >> Kind regards
> >> -- 
> >> Mark Renoden [MSFT]
> >> Windows Platform Support Team
> >> Email: markreno@online.microsoft.com
> >>
> >> Please note you'll need to strip ".online" from my email address to
email
> >> me; I'll post a response back to the group.
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> >>
> >> "Jeff" <anonymous@discussions.microsoft.com> wrote in message
> >> news:83b801c47803$9d979ad0$a401280a@phx.gbl...
> >> > Ok, I'm going to sound like the GPO newbie that I am...
> >> >
> >> > I'm reading this month's windows & .net mag, and the
> >> > article is talking about deploying XPSP2 using GPO.  The
> >> > author suggests enabling "Always wait for the network at
> >> > computer startup and logon policy under the GPO's
> >> > Computer Configuration\Administrative
> >> > Templates\System\Logon object" to ensure the policy is
> >> > enforced.  This policy is only available in the local
> >> > GPO.  So here is my question:
> >> >
> >> > Can local GPO's be remotely configured?  If not, how does
> >> > an organization implement local GPO changes system wide?
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Relevant Pages

  • Re: Server 2K3 Remote Desktop Access - is this right place?
    ... All roads for that particular error of 'You do not have access to logon to ... On Windows Server 2003, launch GPEDIT.MSC from Start -> Run. ... Drill down and expand the following for Local Computer Policy: ... > Strange - when I activate the Remote Desktop Terminal from the server, ...
    (microsoft.public.win2000.advanced_server)
  • Re: GPO problems when logon to kerberos-realm
    ... when I put the same policy on an OU with e.g. a Windows ... problem when logon to a Terminal Server. ...
    (microsoft.public.windows.group_policy)
  • Re: local GPO question
    ... You just had the option of> synchronous or asynchronous policy processing. ... Windows XP lets you wait for the network or not. ... I had understood that turning off Fast logon optimization in>> XP ...
    (microsoft.public.win2000.group_policy)
  • Re: local GPO question
    ... synchronous or asynchronous policy processing. ... Windows XP lets you wait for the network or not. ... > "Note that Windows XP clients support Fast Logon Optimization in any ...
    (microsoft.public.win2000.group_policy)
  • Re: Can run Scheduled Task once only
    ... Also make sure the account isn't listed as 'Deny logon as batch job' ... Windows 2000 but the steps should be the same. ... | In Local Policy I can't add users directly to Logon as Batch right ...
    (microsoft.public.windows.server.general)