Sunday 18 November 2018

Citrix 17. Capturing and analyzing launch.ic

Capturing and analyzing launch.ica


Just a short one. I thought I’d post this because recently I had to do this exact task to troubleshoot a Citrix connection issue. It made me again realise how important it can be to get a look at the launch.ica file and view connection details to help diagnose a fault.


 


The launch.ica file can be saved (logged) to a location of your choice by:


Launch RegEdit.


Navigate to:

64bit – HKLM -> Software -> Wow6432Node-> Citrix -> ICA Client -> Engine -> Configuration -> Advanced -> Modules -> Logging.


32bit – HKLM -> Software -> Citrix -> ICA Client -> Engine -> Configuration -> Advanced -> Modules -> Logging.


Set string value LogICAFile=true


Set string value LogFile=C:\ICA\ica.log




Alternatively you can find the launch.ica file in your Temporary Internet files folder. Copy this file to an alternate location and replace the .ica extension with .log.


Now on opening the captured file, you can view the IP address the client uses to attempt connecting to a session. In environments where connections are proxied etc. this can be useful to determine where traffic is going.




In the event that firewalls were blocking ports inbound or outbound, we now have an IP to test against with telnet. We can then attempt to telnet to the IP noted above using ports 1494/2598.


You can even identify that the generated ICA file contains the wrong IP address, which explains the failures.


Citrix 16. Citrix Provisioning Services

Citrix Provisioning Services


 


Citrix Provisioning Services tutorials and general information on the product around system requirements, installation and configuration.


 PVS install guide here.

BDM guide including automatic BDM updates in PVS 7.9+ here.

NetScaler TFTP load balancing guide here.

Streamed VM setup wizard here.

XenDesktop Setup Wizard here.

Disable Large Send Offload and other PVS recommendations listed here.

New in PVS 7.7:

Support for Windows 10 Enterprise and Professional editions.


In-place upgrade of target device software. No more having to reverse image. To upgrade target devices that have software version 7.6, first install 7.6.1 then you can perform an upgrade to 7.7+.


Support for UEFI pre-boot environments. Allowing for faster startups as you can now use gigabit network speeds.


PVS licensing grace period changed from 96 hours to 30 days to bring in-line with XenApp and XenDesktop.


vGPU XenDesktop machines can be provisioned using PVS XenDesktop Setup Wizard. Prior to 7.7 you could only use PVS STreamed VM Setup Wizard.


Generation 2 VMs (Hyper-V) can be provisioned through PVS.


VHDX streaming now available along with usual VHD streaming.


New FIPS compliant algorithm used in PVS.


New in PVS 7.8:

Support for Hyper-V Generation 2 VMs in PVS 7.8. (Streamed VM Setup Wizard does not support Gen 2 templates). You muse use the XenDesktop Setup Wizard to create VMs from a Gen 2 template.


UEFI enhancements. (BDM does not spport UEFI, only TFTP/PXE).


New in PVS 7.9:

Opt in or out of the CEIP (Customer Experience Improvement Program). 7 days to disable CEIP after installation.


BDM support for UEFI in PVS 7.9 using integration with XenDesktop Setup Wizard (attaches BDM ISO to desktop upon provisioning – eliminating extra step).


BDM creation wizard allows you to specify that target devices use UEFI firmware.


BDM partitions can be automatically upgraded by collection, single device or multiple device selection. Useful if PVS IP changes and you need to edit bootstrap to reflect change.


No need for TFTP/PXE anymore when using BDM.


New in PVS 7.11:

Always on tracing using CDF Monitor to upload diagnostic data to Citrix.


SQL Server Always On multi-subnet failover using an ODBC connection between the PVS server and SQL database. Requires SQL Native Client on PVS server.


Support for CIS in PVS 7.11 allowing you to report problems to Citrix that you experience whilst using PVS. This feature and CEIP is used by Citrix to continually improve PVS.


Windows Server 2016 support, install PVS on Server 2016 or run Server 2016 Target Device VMs.


New in PVS 7.12

Linux VDA streaming in PVS 7.12 (technical preview at this stage).


Cached secrets cleanup, removing cached admin credentials from a vDisk when private/maintenance mode is changed to shared (standard image mode).


New in PVS 7.13

Linux CentOS VDA streaming in PVS 7.13.


PVS Accelerator (XenServer) – A PVS proxy resides in XenServer’s Dom0. Streaming of the a vDisk is cached in the PVS proxy before being forwarded to a Target Device. All further booting or IO requests of the Target Device on the same host is streamed from the proxy rather than over the network from PVS. This results in reduced network traffic. PVS Accelerator works on XenServer 7.1 hosts with the required proxy feature installed. Target Devices access data directly from XenServer memory and storage instead of PVS server RAM.


New in PVS 7.14

Linux streaming improvements including support for Ubuntu Desktop 16.04.


Support for provisioning to Nutanix AHV – Using the XenDesktop Setup Wizard, you can now provision VMs to Nutanix AHV.


Microsoft Device Guard integration.


New in PVS 7.15

Expanded platform support for Linux Streaming on Ubuntu Desktop 16.04. Now support provisioning to Nutanix AHV 5.1+.


UEFI – XenDesktop supports UEFI hardware technology on Hyper-V VM that are managed using SCVMM and streamed using PVS. UEFI provides faster Target Device startup times using GB network speeds. UEFI is the complete replacement for BIOS and requires a new PVS bootstrap. Two new bootstraps are available, one for x32 systems and one for x64. BDM is not available for UEFI devices unless using PVS 7.9+. In PVS 7.7, the boot menu is not available for manual selection. If a maintenance version is detected then a target device will boot in to the maintenance mode version, the highest test version, or the production version in that order. Note this is dependant on what mode the target device is set to. The boot menu does appear to be present using PVS 7.11. I cannot speak for PVS 7.8 or PVS 7.9. If multiple vDisks are assigned to a target device the machine boots to the first one in the list. Secure Boot (Hyper-V) does not work for PVS when using easlier versions of XenApp 7.12 and must be disabled on UEFI VMs. The Secure Boot term has been replaced by Protect SDB in PVS 7.12+.

Note: You must use the most recent version of Citrix License server to get the latest features. The required version to work with your version of PVS is normally available with the PVS product software. Failing to run the latest version results in PVS entering grace period. Latest version 11.14.0.1 build 19005 (Feb 23, 2017).

PVS 7.15 server system requirements:

SQL 2008 SP3 through to SQL 2016 (x86, x64 & Express editions). Database clustering supported.


Windows Server 2016.


Windows Server 2008 R2, 2008 R2 SP1 Standard, Enterprise & Datacentre.


Windwos Server 2012, 2012 R2 Standard, Essentials & Datacentre.


Intel or AMD  x64 2GHz minimum, 3GHz preferred. 3.5GHz dual-core/HT or similar when streaming to 250 target devices or more.


2GB RAM minimum, 4GB preferred. 4GB required when you have 250 vDisks or more.


100MB ethernet NIC minimum, 1GB preferred. Dual 1GB NICs when streaming to 250 target devices or more.


