.

 

 

FSLogix - App-V Refresh failure

Problem:

When using FSLogix Profile Containers, user assigned App-V applications either fail to appear in the Start Menu, or appear with white icons. Globally assign App-V applications behave correctly.

This happens most commonly on the first logon however it can happen on subsequnet logons with inconsistent behaviour.

If you exclude AppData\Local\Microsoft\AppV using redirections.xml then the problem is more apparent. However excluding this directory is a common solution to this problem with other profile management solutions. Exluding this directory forces a refresh of the Copy on Write (COW) Local data location at each logon.

This was observed in the following environment.

HyperVisor: Hyper-V with SCCM

Operating System: Windows 2016 Server (build 1607)

Citrix XenApp build 1906 (MCS Non-Persistent)

App-V dual-admin mode

FSLogix Version: 2.9.7117.27413

Profile Container Mode: 1 with Concurrent Access Mode

Cause:

From the FSLogix point of view, I can only assuming this is a matter of timing.

From the App-V point of view, there should be a GUID folder in the integration directory of the COW Local for each application. In this case, there should be four folders however there are only two (two applications function). On some occasions, the AppData\Local\Microsoft\AppV folder was not created at all (zero applications available).

Troubleshooting:

Tried VHD and VHDX files to store the profile - no difference

Tried non-dynamic (fixed size) VHD(X) files on the assumption that growing the VHD(X) was the issue - no difference

Tried Mode 0 - This was more reliable but not suitable for multisession

Assumed there may be an issue with filter driver incompatibility - interesting subject, but offers no solution. Allocated Altitudes

Standard filter drivers on a Winodws 2016 RDS Server without App-V Client enabled or FSLogin installed.
Filter drivers with the App-V Client enabled.
Filter drivers with FSLogix additionally installed.

Run "Sync-AppVPublishingServer 1" manually after logon - This fixed it, but did not fix up the application icons.

This made me assume that the Scheduled Task to sync the App-V publishing server was running before the VHD(X) file containing the user profile had been mounted.

The VHD(X) file is mounted at 31 seconds.

The App-V Sync happens a full three seconds later

So all appears to be in order however timing of the App-V sync does appear to be an issue.

Workaround / Fix 1:

When an App-V publishing server is added to a XenApp server using Add-AppVPublishingServer, a Microsoft Group Policy, or a Citrix Policy, a scheduled task is created to Sync the App-V client with the publishing server at user logon. Notice that the task runs using the BUILTIN\Users Group.

The task has the following trigger. The task runs at user logon. Notice there is no delay.

So let's increase the delay to give FSLogix some extra time to mount the VHD(X) and settle down.

Here come the problem. The 1_user_logon scheduled task is created programmatically by the App-V client. When you OK out of the scheduled task, you'll be prompted for the password for the BUILTIN\Users group. No idea what the answer is, therefore you cannot modify the scheduled task manually.

Even if you could modify the task, it is created dynamically at computer startup by the Microsoft or Citrix Policy so updating the master image isn't really an option.

Using Task Scheduler, export the scheduled task to C:\WIndows\Temp\1_user_logon.xml

Edit 1_user_logon.xml and add the following line to create a 10 second delay.

<LogonTrigger>
<StartBoundary>2008-06-22T12:00:00</StartBoundary>
<Enabled>true</Enabled>
<Delay>PT10S</Delay>
</LogonTrigger>

Save 1_user_logon.xml - ensure that the file is saved using UTF-16 / Unicode formatting otherwise you will probably experience errors when importing the task in the next step.

Create a PowerShell script with the following two lines

Unregister-ScheduledTask -TaskName 1_user_logon -Confirm:$False
Register-ScheduledTask -xml (Get-Content 'C:\WINDOWS\TEMP\1_USER_LOGON.xml' | Out-String) -TaskName "1_user_logon" -TaskPath "\Microsoft\AppV\Publishing\" –Force

 

Unregister-ScheduledTask deletes the dynamically created Scheduled Task

Register-ScheduledTask creates the modifed App-V Sync Scheduled Task

You can deploy the updated scheduled task using another Scheduled Task that runs a few minutes after computer startup, or using a computer startup script. Keep in mind that the powershell script must run AFTER the Citrix or Microsoft Group Policy that configures the App-V Publishing server has applied.

Workaround / Fix 2:

Don't use App-V delivered shortcuts to the user's Start Menu. Use Citrix Receiver / WorkSpace App with the VPrefer option to enable local launching of published application within a published desktop.

Modify the configuration of your App-V packages disabling all shortcuts.

Create a dedicated Storefront site exclusively for Citrix Receiver installed on XenApp VDAs. Disable Proxy detection in the default.ica for faster app launching. Do not configure 'Remote Access' via NetScaler as the XenApp VDAs are always internal. A dedicated Storefront site allows you to configure keywords so that you can hide / show a subset of required published applications.

Unfortunately ctxappvlauncher.exe does not support local launching of App-V applications with vPrefer so you will need to publish you App-V applications using AppVCloudSync which requires XDAppVLauncher installed on the VDA. XDAppVLauncher does support vPrefer.

This method works because XDAppVLauncher Syncs the App-V Publishing server at every launch therefore the Copy on Write (COW) Local directories are created at launch time, not at user logon time.