My Citrix XenApp Sucks: Part 1

 

It happens a lot, people like me get invited to various meetings which are focused around issues that a business is facing with it's XenApp deployment, this could be any type of business from local councils to retail, hospitals, police etc, where ever it is, the technology is usually the same it is just the method of access and the application suite that is different.

 

There is a pattern here though,  meetings usually start with "This Citrix environment is giving me and my users nothing but problems, they complain about performance, stability, poor login times, security restrictions etc, you know what? I think Citrix XenApp sucks"  Really....?  Now this gets me thinking, thinking about the huge organisations out there that have thousands of seats running XenApp for internal users or service providers such as nasstar.com who provide desktop as a service primarily through XenApp technology.  It works good for them, so why isnt it working well for you?  Usually what follows is a number of questions and discussions which are focused around process and operational management, and then silence.  The questions are usually in the following format:

 

Question 1.  "Who implemented it for you, and were they wearing a cowboy hat and spurs when they did it?"  

 

Just a joke.. but seriously I have seen some really poor implementations and strategic advice over the years even from major vendors.   I also hear people talk and blog so much about strategy and vision and it can be an easy sell when painting a picture for potential clients 'consolidate and deliver everything centrally, virtualise this and that, turn your data center into a delivery center', don't get me wrong as this is all great stuff but once the deal has been done the challenges begin as the process from initial buy in to the vision and how to actually deliver it is very different and can be totally screwed up somewhere in-between.  So building on that, this would be my next question:

 

Question 2.  (The important one).  "Explain to me the methodical approach that you follow to enable safe delivery of your applications into your Citrix XenApp environment, usually this includes the following steps so please let me know which of the following you actively action".

 

Disclaimer: This is a quick overview only as it can differ from business to business.

 

Phase 1: Application Data Gathering

 

An new application request comes in from the business or is in-scope for your application delivery project, either way this is your starting point, here you should be collecting the following information, put it in a spreadsheet, database or whatever.

 

• Installation Documentation
  
  • Read it and figure out if it will cause you any potential issues
  • What are the pre-requisits? When do they need to be installed?  What version are they?  Will they cause conflicts?

• Vendor contact details
  • Anyone using it though XenApp already?  If so, can I contact them?
  • In your experience, what is the resource footprint like?
  • Is it XenApp compatible?  If so, do you have any technical notes?
  • Is there a reason why I can't virtualise and stream it to my XenApp servers?

• Key Users
  • Find a key user in the business, there is always someone (a user) who know the application inside and out right? 
  • Make contact and get some commitment for future testing
  • Ask the key user if they will create a test script for you.  What is a test script?  Just a simple instruction document that you can follow which will enable you to perform a good unit test of the application.

• Actual Users
  • Who and where are they?
  • WAN and location considerations
  • Do they already have an Citrix XenApp client?
  • What are their data requirements?
  • What are their printing requirements?

• Permissions
  • User ID and Passwords for testing the application
  • Active Direcory accounts and permissions required to access data
  • Test accounts needed if nessessary

• Pre UAT Identification
  • Identify the users that you are going to approach for your 'pre UAT' testing phase

• UAT Identification
  • Identify the users that you are going to approach for your 'UAT' testing phase

• BAT Identification
  • Identify the users that you are going to approach for your 'BAT' testing phase

 

 

Phase 2 : Application Installation / Packaging / Unit Testing

 

Here you have a classic use for desktop virtualisation, this is a direct clone of your production build.  There is no excuse for not doing this correctly as everyone is giving away virtualisation for free these days so at a minimum this would be a p2v clone of your Citrix production build running on VMware server on your laptop:

