locked
XP machines slow to login following resolution of 1.0.1703.0 reoffering problem RRS feed

  • Question

  • Since the fix was released for the reoffering of client engine 1.0.1703.0 all of our XP machines are taking upto 3 minutes to login. Users can enter their password but then the login box sits there for 3 minutes before continuing. Once the machine has started all seems to work fine.

    Anyone else seen this issue?

    Thanks
    Tuesday, June 23, 2009 1:46 PM

Answers

  • Seems to be more of an issue for slightly older systems is what we are seeing.  Saw the following behaviour with the customer we worked with yesterday.


    Moving into an OU with no computer logon scripts fixed the issue. (my customer had some pretty serious logon scripts using ifmember.exe and various other .exe's etc from sysvol during logon for his systems)
    Setting the Minifilter scan timeout values back to pre-971026 fixed the issue. See Oz's post above.
    We do not see the issue on newer dual core systems.
    Disabling FCSAM service stops the issue (of course this leaves you totally unprotected NOT a viable solution)

    We are still working on getting tracing/debug of this to see exactly what is happening but the current hypothesis is that on a slower system with a lot of logon scripting stuff for the computer we are taking longer to timeout on items that we were probably timing out on more quickly before and thus starting up more quickly.  From what we could tell from a Process Monitor boot log it sort of seems like the Minifilter is probably passing items to the Service/Engine before it is completely started and then has to wait on this longer timeout period before allowing that file to run on the system.

    In conclusion the reg keys listed should get you back to the way your logons on were previous to KB971026.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MpFilter\Parameters]
    "MaxScanTimeout"=dword:7530
    "MinScanTimeout"=dword:3A98


    CSS Security Support Engineer (FCS/MBSA/WUA/Incident Response) Check out my blog http://blogs.technet.com/kfalde
    Friday, June 26, 2009 2:01 PM