.NET 4.5.2 & PowerShell 3.0.


PVS 7.15 firewall requirements:

UDP 6890-6909 – Provisioning server to server communication using the Messaging Manager.


UDP 6910-6930 – vDisk streaming between Target Device and PVS Server. UDP 6910 is used as login when a device is booting.


UDP 6901, 6902, 6905 – Target device to PVS server traffic.


TCP 54321-54323 – SOAP Server communication when accessing the PVS Console.


UDP 69 – TFTP communication inbound to PVS server.


UDP 6969 – TSB communication inbound to PVS server. For BDM boot.


PVS 7.15 Target Device software supported Operating Systems:

Windows 7 SP1 Professional, Enterprise, Ultimate (Private mode only). x32/x64 editions.


Windows 8 all editions. x32/x64.


Windows 8.1 all editions. x32/x64.


Windows 10 all editions. x32/x64.


Windows Server 2016.


Windows Server 2012 & 2012 R2 Essential, Standard & Datacentre.


Windows Server 2008 R2 & R2 SP1 Standard, Enterprise & Datacentre.


RedHat Enterprise Linux 7.2, CentOS 7.2


Generation 2 (Hyper-V) VMs are supported is Server 2016, Server 2012 and Server 2012 R2 Standard, Essential and Datacentre.


PVS 7.15 Target Device software requirements:

.NET 4.5.2.


PVS 7.15 console system requirements:

1GHz CPU, 2GHz preferred.


1GB RAM, 2GB preferred.


500MB disk space free.


Windows Server 2008 R2, 2008 R2 SP1 Standard, Enterprise & Datacentre.


Windows Server 2012 Essential, Standard and Datacentre.


Windows Server 2012 R2 Essential, Standard and Datacentre.


Windows Server 2016.


Windows Vista Business, Enterprise and Ultimate.


Windows 7 & 8 all editions. x32/x64.


Windows 8.1 all editions. x64.


Windows 10.


MMC 3.O, .NET 4.5.2 & PowerShell 3.0.


PowerShell 3.0 if using PVS with SCVMM.


Hypervisor considerations (XenServer 5.6+):

MAC address on template cannot be 00-00-00-00-00-00-00.


Hypervisor considerations (SCVMM 2012+):

To stream from Synthetic NIC (after vDisk boot) on Generation 1 VMs see here.


When creating VMM VM template, choose None – customization not required when asked to configure Guest OS.


Make sure the PXE boot NIC is first in the hardware settings list.


Hypervisor considerations (ESX 4.1+):

ESX 4.x = E1000, ESX 5.x+ = VMXNET3 (supported NICs).


Enable Interupt Safe Mode on the PVS bootstrap to prevent target device displaying a partial MAC address during reboot on ESX 5.0 only.


Make sure the PXE boot NIC is first in the hardware settings list. Also be aware that the BIOS may store the NICs in a different order.


Make sure the tenplate VM and master VM have the exact same guest OS, configuration, and virtual machine version.


When creating a new VM template in ESXi 5.5 make sure that the template’s CD/DVD drive is attached to an IDE controller and not a SATA controller. This will ensure the template is compatible with the XenDesktop setup wizard.


Hypervisor considerations (Nutanix Acropolis)

You can provosion Target Device’s to AHV using the XenDesktop Setup Wizard starting PVS 7.14.


PVS spanning multiple datacentres

Lantency between PVS servers and the SQL database is important. Make sure proper testing is performed if latency is >15ms. It may be better to create a PVS farm per datacentre with a local SQL server in each datacentre. This will provide the best performance and reduce the risk of failure or sluggish perfomance. This is also how most enterprise customers implement PVS.


Latency between VDA and PVS server is important to ensure streaming is not affected. PVS servers should generally be within the same location as each Target Device.


Components of PVS:

License Server – Use existing License Server if available. Make sure the License Server is running the latest version software. You must use the latest license server when upgrading to the latest Citrix PVS. If licensing is not availale, PVS goes in to a 30-day grace period. When the grace period expires, all target devices are shut down.


PVS Database – Only one database per farm.


Console – Used to manage the PVS farm.


Network Services – DHCP, PXE & TFTP are used to obtain an IP address, boot server information and to deliver the bootstrap file to target device.


Farm – The top level of a PVS infrastructure. The farm contains Sites, PVS servers, stores, vDisks, target devices etc.


Stores – Stores are NTFS/ReFS locations on your network that store vDisk (VHDX – new in 7.7+), PVP, AVHD, LOK and Write Cache files etc.


Sites – One or more can exist in a farm. Sites contain servers, stores, vDisks etc. and may represent different office locations across the country.


Provisioning Servers – Used to stream vDisks to target devices. Any server with Stream Services installed is a PVS Server.


vDisk update management – Used to provide automation of vDisk updates. These updates can be performed on a schedule and can be used in scenarios such as Windows patching.


Device Collections – A group of target device machines are kept in a Device Collection. Generally these Device Collections contain similar functioning machine such as for example, Windows 8 Desktops.


vDisks – Contain the image file, such as Windows 8.


vDisk modes

Private image mode = Read/write access to the vDisk, streamed to a single device.


Standard image mode = Read only access to the vDisk, streamed to multiple devices.


vDisk chain – A versioned vDisk, containing the Base Image and a number of manual, maintenance or test versions.


PVS Permissions:

Different groups are available in PVS which control access and management capability:

Farm Administrator – Can manage all objects within a farm including creating new sites.


Site Administrator – Can manage all objects within a site includnig creating new Device Collections. Site Administrators cannot administer a store unless that site is set to act as the owner of the store.


Device Administrator – Can manage all objects within a device collection including assigning vDisks to a device and editing device properties.


Device Operator – Can boot, shut down, send messages to target devices and view target device properties.


Membership to each group can be configured by editing the properties of the Farm, Site or Device Collections and clicking the Security tab.

Note: The user account used to create the farm automatically becomes a farm administrator.

Database documentation:

To create a database script to pass to the SQL team, use the DbScript.exe program. This utility is located by default in C:\Program Files\Citrix\Provisioning Services. This program is present once you install the PVS Server component.


Enable offline database support:

Offline Database Support in PVS is a feature that can be enabled to allow PVS servers to use a snapshot of the PVS database if the connection to the database is lost. The snapshot of the database is created and initialized at server startup and continually updated by the Stream Process. When the database is back online the Stream Process synchronizes any PVS server or Target Device status changes made to the snapshot back to the database.

Keep in mind that when the database is offline, the following functions are unavailable:

Auto-Add Target Devices.


vDisk updates.


vDisk creation.


Active Directory password changes.


Stream Process startup.


Image Update service.


PowerShell management functions, MCLI, Soap Server and Console management functions.


To enable offline database support, right-click Farm -> Properties.

Click Options -> Enable offline database support -> OK.

Click OK and restart the Stream Service on each server for offline database support to take effect.

Other SQL requirements:

Database sizing – The initial size of a PVS database is 20MB. The database log initial size is 10MB. A four server, load balanced PVS environment with 6 stores, 8 vDisks and 100 Target Devices can roughly have a database size of 800MB. Database sizes obviously vary based on many factors so another environment with the same capacity will likely be different.


