Citrix XenApp 5.0 – Citrix SMA Service dont start

In Citrix XenApp 5.0, only Citrix SMA Service dont start.


Event Type: Error

Event Source: Service Control Manager

Event Category: None

Event ID: 7000 / 7011 / 7009

The ServiceName service failed to start due to the following error:

*The service did not respond to the start or control request in a timely fashion.

*Timeout (30000 milliseconds) waiting for a transaction response from the ServiceName service.

*A timeout was reached (30000 milliseconds) while waiting for the ServiceName service to connect.

To work around this problem, modify the registry to increase the default time-out value for the service control manager. To increase this value to 60 seconds, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:


3. In the right pane, locate the ServicesPipeTimeout entry. If the ServicesPipeTimeout entry does not exist, you must create it. To do this, follow these steps:

a.On the Edit menu, point to New, and then click DWORD Value.

b.Type ServicesPipeTimeout, and then press ENTER.

4. Right-click ServicesPipeTimeout, and then click Modify.

5. Click Decimal, type 60000, and then click OK. This value represents the time in milliseconds before a service times out.

6. Restart the computer.

Posted in Citrix XenApp

Citrix Provisioning Services Boot Process

The PVS target device acquires an IP address using the DORA Process (Discover, Offer, Request and Acknowledge)

1. The Target Device broadcasts DHCP Discover packets.

2. The DHCP Server sends a DHCP offer packet to the Target Device with the IP address, Subnet Mask, lease time, Default Gateway, DNS Server and Domain Name information to the Target Device.

3. The Target Device sends a unicast message to the DHCP Server requesting the offered IP address. A Transaction ID is used to track the accepted offer. The Target Device will send a broadcast message notifying other DHCP Servers that the offer from another DHCP Server was accepted.

4. The DHCP server sends a DHCPACK packet to the Target Device.

Download the bootstrap file from the TFTP server to the Target Device

These are the two popular methods for getting Target Device boot information.

A. Network Booting – with DHCP options (no PXE Service)

1. The TFTP server name and Boot file name (ardbp32.bin) is provided using options 66 & 67. From the TFTP server the bootstrap file is downloaded to the Target Device using the TFTP server name from the DHCP option 66 and filename (ardbp32.bin) from DHCP option 67.

B. Network Booting – with PXE Service (no DHCP options)

1. The firmware of the Target Device adds option 60 to the DHCP Discover packet being broadcast.

2. DHCP server responds with IP Address, Gateway and Subnet information.

3. The PXE server replies with the TFTP server address and bootstrap file name.

4. The Target Device sends a request to the TFTP server for the bootstrap file.

5. The TFTP server replies with the bootstrap file name.

Logon process

After the Target Device gets the IP address and downloads the bootstrap file it proceeds to login to the PVS server to start streaming the vDisk image.

1. The Target device contacts the PVS server specified in the bootstrap file using the default UDP port 6910.

2. The PVS server responds with the IP address and the port number to continue the login process.

3. The Target device contacts and identifies itself by its MAC address to the PVS server.

4. The PVS server replies with all disks, client and policy information needed and sent ot the Target Device.

5. The Target device requests the IP address and information on which vDisk to use.

6. The PVS server grants access for I/O operation and the Target device requests which vDisk will be streamed.

7. The PVS server sends the all the vDisk information including write cache location if the Target Device is in standard mode.

Load Balancing

All PVS servers are capable for acting as both a login server (booting and load balancing) and I/O server (streaming vDisk). A PVS login server normally attempts to load balance devices between all PVS servers that have access to the given vDisk when the Target device initially logs in.

Streaming vDisk (BNISTACK / MIO)

The Target Device and the PVS server continue to communicate exchanging the vDisk data until the Operating system starts loading drivers and the BNISTACK is successfully loaded.

Once the BNISTACK driver is loaded and PVS server and Target Device start handshake and multiple I/O communication begins. At this point the following information is exchanged and the Target device is operation and R/W request continues.

