App-V 5: Installing to the PVAD: Don’t do it . . . Yes . . . I said it.

Update 12/5/2014: The PVAD feature is now optional as of App-V 5.0 SP3. Also SP3 allows for merged roots with Connection Groups. Read more here: https://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden

If you have ever dealt with me directly as a customer, attended one of my presentations, or even simply stomached one of my diatribes in a casual, technical conversation, you have no doubt heard about one of my pet peeves (no, not “Tips –n- Tricks” – we’ll visit that another time) but the term “best practices.”

I loathe that term. I know we are guilty of it at Microsoft – so are just about every single technology-based organizations. In our ever-evolving industry, to put something down in print as THE ABSOLUTE BEST PRACTICES goes against the very nature of the word “practice.” It can seem arrogant. It implies way too much finality. It also can mean serious disruption when a practice changes. I work in a consulting practice. As products, regulations, politics, and trends change, so do our recommended practices. This is why I purposely try to use “under the current recommended practice” or simply just “current recommended practices.”

When it comes to recommended practices involving the sequencing of applications with App-V, I have been evolving my recommended practices particularly in the area of whether or not to use the PVAD. Specifically, whether to ever recommended to match the installation directory to the directory that was used for the Primary Virtual Application Directory. You may have also heard this as “Sequence to the PVAD, Install to the PVAD.”

Back in May, I expanded upon the subject of the PVAD and how it served as a placeholder for root-based files and directories (https://blogs.technet.com/b/gladiatormsft/archive/2014/05/24/app-v-5-on-sequencing-using-tokenized-paths-pvad-s-vfs-and-vfs-write-mode.aspx.) These differ from VFS-based resources (i.e. those beneath \root\vfs) in how the App-V 5 file system handles file operations. How you use the PVAD does have implications in terms of how:

• KNOWNFOLDERID’s always get translated to proper App-V Tokens
• Directories and Files get properly merged within Connection Groups
• Environment variables get properly translated
• VFS Write Mode is effective

Well after adjusting recommendations for App-V 5 regarding sequencing for connection groups, tokenization, and environment variables, I am now making the following recommendation to ensure that the above items always happens: It is best to always sequence with a fake PVAD which means create a false PVAD that will be different from the installation directory.

Now the next logical question would be: Are there any circumstances where this would create problems with newly sequenced virtual applications? I don’t think so. But I await your comments. :)

 

Update 12/5/2014: The PVAD feature is now optional as of App-V 5.0 SP3. Also SP3 allows for merged roots with Connection Groups. Read more here: https://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden

Comments

• Anonymous
  January 01, 2003
  Thanks for sharing.
• Anonymous
  January 01, 2003
  @Matt - the OneNote issue is still being looked at. Stay tuned. @others - thank you for the responses and I welcome others as well.
• Anonymous
  January 01, 2003
  Hi Steve,
  PVAD allows for installing to AppVPacakgeDrive and expanding out to the absolute value without tokenization.
  http://social.technet.microsoft.com/Forums/en-US/f7bc2cd8-ced5-498a-bc9d-637528e90874/appv-5-how-to-force-a-drive-letter-that-the-package-will-be-mounted-to?forum=mdopappv&prof=required
  
  Essentially, if my client machine has two drives (C:, D:) and I set the PackageInstallationRoot to D:AppV; AppVPackageDrive will expand to D:
  
  If I have an application that installs two folders to the root of C: while sequencing (C:Epic, C:CrashDumps) the variables are expanded out in the package to {APPVPACKAGEDRIVE}Epic and {APPVPACKAGEDRIVE}CrashDumps. Upon deployment to the client they are "virtualized" as D:Epic and D:CrashDumps. Since these values are hard coded in config files and the application itself to C: my application breaks. To avoid this I can force it to C: by making one of them the PVAD.
• Anonymous
  August 24, 2014
  Would you also follow this same approach with Office 2010 or any gotchas? ie Technet article suggests installing to PVAD. Curious if this might be why my OneNote protocol handler is failing (installed to C:OneNote2010 PVAD). Linkhttp://support.microsoft.com/kb/2830069
• Anonymous
  August 25, 2014
  I agree with the recommendation, however I have found a few exceptions to the rule! I have seen applications that either do not launch unless sequenced to the PVAD, or where the VFS write option doesn't work as expected, requiring the PVAD to set to a specific directory. I'll try and find the specific apps and write a blog post.
• Anonymous
  August 25, 2014
  Yes. I have found one or two that require PVAD install., but those are rare. More often, the app is OK UNTIL you add into a connection group. But there performance impacts also. Not too big of difference, but it is measurable (said by the guy who claimed Microsoft was all wet when they claimed performance differences in VFS performance in 4.X). Some differences are relative (VFS moves some overhead from Add to Publish) but file references for VFS are a little slower as most references require lookup in 2 places instead of 1.
• Anonymous
  August 25, 2014
  I have been using fakepath for PVAD as best practise for a while. You could always change to PVAD if needed. Applications seem to work more often with fakepath. Besides it wil cause less headaches if you want them to use them later in connectiongroups
• Anonymous
  June 30, 2015
  ~ John Behneman | Senior Support Escalation Engineer Hello everyone, John Behneman here again. I’d like
• Anonymous
  February 16, 2016
  The comment has been removed
• Anonymous
  February 16, 2016
  The comment has been removed