Tag Archive: App-V


App_Remediation is a new free tool I am releasing to the public today.

App_Remediation is a console application designed to be used with App-V 5 (and above) to save and restore application related data (ARD) between locations that normally do not roam and those that do.

App-V now isolates ARD changes and redirects the saved file changes to locations that either roam or not, based on whether those changes would have roamed if the application was natively installed. This is quite different from the versions of App-V before version 5, where these changes would have been isolated and redirected to a location that always roamed. This remediation of badly constructed apps is very important to customers in a roaming environment, including not only those using “roaming profiles”, but also if using folder redirection, home drives, or other methods.

This program can be used in scripts to remediate virtual applications in two different ways:

  • PER APP BASIS
    Quite possibly, you only have a few apps in production today that require this kind of remediation. A simple solution would be to add this program as the script file for both “StartVirtualEnvironment” and “TerminateVirtualEnvironment”.

    For the StartVirtualEnvironment script, you use the parameter “/restore“, followed by a space, and then followed by the Package Id GUID (not the package version guid, and not inclosed in { } characters). You would mark the script to start outside the virtual environment with rollback=false.

    For the TerminateVirtualEnvironment script, use the parameter “/save“, followed by a space, and then followed by the Package Id GUID.

  • PER USER SESSION BASIS
    The app may also be run as part of user logon / logoff scripts, using the “/saveall” and “/restoreall” parameters. No GUIDs required as it will save or restore all packages found.

HOW IT WORKS

When saving changes, it will copy the folders and files (preserving the attributes, ACLs, and timestamps) from the users AppData/Local redirection repositories into a similar location under the users AppData/roaming location.

For example:
    C:\Users\Tim\AppData\local\Microsoft\AppV\Client\VFS\7EA4C0C9-2099-E743-AAEA-A1C03D11138E
is saved to:
    C:\Users\Tim\AppData\remote\Microsoft\AppV\Client\VFS\SavedFromLocal\7EA4C0C9-2099-E743-AAEA-A1C03D11138E

The program does not touch isolated registry information, as those are properly handled for standard users when apps do not require elevation.

Example Script

Below is an example of use of App_Remediation solving the problem of Paint.Net saving user settings into AppData/Local based files. The Package Id GUID is conveniently found at the top of the Deployment or User config file as PackageId=…

<UserScripts>

    <StartVirtualEnvironment RunInVirtualEnvironment=”false”>
        <Path>C:\Windows\App_Remediation.exe</Path>
        <Arguments>/restore 26ceb0bc-1e69-4de1-a444-70b6f1e0dfc3</Arguments>
        <Wait RollbackOnError=”false” Timeout=”30″/>
    </StartVirtualEnvironment>

    <TerminateVirtualEnvironment>
        <Path>C:\Windows\App_Remediation.exe</Path>
        <Arguments>/save 26ceb0bc-1e69-4de1-a444-70b6f1e0dfc3</Arguments>
        <Wait RollbackOnError=”false” Timeout=”30″/>
    </TerminateVirtualEnvironment>

</UserScripts>

You can also solve this problem with some User Environment Management products, although ironically not Microsoft’s UE-V product. This tool should prove to be easier to use, since you don’t need to worry about the app-specific details of what to capture or not. Just use this and it grabs everything that App-V isolates.

See this page for more information on download and installation.

Here is my attempt to explain the differences between App-V before version 5 and version 5. It is a 16 minute video to explains the main differences at the client and how this affects your ability to deploy applications.

App-V 4 versus 5
Click to view MP4 video in HD

One aspect of App-V that we rarely discuss is then when you are sequencing, the sequencer not only detects added folders, files, registry keys, and registry items, but it also pays attention to things that the installer removes. By this I am not referring to a temporary file added and then removed, but something that was present prior to sequencing and actively removed by the installer.

It isn’t something that happens very often. We see it more in an application upgrade scenario than anything else.

