Updating AppV 5 package files without resequencing

/ / /

With AppV 5.0 HF4 you can update the files inside a package without having to go through resequencing.  The only catch is you have to prestage the file you want to replace/update first in the location you want, and I don’t think you can update files in the PVAD, only VFS.

To update a file in a .appv package, open the .appv in the sequencer and select the “Edit Package” option and click “Next”.

Click “Edit”

Expand the path to the file you want to update and right-click and select “Delete”.

Right-click the folder above and select “Add”

Browse to the file, select it, click “Open”.

Click “OK” to make a new VFS mapping.  Choose File > Save and save your package.

If you have the original package and rename it to .zip from .appv and get properties on your file, and do the same on your new version of the package (after making a copy of it) you should see that they are different and you have a new file in the new version without having to “Update” the package; avoiding capturing additional garbage that happens when you update an application.

Read More

AppV 5 – Formatted volume allocation size matters

/ / /

After discovering that AppV 5 configures an allocation size independent of the file system beneath it, I explored the impact of different formatted allocation sizes on AppV packages; specifically mounting AppV packages.

I took our AppV setup and set the PackageInstallationRoot to D:AppVDataPackageInstallationRoot and then formatted the D: to different allocation sizes and then mounted the AppV package.  I timed how long it took to mount the package over 4 runs per allocation choice, took the AppV file size allocation, and the total, actual size of the package on the drive.  Package Details:

The results:

Different Allocation Sizes


Actual Used Space vs. Allocation size


Actual AppV 5 file allocation size vs. formatted allocation size


AppV 5 Mount Time vs. formatted allocation size

I would propose using 64KB allocation sizes for the AppV volume if possible (note, this only applies to fully mounted packages).  There does appear to be some benefit to using larger allocation sizes, one of the main ones is the properties of the PackageInstallationRoot now reflects more accurately the actual consumed filesystem on Windows 2008 / Windows 7.  Another is there is a speed improvement around the 4KB allocation size then minor increases afterwards.

Read More

AppV 5 – changing PackageInstallationRoot impacts AppVPackageDrive variable

/ / /

I just sequenced an application (Epic) and it puts two folders on the root of the C drive.  C:\Epic and C:\Crashdumps.  When I published the application to our Citrix servers the application failed to launch.  Procmon’ing it I saw that Epic was unable to find C:\Epic.  I opened a command prompt and tried to cd /d C:\Epic which failed.  On a hunch I tried cd /d D:\Epic and lo and behold it was successful and I was put in that folder.  I investigated this and created a package with two folders on the root of the C:\.  They were C:\test and C:\test_happy_folder.  When I published the package on our Citrix servers I could not cd into them on the C:\ drive but I could because they were on the D:\ drive.  Examining the package it showed:

Why was it going to D:?  We have our servers setup so that the PackageInstallationRoot registry key points to the D:.


When I changed PackageInstallationRoot to be C:\AppVData\PackageInstallationRoot I could then cd /d C:\Epic without issue.  This is unfortunate but I do not think this was the expected behaviour because we sequence to C:.  To fix this I set the PVAD to C:\Crashdumps (which does expand out to the C: when specified in the sequencer, not the D:) and moved the C:\Epic folder to within a tokenized folder (programfiles\Epic) which correctly expands out to C:\Program Files\Epic.  I then needed to hunt down all config files and scripts that point to C:\Epic and update them to point to C:\Program Files\Epic.  Unfortunately, I do not know of a way to modify AppVPackageDrive to a drive letter without changing PackageInstallationRoot because I would love for my sequenced applications to stick to C:\ so I don’t need to do any workarounds.

Essentially, I guess what I’m saying is I hope AppV 5, sometime in the future, allows you to either hard code the AppVPackageDrive variable to a specific drive letter, or use some other tokenized variable that points to a specific drive letter ({CDrive},{DDrive},{EDrive},{FDrive}, etc.)

Read More

AppV 5 – minimum mounted file size is 64KB, size of packages is misrepresented on 2008R2/Windows 7

/ /
in Blog

