Zone Data Collector Communications

How does the ZDC keep track of all of the hosts in the farm to make sure they are live?

If ZDC does not receive an update within the configured amount of time from a member server (default: 1 minute) in its zone, it sends a ping (IMAPing) to the member server in question. This timeframe can be configured in the following registry path:
HKEY_LOCAL_MACHINE\Software\Citrix\IMA\Runtime\KeepAliveInterval

If ZDC does not receive an update within the configured amount of time from a peer ZDC server, it does not continually ping the “lost” ZDC. It waits a default of 5 minutes, which is configurable in the following registry path: HKEY_LOCAL_MACHINE\Software\Citrix\IMA\Runtime\GatewayValidationInterval

How does the ZDC ensure servers communicating with are in the farm and authorized to trade information?

For every 30 minutes, the IMA service contacts the central data store to see if anything has changed. There are several layers of security used in this process, including those that exist in the Transport and Host Resolver functions. One of the most important checks a ZDC does to allow a server to communicate within the farm is called a magic number check. Magic Numbers are set the first time a server in a farm is joined into a farm.
If a server in the farm has a different magic number than the ZDC expects, it can cause the server to believe that it is in it’s own farm and declare itself a data collector, thus causing two data collectors to exist in a single zone and causing further zone elections.

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

Citrix XenApp 5.0 – Citrix SMA Service dont start

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

Symptoms:

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control

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: http://support.citrix.com/article/CTX125693

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:

HKLM\Software\Wow6432Node\Citrix\Install.

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.

Futures

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

Requirements

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.
admx:
From : ConfigurationCitrixCQI.admx
To : %systemroot%policyDefinitions

From : ConfigurationCitrixBase.admx
To : %systemroot%policyDefinitions

adml:
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:

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsNTCurrentVersionWinlogon

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:

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun

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:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixwfshellTWI

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.

Reference: https://support.citrix.com/article/CTX127874

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).

Logging

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