Provisioning Services uses Windows authentication with SQL when accessing the database. SQL authentication is not supported except by the Configuration Wizard. Create a service account for database access.


Database permissions – dbcreator for creating the database and securityadmin for creating the SQL logins for Stream and SOAP services.


Additional database permissions – The Stream and SOAP accounts need db_datareader and db_datawriter permission to the database. These permissions are automatically configured when running the Configuration Wizard. These accounts must also have the following rights:

Run as service.


Registry read access.


Access to Program Files\Citrix\Provisioning Services.


Read and write access to all vDisk locations.


Note: Sometimes Windows will ask for a restart after installing the PVS Console component or Server component. Do not restart. Complete the configuration wizard before restarting the server.

Configure Bootstrap Options:

To configure bootstrap, open the PVS Console -> navigate to Servers -> right-click a server -> Configure Bootstrap.

Verbose Mode – I always recommend enabling this. Outputs system messages during the boot process for deeper insight.


Interrupt Safe Mode – Enables debugging of target device drivers that exhibit timing or boot behavior problems. (Keep disabled unless you have a problem).


Advanced Memory Support – Enabled by default to allow the bootstrap to work with newer Windows OS versions.


Network Recovery Method:

Restore network connection – When a target device loses connection with the PVS server, it will continue trying to restore the connection.


Reboot to Hard drive after x seconds – Instead of continuously trying to restore the connection, the machine will be force restarted after a defined number of seconds and booted to the local HDD.


Logon Polling Timeout – Amount of time (in milliseconds) between retries when polling for PVS servers. Each PVS server is sent a login request packet in sequence. The first PVS server that responds is used. In a non-HA setup, this value defines how often to retry the single PVS server with the initial login request. In HA environments, this value defines how quickly a target device will try the next server in a DNS round robin fashion with the initial login request.


Login General Timeout – Time in milliseconds for all login associated packets except the initial login polling time-out. This value will generally be longer than the polling time out since the target devices need time to contact all PVS servers.


The bootstrap file is important because it tells target devices which servers to connect to when booting. You can list up to four servers in the bootstrap file. This allows the target device to boot from other servers in the list if one or more is offline. Each server contains a copy of the bootstrap file which can be edited from the PVS Console. All servers should be configured with their own IP first in the bootstrap file.

Creating a Master Image:

Some PVS Master Image recommendations are listed here.


If your vDisk is going to stream to a number of different Target Devices that reside on different motherboards, network cards, video cards etc. then you must use the PVS Common Image. An example scenario would be when you stream vDisks to physical devices. Citrix provide details on creating a Common Image.


When creating a master image using the Imaging Wizard, each partition is cloned separately and must be equal or larger than the source partition regardless of how much free space is on each source partition.


Note: At the beginning of a Master Image capture using the Imaging Wizard, you may be asked to restart your machine. Ignore this prompt and let the capture complete.

vDisk assignment:

To assign a vDisk to a single Target Device, right-click the Target Device -> Properties -> vDisks -> Add.


To assign a vDisk to a Device Collection, drag and drop the vDisk on top of the Device Collection.


To unassign a vDisk from a single Target Device, right-click the Target Device -> Properties -> vDisks -> Remove.


To unassign a vDisk from multiple Target Devices, right-click the vDisk -> Unassign from Selected Device(s)… -> check devices -> Unassign.


Target Device boot process:

It is important to know that the boot process involves a Target Device contacting PVS for the bootstrap file which is delivered via TFTP. Once the bootstrap file is delivered the Target Device can boot from the assigned vDisk.

Creating views:

To create a view, right-click Views -> Create View..


Specify a name for the view and description if desired.


Click on the Members tab -> Add.


Select a Device Collection, highlight VMs to add and click OK


.


Click OK again and the devices will appear in the new view.


You can also drap and drop Target Devices on to a view, which makes them a member of that view.


Changing the PVS license server:

The License Server details are within Farm Properties -> Licensing. After changing the license server details, restart the Stream Service on each PVS Server


.


Enable auditing:

Right-click the Farm -> Properties -> Options -> Enable Auditing -> OK


.


Right-click your Site -> Audit Trail


.


Archive an audit trail:

Right-click your Farm name and select Archive Audit Trail.


Choose a location to save the .xml archive file and the end date which should be archived


.


Select or do not select Remove information archived from the Audit Trail. If you do check this box, the information archived will going forward only be viewable from the XML file.


Override stores:

Override store locations can be set individually on servers that cannot access the default store path set within the Store properties. For example:

Server 1 – Store1 – D:\PVSStore\ (retrieved from Store properties).

Server 2 – Store1 – D:\PVSStore\ (retrieved from Store properties).

Server 3 – Store1 – E:\PVSStore\ (override location).

To set an override path:

Open the PVS Server Properties -> Stores.


Select the required Store and click Edit.


Under Path used to access the store, insert the override location.




Click OK.




PVS Server Properties

What can you set here?

Power Rating (General tab) – You can assign a power rating based on 0.1-1000.0 for each PVS server. If PVS1 has a power rating of 1 and PVS2 has a power rating of 2 then PVS2 is considered twice as powerful and will be assigned twice the number of target devices. By default each server power rating is set to 1.0.


Log events to the server’s Windows Event Log (General tab) – Enabling this option will log PVS events to the Windows Event Log.


Streaming IP Addresses (Network tab) – The list of IP addresses that the PVS Stream Service should use for a target device/PVS server communication.


Ports (Network tab) – Range of UDP ports for streaming communication. By default UDP 6910-6930 are used. This allows for 160 Target Devices to stream from one PVS server.


Stores (Stores tab) – List of all stores including their path which is either default from store or an override path.


Active Directory (Options tab) – Allows you to enable which is a default the automation of computer account updates. Also allows you to specify how many days between password updates.


There are also a number of settings in Advanced Server Properties.

Threads per port (Server tab) – The number of threads in the thread pool that service UDP packets received on a given UDP port. Citrix say between four and eight is reasonable. 8 is the default setting. Setting the bar higher allows more target devices per port but consumes more system resources.


Buffers per thread (Server tab) – The number of packet buffers allocated for every thread in a thread pool. Setting this value too large consumes extra memory but does not affect efficiency. Setting the value too small on the otherhand does affect efficiency at the expense of using less RAM.


Server cache timeout (Server tab) – Every PVS server periodically writes status information to the PVS database. Every status information write is time-stamped. A server is considered online by other PVS servers in the farm if the status information in the database is newer than the cache server timeout. Every PVS server in the farm will attempt to write its status information at twice the speed of the timeout value. For example, the timeout value by default is 8 seconds so each PVS server will attempt to write its status information every 4 seconds. A shorter cache timeout value will allow servers to detect offline servers quicker at the expense of more database overhead whilst increasing this value will reduce the database load but servers will take longer to detect offline servers.