Our current configuration for our Citrix environment utilizes AppV 5 and mounts the packages to a different drive letter.  Our Citrix servers have the OS on C:\ and we changed the packageinstallationroot to D:\AppVData\PackageInstallationRoot and do full mounts of our AppV packages.  What we found is we have some packages consuming significantly more space then their extracted size would dictate.  I worked with Microsoft premier support to try and determine why, finally, after flaying for several months on why I finally got a reason and how we can avoid package bloat.

First the problem.  We have several packages that their total size should be less than the disk space it is consuming on our D:\.  We started running out of disk space earlier than anticipated so we investigated.

We packaged VMWare vSphere Client and included multiple versions of vSphere that maximizes the ability to connect to the servers/vCenter versions while minimizing the number of vSphere clients in the package.  In total, we sequenced 3 vSphere installs in one package.  The total package size is:


When we rename the .appv to .zip and extract the package the total size is:

1.71GB on the AppVData for the extracted file.  1.83GB used space on disk.

But, when we mount the .appv package using AppV the total size is:

1.71GB on the AppVData folder, but 2.25GB used space on disk.  A discrepancy of ~400MB.  With 10 packages that could be 4GB of wasted space across 60 Citrix servers it adds up fast.

So…  Where is this missing space and why does AppVData not report it correctly?  Well… it turns out it does report the used space correctly in Windows 8 / 2012.  The AppVData folder for the mounted application actually shows that it’s 2.2GB when mounted on a Windows 8 / 2012 box.  Why the difference?  It turns out that when Appv 5 mounts applications it is mounting them using a 64KB allocation size.  In Windows 8 / 2012 when you get properties on a file in the mounted package it shows that it’s 64KB used on disk.  On Windows 2008 / 7 it shows the file size used on disk, then it goes to the allocation size:

Windows 2008 / 7 file sizes are incorrect for mounted packages

If we delete a file under 64KB we will actually free up 64KB of space and Windows 2008 reports that correctly:

19,045,400,576 bytes free before the 2,951 byte file is deleted, 19,045,466,112 bytes after.

19045400576 – 19045466112 = 65536 bytes.

So, in the end, it turns out that AppV 5 utilizes 64KB cluster size even if the allocation size on the disk is 4KB.  I’m not sure if having mismatched cluster sizes impacts the performance of AppV but the Microsoft support personnel implied that it could.  For AppV 5 you’ll want to reduce the number of small files in your AppV packages to as few as possible to limit this space sucking overhead.  The missing space is “sparse” files, but fully mounted I wouldn’t expect to have any sparse files.  So AppV is using sparse files to ensure a 64kb allocation size.


Read More

AppV 5 – Short file names are not created after publishing a new version of an application

/ / /



Our AppV packages are loaded on Citrix PVS servers.  The PVS server is clean, and on each restart (restarts once a day) it will contact a AppV publishing server and pull down and mount the packages.
We have an application that makes file system calls in the 8.3 space (awesome, I know).  When launching the application I can see a trace of it hitting 8.3 name spaces (via Procmon) and the application works without issue.  So, we required a tweak to the package, I added to the management server, published the application and refreshed on the AppV Client, saw the new package get loaded and ran the application.  Only now when I trace via Procmon.exe I can see that it’s using Long File Names instead of the 8.3 name space and the program errors out because it’s trying to find a .exe with the short name.  I can confirm the original published package has the 8.3 namespace via dir /x and the new version does NOT.
8 dot 3 is enabled for the volume
8 dot 3 exists for folders but not files…
In the image above, the version 1E65…… was published to the server first and EE168…. is the new version published later in the day.
I have VFS folders in this package and 8.3 names are not created for the new package either.  :/
While attempting to create a 8.3 file name manually I got a NAME COLLISION and a failure to create it(?)
So it appears if you have an application that does not properly support LFN (Long File Names) then it may not operate correctly if you update an AppV package, at least until the next restart (for some reason for us it creates the LFN after that).
Read More

AppV 5 – .NetFramework applications that only work with 32bit .NetFramework architecture

/ / /

