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

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

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?

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.

App-V 5: On Using Sequencing Templates

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

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

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.

Important Information for those still using Softgrid 4.1 and 4.2

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 11^th, 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.

App-V 4.6: Are you using the Latest Version of the Client and Sequencer? You should be.

When many organizations move to Windows 7, they also take on the task of discovering, inventorying, testing, and remediating all of their current applications currently used in production. Often part of that process includes a decision to deliver those applications with App-V. The App-V 4.6 SP1 Sequencer and client offers a streamlined workflow to virtualize, package, and deliver those applications to the desktop or RDS server providing a simplified, centralized approach to application delivery and management. It also, at the same time, resolves many application interference issues through isolation and state separation.

When a product such as App-V undergoes a significant maintenance release, there are always the possible regressions. With 4.6 SP1, there were a few, and the App-V team was able to quickly isolate many of them and provide fixes in a timely manner. Servicing is always an important process in the support of production software.

App-V service releases (a.k.a hotfixes) are released in a manner that allows for the simplification of the deployment of fixes. Hotfixes are based on major release points (i.e 4.6, 4.6 SP1) and are designed to be cumulative. This way, if you deploy the recent hotfix pack, you can rest assured you are getting all of the cumulative patches released since the last major revision. In the case of App-V 4.6 SP1, the most recent release is 4.6 Hotfix Package 6 (build 4.6.1.30121.) if you are not currently running your 4.6 clients at this build you can leverage the hotfix download link found with the associated KB article here:
http://support.microsoft.com/kb/2693779

The hotfix packages are made available in MSP format. This allows for flexibility in enterprise deployment of the patch.  Remember, since the patches often affect revision changes of the App-V filter drivers, a reboot is necessary when deploying the patch.

But What about the Sequencer?

As many client changes involve patching the App-V System Guard (the component that facilitates the virtualization engine) it requires making revision to the App-V 4.6 SP Sequencer as well. I always advise all of my customers to ensure that they are always using the most recently released build of the App-V Sequencer.
The relase process for the sequencer is slightly different. Not every cumulative patch, involves a change to the sequencer. With this, you will not always see inclusion of the sequencer with every cumulative hotfix release. In the case of the most recent release of App-V as of this writing, the most recent service release of the App-V 4.6 SP1 sequencer is the refresh build that came with 4. SP1 Hotfix 3. You can download the release via the KB article for the hotfix here:

Hotfix Package 3 for Microsoft Application Virtualization 4.6 SP1: August 2011
http://support.microsoft.com/kb/2571168

Instead of an MSP file, when a sequencer is patched, an entirely new installation is made available. This makes sense because sequencer machines are often never “upgraded.” They are often cleanly reverted. This allows sequencing engineers to refresh their machines images used for sequencing in a clean manner without having to worry about patching.

App-V: Don’t use WMI for querying virtual registries.

It is important to understand that the virtual registry is designed for virtualization of an application’s registry and it facilitates it through the interception of standard Win32 registry APIs. These APIs (i.e. RegOpenKeyEx, RegEnumKeyEx,  RegEnumValue,  RegCreateKeyEx, etc.)

I have, from time to time, dealt with alleviating confusion with how to access the virtual registry. I have often encountered a problem with applications and especially scripting where the application or script is unable to properly accessing the registry. Here is an example scenario which you can practice and demonstrate on your own sequencer and client.

On a machine with the App-V sequencer, pre-create the following registry key and value:

• HKEY_LOCAL_MACHINE\SOFTWARE\Test1\Key1
• Value: Value1
• Type: REG_SZ
• Data: Data1

On an App-V 4.6 sequencer machine, create the following VREG exclusion:

• \REGISTRY\Machine\Software\Test3\Key3\

Now, open up the App-V sequencer and create a new virtual application package. I do the experiment on both the 4.6 and 4.6 SP1 sequencer.

Accept the defaults, give it a test name. Start monitoring. During the monitoring phase, open a command prompt and do the following using the “reg” command.

Create the following key and value:

• HKEY_LOCAL_MACHINE\SOFTWARE\Test2\Key2
• Value: Value2
• Type: REG_SZ
• Data: Data2

Using the following command:

reg add HKLM\Software\Test2\Key2

reg add HKLM\Software\Test2\Key2 /v Value2 /d Data2

Now Create the following key and value:

HKEY_LOCAL_MACHINE\SOFTWARE\Test3\Key3