In App-V prior to 5.0, the SFT format had a special provision that listed files and folders that were deleted during sequencing. Similarly, the osguard.cp file that contains the virtual registry had the ability to mark deleted registry items. These are both clearly documented in the file format document that Microsoft finally released a couple of years ago. This capability also was further carried out in the PKG format, where it is needed more. If the user deletes a folder/file/registry key/registry item, a marker for this this was stored in the PKG file.

The Sequencer did not show you these deleted entries, but tools like my free “PkgView” tool, or Kalle’s “Application Virtualization Explorer” tool would parse these formats and show them to you. All of this worked great in the pre 5.0 releases. So how does this work in 5.0?

“Different”.

During sequencing, the sequencer seems to detect and store deleted registry keys and items, but not folders/files. As in the older releases, you can’t see the deleted entries (files or registry) in the Sequence editor, but need a tool to break into the format to find them. Breaking into the AppV format is fairly simple, using standard OS tooling. You make a copy of the “.AppV” file and rename the extension to “.zip”. You can then open up the file for viewing only using the zip compression utility that comes with the OS, or a third party zip compression tool. Note: Don’t ever think of saving the file with one of these utilities and renaming back to “.AppV” — you end up with a broken package (hence the part of that initial statement that said “make a copy of …”).

Once you open the zip file, you will see a folder named Root, a bunch of XML files, and a file ending in “.DAT”. If you look under the Root folder, you will see all of the added or modified files. You will find no indication of any deleted files. Further investigating all of the XML files by opening in notepad or some xml editor or viewer, you will also find no indication of the deleted files. It appears that we have lost this capability to mark deleted files.

To view the Registry.Dat file, we can also use a standard OS utility – regedt32. The format appears to be only slightly different than a standard registry hive format. To view the file, you create a temporary key in regedit, and click on the key. Next, use File–>Import from the menu. You will need to change the allowable file types to all Registry file hives (*.*), then select the Dat file. This will import the virtual registry, in essence, mounting it under the active key.

image of registry

In the image above, you can see an example of a deleted registry item. The marking is accomplished by using a unique, and unknown to regedit, registry type of 0×20000. This is how App-V is designating the item as deleted. I have not verified deleted registry keys, but presumably this would be captured similarly.

We probably need more investigation to see what happens with deletions in the stored user personalization. I expect that the registry items are handled similarly to how they are handled in the Registry.dat file. I also expect that file deletions are not handled.

These changes in App-V 5 have the potential to break an application. It would be rare, and I am unable to point to any production application that these changes would affect (tests to show the changes were done using a purpose-built app to show the effect). But it is the kind of thing that we all need to be aware of when we run into the odd application that just won’t work right anymore.

Scripting has changed in App-V 5.0.

The scripts move from the OSD to the new “Dynamic Configuration Files”, and very different options are now available to us to customize actions at the client.

Microsoft’s Aurung wrote a blogpost that describes much of the detail, but there are a few things to clarify and point out. Still, it is a great start, so go read that first and then come back. I’ll wait!

OK. You are back.

First, let’s replace the table in that post with this one:

Most important is that, depending on the script, these scripts can run in the system or user context. This allows you to do great new things like install a dependent device driver on behalf of the user. But there are some things that you need to know:

  1. The “script” must started as an EXE optionally with parameters. So you might need to specify the script engine (cmd.exe, cscript.exe, etc) for some of the things you want to do.
  2. Only scripts starting the virtual environment, or starting the application, can run inside the virtual environment. Everything else, including terminate application and terminate virtual environment, must be run outside the virtual environment. When a script is run outside the virtual environment, it cannot access anything inside the environment, so you’ll probably need to utilize a file share. So the idea of placing the scripts in a script folder inside the VE is cool, but how often can I really use that?
  3. You will want to ensure that scripts that run don’t produce UI elements. Just try to use “C:\Windows\System32\Notepad.exe” as your script that runs under the system context to see the results. You don’t see the UI and a timeout happens. If the rollback option was specified, you become an unhappy camper.
  4. You will want to ensure that script that run in the user context don’t cause UAC elevation prompts. Have a script try to create a file at the root of C:\ and if the script is running in the user context it will fail on default permission systems.
  5. Don’t forget about that column about only running once. They should have given us an option on the script definition for that feature. Most of the time you are probably going to remove the package before adding again, so you will rarely have an issue, but not if you are adding a package update. This probably forces you to use a Publishing script at the Machine level with logic to figure out if it is updating the pervious or starting new.

