Mouse freezes on VDI machines: A surprising solution

Bild des Benutzers Clemens Geiler

The other day at my customers’ site I had a call coming from a user, who complained about losing her mouse on a Win7 VDI Machine completely. Keyboard would still work, mouse would work again after logging off and back on. As she started her AppV 5 Console to reload some AppV apps the mouse input stopped working. Hmmm.

Quick-googling for according tags tells me the following:

Disable TabletInputService, remove read-permissions for user and administrators from c:\windows\system32\wisptis.exe

Apparently we are dealing with a bug related to .NET and Silverlight. As soon as a local application uses Silverlight the TabletInputService tells wisptis.exe to take over Input and steal it from the Mouse. Wisptis.exe hosts the IH-Ink-Support Feature, as such it’s just doing its Job as it seems.

Since we are in an automated environment with SCCM, I had to write a script to fix that behavior.
Hahaha, easy. (Well I could just have renamed the above file, but I don’t like to do stuff like that).

No. Not easy!

Wisptis.exe is owned by TrustedInstaller. In SCCM my script runs as “System”.

Taking ownership using

$objuser = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN","$env:USERNAME")
$objfile = get-acl (Join-Path $(Join-Path $env:windir system32) wisptis.exe)
$objfile.SetOwner($objuser)
set-acl -AclObject $objfile -path $objfile.Path -ea SilentlyContinue

does not work.

Setting NTFS Permissions using

$UserPermission = "VORDEFINIERT\Users","ReadAndExecute","Deny"
$AdminPermission = "VORDEFINIERT\Administrators","ReadAndExecute","Deny"
$UserAccessRule = new-object System.Security.AccessControl.FileSystemAccessRule $UserPermission
$AdminAccessRule = new-object System.Security.AccessControl.FileSystemAccessRule $AdminPermission
$objfile.SetAccessRule($UserAccessRule)
set-acl -AclObject $objfile -Path $objfile.path
$objfile.SetAccessRule($AdminAccessRule)
set-acl -AclObject $objfile -Path $objfile.path 

does not work either.

set-acl : Attempted to perform an unauthorized operation.

The reason here is related to the fact that I not only don’t own the file but additionally TrustedInstaller is the owner. This above code works with files that are not owned by TrustedInstaller.

A bit later my old Colleague Helge Klein, who wrote setacl.exe back in the days, returned to my mind. It’s a while ago, that I used setacl and I remembered the not exactly intuitive syntax. Fearless I figured out that setacl would be the only tool being able to do the Job properly. It’s able to take ownership from TrustedInstaller as well as setting proper NTFS permissions in just one step. This is cool. Look at the following line:

SetACL.exe -on $filepath -ot file -actn setowner -ownr "n:$mySID;s:y"

I'm using $mysid from the snippet above, here just for your notice again:

$objuser = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN","$env:USERNAME")
$mySID = $objuser.Translate([System.Security.Principal.SecurityIdentifier]).value

This simply works. With the next line I remove all DACLs, reset them and give TrustedInstaller back ownership

SetACL.exe -on $filepath -ot file -actn clear -clr DACL -actn ace –ace "n:$SIDSystem;p:full;s:y;i:so,sc;w:dacl" -ace "n:$SIDTrustedInstaller;p:full;s:y;i:so,sc;w:dacl" -actn setowner -ownr "n:$SIDTrustedInstaller;s:y" 

Btw: TrustedInstallers’ SID is a well-known one. It’s the same on all systems and easy to remember as well. Nevertheless I write it down for you right here:

$SIDTrustedInstaller = "S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464"

Kommentare
wisptis
Not sure it solves this issue, but adding wispts to the App-V object exclusion registry solves most App-V / wispts issues.
Neuen Kommentar schreiben
Durch Absenden dieses Formulars akzeptieren Sie die Mollom Privatsphärenrichtlinie.