I encountered an issue with an application of ours that refused to launch on Windows 2008 R2 SP2 but worked on Windows 2003 R2.  I did a procmon.exe trace and noticed some discrepancies in the trace results:

^^ 2008 R2 SP2 (non-working application launches)

^^ 2003 R2 (working application launches)

So, my application was defaulting to the .NetFramework64 architecture and no launching.  To correct this I was able to run this command:

If you have a 64 bit machine and want to run a .NET application that only works with the 32 bit CLR you would have to make changes to the .NET framework on your machine
Set the .NET framework to load the CLR in WOW mode through this command
Open up command prompt and type this command
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe SetWow
Now you should be able to run apps that use only the .NET 32 bit CLR.
To revert back to the default 64 bit framework run
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe Set64
It appears all this does is modify one registry key:
REG_DWORD Enable64bit
DATA 0x0 (for SetWow) 0x1 (for Set64)
Alternatively, run corflags.exe against your executable to force it only utilize the 32bit .NetFramework.  Corflags.exe can be gotten from the “.NET Framework 2.0 Software Development Kit (SDK) (x64)
Execute the application with the following:

“c:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\CorFlags.exe” MyApplication.exe /32bit+

After doing so your application should only use the 32bit .NetFramework.  And, if you are in my scenario, the app now works without issue.


It appears the following registry key is for status only:

REG_DWORD Enable64bit
DATA 0x0 (for SetWow) 0x1 (for Set64)

It does not actually do anything configuration-wise. Changing this key does not manipulate the ability to .NetFramework to use 32bit or 64bit.

Read More

AppV 5 registry keys not applying when set in DynamicConfiguration.xml

/ / /

I recently ran into an issue with AppV 5 and it not applying registry keys/values I set in the DynamicConfiguration.xml file. Everything else seemed to be applying without issue in the XML file, scripts I added, shortcuts manipulated, just not registry values. I created a thread at Microsoft’s support forum here:

We even had a PFE on site who was unable to determine the cause. Eventually, I did a clean, generic, click-click install of the AppV client on a non-domain system (to exclude GPO’s). I manually copied the .appv and .xml over and added/mounted/published the package via powershell with the dynamicconfiguration.xml and I saw my missing registry keys! hurray!

I then took the registry values from our non-working system and compared them to the working system. Adding in keys from the non-working system to the working system until it failed I came across the following culprit:

When that value was set to 0x1 the registry keys from the dynamic xml file would not apply. If it was deleted or set to 0x0 then the keys applied without issue. I had originally added this key from this article:

But it appears that article didn’t specify the full impact of adding this key. Steve noticed that CPU utilization was lower when publishing applications with this key set, but it appears that could be because XML processing on the dynamicconfig.xml isn’t happening. Because of this removal of this great feature to add keys after package creation I would recommend removing the NoBackgroundRegistryStaging key.

Notice the Foo and EmptyKey. Those keys are set via the dynamic.xml fle.

Read More

AppV 5 Shared Content Store performance profiled vs. local disk

/ / /

We are looking to utilize AppV 5’s shared content store and one of the things I was interested in was knowing what kind of overhead network performance may vs. local disk.  What I have is a physical server with 3x300GB 10,000 RPM SAS drives in a RAID-5 vs. a CIFS share on SSD.  The catch about the CIFS share is it is 300 kilometers (200 miles) away in another city.  I used this share as I don’t have another share local to the physical box and this brings the performance of the share down, but it’s still faster than the disk.  The IOMETER readings for the Shared Content Store and the local disk hosting the PackageInstallationRoot are:


IOMeter settings was 100% read with 4k transfer sizes

The CIFS share is 2x faster on average, pulling 2803 IOPS vs 1324.  Bandwidth of the CIFS share is faster as well, 11.48MB/s vs. 5.43MB/s for the local disk.

To test the performance I did the following, I loaded an AppV 5 application to disk, I then wrote a AutoIT script to get the start time, launch the program, wait for the login screen, once the login screen is visible get the finish time.  I then stopped and started the appvclient as this ensures nothing is cached in RAM and ran the AutoIT script again.  I did this thirty times.  I then turned on Shared Content Store (SCS) and loaded the package in that manner and retested.  The results are (average of all 30 runs):

Local Disk: 9.6s
SCS: 9.7s

For the 30 runs the Local Disk deviated +/- 0.2s from average so the range was from 9.4s to 9.8s.

For the SCS the deviation was much bigger, probably to be expected when you’re pulling from a file share 6ms away across a shared pipe.  Deviation on the network was:
+/- 1.85s with a range from 8.2s to 11.9s.  Amazingly, there were numerous runs where the network bested the local disk under 9.4s for launch time.  I’m sure if the SCS was local we’d get even more consistent performance and probably even faster performance.  A local server to the share gets about 8x better IOMeter numbers.

Now, how about when the application has already been launched so files are cached?  Results (average of all 30 runs):

Local Disk: 4.8s
SCS: 4.8s

Local Disk deviation/range: +/- 1.4s, range 3.5-6.3s
SCS deviation/range: +/- 1.85s, range 3.4s-7.1s

Again, the SCS has a bigger range but again pulls ahead of the local disk numerous times.

A curious thing I found was that after the 14th run in the loop the times improved greatly:

I’m not sure if that’s the application or AppV has a caching structure but I’m leading towards AppV/Windows doing something with the file cache.  I’m unsure how to prove this out.

Read More

PVAD, Connection Groups, AppV 5

/ / /

With AppV 5 and connection groups, a lesson I learned today is if you want to utilize connection groups you cannot use a valid PVAD path as the PVAD will not merge with VFS or another package’s PVAD.  So for any application you plan on using Add-on’s or Middleware you MUST set the PVAD to something that is not used and install to the VFS for both the base package and the Add-on/middleware.  If you use a PVAD what ends up happening is one of the packages in the connection group will “win” and be the only thing you see when you browse the PVAD path.

In the instance of this error I found, we sequenced VMWare and I wanted to add the VMware Update Manager as a add-on/plugin to the package.  I used the same PVAD for both packages initially, “C:\Program Files (x86)\VMware” and when I published each seperately to a server I saw the proper file structure for each, when I made a connection group and published both to a single server and browsed to that PVAD I only saw the contents of one of the package, not the combination of both.  I then resequenced the Add-on with a VFS path and it usurped the PVAD as it was not accessible nor the file systems merge.

I found one little blurb about this on WCA-8139.pptx on slide 38: PVAD is not merged in Connection Groups.

There is also a small blurb here detailing that you should not install to PVAD if you plan on using Connection Groups.

“File Convergence

Only VFS Folders and tokenized paths merge. Pure and simple. If you suspect you will use an application or a plug-in within a connection group, you will need to sequence your application a specific way when it comes to selecting a PVAD (Primary Virtual Application Directory) and an installation directory. Unlike the former DSC (Dynamic Suite Composition) where the opposite was true, non-VFS folders do NOT merge. You will need to fully VFS the packages, that is, provide incorrect ‘Primary Virtual Application Path’ (PVAD) while sequencing the packages. This puts all the files of the package under VFS folder and nothing ends up in the root folder. For example, use C: as the PVAD and install to its regular tokenized path (i.e. C:\Program Files, etc.) If the application does not normally install to a tokenized path, make sure you install to a different folder then the PVAD.”

It’s also important to note that registry keys will merge even if the underlying filesystem does not.  This can make for some interesting customizations in applications that can be changed by registry only.  You could publish the application to a generic group of users and then have two connection groups with two different packages and the difference between the packages is some registry keys that does something like change the server depending on the groups user location.  This way a single package can serve multiple roles.

Read More

Microsoft Disable-AppvClient.ps1

/ / /

Microsoft has noticed that AppV 5 sometimes has trouble cleaning up after itself and it looks like Microsoft has made a cleanup powershell script for AppV5.  It is located here:
C:\Program Files\Microsoft Application Virtualization\Client

The command needs to be executed like so:

This powershell script will also inform you if you need to remove the packages manually because of permissions issues.  I would highly recommend putting it in the shutdown script of your servers/desktops.

Read More