While I continue to try to get a better grip on connection groups, let’s continue documenting some of the side issues I have come across. Today, I’ll focus on a single package and either want to block visibility of a potential local installation or need to allow visibility of something local, like a license file.
In attempting to work solutions to these challenges, I noticed a few things in 5.0 SP2 that need to be written down somewhere. Here are a collection of things involving the file system.
Single package oddities of the File System kind:
- In the sequencer editor, you cannot change the Pellucidity setting (“merge with local” versus “override local”) on folders that are under the Root (aka “Primary Virtual Application Directory”, or PVAD) folder, only those that are in the VFS area.
- The visual indication of this setting as shown in the sequencer for folders under the PVAD cases (the ones where you can’t change the settings anyway) are sometimes wrong. They may appear as grey (normally meaning “Merge with Local”), or yellow (normally meaning “Override local”), however the color does not appear to affect the implementation at the client for those PVAD folders. In a typical package (where all folders are created while monitoring) is seems that the Root is grey, direct subfolders are yellow, and subsequent subfolders are grey. But the implementation at the client depends on how the reference is made and has nothing to do with the color of the folders above.
- By contrast, you can change the Pellucidity settings when VFS style installs are used, and the display is accurate.
- By default, an executable in the package with a shortcut is launched at the client using a current working directory under the ProgramData/AppV folder so the merge/override setting is not applicable as the client cannot have any local files in those locations. But if the program looks for files using a reference of the original PVAD folder, the client has a virtual junction point pointing to the ProgramData location, allowing local files under a real local PVAD folder to be seen, and all of the PVAD folders then act like merge-with-local (no matter what color is showing).
- Pre-creating the PVAD folders in advance of sequencing affects the display, but not the client implementation one iota.
- In the file system tab of the sequencer editor, you can only add a file, not a folder.
- In the file system tab, you can only add a file that is currently on the same disk partition as your package, but not present in the PVAD area. Which means it ends up in the VFS area.
- Once a file is added this way, you can then edit the file mapping to change the mapping to a PVAD location to get the placement you want, including naming a new sub-folder not currently present in the PVAD. If desired, you can then remove the added file from the tab, leaving the folder you created. [EDIT: I always recommend making such a change by adding the file during monitoring mode of the sequencer rather than in the editor whenever possible; we tend to have issues with “losing” these kinds of edits if the package is upgraded in the future.] In the image below, FolderUpdateC and file FileUCA.txt were added this way.
- For the file system, you can add deletion markers, which hide visibility of a potential client entity. But it only works at the folder level, not the file level. Furthermore, these markers do not show in the Sequencer Editor. (To mark a folder as deleted, pre-create the folder prior to sequencing, then delete the folder while in installation monitoring mode).
- Folders in the VFS have default settings just like App-V 4.*. If created new during monitoring, they are marked override local, otherwise marked merge with local. Client testing results, however, are affected by reference. The default publishing for the shortcut will actually be to a ProgramData/App-V/guid/guid/Root/VFS folder, meaning that the effect is override local. If the app references the original location (like C:\Program Files\vendor) then the results will either be merge or override depending on the package setting.
- When you have multiple level folders, walking down from the root, as soon as a folder is marked for Override, all subsequent sub-folders act as override (even when marked merge) because the app can’t see client files past the first Override. This is nothing new, but everyone needs a reminder now and then.
- For shortcuts, you can change the working directory. This is done by editing the deploymentconfig file. By changing the working directory back to where the app was installed to, you can gain merge with local capability.
- Unfortunately, there does not seem to be a way to get FTA and protocol handler launches to have an altered working directory.
- Junction Points may be included in your package. This makes another way to pop in an external license file.
Multi-package oddities of the File System kind:
- If you have several packages in a group that contain reference the same VFS folder, all must mark the folder as merge-with-local if you want the app to be able to see any additional files and sub-folders that are present at the client.
- Conversely, if any one or more of the group packages have the VFS folder marked with the override-local setting enabled, you will not be able to see the client files/subfolders. It does not matter which of the packages has this setting (primary or plug-in), nor in what position the override set package is placed in the group ordering.
- And to finish off the connection group with one VFS folder marked override-local scenario, setting override-local on any of the connection group packages has NO effect on the ability to see all of the plug-in files under that folder no matter what order is used in the group. This means that you can always see all of the files from every package in the group as long as the folder is in the VFS and is being referenced by the original path reference.
As I said, not like 4.* at all. And that last item on the list gives me some hope that it might be possible to get more plug-ins to work in connection groups. But it isn’t simple. Controlling the reference used by the app is a hack that can be applied in some cases and not possible in others. And VFS installs sometimes don’t work for some packages at all. Shortcuts seem to only be able to point to real exe files, not to other shortcuts or symlinks. You can affect the current working directory of a shortcut, but not for file type associations. And I have some PVAD cases where the presence of a client folder seems to affect plug-in visibility that I have yet to document.
So while I continue to pound away at some of those, let’s just stop here and summarize what we can do with a single package and potentially stuff at the client layer.
Blocking Visibility
When you want to block visibility of a potentially locally installed native version of an app, we need to consider both the registry and the file system.
The file system is most easily handled by making sure that you don’t install to the same place that the native app will be. This eliminates all forms of file conflict no matter if you install to a unique folder, either in the PVAD, or VFS’d, just don’t specify the PVAD as under Program Files and don’t install it to Program Files either when you sequence it. It also eliminates visibility to natively installed files for the same app no mater how the app references the file locations (assuming it doesn’t pick up an old registry reference pointing it there).
The Registry lacks some of the File System complications, and when sequencing acts like a VFS in that Pellucidity is correctly marked based on new or pre-existing keys. And you can always change the setting on the keys. However, it does not allow you to install to a different registry location, so it is important to ensure that the top level vendor key (in both HKLM and HKCU) is marked “override local” when you need to block.
There can be other issues causing you to do more to fully block. Java is a great example, and Aaron Parker (stealthpuppy.com) has a blog that shows the basic technique of adding Registry Key deletion markers to the package (the blog post is for App-V 4.5, but other than your need to add in newer Java version references it should be sufficient for you). And Dan Gough (packageology.com) is in process of posting a three part series on Java and App-V 5 as I write this.
Blocking Visibility with (limited) Client file access
Let’s say you want to have a package that needs to reference a license file, but you want to block visibility to the other version.
Start by installing the software in your package to somewhere other than the normal Program Files area. I like to use a PVAD of a folder directly under C:\ that is the package name. So install to there. Or if you want a VFS style installation, name the PAD as C:\PackageName.PVAD and install to C:\PackageName. The latter, while not recommended by Microsoft, gives you the flexibility to customize all of the folder Pellucidity settings (and usually works anyway).
The situation with the registry is the same as before. The right keys should be set to override automatically, but if not you may change them.
To make the license file visible, you might try one of several approaches:
- Get the file coped to inside the virtual environment at the client. This would entail a StartVE script to copy the license file to the PVAD referenced folder location, which would then be redirected to the users application related data area. Currently, this only works if the package was a PVAD installation and not a VFS one (hopefully this might change some day). You probably want to copy a file from the user’s home drive share folder, so you may need my ScriptLauncher tool to make this work.
- Add a junction point inside the package for the license file, pointing to somewhere outside the package. The target location should probably be on the client machine (to avoid having to enable local-to-remote link following), ideally in the user’s appdata roaming folder. Because the reference will be done under the user credentials, this can work.
- Change DynamicConfig.xml as follows.
a) Locate and modify the current working directory of the application shortcut. For example, from
to this
Note that you change the to reference the folder as C:\PackageName\…. You don’t want to set it as [{AppVPackageDrive}]\PackageName but actually as C:\PackageName (the former would become C:\ProgramData\App-V\guild\guid\Root\VFS\AppVPackageDrive ). This is another reason not to install the application to C:\Program Files vendorname in your package; you would have to hard code a reference either C:\Program Files or C:\Program Files (x86) for the working directory and your package would only work on one architecture.
b) Add an AddPackage script to create the base folder on the client system as an external folder (see example at the bottom of this post),
c)Create an SCCM job to copy the file locally, or add a StartVE script to copy the file (and don’t let your users become admins).
