local GPO question

[Jeff]

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?

 

[Mark Renoden [MSFT]]

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: (e-mail address removed)

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]

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

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: (e-mail address removed)

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.

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?

 

[Mark Renoden [MSFT]]

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: (e-mail address removed)

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.

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

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: (e-mail address removed)

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.

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?

 

[Darren Mar-Elia]

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

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: (e-mail address removed)

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.

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

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: (e-mail address removed)

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.

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?

 

[Mark Renoden [MSFT]]

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: (e-mail address removed)

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.

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

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: (e-mail address removed)

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.





message

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



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: (e-mail address removed)

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.

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?

 

[Darren Mar-Elia]

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


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

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: (e-mail address removed)

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.

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

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: (e-mail address removed)

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.





message
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



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: (e-mail address removed)

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.

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?