Olivier Marchetta

Feb 152020
 

In Windows Server 2012 and 2016 (and possibly 2019), the smart card service behavior was changed by Microsoft. It is now triggered by the insertion of a smart card.  In Windows Server 2008, the smart card service was always on.

This can pose challenges in some environments, especially for Citrix / RDS deployments when using the smart card redirection virtual channel. The smart card service will not detect the smart card insertion.

The workaround is to deploy a scheduled task to restart the smart card service “SCardSvr” when stopped.

The scheduled task trigger is “On an event” with a custom XML query looking for the event ID “7036” (source: Service Control Manager) containing the keywords “Smart Card” and “stopped”. The XML query is the following: 

The task action is to start a program “SC” with the arguments “start SCardSvr”. The task can be run as SYSTEM and with high privileges.

When this task is deployed, the smart card service will be continuously restarted on the server, solving the issues when using a redirected smart card reader with Citrix / RDS.

Dec 192018
 

PVS Server Memory Sizing

Citrix PVS server will use the system memory as a cache for the streaming operation. It is recommended to allocate enough memory to the server to get the best streaming performances by caching the virtual disks into the RAM. I use Sysinternal RAMMap on the PVS servers under load to find the maximum cache-in-memory value for each virtual disks file (in the “File Summary” tab). For the memory sizing, I’m using a modified formula from the Citrix PVS blog:

