Thursday, 28 April 2011

XenApp 6 and Service Pack 1 for Windows Server 2008 R2

No-one who has had a production XenApp 6 system since mid-last year would claim they have had no issues, but with all the latest hotfixes from MS and Citrix we do seem to be getting closer to stability, and a big part of this is Service Pack 1 for Windows Server 2008 R2. 

This is something of a relief after I tried using the beta of SP1 last year – that broke XenApp altogether!

Citrix have said that they support the use of XenApp 6 with 2008 R2 SP1, and I can confirm that I have SP1 servers in production already and they are working perfectly – well, at least no worse than the non SP1 servers!

Citrix do have a page of known issues with SP1, though they appear to be fixed if you have installed the first XenApp 6 hotfix

Known issues: http://support.citrix.com/article/CTX126711

Hotfix: http://support.citrix.com/article/CTX125388

Apart from any general improvements and security fixes Microsoft have made, there are several which appear to be included in SP1 and are especially useful for XenApp 6 servers:

  • KB975777 (delays shutting down systems)
  • KB979530 (connections denied during heavy logon and logoff conditions)
  • KB980663 (stop error during heavy logon and logoff conditions)
  • KB2265716 (server stops randomly if heavily using group policy and SCOM)
  • KB2383928 (remote sessions to not completely exit)

I would still install this post-SP1 patch by the way:

  • KB2465772 (causes XenApp to stop randomly with lots of 7011 errors about services being unresponsive – a very long standing problem for us)

Personally by the way, I would probably rebuild servers with SP1 installed from the start, rather than add SP1 onto a server which has been in use for a long time.  But then XenApp servers like being rebuilt now and then.

As a note, when I installed Service Pack 1 on a server which was already operational and had the EdgeSight Agent running, I then got an EdgeSight Operational Alert:

Error:  An unrecoverable, fatal database error has occurred.  Shutting down the Citrix System Monitoring Agent.

Nice.  EdgeSight carried on working afterwards though.

Tuesday, 15 March 2011

Citrix Web Interface errors: Some of your resources have not been reconnected…

We had an annoying message suddenly appear this morning for all web interface users on logging in and out.  When they logged in they were told “Some of your resources have not been reconnected.  Try reconnecting to your resources again and, if the problem persists, contact your system administrator”:

image

And when they logged out, they were told “Some of your resources have not been logged off.  Ensure you have shut down all your active resources.  If this message does not usually appear at the end of your sessions, contact your system administrator”

image

Turns out the users were quite willing to contact their system administrator as well!  Repeatedly.  I especially like the way the second message assumes you might just always see this message and that this would be okay.

A bit of Googling turned up that we would get rid of this be turning off Workspace Control.  This is in the Citrix Web Interface Management console – right click your websites, select Workspace Control and uncheck the first checkbox…

image

This removed the message – and also the Reconnect and Disconnect buttons.  Not the end of the world, but not the intention either. 

Then I noticed in the event log on the web interface box lots of Application errors of ID 31003 and 30015.  These had messages of…

  • All the Citrix XML Services configured for farm Test XenApp Farm failed to respond to this XML Service transaction.
  • The Citrix XML Service at address http://xensvr01:80/scripts/wpnbr.dll [com.citrix.xml.NFuseProtocol.RequestAppData] is not able to process requests

It was just a test farm with one server which was set up in the web interface, and I was installing updates on it and rebooting repeatedly.  Every time it was unavailable the website was giving the message to users logging in and out as a farm was offline – even though none of the users would be logging into that farm.  Once the work was completed the error stopped coming up.

A good lesson that when you ignore some errors they fix themselves!