Local and Remote Concurrent I/O limits (Server tab) – Controls the number of concurrent I/O transactions that can be sent to a given storage device. A storage device is defined locally (C:\, D:\) or networked via UNC paths. Since the PVS service is a highly multi-threaded service it is possible for it to send hundreds of simultaneous I/O requests to a given storage device. These requests are then usually queued up by the storage device and processed when time permits. Some storage devices (Windows Shares notable) do not cope well with a large number of concurrent requests. As a result connections can be dropped or long times are taken to process transactions. By throttling the I/O transactions in the PVS service, better performance can be achieved. If you have a slow machine providing a network share, or slow drives on the machine, a count of 1 to 3 for the remote limit may be necessary to achieve best performance with the share. If you have fast local drives you may be able to set the local count fairly high. For the optimal setting, you will need to test. Setting either count to 0 disables the feature and allows the PVS service to run without limits. This might be desirable on very fast local drives. By default the remote and local I/O limits are set to 4. If a network share is overloaded, you’ll see a lot more device retries and reconnections during boot storms etc. This is caused by read/write and open file times. Throttling the concurrent I/O transactions on the share reduces these types of problems considerably.


Ethernet maximum transmission unit (MTU) (bytes) (Network tab) – The number of bytes that fit in a single UDP packet. For standard ethernet, the default value of 1506 bytes is correct. If you are attempting to operate over a WAN a smaller value may be needed to prevent IP fragmentation. PVS does not support IP fragmentation and reassembly. If you are using a device or software layer that adds bytes to every packet, a smaller value may be needed to compensate. If your entire infrastructure (PVS NIC, Target Device NIC, Switches and Routers in between) support jumbo packets then you can set the MTU to 50 bytes less than your jumbo packet max size to achieve much higher network throughput.


I/O burst size (KB) (Network tab) – The number of K bytes that will be transmitted in a single read/write transaction before an ACK is sent from the server or device. The larger the I/O burst the faster the throughput to an individual device however more stress is places on the network and server infrastructure. Larger burst I/O also increased the risk of lost packets and costly retries. Smaller I/O bursts reduces the throughput to a client, reduces the server and network infrastructure load and the likelyhood of retries.


Boot pause (seconds) (Pacing tab) – The number of seconds a device will be told to pause if the Maximum devices booting limit has been reached. The device will continue to check with the server ever Boot pause seconds until the server allows the device to boot. By default the boot pause is 10 seconds and the boot device limit is 500 devices.


Maximum boot time (minutes:seconds) (Pacing tab) – The amount of time boot pacing will consider a device to be in the booting stage.


Maximum devices booting (Pacing tab) – The maximum number of devices a server allows to boot at any one time before pausing new booting devices. The number of booting devices must drop below this limit before the server will allow more devices to boot.


vDisk creation pacing (Milliseconds) (Pacing tab) – Amount of pacing delay to introduce when creating a vDisk on this PVS server. Larger values increase the vDisk creation time but reduce PVS server overhead to allow target devices that are running to continue running efficiently. The default vale is 0 milliseconds.


License timeout (minutes:seconds) (Device tab) – The amount of time from last hearing from a target device to hold a license before releasing it for use by another target device. If a target device for example loses power unexpectedly its license is held for this long. Licenses are checked out on boot


.


Copying server properties:

To copy PVS server properties from one server to another PVS server:

Right-click your PVS server -> Copy server properties.


Now select the properties you want to copy and click OK.




Next right-click the destination PVS server and select Paste.


Select the settings you want to paste and click Paste.


Restart the Stream Service on the destination PVS server for the new properties to take effect.


View Target Devices streaming from a PVS server:

To get a list of which Target Devices are streaming of a particular PVS server, right-click the desired PVS server. Click Show connected devices. From here you can reboot Target Devices or send a message etc.

View Target Devices using a vDisk:

Right-click desired vDisk – >Show Usage.


From the Show vDisk Usage screen you can reboot, shutdown or send a message to any of the Target Devices. You can also get information such as Device IP, Server IP, Server Port, Retries, vDisk version, vDisk Full Name and Access mode.


vDisk Load Balancing:

To enable Load Balancing on a vDisk:

Right-click your desired vDisk and select Load Balancing. Under Use the load balancing algorithm select one of the following:

Subnet Affinity – None – Ignore subnets, use least busy server. Default setting.


Subnet Affinity – Best Effort – Use the least busy server/NIC combination from within the same subnet. If no server/NIC combination is available within the subnet, select the least busy server from outside the subnet. If more than one server is available within the selected subnet, perform load balancing between those servers.


Subnet Affinity – Fixed – Use the least busy server/NIC combination from within the same subnet. Perform load balancing between servers in that subnet. If no server/NIC combination exists in the same subnet, do not boot Target Devices assignd to this vDisk.


Rebalance Enabled – This setting (percentage value) can be enabled to rebalance the vDisk should it end up being streamed from a particular server more than other PVS servers that can provide the vDisk. For example, a 20% trigger value would initiate a vDisk rebalance if a server had 20% more load compared to other PVS servers that could provide the vDisk.


Note: The load balancing algorithm takes into account the PVS power rating which is talked about above

.

Target Device Templates:

A template device can exist per Device Collection. Any newly created Target Device can inherit the template settings (apart from name and MAC) to speed up the creation process and decrease manual input. To set a Target Device as the template:

Right-click your desired Target Device -> Set Device as Template -> Yes.


You can also copy Target Device properties to paste on to other devices.

Right-click your desired Target Device -> Copy Device Properties.


Select the properties to copy and click Copy.


Right-click the destination Target Device -> Paste -> Paste.


Note: You can select and paste to multiple Target Devices from the same or different Device Collections.

Copying vDisk properties:

Right-click desired vDisk -> Copy vDisk Properties.


Choose from the list the properties you want to copy then click Cop


.


Right-click the destination vDisk -> Paste -> Paste.


Target Device Status:

The Status tab (right-click Target Device -> Properties -> Status) provides some useful information such as:

IP Address – The IP address of the Target Device.


Server – The PVS server this machine is streaming its vDisk from including PVS server IP and UDP streaming port.


Retries – The amount of retries encountered since the vDisk started streaming to this Target Device.


vDisk – The vDisk name.


vDisk version: The vDisk version number.


vDisk full name: The full vDisk name and extension.


vDisk access: Production, Maintenance or Test.


Shutting down or restarting Target Device or collection of devices:

Either right-click a single Target Device, multiple Target Devices or a Device Collection.


Point to Target Device -> Shutdown or Restart.


Enter a message for users and a value for Delay seconds which will delay the shutdown for the specified seconds.


Click Shutdown devices or Restart Devices.


BIOS-embedded bootstrap:

The BIOS embedded bootstrap feature is for machine that have the PVS bootstrap embedded in to the BIOS. This feature is OEM specific and provides users with systems preconfiugured with PVS. This feature becomes an alternative to the PXE boot method.

Target Device Status Tray:

The Status Tray (Virtual Disk Status) is a piece of software that runs on each Target Device giving information that you can use for troubleshooting or baselines etc. The following below information is presented:

Virtual Disk Information (General tab):

Status – Active or inactive (Target Device is or is not currently accessing this vDisk).


