New Data Collector ElectionProcess

New Data Collector Election Process

When a communication failure occurs between a member server and the data collector for its zone or between data collectors, the election process begins in the zone. Here are some examples of how ZDC elections can be triggered and a high level of summary of the election process. A detailed description of this process and the associated functions used is further below in this document.

1. The existing data collector for Zone 1 has an unplanned failure for some reason, that is, a RAID controller fails causing the server to blue screen. If the server is shutdown gracefully, it triggers the election process before going down.

2. The servers in the zone recognize the data collector has gone down and start the election process.

3. The member servers in the zone then send all of their information to the new data collector for the zone. This is a function of the number each server has of sessions, disconnected session and applications.

4. In turn the new data collector replicates this information to all other data collectors in the farm.

Important: The data collector election process is not dependent on the data store.

Note: If the data collector goes down, sessions connected to other servers in the farm are unaffected.

Misconception: “If a data collector goes down, there is a single point of failure.”

Actual: The data collector election process is triggered automatically without administrative intervention. Existing as well as incoming users are not affected by the election process, as a new data collector is elected almost instantaneously. Data collector elections are not dependent on the data store.

Detailed Election Process:

As we know, each server in the zone has a ranking that is assigned to it. This ranking is configurable such that the servers in a zone can be ranked by an administrator in terms of which server is most desired to serve as the zone master. “Ties” between servers with the same administrative ranking are broken by using the HOST IDs assigned to the servers; the higher the host ID, the higher-ranked the host.

The process that occurs when an election situation begins is as follows:

1. When a server comes on-line, or fails to contact the previously-elected zone master, it starts an election by sending an ELECT_MASTER message to each of the hosts in the zone that are ranked higher than it.

2. When a server receives an ELECT_MASTER message, it replies to the sender with an ELECT_MASTER_ACK message. This ACK informs the sender that the receiving host will take over the responsibility of electing a new master. If the receiving host is not already in an election, it will continue the election by sending an ELECT_MASTER message to all of the hosts that are ranked higher than itself.

3. If a server does not receive any ELECT_MASTER_ACK messages from the higher-ranked hosts to which it sent ELECT_MASTER, it will assume that it is the highest ranked host that is alive, and will then send a DECLARE_MASTER message to all other hosts in the zone.

4. When a server that has previously sent an ELECT_MASTER message to the higher-ranked host(s) in the zone receives an ELECT_MASTER_ACK from at least one of those hosts, it enters a wait state, waiting for the receipt of a DECLARE_MASTER from another host. If a configurable timeout expires before this DECLARE_MASTER is received, the host will increase its timeout and begin the election again.

At the conclusion of the election, each host will have received a DECLARE_MASTER message from the new zone master.


Posted in Citrix

Specifying Backup Data Collectors

When you create a server farm and whenever a new server joins a zone, a server is elected as the data collector for that zone. If the data collector for the zone becomes unavailable, a new data collector is elected for the zone based on a simple ranking of servers in the zone.

Important: A primary domain controller or backup domain controller must not become the data collector for a zone. This situation may arise if XenApp is installed on Windows domain controllers. Citrix does not recommend such installations.

To set the data collector election preference of a server

1. Depending on the version of XenApp you have installed:
   • From the Start menu, open All Programs > Citrix > Administration Tools and choose XenApp Advanced Configuration.
   • From the ICA toolbar, open the Presentation Server Console.
2. Select the farm.
3. On the Actions menu, click Properties.
4. Select Zones.
5. In the list of zones and their servers, locate the server, select it, and click Set Election Preference.
6. Select the ranking for the server by choosing from the following election options:
   
   Important: If you change the server name of the data collector, the new server name is added to the list of servers in the farm. The old server name is still listed as a member of your farm and must be removed using the Access Management Console. Before removing the old server name, you must update the data collector ranking for the new server name.

   
   Most Preferred

   The server is always the first choice to become the data collector. It is recommended that only one server per zone be given this setting.

   
   Preferred

   When electing a new data collector, XenApp elects the next collector from the Preferred servers if the Most Preferred server is not available.

   
   Default Preference

   The default setting for all servers. The next collector is selected from the Default servers if neither a Most Preferred server nor a Preferred server is available.

   
   Not Preferred

   Apply this setting to servers that you do not want to become the data collector for the zone. This setting means that this server becomes the data collector only when no servers are available with any of the other three settings (Most Preferred, Preferred, Default Preference).

