Unable to launch /appvve switch via XenApp 6.5

It appears you can't launch an AppV environment around an application with the /appvve switch as Microsoft automatically strips the /appvve switch OR because icast.exe freaks out.

I have found an alternative method though:

powershell.exe -command "&{$AppVName = Get-AppvClientPackage *APPNAME* ; Start-AppvVirtualProcess -AppvClientObject $AppVName cmd.exe}"


This will launch a cmd.exe window in the virtual environment in citrix with the passed .exe (cmd.exe in this example).

Group Policy Preferences - Scheduled Task fails to apply

We had a couple issues with scheduled tasks not applying when submitted as a GPP (Group Policy Preference).  We turned on tracing via local gpedit.msc (Administrative Templates > System > Group Policy > Logging and tracing).  From here we turned on the Scheduled Task logging and events were then stored in the eventvwr.msc (we also turned on tracing which stored a computer.log file here: C:\ProgramData\Group Policy\Trace)

The first error we got was:

2014-10-03 10:42:19.372 [pid=0x59c,tid=0x1294] No item to delete.

2014-10-03 10:42:19.372 [pid=0x59c,tid=0x1294] pWorkItemV2->Create [ hr = 0x80070534 "No mapping between account names and security IDs was done." ]

2014-10-03 10:42:19.372 [pid=0x59c,tid=0x1294] replaceTask [ hr = 0x80070534 "No mapping between account names and security IDs was done." ]

2014-10-03 10:42:19.372 [pid=0x59c,tid=0x1294] Properties handled. [ hr = 0x80070534 "No mapping between account names and security IDs was done." ]

2014-10-03 10:42:19.388 [pid=0x59c,tid=0x1294] EVENT : The computer 'AHS-Add-GlobalPrinters' preference item in the 'CTX XenApp 65 Test {E6775312-AAC0-45C3-8A1C-5F5EA46701A7}' Group Policy object did not apply because it failed with error code '0x80070534 No mapping between account names and security IDs was done.'%100790275

2014-10-03 10:42:19.388 [pid=0x59c,tid=0x1294] Completed class - AHS-Add-GlobalPrinters. [ hr = 0x80070534 "No mapping between account names and security IDs was done." ]

2014-10-03 10:42:19.388 [pid=0x59c,tid=0x1294] Error suppressed. [ hr = 0x80070534 "No mapping between account names and security IDs was done." ]

So it can't map between user ID's.  It'd be nice if it told us which mapping failed, but it gives us a pretty good hint. Looking at the XML file the GPP creates (stored here: "C:\ProgramData\Microsoft\Group Policy\History\\Machine\Preferences\ScheduledTasks\ScheduledTasks.xml" )

We saw the following:

Everything validates.  Googling for BUILTIN\SYSTEM brought up that several people were getting the same error when using BUILTIN\SYSTEM.  Which makes some sense as "BUILTIN\SYSTEM" isn't a real account.  We renamed it to NT AUTHORITY\SYSTEM.  This time we got a new error message:

The computer 'AHS-Add-GlobalPrinters' preference item in the 'CTX XenApp 65 Prod {CB954F1D-7AE5-4706-9BCC-995A0D83CED5}' Group Policy object did not apply because it failed with error code '0x80041316 The task XML contains an unexpected node.' See trace file for more details.

This doesn't tell us a whole lot of information.  What is the unexpected node? Looking again at the XML file it looked like so:

The difference that I can see:

<GroupId>NT AUTHORITY\SYSTEM</GroupId>

The SYSTEM account is NOT a group.  We changed how we selected the SYSTEM account by "Browsing" AD, going into the root of the domain, going into the Builtin OU, and selecting SYSTEM.  This populated as "NT AUTHORITY\Well-Known-Security-Id-System".  This will fail because there is no such user account called "Well-Known-Security-Id-System".  At this point we renamed it to "NT AUTHORITY\SYSTEM".

Boom, GPP Scheduled task now worked without issue.  Checking the XML the difference by manually selecting the SYSTEM account changed 

<GroupId>NT AUTHORITY\SYSTEM</GroupId>

To

<UserId>NT AUTHORITY\SYSTEM</UserId >

SO.

If you are having issues with your GPP Scheduled task item running as the SYSTEM account I would HIGHLY recommend you check your XML file and confirm it is set as "NT AUTHORITY\SYSTEM" and it is surrounded by UserId NOT  GroupId.

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