1. vDisk name

2. Image mode

3. Active Directory Password Management Option

4. Write Cache Type and Size

5. Client Name

6. Licensing

Posted in Citrix XenApp

Citrix XenApp shadow failed with error code 120

Mostly this issue would be caused by the end user having multi monitors:

This may be due to the change to the server, either by a removal of the farm, or a misconfiguration which causes a registry key to be deleted.

Follow the below steps to resolve the issue:

On the non-working server open registry key: HKLM\Software\Wow6432Node\Citrix\Install.

Look for a Binary entry called Setting. Note: If this entry is not present, shadowing will not work.

On a working server, open registry key: HKLM\Software\Wow6432Node\Citrix\Install.

Look for a Binary entry called Setting, you will see a binary number

Note the binary number on the working server and on the non-working server; create the binary entry called Setting at:


Enter the number from the working server in the non-working server

Note: Also you may get "Shadow failed. Error code 7044". You cannot shadow a session with multiple monitors enabled in Windows Server 2008 R2. Remote Desktop Services do not support shadowing multiple monitors.

To shadow a system running multiple monitors, they will need to be disabled in the Remote Desktop Connection application. To do this, uncheck the box for Use all my monitors for the remote session.

Posted in Citrix XenApp

Connection Quality Indicator

Connection Quality Indicator

In Citrix environment the published applications would be deployed across the network utilizing physical application servers and numerous workstations and connectivity can be reduced in session basis. Connection Quality Indicator tool provides feedback to the user when the network connectivity has been reduced to the point that the user’s experience is degraded. Displaying this information to the end user will improve overall user experience and users can know the status of the Citrix connection hence reduce the number of calls to help desks for network related user experience issues.


Notifications can be enabled and disabled using Group Policy settings. We can customize notification wording and user preferred notification window location using Group Policy settings. Under real time data users can check available bandwidth


XenApp and XenDesktop 7.7 and higher versions

Microsoft Windows 7 SP1or Windows Server 2008 R2 SP 1 or higher.

Microsoft .NET Framework 4.5.1

Citrix Virtual Delivery Agent 7.6.300 or higher must be installed.

Group Policy Configuration

It is recommended to use Windows Group Policy editor to configure CQI. CQI includes administrative templates files (CitrixCQI.admx CitrixCQI.adml) in the installation directory.

See below information on policy templates files and their respective location.

File Type Location

CitrixCQI.admx Configuration

CitrixCQI.adml Configuration[MUIculture]

CitrixBase.admx Configuration

CitrixBase.adml Configuration[MUIculture]

NOTE: You can use admx/adml template files to configure Local GPO and/or Domain-Based

To add the CitrixCQI.admx/adml template files to the local GPO

After installing Connection Quality Indicator, copy the template files.
From : ConfigurationCitrixCQI.admx
To : %systemroot%policyDefinitions

From : ConfigurationCitrixBase.admx
To : %systemroot%policyDefinitions

From: Configuration[MUIculture]CitrixCQI.adml
To: %systemroot%policyDefinitions[MUIculture]

From : Configuration[MUIculture]CitrixBase.adml
To : %systemroot%policyDefinitions[MUIculture]

CQI template files are available on local GPO “Administrative Templates > Citrix Components > Virtual Desktop Agent > CQI” folder when the user adds the CitrixBase.admx/CitrixBase.adml to the policyDefinitions folder.

Launching CQI on Session Startup

The CQI installer modifies the system in order to launch the tool automatically on session startup. Depending on the type of Virtual Delivery Agent, the method used to launch the tool can vary:

For Server OS Virtual Delivery Agents, the AppSetup registry value is modified and CQI’s Launcher.cmd script is appended to it. The location of the registry key containing this value is as follows:


For Desktop OS Virtual Delivery Agents, a value is added to the Run key which contains a path to CQI’s executable. The location of the registry key containing this value is as follows:


To ensure sessions are logged off properly, The LogoffCheckSysModules registry value is modified and CQI’s executable name is appended to it. The location of the registry key containing this value is as follows:


