Archive

Posts Tagged ‘sequencing’

App-V: How the Sequencer Detects an Existing Package was Created

October 26, 2014 Leave a comment

One of the most consistent recommended practices throughout the history of App-V sequencing is to always sequence on a clean sequencer. Starting with App-V 4.6 SP1, a detector was put in to warn users if they were about to sequence on a machine where a previous package was sequenced.

 

When the App-V sequencer is installed, it will create a registry key called ReadyBit located beneath HKLMSoftwareMicrosoftAppVSequencer and set this value to 1. As soon as a sequence begins to go forward (creating a PVAD, Package Name, etc.) this bit will be set to 0 to inform the sequencer that we are no longer working with a clean sequencer.

So, the obvious next question would be, should we be manually resetting this bit. Only in certain circumstances. Let’s say you gave an incorrect package name or specified the wrong PVAD and went forward with the wizard and accidentally began monitoring. You had yet to install any binaries but you realized you made a mistake. Is there another option other than reverting to a previous snapshot of the virtual machine? What if you were doing this on a physical workstation? Yes, you can exit out of the sequencer, set that registry setting manually, and restart the sequencer and not have to worry about having that warning pop up during the computer preparation stage.

Please note that this is the ONLY time I would recommend doing this.

Advertisements

App-V 5: On Environment Variables

October 26, 2014 8 comments

Environment variables are managed on a per-package basis in App-V 5 just as they have with previous versions. During sequencing, the Environment Variable Virtualization Subsystem (say that 10 ten times fast) will capture snapshots of the user and system variable list before and after the monitoring process. Then lists are compared and any differences are added to the package manifest. This means the package will default to the variable data entered in during sequencing. The variables are then stored in the package manifest using the following format:

<appv:Include>

<appv:Variable Name="TMP" Value="[{LocalAppData}]Temp" />

</appv:Include>

Where the “Name” is the variable and “Value” is the new, tokenized (if necessary) value of the environment variable.  On the client, the named variable will be set to the new value within the virtual environment and properly translated.

The one time there is an exception to this process is when the PATH value is being handled. Applications never “set” the PATH variable – they only append, or add to it therefore if changes to the PATH value are detected during sequencing, the changes will be captured and will appear slightly different in the manifest, with a self-referential value. The PATH variable that is captured in manifest will look similar to:

<appv:Variable Name="PATH" Value="<dirpath1;%PATH%;dirpath2" />

Where dirpath1 would be a prefixed Path segment to the current PATH and dirpath2 is a suffixed path segment to the current PATH.

The sequencer can also detect the deletion of existing variables and will apply those in the manifest using the following format:

<appv:Delete>

<appv:Variable Name="TEMP" />

</appv:Delete>

In this case, the Environment Variable TEMP will be deleted within the virtual environment of the application.

These captured values can be modified and overridden using dynamic configuration. An administrator can modify DeploymentConfig and/or UserConfig to edit Environment Variables. The <Include> element beneath the <EnvironmentVariables> section is where new or modified variables should be placed. The <Delete> element is where values need to be removed. In the example below, the PATH variable is modified, two additional variables are added and one will be deleted (if exists.)

 

The Virtual Environment Variable Subsystem reads the package manifest and the option deployment and user dynamic configuration files, and produces two lists – variables to add and variables to remove.  This is all done when the application launches. As the catalog documents are processed, newly processed values overwrite previously processed values, so last writer wins. It is important to make sure all needed variables from the manifest are transferred over to the dynamic configuration files when leveraging them to change variables post-sequencing.

As with sequencing, there is an exception and it again involves the PATH variable. The PATH variable is injected after a process has completely loaded. This is why it is not a good idea to try to use the PATH value to help a virtual application to find a static binary dependency (even inside the immutable package cache.)

Caveat with Connection Groups

An area that confuses sequencers is how environment variables are handled with Connection Groups. Environment variable lists overwrite each when combining packages into Connection Groups. Like with registry convergence, variable convergence is a last writer win scenario in the case of overlapping variable names. The package with the highest order within the connection group descriptor document wins variable name conflicts.

Exception with Multi-String Values

