[gptalk] Re: Long logon times when switching between metaframe servers.

  • From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Mon, 30 Jul 2007 07:03:49 -0700

Bart-

This is not the Admin Templates extension that is shown in the userenv log
below. This is the PolicyMaker Registry CSE. Check RSOP on one of those
machines for the setting at:

 

Computer Configuration\Admin. Templates\System\Group Policy\Registry Policy
Processing

 

Darren

 

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of bart.schillebeeks@xxxxxxxxxx
Sent: Monday, July 30, 2007 6:57 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Long logon times when switching between metaframe
servers.

 

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-634
6-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

JPEG image

Other related posts: