How to troubleshoot App-V 5.0 DeploymentConfig & UserConfig script deployment failures using AppV Manage

Article
01/30/2014

Hello everyone, John Behneman here again. Recently I had case where a customer wanted to modify policy registry keys during a publishing event. Specifically, he wanted to disable protected mode for his Adobe 11 package. By default, protected mode is enabled and deploying Adobe 11 using App-V 5.0 with protected mode enabled will cause Adobe reader to fail within the App-V VE. This is why they don’t officially support it.

KB2900929 - Adobe only officially supports creating App-V 4.6 packages of Adobe Reader XI (https://support.microsoft.com/kb/2900929)

Providing a complete recipe for Adobe XI is beyond the scope of this article, however the issue I address here is how to troubleshoot DeploymentConfig scripts using Adobe XI as an example.

My customer was looking for a method to set the following registry key to 0 using the DeploymentConfig file as described in Scripting and Embedded Scripting for AppV 5.0 (Dynamic Deployment and User Configuration Scripting).

\HKLM\Software\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown\bProtectedMode=0

My thought when this issue was first presented was what is the best technique to troubleshoot 5.0 package script failures? Of course I am going to use Process Monitor, but what else do I need? I had been playing with TMurgent Technologies’ AppV Manage Client tool and found it very useful, and I noticed on the publishing tab of the tool it has an Add WithCfg button – interesting.

Before we get too far though, first a little about the tool. It can be found at the URL below and the only configuration required for the purpose of this article is to point it to a content share that contains the package you want to troubleshoot. This can be configured during the install or post install. This tool is well documented and even has a 13 minute demo video to get you started.

AppV_Manage: A Client Tool for App-V 5 (https://www.tmurgent.com/Tools/AppV_Manage/Default.aspx)

Post install content share configuration:

Troubleshooting the issue

Once AppV Manage is installed and the content share configured as shown above, on the Publishing tab find the package you want to test. In this case it is the Reader XI (11.0.05) DSC_13 package.

Click on Add WinCfg. When doing so, the first error I received is the following:

Searching on the error above, I found the following article:

KB2778945 - Importing a deployment configuration file on App-V v5 fails with "The configuration file does not contain well formed AppV configuration XML" (https://support.microsoft.com/kb/2778945)

Following the article above, I searched both the UserConfig.xml and DeploymentConfig.xml files in the package for the TakeoverExtensionPointsFrom46 tag but did not find one. Taking the error at face value I assumed that my customer has added some invalid XML syntax to the DeploymentConfig.xml file since this is where I found his Reg-Add-Config.ps1 referenced. I also noticed that he tried to implement this registry key using the Machine Wide Virtual Registry tags highlighted below below:

Machine Wide Virtual Registry

-->
< Registry>

To rule out these tags, I commented out this section using the XML comment tags  (end comment), and to make the tags easy to find later I add my initials JFB as seen below.

So after doing that I tried to deploy the package again by highlighting the package and clicking on the Add WithCfg button again. Doing so I received a different error:

[MS1]

The error was “Please either enable embedded scripting for this client (to run the script), or modify the script definition for this package to set rollback on error to false (in which case the script will be still disabled and ignored) .”

Once again, if we take this error at face value, this indicates that EnablePackageScripts is not enabled on our App-V 5.0 Client. Using the Get-AppvClientConfiguration PS cmdlet we can determine if this parameter is enabled:

Apparently it is not set so let’s set it:

Then just to be sure, let’s verify that it is set:

AppV Manage also displays the EnablePackageScripts setting on the Client Config tab – very nice:

Now that this requirement is met, let’s try to deploy the package again. This time we receive a different failure:

When checking the AppV Client Event log for more details as suggested in the error above, we find this:

The error mentions something about Rollback set to true, and if we look at the custom script tags in the MachineScripts section of the of the DeploymentConfig we will find rollback set to true. Obviously something is still failing and rolling back, so I tried setting rollback to false to see if the deployment proceeded any further. To do this I changing the following:

BEFORE

<MachineScripts>
< PublishPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Scripts\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="true" Timeout="30"/>
< /PublishPackage>
< AddPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Scripts\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="true" Timeout="30"/>
< /AddPackage>
< /MachineScripts>

AFTER

< MachineScripts>
< PublishPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Scripts\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="false" Timeout="30"/>
< /PublishPackage>
< AddPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Scripts\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="false" Timeout="30"/>
< /AddPackage>
< /MachineScripts>

Once the RollbackOnError tags were set to false I clicked on Add WinCfg again, This time it published the application successfully but it didn’t modify the desired registry keys. If we check the AppV\Client\Admin event log we find this:

AppV Manage indicates that Reader XI is publish to users by placing a U in the Pub? Column:

Now that the package will publish we can add Process Monitor tracing and see what it reveals. What I like about AppV Manage is the ability to simply click a button to deploy a package which allows me to quickly click Capture in Process Monitor and then immediately click Add WithCfg if you arrange the tools up like so:

This arrangement allows you to quickly capture just what you need – click Capture then Add WithCfg

Since we know that the script is failing to run and we know the extension of the script is .ps1, we can create a filter in Process Monitor to only show us files in the trace that have a .ps1 extension. To do this, click on the diamond icon on the Process Monitor tool bar and create the following filter and click apply and OK.

Here is the output from the filter above:

Here is the specific event we are concerned about:

9:49:59.0126541 AM powershell.exe 3620 CreateFile C:\ProgramData\App-V\BC1029CC-E544-42C7-929B-357C250B9C6E\61DD6D5B-E6FC-4563-AA89-C3A83FFB7890\Scripts\Scripts\Reg-Add-Config.ps1 PATH NOT FOUND Desired Access: Read Attributes, Disposition: Open, Options: Open For Backup, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a

According to the blog post referenced earlier we are referencing the script directory correctly.

This is the example given in the “Referencing script collateral” section of the blog:

<PublishPackage>
< Path>powershell.exe </Path>
< Arguments>.\Scripts\InstallDriver.ps1 </Arguments>
< Wait RollbackOnError="true" Timeout="120"/>
< /PublishPackage>

If you recall above this is Machine scripts section of the DeploymentConfig file:

< MachineScripts>
< PublishPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Scripts\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="false" Timeout="30"/>
< /PublishPackage>
< AddPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Scripts\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="false" Timeout="30"/>
< /AddPackage>
< /MachineScripts>

Now I wonder what happens if we remove the .\Scripts from the path so I changed the snippet above to:

< MachineScripts>
< PublishPackage>
<Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="false" Timeout="30"/>
< /PublishPackage>
< AddPackage>
< Path>powershell.exe</Path>
< Arguments>-ExecutionPolicy ByPass -File .\Reg-Add-Config.ps1</Arguments>
< Wait RollbackOnError="false" Timeout="30"/>
< /AddPackage>
< /MachineScripts>

I removed and published the package again using the AppV Manage tool, and this time when I checked the policy registry hive HKLM\Software\Policies I noticed that the script added the Adobe policy hive to the Polices key of the Client registry:

SUMMARY

So in summary, we made the following changes to the DeploymentConfig file:

1. We commented out the Machine Wide Virtual Registry section.

2. We changed the RollbackOnError tag from true to false.

3. We changed the path referencing the script from .\Scripts\Reg-Add-Config.ps1 to .\Reg-Add-Config.ps1.

Note that once the correction in step 3 was made I was able to return the RollbackOnError setting to true and the script continued to work as expected.

A Best Practice when troubleshooting is to only test one change at a time. What made this issue difficult to troubleshoot was the fact there were multiple configuration errors in the DeploymentConfig file. We recommend that you only test one implementation at a time, and once it works then move on to the next setting. Don’t try to test more than one configuration change at a time.

I mentioned AppV Manage here but you might want to look at some of the other free tools at Murgent Technologies, LLP. Of course these tools are not provided or tested by Microsoft and we make no warranties regarding them in any way, nor do we support their use, however here are a few of my favorites that you might find useful as well:

OSD Illustrated: OSD Illustrated is probably the best OSD tag reference around. This is a 4.X tool.

ScriptLauncher for App-V 5 : ScriptLauncher is a free tool designed to make it easier to use scripts on Microsoft App-V 5 virtual application package that require scripts. It overcomes a few environment variable issues when using deployment scripts.

If you run into App-V performance issues this tool may also come in handy.

xPerf Profile for App-V 5 Client

Happy troubleshooting!

John Behneman | Senior Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter :

System Center All Up: https://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: https://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: https://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: https://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: https://blogs.technet.com/momteam/
System Center – Service Manager Team blog: https://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: https://blogs.technet.com/scvmm

Windows Intune: https://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: https://blogs.technet.com/sus/
The AD RMS blog: https://blogs.technet.com/b/rmssupp/

App-V Team blog: https://blogs.technet.com/appv/
MED-V Team blog: https://blogs.technet.com/medv/
Server App-V Team blog: https://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : https://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : https://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: https://blogs.technet.com/b/isablog/
The Forefront UAG blog: https://blogs.technet.com/b/edgeaccessblog/

How to troubleshoot App-V 5.0 DeploymentConfig & UserConfig script deployment failures using AppV Manage

Troubleshooting the issue

SUMMARY

Additional resources