Be advised though that some variables are treated specially, as they have been identified as having multi-string values.  If a multi-string variable is present in multiple packages, the resulting value is the combination of values from all packages, instead of the last writer winning. The list of variable names which are treated as multi-strings is stored in the registry at HKLMSOFTWAREMicrosoftAppVSubsystemEnvVarMultiStrings

Exception with Cross-Bitness

App-V deploys special additional tokens used to denote information that has to be adjusted depending on the bitness of the sequencing machine and the correlation of the client machine. These tokens apply to environment variables impacted by Wow64 redirection. They enable the proper translation when an application that was sequenced on a 32-bit machine gets deployed on a 64-bit client machine.

The two are:

  • AppVEnvironmentVariableCommonProgramFiles: Can be %commonprogramfiles% or %CommonProgramFiles(x86)%

  • AppVEnvironmentVariableProgramFiles: Can be %ProgramFiles% or %ProgramFiles(x86)%

The rules for this are as follows:

  • If the application is a 32-bit application, sequenced on a 32-bit operating system, deployed on a 32-bit operating system, then these tokens are expanded back to the original values.

  • If the application is a 32-bit application, sequenced on 32-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to X86 versions of the values.

  • If the application is a 64-bit application, sequenced on 64-bit operating system, deployed on 64-bit operating system, then these tokens are expanded back to the original values.

Verification of Virtual Environment Variables

When testing environment variables within a virtual application package, the environment variables will not be visible outside of the virtual environment. That is why you will see no changes when you list the variables using the internal “set” command:

 

However, when you open the command prompt inside of the virtual environment, you will see the variables from above:

 

 

 

 

AppV 5: Important Considerations and Ramifications for Package Upgrade and VFS Write Mode

August 30, 2014 3 comments

If you are running any version of the App-V 5 client or Sequencer prior to App-V 5.0 Service Pack 2 Hotfix 4 – stop reading. This does not apply to your environment. If you are running HF4 or sooner, you need to have a good understanding of the net effects of toggling VFS Mode on and/or off during package upgrade.

VFS Write Mode was introduced to (my words) “fix bad brake jobs” when it comes to application development. Applications that need to be able to read and write configurations files in normally protected directories or have modified ACL’s for standard users in order to write to program locations that only administrators would normally have access to (Notepad++ has a way to go back and forth between good and bad program configuration – 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.)

While VFS Write Mode involves setting a specific attribute within the package manifest, the effects on how the VFS (Virtual File System) and COW (Copy-on-Write) filter are handled for the user are significant. As a result, making any changes to this setting during package upgrade could have some effects.


Scenario 1: Package Upgrade where the VFS Write Mode setting is not changed

This one is pretty straight-forward. No considerations are needed. Nothing is changed in how the VFS handles things.

 

Scenario 2: Package Upgrade where VFS Write Mode setting is turned on when previously not enabled.