Flow chart to troubleshoot Citrix Issues-2

 

Session Sharing

 

 

Server Performance

 

Citrix Printing Problems

 

 



Flow chart to troubleshoot Citrix Issues-1

Basic

Check Citrix Services

Check Secure Gateway

Check Terminal Services

 

 

Unable to Telnet to port 1494.

Symtoms

1.  Unable to telnet to port 1494. Connecting to servername.
2. Could not opena connection to host on port 1494: Connect failed..
3. NetStat -a does not show the server listening on port 1494.
4.  A Microsoft RDP connection works (MSTSC). 
5.  Idle sessions are available and the ICA listener (TSCC.MSC) is created andenabled.

How to Hide Published Applications in web-interface?

Use the following steps to complete the task: 
1. Unzip the file Global.asax.zip. It contains the modified global.asax file for each Web Interface 5.x version. Make sure to use the correct one, otherwise compilation errors may occur.

2. To verify the version of Web Interface, check under Add/Remove Programs (or Programs and Features) for Citrix Web Interface component.

Note: Make sure to read the readme file for Web Interface Backup the global.asax file located in the Citrix/xenApp/ directory. For Web Interface 5.2, 5.3, and 5.4 only, be sure to back up global.asax.cs in the Citrix/XenApp/App_code directory by renaming the file as global.asax.old or moving the file out of the Inetpub directory.

3. Do not leave both (original and modified) global.asax files with the .cs extension in the same directory. Only leave the modified global.asax file. Otherwise, Web Interface generates an internal error during compilation. Place the attached global.asax file in the Citrix/XenApp directory.
For Web Interface 5.2, 5.3, and 5.4 only, place the global.asax.cs file in the Citrix/XenApp/App_code directory. For Web Interface 5.4 only, get the HiddenFoldersFilter.java and HiddenApplicationsFilter.java files from the WI_5.4 folder (inside the global.asax.zip file) and place them in the following location: C:\Inetpub\wwwroot\Citrix\XenApp\app_code\PagesJava\com\citrix\wi\pageutils Add the following line to the C:\Inetpub\wwwroot\Citrix/xenApp/conf/WebInterface.conf file: HiddenFolders= (example: HiddenFolders=\FolderA, \FolderB\SubFolderC)

Note: Make sure to place the backslash (\) before the folder name. - Or - HiddenApps= (example: HiddenApps=Calculator, Admin Tools) Save file and test.
Note: The entries in HiddenFolders= must contain unique folder names and cannot be a name which is a subset of an existing folder. For example, if two folders exist named “Folder” and “Folder2” and you intend to hide “Folder” by adding the entry “HiddenFolders=\Folder”, this makes “Folder2” inoperable. Instead, rename “Folder” to “Folder1” so “HiddenFolders=\Folder1” maintains its uniqueness.

Link to download zip file. http://www.thomaskoetzing.de/index.php?option=com_content&task=view&id=56&Itemid=96

Citrix vendor daemon down

Licenses are granted by the Citrix vendor daemon (Citrix.exe), a process that runs on the license server. The Citrix vendor daemon tracks the number of licenses that are checked out and which product has them. Citrix products communicate with the Citrix vendor daemon using TCP/IP. By default, the Citrix vendor daemon uses TCP/IP port 7279.

Scheduled a script on license server to restart Citrix licensing server every 2 hours. This is to prevent license service hung issue. No user has reported issue after applying of this fix.However we need to have a permanent fix of this as it may lead to server crash.

Vendor daemon down: CITRIX error is coming in licensing console after every 3-4 hours

In the lmadmin log file, we are getting the below error messages - root.Vendor (CITRIX)

ERROR: receiving response message. root.Vendor (CITRIX) ERROR:
connect failed.   Event Id 1004 in event log - Reporting queued error: faulting application lmadmin.exe, version 0.0.0.0,
faulting module unknown, version 0.0.0.0,
fault address 0x00000000,
This started coming from 5th Sep..  
In event logs there were many errors related to McAfee (Not related to this issue however should be resolved) No error comes while running command line in Lmdiag/lmstat.
Warning\Information events occurring in Citrix server\s (Event ID 9026 ,9015 and 26) In server farm, licensing server is denoted with its name (CLSCiproca). However it is recommended to mention the IP address (10.60.24.82) there to avoid any DNS/IP resolution issues. Try uploading the licensing file again in licensing console. Need admin rights to do that.   We can also try configuring another static port for Vendor Daemon, presently it is running on port 27001.

