Last week I was asked to help out with a problem in a XenApp 6.5 production environment with a new published application. Users trying to start the application from the Citrix Web Interface received an error, stating the resource was not available. The same error was given when the application was started directly, using a ICA file.
Remote Desktop Connection
To see if the problem might be bigger than the published application, I tested if a RDP connection could be set up to one of the assigned servers. The RDP session was set up without any problems or notifications. So connecting to the server or running a Remote Desktop session on the server was not the problem either.
Event logs
Time to check the Event logs for clues (errors or warnings) on the source of the problem. To my surprise no clear warnings or errors were found in the Event logs explaining the odd behaviour
Qfarm /load
So it was time to check the load on the assigned servers for the application. And there it was!
A constant load of 10000 was shown for each newly provisioned server in our farm.
Seeing the servers report full load triggered a memory of reading an article on custom load evaluators and spiked loads. A quick google search did not offer any hits though.
Custom Load Evaluators
It was time to further investigate the load evaluators assigned to the affected servers. Each server was assigned a custom load evaluator containing memory and cpu settings. But that same load evaluator was also assigned to a bunch of XenApp servers that showed normal load values
Let’s change the LE
Intrigued even more by this discovery I decided to change the assigned Load Evaluator and assigned a new Custom LE based only on a maximum number of user sessions. After the gpupdate the load for the affected servers dropped immediately and the values were normally calculated. This workaround ensured users could start the application once more, but did not offer a real solution as the newly assigned Load Evaluator did not protect the server resources from being overloaded by the logged on users.
Wait a minute …. what’s with the dutch UI?!?!
So I decided to run some more tests on the affected servers. And then it hit me …. my session was run with a Dutch UI instead of the English UI I normally had.
And once more a memory was triggered that I read some article on full loads, custom Load Evaluators and MUI packs
And after changing some of the keywords, my google search came with the answer, by returning an article from Edwin Friesen: XenApp 4.5 Load Evaluator reports 100% Memory on idle server after installing Dutch MUI Pack.
The solution
It turned out that a change in the sysprep settings for the new provisioned image changed the default and system language to Dutch instead of the previously used English default. Luckily this could easily be restored in the unattend.xml file and provision servers once more with default English UI settings.
Apparently the dutch UI changes the way comma’s and dots are used in decimal numbers, which disturbs the Load Evaluator calculations and creates false positive full load results. To manually change the UI settings, you can follow the directions in this article: How To Change The Default Language For Windows 7 Logon Screen
The same false positives occur with System Center Operations Manager checks and rules that report miscalculated results as well for servers configured with a default Dutch system language.
The following sources have been used to create this post:
XenApp 4.5 Load Evaluator reports 100% Memory on idle server after installing Dutch MUI Pack
How To Change The Default Language For Windows 7 Logon Screen
Next time try to Bing it 😉