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:

http://social.technet.microsoft.com/Forums/en-US/251bae44-54d9-4295-a86b-09e2292c37e3/appv-50-sp2-hf4-registry-not-applying-when-set-via-dynamicconfigxml?forum=mdopappv

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:

NoBackgroundRegistryStaging REG_DWORD 0x1

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:

http://blogs.technet.com/b/gladiatormsft/archive/2013/09/25/app-v-on-registry-staging-and-how-it-can-affect-vdi-environments.aspx

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.

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:

Local Disk (D:)
IOPS     MB/s  Avg IO/s  Max IO latency  %CPU
1324.44  5.43  24.123    451.5146        0.50%

CIFS Share
2803.2  11.48  11.41     4878.02         3.96%

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:
Disk Start Finish Delta
Local D 15:58.0 16:10.7 00:12.7
Local D 16:10.9 16:17.1 00:06.2
Local D 16:17.2 16:23.4 00:06.3
Local D 16:23.5 16:29.6 00:06.1
Local D 16:29.7 16:35.9 00:06.2
Local D 16:36.0 16:42.1 00:06.1
Local D 16:42.2 16:48.2 00:06.1
Local D 16:48.3 16:54.5 00:06.2
Local D 16:54.6 17:01.5 00:06.9
Local D 17:01.5 17:07.6 00:06.1
Local D 17:07.7 17:13.7 00:06.1
Local D 17:13.8 17:20.3 00:06.5
Local D 17:20.3 17:26.4 00:06.1
Local D 17:26.5 17:32.5 00:06.0
Local D 17:32.5 17:38.1 00:05.5   //--speeds up here
Local D 17:38.1 17:41.7 00:03.5   \\--speeds up here
Local D 17:41.8 17:45.3 00:03.5
Local D 17:45.4 17:48.9 00:03.5
Local D 17:49.0 17:52.8 00:03.9
Local D 17:52.9 17:56.4 00:03.5
Local D 17:56.5 18:00.0 00:03.5
Local D 18:00.1 18:03.6 00:03.6
Local D 18:03.7 18:07.3 00:03.6
Local D 18:07.3 18:11.1 00:03.7
Local D 18:11.1 18:14.7 00:03.5
Local D 18:14.7 18:18.2 00:03.5
Local D 18:18.3 18:22.1 00:03.8
Local D 18:22.1 18:25.7 00:03.6
Local D 18:25.7 18:29.3 00:03.6
Local D 18:29.4 18:33.0 00:03.7

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.

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.
http://video.ch9.ms/sessions/teched/na/2013/WCA-B319.pptx

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.