Server – The IP address of the PVS server streaming this vDisk to the Target Device and the UDP streaming port being used.


Boot From – If Target Device is set to boot from vDisk or local Hard Disk or Floppy Disk.


Virtual Disk – The vDisk name that is being streamed to this Target Device.


Mode (General tab):

vDisk – Read Only or Read and Write.


CacheType – Cache type used for example Device RAM with overflow on local hard drive.


Cache Size – Dependant on the cache drive size.


Cache Used – The cache size and percentage used.


Version (General tab) – PVS version and build.


Preferences (General Tab):

Prompt status message in System Tray – Enabled by default. Enables the Status Tray to automatically start when a user logs on to the Target Device.


Show icon in System Tray – Enabled by default. Shows the icon in the notifications tray in Windows.


Boot Statistics (Statistics tab):

Boot time – Number of seconds it took during the boot phases of the operating system. This value doesn’t include POST, BIOS, PXE, DHCP or TFTP processing times.


Retries – The number of packet retries that occured during boot phases.


Bytes Read – The number of bytes read during the boot phases.


Bytes Written – The number of bytes written during boot phases.


Throughput – A value calculating the overall throughput of the software during the boot phases. Throughput is calculated by adding the bytes read/written values then dividing that by the boot time in seconds.


Session Statistics (Statistics tab):

Uptime – The length of time this Target Device has been online.


Retries – The number of packet retries encountered.


Bytes Read – The total number of bytes read.


Bytes Written – The total number of bytes written.


Diagnostic Statistics (Statistics tab):

Uptime – The length of time the Target Device has been online.


Retries – The total number of retries.


Bytes Read – Total number of bytes read.


Bytes Written – Total number of bytes written.


Target Devices that use personal vDisks:

Personal vDisks (PvD) are created using the XenDesktop Setup Wizard (turorial at beginning of this section). These personal vDisks are made for users who use a VDI desktop with a static pooled desktop. PvD’s allow the user to personalise their desktop but still allow the administrator to stream one standard read-only vDisk for example. Personalisation is any change to the desktop such as application installs, application setting changes, document downloads etc.

Default drive letter for PvD is P: but can range from E: to Z:.

vDisk Cache Modes:

The different vDisk cache modes are:

Cache on device hard drive (deprecated 7.12+) – The cache file is stores on an NTFS drive within the Target Device. Write requests are kept within the Target Device. The WC drive should be formatted with MBR. GPT is not supported.


Cache on device hard drive persisted (deprecated 7.12+) – The same as above only the write cache file persists between reboots. This write cache mode is experimental and supported only on NT6.1 or later. This method also requires a different bootstrap (CTXBP.bin).


Cache in device RAM – Write cache can exist as a temporary file in the target devices RAM. This provides the fastest method of disk access as writing to memory is always faster than writing to disk.


Cache in device RAM with overflow on hard disk – The write cache is written to RAM first until the RAM limit is reached. After the RAM limit is reached the least recently used block of data is written to local HDD to accomodate for newer write cache data on RAM. The WC drive should be formatted with MBR. GPT is not supported.


Cache on server – The write cache is stored on a PVS server. This is a slow type of cache feature since writes from the Target Device will need to traverse the network. The cache is wiped on reboot.


Cache on server persistent – Same as above only the cache is retained during reboots. Each Target Device will have their own specific cache file which is uniquely named. Persisted cache files will be persisted if for example you create a maintenance mode version on the vDisk or change the vDisk from Standard to Private Image mode. Invalidated cache files need to be manually deleted.


Note: If you have multiple drives attached to each Target Device and the Write Cache is ending up on the wrong one, create a file called {9E9023A4-7674-41be-8D71-B6C9158313EF}.VDESK.VOL.GUID on each drive that you do not want the Write Cache to reside. For example, C:\ and E:\ have this file present, D:\ does not. This results in the Write Cache being placed on D:\.

Deleting the Write Cache from a persisted server cached vDisk:

This option is only available if the vDisk uses a cache method of Cache on server persisted.

Right-click the Cache on server persisted vDisk -> Delete cache from selected device(s).


Select from the list the devices you want to delete the cache from then click Delete.


Replicating vDisks:

PVS support the replication of vDisks that are stored on local or locally attached storage on PVS servers. I have used DFS-R numerous times with great success. Each PVS server participating in replication must have network connectivity to each other. The PVS files that should be replicated include:

VHDX, AVHDX, and PVP.


.LOK files should not be replicated.


Note: DFS-N (Namespaces) are not supported as store paths.

To view the replication status of a vDisk, right-click the desired vDisk and select Replication.


If replication has not reached one or more PVS servers an orange warning icon will appear beside the server name. Hovering over this icon will indicate why replication is not complete. This can be handy when troubleshooting replication such as when required files are missing or out of date.


Note: The PVS Stream Service account needs to have full control permissions over each vDisk.

Releasing vDisk locks:

vDisk locks occur when Target Devices boot to a vDisk. When the Target Device is gracefully shut down the lock is removed. In some cases such as unexpected power outage to the Target Device, the lock may not be released. The locks however can be released manually by an administrator.

To release a vDisk lock:

 

Right-click on the desired vDisk -> Manage Locks.




Click Yes on the “Ensure vDisk is not in usage” warning.


Check each Target Device you want to release then click Remove Locks.


Expanding a vDisk

Merge all vDisk versions together


Take a copy (backup) of the VHDX file


Use diskpart or GUI to expand the vDisk


Detach vDisk and import back to PVS


Importing Target Devices into a collection:

Target Devices can be imported to a Device Collection from a .csv file. The .csv file can be created with NotePad using a .txt file and then the extension renamed to .csv, or it can be created with Excel.

Each line in the .csv file should be formatted as:

DeviceName,MACAddress,SiteName,CollectionName,Description,Type

All of the properties above are easily identified. The Type field should be either:

0 for production.


1 for test.


2 for maintenance.


The MAC address can contain colons, hashes or nothing.


To access the Import Devices wizard:

Right-click a Device Collection -> Target Devce -> Import Devices




Click Next.


Search for and select the .csv file and click Next.


Choose if you want to apply the template device properties to these imported Target Devices or not. Click Next.


The list of Target Devices to be imported appear. Click Finish.


Managing domain account passwords

When Target Devices boot from a standard mode vDisk, the PVS server assigns the target device its name. In a domain environment, this PVS Target Device name and the password must match the information in the corresponding computer account that exists in Active Directory. If it does not, the Target Device is not able to log on successfully. To achieve name and password compliance the PVS server must manage the domain passwords for Target Devices that share a vDisk.

To allow the PVS to manage passwords, you must disable the Active Directory controlled machine password changes. This can be done via GPO with the setting Domain Member: Disable machine account password changes which is found in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies/Security Options. This policy should be applied to the OU that contains your Target Devices.

To confgure computer account password updates from PVS

Enter the properties of each PVS server.


Click the Options tab.


You can now control the number of days between password updates and it passwords should be updated automatically (default).


Citrix 15. Citrix Fixes – XenServer

Citrix Fixes – XenServer


 


