Archive

Posts Tagged ‘sequencer’

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.

App-V 5: On why the App-V 5 Sequencer *Really* Reboots

September 30, 2014 4 comments

Prior to version 5 of App-V, when you sequenced an application that required a reboot, the reboot was simulated in that the sequencer would process the reboot action including the Pending File Operations and the RunOnce registry keys (RunOnce, RunOnceEx, GuiRunOnce, etc.) when monitoring ceased. In most cases, the simulation would be fine and all of the necessary reboot tasks would be processed properly. There were some exceptions – notably the famous disappearing Google Chrome application famously mentioned  in “Stealth Puppy’s” [I love that handle] “Case of the Disappearing Application During Sequencing http://stealthpuppy.com/the-case-of-the-disappearing-application-during-sequencing/ “ where after the reboot tasks processed and the monitoring of the installation of GoogleChrome completed, the Program Files directory simply disappeared.

In defense of the sequencer, this was not as much the fault of the App-V sequencing process, but also an issue with the mechanism of the installation. This was easy to prove by going through the sequencing process and verifying the contents prior to stopping the monitoring process. The files were indeed correctly located prior to the stopping of monitoring:

However, when we ran PENDMOVES.EXE (http://technet.microsoft.com/en-us/sysinternals/bb897556)  from Sysinternals, we found this:

The operation pending was to DELETE the actual files. This would explain why the files got deleted after the monitoring process ended. The next logical step would be to see if this was a properly captured operation and not just some bug in the sequencer and install the application natively. Prior to rebooting the machine, run the PENDMOVES.exe utility again. Upon doing this, you will find the EXACT same pending file operation – DELETE C:Program FilesGoogleChrome.

So the native installation does indeed remove the files upon a reboot. The difference is after the reboot, the files are back where they need to be! How is this possible? Google triggers updates using the Google Update service which is set to start automatically. The missing files would force the Google Update service to pull down the most up to date version. Indeed a prime example of some of the exceptions to the rule that the 4.6 sequencer was not catching.

Going back to the original issue – and never passing up an opportunity to showcase a Sysinternals utility – I would recommend a workaround. Given the issue was a DELETE operation, you could leverage another Sysinternals tool to add in a recopy function as a workaround with 4.6. Before actually stopping the monitoring process, first copy the files in question to a safe area.

Then I used the MOVEFILES.EXE utility (http://technet.microsoft.com/en-us/sysinternals/bb897556) from Sysinternals to have them moved back during the simulated reboot.

Changes in the V5 Sequencer

So to ensure that the sequencer works better with installations that require reboots (or even multiple reboots) the sequencer was changed to actually reboot. When the sequencer detects that the application is requesting a reboot, all tasks are recorded and deleted (except for the PendingFileRenames key) to force resume only after the system is rebooted and the monitoring has resumed, otherwise, these tasks could occur prior to the sequencer resuming. This information is recorded to disk (although obfuscated) and the system will reboot as normal

After the reboot, the PendingFileNames key will be processed as it would in a normal reboot. Upon the user logon, the sequencer will be launched (as it registered itself to do that prior to reboot.) Upon relaunch of the sequencer, the sequencer reads its state from the registry and the file system and restarts monitoring. The first tasks that will be processed will be the RunOnce tasks that were captured prior to the reboot.

One Exception

While the Sequencer User Interface allows for the preservation of settings and a real system reboot, this is not the case for applications sequenced using the PowerShell Sequencer Cmdlets. Since this is mostly reserved for scripted MSI packages, those usually have suppressed reboots anyway.

App-V 4.6 Sequencing: What are the logs really for?

September 20, 2014 2 comments

For sequencing in App-V 5, the new ETW model simplifies the process and moves App-V to the Windows standards for event tracing. Even better, the sequencer not only has two logs to worry about (operational and administrative) but a simple process can occur to enable more verbose debug logging.

In App-V 4.6, the process was not that simple. While the logs did not write to the Event Viewer-able logs, all but one are text-based which makes for easy manipulation with your favorite log parser. I prefer Trace32 of course! These log files are stored in the logs subdirectory of the Sequencer installation directory which defaults to C:\Program Files\ Program Files\Microsoft Application Virtualization Sequencer\Logs. Certain logs pertain to specific functions so the relevancy will vary on whatever your troubleshooting scenario might be.

SFT-Seq-log.txt: The majority of sequencer logging occurs here (Uploads to virtual environment, downloads from the virtual environment, service starts and service stops, etc.)

SFTrbt.txt: This is the sequencer reboot log file. When the 4.6 sequencer simulates reboots, the elements that are processed will be tracked in this log file.

SFTCallBack.txt: This is a more simple logs that allows you to reconsile process starts and stops during sequencing. It works great in conjunction with a process monitor log.

Filter.log: Outside of working with Microsoft Support, this log is not very useful as it is obfuscated. It tracks file activity but must be decoded with an internal utility. You can enable further tracking into a file called files.txt which will contain a log of all files created in the VFS. This can be enabled (although it will increase sequencing time) by enabling the following value in the registry:

  • Key: HKEY_LOCAL_MACHINE\Software\Microsoft\SoftGrid\4.5\Sequencer\Configuration\
  • Value: FileManifest
  • Data Type: REG_DWORD
  • Data: 1

SFTrpc.txt: This is the log file created by the monitoring element SFTRPC.EXE and in addition to also capturing process startup and shutdowb, will also contain verbose diagnostic information about each monitored shortcut.

In addition to the sequencer logs, you can also leverage process monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and verbose MSI logging (https://madvirtualizer.wordpress.com/2014/03/17/enabling-advanced-windows-installer-logging/) if you encounter errors within the application during sequencing.

Categories: App-V Tags: , , ,

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: On Virtual Services in App-V 5.0

November 12, 2013 4 comments

On the subject of services, it is probably worth mentioning some of the changes with how App-V handles virtual services in V5. First and foremost, you may have noticed there is no separate virtual service agent service running for the V5 client. You have probably also noticed that virtual services are not managed or modified through the sequencer interface. So how do you configure a service during sequencing? Well, the same as a regular service, through the services control panel or the command line (or PowerShell) during the monitoring phase. Also, only the use of the LocalSystem account is supported. Other well-known SIDs such as Network Service are not supported. Services that are virtualized will also have read-only configuration during run-time when virtualized. You will not be able to change the state of the service when it is running in the virtual environment using traditional APIs.

Since App-V requires execution of an application in the context of a user account, it limits what kinds of services can be virtualized. Services that require execution at boot time or any time prior to a user logging on will not likely be a good candidate for virtualization. There are, however, many user-mode services that can be virtualized with App-V and actually work quite well with App-V.

. . .  and then there are those services we do not want in our virtualized application package due to functional or practical reasons. I use Google Chrome’s auto-update service feature as an example. Virtual applications work best when sequenced to a steady state and updated through the App-V update process. Services that automatically update base software binaries can cause applications not to function as expected.

The App-V sequencer will capture services during the sequencing process. In previous releases of the sequencer, there was a way to review the services detected in the Services tab. At that point, you could delete the services should you not want to keep them in the package. This has changed in the V5 version of the sequencer. If you notice, when you go to the services tab, you will notice that at this stage, you are unable to remove the virtual services from this screen.


  
 Removing Services during Sequencing

If you want to remove services that are captured in the monitoring process with the V5 version of the sequencer, you will have to use a different method now. During sequencing, you need to delete the services registrations in the registry prior to closing monitoring. This will require you to know where the service registrations are stored in advance or before you close out the monitoring process. For example, if I wanted to remove the service registrations for the Google Update Service, I would open up the Services management console and the Registry Editor after installation has completed and prior to stopping monitoring. When you view the properties of the service, the Service name field will give you the short name of the service. This will reflect the name of the subkey of the service located in HKLMSystemCurrentControlSetServices


 

You can then delete this subkey to remove the service registration. In most cases, the sequencer will capture that removal and thus remove the service entry.

Removing Services from an Existing Package

If the package has already been saved, then you can modify this by opening up the package using the workflow “Update Application in Existing Package.”

 

Then during monitoring, you can open up a command prompt and run the registry editor to remove those service registrations.

Once you delete the keys under HKLMSystemCurrentControlSetServices<SERVICENAME> you will find the services are gone when you look at the Virtual Services tab.

 

In addition to the above, you can also use other registry editing utilities (such as REG.EXE) or even use the SC command if you are looking for a safer alternative for removing service registrations.

Disabling Virtual Services using Dynamic Configuration

If you do not want to open up the package to remove a service, you can simply disable the virtual services subsystem using dynamic configuration. Just set the subsystem value to “false” such as follows:

<Subsystems><Services Enabled=“false“/></Subsystems>

AppV: On Devirtualization

October 25, 2013 4 comments

So, I am hanging out on the Technet Forums one Saturday night and I got inspired by a thread (http://social.technet.microsoft.com/Forums/en-US/9b136314-77be-4568-8bc6-6e2ed865f43e/this-document-could-not-be-opened-it-does-not-appear-to-be-a-crystal-report-document) to write this particular blog post. Yes, before I go any further, I will acknowledge the pathetic revelation of what I like to do on a Saturday night – because there is nothing more wild and crazy than hanging out on the forums. Anyway, I wanted to stress the importance of how you can use the sequencer as a troubleshooting mechanism to determine whether an issue with a problematic application is tied to the sequencing process or is an issue with virtualization (in general or with a particular virtualization subsystem.) So, it makes total sense that here I am late on a Friday revealing doing something I love to do – wax poetic about App-V on my blog!

So, if you encounter errors in your application and you suspect that an important asset was not captured during sequencing or you cannot eliminate whether or not a clean sequencing machine was used – you can always DEVIRTUALIZE! Devirtualization is a great step in troubleshooting as it helps you determine if an APPV package has all of the necessary file and registry assets. Here is what you need:

You will need a clean sequencing machine with . . .

  • . . . the same version of the sequencer used to sequence the application.
  • . . . any dependencies or middleware that the application needs to run (otherwise not included in the package.)
  • . . . a troubleshooting toolkit (i.e. Process Monitor)

Once this is in place, copy the package to the sequencer machine and then launch the sequencer application. From the Tools menu, select “Expand Package to Local System.”

Select the APPV package. It will then expand the package to a local installation footprint. If the application was sequenced properly, then all of the file, registry configuration, environment variables, and extension points will “install” to the local operating system. Once the expansion has completed, you can then proceed to launch and test the application. If the application functions correctly, you know the problems you have encountered with the application are not a result of sequencing issues. You can then redirect your troubleshooting towards issues including but not limited to:

  • Virtualization subsystems (Virtual COM, Virtual Objects, Virtual Services, VFS, etc.)
  • Incompatibilities with virtualization as a whole (drivers, COM+, etc.)
  • Information that could have been captured incorrectly in the FSMetadata.xml file (Short Names, Directory Opacity)
  • Registry Opacity
  • Static Dependencies

If the application fails to launch or function as expected after de-virtualization, then you can proceed to troubleshoot using your troubleshooting toolkit. Usually Process Monitor is quick to isolate these issues (missing files or registry entries.) However, you should always inspect the native equivalent of the extension points as well.

Categories: Uncategorized Tags: , , , ,

Important Information for those still using Softgrid 4.1 and 4.2

September 25, 2012 Leave a comment

If you are currently using Softgrid 4.1 or4.2 clients and/or servers, you need to be aware of the following support milestones:

Product

Availability

Mainstream Supports Ends

SoftGrid Application Virtualization 4.1 for Desktops

5/25/2007

7/10/2012

SoftGrid Application Virtualization 4.2 for Desktops

5/25/2007

7/10/2012

SoftGrid Application Virtualization for Terminal Services 4.1

5/25/2007

7/10/2012

 

As of last July 11th, these products are now in extended support which means

  • No more requests to change product design and
    features
  • No more hotfixes unless using an extended hotfix
    support contract.

Once a product moves out of mainstream support, I immediately start advising my customers to move forward. In the case of application virtualization, the reasons for moving to a more modern virtualization engine primarily revolve around more virtualization features and support for more modern operating systems (Windows 7 and Windows 8.) At this point it is a matter of determining what course of action to take – either moving to 4.6 or moving to 5.0. Most of the time, this decision depends on parallel factors (OS migration, ESD implementation, Application Compatibility remediating efforts, etc.) Use the following table to determine your general options for
moving forward:

Product

Transitional OS Support

Modern OS Support

Configuration Manager Integration Support

Upgrade from 4.1/4.2?

Engine Co-existence Support

App-V 4.6 Desktop Client

Windows XP & Windows Vista

Windows 7 & Windows 8**

2007, 2012

Yes

App-V 5.0**

App-V 4.6 RDS Client

Windows Server 2003 & Windows Server 2008

Windows 2008 R2 & Windows 2012**

2007, 2012

Yes

App-V 5.0**

App-V 5.0 Desktop Client

None 

Windows 7* & Windows 8

2012 ***

No

4.6**

App-V 5.0 RDS Client

None 

Windows Server 2008 R2* & Windows Server 2012

2012 ***

No

4.6**

 *- requires PowerShell 3.0
**- Requires App-V 4.6 SP2
***- Requires CM 2012 SP1 or later

Getting Your Virtual Applications to 4.6

Should you decide to move to 4.6, besides the obvious infrastructure upgrades, you will need to plan on moving your virtual applications to this newer platform. If you are currently on Windows XP, 4.6 is still the only option. For moving to is 4.6, I generally recommend following the general process below for assessing and remediating virtual application package migration.

  • Test existing package. While the injection/virtualization model did change between 4.2 and 4.5, a lot of regressions were identified and fixed – however – in my opinion, this may only be a guarantee in 80-90% of applications.
  • Update SFT file using App-V 4.6 SP1 sequencer or later. You can simply open a package and save it under the 4.6 SP1 sequencer and this will often serve the purpose of getting the applications functioning properly on the 4.6 client. You can also automate this by using the App-V sequencer command-line. Refer to this Technet Article – http://technet.microsoft.com/en-us/magazine/gg236638.aspx
  • Re-sequence using 4.6 SP1. If all else fails, re-sequence using the 4.6 SP1 sequencer (or later.)

Getting your Applications to 5.0

Should you decide to move to 4.6, your 4.1/4.2 packages will need to follow a different process for migration as there is a drastic change in the sequencer file format (SFT to APPV) as well as the XML governing these packages. Sequencer generates new package format based on the Windows 8 installer (APPX).

There is no direct step for moving these packages to the new formats. For moving to 5.0, I am currently recommending following the general process below for assessing and remediating virtual application package migration.

1.)   Update the 4.1/4.2 package using the App-V 4.6 SP1 sequencer or later. You can simply open a package and save it under the 4.6 SP1 sequencer and this will often serve the purpose of getting the applications to the minimum level needed for migration to 5.0 as mentioned above, you can also automate this by using the App-V sequencer command-line.

2.)   Test the package functionality using a test client running App-V 4.6 SP1 or later. This step is often left out – but is necessary.

3.)   Once the package is a confirmed working 4.6 SP1 package or later, you can proceed with migrating the package using the package conversion module that is included with the App-V 5.0 sequencer. The “AppVPkgConverter” PowerShell module installs with the App-V 5.0 Sequencer.

Please note: It is early in the process for me to give exact specifics as to expected successes – however, I can point out that there are elements that will not convert and will need to be tweaked/adjusted as of the App-V 5.0 Beta 2 release. These will help you determine if you would be better of re-sequencing the application:

  • OSD Scripts These will need to be added using the Dynamic Configuration feature of 5.0
  • OSD Registry Settings: These will also need to be added using the Dynamic Configuration feature of 5.0
  • Dynamic Suite Composition Settings: You will need to use the Virtual Application Connection feature instead.

You will also need to re-sequence in order to take advantage of Virtual Application Extensions Points.