[gptalk] Re: Long logon times when switching between metaframe servers.
- From: <bart.schillebeeks@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Mon, 30 Jul 2007 15:56:34 +0200
Hi darren ,
I've checked that already but i see no odd values in there. Maybe you can have
a quick look ?
these are the setting on the metaframe for the extension that gives the
problem.
???
Vriendelijke groeten,
Cordialement,
Kind Regards,
Schillebeeks Bart
Active Directory Security Consultant
Bart.schillebeeks@xxxxxxxxxx
AD 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 Darren Mar-Elia
Sent: Monday, July 30, 2007 3:21 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Long logon times when switching between metaframe servers.
Bart-
Have you checked to see if there is a policy set to tell registry processing to
always run even if the policy hasn't changed? The history information that GP
uses to determine if versions or group memberships have changed is stored
per-machine and does not roam with the user, so I can understand that policy
might apply at least once when a user logs into a new machine, but the repeated
refreshes don't make sense unless something external is forcing that.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of hans straat
Sent: Monday, July 30, 2007 4:27 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Long logon times when switching between metaframe servers.
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 +0200
From: bart.schillebeeks@xxxxxxxxxx
To: 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 Bart
Active Directory Security Consultant
Bart.schillebeeks@xxxxxxxxxx
AD 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 straat
Sent: Monday, July 30, 2007 1:01 PM
To: gptalk@xxxxxxxxxxxxx
Subject: [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 straat
www.datacrash.net <http://www.datacrash.net/>
________________________________
Subject: [gptalk] Long logon times when switching between metaframe servers.
Date: Mon, 30 Jul 2007 11:40:27 +0200
From: bart.schillebeeks@xxxxxxxxxx
To: gptalk@xxxxxxxxxxxxx
Hello,
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.937
USERENV 14:34:43:401 DeleteRegistryValue Deleted
Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\3\1004 4.937
USERENV 14:34:43:401 DeleteRegistryValue Deleted
Software\Policies\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\3\1C00 4.937
USERENV 14:34:43:401 DeleteRegistryValue Deleted
Software\Policies\Microsoft\Internet Explorer\Control Panel\Autoconfig 4.937
USERENV 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.422
USERENV 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.359
USERENV 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 Bart
Active Directory Security Consultant
Bart.schillebeeks@xxxxxxxxxx
AD 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 <mailto:Sales@xxxxxxxxxxxxxx>
= = = = = = = = = = = = = = = = = = = = = = = = =
Fortis disclaimer :
http://www.fortis.be/legal/disclaimer.htm
Privacy policy related to banking activities of Fortis:
http://www.fortis.be/legal/privacy_policy.htm
= = = = = = = = = = = = = = = = = = = = = = = = =
Other related posts:
