Office 365, App-V and Windows 10 – 1607

Oh, the joy of reusing technology. Office 365 leverages the App-V technology, however slightly modified and primarily used as a delivery method with no isolation. App-V in comparision is used more for its isolation and to be honest – not so much for its delivery mechanism.

In addition – since Windows 10 – 1607 the App-V client is now a Windows Feature.

Now, for fun – lets try these steps;

  1. Install Windows 10 – 1607
  2. Install any version of Office 365 ProPlus

Find a Visio drawing and open it. Most likely it will be opened with the Visio Viewer – which is a component part of Office 365 ProPlus. Visio Viewer is just an ActiveX component and will therefore load the drawing inside Internet Explorer 11.

image

let’s add a third-step to this process….

3. Open an elevated Powershell prompt and type Enable-AppV. Press the enter-key
image

Once you attempt to re-open the Visio-drawing you will most likely see a blank Internet Explorer-page instead of the Visio Viewer ActiveX component. The below is from a minimal window.

image

All Microsoft components and suddenly we have a break scenario? The details are actually clarified in a knowledgebase-article relating to Skype for Business, Internet Explorer and App-V;

By default, Explorer.exe and Internet Explorer are listed there. Therefore, when the iexplore.exe process runs, it has the APPVEntsubsystem32.dllloaded in Internet Explorer. When Office C2R detects that APPVEntsubsystem32.dll is loaded into Internet Explorer, it does not load jitv.dll or APPVISVSubsystem32.dll into Internet Explorer. As a result, there is no registry redirection support.
When the JavaScript that’s running in Internet Explorer tries to create any ActiveX objects that are part of the Office C2R package, that operation fails and the Office C2R and SharePoint integration are broken. Office C2R and App-V dynamic virtualization aren’t designed to co-exist; therefore, Office C2R disables Dynamic Virtualization when it detects that AppV client binaries are loaded in Internet Explorer to prevent double hooking.

The article unfortunately provides no fix for a Windows 10 – 1607 unless someone is wanting to decrease the feature set for App-V. Browsing the web allows a little gem to be spotted in the comment section of Dan Gough’s amazing blog – the comment is from an Andrew G:

and also there is a registry key suggested by MS:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ClickToRun\OverRide
keyname=AllowJitvInAppvVirtualizedProcess (reg_dword)
keyvalue=1

Searching for this registry key on google presents only a few results (one spiceworks thread) are found. A hidden gem, I presume?

Add the registry key and immediately the Visio drawing can be opened without issues

image

2017-08-22 Update

According to Roy Essers – these registry keys will be automatically created on Windows 10 – 1703

App-V 5 and publishing error code: 040000002C.

