Archive
App-V: On Current Recommended Practices and how they Evolve . . . (a.k.a. – about that PVAD)
This morning, I was on a joint webinar with Flexera (http://learn.flexerasoftware.com/AR-WBNR-Microsoft-AppV-Best-Practices) on App-V best practices and I reminded many on the call why I always prefer to use the term "current recommended practices" as opposed to "best practices." Today I explained that I know longer insist on avoiding the use of the PVAD (Primary Virtual Application Directory) and sticking to strictly VFS sequences. True, I did make this recommendation nearly a year and a half ago (http://blogs.technet.com/b/gladiatormsft/archive/2014/08/25/app-v-5-installing-to-the-pvad-don-t-do-it-yes-i-said-it.aspx ) however, at the time, App-V 5.0 Service Pack 2 required VFS sequencing to ensure connection group convergence as well as a few others mentioned in the blog post. With the addition of the merged roots feature as well as the correction of issues with the convergence of environment variables, there is no longer any major reason to force packages to VFS sequences for the purposes of making connection groups work.
Some Applications Need the PVAD for Proper Functionality
As App-V 5.0 SP3 was released over a year ago and App-V 5.1 was released a few months back, it has become known that due to issues with pathing limits and other issues related to the App-V VFS subsystem and its native NTFS integration, there are some applications which still require the use of the PVAD. By this, I mean to actually expose the Primary Virtual Application Directory (PVAD) within the App-V sequencer and selecting that same directory during the installation of the application during the monitoring phase of the sequencer. You will find many examples of applications within the App-V community. While the number of applications requiring the use of the PVAD is a relatively small percentage, the applications that are affected represent a significant footprint that involve nearly every major enterprise organization's application library. For example, Office 2010 is one of those applications. In fact, if you were to look at the virtual file system structure of the App-V package generated by the ODT (Office Deployment Tool) you would also find that the flattened Office 2013 and Office 2016 packages are actually PVAD sequences.
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: http://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 (http://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 rootvfs) 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: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden
App-V 5: On Sequencing Using Tokenized Paths, PVAD’s, VFS, and VFS Write Mode
Update 12/5/2014: The PVAD is now considered optional due to changes in App-V 5Service Pack 3. Read more here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden
When sequencing applications, you often never know how the application was written with regards to what paths are actually referenced via hard-coded paths or through tokenized, or well-known paths or KNOWNFOLDERIDS. In previous versions of App-V and Softgrid, these paths were referenced using %CSIDL% variables. These are well-documented on MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494(v=vs.85).aspx). If the application was developed to reference CSIDLs, they usually function when virtualized just fine with App-V. CSIDLs are still supported for backward compatibility, but going forward starting with App-V 5, a different tokenization process is used to align better with KNOWNFOLDERIDs. The new App-V Tokens and their default locations upon installations are well documented in the App-V 5 sequencing guide:
Tokenization helps to remove a specific application’s tie-in to specific folder paths and to allow for greater portability especially when these KNOWNFOLDERIDS have been redirected for specific configurations.
It is important to understand that for sequencing applications that will be used for Connection Groups or to better take advantage of the App-V 5.0 SP2 HF4 VFS Write Mode, all files will need to be located in the VFS structures. This will drastically affect the sequencing process.
Sequencing to a PVAD, Installing to the PVAD
If you specify a Primary Virtual Application Directory and then install to that same location, the base directory of installation files will not be tokenized. For many older applications, this may be the best route to take. For example, if the Primary Virtual Application Directory (PVAD) is specified as C:DIRECTORY1 and the sequencer monitors an install during sequencing to C:DIRECTORY1 then everything created beneath DIRECTORY1 goes beneath Root and will not be tokenized or located beneath the VFS folder. There may be additional files that do in fact get written to tokenized paths and they will be tokenized but you will now have a mixture of both “rooted” file assets and VFS file assets.
In the example below, Notepad ++ is sequenced to C:Notepad and installed to C:Notepad:
As you can see above, the majority of the files appear below the Root structure and are not contained with the VFS tokenized directories. Also notice the folders beneath Root cannot be adjusted for opacity:
When the files are deployed to the App-V immutable package cache, they will be laid out the same way.
In addition, in order to troubleshoot and navigate the file system within the bubble, non-VFS folders do not appear in directory listings.
You will be able to change to virtual directory by using cd Notepad+
Sequencing to the PVAD, Installing to Program Files or a Different Location other than the PVAD (Fake PVAD)
If you specify a PVAD and then install to a different location, all of the files will be written to the VFS location inside the package. For example, if the PVAD is C:DIRECTORY1 and the sequencer monitors an install to C:Program FilesDIRECTORY1 during sequencing, then everything gets put beneath RootVFS and root installation files will get tokenized if they are written to write to a KNOWNFOLDERID or CSIDL during installation.
In the example below, Notepad++ is sequenced using a fake PVAD and installed into C:Program Files
As you can see, all of the files are stored beneath the VFS directory structure.
When files are VFS’ed, you can see the directory listings as normal directories converged with the local directories when you launch a command inside the App-V bubble.
What About Using a KNOWNFOLDERID as the PVAD?
This question comes up quite a bit. Many packagers like to match PVAD with the installation directory (especially now that the Q: requirement is gone.) This is fine but understand that when you install to a PVAD during sequencing, all installation files beneath that folder that are not otherwise set to install to another explicit KNOWNFOLDERID or CSIDL path will be treated as rooted files.
For example, if you choose C:Program FilesDIRECTORY as the PVAD and the sequencer monitors an install to C:Program FilesDIRECTORY1 during sequencing, then most files will still be beneath root and NOT VFS except for tokenization of explicit KNOWNFOLDERID paths.
In the example below, when sequencing Notepad++, a PVAD of C:Program FilesNotepad++ is specified.
During the monitoring of the installation, notice the specified install directory is also C:Program FilesNotepad++.
Upon completion of sequencing, you will then notice that the package files are laid out just like any other PVAD-sequenced package.
The base installation files are located beneath Root.
Like the example earlier, when you open up a command prompt inside the bubble, you will not see the root directory in a directory listing.
However, you can still change to it manually inside the bubble.
So What about this VFS Write Mode?
For a lot of applications, especially older applications, they are written to use configuration files beneath the root of the installation directory. Natively installed applications often have to use shims to redirect these modifiable configuration files to safer directories. Combine this with the fact that most packagers are not always sure where to place the installation files in relationship to the PVAD (we cannot always read the minds of developers) and you can run into problems when virtualizing applications. While using shims is possible with virtualized applications, this can drastically increase the sequencing and remediation time for an application.
Enter VFS Write Mode. The App-V team added this “silver bullet” of a feature into HF4 of App-V 5 SP2. Using the advanced configuration options in sequencing, you can now select this option to enable an application to normally open files for modification within the package.
To demonstrate how this can be helpful, once again we will use Notepad++. When you install Notepad++, you have the option to load/write the configuration files from the install directory instead of using the %APPDATA% directory which would be properly tokenized.
Prior to the invention of VFS Write Mode, if you selected “Don’t use %APPDATA%” during sequencing, this is what would happen when you tried to run the program virtualized. First you would get an error message like this:
This would be followed by a crash.
When you troubleshoot the application with Process Monitor, you will notice a series of failures when trying to load the files:
In HF4, you can open up the package in the new sequencer, navigate to the “Advanced” tab, and check the box enabling VFS Write Mode.
As a result, Notepad++ will open and function as expected.
You will also notice in Process Monitor, the file operation to open the XML configuration files in the installation directory (with Read/Write/Delete) is successful.
The great thing about VFS Write Mode is that it can be enabled simply by opening up the package in the App-V 5 SP2 HF4 sequencer. You can now put this into your arsenal of App-V AppCompat secret weapons.
Update 12/5/2014: The PVAD is now considered optional due to changes in App-V 5 Service Pack 3. Read more here: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_pvad_hidden
Connection Group Case Study: Notepad++
Notepad++ uses plug-ins that register through a configuration file. This is one of the most common methods used by applications. Too often people run into problems because they order the primary application too high in the packages list inside the connection group. As a result, the configurations conflict with the one from the main package were overriding the one from the plug-in package. So to avoid this problem, and to allow more flexibility of deployment and connection group interaction, I will show you how I recommend you sequence these types of applications. I will be using Notepad++ as an example as it can fall into this same problem. My hope is that you can avoid this problem in the future with Notepad++ (and subsequently those applications that load plug-ins in the same style.)
For this example, I will be using Notepad ++ version 6.5.3 downloaded (from http://notepad-plus-plus.org/) Please bear in mind that Notepad updates very frequently although I do not think there will be drastic changes forthcoming in how the application manages its plug-ins. For the plug-ins, I will be using the following examples:
- TextFX: http://sourceforge.net/projects/npp-plugins/files/TextFX/NPPTextFX.v0.26.bin.zip/download
- XML Tools: http://sourceforge.net/projects/npp-plugins/files/XML%20Tools/Xml%20Tools%202.3.2%20r908%20Unicode%20Beta4/xmltools_2.3.2_r908_unicode_beta4.zip/download
These plug-ins differ as one of them actually requires overlays to the Notepad++ program files.
The Sequencing Process
Notepad++ uses a normal installation procedure. The installation is almost straight forward so the only adjustments I will make are:
1.) Sequence to a fake PVAD.
2.) I will then install Notepad to the %PROGRAMFILES% directory to get a tokenized VFS installation (using the VFSProgramFilesx86 directory.
3.) When I get to the “Components” dialog page, I disable updaters and for demonstration purposes, I do not select any plugins except the plug-in manager as I want to do all of this through connection groups.
4.) On the next page, I leave everything blank. If you check the box to “Don’t use %APPDATA%” you will run into problems with Notepad as it will try to open immutable assets for modification once virtualized. I will also be converging the main program directories for the plug-ins and I do not want to be loading plug-ins from the %AppData% folder.
5.) I will then sequence the application as normal opting to provide advanced customization so I can get to the tabbed, advanced package editor. Here, I will verify that the paths in the registry for Notepad are properly tokenized.
6.) Then I will go to the “Package Files” tab to perform two very important tasks.
7.) I will be changing the convergence settings for the ProgramFilesx86Notepad++plugins directory from “Override Local Directory” to “Merge with Local Directory.” This will change the color to grey.
8.) I will then save the package, copy it off, and then revert my sequencing machine. (PLEASE NOTE – I only mentioned particulars here that go outside the norm of sequencing. I am making an assumption that the reader is familiar with the basics of sequencing.)
Sequencing the Plug-in Package
Now that the primary application has been virtualized, I will need to reuse this package on the sequencer when it comes time to virtualize the plugins for Notepad++. I will copy the parent package to the reverted clean sequencer. In the case of these plug-ins – since they are DLL’s I have downloaded and extracted them into a staging directory on the sequencer as well.
Sequence as an Add-In
You will need to use the “Add-in or Plug-in” workflow as it will give you the opportunity to expand the virtualized package (Devirtualize) to the local machine so you can launch the parent application during sequencing to ensure that the plug-ins load and that the configuration will get registered properly and then stored inside the plug-in package.
In this example, I am pointing to my previous package I just sequenced and will be selecting this package as the primary parent application.
I then ensure that I do a custom installation so I can name my plugin package properly AND I will also use a fake PVAD to ensure that everything that gets captured goes to a VFS or tokenized path.
Once all of that is completed, I can proceed to install my plugins while the sequencer is monitoring. When I click the “run” button to proceed with the installation, I choose a command prompt (C:WindowsSystem32cmd.exe.)
Since these plug-ins are DLL’s I use xcopy to copy them over to the C:Program FilesNotepad++ directory.
Since I am still in the monitoring phase, I now want to ensure that the plug-ins get loaded and registered to automatically load through Notepad++’s plug-in manager. From that same command prompt, I launch the NOTEPAD++ application and verify the plug-ins are there from the plug-in manager. I see they are there:
I can now close Notepad, stop the command prompt and stop monitoring by checking that I have finished installing and clicking next. I will then click through and select the customize screens until I get to the final editing tabbed mode. You will notice that this way when you view the advanced editing Files tab the files are already set to merge and they are in the tokenized path. If they are not set to merge, you will want to make that adjustment.
Then save the Plug-in package and move it to a staging area with the parent application. You can now being testing. First add and publish both packages. Target should not matter so long as the connection group you create and enable matches the target of the packages it contains.
Once the packages are published you can create the CG XML document. The order in which you do this does not matter. If you wanted to create the document in advance of publishing, that is fine. I just use the published GUID paths in explorer easier for copying and pasting when I test. But your methods may differ according to your preferences.
In the CG XML document, you will notice that I have my plug-in package at the top of the package order. I then add and enable the connection group.
Once the connection group is enabled, I then launch Notepad++ and navigate to the plug-in manager where I find my plug-ins loaded properly.
More case studies to come.
On the Design of (and Sequencing for) Connection Groups
Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_cg_improvements after reading this article for the updates.
I constantly stress to my customers that significant assessment and planning revolving around the design and implementation of connection groups is essential to a successful lifecycle for virtual environments. One of the primary challenges with connection groups is that while understanding the mechanics of setting them up is quite easy; it is the sequencing thereof (as well as the understanding of how applications are affected by them) that is challenging.
I approach connection groups from a packaging and integration perspective. With that approach, I must plan out my strategy PRIOR to sequencing as retrofitting previous sequenced applications for connection groups can be quite risky and I recommend avoiding it.
Connection Group Architecture
I am not going to do too much diving into this point because there is already good information available. But a connection group is a virtual environment that contains more than one virtual package. All of the packages share the same virtual environment where the VFS and tokenized paths merge and the registries are converged. This gives sequencing engineers the flexibility to maintain packages independently and removes the redundancy of adding the same application several times onto a machine. Simple Concept. How about Execution?
Targeting
The first thing you need to reconcile will be targeting. Connection groups, like packages, can be targeted to users or to machines (globally published.) But targeting cannot overlap. All packages within a connection group must align. If a connection group target is per user, member packages must be published per user. If a connection group target is machine, member packages must be published to the machine.
Test Strategy
A connection group needs to be tested operationally and functionally by incorporating the connection group and package publishing life cycle into your QAUAT application testing. Creating Connection groups in stand-alone mode allows for more seamless testing. It can also be automated using PowerShell. The general flow for this is as follows:
- Add and Publish packages
- If possible, test the functionality of the individual applications.
- Manually create the connection group XML descriptor document (to be used in stand-alone testing to verify functionality independent of delivery system.)
- Add and Enable connection group
- Test applications
- Disable and Remove connection group
- Unpublish and Remove packages
The Easy Part – the CG Descriptor
Creating connection group descriptor documents is a pretty easy process. All you need to do is supply a unique GUID for the connection groups VersionID and AppConnectionGroupId. The packages PackageId and VersionId fields come from the packages themselves. You then list the individual packages under the <appv:Packages> element in order of convergence priority. When you create connection groups using the management server or through SCCM, you are simply automating this very process. For more detail on this descriptor document and the format, please refer to the following Technet article: http://technet.microsoft.com/en-us/library/jj870811.aspx
The Hard Part: Actual Sequencing for Connection Groups
The Technet article above also mentions supported scenarios for using connection groups. Connection Groups are great in that they facilitate the use of primary applications virtualized separately from plug-in or add-in applications to be brought together. You can also use connection groups to leverage run-times or middleware without having to package everything together creating a servicing nightmare. The use of converging primary applications with add-ins and plug-ins is one of the most desired use cases of connection groups – HOWEVER, they can be the most difficult to implement if you do not understand how the add-in is loaded and used by the application. This is important information because it will govern how you sequence the application.
Not Every Application Loads an Add-in the same way.
Each type of load method will govern how we sequence. In earlier blog posts, we even learned that Office Add-ins are even registered or loaded differently depending on the addin.
(See the following: http://blogs.technet.com/b/gladiatormsft/archive/2013/07/25/app-v-on-that-failed-office-add-in.aspx
Most add-ins load because they are registered to load. Some add-ins load because there’s a variable or a search path. In some cases, they load because the add-in simply exists in a special directory. Understanding how the plug-in or add-in loads (and it’s format) will affect how you engineer your 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:<PACKAGE_NAME> 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.
Registry Behavior across Connection Groups
Registry keys will merge across connection groups however the data and value overlap will be ruled by order within the connection group. To clear up potential issues with conflicts due to registry opacity configuration where key information may not resolve properly, I would consider placing virtualized plug-in/add-in information (where the add-ins were registered) ahead in the list inside the connection group descriptor document to ensure the right configuration wins out. This is especially important not only when it comes to add-ins but when it comes to VFS file convergence where you may have duplicate directories across multiple packages.
In the next few posts, I will discuss case studies on different types of applications.
Update 12/5/2014: There have been significant improvements to the behavior of Connection Groups including mixed targeting, optional membership, and version relaxation. Please refer to this document: http://technet.microsoft.com/en-us/library/dn858700.aspx#BKMK_cg_improvements after reading this article for the updates.
madvirtualizer
The Mad Virtualizer at Microsoft 