Hi,
I have a major problem with a customer Ctrix server that I am struggling to find a solution for, I have found a work around but I am hoping someone can help explain the issue and a better solution.
My customer is a school that has a suite of 30 HP Thinclients running linux connecting to a Windows 2003 R2 SP2 Server running Citrix Xenapp 5.
The issue is that when all clients login simultaneously it can take up to 10 minutes for them all to login. Normally the first 2 go in instantly, the remaining systems pause with the Citrix Presentation server loading screen. This pause can last any duration up to 10 minutes before they login.
The suite was running Presentation Server 4.5 previously and this displayed the same symptoms.
I have switched on userlevel debugging for the login process but there are no visible delays, these seem to happen outside of the login routine.
If the suite is logged in in two sets of 15 systems then the whole login process for each half takes about 1.45 minutes which is acceptable.
The students all access a centrally located mandatory profile located on an area on the same server. We are also using a simple Group Policy object to lock down the students (for obvious reasons).
When the group policy object is disabled then the whole suite logs in completing in under 1 minute 30 seconds - again acceptable except for the lack of restrictions.
I have tried trimming down the GPO as much as possible but this simply makes no difference to the login times.
My short term fix is going to be to manually merge all of the restrictions and settings applied by the GPO into the central student profile then to disable the GPO altogether. This should get me to the fastest possible login time for now.
Has anyone else ever seen this issue with Citrix applying GPO's and can anyone help shed some light?
Thank you for taking the time to read this, I really appreciate any help / advice given.
The last time I saw this, I applied the latest Hotfix Rollup to the 4.5 server and that resolved the issue.
Hi Alastair,
Is this thread applicable to your problem? : http://www.brianmadden.com/forums/t/32207.aspx.
Anyway, handling a user logon is a very resource-hungry thing for the server to do, so handling lots simultaneously can cause slow logons. There are quite a few things to try (plus obviously using a latest rollup pack), such as amending the load evaluator configuration to slightly "step" the logons.
You mention the UserEnvDebug logs show a delay outside of the logon process - but maybe this could still be a delay a user sees? What was the delay in the log?
Regards,
Mark
Thank you both for your input here, I really do appreciate it!
I initially thought the problem could be down to the version of Citrix and bugs so I upgraded it all the way to Xenapp 5 because this seemed an easy option. Sadly this made no difference.
As for the userenvdebug, that's just it, there were no obviously delays, each task was within milliseconds of the next. This means that whilst I know it's part of the login process, the delay doesn't appear to be anything logged during the login process, this is making this really difficult to troubleshoot!
I've seen the artice you linked to but again, the symptoms were different but I applied the changes anyway with no positive effect.
All the group policy does is lock out control panel, IE control panel and a number of other restrictions, as well as redirect my documents to the students home directories. We have tested the login times with the my documents redirection switched off but the other restrictions in place but again this made no difference.
I think it's also worth mentioning that we have other suites with approx 30 fat clients and none of these display the symptoms either.
Yesterday I went through the GPO and integrated each restriction into the central student profile NTUSER.MAN registry hive and switched off GPO altogether. Not ideal but I'm hoping this will make a short term improvement - I am awaiting feedback on how this is performing (obviously it's tricky for me to test 30 simultaneous logins without the students help!?)
Once I have feedback on the above I will also look at the load evaluator because that does sound very interesting too.
Thanks once again for your help!
Regards
Alastair
Sure, keep us posted.
Changing the load evaluator settings may not fix the underlying problem but it sounds like if we can stagger the logons slightly, the problem may be eased. Anyway, pass on the feedback when you have it and we can take it from there.
Regards, Mark
Try turning off branding:
Hotfix - IE7-WindowsServer2003-KB941158-x86-ENU.exe
After Internet Explorer Maintenance Group Policy settings are configured in a domain, a delay occurs when you log on to the domain from a client computer that has Internet Explorer 7 or Internet Explorer 8 installed
To enable this hotfix, follow these steps:Click Start, click Run, type regedit, and then press ENTER.Locate and then click the following registry subkey:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControlOn the Edit menu, point to New, and then click Key.Type the following name, and then press ENTER:FEATURE_PARSING_BRANDING_CMDLINE_FLAGS_KB941158On the Edit menu, point to New, and then click DWORD Value.Type the asterisk symbol (*), and then press ENTER.On the Edit menu, click Modify.Type 1, and then click OK.Exit Registry Editor.
We had similar issues with slow logins because of the IE branding. The KB941158 worked like a charm for us!
Why is it called "Common Sense"? It doesn't seem all that common!
thanks all once again for all your input, it's all appreciated!
since merging the restrictions into the profile we have more than halved the login time but I'm confident we can do better.
I will apply the hotfix at the weekend and test throughout Monday, if all goes well I will attempt to revert back to using gpo for the restrictions.
i'll let you all know how this goes!
cheers
Hi again,
I've been out of the country for a little while but implemented the IE6 version of the DLL before I left. I tried applying the above Microsoft patch but this wouldn't apply on IE8, I opted instead to replace the file IE8 file 'iedkcs32.dll' with the IE6 version - this reduced the login time significantly and my customer is very happy with the end result!
Thanks again for all of your help, I really do appreciate it!
All the best
Wow!, you replaced the IE8 version of iedkcs32.dll with an IE6 version ...and this brought logon times right down? Crikey. Any side effects of replacing this file?
Yikes! Probably not the most recommended solution. The next patch for IE8 could easily overwrite it and you will be back where you started! That particular DLL handles user personalization for IE, so I'm guessing using the earlier version skips a bunch of stuff that IE8 would go looking for. You might want to check out http://support.microsoft.com/kb/899797 to see if this applies to you. I had a similar issue with IE7 and an MS patch (for Server 2003) fixed it up great! I suspect the same things goes for IE8.
Dan
Nope, none whatsoever I'm pleased to say!
This reduced the 30 simultaneous login times for the suite from between 4-5 minutes down to about 2-3 minutes (max).
The customer is very happy with this and has been running without complaint with this in place for the last couple of weeks.
I plan to remove the policy restrictions from the central student NTUSER.MAN registry hive next week and reintroduce these via group policy again.
I will be tracking the login times very closely.
I read the Microsoft knowledgebase article about IE branding and it seemed to match the symptoms but we have already applied all the updates and the hotfix will not apply. That left me with replacing the dll as the simplest option.
I'll keep an eye on this during updates obviously!
Thanks again for you great advice
Well you've certainly got me thinking about this now. I'm going to check whether the "Feature_Parsing" settings are working for us, and am going to experiment on a test server with the iedkcs32.dll file.
We've got an older version of the file on our servers, but a newer date!
941158: iedkcs32.dll - 18.0.6001.22917 - 25-Aug-2009
Installed: iedkcs32.dll - 18.0.6001.18882 - 02-Jan-2010
We're missing the registry key anyway.