A list containing the majority of Citrix XenServer support articles collated to make this page a one stop place for you to search for and find information regarding any issues you have with the product and its related dependencies.


 


The page is updated daily with new support articles and information. Articles will change from time and if information here is outdated or incorrect please let me know using the comments. Links may also expire or change so if you find broken links, please again let me know. For each issue, known product versions affected are recorded however that does not mean product versions that aren’t listed are not affected.


There is a search box that you can use if looking for a specific fault. For example if you have an error code or error message, use that to perform a search. You can also use your browsers search feature which will perform a search against the whole page based on the words you enter.


 


 

Search: 

Brief Description of IssueBrief Description of FixApplicable Product Versions Affected (if known)Link to supplemental Support Article(s)A XenServer 6.2 to 7.1 upgrade fails with "[Errno 28] No space left on device:'/tmp/backup-rORnXu/.xen-backup-partition'".Find the folders with high inode usage, check which folders have a high number of files e.g. temporary files, and then delete the files from each folder. https://support.citrix.com/article/CTX227290When attempting to install XenTools you receive error "Your Tools ISO is on a broken SR, XenServer will attempt to fix it before proceeding. Do you wish to continue?". Within "xensource.log" is error "Storage_interface.Sr_not_attached".Search for stale/duplicate XenServer Tools Storage Repository by running command "xe sr-list name-label="XenServer Tools". If there are multiple entries, find each one with state "currently-attached (RO): false" and forget them. https://support.citrix.com/article/CTX220219XenServer time is incorrect after changing the BIOS time.Make sure all XenServer hosts in the pool have identical NTP servrs specified. You may have to manually restart the "ntpd" service and then run a manual sync as explained in the CTX article. https://support.citrix.com/article/CTX226572Virtual Machine cannot start with error "VDI is being used by another operation".Look for instances where the VBD is attached to other VMs as described in the CTX article. https://support.citrix.com/article/CTX214407On some high resolution monitors, the XenServer console does not display.Use an alternative monitor or connect remotely via SSH for example and edit the grub config file to edit the VGA section, as outlined in the CTX article. https://support.citrix.com/article/CTX226191You receive error "Internal error: Connection failed: no host resolved" when adding a new server to the pool.Reconnect XenCenter with the IP address of the pool master and then try again. https://support.citrix.com/article/CTX224728Applying a patch through XenCenter results in error "invalid_file". Trying to patch via CLI hangs.This is caused by no SR being elected as the default SR. Right-click on an SR and set it as default.Citrix XenServer 7.1.https://support.citrix.com/article/CTX224142After upgrading an HPSA driver XenServer can no longer boot. You see error "Kernel panic" on the XenServer console.Before upgrading the HPSA driver, add options "hpsa hpsa_allow_any=1" to "/etc/modprob.conf". https://support.citrix.com/article/CTX223518When importing a VHD into XenCenter you receive error "No local storage and no default storage: cannot import Transfer VM" on the XenServer console.Set a default SR for the pool in XenServer and then reinstall the Transfer VM using the steps provided in CTX article. https://support.citrix.com/article/CTX215142The Management Interface shows blank in the Nteworking tab on XenCenter and the pool Management Network bond shows as "unknown" after adding a host to the pool.Find and forget all NICs that are disconnected on both the master host and the host you just added.Citrix XenServer 7.1.https://support.citrix.com/article/CTX223314When selecting a Master Image during Machine Catalog creation you receive error "You must select a disk image with at least one network card",This can happen if you have a VM imported from a previous version of XenServer into a higher version. Create a diskless VM but do not start it. Detach the disk associated to the problematic VM and attach it to the newly created diskless VM. Create a Machine Catalog using this VM as the template. https://support.citrix.com/article/CTX222490XenCenter shows dom0 memory as 4GB after changing it to 32GB, even after a reboot.During reboot the XenServer was booting to "Trusted Boot" mode rather than "XenServer" mode. The Trusted Mode memory setting was set to 4GB. You configure the default XenServer boot mode to boot into "XenServer" mode as explained in the CTX article.Citrix XenServer 7.1.https://support.citrix.com/article/CTX221790On a host that has been removed from the pool, a red X displays beside the host name in XenCenter. When you issue a "xe host-forget" against the removed host you receive error "This host cannot be forgotten because there are some user VMs still running host".You need to determne which VMs are still running on the host and shut them down. This is done via CLI, following the CTX article steps. https://support.citrix.com/article/CTX126382When starting a virtual machine you receive error "Internal error: xenopsd internal error: Device.Ioemu_failed('vgpu exited unexpectedly')".If the ECC feature is enabled on a GRID K2 card (disabled by default), virtual GPU fails to start. vGPU is currently not supported with ECC active. Use "nvidia-smi" to list the status of all GPUs and then issue another nvidia-smi command to disable ECC on the culprit GPU as explained in the CTX article.NVIDIA GRID.https://support.citrix.com/article/CTX219835When using older NVIDIA drivers, XenServer experiences hanging or crashing.Update drivers to latest version from NVIDIA.Citrix XenServer 7.0.https://support.citrix.com/article/CTX223092When pointing XenServer to your license server you receive error "A license for XenServer could not be checked-out because the license server could not be reached at the given address and port. Please check the connection details and verify that the license server is running".Restart the XenServer toolstack, verify the time and date on affected XenServer host, make sure DNS settings are configured correctly so that the license server is resolvable, make sure the firewall is allowing connections. https://support.citrix.com/article/CTX200015Virtual Machines fail to boot with error "No bootable device found".Check the position of the OS disk. The disk should be at position 0. This could also be an issue with the RAM on the physical XenServer host. The "mcelog" will contain any RAM related errors. https://support.citrix.com/article/CTX216911When starting multiple vGPU enabled Virtual Machines, the XenServer host crashes.This is caused by a feature (PML) introduced with Broadwell CPUs that has been adopted in Xen 4.6 and XenServer 7. As a workaround, disable PML via CLI on each host in the pool.Citrix XenServer 7.0.https://support.citrix.com/article/CTX220674When upgrading to XenServer Tools 7.0 you receive error "Windows Management Agent failed to install".Remove "XENBUS" and "XENVIF" keys from the registry using "psexec". Reoot and install the tools again. https://support.citrix.com/article/CTX215427Window Server 2016 VM template is missing from XenServer 7.1.Create the template manually by running command "/usr/bin/create-guest-templates".Citrix XenServer 7.1.https://support.citrix.com/article/CTX221332After upgrading to XenServer 7.1, creating new or reattaching existing NFS storage repositories can fail.Install Hotfix "XS71E003".Citrix XenServer 7.1.https://support.citrix.com/article/CTX223285You may experience a system leak in "systemd" when using SSH.This is a known issue, due to a defect in systemd. Citrix have published a hotfix for XenServer 7.0 and the fix is part of 7.1 CU1.Citrix XenServer 7.0 and 7.1.https://support.citrix.com/article/CTX228129After an upgrade to XenServer 7.1, the hosts do not reconnect to storage.The PDB(s) are likely damaged and need recreated, by following steps from the CTX article. https://support.citrix.com/article/CTX229625When you try and remove a host from the pool you receive error "the SR.shared flag cannot be set to false while the SR remains connected to multple servers".The CTX article explains how destroying a PBD (Physical Block Device) will get around this issue. https://support.citrix.com/article/CTX230692The uploaded update package is invalid.This issue happens when the date on XenServer is older than the date of the "gpg" key. Synchronise the time by running "ntpdate -U 'NTP server IP'" as described in the CTX article.Citrix XenServer 7.1.https://support.citrix.com/article/CTX231197When adding Hardware HBA Storage through XenCenter you receive error "The SCSlid parameter is missing or incorrect".Upgrade XenCenter from 7.1.1.4743 to 7.12.5459.Citrix XenServer 7.1 LTSR CU1.https://support.citrix.com/article/CTX231200XenServer 6.5 upgrade to 7.1 becomes stuck at 72%.The upgrade isn't actually stuck, it is trying to restore all your previous performance related information. Manually archive the files under "/var/xapi/blobs" and then proceed with the upgrade.Citrix XenServer 6.5.https://support.citrix.com/article/CTX224419XenServer unexpectedly reboots due to multipath failovers on a Storage Repository.Download and apply patch "XS71ECU1007".Citrix XenServer 7.0, 7.1, 7.1 CU1.https://supp