All replies

  • We are also seeing this problem (or one similar!)

    In our case the delay is about 2 minutes waiting on the dialog "Applying Computer Settings".

    As a test I uninstalled Forefront and MOM on one machine and rebooted. The same screen took 10 seconds! I then forced an update cycle using "wuauclt /detectnow" and accepted the 2 different sequential Forefront pushes. After the 2nd one I did another reboot and I'm back to the 2+ minutes spent Applying Computer Settings.

    Additionally, it appears the MOM service is now hosed. One minute after Event 9010 (MOM is starting), I get an event 9001 (MOM failed to start). Then a minute later I get event 9002 (MOM failed to stop). Then a minute later I get 9013 (MOM has stopped).

    I tried the trick of deleting MOM's configcache file and restarting MOM and it will in fact run then, but on the next reboot cycle I'm back to square one again with the 2+ minute delay and MOM is no longer able to run.

    -Mike Tanis
    Tuesday, June 23, 2009 4:05 PM
  • This is still happening to about 25% of my client machines. (32-bit XPSP3 on mostly Dell hardware). I haven't been able to recognize a pattern in the machines which are involved. I enabled verbose logging on the MOM client and generated a 120kB log file but I wasn't able to discern anything in the log which was helpful.

    Just for grins I just invoked "psexec \\* net start mom" on my domain and let it start all the agents for me.

    I'll probably start a support incident tomorrow if I continue to be unable to make progress in troubleshooting this.

    -Mike Tanis
    Wednesday, June 24, 2009 4:00 PM
  • We are having the same problem with slow machines.  We have found by removing the machine from the domain and adding it again solves the problem.  We have tried this on 3 machines.  But we really need a global fix as we have a lot of affected machines. 
    Thursday, June 25, 2009 11:45 AM
  • Hi all,

    Can you do the following:

    1. Enable userenv logging as per below:

    Use a value of 0x00030002 and follow the KB article at  http://support.microsoft.com/kb/q221833/ to do this. Once the system is restarted, and the logon delay occurs, find the userenv.log file at %Systemroot%\Debug\UserMode\Userenv.log

    2. After a restart open this log file and search for the below:

    "ProcessGPOs:  Starting computer Group Policy (Async forground) processing..."

    Please send me the outputs from what you see, if you are seeing something similar to the below one....
    USERENV(27c.57c) 15:55:31:859 ProcessGPOs:  Starting computer Group Policy (Async forground) processing...
    USERENV(27c.57c) 15:55:31:859 ProcessGPOs:
    USERENV(27c.57c) 15:55:31:859 ProcessGPOs:
    USERENV(27c.57c) 15:55:31:859 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0
    USERENV(27c.57c) 15:55:31:859 EnterCriticalPolicySectionEx: Machine critical section has been claimed.  Handle = 0x710
    USERENV(27c.57c) 15:55:31:859 EnterCriticalPolicySectionEx: Leaving successfully.
    USERENV(27c.57c) 15:55:31:859 ProcessGPOs:  Machine role is 2.
    USERENV(27c.57c) 15:55:31:859 PingComputer: Adapter speed 100000000 bps
    USERENV(27c.57c) 15:55:31:859 PingComputer:  First time:  0
    USERENV(27c.57c) 15:55:31:859 PingComputer:  Fast link.  Exiting.
    USERENV(798.7d4) 15:55:32:203 LibMain: Process Name:  C:\WINDOWS\System32\CCM\CLICOMP\RemCtrl\Wuser32.exe
    USERENV(7dc.7c) 15:55:32:578 LibMain: Process Name:  C:\WINDOWS\System32\CCM\CcmExec.exe
    USERENV(190.194) 15:55:32:718 LibMain: Process Name:  C:\WINDOWS\system32\wbem\wmiprvse.exe
    USERENV(27c.16c) 15:56:49:494 SetFgRefreshInfo: Next User Fg policy Synchronous, Reason: NonCachedCredentials.
    USERENV(27c.280) 15:57:51:834 LoadUserProfile: Yes, we can impersonate the user. Running as self
    USERENV(27c.280) 15:57:51:834 =========================================================

    notice the delay at wmiprvse.exe....

    thanks,
    Oguzhan
    Thursday, June 25, 2009 5:04 PM
  • Here is a section of that log file from my machine... the relevant part is about in the middle... note the 2:44 minute delay after or during wmiprvse.exe...


    USERENV(2e0.2f8) 12:41:36:265 =========================================================
    USERENV(2e0.2f8) 12:41:36:265 LoadUserProfileI: returning 0
    USERENV(30c.310) 12:41:36:265 LoadUserProfile: Running as self
    USERENV(30c.310) 12:41:36:265 LoadUserProfile: Calling LoadUserProfileI (as user) succeeded
    USERENV(30c.310) 12:41:36:265 LoadUserProfile:  Returning success.  Final Information follows:
    USERENV(30c.310) 12:41:36:265 lpProfileInfo->UserName = <LocalService>
    USERENV(30c.310) 12:41:36:265 lpProfileInfo->lpProfilePath = <>
    USERENV(30c.310) 12:41:36:265 lpProfileInfo->dwFlags = 0x9
    USERENV(2e0.408) 12:41:36:265 IProfileSecurityCallBack: client authenticated.
    USERENV(2e0.408) 12:41:36:265 ReleaseClientContext: Releasing context
    USERENV(2e0.408) 12:41:36:265 ReleaseClientContext_s: Releasing context
    USERENV(2e0.408) 12:41:36:265 MIDL_user_free enter
    USERENV(30c.310) 12:41:36:265 ReleaseInterface: Releasing rpc binding handle
    USERENV(30c.310) 12:41:36:265 LoadUserProfile: Returning TRUE. hProfile = <0x498>
    USERENV(30c.310) 12:41:36:265 GetUserDNSDomainName:  Domain name is NT Authority.  No DNS domain name available.
    USERENV(128.12c) 12:41:36:328 LibMain: Process Name:  C:\WINDOWS\System32\svchost.exe
    USERENV(1f8.1fc) 12:41:36:500 LibMain: Process Name:  C:\WINDOWS\system32\svchost.exe
    USERENV(3e4.3e8) 12:41:36:828 LibMain: Process Name:  C:\WINDOWS\system32\SearchIndexer.exe
    USERENV(4d4.4dc) 12:41:37:109 LibMain: Process Name:  C:\WINDOWS\system32\wbem\wmiprvse.exe
    USERENV(2e0.6e8) 12:44:21:978 ProcessGPOs: network name is donthackmydomain.com
    USERENV(2e0.6e8) 12:44:22:415 ProcessGPOs:  User name is:  CN=M-MTANIS-620,OU=Computers,OU=Marshfield,DC=donthackmydomain,DC=com, Domain name is:  DONTHACKMYDOMAIN
    USERENV(2e0.6e8) 12:44:22:415 ProcessGPOs: Domain controller is:  \\mfld-pdc.donthackmydomain.com  Domain DN is donthackmydomain.com
    USERENV(2e0.6e8) 12:44:22:415 ReadGPExtensions: Rsop entry point not found for gptext.dll.
    USERENV(2e0.6e8) 12:44:22:415 ReadGPExtensions: Rsop entry point not found for dskquota.dll.
    USERENV(2e0.6e8) 12:44:22:415 ReadGPExtensions: Rsop entry point not found for gptext.dll.
    USERENV(2e0.6e8) 12:44:22:415 ReadGPExtensions: Rsop entry point not found for iedkcs32.dll.
    USERENV(2e0.6e8) 12:44:22:415 ReadGPExtensions: Rsop entry point not found for C:\WINDOWS\System32\srchadmin.dll.
    USERENV(2e0.6e8) 12:44:22:431 ReadGPExtensions: Rsop entry point not found for scecli.dll.
    USERENV(2e0.6e8) 12:44:22:431 ReadGPExtensions: Rsop entry point not found for C:\WINDOWS\System32\cscui.dll.
    USERENV(2e0.6e8) 12:44:22:431 ReadGPExtensions: Rsop entry point not found for gptext.dll.
    USERENV(2e0.6e8) 12:44:22:431 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}
    USERENV(2e0.6e8) 12:44:22:431 ReadStatus: Read Extension's Previous status successfully.

    Thursday, June 25, 2009 6:07 PM
  • I don't seem to get any ping replys from the machine experiencing this problem.  Then after about 8 minutes I start getting a reply and everything jumps into life!!  I'm enabling the above log file as suggested.

    Thank you for your response!!

    Paul.
    Thursday, June 25, 2009 6:23 PM
  • Fantastic Mike, thank you very much for this. Currently I have 2 customers experiencing this and we are working around the clock to fix this issue. We are analyzing debug logs collected from the mom agent.

    In the meantime can you let me know if disabling the MOM Service and then restarting the client makes any difference, logon will probably be faster.

    Once I have more information, I'll post the answer here.
    Thursday, June 25, 2009 6:27 PM
  • I disabled the Forefront Services and all is ok on the affected machine.

    Thanks
    Thursday, June 25, 2009 6:27 PM
  • Specifically was the service you disabled, FCSAM service or the MOM agent or both?

    thank you,
    Oguzhan
    Thursday, June 25, 2009 6:30 PM
  • I disabled MOM plus the 2 forefront services.


    I did disable the mom service initially and rebooted but it made no difference so I disabled both Forefront services to.

    Thanks
     

    Thursday, June 25, 2009 6:34 PM
  • Like Paul, I initially disabled the MOM service and rebooted. >> No improvement.

    Then I disabled the Forefront Security State Assessment service and rebooted. >> No improvement.

    Then I disabled the Forefront AntiMalware service and rebooted. >> Normal login times.
    Thursday, June 25, 2009 7:48 PM
  • Any more progress on this?  We have many public facing machines experiencing this problem and I know we will get a lot of complaints this morning.  We have opened a call with Microsoft I will update this thread with there feed back.

    Thanks

     

    Paul.

    Friday, June 26, 2009 7:20 AM
  • Here is a section of the log file you asked me to enable.

    USERENV(298.3c4) 19:42:36:453 =========================================================

    USERENV(298.3c4) 19:42:36:453 LoadUserProfileI: returning 0

    USERENV(2c4.2c8) 19:42:36:453 LoadUserProfile: Running as self

    USERENV(2c4.2c8) 19:42:36:453 LoadUserProfile: Calling LoadUserProfileI (as user) succeeded

    USERENV(2c4.2c8) 19:42:36:453 LoadUserProfile: Returning success. Final Information follows:

    USERENV(2c4.2c8) 19:42:36:453 lpProfileInfo->UserName = <LocalService>

    USERENV(2c4.2c8) 19:42:36:453 lpProfileInfo->lpProfilePath = <>

    USERENV(2c4.2c8) 19:42:36:453 lpProfileInfo->dwFlags = 0x9

    USERENV(298.2b0) 19:42:36:453 IProfileSecurityCallBack: client authenticated.

    USERENV(298.2b0) 19:42:36:453 ReleaseClientContext: Releasing context

    USERENV(298.2b0) 19:42:36:453 ReleaseClientContext_s: Releasing context

    USERENV(298.2b0) 19:42:36:453 MIDL_user_free enter

    USERENV(2c4.2c8) 19:42:36:453 ReleaseInterface: Releasing rpc binding handle

    USERENV(2c4.2c8) 19:42:36:453 LoadUserProfile: Returning TRUE. hProfile = <0x3b8>

    USERENV(2c4.2c8) 19:42:36:453 GetUserDNSDomainName: Domain name is NT Authority. No DNS domain name available.

    USERENV(51c.520) 19:42:36:500 LibMain: Process Name: C:\WINDOWS\system32\svchost.exe

    USERENV(5a8.5ac) 19:42:36:796 LibMain: Process Name: C:\WINDOWS\system32\spoolsv.exe

    USERENV(298.4e4) 19:46:36:859 ApplyGroupPolicy: Entering. Flags = f

    USERENV(298.4e4) 19:46:36:859 ProcessGPOs:

    USERENV(298.4e4) 19:46:36:859 ProcessGPOs:

    USERENV(298.4e4) 19:46:36:859 ProcessGPOs: Starting computer Group Policy (Async forground) processing...

    USERENV(298.4e4) 19:46:36:859 ProcessGPOs:

    USERENV(298.4e4) 19:46:36:859 ProcessGPOs:

    USERENV(298.4e4) 19:46:36:859 EnterCriticalPolicySectionEx: Entering with timeout 600000 and flags 0x0

    USERENV(298.4e4) 19:46:36:859 EnterCriticalPolicySectionEx: Machine critical section has been claimed. Handle = 0x720

    USERENV(298.4e4) 19:46:36:859 EnterCriticalPolicySectionEx: Leaving successfully.

    USERENV(298.4e4) 19:46:36:859 ProcessGPOs: Machine role is 2.

    USERENV(2c4.2c8) 19:46:44:968 LoadUserProfile: Yes, we can impersonate the user. Running as self

    USERENV(2c4.2c8) 19:46:44:968 =========================================================


    Here is the same machine with the Forefront services disabled

    USERENV(2c4.2c8) 19:55:29:703 =========================================================

    USERENV(2c4.2c8) 19:55:29:703 LoadUserProfile: Entering, hToken = <0x2d8>, lpProfileInfo = 0x7fcf8

    USERENV(2c4.2c8) 19:55:29:703 LoadUserProfile: lpProfileInfo->dwFlags = <0x9>

    USERENV(2c4.2c8) 19:55:29:718 LoadUserProfile: lpProfileInfo->lpUserName = <NetworkService>

    USERENV(2c4.2c8) 19:55:29:718 LoadUserProfile: NULL central profile path

    USERENV(2c4.2c8) 19:55:29:718 LoadUserProfile: NULL default profile path

    USERENV(2c4.2c8) 19:55:29:718 LoadUserProfile: NULL server name

    USERENV(2c4.2c8) 19:55:29:718 GetInterface: Returning rpc binding handle

    USERENV(298.2b0) 19:55:29:718 IProfileSecurityCallBack: client authenticated.

    USERENV(298.2b0) 19:55:29:718 DropClientContext: Got client token 000005F8, sid = S-1-5-18

    USERENV(298.2b0) 19:55:29:718 MIDL_user_allocate enter

    USERENV(298.2b0) 19:55:29:718 DropClientContext: load profile object successfully made

    USERENV(298.2b0) 19:55:29:718 DropClientContext: Returning 0

    USERENV(2c4.2c8) 19:55:29:718 LoadUserProfile: Calling DropClientToken (as self) succeeded

    USERENV(298.3c0) 19:55:29:718 IProfileSecurityCallBack: client authenticated.

    USERENV(298.3c0) 19:55:29:718 In LoadUserProfileP

    USERENV(298.3c0) 19:55:29:718 LoadUserProfile: Running as client

    USERENV(298.3c0) 19:55:29:718 =========================================================

     


    Oguzhan - I understand you are in contact with my manager Geoff?

    Thanks

    Paul.

    Friday, June 26, 2009 8:28 AM
  • Hi all,

    In a similar case, we have found out that the changes introduced in the network scanning have been causing this. While we still need to investigate more, here is a possible solution:

    Put one of the clients to a test OU and block inheritance. This will block all scripts processing and similar activity that happens over the network during logon. This is a test to see if you are hitting the network scanning timeouts. If the logon times improve, then you can set the below 2 registry keys as below:



    Save the below text in .reg file and run this on the client machine and restart:




    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MpFilter\Parameters]
    "MaxScanTimeout"=dword:7530
    "MinScanTimeout"=dwoad:3A98

    Let me know if this works out fine for you.

    Thank you,


    Oguzhan Filizlibay Security Escalation Engineer Microsoft EMEA CSS Security

    Friday, June 26, 2009 9:27 AM
  • You have a typo......

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MpFilter\Parameters]
    "MaxScanTimeout"=dword:7530
    "MinScanTimeout"=dword:3A98


    Above is correct spelling.

    ;-)


    Kathleen Barry

    Friday, June 26, 2009 10:46 AM
  • We blocked inheritance on a test OU with some test machines and logon was lightning quick.  We put the machines back into their original OU's and the problem then re-appeared.  We then added the registry changes and log on was much quicker.  

    On the three test machines there was still a moment where the machine seemed to freeze.  Would these value's be adjustable to see if this speeds things up even more?

    Thanks

    Paul.   
    Friday, June 26, 2009 10:58 AM
  • I tried the registry settings on one machine and they seemed to "fix" the problem. On another machine I removed it and then put it back in the domain and that also seemed to "fix" the problem. I'm still scratching my head why >75% of my machines seem to be fine.
    Friday, June 26, 2009 1:39 PM
  • Seems to be more of an issue for slightly older systems is what we are seeing.  Saw the following behaviour with the customer we worked with yesterday.


    Moving into an OU with no computer logon scripts fixed the issue. (my customer had some pretty serious logon scripts using ifmember.exe and various other .exe's etc from sysvol during logon for his systems)
    Setting the Minifilter scan timeout values back to pre-971026 fixed the issue. See Oz's post above.
    We do not see the issue on newer dual core systems.
    Disabling FCSAM service stops the issue (of course this leaves you totally unprotected NOT a viable solution)

    We are still working on getting tracing/debug of this to see exactly what is happening but the current hypothesis is that on a slower system with a lot of logon scripting stuff for the computer we are taking longer to timeout on items that we were probably timing out on more quickly before and thus starting up more quickly.  From what we could tell from a Process Monitor boot log it sort of seems like the Minifilter is probably passing items to the Service/Engine before it is completely started and then has to wait on this longer timeout period before allowing that file to run on the system.

    In conclusion the reg keys listed should get you back to the way your logons on were previous to KB971026.

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MpFilter\Parameters]
    "MaxScanTimeout"=dword:7530
    "MinScanTimeout"=dword:3A98


    CSS Security Support Engineer (FCS/MBSA/WUA/Incident Response) Check out my blog http://blogs.technet.com/kfalde
    Friday, June 26, 2009 2:01 PM
  • On another note has anyone seen this on a Vista machine?

    Specifically where ONLY after applying KB971026 the system bootup is say 2x slower then previously and disabling FCSAM service gets you back to a "normal" bootup time for your environment?
    CSS Security Support Engineer (FCS/MBSA/WUA/Incident Response) Check out my blog http://blogs.technet.com/kfalde
    Friday, June 26, 2009 2:06 PM
  • Kurt, the machine I tested the registry settings is running a Core2Duo E8200 (2.66GHz) cpu. I just deleted the registry entries and rebooted and confirmed the problem returned immediately. Many other machines in my environment that are having the problems are dual-core Pentium D CPUs running at 3.2GHz. All are runnning XPSP3. I only have a single Vista and a single Windows 7 machine running Forefront and neither have the problem.

    I DO have is a reasonably complex management situation with Desktop Authority 7.81 running an array of startup scripts, drive mappings and shortcut deliveries. My people complain about login times even when the systems are working as designed! :)

    -Mike Tanis
    Friday, June 26, 2009 3:39 PM
  • Thanks Mike if you could shoot me an email when you have a chance so if I need to I can contact you kfalde microsoft com

    Thanks
    CSS Security Support Engineer (FCS/MBSA/WUA/Incident Response) Check out my blog http://blogs.technet.com/kfalde
    Friday, June 26, 2009 6:45 PM
  • We have sent the registry changes out via SMS on Friday and we are seeing some good results.

    We need to know if an update will be released that includes these reg keys as we need it written into the software and not just rely on the SMS workaround to cover our machines.  For example our public facing machines are in a different domain and do not communicate with with the SMS server so not receiving the reg fix.

    Thanks

    Paul. 
    Monday, June 29, 2009 10:17 AM
  • Could we have an update on this please as this is just a quick fix and not a solution.  We need to know if a perminant fix will be done as machines that do not connect to the SMS server will still have a problem.

    Thanks

    Paul.
    Tuesday, June 30, 2009 8:17 AM
  • Any update about this issue?
    Tuesday, July 14, 2009 8:03 PM
  • The product group is aware of it and we do have an internal repro of the issue we have debugged.  Any fix though will usually take a while to get pushed out as this would be a fix to the client itself and not just the engine (which is released monthly).

    One thing that you may want to check as well is let me know if you are using any network path exclusions for machines that are having this issue i.e. in your FCS policies do you have any exclusions for \\server\directory setup?  If so test removing the network path exclusions and see if that resolves the issue as well.

    We could create an .adm file I believe for the reg keys that would assist with making it easier to fix this issue by modifying the timeouts however these keys unlike the policy keys are tatooed in the registry as they are under the service entry and would require some other method of removing them once the problem has been resolved.


    For now I would stick with using one of these fixes, if you have the issue, as a final solution will take some time.
    CSS Security Support Engineer (FCS/MBSA/WUA/Incident Response) Check out my blog http://blogs.technet.com/kfalde
    Wednesday, July 15, 2009 6:40 PM
  • I read some articles about issues with KB971026 and logon delays.
    Yesterday, a new version of this KB was downloaded to my WSUS server (07/14/2009). ??
    With all the forefront services down the logon time is normal.
    I tried to applied a GPO with the information bellow to Disable Network Scans, but this didn't solve the issue. Anyway, we don't use network path exclusions in the policy. We only have this problem with notebooks computers. And the WSUS and FF policies are almost the same for desktop and notebooks machines.

    http://support.microsoft.com/?scid=kb%3Ben-us%3B971026&x=12&y=13

    I just fix a couple of machines doing the following:

    - I approve the new KB in my WSUS, and i checked it was installed on the box affected
    - Create a reg file and i applied this:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MpFilter\Parameters]
    "MaxScanTimeout"=dword:7530
    "MinScanTimeout"=dword:3A98

    - Reboot the machine, and the logon time was right and normal.

    But we still have reports about logon delay. So, we are waiting for a solutions on this.


    Thanks!

    Regards,
    Miguel

    Thursday, July 16, 2009 1:37 PM
  • I would recommend that you should probably open a case with CSS Security if you are still having the issue here so we can take a closer look at what is going on with your environment in this case.

    Thanks
    Kurt
    CSS Security Support Engineer (FCS/MBSA/WUA/Incident Response) Check out my blog http://blogs.technet.com/kfalde
    Thursday, July 16, 2009 2:24 PM
  • I actually just solved this issue (in my case)  by using 'Domain Users' in in the security tab of the policy to apply the policy, rather than 'authenticated users' which is what we were using before. In our case, logins became very slow after last week's windows updates come down.

    Not sure why using a different security group fixed, but happy to have that over with- We were looking at 5+ minute delays and many unhappy users.
    Monday, July 20, 2009 6:30 PM
  • So changing from Authenticated Users to Domain Users solves the problem of slow logins  ? Cause after implementing FCS our WinXP SP3 on the test lab workstations our login script doesnt work anymore neither was it possible to work after a restart for at least 10mins. after 10mins of....dunnow what exactly the users where able to work again. no need to say that this behavior is not acceptable.
    Wednesday, October 28, 2009 3:32 PM