• Twitter
  • LinkedIn
  • RSS Feed
  • Subscribe via Email

Sequencing LibreOffice

Written by Dan Gough. Posted in App-V v5.x

Don’t ask me why somebody asked me to sequence this… If you are using App-V, chances are you have licenses to use Microsoft Office already! But if you want to sequence this knock-off product, or want to just learn a cool trick that might help out with other apps, read on!

This one was coming up with an error on launch:


Procmon showed that it was trying to access (but could not find) the user profile of the account used to sequence it, even though it was not launched during sequencing, there was no appdata folder in the package, and there was no evidence of the user name stored anywhere that I could find. This is a prime example of why you should always use a different account to test the app than the one used to sequence it by the way!

My solution was to install the MSI under the System account during monitoring. The user profile for this account is stored under C:\Windows\System32\config\systemprofile, and with VFS Write enabled, users should not have a problem accessing this folder within the bubble. To do this I used Sysinternals tool PsExec to start a CMD prompt as System:

psexec -s -i cmd

Then install the software from within there.

Now the sequenced package works! I could not find it trying to write to the System profile during use, instead the application writes to %APPDATA%\LibreOffice as intended, but this little trick solved whatever was causing it to hiccup during launch previously.


Creating a Shortcut to an Exe in Another Package in a Connection Group

Written by Dan Gough. Posted in App-V v5.x


There are a few use cases where you might want to create a connection group that involves calling an executable from one package from a shortcut belonging to another package.

For example you could have an application with a bunch of shortcuts that call the same exe with different parameters to connect to different servers. Back in App-V 4.x, you might have employed one of the following methods:

  1. Use one package with multiple custom OSD files and deploy each one to its own AD group.
    We have UserConfig.xml files in App-V 5, but they do not offer the same level of flexibility. Each XML file can contain its own set of custom shortcuts; but the major drawback is that if a user belongs to more than one of the groups, the client does not know which UserConfig to apply so it applies none, instead using whatever the default settings are.
  2. Create a bunch of shortcut packages that DSC link to the main application.
    We could in theory do this with connection groups, but as this article demonstrates, the resulting shortcut does not work without resorting to workarounds.

In this example below, I will be using a very simple application, the terminal emulator PuTTY. I have created a sequence with putty.exe installed to C:\Program Files (x86)\PuTTY; I also have a custom shortcut that launches PuTTY with a parameter to connect to a server, which I want placed in a standalone package. The custom shortcut path is:

“C:\Program Files (x86)\PuTTY\putty.exe” telnet://nyancat.dakko.us

When this works this is what we should expect to see!


This shortcut was sequenced by simply selecting ‘Add-On or Plug-In’, expanding the PuTTY package, then creating the shortcut whilst monitoring. After publishing the package to the client, the shortcut has changed to show one of the following paths, depending on if it was published to the user or the machine:

%LOCALAPPDATA%\Microsoft\AppV\Client\Integration\<PackageID>\Root\VFS\ProgramFilesX86\PuTTY\PuTTY.exe telnet://nyancat.dakko.us

%ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\<PackageID>\Root\VFS\ProgramFilesX86\PuTTY\PuTTY.exe telnet://nyancat.dakko.us

The PackageID is from the shortcut package, which does not contain the exe, so the shortcuts are now pointing to a non-existent file. Putting both packages in a Connection Group does not update the shortcut either. When you launch it you will see the error below:

Missing Shortcut

So how can we get this to work in a Connection Group? To stop the App-V client from changing the path, we need to point the shortcut to an exe that already exists at publish time. There are two working solutions that I know of:

1. Recreate the App-V client paths on the sequencer and point the shortcut there instead.

There are three potential paths we could select, each with a unique drawback:

  • %LOCALAPPDATA%\Microsoft\AppV\Client\Integration\<PackageID>
    This path is only valid if the app is published to the user.
  • %ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\<PackageID>
    This path is only valid if the app is published globally.
  • %PROGRAMDATA%\App-V\<PackageID>\<VersionID>
    This path works for either publishing method, but the path is now dependent on the VersionID, so it’s more likely to change in future. Unless you are 100% sure that the app is only to be published either per-user or per-machine, this is the way to go.

To create the package, before you start sequencing, recreate the exact same path that you see on the client, on the sequencer. Then whilst monitoring, create the shortcut pointing to this path, e.g:

C:\ProgramData\App-V\<PackageID>\<VersionID>\Root\VFS\ProgramFilesX86\PuTTY\putty.exe telnet://nyancat.dakko.us

This method has some advantages and disadvantages:

  • If your shortcut package is a pure shortcut with no other files or registry entries required (as in this example), you don’t even need a Connection Group! The shortcut will launch PuTTY in its own virtual environment and with the necessary parameter to connect to the server.
  • The package containing the target exe must be published before the shortcut package, otherwise the shortcut will be created with a blank target path. If they are published in the wrong order, this can be remedied by repairing the shortcut package.
  • The shortcut package is dependent on the PackageID and perhaps the VersionID of the target package. If you had a lot of shortcuts, that’s a lot of work to update them if the target package is resequenced with a new version.

2. Use CMD.exe or a script to launch the application directly from Program Files

If you point your shortcut to some other middleman, such as cmd.exe, once it is up and running in the virtual environment it can see the original install path within the virtual file system. You could use a script to do this, but the simplest method is to just call cmd.exe directly like this:

C:\Windows\System32\cmd.exe /c START “” “C:\Program Files (x86)\PuTTY\putty.exe” telnet://nyancat.dakko.us

The double quotes are necessary after the START command to supply a blank window title if there are spaces in the paths that follow, this is just a peculiarity of cmd.exe. You should also change the icon of the shortcut to match the original exe, and you may also have to set the working directory to the application folder if the application requires it.

Crafting the shortcut in this way means it always needs to be put in a connection group. But there are no dependencies on the package GUIDs or installation order, making this the recommended method!


Powershell Scripts For Testing App-V Packages

Written by Dan Gough. Posted in App-V v5.x

I thought I’d share these as some of you may find them useful! When I am testing App-V packages, I generally either have them on a network share in one folder, or have copied them to my desktop, and want a simple way to add and remove them. These Powershell scripts do just this:

  • Add-AppvPackages.ps1 – Searches recursively for all .appv files under the same folder as the script, adds them (without config files), and publishes them globally.
  • Remove-AppvPackages.ps1 – Looks for all published App-V packages, and Stops/Repairs/Unpublishes/Removes any that have the path of the .appv file matching a package found under the same folder as the script.

Both scripts do these jobs in one line of code, even though that makes them harder to read! But then there are a few lines to relaunch the script with admin rights, which ruins my single-line elegance, but makes it much easier to use. For example, copy these scripts and a bunch of packages to your desktop, right-click the script and select Run with Powershell, and it will automatically prompt for elevation if you have UAC turned on (which you should).

Download them here.