• Value: Value3
• Type: REG_SZ
• Data: Data3

Using the following command:

reg add HKLM\Software\Test3\Key3

reg add HKLM\Software\Test3\Key3 /v Value3 /d Data3

Don’t click Stop Monitoring button. Now run “regedit” from the same command prompt.

Verify the entries under HKEY_LOCAL_MACHINE\SOFTWARE\

You will see keys for test1 and test2, because of what was locally present (Test1) and remember the exclusion (Test3).

Now stop monitoring. Continue to configure the package by creating a command prompt shortcut for the package. Now launch the Command prompt when optimizing for streaming phase (launch phase) – then launch regedit.exe.

You will see only Test1 and Test2 keys again.  Exit regedit and exit the command prompt. Don’t close – select option to modify package.

Now confirm that under the “Virtual Registry” you will see keys test2 only.

Save the package and deploy and launch the application on a test App-V client. On that same machine with the App-V client, pre-create the following registry key and value:

• HKEY_LOCAL_MACHINE\SOFTWARE\Test1\Key1
• Value: Value1
• Type: REG_SZ
• Data: Data1

Launch the application (which will launch the command prompt.) From a command prompt, launch regedit and you will see the virtual registry entries.

Open notepad, create and run a vbscript as below for using WMI to read registry keys that are created in above steps.

SCRIPT1.VBS

---------------BEGIN--------------------
dim RegKeyPath, RegValueName, RegValue
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set RegObj=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\default:StdRegProv")
RegKeyPath = "SOFTWARE\Test2\Key2"
RegValueName = "Value2"
RegValue = ""
RegObj.GetStringValue HKEY_LOCAL_MACHINE,RegKeyPath,RegValueName,RegValue
If IsNULL(RegValue) Then
 msgbox "Returns NULL"
Else
 msgbox RegValue
End If
---------END----------------

Now when you run this script in the virtual command prompt, it returns null. Now when you run this next script:

SCRIPT2.VBS

------------BEGIN-------------------
dim RegKeyPath, RegValueName, RegValue
const HKEY_LOCAL_MACHINE = &H80000002
strComputer = "."
Set RegObj=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & _
strComputer & "\root\default:StdRegProv")
RegKeyPath = "SOFTWARE\Test1\Key1"
RegValueName = "Value1"
RegValue = ""
RegObj.GetStringValue HKEY_LOCAL_MACHINE,RegKeyPath,RegValueName,RegValue
If IsNULL(RegValue) Then
 msgbox "Returns NULL"
Else
 msgbox RegValue
End If
-----------END-----------------

Now when you run this script, it returns success. Why? If you look at the VBSCRIPT syntax, notice it uses the WMI provider to query the registry which is local and outside the virtual registry. Key Test1 is resident locally, and Key Test2 is virtual.

Steve Thomas

App-V: always Always ALWAYS!! exit the Sequencer before snapshotting your Sequencer VM

Never, ever, ever  . . . never, ever, ever snapshot your sequencer virtual machine while the App-V sequencer application is still running. I am not talking about monitoring. I am talking about simply having the sequencer program left running (even without a package loaded) while the virtual machine is being snapshotted.

I’ll explain why this can be bad and how it can get you into trouble.

When the App-V sequencer creates a GUID for the package that needs to be unique. If somehow two packages get the same GUID, you will run into an error at deployment and need to re-sequence.

For example, If you do the following:

1.) Install Sequencer.

2.) Open Sequencer – take snapshot.

3.) Sequence Package A. Copy to External Location.

4.) Revert VM.

5.) Sequence Package B. Copy to External Location.

Then upon deployment, you will run into problems due to packages having the same (identical) GUIDs. For example, when deploying to an App-V Management Server

1.) Import first package – all is successful

2.) 2nd package appears to be successful but the second package never imports even though the application(s) from the second package appear in the console. The applications actually show as being from the first package rather than the second package.

This is caused by the 4.6 code creating a default working package and GUID behind the scenes upon launching of the sequencer process.
This behavior has changed and varied with releases. Older Softgrid releases may generate the GUID on launch, some versions prior to 4.6 stopped this and generated the GUID only after the “File-New” option. With 4.6, we definitely still have this issue.

My co-worker who worked the latest sequencer beta did inform me this is now fixed in 4.6 SP1 however, the current recommendation is not to have the sequencer opened when taking snapshots of VMs. It makes no sense to have the sequencer opened during snapshots.