App-V 5: On Explaining this New VFS to Softgrid Users
There is an expression that is based upon a well-known book – “Who moved my cheese?” Ah, change – it can be hard. I will confess, there was a lot of "cheese moving" in the redevelopment of App-V 5 from my perception. I’ve
spoken about some areas where changes have been significant. I find myself doing a lot of explanation to Softgrid users. When I speak of Softgrid users, I speak of those who were brought up in what I now call the “legacy SFT world.” This was the world of the SFT file; the world of the SFTMIME and SFTTRAY commands; the troubleshooting of the SFT listener service and the SFTLOG file. This went all the way to App-V 4.6. It is still in use, still supported, and it will be here for a while. But as of App-V 5.0, that era is now starting down its road into the sunset. If you are looking to survey App-V for the first time, you should be looking into a modern solution: App-V 5 and beyond.
To continue on a point I alluded to earlier regarding change, I wrote an article on scripting several months back. Scripting was indeed an area where there was tremendous change. I felt it was needed as I was hearing numerous stories about “how scripting just doesn’t work in App-V 5.” What bothered me the most was that I was hearing this from experienced users of App-V 4. I laid down as best I could a guide for transitioning scripts from 4.x to 5.x. Not only were the mechanics different, but a lot of concepts had changed, because we now had more options. It was change. Change for the better.
With a new VFS, there are also changes, but the concepts are very similar. It is the implementation that is drastically different. I’ve noticed something interesting. With this new VFS, there is a huge desire to understand what has changed and what has not changed. There is also the assumption that since the way App-V handles file assets has been completely re-written, then all of the fundamental basics should be thrown out the window. Sometimes, one can get lost when there as an attempt to over complicate something. And believe me, I’ve read some over-complicated interpretations out there in the blogosphere. Fundamentally, at a high level there are no major differences. AppV uses a VFS to separate assets from their traditional locations as to not conflict with each other. The concept is not different from 4.x.
Isolation vs. Immutability and State Separation
Isolation implemented differently is still isolation and protection. Moving from a proprietary file system to one that uses native NTFS means that the way AppV “isolates” has to be implemented differently. If you ever look at the Server App-V product, you can actually see a mid-point in this evolutionary process where there was indeed, still a "Q drive" - yet the Q:\ drive yielded a human-readable file system. With App-V 5, there is a moving of these “Q:\
drive assets” or %SFT_MNT% assets into an overlay of file assets that are state separated where the base package remains immutable or read-only – just as the assets within %SFT_MNT% which were cached into an actual file called SFTFS.FSD in 4.x.
Advice for the Softgrid Users: Learn by aligning the concepts
Transitioning is easier when you can map where the concepts carry over. Then all that is needed is to focus on the details of transitioning how you would virtualize your applications in v5, especially those that required customization and advanced sequencing techniques.
SFT_MNT\PackageRoot vs. AppVPackageDrive\AppVPackageRoot
The package root in v4 (which we referred to as SFT_MNT due to the variable %SFT_MNT% reflecting the package root of an application) was laid down in the virtual environment as Q:\RootDir. Applications outside the virtual environment could not see this without special configuration. All cached assets went here in their own separate folders which would all actually be stored inside a read-only file system file called sftfs.fsd (by read-only, I mean immutable – the changes and modified files go somewhere else.) In V5, it is essentially the same. They are just laid down in human-readable file system assets. It is just not isolated. However, it is still read-only. It is still
immutable. This is why you cannot change anything – by anything we also mean permissions. When you add a package through PowerShell, or a package comes down on the ConfigurePackage function (using the publishing server) regardless of the target publishing, a “Package Root” is laid down with a series of shadow files and directories.
This will be in the PackageInstallationRoot configuration item which defaults to %PROGRAMDATA%\AppV but it can be redirected if needed by changing PackageInstallationRoot in HKLM\Software\Microsoft\AppV\Client\Streaming in the registry. Directories and markers will be laid down as well. These markers are actually shadow files. Do not confuse these with sparse files. Sparse files will be used if you are implementing the Shared Content Store. When you stream the package, the shadow files will become the streamed-to-disk assets. They will be immutable, or read-only. The integration components, including links and shortcuts, will not be laid down until the publish event has occurred. The integration link placement will depend on how the actual package has been targeted for publishing.
Targeted Publishing – A Difference
It is with publishing that things get different. The integration components (what serves as the target for linking the OS environment and ultimately the user) for this package will be placed in IntegrationRootUser if it is published to the user and IntegrationRootGlobal if it is published to the machine (globally.) These locations can also be controlled by setting those values in HKLM\Software\Microsoft\AppV\Client\Integration.
For those packages that are targeted to the user you will see the symbolic links to the package GUIDs under IntegrationRootUser which will reflect the beginnings of the user state data, the user mode VFS, and the elements that are allowed through the COW (copy-on-write-filter.) In essence, the data that would have normally be encapsulated inside of the PKG files in Softgrid. With user publishing, you will see here exclusively the publishing
integration elements which would normally be under %PROGRAMDATA%\Microsoft\AppV when they are published globally. Even with global publishing, the users will maintain settings for their user state within %LOCALAPPDATA%\Microsoft\AppV or IntegrationRootUser.
How AppV 5 Manages File-based user data vs. PKG’s
We used to call these PKG files. We use to have both user state data and global package data inside these PKG files. This data is managed differently in that they are no longer isolated into PKG files. AppV lays down these assets into human-readable files but everything is still state separated. But for the application, the virtual view is no different conceptually. The virtual view is the combination of namespaces in V5 just as it was in V4 (where the
virtual view was a combination of read-only immutable assets (within the FSD) and read-write global and user assets (within the PKG.)
Caching is now mounting
Which means, to pre-stream, or pre-mount, you simply run a “Mount-AppVClientpackage” cmdlet. Otherwise, the operation is similar in the mounting occurs on demand when you stream the application on first launch. Slowly, as the files are fully downloaded, the shadow files become fully cached files. The icons switch back to a normal icon in the PackageInstallationRoot. THAT IS – if you are using the traditional “stream-to-disk” process. If you are
implementing the Shared Content Store or “stream-to-memory” you will not be caching 85-90% of the file system assets. Those sparse files remain as such in the PackageInstallationRoot. NOTE: If you run the Mount-AppVClientPackage even in shared content store mode, it will fully cache those files to disk.
Now Why Can’t I set ACL’s on the Package Files beneath PackageInstallationRoot?
Applying permissions to the files and directories beneath PackageInstallationRoot is not possible because, as I mentioned, earlier, these files are read-only and that also includes the extended attributes. You can however set permissions on folders and files located in the user mode VFS located beneath IntegrationRootUser (which itself is beneath %LOCALAPPDATA%.) Pre-staging these permissions does require some work. Some in the community
have come up with great ideas. I like the script by Dan Gough in particular (located here: https://packageology.com/2013/06/file-permissions-app-v-5/) The reason why it has to be done this way is due to the new way in which file
assets are implemented using native NTFS instead of the previous methods.
Conclusion
Change can be hard. But not so much if all you are having to do is learn new technique. Conceptually, not a lot has changed but because Windows as a whole is evolving, applications and application formats are modernizing,
it is important that App-V evolves as well as a key tool for that modernization. This means that certain things may change when it comes to minor elements such as permissions. In a later post, I will dive further into the intricacies of how files are handled and how this understanding can help us troubleshoot when needed.
I sense the comments will come in 3 . . . 2 . . . 1 . . .
Comments
Anonymous
January 01, 2003
Stay tuned for something exciting related to this.Anonymous
November 04, 2013
Can we have the ability to set permissions in the App-V Sequencer, please? :-) You knew that was coming!Anonymous
November 04, 2013
Less than 15 minutes too . . . ;)Anonymous
November 05, 2013
Small precision: %SFT_MNT% is the virtual drive letter only, so the package root is actually %SFT_MNT%PackageRoot (and used to have the 8.3 folder format). Apart from that: Great article! :-)Anonymous
November 05, 2013
Corrected, thanks for the heads-up.