In order for CQI to be launched for Published applications hosted on Desktop OS Virtual Delivery Agent, the following policy must be applied to the VDA.

Create the user profile by first launching a full desktop session.

Start the Runonce.exe file together with the /AlternateShellStartup switch.

· In the server Group Policy Management Console, navigate to Local Computer Policy > User Configuration > Windows Settings.

· Click Scripts (Logon/Logoff), and then double-click Logon.

· Click Add.

· In the Script name box, type runonce.exe.

· In the Script parameters box, type /AlternateShellStartup.

· Click OK two times

If wfshell is not loaded, the default.profile is not created correctly. This behavior occurs because when the explorer shell is not loaded with the Run registry entry, the RunOnce registry entry and the startup applications are not loaded. If you start a published application which depends on wfshell, it might fail to load because of dependencies executed in the runonce command.


How to Use Connection Quality Indicator

CQI is launched on session startup and continues to run for the life of the session notifying the user of changes to network performance. Notifications are used by CQI to alert the user about network state.

There is a difference when end user interacts with CQI when using a Published Desktop or Application.

When using a Published Desktop, CQI notifications are displayed in two different areas, system tray and standard notifications.

For Published Applications, since there’s no desktop, only standard notifications are shown. If more than one Published Application is in use within the same session, only the foreground application will display the notification.

We can access the Options Panel by clicking on the gear located upper right hand corner of the Notification window, We can snooze notifications for a predetermined amount of time or to reposition notifications to another area of the screen. When snooze is selected, the timer chosen by the user is highlighted in green as shown below. Once the timer has expired, standard notifications will be shown on the next state change. The user can also access the last notification by clicking on the CQI system tray icon for Published Desktops or by using the hot key combination Ctrl+Alt+H for Published Applications. Notifications accessed by the user using these methods will remain visible until explicitly closed.

The position setting can be used to move the notification display area in the screen. Selection of a new notification position takes effect on the next state change or if the user closes the current notification and opens the last notification manually by clicking on the system tray icon (Published Desktop) or hot key combination Ctrl+Alt+H (Published Applications). The user selection is retained by CQI per session type.

Options Panel

System Tray Icon

Notifications are shown to the user and remain visible for a predefined interval when a degraded network condition has been present for a prolonged period of time. Short lived degraded network conditions, although detected by the tool, will not trigger notifications. This behavior is by design and prevents the tool from over notifying the user.

How CQI Uses Counters

CQI uses three counters to monitor the connection quality between an endpoint and the VDA. Each counter contains a low and high threshold that the tool uses to determine which type of notification to display. The counters used by CQI and displayed in the Options Panel under “Real Time Data” section are:

Available bandwidth – Reports how much bandwidth is available for a session to use. CQI monitors this counter to determine if the amount of available bandwidth has fallen, as this may indicate a change in network conditions between an endpoint and the VDA.

Latency – A calculation by the VDA that allows CQI to understand network conditions between an endpoint and the VDA. Unlike ICA Round Trip (ICA Rdtrp), Latency measurements are passive and rely on input activity from the endpoint. As a result, Latency times could be lower than ICA Round Trip (ICA Rdtrp) in some cases, such as variable networks.

ICA Round Trip (ICA Rdtrp) – An active check by the endpoint that allows CQI to understand the screen response time to user input into the session. Unlike Latency, an Administrator can determine how often ICA Round Trip checks are performed by modifying “ICA round trip calculation interval” policy in Studio, default is 15 seconds. ICA Round Trip times tend to be higher than Latency since they also take into consideration processing of user activity on both the VDA and endpoint. For ICA Round Trip calculations to take place, the version of Citrix Receiver on the endpoint must support EUEM (End User Experience Monitoring).


CQI utilizes two logging options, a plain text file maintained per user session and Windows Event Log shared across all user sessions running on VDA.

