none
Windows 7 slow to logon screen, slow to desktop ... GPClient 6005/6006 (Oh no, not again!) RRS feed

  • Question

  • I'm banging my head into an annoying wall here.  I thought it was licked a few months ago ...

    - 2008 AD
    - Windows XP Pro.sp3 and Windows 7.sp1 clients

    GPOs as configured work beautifully with Windows XP.  Windows 7 clients systems are bogging down in 3-5minute delays before reaching the logon box, then another 3-5 minute delay for domain users to reach the desktop.

    On the Windows 7 clients, I've tried:
    - disabled IPv6
    - disabled autotuning
    - disabled card reader device
    - drivers are ALL latest
    - problem is occuring with All Windows 7 clients, regardless of hardware.
    - there are three different Windows 7 images live, built from different sources, including an OEM oobe image.
    - several other registry hacks amongst the bajillion pages of folks having similar issues.

    Let me reiterate, the GPOs work flawlessly on WXP.  The Windows 7 client Desktop is not a solid colour, is a wallpaper, and there aren't any printer mapping being applied; besides... they have SP1 installed which is supposed to take care of that particular nonsense.

    Whether the domain user is limited/mandatory/roaming profile or normally generated from the local\Default profile doesn't matter... it especially wouldn't matter the slightest in explaining the delay to reach the logon box to begin with.

    DCs (4... one is radius) are 2008.sp2  Enterprise  native mode (though gpresult from connected clients shows Domain Type as Windows 2000)

    If all GPOs are filtered to not be applied to Windows 7 clients, the problems go away.

    Clients were built up in Audit mode, syspreped, and activated by KMS.

    After all the hours I've spent digging into Windows 7, I'm convinced the issue is server side; DNS I'm looking at you!

    But... while I'm filtering GPOs away from Windows 7 clients again, I'm hoping some sage advice might appear here.

    GPClient timeout errors are killing me.

    Wednesday, June 29, 2011 4:35 PM

Answers

  • Okay, so KB2460922 wasn't it.

    Further searching has led me to this page:  http://support.microsoft.com/kb/2590914/ and this:

    2561285 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;2561285) You experience a long domain logon time in Windows 7 or in Windows Server 2008 R2 after you deploy Group Policy preferences to the computer

    Looks promising ...

    My first test using just the two known good items ... works.  But I've been here before.

    I'm now restarting again with the heavy 36/36.

    W00t!  Three restarts with the heavy 36/36 in place and things are working fine!  I must retest on a couple of other Win7 boxes and incorporate several larger 162 item GPP but I'm cautiously optimistic that this is the winner.


    Monday, September 26, 2011 1:41 PM

