local GPO question

jeff

Distinguished
Apr 5, 2004
1,172
0
19,280
Archived from groups: microsoft.public.win2000.group_policy (More info?)

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?
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

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?
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

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?
> >
> >
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

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?
>> >
>> >
>>
>>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

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?
> >> >
> >> >
> >>
> >>
> >
> >
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

Hi Darren

I think it's slightly more subtle:

1. Windows 2000 always waited for the network. You just had the option of
synchronous or asynchronous policy processing.

2. Windows XP lets you wait for the network or not. If you don't wait,
you're using asynchronous processing. If you do wait, you're using
synchronous processing.

I guess the policy processing aspect result is the same but there is a
subtle difference here that may make some difference some of the time.

Cheers
--
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:erIWyzPeEHA.3732@TK2MSFTNGP11.phx.gbl...
> 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?
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.group_policy (More info?)

Thanks Mark. Strange, but I think it makes sense.


--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com



"Mark Renoden [MSFT]" <markreno@online.microsoft.com> wrote in message
news:%23tTXJpQeEHA.596@TK2MSFTNGP11.phx.gbl...
> Hi Darren
>
> I think it's slightly more subtle:
>
> 1. Windows 2000 always waited for the network. You just had the option of
> synchronous or asynchronous policy processing.
>
> 2. Windows XP lets you wait for the network or not. If you don't wait,
> you're using asynchronous processing. If you do wait, you're using
> synchronous processing.
>
> I guess the policy processing aspect result is the same but there is a
> subtle difference here that may make some difference some of the time.
>
> Cheers
> --
> 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:erIWyzPeEHA.3732@TK2MSFTNGP11.phx.gbl...
> > 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?
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>