An anatomy of one %SFT_ALLUSERS_DIR% variable…

I recently got the inquiry from Sebastian Gernert, Microsoft’s App-V support engineer from Germany, about the way AVE displays certain App-V variable, %SFT_ALLUSERS_DIR%. Since this whole thing might be of interest to others as well (along with the original customer who was relaying this query through Sebastian), I thought to write up about it here.

To give a little bit background, the problem someone was facing was that there were some VFS folders in an App-V package originating from Windows XP Sequencer, which had %SFT_ALLUSERS_DIR% as an App-V mapping variable for the target folder inside VFS configuration. When looking at this package with AVE, it gets resolved to C:\ProgramData but when App-V Client actually executes the package, all the content is actually shown through C:\Users\All Users! So why the disparency and from where it comes from?

To illustrate the issue let’s concoct a little test package with only one VFS mapping in it that points to the “problematic” folder. Add new base folder to the package using AVE (this adds empty directory with any arbitrary mapping we would like):

As a next step for creating a new arbitrary VFS folder, we add one mapping entry manually that will be attached to this new folder:

We specify the mapping manually instead of browsing an existing folder + enable Encoded checkbox so that App-V will know that our path contains those “special” variables. Otherwise the text in Virtualized Path will be taken literally by the client:

After accepting changes and closing the VFS mapping editor, let’s rename the folder itself to better conform to how App-V names VFS directories (i.e. using name of the variable, but without percent –signs in it):

After renaming, we leave the state of the VFS folder as fully virtualized since that makes it easier for us to see the effect on a client (i.e. excluding away all the other content from our target directory we are not interested about in this case). If we now go to AVE’s View –menu, and enable Resolve VFS targets –option, we can already see that AVE converts %SFT_ALLUSERS_DIR% variable as C:\ProgramData:

All right, with the folder in place let’s then add one empty file into the mix so that we can really see where our file will appear when run with the App-V Client:

Now we have one file, named New File 1, which should appear wherever the App-V Client chooses to virtualize our directory to. According to AVE, this would be C:\ProgramData\New File 1:

One final touch to our test package is to add Windows Explorer as an application we start from the package, so that we roam around and see how the application would see the world according to the package’s VE:

After saving the package and importing it to the App-V Client, we can start our Explorer instance into the “bubble”.

Launching the app, we can see that, indeed, the file is not visible over C:\ProgramData nor it is fully virtualized (i.e. masking all local files and folder inside it)…

Then looking at the C:\Users\All users we can see that the file is really over there as reported and what’s more baffling, this folder has not had its other files and directories masked away like fully virtualized flag should indicate!

So it does look like the %SFT_ALLUSERS_DIR% target mapping resolves to c:\Users\All Users –directory, but what was the whole deal with that All Users directory in Windows 7 after all?

You see, when I originally started to investigate on this issue when Sebastian was kind enough to report it to us, I immediately wondered about the fact that I had not really noticed any folder named All Users inside C:\Users, at least since moving into new profile layout starting from Windows Vista (it existed during the first iteration of profile folders up to XP/2003). Remembering the fact that during transition of these folders Microsoft did some app compat foo for making sure that older application (ones having hard-coded paths inside them) would still work; I took a second look at the C:\Users directory from the command prompt more closely.

Seeing no All Users present or listed there, I then listed all the hidden folder instead (dir /a:h):

And sure enough, there it was but not as a real directory but rather as a directory symlink version pointing to … C:\ProgramData! So as I had remembered, there isn’t any real c:\Users\All Users –directory or profile anymore but rather it is just simply a pointer to actual storage location for application data that is common to all users on a machine.

What makes this interesting is that while obviously App-V Client’s variable %SFT_ALLUSERS_DIR% has originally been defined as pointing to C:\Users\All Users -directory, it looks like it is not tied to what is the actual, correct, filesystem location for that type of data. Since the customer – who had this whole confusion over what AVE shows and what App-V in reality does – had packaged the App-V package in question on a XP machine it naturally converted references to files added to C:\Users\All Users to %SFT_ALLUSERS_DIR%.

Development of VFS was of course done during the time of Windows NT 4 / Windows 2000, and that directory or profile was the actual location to be represented by our variable back then; just that it is not anymore…

Sebastian also mentioned that on Windows 7 they don’t have variable for c:\Users\All Users –directory anymore (while not explicitly said so, I understand that remark to mean that the %SFT_ALLUSERS_DIR% won’t be used by the Sequencer anymore on Win7 platform as a mapping target), which is quite understandable since all the changes made by the application installer against that location would also be shown through C:\ProgramData as well to the Sequencer.

So in the end, this “issue” really only affects package coming from XP/2003 and trying to view them with AVE on Windows 7. Something to be aware of at this time and maybe we will add special handling for that variable for viewing purposes on post-XP era platforms so that the confusion would not be there anymore.

On the other hand, what’s also really interesting to me is why MS didn’t just simply re-point the variable inside App-V Client to C:\ProgramData starting from Windows Vista? I can only theorize that this is some sort of limitation in how VFS works. Specifically it could be that when App-V’s VFS overlays some directory, those overlaid files and directories cannot be seen through another directory that is directory symlink (or maybe also in case of a junction point, which is a separate concept in NTFS and available well before directory symlinks existed) to that VFS target dir.

Maybe a topic for some future blog article, who knows!

And as to why AVE shows %SFT_ALLUSERS_DIR% the way it shows, well, when we initially implemented Lib-V, the App-V package SDK which is the technical underpinning for AVE’s package handling functionality, it sure looked like %SFT_ALLUSERS_DIR% needs to be resolved according to what is the canonical folder for shared application data. And since there are API calls in Windows for doing just that, it is what Lib-V (and by extension both AVE and Virtualization Encoder) does when seeing such a variable. Little did we know at the time that this variable was actually a “hardwired” one!

—

As a closing note, I would like to thank Sebastian Gernert for into bringing this whole thing into our attention, it seems that we still haven’t stopped learning about previously unknown “features” of App-V!