I always love when I’m asked at work to do the maximum imaginable result with the least amount of resources. It’s like being asked to move a mountain and handed a single rope. While not impossible (you could do it in many trips with the rope tied to chunks), it does make you wonder, while you’re laboring, how on Earth you got yourself into this.
Thankfully I was ready for a challenge. Recent projects were the same ol’, same ol’, and I was bored. When I was asked to take the reigns on vetting an app virtualization product to use I was pretty stoked. I spent a few weeks on one product that has a great Cloud capability but we eventually settled on Microsoft’s App-V for various reasons. I was then asked to figure out how to publish apps without the need of a management server and database. 😐
Management doesn’t want the overhead of maintaining those two additional servers…. OK. I took it as a challenge and set to figuring it out. One goal I made for myself was to figure out a way to do it in Powershell that was generic. We use PVS with out Citrix environment but the thought of having to open up an image every time we add or change an App-V package wasn’t very appealing. After all, the goal is the least amount of maintenance and hassle. Mind you, integration for App-V packages is now built in with newer versions of XenApp but we aren’t there yet. So, the initial foray was quite easy and successful. To publish an individual app it only takes 3 lines of Powershell code. However, that’s a specific application and I wanted to go generic. That’s where the fun began.
My inital plan was to write a script that lived in the PVS image and would accept parameters. I’d use the published app in the XenApp console to pass those parameters depending on what app was published. My two parameters were the name of the App-V package and the path to the EXE that needed to be launched. The script was capable of taking the name of the package and building the DFS path to where the packages are stored. The folder names are the same as the package names for ease of use. The script would then add the package to the local disk and then publish it globally. The path to the EXE is, well, to launch the correct app. This didn’t work out so well because the EXE’s for a package are burried deep in the folder structure for App-V and the Windows command line can only accept a command that is 255 characters long or less.
I then dug into the cmdlets for App-V looking for a way to identify executables based off a package. Nothing in the way of EXE’s. I then tried creating shortcuts in a folder at the root of C inside the package’s XML configuration. That failed and it appears an App-V package wont write a shortcut in most directions. It has to be either the public desktop, start menu, or inside the packages folder structure. I figured if I can’t do it by manually editing the XML file, then perhaps I can do it by adding it in the package itself. Nope. It writes the code to the XML file to create the shortcut just like I had manually, but it never actually creates it. I’m assuming this probably isn’t a bug, since virtualized apps are supposed to be contained and writing shortcuts anywhere on the computer would be a mess. It’s probably just an undocumented feature.
After a little bit of feeling frustrated I got the sudden inspiration to return to the XML file. Why? Because the XML file lists every single EXE that was packaged! I didn’t need to pass an entire path because I could just read it from the XML file. So that’s what I did. My second parameter in the Citrix published app was now just the EXE name I needed to launch. The publishing script in the PVS image now, after adding and publishing the package, will read in the XML configuration file and search it for the EXE name being passed to it. Once it finds it, it takes the path for it in the XML, does a little string modification in the way of parsing, replacing, and concatenating, and voila, I have the entire path to the program I need to launch.
It took me about a day and a half to finish the entire script. I added a couple more things like popping up an error message if it encountered a problem adding and publishing the App-V package. Also, a loading screen that cleverly waits for the app to launch and show up before disappearing so the end-user doesn’t think nothing is happening. Script is below. I also published it as my first script to poshcode.org.
The location for the Citrix published app looks something like this: powershell.exe -file C:\Scripts\AppVAddAndPublish.ps1 “AppName” “Exename.exe”
(don’t forget to set-executionpolicy in the PVS image or override it here)
Of course, now we’re upgrading to 7.8 for Citrix so all of this work is probably going to be useless! It was fun and challenging anyway 🙂