All replies

  • Hi Robert

    Try the following link: http://support.microsoft.com/kb/977346

    Also try to remove the wallpaper on the windows 7 machines and see if this makes a difference.

    Hope it helps

    Karl

    Thursday, June 30, 2011 2:18 PM
  • Already tried with the default Aero image, no changes to colours, wallpaper, sounds or screensaver alteration... Stock default Aero.  And this KB is included with SP1.
    Thursday, June 30, 2011 3:13 PM
  • You mentioned ) If all GPOs are filtered to not be applied to Windows
    7 clients, the problems go away.
     
    Can you try applying the filter so it applied to Win7 to one GPO at a
    time to see if it narrows things down?
     
     
    Robert Sudbury wrote:
     
    >
    >
    >I'm banging my head into an annoying wall here. I thought it was licked a few months ago ...
    >
    >- 2008 AD - Windows XP Pro.sp3 and Windows 7.sp1 clients GPOs as configured work beautifully with Windows XP. Windows 7 clients systems are bogging down in 3-5minute delays before reaching the logon box, then another 3-5 minute delay for domain users to reach the desktop. On the Windows 7 clients, I've tried: - disabled IPv6 - disabled autotuning - disabled card reader device - drivers are ALL latest - problem is occuring with All Windows 7 clients, regardless of hardware. - there are three different Windows 7 images live, built from different sources, including an OEM oobe image. - several other registry hacks amongst the bajillion pages of folks having similar issues. Let me reiterate, the GPOs work flawlessly on WXP. The Windows 7 client Desktop is not a solid colour, is a wallpaper, and there aren't any printer mapping being applied; besides... they have SP1 installed which is supposed to take care of that particular nonsense. Whether the domain user is
    >limited/mandatory/roaming profile or normally generated from the local\Default profile doesn't matter... it especially wouldn't matter the slightest in explaining the delay to reach the logon box to begin with. DCs (4... one is radius) are 2008.sp2 Enterprise native mode (though gpresult from connected clients shows Domain Type as Windows 2000) If all GPOs are filtered to not be applied to Windows 7 clients, the problems go away. Clients were built up in Audit mode, syspreped, and activated by KMS. After all the hours I've spent digging into Windows 7, I'm convinced the issue is server side; DNS I'm looking at you! But... while I'm filtering GPOs away from Windows 7 clients again, I'm hoping some sage advice might appear here. GPClient timeout errors are killing me.
     

    Ha®®y
    Thursday, June 30, 2011 6:58 PM
  • Hi,

     

    Since you are convinced the issue is server side, it is recommended contacting Windows Server Group Policy Forum to check the issue from server side.

     

    http://social.technet.microsoft.com/Forums/en-US/winserverGP/threads

     

    From Windows 7 client side, please try the following methods to check the result.

     

    1. Open an elevated command window and type the following commands.

     

    netsh interface tcp set global rss=disabled

    netsh interface tcp set global autotuninglevel=disabled

    netsh int ip set global taskoffload=disabled

     

    2. Enable NetBIOS over TCP/IP

     

    a) Go to "Control Panel -> Network and Internet ->Network Connections".

    b) Right-Click on the connection and choose Properties.

    c) Click "Internet Protocol (TCP/IP) Version 4" in the list.

    d) Click Properties, and then click Advanced.

    e) On the Advanced TCP/IP settings windows, go to "WINS" tab.

    f) Under NetBIOS setting, click "Enable NetBIOS over TCP/IP", and then click OK.

     

    Best Regards,

    Niki

     


    Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, July 1, 2011 8:17 AM
    Moderator
  • I am still working on this.  I'm giving the GPOs another once over, by recreating each GPO (thirteen of them), one setting at a time, to apply only to Windows 7 boxes.  This will take some time, while working on the usual fires that tend to pop up this time of year.  Please be patient. 

    I will update as I have more information.

    Monday, July 4, 2011 4:33 PM
  • rem this is what I'm testing:

     

    rem turn on verbose status while booting
    reg add hklm\software\microsoft\windows\currentversion\policies\system /f /v VerboseStatus /d 1 /t reg_dword

    rem disable multimedia class scheduler
    sc config AudioSrv depend= AudioEndpointBuilder/RpcSs
    sc config MMCSS start= disabled

    rem applying user settings... lag fix from http://support.microsoft.com/kb/2379016
    sc config http depend= cryptsvc

    rem delay Cryptographic Service (I guess the http service has to depend on it?)
    sc config CryptSvc start= delayed-auto

    rem generate layout.ini for readyboot and do boot defrag (could take 20 min to defrag)
    start /wait rundll32.exe advapi32.dll,ProcessIdleTasks

    rem try to rate your computer remotely, fails, but maybe it's faster after?
    winsat cpu

     



    Friday, July 15, 2011 6:58 PM
  • I was unable to generate any movement on this issue before starting vacation, so this is on hold for another week.

    Thank you for your replies, I will take them into consideration when I return.  I will update this thread as soon as possible.

    Moderators, please do not arbitrarily mark any replies as the answer until I have had time to investigate them; and I repeat, I'm on vacation right now and unable to update research results.

    As of 2011/07/20 this thread is neither abandoned nor closed, merely on hold while I'm out of the office, and then while further research can be completed.



    Wednesday, July 20, 2011 5:50 PM
  • This is something I will be filtering, _again_.  It's quite annoying really.

    Most of the GPOs were recreated from scratch.

    Two particularly large and complex GPOs using legacy components (not the yummy new  .xml) for folder redirections were not recreated, though they were merged into a single computer/user GPO.

    The last task I performed before disappearing on vacation was to re-enable the Windows 7 filtering (WMI) of the GPOs so Windows7 clients would not receive them.  I can't say with 100% certainty, due to time-lags in replication between the DCs, but the GPclient timeout issued on clients remained an issue until the very last (the largest and most complex) GPO was filtered out.  The trick when I return will be to remove the Windows 7 filters from the GPOs from smallest to largest at my very next test.

    ... and I reiterate, the timeout occurs before the logon box, during COMPUTER policy parsing and then again after logging on, during the USER policy parsing.

    Wednesday, July 20, 2011 5:58 PM
  • Bumped to keep alive, while I await the opportunity to revisit the GPO creation and any possible corruption.

    We're brainstorming other ideas as well as investigating if it is indeed a DC/DNS issue via cloned and siloed DCs.

    I will update this thread when I have something concrete to report.

     

    Thursday, August 4, 2011 12:29 PM
  • Robert,

    I've been following your thread since I have also been banging my head for weeks on this issue.  Your issue is exactly the same as ours and I tried everything you did.  My test environment was a lab of 24 Win 7 computers.  Within three times around logging into them all, I was always able to reproduce the problem on at least 2 or 3 clients.

    I noticed you mentioned that you disabled IPv6 on the Windows 7 clients which we did as well without resolution.  However, today I checked all our domain controllers and noticed two had IPv6 enabled.  I disabled this on the DC's and then tested in the lab environment.  Not only is the problem resolved for us, but startup and login is much more consistent and faster.  I hope this helps.

    Friday, August 5, 2011 9:12 PM
  • Vacation time is over . 8(

    We just completed upgrades of our DC's to R2 SP1 and the radius server was removed.  According to the tech testing while I was away, the GPclient timeout problem remains.

    IPv6 is installed on the DHCP but is at default status, with no scopes created.

    I'm blocking out a week in the very near future to rebuild the GPOs from the ground up (oh joy), to address the possibility of corrupt GPOs.

     

    Monday, August 22, 2011 1:38 PM
  • Nothing new to report.

    I plan to begin GPO recreation later this week.

     

    Tuesday, August 30, 2011 12:58 PM
  • Nothing new to report still.  GPO recreation has begun.
    Thursday, September 8, 2011 3:34 PM
  • I have another technician working on another project in parallel and he has just reported that by disabling one specific GPO he has eliminated the problem.

    Unfortunately, this particular GPO is rather large and chock full of settings that apply to ALL workstations and ALL users.  oy vey

    Tuesday, September 13, 2011 6:43 PM
  • Just curious:

    Are there any Security settings being applied in that GPO?

    If so, you might want to create a new GPO with all the same settings except security settings, then use that in a test to see if it no longer has the problem...


    Ha®®y
    Tuesday, September 13, 2011 7:16 PM
  • As I've mentioned, this is a particularly complex GPO with several hundred settings including drive maps, accounts management, shut down scripts... everything that everything and everyone must have applied or be filtered through.  The GPO itself has no Filtering or WMI Filtering, all filtering is internal either through direct security group application in the case of legacy GPO settings or ILT references to security groups of user and computers in the GPP settings.

    Recreating this GPO from scratch and testing at each setting change is already lined up for duty, but as it is a particularly large and complex GPO, testing of each step will take significant time; at least 3-5 days uninterrupted once started.  That we've narrowed it down to just one GPO is good news; instead of still being saddled with 15 GPOs to test.

    Tuesday, September 13, 2011 7:49 PM
  • Sorry, when I was asking about security I was actually wondering if the problematic GPO had any significant security settings configured under Computer Configuration/Windows Settings/Security Settings, especially registry or file system settings. Sometimes these can cause a huge hit.
    Ha®®y
    Thursday, September 15, 2011 4:56 PM
  • There are significant changes with ILT to Local Users and Groups targeted in:

    > Preferences

                 > Control Panel Settings

                  > Local Users and Groups

     

    Windows Firewall inbound port and program exceptions

     

    A couple of hundred drive mappings with intricate security ILT filtering (works perfectly btw and is not the source; copied the xml out to a separate GPO just for Win7 and it works).

     

    Very detailed My Documents folder redirection regarding user membership off to different servers, paths etc.

     

    Long list of software restrictions.

     

    Hitting the registry to change the IE home page depending on 80+ different security groups.  As soon as I get IE9 integrated into the DCs I expect to begin testing use of the GPP for the same for the many different IE versions supported in GPP, but using this one registry item that works for all versions of IE is so simple by comparison.

     

    That's an overview of the task ahead of me, which doesn't include about another 50 or 60 other options with their own granular details to test.

     

    BTW, in our focus towards the DNS we came across another issue involving using Ghost Console (Symantec Solution Suite 2.5.1) that could create computer accounts but not finish the job of joining computers to the domain.  We had to incorporate the "Microsoft Windows Server 2008 Domain Controller Compatibility Pack for Clients (KB944043)" into the client recipe.

     

    ... and more fires have cropped up, so the GPO rebuild/test is post-poned to next week at the earliest now. 8))]

     

     

    Thursday, September 15, 2011 5:39 PM
  • Working on the GPOs again.

    First I implemented all legacy options that do not involve any Group Policy Preference setting with Item Level Targeting.  WORKS!

    Then I added a big Local Users and Groups GPP.  There are 36 entries for configuring local accounts (administrator and 2 other accounts).  Each entry can have as many as 85 Computer Security Group membership conditions to be met in order to be applied.

    Why so many ILT conditions?  When this particular cluster of GPP was deployed it was on 2008 DCs.  2008 has a bug that ignores a computer's membership in a security group if the computer exists in a group nested inside another group that you target.

    eg:  Workstations (everything) > Workstations (site1) > Workstations (room) = Workstations

    For W2K8, if the computer is a member of Workstations (room), but the ILT is for Workstations (everything), the GPP is ignored... it will not drill down.  This means that in order for these particular GPP items to work, they must be targeted to each individual nested security group, instead of the top level.

    I remind you, this 85 condition (buried in 2 collections) for some of these GPP works perfectly with Windows XP.  Sure it was tedious creating all of those conditions, but it works and is necessary.

    ===> W2K8r2.sp1 fixes that and will indeed apply GPP to ILT'ing of a computer within a nested security group. yay.

    However... even with using just the high level security group, nested within which is the security group that ultimately contains the computer object, Windows 7 still exhibits the same behaviour. 6005/6006 events, GPClient timeouts.

    Reducing the GPP items in the Local Users and Groups to just two of the simplest (2 conditions using top level security groups) (the GPP item itself alters a local limited user account's password and either enables or disables it) and I'm still hitting 110 seconds of timeout.

    Remove those two GPP items and the timeouts go away.

    I then created a single GPP that won't even apply to this computer because of the ILT but it must still be parsed.  It still causes a ~60 second 6005/6006 GPClient timeout.

    The steps I used to create the GPP:

    >>> Computer Configuration
     > Preferences
       > Control Panel Settings
         > Local Users and Groups

         = New > Local User

      + Action:  [UPDATE]
      + User name:  “user”
      + Full name:  “user”
      + Description:  “It's a user account eh?”
      + Password:  “… the pw …”
           + [User cannot change password]
           + [Password never expires]
           - [Account is disabled] ... aka enabled
           + [Account never expires]
       Common(TAB)
            + Description:  “Here be dragons..."
            + Item-level targeting > Targeting
                 + This collection is true:
                      + “the computer is a member of security group domain\secgroup1
                 + OR this collection is true
                      + “the computer is a member of security group domain\secgroup2
      Name the item:  “user test”

    =-=-=-=-=-

    So then I tried something deeper.  What if it's the logic of the ILT?

    Variant #1:  WORKS!

    + “the computer is a member of security group domain\secgroup1
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup2


    Variant #2:  Timeouts persist

    + This collection is true:
         + “the computer is a member of security group domain\secgroup1
         + “OR the computer is a member of security group domain\secgroup2


    Variant #3:  WORKS!

    + “the computer is a member of security group domain\secgroup1
    + “OR the computer is a member of security group domain\secgroup2


    Variant #4:  Timeouts persist

    + “the computer is a member of security group domain\secgroup1
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup2
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup3


    Variant #5:  Timeouts persist

    + “the computer is a member of security group domain\secgroup1
    + “OR the computer is a member of security group domain\secgroup2
    + “OR the computer is a member of security group domain\secgroup3


    Variant #6:  WORKS!

    + “the computer is a member of security group domain\secgroup1
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup2
         + “OR the computer is a member of security group domain\secgroup3


    Variant #7:  Timeouts persist

    + “the computer is a member of security group domain\secgroup1
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup2
         + “OR the computer is a member of security group domain\secgroup3
         + “OR the computer is a member of security group domain\secgroup4


    Variant #8:  Timeouts persist

    + “the computer is a member of security group domain\secgroup1
    + “OR the computer is a member of security group domain\secgroup2
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup3


    ... and finally Variant #9:  Timeouts persist

    + “the computer is a member of security group domain\secgroup1
    + OR this collection is true
         + “the computer is a member of security group domain\secgroup3
         + OR this collection is true
              + “the computer is a member of security group domain\secgroup3


    =-=-=-=-=-

    Interesting.

    It appears that if you use ILT in a Computer GPO for Local Users and Groups:

    1. You must have an external condition (item)

    2. You cannot use more than one collection

    3. You cannot use more than 2 internal or external conditions (items)

    4. You cannot use a collection as the second internal condition.

    Looking at it as math:

    Works:

    X
    X +/or X
    X +/or ( X )
    X +/or ( X +/or X )

    GPClient Timeouts exist for:

    X +/or X +/or X
    X +/or ( X ) +/or ( X )
    ( X +/or X )
    ( X ) +/or ( X )
    X +/or ( X +/or X +/or X )
    X +/or X +/or ( X )
    X +/or ( X +/or ( X ))

     

    Friday, September 23, 2011 5:46 PM
  • Knowing the source of the problem I did some Googling to come up with:

    Microsoft Windows 7 Hotfix KB976398
    - LDAP filters in the Group Policy preference settings do not take effect on a computer that is running Windows Server 2008 R2 or Windows 7 (would not install)

    Microsoft Windows 7 Hotfix KB2460922
    - Group Policy preference item-level targeting does not work for 64-bit versions of Windows 7 (the x86 version downloaded and it installed)

    Neither solved the problem... or didn't they?... interesting logged events.  First reboot, had some new CAPI errors involving the application of the hotfix.  Second reboot, the timeouts are gone? hmmm ... checking again.

    The GPO I had left on for testing, Variant #9, no longer caused the time outs.

    Dropping the whole enchilada of the original 36 Local Users and Groups items back in caused the timeouts to return.

    Friday, September 23, 2011 7:29 PM
  • ... and now, to twist my noodle.

     

    I removed 34/36; timeout (120sec) persists.

     

    I altered the two remaining to what I've established to be good; timeout persists.

     

    I then removed all GPP items in Local User and Groups and the timeout remains.  Did I just poison the GPO? The computer? 

     

    My tests have fairly well established what is probably one part of the smoking gun; but ...

     

     

    Friday, September 23, 2011 9:08 PM
  • Okay, so KB2460922 wasn't it.

    Further searching has led me to this page:  http://support.microsoft.com/kb/2590914/ and this:

    2561285 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;2561285) You experience a long domain logon time in Windows 7 or in Windows Server 2008 R2 after you deploy Group Policy preferences to the computer

    Looks promising ...

    My first test using just the two known good items ... works.  But I've been here before.

    I'm now restarting again with the heavy 36/36.

    W00t!  Three restarts with the heavy 36/36 in place and things are working fine!  I must retest on a couple of other Win7 boxes and incorporate several larger 162 item GPP but I'm cautiously optimistic that this is the winner.


    Monday, September 26, 2011 1:41 PM
  • I'm now satisfied that:

    2561285 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;2561285) You experience a long domain logon time in Windows 7 or in Windows Server 2008 R2 after you deploy Group Policy preferences to the computer

    ... is the fix.

    Funny that.  Server 2008 couldn't parse computers in nested Security Groups, which helped me push us to upgrade to 2008r2, among other equally important reasons; and Windows 7 can't parse complex computer based Security Group Item Level Targeting membership without this hotfix (which appears to have been released either Mid-July or Mid-August 2011).

    Meanwhile, complex User Security Group membership Item Level Targeting has worked fine all along.

    Thank you all for your patience while I publicly dug through this over the past 3 months.


    Monday, September 26, 2011 4:36 PM
  • I see you are running 2008 R2 for your DC's but what forest and domain functional levels are you at?  We are looking at moving from 2003 R2 to 2008 R2 but won't be able to move up the functional levels for a longer period of time.  Meanwhile, we are fighting the same slow logons you were seeing.

    Thanks,

    William

    Thursday, September 29, 2011 8:39 PM
  • We're running 2008 R2 functional.

     

    Moving from our old 2003 (non-sp1 even) solution all the way to 2008 with the Group Policy Preferences was carthatic.  You won't look back.

     

    I'd love to hear back if the Windows 7 hotfix that solved our problem works for you.

     

    Thursday, October 6, 2011 9:24 PM
  • Thanks for this, I have been researching this issue over the weekend and have experienced the same Delays with GPClient and Winlogon.  Using the MS Performance Toolkit I was able to get snap shots of some of these delays.  The hotfix you located did help us cut the time in half however it still takes 3 min's to logon with a domain profile vs a local logon on the Windows 7 systems.  This is still far too long and I would like to know if anyone has found additional information that could assist us with further with correcting the problem.  Time to inital "ctrl-alt-Del" is about 45seconds-1 min.  Time once you key your domain logon information is about 2 mins.  The event logon shows some 6005-6006 messages regarding the Winlogon subscriber, GPclient taking about 94 seconds to handle notification event (Create Session).  Any ideas would be appreciated. 
    Monday, November 7, 2011 5:24 PM
  • Robert, I do not have anything new to add to what you did, but I wanted to login and say Thank You for the time you took to look into this problem and for your extensive documentation of it.
    Innovate or close shop ..
    Tuesday, November 8, 2011 2:04 PM
  • What exactly did you do? 

    cenubit

    Friday, July 27, 2018 12:48 PM