Citrix 14. Citrix Receiver launch.ica file does not open – nothing happens

Citrix Receiver launch.ica file does not open – nothing happens





Just reporting on a small issue I had with a machine and brand new Citrix Receiver 4.4 install. Clicking on a published application or desktop resulted in nothing happening. Seemed like the launch.ica file just wasn’t calling Citrix Receiver properly to start the connecting process.



IE wasn’t asking me to save or open launch.ica, this was differrent.

After a Citrix Receiver cleanup and reinstall the same problem remained. I checked the .ica file extension to see what program was associated with it but everything looked OK.

Clutching at straws I decided to manually associate .ica files with the Citrix Connection Manager.



This file by default is located in C:\Program Files (x86)\Citrix\ICA Client\wfcrun32.exe.



Once set, ICA files mysteriously started to launch. Something to look out for!

To set the association, you can choose default applications by file type within Windows or download the ICA file by following the steps located at



Citrix 13. Citrix Receiver for Windows Logging

Citrix Receiver for Windows Logging


 


List of the different types of data you can log with Receiver for Windows.


 

General Receiver Logging

Add the following values to HKLM\Software\Citrix\ (32-bit) or HKLM\Software\WOW6432Node\Citrix\ (64-bit):

DWORD ReceiverVerboseTracingEnabled = 1


When you stop and start Receiver a Receiver_.log file will be created in %USERPROFILE%\AppData\Local\Citrix\Receiver\.

Single Sign-On Logging

You can enable SSON logging which may help in identifying an issue with single sign-on.

Add the following values to HKLM\Software\Citrix\Install\SSON (32-bit) or HKLM\Software\WOW6432Node\Citrix\Install\SSON (64-bit):

REG_SZ DebugEnabled = true


REG_SZ LogPath = Path location


When you log off and on again log files will be created relating to SSON in the path you specified.

The trace-pnsson.log file shows information such as the credentials captured and packaged by SSON.

Authentication Manager Logging

Add the following values to HKLM\Software\Citrix\AuthManager (32-bit) or HKLM\Software\WOW6432Node\Citrix\AuthManager (64-bit):

REG_SZ LoggingMode = Verbose


REG_SZ TracingEnabled = True


REG_SZ SDKTracingEnabled = True


When you stop and start Receiver log files will be created within the sub-folders that are present under %USERPROFILE%\AppData\Local\Citrix\AuthManager\.

Self-Service Plugin Logging

Add the following values to HKLM\Software\Citrix\Dazzle\ (32-bit) or HKLM\Software\WOW6432Node\Citrix\Dazzle\ (64-bit):

REG_SZ Tracing = True


REG_SZ AuxTracing = True


REG_SZ DefaultTracingConfiguration = global all -detail


When you stop and start Receiver log files will be created within the sub-folders that are present under %USERPROFILE%\AppData\Local\Citrix\SelfService\.

Citrix 12. Reduce Citrix logon times by up to 75%

Reduce Citrix logon times by up to 75%


 


Citrix Director is great at recording logon times per session and logon averages over periods of time. We can even produce logon reports and show them off to managers or other teams within the organisation to show them how good (or bad) the virtual workspace performs! Though without any effort you’ll likely be wowing everyone for the wrong reasons until you put in the background work to get logon times down to a low number. Citrix unfortunately doesn’t magically make logons quicker than any other desktop.


Many of the logon friendly optimisations and best practices out there today are straight forward and common sense and help to get you started:


Keep GPOs at a minimum (don’t be GPO happy).


Keep close control of Group Policy incuding monitoring – http://www.jgspiers.com/audit-group-policy-changes/


Don’t map tonnes of drives, especially to users who do not need them.


Don’t map tonnes of printers. Joe who prints to two printers doesn’t need 13 printers mapped to his machine.


Avoid using logon scripts, these are only going to add time to the logon.


Move Group Policy settings to Citrix WEM.


There are more, and I’ll cover off some additional ones in this post to really reduce logon times. If you’re interested in some more tips, see http://www.jgspiers.com/citrix-tips-tricks-tweaks-suggestions/


Also, if you’re interested in finding out more about the logon process see http://www.jgspiers.com/digging-in-to-citrix-logon-process/


So you’ve performed all of the above and more, you’re timings tells you that logon times are no longer than 20 seconds. You look at Director and the logon times are double. Why? There is still one recorded metric that:


Not everyone knows what exactly it is and or struggles to understand it.


Takes a bit of work getting the metric value to reduce, although once you know what it does it’s easier to shave the seconds off.


That metric is: Interactive Session Time.


What is Interactive Session Time?


From https://www.citrix.com/blogs/2016/08/19/interactive-session-of-logon-duration-in-citrix-director-explained/


It is the time taken to handoff keyboard and mouse control to the user after the profile of the user is loaded for a session.


Event ID 2 is initially logged on the VDA shortly after the desktop/application icon is clicked within Receiver client or Receiver for Web. This event triggers the Interactive Session timer which ends once Event 1000 is logged to indicate that the session is ready for use. Event ID 1000 is logged by the Citrix Profile Management service.


So whilst Director records logon times, it is important to understand that this is the time taken from clicking to launch a resource until the machine is actually usable even though the actual logon may have completed some time before that. This produces innacurate results in Director for true logon times so let me show you how you can almost eliminate Interactive Session times, get overall logon times reduced and get Director logging much more accurate data.


My testing environment


For the following logon tests, I used XenDesktop 7.13, running PVS 7.13 and a 7.13 VDA configured with 2GB RAM and 2vCPU. The VDA runs Windows Server 2016 with no optimisations to start however as you will see later it does become optimised and improves logon times. The Target Device Write-Cache is configured as RAM w/overflow to HDD (which is on SSD storage).


Note: The following configurations can be applied to both Server and Desktop OS in persistent and non-persistent environments. You don’t have to implement all of them, consider each one individually. Logon times will also fluctuate based on factors such as load (busy periods), VDA performance and underlying hardware used.