When this happens and directories previously existed in the COW but there was no “S” directory, then the original directory will be renamed to the “S” version and the permissions appropriately adjusted. The new “regular” directory will be created. So instead of just one directory (i.e. ProgramFilesX86) there will be two (adding ProgramFilesX86S.) For more information on the “S” directories, please refer to my previous post here (http://blogs.technet.com/b/gladiatormsft/archive/2014/08/29/app-v-5-on-the-now-sometimes-immutable-package-cache-location.aspx.)

 

Scenario 3: Package Upgrade where VFS Write Mode setting is turned off when previous enabled.

In this scenario, there will likely be existing two structures: directories appended with “S” and the regular directory with the relaxed permissions. When this happens, the relaxed permissions directories will be deleted and the “S” directories will be renamed back to their original names. If this is ever done unintentionally, you can imagine some of the issues that may happen so be careful doing this.

 

I would advise always avoiding Scenario 3. Scenario 2 will be quite common as many sequencers and packagers are now upgrading their pre-SP2 HF4 App-V packages in order to take advantage of the new VFS Write mode feature. The question I am getting asked a lot lately is whether it is better to re-sequence with VFS Write Mode on or to simply just perform a package upgrade. I would advise trying the package upgrade first to turn on the value. In most cases, this should work – but as always, I await your comments.

App-V 5: On Sequencing Using Tokenized Paths, PVAD’s, VFS, and VFS Write Mode

May 23, 2014 7 comments

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:

http://download.microsoft.com/download/F/7/8/F784A197-73BE-48FF-83DA-4102C05A6D44/App-V%205.0%20Sequencing%20Guide.docx

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

App-V 5: Application Troubleshooting: On the Origins of an Error Message

May 12, 2014 2 comments

Have you ever been testing a virtualized application and it fails with a bizarre application error that is either extremely vague (unknown error) or coupled with some random hex code? Your first reaction usually is “Where’d that error come from?” That is a good reaction to have as it is the first major hurdle in determining how to troubleshoot what has gone wrong. If you have not narrowed down the target of where the application error is coming from, you leave yourself open for spending a tremendous amount of wasted time down “troubleshooting rabbit-holes.”

Is it an App-V Operational Issue?

The first thing you will want to narrow down is whether or not it is an operational issue coming from the App-V Client itself, or is it related to the package (Application not functioning as expected.) I always recommend to first look at the source of the error window. If the error message is originating from a “Microsoft Application Virtualization” window, it is likely an operational issue tied to one of the client engine components or perhaps a streaming issue.


If it looks to be an operational issue, I would advise you leverage some scripts and tools written by Dave Falkus, one of my colleagues in the UK: http://blogs.technet.com/b/virtualworld/archive/2014/04/12/app-v-5-0-etw-tracing-automation.aspx

In addition, one of my previous articles will assist you in dissecting App-V error codes: http://blogs.technet.com/b/gladiatormsft/archive/2013/11/13/app-v-on-operational-troubleshooting-of-the-v5-client.aspx

So I’ve determined it is an error that occurs within the virtualized application itself, now what?

Whether you are isolating an issue that may be caused by virtualization or by bad sequencing, if you have determined the error is coming from the virtual application then it is time to start doing a little reverse engineering with a couple of Sysinternals tools. The first thing I do for an application completely new to me is map out the EXE and DLL launch tree. You can do this by capturing the issue with Process Monitor ensuring that you start capturing at application launch.

You can then run a quick capture filter (I usually load a saved filter with these filter settings)

My filters contain these operation events:

  • Process Create

  • Process Start

  • Load Image

  • Process Exit

If the application is devirtualized on the sequencer, you will be looking to start from the shell process that initiated the Process Create operation (CMD.EXE or EXPLORER.EXE likely.) On a side note, svchost.exe will spawn modern apps, but that is out of scope here. J

If the application is running virtualized on the client, you will see that the AppVClient.exe process interjects spawning the mavinject32.exe or mavinject64.exe process depending on application bitness – followed by the shell creating the process. The example below using virtualized SongSmith displays this in Process Monitor:

Incidentally, if you want to know more about how the AppVClient.exe determines when to run the MAVInjector, read this previous article:

http://blogs.technet.com/b/gladiatormsft/archive/2013/09/12/app-v-5-to-virtualize-or-not-to-virtualize-how-app-v-5-answers-that-question-when-you-launch-a-shortcut.aspx

OK, I have identified the EXEs and DLLs, Now What?

You can do one of two things. You can search the Processes for strings using Process Explorer, or in the case of DLLs and EXE’s, you can simply leverage the Sysinternals STRINGS.EXE tool. The Process Explorer tool is great for finding error strings (by going to the properties of a process, selecting the “Strings” dialog box, clicking the “Find” button.)

The reason I do not use this is because it requires the process to still be active and it is not easy for searching DLL modules if they are not still in memory. I use instead the STRINGS.EXE utility (http://technet.microsoft.com/en-us/sysinternals/bb897439) as it allows for more search flexibility.

Case in point, this bizarre error in Notepad++:

I can confirm the error came from the EXE NOTEPAD++.EXE by using the following command:

Strings-o “C:Program FilesNotepad++Notepad++.exe” | findstr /I scintilla

  

Putting it All Together

When you get that unknown application error, you can then proceed to investigate towards a resolution using a clear path by:

  • Determining whether it *IS* an application error and not an operational error.
  • Determining if it is a sequencing or virtualization issue.
  • Collecting the Process/DLL load/execution order.
  • Identify which EXE or DLL is contains the error string.

 You can then proceed to continue troubleshooting by focusing around that EXE or DLL with Process Monitor, SpyStudio, APIMon, or whatever tool you prefer to further debug the issue.


App-V 5: On Using Sequencing Templates

March 18, 2014 5 comments

Sequencing Templates (.APPVT) files are designed for automating the sequencing of applications. While you can take advantage of some of the benefits of templates with manual, interactive sequencing, be careful making assumptions when sequencing following the importing of a template in the Sequencer GUI. Sequencing Templates are also essential for the upgrading of packages.

Remember this from the App-V Sequencing Guide:

“Templates are also very important for upgrade scenarios.  The Sequencer does not save state so when a new Sequencer session is open and a package is opened for upgrade, the settings are in the default state.  If certain sequencer settings were changed when sequencing a package, the changes will not remain at time of upgrade.  Therefore, it is recommended to save a template for any package that has Sequencer customizations, and re-apply them on upgrade.  A template may also contain additional options such as Package Deployment Settings and Advanced Monitoring Options.”

Creating a Sequencing Template

Creating a sequencing template is pretty straight forward. You launch the App-V Sequencer and first set your advanced options for sequencing. You do this by going to the “Tools” menu and selecting “Options.”

All of the General Items and Exclusion Items can be adjusted using this dialog box. All of these settings will be saved into the template.

If you plan on only using these settings in your template, you can proceed to save as template using the “File” menu to “Save as Template.” However, if you want to include additional settings (for automated sequencing with PowerShell) instead of saving as template, proceed and go through the process of creating a blank dummy package. Make sure you click through to the advanced options so you can configure:

  • Operating System Options
  • Advanced Interaction

 

 

Once you have all of these settings the way you want them then you can proceed to save the template. Notice you will get a specific alert when doing so.

 

While it implies that the additional settings (OS, COM, objects) will not be saved in the template, you will find that they are, in fact, saved. What the effect of this message is any settings other than General Options or Exclusion Items will NOT be imported if you import the template into the sequencer GUI for the sequencing of a new package.

 

 

All of the settings will however be used if the template is used in conjunction with the New-AppVSequencerPackage PowerShell cmdlet. It will support the use of all of the template items. The use of PowerShell with templates opens the door of many possibilities for automating the sequencing of your packages. Here is an example:

 

Once the package has been created, you can verify the configuration held by observing the information in the App-V manifests.

 

Happy Automation!!

App-V 5: Capturing Data Source Configuration

January 11, 2014 4 comments

You may have noticed that in previously releases of Softgrid and App-V, it was recommended as a best practice to manually create a dummy (I hate that word – I prefer “artificial”) ODBC data source (DSN) connection on the sequencing prior to sequencing anything that interacts with ADO/ODBC. The reason for this has to do with how these settings get captured during the sequencing process and how default registry opacity is handled. If the settings for ODBC are empty than any settings that are captured during the sequencing will be reconciled as “Override” since there will be no existing ODBC registry keys on the sequencer.

The problem this creates is the override settings will prevent the virtual application from seeing any existing ODBC settings that may exist on the client workstation. Given that the application may need to interface with a database client or middleware that needs these settings, this could be problematic. If you create a dummy (as it has been called) ODBC connection in advance, then only the settings for the connection parameters (DSN) captured during sequencing will be collected and the opacity will be set to “Merge.”

With the advent of the 4.6 SP1, many sequencing best practices were implemented into the workflow of the sequencer software. Among them was this very creation of an artificial DSN. As a result, people stopped having to worry about it. Well . . .

It is time to start doing this again. With the 5.0 Sequencer (including the latest SP2 release) you will need to create an artificial ODBC connection in advance of sequencing. Otherwise, you will still run into registry opacity issues with ODBC settings that are captured during sequencing. In most cases, virtual machines are used so I would simply add this to the default configuration of your base sequencing machine.

Categories: Uncategorized Tags: , , , , ,