https://support.citrix.com/servlet/KbServlet/download/17935-102665672/firewalls_and_security_v11.3.pdf ,

We can try running the LSQuery utility, which is used to collect necessary data to assist in troubleshooting for licensing server issues. Reallocate the Citrix license from Citrix licensing portal to avoid 9015 error.

 http://support.citrix.com/article/CTX115870 http://support.citrix.com/article/CTX106670 Try renaming current_state.xml as per the below article to resolve lmadmin faulting event log

http://www.itexperience.net/2011/12/14/citrix-licensing-service-crashes-after-startup-event-1000-lmadmin-exe/

Recommendation Raise incident with McAfee team to resolve the McAfee events.   We may need to reinstall the Licensing or upgrade it to latest version.

http://forums.citrix.com/thread.jspa?threadID=313690 http://forums.citrix.com/thread.jspa?threadID=266764

We can also try creating a new VM with same host name and take it out of network, install the Citrix Licensing role on that and upload the existing licensing file. This will help to check if the license file itself is corrupted or not. As per citrix, we can also try installing Hotfix Rollup Pack 7 on XenApp servers. However will recommend a rigorous testing of this before applying. 

http://support.citrix.com/article/CTX123372

Would request to grant the Admin Access over Licensing Console to dig more into such kind of issues.

Fix - We had another server with same web-interface version. We copied citrix.exe from there and paste it in respective folder.

What is LHC?

The IMA service running on each Presentation Server downloads the information it needs from the central data store into a local MDB database called the local host cache, or “LHC.” (The location of the local host cache is specified via a DSN referenced in the registry of the Presentation Server, at HKLM\SOFTWARE\Citrix\IMA\LHCDatasource\DataSourceName. By default this is a file called “Imalhc.dsn” and is stored in the same place as MF20.dsn.) Each Presentation Server is smart enough to only download information from the data store that is relevant to it, meaning that the local host cache is unique for every server. Citrix created the local host cache for two reasons: 1. Permits a server to function in the absence of datastore connectivity. 2. Improves performance by caching information used by ICA Clients for enumeration and application resolution. The LHC is an Access database (Imalhc.mdb) stored default in the path "\Citrix\Independent Management Architecture" folder. LHC contained the following information: 1. All servers in the farm, and their basic information. 2. All applications published within the farm and their properties. 3. All Windows network domain trust relationships within the farm. 4. All information specific to itself. (product code, SNMP settings, licensing information) The LHC is critical in a CPS environment. In fact, it's the exclusive interface of the data store to the local server. The local server's IMA service only interacts with the LHC. It never contacts the central data store except when it's updating the LHC. If the server loses its connection to the central data store, there's no limit to how long it will continue to function. (In MetaFrame XP, this is limited to 48 or 96 hours, but that was because the data store also store license information.) But today, the server can run forever from the LHC and won't even skip a beat if the central connection is lost. In fact now you can even reboot the server when the central data store is down, and the IMA service will start from the LHC with out any problem. (Older versions of MetaFrame required a registry modification to start the IMA service from the LHC.) The LHC file is always in use when IMA is running, so it's not possible to delete it or anything. In theory it's possible that this file could become corrupted, and if this happens I guess all sorts of weird things could happen to your server. If you think this is the case in your environment, you can stop the IMA service and run the command "dsmaint recreatelhc" to recreate the local host cache file, although honestly I don't think this fixes anything very often. Local Host Cache is synchronised with the Data Store by the Zone Data Collector for every 30 minutes and it can also be configured through registry

www.myxenapp.com

www.myxenapp.com

TS CAL

A good example to what to use is if you have a call centre with 25 client machines. To start with you work 9 to 5 with all 25 connected. With citrix as well you would need 25 PS licenses, and 25 TS cals of either Device or User. Making sure that the citrix servers are set to the right TS cal version. If you change to 24x7 with 3 shifts working 8 hours then you would only ever have 25 citrix connections con current, so you would need 25 licenses, but TS is different. If you use per user license then you would need 75 licenses as you have potentially 75 users that are connecting. If you have TS cals per device then you would still only need 25 licenses as you only have 25 devices that are connecting to your servers. If you then have other servers that these users need to connect to that are TS servers then they don't need additional licenses if the license mode eg user/device are the same as they already have a license.

per device - if you own 25 citrix license you will need 25 ts cals,
that would be a 1 to 1 ratio.

Per user - you would need 25 CPS X amount of user.