~ Lars Iwer | Consultant II
Here’s a quick tip on an interesting issue I saw the other day where a client was unable to open the Microsoft Application Virtualization 5.0 Service Pack 1 client GUI. Double-clicking on the system tray icon had no visible effect and instead, error events 1026 followed by event ID 1000 and 1001 got logged to the event log under Applications and Services\Microsoft\AppV\Client in the Operational Log:
Event 1026 contains a System.Windows.Markup.XamlParseException caused by AppVClientUX.exe
Event 1000: Faulting application name: AppVClientUX.exe […] Exception code: 0xe0434352
Additionally, App-V 5.0 SP1 packages distributed through System Center 2012 Configuration Manager would not install successfully but instead time-out. Looking at AppEnforce.log on the client shows that the installation stops when executing this command:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass import-module ‘C:\Program Files\Microsoft Application Virtualization\Client\AppvClient\AppvClient.psd1’; Get-AppVClientPublishingServer | Remove-AppVClientPublishing Server
The PowerShell execution policy was configured via group policy to „AllSigned“.
This leads to PowerShell trying to verify a module’s publisher before running it. The App-V client commandlets are signed but the publisher is not included in the “Trusted Publishers” certificate store by default (both for system and user).
An interactive PowerShell session asks the user for confirmation if the publisher should be trusted. When the user selects “Always run”, the code signing certificate used to sign the module is added to the “Trusted Publishers” certificate store of the current user.
This confirmation leads to the System Center 2012 Configuration Manager timeout since it is waiting for an interactive input.
1. Change the PowerShell Execution Policy
The simplest way to get the App-V client GUI and System Center 2012 Configuration Manager App-V package distribution working is to change PowerShell’s execution policy to a less restrictive setting (e.g. “RemoteSigned”). However, usually there is usually some corporate policy or other valid business reasons for setting the policy to “AllSigned” in the first place. This leads to the second, preferred solution:
2. Install the Code Signing Certificate
The following steps show a way to distribute the code signing certificate used to sign the App-V Client PowerShell module.
1. Add the code signing certificate to the current user’s “Trusted Publishers” certificate store.
a. Launch a PowerShell session on a client where the App-V client is installed.
b. Run Import-Module AppVClient:
This should bring up the question above which should be answered Always Run.
2. Export the code signing certificate from the user’s certificate store.
a. Run certmgr.msc and navigate to “Certificates – Current User”, “Trusted Publishers”, “Certificates”.
b. Right-click on the certificate issued to “Microsoft Corporation“ issued by “Microsoft Code Signing PCA“ and select All Tasks, Export.
c. Export the certificate as DER encoded binary X.509 (.cer)
3. Deploy the code signing certificate via Group Policy
a. Edit a fitting Group Policy Object Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Publishers (see http://technet.microsoft.com/en-us/library/cc770315(v=WS.10).aspx).
b. Right-click and select the menu item Import.
c. Import the certificate exported in step 2.
After updating the group policy on the client (e.g. using gpupdate /force) the code signing certificate should be present in the system’s “Trusted Publishers” Certificate store. Now it is possible again to launch the App-V client GUI and distribute App-V packages using System Center 2012 Configuration Manager successfully.
Lars Iwer | Consultant II | Microsoft Corporation
System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm
The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/