(Recommended Memory + (#XenApp_vDisks* 4GB) + (#XenDesktop_vDisks * 3GB)) + 5% buffer

So in example, for a Windows 2012 R2 PVS server streaming two XenApp (Windows 2012 R2) and seven XenDesktop (Windows 7 x64) virtual disks, the memory sizing formula is as follows:

(2 + (2*4) + (7*3))*1.05 = 32.55 GB of memory per PVS server

In this scenario, the PVS servers is configured with 32 GB RAM.

PVS Ports and Threads configuration

The base formula for configuration the number of ports and the number of threads is:

“# of ports” * “# of threads/port” = “max clients”

The number of threads should match the number of virtual CPUs on the server, making it a constant value in the formula. In our scenario, the PVS server will stream virtual disks to 500 targets with 6 virtual CPUs. Note that “# of ports” can only be an integer. This gives us the following formula: {84 * 6 = 504}. The PVS server will be configured with 84 listening ports (6910 to 6094) and 6 threads per port for a theoretical 504 maximum concurrent streaming targets.

PVS MTU configuration

The default MTU size on the PVS server is set to 1506 which correspond to: the payload size + UDP header (L4) + IP header (L3) + Ethernet header (L2).

1464 (payload) + 8 (UDP header) + 20 (IP header) + 14 (Ethernet header) = 1506

To prevent PVS traffic from being rejected or segmented, the PVS server network interface used for the streaming traffic should have a Layer 3 MTU size greater than the PVS Server MTU size without the Ethernet Header. In our case, this correspond to: 1464+8+20= 1492. Usually, the default Layer 3 MTU size on Windows Server is {1500 bytes}. To check the layer 3 MTU setting on the PVS server, the following command should be used: “netsh interface ipv4 show subinterface“. The global default MTU size including the Ethernet header is usually {1514 bytes} (Cisco Networking Infrastructure). To check the global MTU size the {ping} command should be used with a payload corresponding to the PVS Server payload. Note that the ICMP header has the same size as the UDP header so the payload doesn’t need to be adjusted to make the test. For example you can ping the gateway with a specific payload using the following command: “ping {gateway IP} -S {PVS Streaming IP} -f -l 1464″. The “-f” parameter prevent the packet from being segmented. If the packet is segmented then the following error is returned: “Packet needs to be fragmented but DF set“. This is the sign that the packet will be fragmented and the payload is too large for the current network infrastructure.

PVS Burst Size configuration

Only 32 packets can be sent over the network in a single IO Burst. 2 packets are reserved for the traffic overhead. Therefore the I/O burst size formula is the following: (MTU Payload * 30). In our case: 1464 * 32 = 43,920. The IO Burst Size will be set at 44 Kbytes.

PVS I/O Limit configuration

In my personal benchmarks, settings the concurrent I/O limit (transactions) slider to “0” had a negative impact on the overall streaming performance. Setting the slider to “128” for both “local” and “remote” concurrent I/O limit had the best performance output.

PVS Buffers per threads configuration

The number of buffers per threads is calculated with the following formula: (IOBurstSize / MaximumTransmissionUnit) + 2). The IOBurstSize is obtained with the formula (MTU Payload * 32). So in our example the formula is ((1464*30)/1464)+2. The number of buffers per threads is set to “32“.

PVS TCP/UDP Offloading

Large Send Offload and TSO Offload are responsible for re-segmenting TCP and UDP packets which is not properly supported by the Citrix PVS streaming traffic. Disabling TCP and UPD Offload on Windows Server 2012 R2 and on the network card interface driver options did not improve the network performance in our case, but had a negative impact on the CPU consumption under load. This settings should be tested for each deployment.

PVS Network dedicated NIC configuration

The best network performance was achived by disabling all network layers except IPv4 on a dedicated network interface, and disabling all WINS and NetBIOS listeners:

PVS targets RAM Cache sizing

In order to define the size limit of the RAM cache to prevent Boot and Logon performance issues, the target cache is redirected on the PVS server and the size will be monitored 10 minutes after the initial OS Boot, and 10 minutes after a user logon. Result: The Operating System (Windows 7 x64) will use the cache up to an average of 512 MB at boot time. This value should be set on all vDisks to reduce OS Boot storms effects in the VDI infrastructure. When a test user logs on, the cache will quickly fills up to an average of 1024 MB of cache. This value should be used on all vDisk to avoid OS Boot AND Logon storms on the VDI infrastructure by redirecting the I/O into the target’s RAM.

PVS vDisks defragmentation

Defragmenting the master vDisks offline after a merged base is a best practice for PVS environments. The merged vDisk (VHD file) is mounted on the PVS server as a disk drive (via Windows “mount” built-in command, from the right click menu). The disk is then defragmented via the native defragmenter tool from Windows (disk tools), but also using a third-party application named “Defraggler”. The latest showed slighly better results. The gain after a disk defrag was around 10 MBps in read speed using a benchmark tool on the PVS target.

Dec 052018
 

It can be usefull to launch certain tasks on the behalf of the user, in the user security context, on a CVAD server.

Create the task in the Task Scheduler then export it as XML. Find and replace the “<Principals>” entries with either Interactive Users or Users:

Interactive users is the one I use the most. I keep the Users group ID in case I would neet to run a task with high privileges. But this is not recommended and even dangerous. Interactive tasks (impersonating users security context) can be used for small local tasks, but should not be used to run more important applications.

What about GPPs?

When deploying an interactive task via GPP to all Citrix CVAD servers, “%LogonDomain%\%LogonUser%” can be used in the graphic interface.

Nov 252018
 

When defining the policy “Default Associations Configuration File” with an XML definition file, users are still able to use the “Open with…” command in the context menu and set their own file type association. This is by design. One solution to enforce the FTA at logon is to use the “SetUserFTA” software from Christoph Kolbicz’s Blog. Another way is to detect and remove user defined File Type Associations in the registry via a script. The registry key is locked down with a “Deny” access control set to everyone including the Administrators. The following script will remove the “Deny” access control, and then proceed to the deletion of the user defined file type association. This script runs at logon and at logoff and have been tested successfully.

Nov 052018
 

Long story short, this is the script I’ve found and is the most accurate / reliable in my experience when used in recurse mode on Citrix user profiles to get the profiles size:

Oct 052018
 

Remove-Item cannot be used to remove symbolic link to directory as it will remove the content of the directory it points to (so be careful!).

To safely remove a symbolic link from the file system using PowerShell, add the following function to your script:

From: PowerShell Gallery | Private, LinkUtils

Remove-Symlink -Link [path to the symbolic link you wish to remove]

Done! 🙂

Apr 192018
 

I’ve come across a strange configuration in a recent XenApp deployment. I had to implement Folder Redirection on a XenApp server pointing to a local OneDrive folder on the client, shared as a network drive “\\client\onedrive$”.

So all I needed to do was to configure the Microsoft Folder Redirection in a GPO right? Wrong. The built-in redirection mechanism was not very happy with the network path “\\client\onedrive$”. I had recurrent failed drive mappings in the event logs and the users wouldn’t get their XenApp documents redirected to their local One Drive folder.

After several attempts, I finally decided to go via the old fashioned way hacking the User Shell Folders in the Registry. But with Windows 10 and Server 2016 the registry keys and values have changed since the Windows XP-7 era. It’s less intuitive and I had to dig to find what GUIDs was used to point to a local Document or Desktop folders. Finally, the setup is working fine! But I wanted to leave a billet with the GUIDs I needed to hack in the Registry to manually point the XenApp user folders to the client’s One Drive shared folder.

Now the list of the GUIDs you may use to manually implement folder redirections:

Desktop:

Documents (redirection 1):

Documents (redirection 2):

Pictures (redirection 1):

Pictures (redirection 2):

Music (redirection 1):

Music (redirection 2):

Videos (redirection 1):

Videos (redirection 2):

Downloads:

Links:

Mar 052018
 

The PowerShell Get-Process commandlet cannot return the process owner in the v3 implementation. In PowerShell v4, the Get-Process cmdlet now has a “-IncludeUserName” parameter but it will only run as elevated (administrator).

I’ve been searching for an optimized script, running in a non-elevated context. But all I’ve found was slow and high resource demanding scripts to match or find a process owner. I needed a simple, short and efficient script to run in Citrix XenApp environments.

So I’m happy to share with you my “optimized” version of the script:

This example runs in the user context, find the explorer.exe owned by the user and restart it by stopping the process (explorer.exe will automatically restart when stopped via a PS script). I need to restart explorer.exe if the user shell folders (folder redirections) have changed since the last logon.

But this script could be reused to find the owner of a high CPU usage process (I’m thinking at some PDF readers stuck at 99% CPU usage when the user is disconnected). Finding the process owner is not easy with the current version of PowerShell, but you can use my own script freely if you like it.

Feb 152018
 

My client wanted to redirect the personal documents for the published applications in XenApp to the local OneDrive folder on the user’s devices, and if possible, to create a OneDrive folder shortcut in XenApp looking exactly as the local OneDrive client in the file explorer. Mission accomplished. Discover how I have done it in this document.

Preamble

Current implementation (pre-migration): Microsoft OneDrive has been implemented as the default personal documents storage for the users on the VDI machines and laptops. In the current Citrix XenApp 6.5 farm (published applications), a network drive “O” is mapped on the local client machine using the “OneDrive Mapper” script and is then mapped in the XenApp published application environment via a Citrix policy (file redirection, network drives). The users have been instructed to save their documents in the mapped network drive “O” when using a XenApp published application. The personal folders (Documents, Pictures, etc) in XenApp are not redirected to the network drive and are pointing to the Citrix UPM user profile, which can be confusing when using the published application’s file explorer.

The current OneDrive redirection for the XenApp 6.5 farm is a complex setup involving configuration on all clients (VDI, laptops) with the “OneDrive mapper” script. Several issues have been reported to the service desk regarding the reliability of the “OneDrive mapper” script on laptops, and the disappearance of the redirected network drive “O” in XenApp published applications.

For the new Citrix XenApp 7.15 farm deployment, the OneDrive redirection should be redesigned to remove all pre-requisites on the client side (zero client configuration) in a more reliable approach with less “moving parts” on both servers and clients, and with a more seamless integration in the published applications’ file explorer for a better user experience.

OneDrive folder redirection for XenApp design

The OneDrive folder redirection configuration will use the Citrix client drive mapping and redirection technology to get access to the client device local disk drive and locate the user’s OneDrive folder.

The file explorer hosted in Citrix XenApp for the published application will have folder redirection implemented to seamlessly redirect the user’s personal folders to the local OneDrive client folder located on the user’s device.

In addition, the root OneDrive client folder will be added to the File Explorer as a network shortcut and appearing as the native OneDrive client root folder, even if the client is not actually installed on the Citrix XenApp servers.

Citrix client drive mapping configuration

Microsoft group policies have been used to implement the Citrix XenApp user policies. Note that Citrix does not support mixing Windows settings and Citrix settings in the same group policy. Two policies have been created, one to configure the Citrix client drive mapping policy, and one to configure the OneDrive redirection with PowerShell.

In the first policy, the Citrix File Redirection settings are configured in:

User Configuration / Policies / Citrix Policies / File Redirection

User personal folders redirection configuration

The user personal folders will be redirected into the user’s OneDrive folder as follow:

The user personal folder redirection will be set only if the following conditions are met:

• client drive is reachable (exists) AND the user OneDrive folder is reachable (exists)

If the user OneDrive folder exists but the target folders for the redirection do not, they will be created. For example, if the directory “Videos” is missing in the user’s local OneDrive folder, the directory will be created before configuring the redirection on the XenApp server.

If the conditions are not met, the redirection will not be set to the user’s local OneDrive folder, but to the Citrix user profile (on the XenApp server).

The embedded folder redirection configuration in the Microsoft group policy could not be use in this complex scenario. A power shell login script has been defined on the XenApp server for the OneDrive folder redirection: (see Annex A).

OneDrive network shortcut in file explorer configuration

To achieve the best user experience with the OneDrive folder redirection, a network shortcut pointing to the root of the user’s local OneDrive folder on the user’s device will be added with the native OneDrive icon to the hosted file explorer in XenApp for the published applications.

The shortcut will be created as a symbolic link (directory junction) in the “Network Shortcuts” directory located in:

%username%\AppData\Roaming\Microsoft\Windows\Network Shortcuts

Note that the type of shortcut is a “File folder”, showing that this is not just a regular shortcut (.lnk) but a directory junction:

To get the OneDrive native icon for the shortcut and for this shortcut to appear in the save location window for legacy applications, it is required to copy a “desktop.ini” file at the root of the OneDrive folder. The “desktop.ini” file contains the property of the folder and the icon file location:

The Shell Class Info is pointing to the registry

This is to help the embedded Explorer from published applications to see the directory junction as a directory. The icon file is located on the server itself. The network shortcut is created with a PowerShell script at the user login on the XenApp server.

The script will test the client local drive mapping and the OneDrive folder path on the client device before creating the shortcut. The script will then create the directory junction and create the “desktop.ini” at the root of the OneDrive folder. The script is available at this end of this document (see Annex B).

Annex A: XenApp_OneDrive_Redirection.PS1

Annex B: XenApp_OneDrive_Shortcut.PS1

Apr 052016
 

In our corporate environment I was asked to remove most of the built-in Windows 10 applications from the command line .

It works fine , but the Start Menu layout is then filled with missing applcations as shown in the following screenshot :

And it will be looking like this for each new user logging-in the computer. So I’ve customized the Windows 10 layout to look clean as below :

But to define this new layout as default for everyone in the computer, you have to use some powershell commands to export – import the layout :

Export-StartLayout -Path C:\users\_you_username_\start_menu.xml

Import-StartLayout -LayoutPath C:\users\_your_username\start_menu.xml -MountPath C:\

You might consider using GPOs instead of a command in the distribution image … But the GPO that defines a “layout” located in “Administrative Templates > Start Menu and Taskbar > Start Layout” will apply your exported layout, but also lock the Start Menu customization for the users ! Which we didn’t want to happen…

Finally the Export/Import in PowerShell was a good solution for our needs. 🙂