A minor defect that causes a publishing failure for any packages (only tested for publishing towards a user though. The error code looks like this;

Publish-AppvClientPackage : Application Virtualization Service failed to
complete requested operation.
Operation attempted: Publish AppV Package.
AppV Error Code: 040000002C.
Error module: Virtualization Manager. Internal error detail: 4FC086040000002C.

There seems to already be a few discussions online that assists in resolving the with a few different methods – one seems to suggest to delete a registry key and there is a one that contains a more granular approach by resetting the registry values under LocalVFSSecuredFolders.

A correct view is that each SID under this registry key references the %USERPROFILE%.

image

and incorrect (and the cause of the error) references the Default-user profile

image

A quick script (which you can wrap in a Compliance Item or a script – or whatever the preference is..) to remediate this. The actual fix (Set-ItemProperty) is prefixed with # – please test it before you deploy it.

$users=@()
$return = 0
$users = ($k = gi HKLM:\SOFTWARE\Microsoft\AppV\client\Virtualization\LocalVFSSecuredUsers).GetValueNames() | % {

New-Object PSObject -Property @{

Name = $_

Type = $k.GetValueKind($_)

Value = $k.GetValue($_)

} | select Name, Type, Value

}

foreach ($u in $users) {
if ($u.value -eq 'c:\users\Default\AppData\Local\Microsoft\AppV\Client\VFS') {
$return = 1
#Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\AppV\client\Virtualization\LocalVFSSecuredUsers' -Name $($u.Name) -value '%USERPROFILE%\AppData\Local\Microsoft\AppV\Client\VFS'
}
}
$return

 

 

Per the above forum post this should be resolved within App-V 5.0 SP3, however I have still seen minor occurances for later releases – so I wouldn’t call that a  confirmed fix.

Acrobat XI and App-V 5 – 2015

I previously wrote a few blog-articles for Acrobat XI and App-V 5, however I thought I would condense the information into a single-post. So, tag along with how you get Acrobat working with App-V 5.

Adobe Customization Wizard XI

Adobe Customization Wizard is a generic tool to edit one type of Acrobat deployment. I previously used (and recommended) leveraging the Adobe Creative Cloud Packager, however there are limitations with the CCP and the ACW has been updated for every version of adobe (currently at the Document Cloud edition).

CCP offers some basic settings (disable updates) and in the end it will actually wrap the MSI into the Adobe lipstick-on-a-pig-approach of deployment.

Settings to consider for your package;

Installation Options

Caching of installation-files should be disabled. This will increase the package size with roughly about ~500mb when its enabled.

image

Registry

To avoid excessive overhead when starting the Virtual Environment there are two Run-registry keys that are removed from the package

image

In addition you should remove the ability for the end-user to trigger a repair of Acrobat from the help menu. This registry key should be added to disable the Repair-menu option.


[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adobe\Adobe Acrobat\11.0\Installer]

"DisableMaintenance"=dword:00000001

Shortcuts

Cleaning up shortcuts is a good idea and completely removing the shortcuts on the Desktop is a not to unusual enterprise practice.

image

Online Services and Features

Just disable everything in the Online Services and Features view, however quite a few of the settings here will not be captured within the App-V 5 package. We will touch on this later on…

image

Properties

You can set the installer to not install the Adobe Updater services based on the information in their Enterprise Guide. Set the DISABLE_ARM_SERVICE_INSTALL to 1

Reproducible installation

In the end of this process you should have a generic MSI-package along with a specific MST-file that contains your predefined settings. In addition to the settings there are numerous patches for Acrobat. Gather up all of them and ensure that we create a simple file to install all of them in a single run. This is a sample approach containing all but the two latest patches, that I will save in a simple-to use batch file (crude, but does the job).

msiexec /i "%~dp0vc10rt_x64\vc_red.msi" /qb /norestart

msiexec /i "%~dp0acropro.msi" /qb TRANSFORMS=customer.mst
msiexec /p "%~dp0AcrobatUpd11001.msp" /qb /norestart

msiexec /p "%~dp0AcrobatSecUpd11002.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11003.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11004.msp" /qb /norestart

msiexec /p "%~dp0AcrobatSecUpd11005.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11006.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11007.msp" /qb /norestart

msiexec /p "%~dp0AcrobatSecUpd11008.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11009.msp" /qb /norestart

msiexec /p "%~dp0AcrobatUpd11010.msp" /qb /norestart

The not App-v 5 part of the deployment

Policies

As stated previously there are somethings that will not be part of the final package. A sample of those are the settings that will limit some Acrobat UI options. Like Updates for example. The reason for this is how Adobe handles these settings. In their wisdom they have (correctly) placed the settings in the registry under a specific key named Policies. App-V 5 will (per default, can be reconfigured) exclude these keys from the virtual registry. Regardless of what is in the package this exclusion happens at the client; this leaves the option of either remove the exclusion (or pass-through as its named) for the client and thereby all packages or to set the natively, or to set them natively. Personally, this is where we go for Group Policy as this is really a setting that should be enforced, however; any and all means for getting a registry key set on the client is fair game.

Registry keys are as follows on a x64-system;

HKLM\Software\Wow6432Node\Policies\Adobe\Adobe Acrobat\11.0\FeatureLockDown

image

Printer

App-V 5 can’t handle drivers and in terms of the Acrobat package there is a specific need to install a printer (aka Distiller) to enable loads of the functionality provided by Acrobat. The printer can not (easily at least) be extracted from the Acrobat installation package, however it is available in the XI-version from other installation packages such as FrameMaker or RoboHelp. There is a minor tweak necessary that was detailed in the previous blog post. Repeating again; This printer needs to be deployed seperately and outside of the App-V 5 sequence. Any means that you have at your disposal will of course to install the driver. One route is to use Dependencies within ConfigMgr, a different route is to install it as a script during the deployment of the App-V 5 package.

App-v 5 sequencer setup

Prerequisites

Acrobat will integrate to quite a few different applications and therefore it is vital that these are installed on your sequencer before you start sequencing to avoid issues in the long run. If you want Acrobat to integrate with an application the recommendation is to install it as a prerequisite on the sequencer. Here is the sample used:

Platform
Windows 7 x64
Applications
.NET Framework 4.0
App-V 5.0 SP2 sequencer
Microsoft Office 2007 SP2
Adobe Illustrator CC 2014
Adobe Photoshop CC 2014

Exclusions

There are exclusions that are required for the application to work, and others will just make your life easier. Here is the list as written previously

C:\programdata\adobe\slstore

REGISTRY\USER\[{AppVCurrentUserSID}]\Software \Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem

REGISTRY\USER\[{AppVCurrentUserSID}]\Software \Microsoft\Windows NT

REGISTRY\USER\[{AppVCurrentUserSID}]\Software\Microsoft\Office\15.0

Decision time

To PVAD or not to PVAD, that is the question. PVAD stands for Primary Virtual Application Directory. If you have been tagging along since the Softgrid days this is the new way to have the Q-drive discussion. Multiple rants have been given about its usage and I have aggressively proclaimed that you should avoid it. However, if you want to use it you should know why you want to use it. And here comes the why in this instance. (as you notice there is an avoidance of explaining what it actually does. Noone is certain, it does give the user full-write access to that directory. Unless you enable VFS-write. Therefore its existance is something you will discover while sequencing with older versions of the sequencer – not in App-V 5.0 SP3 which is the latest – as the option is removed by default in the latest version.

Adobe has an appaling installation method and Acrobat is actually the better part of this, however their licensing engine is far worse. In part of getting their licensing engine operating without issues the user (regardless of their permisson level on the system in question) must posses write-abilities to quite a few directories. App-V 5 RTM and quite a bit along the way was a bit step backwards in terms of functionality when it comes to permissions, and not until the App-V 5.0 SP3 release was there a suistainable way forward. So,

Pre App-V 5.0 SP3
PVAD:

C:\Program Files (x86)\Common Files\Adobe\Adobe PCD

In addition, the directory has to natively exist and the end-user must have full permissions to it.

Post App-V 5.0 SP3
Enable full Virtual Filesystem Write.

The first scenario is extensively tested. The second scenario is a logical continuation, however not extensively tested.

Sequencing

Run your bat-file

Start Acrobat once, and then close it. Stop sequencing. Enable all COM and named objects interaction. Save your sequence.

Post-sequencing

To enable full-functionality you are required to publish the package globally. A global publication will enable full usage of the Internet Explorer plugin. In addition you are required to enable the integration between any applications that have Acrobat plugins – such as Office applications.

Sample way for Outlook;

reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\outlook.exe /ve /d XXX_YY /f

Easiest way? Do this when the publishing action occurs. Create the below sample code for the Deployment Configuration-file. Of course, to create beautiful XML like the part below use the Virtual Engine ACE.

 <MachineConfiguration>
 <ProductSourceURLOptOut Enabled="true" />
 <Subsystems>
 <Registry />
 </Subsystems>
 <MachineScripts>
 <PublishPackage>
 <Path>CMD.EXE</Path>
 <Arguments>/c reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\winword.exe /ve /d XX_YY /f | reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\excel.exe /ve /d XX_YY /f | reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\powerpnt.exe /ve /d XX_YY /f | reg add HKLM\Software\Microsoft\AppV\Client\RunVirtual\outlook.exe /ve /d XX_YY /f</Arguments>
 <Wait RollbackOnError="false" />
 </PublishPackage>
 <UnpublishPackage>
 <Path>CMD.EXE</Path>
 <Arguments>/c reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\outlook.exe /f | reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\winword.exe /f | reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\excel.exe /f | reg delete HKLM\Software\Microsoft\AppV\Client\RunVirtual\powerpnt.exe /f</Arguments>
 <Wait RollbackOnError="false" />
 </UnpublishPackage>
 </MachineScripts>

 

Known issues

Using the Review Tracker fails to start. Within the installer this is known as the Synchronizer. Not entirely sure why this happens and haven’t spent (any) a lot of time troubleshooting it.

(this can be found under View –> Tracker)

App-V 5 Upgrade without a reboot

This will most likely need to be tested for each version of a potential App-V 5 upgrade, but lets clarify the issue.

When upgrading the App-V 5 client there are some nasty behaviors that cause grievances among users. Since App-V 5 is a middle-man there has been a personal hope that Microsoft would have addressed the upgrade path to offer the same seamless and smooth experience that for example Internet Explorer, Office or general Windows components offers.

What’s the issue?

  1. Install App-V 5 version old
  2. Deploy a few applications, get the users productive
  3. Version new of App-V 5 is released and of course this resolves some issues you have experienced
  4. Manually or in an automated manner install the new version.
    All running virtual applications will be terminated
    After the upgrade and until a restart has been completed no applications can be started

The impact of running the App-V 5 version new upgrade when a user is active on the machine is rather frightening and will decrease the end-user productive. Terminating active virtual applications would stop most change management, but halting productivity until a reboot is of course a deal-breaker.

Depending on your scenario this issue might be able to workaround using processes alone, however in a road-warrior type of world where devices are laptops and either used or offline the ability to control the upgrade path to minimize user friction is of course limited.

Since two thirds of the worlds corporate Windows client estate is managed by Configuration Manager there are certain abilities to ensure that something is not installed while a user is active on the client. The client would become aware of what needs to be executed, download the necessary files and then would not start the install until the following condition is met;

image

The issue that still stands is that even though the new App-V 5 version new is installed the user can not start the virtual applications (or interact with the client) until the device is restarted.

It seems that the to avoid a scenario where the device drivers loaded into the system should not be different than service running the upgrade will stop the service. There may of course be issues, however running with this version difference (services vs drivers) within a limited time frame is a minor risk if it allows a gradual upgrade path and setting a new standard baseline for the App-V 5 client version

So, run the App-V 5 upgrade;
appv_client_setup.exe /ACCEPTEULA /CEIPOPTIN=0 /MUOPTIN=0 /ENABLEPACKAGESCRIPTS=1 /AUTOLOAD=0 /q /norestart

Start the App-V 5 client service:
net start appvclient

The user can then restart in their own time and hopefully everything should be running without any major hiccups. Obviously – this is very unsupported.

App-V 5 Deployment Type fails to import in ConfigMgr

After creating a package of Adobe Captivate 8, validating that it runs as expected in a standalone scenario an obstacle come up during the import-process into the App-V 5 Deployment Type into System Center Configuration Manager 2012 R2.

Error code was very generic and only gave a vague reference:

image
Object reference not set to an instance of an object

Reviewing the activity with Process Monitor only revealed that the before the error occurred the appv-file was parsed. Obviously something within the file itself was generating this error.

No other application spawned the same behaviour, and regardless of how the application was sequenced (different OS, sequencer PVAD etc) the same error always came back.

Based on Microsoft supports reply it seemed to boil down to the fact that a package contained two files with the same name: AppXManifest.xml

The installer for Adobe Captivate generated this file in the following folder;
ProgramfilesCommonX64\Adobe\Adobe Captivate 8 app Packager\assets\AppxManifest.xml

The second file is the generic AppXManifest.xml generated by the sequencer that contains information of howto publish the application.

Workaround: Delete the second instance (not App-V 5 sequencer generated) copy of the file.

App-V 5.0 SP3 and remote SQL

As App-V 5.0 SP3 has been released it is not only the client that gotten an update, but the App-V Server components has gotten a fresh new installer for the first time since App-V 5.0 SP1.

If one is working in a locked down environment where the roles of server and databases are seperated, and databases might be located on a shared SQL-hotel that no ordinary administrator is allowed access to – the question that rises is how does one get the database up 2 speed?

According to the notes the only supported scenario is to run from the installer provided by App-V 5.0 SP3, and what that is can be debated, which no SQL admin would dream about.

If executing the appv_server_setup.exe with the switch /layout there will be a folder extracted named database scripts.

Looking at the contents (in databasescripts) in App-V 5.0 SP3 and comparing that to the contents of App-V 5.0 SP1 – the files look fairly much the same;

image

When comparing the contents of the files the following differences emerge;

Createtables.sql


CREATE TABLE dbo.PackageGroupMembers (
Id                              int PRIMARY KEY IDENTITY,
PackageGroupId                  int NOT NULL,
PackageVersionId                int NOT NULL,
LoadOrder                       int NOT NULL,
<em>PackageOptional                    bit NOT NULL DEFAULT 0,
VersionOptional                    bit NOT NULL DEFAULT 0</em>
)

CREATE TABLE dbo.SchemaVersion (
Version                       int NOT NULL
)

InsertVersionInfo.sql


SELECT @minserviceversion = N'5.0.10107.0'
SELECT @dbversion  = N'5.0.10107.0'

And finally, looking at updates.sql – you can notice that there are some major changes. For example;

to begin with;


-- Replace SchemaChanges table with SchemaVersion table
RAISERROR('Removing SchemaChanges table', 0, 1) WITH NOWAIT
GO
IF (EXISTS (SELECT * FROM [INFORMATION_SCHEMA].[TABLES] WHERE [TABLE_NAME] = 'SchemaChanges'))
BEGIN
DROP TABLE [SchemaChanges]
INSERT INTO [SchemaVersion] VALUES (1)
END
GO

and continue with;


-- Add PackageOptional and VersionOptional columns to PackageGroupMemebers table
ALTER TABLE PackageGroupMembers ADD PackageOptional bit NOT NULL DEFAULT 0, VersionOptional bit NOT NULL DEFAULT 0

and


-- Erase the current schema version from the SchemaVersion table (the new current version will be written during the install)
RAISERROR('Removing current schema version', 0, 1) WITH NOWAIT
GO
DELETE FROM [SchemaVersion]
GO

It seems that all the changes to the database are actually contained in updates.sql and createtables.sql.

It seems that the below commands are suffice. All of this is just gathered information from the Microsoft provided scripts on howto setup a clean database.


CREATE TABLE dbo.SchemaVersion (
Version                       int NOT NULL
)

INSERT INTO [SchemaVersion] VALUES (1)

-- Add PackageOptional and VersionOptional columns to PackageGroupMemebers table
ALTER TABLE PackageGroupMembers ADD PackageOptional bit NOT NULL DEFAULT 0, VersionOptional bit NOT NULL DEFAULT 0
-- Update SchemaVersion table to version 2
DELETE FROM [SchemaVersion]
INSERT INTO [SchemaVersion] VALUES (2)

DELETE FROM [SchemaVersion]

Once this is completed, head on over to your App-V Management Server. install the .NET Framework 4.5.1

Then install the new App-V 5.0 SP3 bits – first the Management Server. Then the Publishing server. After that you are all done!

You can verify that your servers are operational by simply accessing their respective website. if anything odd shows up – check the event logs under Microsoft\App-V

App-V 5, ConfigMgr compliance and fixes

App-V 5 has recently gotten hit by two odd behaviors relating to an update and .NET Framework 4.5.2.

KB2984972 was released as an update for RDC, and caused some havoc both for App-V 4 and App-V 5. The workaround is documented in the article and essentially allows anyone to remove the unfortunate end-user experience by adding some registry keys.

.NET Framework 4.5.2 was released and quite early on people started noticing that a freeze could be experienced when using certain App-V applications. The culprit seems to be the processes wisptis.exe, and the issue could temporarily be worked around by terminating the process.

App-V 5 got hit by two issues that both were resolved by adding registry keys under the registry key ObjExclusions. The Gladiator has written an article that details more about this registry key, the purpose of it and the effects of it. The article is focused on App-V 4, however the knowledge and concepts still apply to App-V 5.

Under (HKLM\Software\Microsoft\AppV\Subsystem\ObjExclusions) this registry key there are a lot of registry keys starting at 1 and going upwards. Each registry key contains a value (oh, really?) that is the name of an object that is not virtualized.  Anyone can append new values by using the next available number. Aaron Parker wrote a great article on howto leverage Group Policy to add the requested registry keys to resolve the issues for KB2984972.

Let’s detail the fun fact about this registry key;

There are in a default installation of App-V registry keys from 1-92. On any given default installation the next available number we can use is 93. We now have two issues and would therefore end up with two extra registry keys (93 and 94). My guess is that Microsoft might potentially include these two above recommended registry keys in a future installation of App-V when a new version comes out. Forcing these values to be added to a specific number in the series could potentially throw other valuable exclusions out the window…

Therefore I personally voted against Group Policy (Preferences) and decided to go the route of ConfigMgr Compliance Settings.

By creating a configuration item I can achieve the following;

Detect if the specific value is already in the list
Find the next available number to create a new registry key in
Append the value if it doesn’t already exist.

In the end, this is what I came up with;

appv_ci

Detect if the App-V client is installed;

appv_detection

Two checks for each specific registry key;

appv_check

Create a rule set that will allow for remediation;

appv_wsptis

Scripts part of the Configuration Item. This sample is from the fix for KB2984972.

Check:

$regKey = "HKLM:\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions"
$p = Get-ItemProperty $regKey
$kb2984972 = $p.PSObject.Properties | where { $_.Name -match "[0-9]" -and $_.Value -eq "TermSrvReadyEvent" } | select-object -ExpandProperty Name -ErrorAction SilentlyContinue

if(($? -and ($kb2984972 -ne $null))) {
1
}
else {
-1
}

Remediation:

$regKey = "HKLM:\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions"
$p = Get-ItemProperty $regKey
$topvalue = $p.PSObject.Properties | Where-Object { $_.Name -match "[0-9]" } | Sort-Object -Property Name -Descending | Select-Object -first 1 -ExpandProperty Name
$topvalue = 1 + $topvalue

Function New-RegistryKey([string]$key,[string]$Name,[string]$type,[string]$value)

{

#Split the registry path into its single keys and save

#them in an array, use \ as delimiter:

$subkeys = $key.split("\")

#Do this for all elements in the array:

foreach ($subkey in $subkeys)

{

#Extend $currentkey with the current element of

#the array:

$currentkey += ($subkey + '\')

#Check if $currentkey already exists in the registry

if (!(Test-Path $currentkey))

{

#If no, create it and send Powershell output

#to null (don't show it)

New-Item -Type String $currentkey | Out-Null

}

}

#Set (or change if alreday exists) the value for $currentkey

Set-ItemProperty $CurrentKey $Name -value $Value -type $type

}

New-RegistryKey $regkey $topvalue "String" "TermSrvReadyEvent"

As a final treat. Here is the Configuration Item – ready to be imported into ConfigMgr.

 

2014-12-07 – Sebastian Gern stated an additional registry key for WISPTIS. The Configuration Item is also updated with the new settings.

AVE: Scripting

This is just some details that showed themselves while using AVE to insert a script for an App-V 5 package.

You can choose to insert the script directly into the package, or to a configuration file.

image

When configuring the script you can easily choose the context of the script, the triggers and howto await the completion of the script.

image

Triggers for machine context are;

image

For use context

image

The “Do not use encoded executable paths” simple toggles the usage of App-V tokens on / off.

image

Regardless if you toggle this on or off – the title will always use App-V tokens.

image

What scripts you have added are easily seen from the contents of the virtual package

image

Thats it! Somethings that just makes life easier…

Application Virtualization Explorer

Kalle Saunamäki is a reallly deep dive kind of guy. He knows a lot about the App-V 4 filesystem, the App-V 4 client and now he is digesting the App-V 5 client.

image

How does one notice this? Well, he is the creator of the most amazing App-V 4 / 5 editing tool. Anyone doing any type of packaging for App-V needs this tool.

Convert

Have you previously tried converting packages from App-V 4 to App-V 5? Seems really as the process is the following;

  1. Install the sequencer on a dedicated VM
  2. Run PowerShell cmdlets to spit out a new package
  3. Open the package to, and save the package again to get all new virtual extensions.

AVE does this in a much faster and easier way. Simply choose to Import the 4.X package, and then save it as a brand new package. This can happen on any workstation you are using, even if you have the App-V client installed!

image

Whats in my package?

Have you wondered exactly what a package contains? As the sequencer only reveals the VFS and registry (and sometimes the shortcuts and FTAs), quite often you resort to reading the DynamicConfig-files that are produced in XML – after you save the package. And even when reading the XML-files trying to understand what will get published on a client – there are quite a few entries missing (shell extensions and browser plugins as a sample).image

AVE will immediately make this visible and more to that!

Services

How about this great feature! Did a service you captured get left out? You can import it and directly insert into the package;

image

App-v and wisptis.exe

Some applications that are virtualized with App-V 5 have caused issues with wisptis.exe –  a process to handle the input of pen-enabled devices. image

Symptoms

When an application that uses a .NET Framework(WPF, silverlight, SCOM / SCCM console, App-V UI etc) 4.5.2 is virtualized on any version of the App-V 5 client there is severe mouse-lag or hang.

Reproduce the issue

Connect a device which uses the Tablet Input service – most commonly Wacom-devices. Any WPF application based on .NET Framework 4.5.2 can cause the issue – for example using Chrome to access Outlook Web Access and then pressing “New message” (will use Silverlight) to generate a new email will spawn the wisptis.exe. The mouse freezes. If the process (wisptis.exe) is terminated mouse responsive will return to normal. The below is the process start of wisptis.exe

Process 5836 starting at 000000013F5AD9C8 C:\Windows\System32\wisptis.exe 11:24:08.939: [6388/6532] NtTerminateProcess( ProcessHandle=0x4f8, ExitStatus=0xc000042c ) => 0

The attempt to start this process fails with an STATUS_ELEVATION_REQUIRED code.

(credits to Paul Richards for the above info)

Public Workarounds

It seems that reverting back to .NET 4.5.1 has resolved the issue for quite a few people. If your application actually requires the .NET Framework 4.5.2 version that is of no use as a workaround. Installing the below hotfix may improve the issue aswell, however the successrate so far is low;

Mouse drawing is displayed incorrectly when the screen resolution is restored after a full-screen application stops on a Windows 7-based computer that has a multitouch screen installed

(while you are at it – apply this one aswell: Tablet PC Input Panel cannot be moved after you install update 2973201 in Windows 7 or Windows Vista )

Obvious workarounds

WISPTIS.exe is a process to handle the pen input, and therefore we can reduce our impact by completely disabling the the functionality. The policy can be find under;

User Configuration – Administrative Templates – Windows Components – Tablet PC – Cursor image

You can also disable it as a service (applicable on Windows 7 – named “Touch Keyboard and Handwriting Panel Service” for Windows 8): image

I haven’t personally confirmed this and so far this seems extremely intrusive as it completely disables the functionality for all applications.

Community discussed workarounds

WPF uses an interface, documented on MSDN, to determine if this is a tablet / touch enabled device. If you, inside the App-V 5 package while sequencing, edit the following registry key;

HKEY_CLASSES_ROOT\Interface\{C247F616-BBEB-406A-AED3-F75E656599AE}

Change the default value (to something else), and then set it to Override Local. image

This obviously breaks the input functionality, however only for the virtualized application.

(Thanks Paul Richards for the above suggestion – brilliant in so many ways)

Microsoft Support Solution – 2014-10-15

This is the Microsoft suggested solution. Apparently App-V makes an attempt to start a second process, and therefore the lag is experienced. Create the following registry key on the App-V client machine. Location:“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions” Type:       Reg_SZ
Name:     93
Value:     {773F1B9A-35B9-4E95-83A0-A210F2DE3B37}-running

The number 93 is used in this because 93 is the first available number in a default installation. This might be higher if your installation has more object exclusions.

Thanks Paul Richards for the update

Long-term resolution

Microsoft has released an informal article (Sebastian Gernert posted it), and as a far as we can see the recommended changes are available in App-V 5.0 SP3

Interesting topic

If you are a heavy user of Wacom hardware – see this guide of Vizibler that hopefully can improve your situation.