Non-optimised image vs optimised image – logon time results


I built a brand new Windows Server 2016 VDA streaming from PVS. Nothing else was performed on the image. Logged on three times. The average logon time is 68 seconds. That time has advantages such as being able to go and make coffee or produce a logon time report from Director to show your boss, which probably won’t go down all that well. Add applications, larger profiles, Group Policies in to the mix and more seconds get added.




So I’ve gone and optimised my image using the Server 2016 optimisation script. You know optimising an image brings a great sense of satisfaction, not to mention the average time is now down to 38 seconds! That is 20 seconds shaven off just by optimising the image.  Notice also that the Interactive Session time has been greatly reduced, that is because the image is a lot more leaner and can get a session ready more quickly.


Serialize/StartupDelayInMSec – logon time results


It was blogged about here https://xenappblog.com/2016/optimize-logon-times/. Windows Server 2012 and Windows 8 introduced a startup delay for applications which has a negative effect on Interactive Session times. By disabling this delay we can start the applications immediately, not an issue if you have only a few. On the write-mode PVS/MCS gold image or Citrix App Layering OS Layer, launch RegEdit -> HKEY_USERS -> File -> Load Hive.




Load the default user hive by navigating to C:\Users\Default and double-clicking NTUSER.DAT.


Give the hive a name and click OK.


Within the hive navigate to SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer and create a new key called Serialize.


Create a new DWORD 32-bit value within the Serialize key.


Give the value a name of StartupDelayInMSec and a data value of 0x0.


Click File -> Unload Hive.


Click Yes. Finalise the image.


Note: You could have done this through Group Policy, but since it applies to all users we want to reduce the need for Group Policy processing and extra logon processing.


The results of this optimisation show logon time averages down to 27 seconds. An 11 second drop. Remember that each logon here is on a non-persistent machine. The machine is restarted between each logon so as to mimic a first-time session logon (post restart) to VDA where no profile is cached. These current logon times look a lot better and are good for a first-time logon after VDA restart.


Autologon account/the second logon is quicker – logon time results


When a VDA restarts as part of scheduled reboots for example or when non-persistent desktops reboot to reset, the first logon is generally always the longest. So I thought of the idea to use an auto-logon account to be the guinea pig and be the one who first logs on when a VDA restarts. This works well particularly in server OS since the autologon account when it logs off doesn’t trigger any sort of restart to the VDA.


You can use Autologon as pointed out by Chris in the comments. This tool easily configures an autologon account and encrypts the password. https://technet.microsoft.com/en-us/sysinternals/autologon.aspx


When launching autologon, enter the credentials to your autologon account and click Enable.




Click OK. The Winlogon Registry Key will be configured with DefaultUsername/DefaultDomainName string values and so on however the DefaultPassword will not be present and is encrypted.


Restart the VDA. If autologon does not work the first time run through the Autologon tool again and it should work on second attempt.


You can now configure the logoff procedure as described below.


For an alternative method of autologon (this section includes the autologoff procedure):


Open the gold PVS/MCS image again or the OS Layer (Citrix App Layering). On the C:\ drive, create a batch file and call it something like AutoLogon.bat.Within the batch file, enter the following:


 


1

2

call reg delete"HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v"DefaultPassword" /f

call logoff



Now open RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrrentVersion\Winlogon.


Set the AutoAdminLogon value to 1.


Set DefaultDomainName to your domain name as below.


Set DefaultUserName to a user account (service account) which has rights to log on to each VDA. This user account should be secured with a strong password and be a Domain User only. If this DefaultUserName REG_SZ string does not exist, create it.


Set DefaultPassword to the password of the autologon account. Click OK.


Right-click the Winlogon key and select Permissions.


Click Add. Search and add the autologon account.


Give Full Control permissions. This allows the autologon account to delete the DefaultPassword string after each logon. Finalise the image.


Now using Group Policy, create a GPO which is filtered to the autologon account as below. Edit the Group Policy obejct.


Expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).


Under General specify a name. Specify Run only when user is logged on and run the task under the autologon account. For Configure for choose Windows 7 or the highest possible OS.


On the Triggers tab click New.


For Begin the task choose At log on. Check Specific user or group and select the autologon account. Click OK.


On the Actions tab click New.


For Action choose Start a program. Under Program/script enter the path of your batch file which resides on the gold image. Click OK.


Your scheduled task is now created.


Now when the VDA boots up, an autologon occurs. The Scheduled Task runs a batch file which deletes the DefaultPassword string immediately for security and then logs off. The machine is then ready for real user logons.


As a result, the average logon time has dropped to 20 seconds. A 7 second drop. Interactive Session times are a lot lower than when we started these optimisations, over a 40 reduction!


UPMEvent – logon time results – Saving the best to last


Note: This really only applies now to VDA 7.13 and below. Citrix made a change in 7.14.1 that allows upmEvent.exe to run quickly out of the box. To read more visit http://www.jgspiers.com/reduce-citrix-director-interactive-session-time/


For VDA 7.13 and below:


If you had implemented what I am about to show you first, you probably could have cut Interactive Session time by more than 60% immediately.


The Interactive Session time is calculated once Event ID 1000 is logged on the VDA. The faster UPMEvent.exe runs the quicker Event 1000 is logged and the calculation is complete.


So ideally we want the UPMEvent.exe to run once we see that desktop wallpaper screen as that is when the logon is complete. By default, it instead runs some time after the profile has loaded.


The StartupDelayInMSec key added earlier simply speeds up when run keys (startup applications) are started. Hence why the Interactive Session time is decreased because UPMEvent.exe is started quicker since we removed the startup delay.


So what is faster than startup applications specified within run? Removing the upmEvent.exe run key and moving it to the Userinit string as described in http://www.jgspiers.com/reduce-citrix-director-interactive-session-time/


What else is faster than startup applications specified within run? A log on Scheduled Task.


Open your gold image or Citrix App Layering Platform Layer (the Platform Layer should contain your VDA). Launch RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Delete the Citrix UPM UserMsg string. Finalise the image.


Now using Group Policy, create a new GPO which applies to all users logging on to the VDA.


Within the GPO expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).


On the General tab specify a name. Keep the task running under %LogonDomain%\%LogonUser%. Set Configure for to Windows 7 or the highest available OS.


On the Triggers tab click New.


For Begin the task choose At log on and for Any user. Click OK.


On the Actions tab click New.


Under Action select Start a program. Under Program/script enter “C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe” and beside Add arguments (optional) enter wait. Click OK.


Click OK to finish creating the Scheduled Task. Now UPMEvent.exe will be run by the Scheduled Task immediately when the desktop shell has loaded.


With UPMEvent.exe being ran now by the Scheduled Task the average logon time has dropped to 13seconds. A further 7 second drop. Notice the Interactive Session times are all at 3 seconds, more than 50 seconds lower than when we first started. Director is logging true logon times and our future reports will be much more accurate.


Note: In VDA versions before 7.7, upmEvent was called upmUserMsg.