[gptalk] Re: Long logon times when switching between metaframe servers.
- From: hans straat <hstraat@xxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Mon, 30 Jul 2007 11:26:55 +0000
Hey Bart yeah a :-) is on it's place been a while since we last talked.
As you describe it , it won't be on the server(s) as you said they are all in
the same OU. Policies shouldn't be loaded again then.
I hope Darren can figure it out or hint you in the right direction. Are there
any strange event's in the servers or is it simply user logged on etc blabla.
Subject: [gptalk] Re: Long logon times when switching between metaframe
servers.Date: Mon, 30 Jul 2007 13:20:07 +0200From:
bart.schillebeeks@xxxxxxxxxxxx: gptalk@xxxxxxxxxxxxx
Hello Hans :-)
All the servers are in the same OU receiving the same gpo's.
they logon to the first and recieve all settings
they logon to the second and recieve all settings
they logon to the first again and again recieve all settings!!
if they
they logon to the first recieve all settings
they logon to the first again it skippes the settings
So it happens when switching servers in the same silo and metaframe farm, as we
have silo's with for example 60 servers in them, this practically means the
settings are applied all the time.
it probably has something to do with the GPO history contained in the
NTuser.pol file from the roaming profile, but can't figure out how this could
be fixed.
Vriendelijke groeten,Cordialement,Kind Regards, Schillebeeks BartActive
Directory Security ConsultantBart.schillebeeks@xxxxxxxxxxxx Internet Consulting
BVBA "When once you have tasted flight, you will always walk with your eyes
turned skyward, for there you have been and there you always will be."Leonardo
da Vinci, 1452-1519 Disclaimer:Any views expressed in this message are those of
the individual sender, except where the message states otherwise and the sender
is authorised to state them to be the views of any such entity.This Message is
in no way legally binding and has to be viewed as a personal opinion of the
sender. This message reflects in no way the views of FORTIS BANK and its
associates and AD internet Consulting BVBA and its associates. Unless otherwise
stated, any pricing information given in this message is indicative only, is
subject to change and does not constitute an offer to deal at any price quoted.
Any reference to the terms of executed transactions should be treated as
preliminary only and subject to our formal written confirmation.
AD Internet Consulting BVBA, Hezemeer 7, 2430 Eindhout-Laakdal ON:0470419019
www.adinternet.com mailto:Sales@xxxxxxxxxxxxxx
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of hans straatSent: Monday, July 30, 2007 1:01 PMTo:
gptalk@xxxxxxxxxxxxxxxxxxxx: [gptalk] Re: Long logon times when switching
between metaframe servers.
As you state they logon to two different servers, does it also happen if they
logon to two servers in the same OU? Or only if they logon to another farm or
silo server(s). regards,hans straatwww.datacrash.net
Subject: [gptalk] Long logon times when switching between metaframe servers.
Date: Mon, 30 Jul 2007 11:40:27 +0200From: bart.schillebeeks@xxxxxxxxxxxx:
gptalk@xxxxxxxxxxxxxxxxxx, I'm a litlle plagued by this annoying problem. Our
metaframe people are complaining about long logon times for GPO's for certain
servers. I've studied their userenv logs and found it relates to following
behaviour. I've got loopback processing enabled with merge, and it merges
several more restrictive settings when logging on to a metaframe server. When a
user logs on the first time al his gpo settings are applied which takes about
30 seconds, when they logon a second time to the same server their settings are
marked "same" and the application is skipped. This is how it should work
obviously. Now when they logon to another server in the metaframe farm i see
NTuser.pol from their profile first erasing all settings in the registry
extension part, and then reapplying them again from the GPO on the domain. Only
the registry extension has this behaviour , all the other ones don't do this.
Why does this happen? and why is the gpo history not transferred via the
roaming profile to another server ? Can this be reversed somehow ? Even if in
userenv it says: "the lists are the same" it still deletes and reapplies. see
example USERENV 14:34:43:370 ProcessGPOs Processing extension Registry
4.906 USERENV 14:34:43:370 ReadStatus Read Extension's Previous status
successfully. 4.906 USERENV 14:34:43:370 CompareGPOLists The lists are the
same. 4.906 USERENV 14:34:43:370 ProcessGPOList Entering for extension
Registry 4.906 USERENV 14:34:43:370 UserPolicyCallback Setting status
UI to Applying Registry policy... 4.906 USERENV 14:34:43:401
LogExtSessionStatus Successfully logged Extension Session data 4.937
USERENV 14:34:43:401 EnterCriticalPolicySectionEx Entering with timeout
60000 and flags 0x2 4.937 USERENV 14:34:43:401
EnterCriticalPolicySectionEx User critical section has been claimed. Handle
= 0x464 4.937 USERENV 14:34:43:401 EnterCriticalPolicySectionEx Leaving
successfully. 4.937 USERENV 14:34:43:401 ResetPolicies Entering.
4.937 USERENV 14:34:43:401 SetRegPermissionsOnPoliciesKey Resetting
permission on the policy key 4.937 USERENV 14:34:43:401
SetRegPermissionsOnPoliciesKey Resetting permission on the policy key 4.937
USERENV 14:34:43:401 ParseRegistryFile Entering with
<C:\Profiles\g60057\ntuser.pol>. 4.937 USERENV 14:34:43:401
DeleteRegistryValue Deleted
Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\3\1001 4.937USERENV 14:34:43:401 DeleteRegistryValue
Deleted Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\3\1004 4.937USERENV 14:34:43:401 DeleteRegistryValue
Deleted Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\3\1C00 4.937USERENV 14:34:43:401 DeleteRegistryValue
Deleted Software\Policies\Microsoft\Internet Explorer\Control Panel\Autoconfig
4.937USERENV 14:34:43:401 DeleteRegistryValue Deleted
Software\Policies\Microsoft\Internet Explorer\Control Panel\Connection Settings
4.937 and then the reapplication SERENV 14:34:45:886 ParseRegistryFile
Entering with
<\\int.sys.shared.fortis\sysvol\int.sys.shared.fortis\Policies\{4120ED14-6346-4964-ABCD-F578457BC151}\User\registry.pol>.
7.422USERENV 14:34:45:932 SetRegistryValue NoComponents => 1 [OK]
7.468 USERENV 14:34:45:995 SetRegistryValue DisablePersonalDirChange
=> 1 [OK] 7.531 USERENV 14:34:46:057 SetRegistryValue
ForceClassicControlPanel => 1 [OK] 7.593 USERENV 14:34:46:104
SetRegistryValue NoDesktopCleanupWizard => 1 [OK] 7.640 USERENV
14:34:46:167 SetRegistryValue NoHardwareTab => 1 [OK] 7.703
USERENV 14:34:46:214 SetRegistryValue NoManageMyComputerVerb => 1
[OK] 7.750 USERENV 14:34:46:276 SetRegistryValue
NoSMConfigurePrograms => 1 [OK] 7.812 USERENV 14:34:46:323
SetRegistryValue NoSMMyPictures => 1 [OK] 7.859 normally it
should be like this (same user again on same server) USERENV 14:12:54:275
ProcessGPOs Processing extension Registry 1.359 USERENV 14:12:54:275
ReadStatus Read Extension's Previous status successfully. 1.359 USERENV
14:12:54:275 CompareGPOLists The lists are the same. 1.359 USERENV
14:12:54:275 CheckGPOs No GPO changes and no security group membership
change and extension Registry has NoGPOChanges set. 1.359USERENV
14:12:54:275 ProcessGPOs ----------------------- 1.359 As we have
multiple metaframe's in multiple farms and silo's this actually mean that
mostly all of these settings are constantly being reapplied costing the user 30
seconds every time.If anyone can shed some light on this it would be greatly
appreciated. Thanks Vriendelijke groeten,Cordialement,Kind Regards,
Schillebeeks BartActive Directory Security
ConsultantBart.schillebeeks@xxxxxxxxxxxx Internet Consulting BVBA "When once
you have tasted flight, you will always walk with your eyes turned skyward, for
there you have been and there you always will be."Leonardo da Vinci, 1452-1519
Disclaimer:Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is authorised
to state them to be the views of any such entity.This Message is in no way
legally binding and has to be viewed as a personal opinion of the sender. This
message reflects in no way the views of FORTIS BANK and its associates and AD
internet Consulting BVBA and its associates. Unless otherwise stated, any
pricing information given in this message is indicative only, is subject to
change and does not constitute an offer to deal at any price quoted. Any
reference to the terms of executed transactions should be treated as
preliminary only and subject to our formal written confirmation.AD Internet
Consulting BVBA, Hezemeer 7, 2430 Eindhout-Laakdal ON:0470419019
www.adinternet.com mailto:Sales@xxxxxxxxxxxxxx
- Follow-Ups:
- [gptalk] Re: Long logon times when switching between metaframe servers.
- From: Darren Mar-Elia
Other related posts:
- » [gptalk] Long logon times when switching between metaframe servers.
- » [gptalk] Re: Long logon times when switching between metaframe servers.
- » [gptalk] Re: Long logon times when switching between metaframe servers.
- » [gptalk] Re: Long logon times when switching between metaframe servers.
- » [gptalk] Re: Long logon times when switching between metaframe servers.
- » [gptalk] Re: Long logon times when switching between metaframe servers.
- » [gptalk] Re: Long logon times when switching between metaframe servers.
- [gptalk] Re: Long logon times when switching between metaframe servers.
- From: Darren Mar-Elia