Quick Hit - ICA-TCP#0 and disconnected sessions

If you were to login to a Citrix server with your ID and you get ICA-TCP#0 as your session name, then disconnected your session, went to another computer and logged in (in the Metavision environment you don't assume the exisiting session -- you get a new one) you will actually take that sessionName "ICA-TCP#0" as the disconnected session made it available. If you reconnect to your disconnected session it will update the SessionName variable to ICA-TCP#1.

I bring this up because I was attempting to use this variable in the registry to determine a user's process list but it fails because of the disconnected session maintaining that same value.

AppV 5 - Unable to launch applications but other users can launch without issue

We have AppV 5 SP2 HF4 installed on a Citrix PVS server with our AppV PackageInstallationRoot redirected to a static drive.  I recently updated the PVS server than found my account could not launch AppV applications but other accounts could launch them without issue.  I deleted my user account from the server, tried launching applications with /appvve (which appeared to work but didn't actually initialize the AppV environment) and procmon'ed the launch of the application.  Procmon showed me the application actually launching, but immediately terminating.

Bad Launch

Good Launch

We can see that the application stops launching at the moment it initializes the virtual environment.  Next we'll dive into the event logs and see if it gives us any more relevant information.  I chose to enable a few event logs that deal with the early process of AppV5.  I can't really tell you why I chose those ones, they are just a few that I've learned to monitor when I have problems launching apps.

I enabled:
Client-Integration
Client-Orchestration
Client-Vemgr
Client-VirtualizationManager
Subsystem-Venv

Launching the application gave me some error messages.  From Client-VirtualizationManager:

64 notification failed with error 5746736078216233004. Package {49bda935-0a17-43e5-aada-44858d95affa}, version {d506ff21-4e9a-40e5-b60f-94481ccbe76a}, pid 5176, ve id 0.
VirtualizationManager component failed to handle 46 activity. Error 4746865492684177448.

If we do the backwards HRESULT dance to try and get a useful error code we get this for the two errors:

PS C:\Users\trententtye> (5746736078216233004).ToString("x")
4fc082040000002c

PS C:\Users\trententtye> (4746865492684177448).ToString("x")
41e0410400000028

According to the link, the object is 04 (

04

Virtualization Manager

Client-VirtualizationManager Log or Client-Vemgr Log

)

with error code 0x28 and 0x2c.  Googling those HRESULT codes reveals nothing.  I then looked into Client-Vemgr and found some error messages there:

Request to generate mappings for globally-published package failed. package moniker 49BDA935-0A17-43E5-AADA-44858D95AFFA_D506FF21-4E9A-40E5-B60F-94481CCBE76A. group moniker . user sid S-1-5-21-38857442-2693285798-3636612711-15138285. result {Operation Failed}
The requested operation was unsuccessful..

Well, this is interesting.  So it appears that AppV can't do mappings; which I assume are the CoW (Copy on Write) for the filesystem...?  Procmon does not reveal anything with a access denied or failed to create directories, as a matter of fact it actually creates the %userprofile%\local\Microsoft\AppV\VFS directories.  But it is specifically targeting my user account, as referenced by the SID.

At this point I scanned Procmon for my SID and found it existed in the AppV registry path here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization\LocalVFSSecuredUsers

Procmon did not notice anything wrong (no access denied or such error messages).  I then launched another application with a runas and saw it that a new registry key SID combination was dynamically generated.  I then suspected that maybe the existence of this key maybe causing my issue...  To verify I rebooted the PVS server and without using my account, checked and saw the registry key was there through reboots.  My next test was to delete the key and try launching the application again.

Lo and behold it worked!  AppV 5 regenerated the key and launched the application.  It appears if the key exists then it will fail to create the CoW mappings in the registry (which you can see in the screenshot when it's creating the MAV keys) and my issue is resolved.

Powershell script to update some sysinternals tools and wireshark

#Update_Tools.ps1
# by Trentent Tye
# Updates processor monitor and processor explorer and wireshark

mkdir c:\swinst\Sysinternals
Set-Location c:\swinst\Sysinternals

$SysInternals=@()
$SysInternals+=ls \\live.sysinternals.com\tools\procmon.exe
$SysInternals+=ls \\live.sysinternals.com\tools\procexp.exe
foreach ($File in $SysInternals) {
    if (Test-Path $File.Name) {
        if ($File.LastWriteTime -ne (get-Item $File.Name).LastWriteTime) {
            Write-Host $File.Name “is out of date. Downloading new version…“    
            Copy-Item $file -Force
} #end If LastWriteTime
            else {
               Write-Host $File.Name “is up to date.“
} #end If LastWriteTime
        } #end Test-Path
    else {
        Write-Host $File.Name “is new. Downloading…“
        Copy-Item $file -Force
} #end else Test-Path
} #end foreach $file

#remove current wireshark
$oldWireshark = dir "C:\swinst\wire*"
remove-item $oldWireshark -force
#download newest wireshark
$link = Invoke-WebRequest https://2.na.dl.wireshark.org/win32/
$wiresharkver = $link.links.innerText | select-string "Wire*" | select -last 1

$Source = "https://2.na.dl.wireshark.org/win32/" + $wiresharkver
$Destination = "c:\swinst\" + $wiresharkver
Invoke-WebRequest -uri $Source -OutFile $Destination
Unblock-File $Destination

AppV5 - Update files in an already mounted package

An issue I've been dealing with lately is we have some in-house applications baked into an AppV package.  We are encountering some issues with them and they require updating almost on a daily basis.  Since you can't update/copy .exe's via a preconfig script or by breaking into the environment (CoW restrictions) they need to be baked into the environment.

One of the new features of AppV 5 vs. 4.6 is that it can mount the files as actual files in the filesystem as opposed to a single binary.  This exposure of the AppV 5 packages allows for manipulation of the files *after* they are deployed, but you need to make some modifications to the mounted files.

1) Navigate to the folder you want to change, right click on it and take ownership of it.  Make sure you replace permissions on all items within the folder.

2) Set the permissions on the folder to Everyone Full.