You just gotta love how Microsoft sneaks things in.

4.6SP2 is pretty much a rollup of hotfixes (almost all of them since 4.6SP1 came out), plus support for Windows 8, Server 2012, and additional client changes for transitional dual client scenarios with App-V 5. As always, you should check the Readme documentation for details, but in the time honored tradition of making changes without telling us, there is more. And when someone in the community finds one, it is nice for them to tell everyone.

So here is one. The following screen shot is from the 4.6Sp1 sequencer:

And here is what the same screen looks like with the same app on 4.6.2:

So it looks like an improvement to the detection logic, or perhaps more accurately, a bugfix to faulty improvement logic. Maybe that means they also fixed the one where it sometimes misses device drivers?

It is nice that they fix these things, I just wish that they would acknowledge it so that we know not to trust the version currently in use by most companies!

 401   We ran into this in our Masters Level App-V Training class this week. We love to try things “outside the box” in these classes because we always learn more. Thanks to Mike from the UK for coming up with this one!

When we sequence a package, the sequencer goes to great lengths to translate hard coded paths and your user ID into pseudo variables in the output package. The client then re-translates them dynamically to what is appropriate.

Of course, one of the things that the sequencer will map is the reference to the virtual drive, as in “Q:”. Since there isn’t a CSIDL for this, Microsoft uses %SFT_MNT% for the intermediate form to store.

But it has been beaten into our heads over the years that it is important to have ALL of the App-V clients use the same drive letter as the one we sequence on to improve application compatibility and consistency. I usually describe the reason for this need as being apps that hide file references in places that App-V doesn’t look (like a .dat file).

But there is this other case where the translation can generate a problem, and this is what we found when the app would not launch.

These translations also apply to command line parameters that you catch in the OSD. In our case, the “command” was to run iexplore.exe with an “https://server/path/file.html” parameter.

But it was sequenced on a machine with S: as the virtual drive letter. So the OSD reference had a parameter “http%SFT_MNT%//server/path/file.html”.

This is OK, when the client is also using “S:” for the virtual drive, as the client translates back the original form. But not when you drop it on a client with a different drive letter. Drop it on a lab client machine using “Q:”, and the translation reads “httpq://server/path/file.html”, which of course will not be found.

PS: The same problem should occur if you standardized on the “P:” drive.

In October, we had a group of 6 App-V MVPs together in Boston to meet with the App-V development team. We had an opportunity to shoot an interview at that time with TechTarget’s Colin Steele. We were handcuffed in that we couldn’t disclose information we knew about (under NDA) the final App-V release, but we were free to talk about what was publicly known at that point thanks to the Beta.

So check out this short video interview, which focuses on some of the big picture considerations we see us all facing in the virtualization space.

http://searchvirtualdesktop.techtarget.com/video/Enterprise-application-delivery-options-A-panel-discussion

As we are getting ready to launch our final App-V 4.6* “Masters Level” training class next week, I am being hit up by people wanting to know about a 5.0 class.

So let me make it clear. We won’t be labeling the new 5.0 class as a “Masters Level” class. oWhen I started training folks on App-V many years ago, we had a “training class”. We quickly determined that with my background in the product, what we were doing was far greater and in-depth than the training that Softricity (and then Microsoft for the first year after purchase of the company) was providing that we started calling it “Advanced”. Over the years, we fine tuned the program and started calling it “Masters”.

Nobody can offer a “Masters Level” class on App-V 5 any time soon. The training we offer next year on App-V 5 will be as good or better than what anyone could offer, but we won’t call it “Masters Level”. App-V 5 really is an entirely new platform, and it will take a couple of years before we have enough opportunities to work out how to work with/around the product to be most effective. And there are a lot of very interesting nooks to poke around.

So when we announce our new class, it won’t be called “Masters Level”, but it will cover everything that we can know about to make the best use of the new product. We’ll reserve that label for the future.