The plain text log is named Citrix.CQI.log and stored in the temp directory, %temp%CitrixCQI. Application also maintains a single archived log file named Citrix.CQI.{YYYY-MM-DD_HH-MM-SS}.0.log in the same location. Log file size limit is 5 MB.

The same logging information is written to Windows Event log. There are two event log channels, Admin and Debug. To see Debug channel, ensure “Show Analytic and Debug Logs” option is enabled.

The CQI logs can be found under Application and Services LogsCitrixVDACQI directory within Event Viewer application:

Event logs combines messages from all user sessions on VDA.

· Admin channel contains only critical messages, error / warnings.

· Debug channel contains same information as file logs.

Posted in Citrix XenApp, Citrix XenDesktop

Write Cache in Provisioning Services Server

In PVS, write cache describes all the cache modes. The write cache includes data written by the target device and the user data. In vDisk caching mode, the data is not written back to the base vDisk. Instead, it is written to a write cache file in one of the following locations

Cache on device hard disk
Cache in device RAM
Cache on device RAM with overflow on hard disk
Cache on server

When the target device is booted, write cache information is checked to determine the presence of the cache file. If the cache file is not present, the data is then read from the original vDisk file. All current versions of PVS have the option for distributing write cache. It is called Multiple Write Cache Paths. The multiple write cache paths (for a store) option provides the capability of distributing the write cache files across multiple physical media. This feature helps to improve I/O throughput for heavily loaded servers.

When a target device starts the server chooses one of the write cache paths from the list based on the MAC address of the client. The goal of selecting a path based on the MAC address is to get an even distribution of the clients across the available paths. The algorithm selects the same path for a given client each time that client is booted. This functionality is needed to ensure that during a High Availability (HA) failover the new server would choose the same write cache for the client (otherwise it would not be able to find the write cache file and the client would hang). If the defined write cache path is not available to a server, the server falls back to the standard vDisk path.

Cache on device Hard Disk

•Local HD in every device using the vDisk.
•It must be a Basic Volume pre-formatted with NTFS file system with atleast 512MB of free space.

The cache on local HD is stored in a file on a secondary local hard drive of the device. It gets created as an invisible file in the root folder of the secondary local HD. The cache file size grows, as needed, but never gets larger than the original vDisk and frequently not larger than the free space on the original vDisk. It is slower than RAM cache, but faster than Server cache and works in a HA environment.

The lack of space on this drive will bring some slowness in user’s session and this drive needs to be expanded a bit to get back a normal user experience.

To expand these disks two actions need to be done :
1. Expand the Virtual Machine hard disk
2. Expand the disk within the Windows Operation System

Cache in device RAM

•Appropriate amount of physical memory on the machine.

The cache is stored in client RAM. The maximum size of the cache is fixed by a setting in vDisk properties. All written data can be read from local RAM instead of going back to the server. RAM cache is faster than cache on server and works in a HA environment.

Cache on device RAM with overflow on Hard Disk

•Provisioning Service 7.1 or later.
•Windows 7, Windows Server 2008 R2 or later.
•Local HD in every device using the vDisk.

When RAM is zero, the target device write cache is only written to the local disk. When RAM is not zero, the target device write cache is written to RAM first. When RAM is full, the least recently used block of data is written to the local Write Cache disk to accommodate newer data on RAM. The amount of RAM specified is the non-paged kernel memory that the target device consumes.

Cache on Server

•Enough space allocated to where the server cache will be stored.

Server cache is stored in a file on the server, or on a share, SAN, or other location. The file size grows, as needed, but never gets larger than the original vDisk, and frequently not larger than the free space on the original vDisk. It is slower than RAM cache because all reads/writes have to go to the server and be read from a file. The cache gets deleted when the device reboots, that is, on every boot the device reverts to the base image. Changes remain only during a single boot session. Server cache works in a HA environment if all server cache locations to resolve to the same physical storage location. This case type is not recommended for a production environment.

Posted in Citrix, Citrix XenApp | Tagged , , , , , , ,