And at this part you can now replace .exe's within that folder and subsequent launches of the application now use the new .exe's.  At this stage I can now replace these files without recreating the package and when another update to that .exe comes down the pipe I don't have to open the sequencer to update a file, update the share, update the batch file with the new /appvve: GUID's.  At least until their software becomes stable and final for this build.

Installing Oculus Rift SDK on Windows Server OS (or bypass the product type check with most apps)

I run a server OS as my primary OS for my home lab, which is a hyper-v system.  I'm not interested in dual-booting this system just to run a consumer OS so I can play with my Oculus Rift.  So I explored bypassing these checks and this is how I was able to get my software to think it was running on a consumer OS.

First thing you need is Application Verifier.  This utility allows you to customize shims for applications.  Once it's installed, go "File > Add Application" and add your application.

Under "Test" expand out compatibility, check "HighVersionLie" then right-click on it and select "Properties"

It's here that you can now determine what "Product Type" this application will recognize the underlying OS as.  The values for Product Type are:

Value	Meaning
VER_NT_DOMAIN_CONTROLLER 0x0000002	The system is a domain controller and the operating system is Windows Server 2008, Windows Server 2003, or Windows 2000 Server.
VER_NT_SERVER 0x0000003	The operating system is Windows Server 2008, Windows Server 2003, or Windows 2000 Server. Note that a server that is also a domain controller is reported as VER_NT_DOMAIN_CONTROLLER, not VER_NT_SERVER.
VER_NT_WORKSTATION 0x0000001	The operating system is Windows Vista, Windows XP Professional, Windows XP Home Edition, or Windows 2000 Professional.

Specifying a value of 1 in Product Type simulates that this is a consumer/workstation OS and the Oculus Rift software now installs without issue.