Publishing App-V Applications into XenApp 6.5

My aim with my XenApp 6.5 farm was to keep the servers as clean as possible, free from any locally installed applications.  Why so?  When PVS is delivering all of my XenApp servers, updating, patching or really, performing any maintenance on a locally installed application at some point, required a reboot of the XenApp servers.  In my XenApp 5.0 and App-V 4.6 days, I annoyingly had to bake a few applications into the vDisk in private mode for the applications to work correctly.  Now, the better virtualization available with App-V 5.x, my XenApp 6.5 servers are squeaky clean with no apps installed locally.

I currently have 2 App-V 5.0 servers providing App-V resources to my XenApp 6.5 farm.  Both servers have the Management and Publishing roles installed, however, I don't use either.  Maybe in the future, but not now.  Both servers have a 'Content' share where all of my packages are kept.  They are referenced by a DFS namespace to give App-V 5.0 some HA capability.  Since our domain doesn't support 2012 schemas (which both of my App-V servers are Server 2012 of course), replication of the content share is not possible.  That's no great drama, since I perform most of my package admin on one App-V server, which I unofficially designate as my primary box.  A simply Robocopy script will keep the 2 content shares in sync.

So why don't you use the Management and Publishing services of App-V?

Simple.  I wanted to use Powershell to manage and publish all of my applications so I had a greater degree of control.  Rather than issue a generic publish refresh on a target XA server, using the add-appvclientpackage and publish-appvclientpackage cmdlets gave me much better control of adding and publishing an application.  So I turned to Powershell to script up the required actions.

What's going on here?

This script is actually initiated by another Powershell script responsible for starting the necessary Citrix services to join the XenApp farm after a reboot.  I'll get to that script in a minute.

The idea being, when used in conjunction with the XenApp script, that a server has all of its applications added and published (using the -global switch so apps are available to the workstation, not just the user).  Once this has completed successfully, the XenApp scripts continue and the server joins the farm.  No risk of a user logging into XenApp and complaining that an application is missing because it hasn't been published.  Cool.  Less stress for me.

If there is an error with the publishing, the script stops and the required Citrix services don't start.  No users can log onto the affected servers.  Cool.  Even less stress for me.  The contents of the script is pretty simple.

Line 1 advises Powershell what to do in the event of an error.  In this case, it's simply just to stop.

Line 2 is for my benefit.  When I jump into PVS to switch a disk into private mode, I don't want App-V adding and publishing all of my applications to my private disk.  Line 2 basically checks what mode the vDisk is running where '4' means its in Shared Mode.  If $WriteCacheType is anything other than 4, the script won't run.  Line 5 checks for that.

Lines 10 through 16 is where the adding and publication happens.  Pretty straight forward.  In my environment, I use the -global switch for all publications.  Since I need the app added and published to the server BEFORE I can use XenApp to publish the app out via ICA to the user.

Line 18 through 20 creates a 'flag' to indicate the success of the script.  If the script runs without error, the Packages.Published file is created.  If it errors out, the file is NOT created.  This will serve a purpose in the XenApp start-up scripts.

XenApp Startup

Below, is the script I use to prepare my XenApp servers for production use in the farm.  It essentially does the following:

• Checks for network connectivity
• Checks and waits for the AppVClient service to start
• Runs the script as above
• If Packages.Published is found, the script starts the required IMA services and joins the farm
• If Packages.Published is NOT found, the script flicks out an email and DOES NOT join the farm

Let's break it down!

Line 5 defines the function to wait for network connectivity.  This function will keep looping until the network interface joins the network.

Line 32 queries the AppVClient service (or any other service for that matter) to obtain it's status.  The function completes when either the service has started or the timeout value has been reached.

Line 56 begins the process of starting the adding/publishing AppV packages, followed by starting the XenApp services (based on the success of the AppV package script).

Line 65 terminates the entire script if either the AppVClient service does not start or the timeout has been reached.

Line 73 adds and publishes the AppV packages (as called from Line 56).  The function will wait for this script to finish.

Line 78 starts the XenApp services.  If Packages.Published DOES NOT exist, the script stops.  Line 82 catches this error and sends an email out to advise accordingly.

Line 87 runs a couple of generic scripts to set the Secure Ticket Authority ID and run a .bat file to start the required XenApp services.

Finally, Line 91 and 92 is what calls all of the above.  With the QueryService function, you can put whatever service you want to check for and set whatever timeout you require.  I have 120 seconds set, since this script runs at server startup which for my farm, happens at 3AM as part of their scheduled reboots, so I can afford to stretch it out a little to give the services a chance to start.

Since using the above, I know I can get consistent results and a great user experience.  Servers which have an issue with publishing apps, do not join the farm.  Only 100% correctly configured servers will be able to provide applications and resources to users.  No more unexpected phone calls on Monday morning from users!  That's a big WIN!

Cheers