• Application Installation and Snaphot on Virtual Machine 1
  • Install your application packaging software or the Citrix installation manager packager
  • Take a virtual machine snapshot

  • Kick of your application packager snapshot (we aren't compiling an MSI here, just reviewing what components, files and registry components were changes during the installation.

  • Kick off the application installation process and install the application

  • Once the install has completely finished, stop the application packager and review what changes were made to the system, what can you see?  any potential show stoppers?  Make notes of potential issues as you will need this at a later date for building application compatibility scripts, be sure to check out any user specific changes during the installation.

  • Launch the application, does it run first time?  What registry keys etc are created at launch time, where is the application looking for information?

  • Does the application require a printer installed?

  • Does the application require a drive mapping or specific drive letter to function?

  • What about ODBC connections?

  • Build the compile the application installation into an MSI and remove any registry or file system entries that aren't required or may swell the profile.

• Application Compatibility Building
  • Using the information gathered from above and using your preferred scripting method, build your application compatibilty script.
  • Use a strong naming convention and version control system
  • Application compatibility scripts should run for a user prior to the application launching (see usrlogon.cmd in system32)
  • Note: Appsense Environment Manager can also be used for this.
  • See my application compatibilty script here

• Application Unit Testing on Virtual Machine 2
  • By now you should have an MSI or some other packaging format of your application
  • Run the package within this clean virtual machine
  • Did the package install correctly?  If not, revisit Virtual Machine 1 and analyse / repackage
  • Once the application has installed, run the application compatibilty script if applicable
  • Launch the application, did the application launch correctly?  If not revisit Virtual Machine 1
  • When you know that the application is launching correctly, follow the test script provided by your key user to ensure it is working correctly.
  • By this stage you should also have any user accounts needed to test the application.
  • Did the application pass the test script provided by the key user?  If not, any errors should be logged, return to Virtual Machine 1 and analyse / remedy the application before starting the process again.

 

 

Phase 3: Application Pre UAT Testing

 

OK, this is optional and people don't always have the time to perform it.  However I feel that any errors within UAT testing is bad, so as a safety net, asking users to pre UAT and application that 'might' experience some issues isn't a bad thing as you are setting the stage for the user (in reality you are not expecting any errors)

 

 

Phase 4: Application UAT testing

If you have completed the pre UAT stage then you are going to be very confident that your application is going to glide through UAT testing.

• UAT Testing on Virtual Machine 4
  • A clean virtual machine (again a replica of your production build)
  • Deploy your packaged application to the virtual machine
  • Launch the compatibility script if applicable
  • Publish the application to your UAT users
  • Ask the users to login and run a 'UAT test' and to stop at any errors that occur (hopefully there wont be any) and to describe what they were doing when the application failed
  • Did the application pass?  If not return to Virtual Machine 1 analyse and remedy the application based on the information provided by the user
  • Once the application has passed move onto BAT.
  • Capture performance data based on multiple user activity

 

 

Phase 5: Application BAT Testing

 

Again, If you have completed the UAT stage correctly then you are going to be very confident that your application is going to glide through BAT testing.

 

• BAT Testing on Virtual Machine 5
  • A clean virtual machine (again a replica of your production build)
  • Deploy your packaged application to the virtual machine
  • Launch the compatibility script if applicable
  • Publish the application to your BAT users
  • Ask the users to login and run a 'BAT test' and to stop at any errors that occur (hopefully there wont be any) and to describe what they were doing when the application failed
  • Did the application pass?  If not return to Virtual Machine 1 analyse and remedy the application based on the information provided by the user
  • Once the application has passed move onto BAT Sign Off.
  • Capture performance data based on multiple user activity

 

Phase 6: BAT Sign Off

 

This is very important if you can pull it off.  I have in the past and it has worked perfectly.  Each user has actually put pen to paper and signed the application off and working and they have verified that a full test has been completed.  This helps when in the future a user complains that when they run report Z at month end it fails only to find that there was a function that wasn't tested.... the fact that the application was signed off gives you some breathing space as you remedy it within an agreed timescale.

 

 

 

Phase 7: Application Provisioning to Citrix XenApp Servers

 

Now you are ready to deploy your application across your Citrix farm.  Now because I haven't included any application regression testing in the above process we are not going to know at this stage if this application will break any other applications that you may have installed and published.  So we are going for a staged approach:

 

• Pick a Production Citrix XenApp Server
  • Disable logons
  • Next working day once the user load as spread across the farm, install the application and application compatibility script if applicable
  • Launch and test the application and all other applications that maybe installed.
  • Enable logons
  • Wait for any errors from users for upto a week.

 

Phase 8: Installation to remaining servers

 

• Ensuring that no errors have occurred since you installed the application on the first production server
• Schedule the installation of the application across the remaining Citrix servers

 

 

Phase 9: Publishing and Go Live.

 

Your application has now been delivered into your Citrix farm and can be published to your live production users.  Because you have followed a strict methodical approach to delivering the application, you know it is going to work, first time and that the user experience will be a positive one.

 

 

Summary

 

I once knew a senior manager (who will remain nameless) who once said, "pah - Citrix is easy... I don't see where the fuss is, it is easy to install and anyone of my engineers could roll it out", he got fired ages ago and is still advising businesses on strategy today.  However in some respects he was right, Citrix XenApp isn't too difficult to configure to get up and running, the challenge is when you put the Citrix XenApp discs down and start with the applications and users, this is where it takes years of experience to get it right because if there is one thing that will drive a Citrix XenApp project into the ground it is a poor user experience.  It is as simple as this, do some of the above or something similar and your Citrix environment will be more stable, if you do none of it then I am pretty sure that over time and as your Citrix XenApp environment grows / becomes more complex and critical to the business, it will suck.

 

 

Next time:  My Citrix XenApp Sucks part 2. Achieving a Single Build and Reducing Application Regression Testing with Application Virtualisation and Application Streaming.

 

 

 

 

• DABCC User:
• Guest
• Subject:
• Message:
• Image Code:
• 

Latest Articles