MyXenApp

Client Drive Mapping (CDM) on Presentation Server 4.5, XenApp 5.0 is now called Citrix Drive Mapping Redirector (CDMR) .

Presentation Server 4.5 and XenApp 5.0, use the method of ‘network mapping’ the local drive of the user. This method only map local drives, not the network drivers of the user machine. So to map the network drivers we need to use script with ‘net use‘ command and to locate the drives from \CLIENT. Also the administrator has to use a log off script to delete the drives when the users log off.

In XenApp 6.0, the CDM uses the concept of redirection. In a session the mapped drives are classified as Network Drives and the redirected drivers are classified as Other. The users need to modify the policy to allow redirection for network drives on the client’s system. The applications can not find the redirected drives while searching. So the users would require searching \CLIENT inside the session and map the desired drive manually or with the scripts.

The Q disk is a network drive being redirected and the drives are recognized as ‘Others’, because the drives are not mapped but redirected.

Here the drives are mapped and are recognized as ‘Network Drives’.

​

​

Data Collector
XenApp member servers replicate their dynamic data to the Zone Data Collector designated for their zone. XenApp uses a star topology for replication among zones, each ZDC replicates all of its zone dynamic data to all other ZDCs in the farm. Thus, it is important to design zones so that there is adequate bandwidth among ZDCs.

When designing zones, the most important variables to consider are latency and bandwidth. If organization has branch offices with low bandwidth or unreliable connectivity, do not place those branch offices in their own zone. Instead, group them with other sites with which they have the best network connectivity. When combined with other zones, this might form a hub-and-spoke zone configuration.

Citrix recommends to have only one zone in a farm unless it has servers in geographically distributed sites. In large environment with data centers on different continents, grouping geographically-related servers in zones can improve farm performance. Citrix does not recommend exceeding 5 zones and max number of zones can be created is limited to 20.
The hardware resources of all data collectors in the farm are sized to accommodate the largest zone. Since data collectors must manage the global state of the farm, they require the same processing capability of the other data collectors in the farm regardless of the size of their particular zone.

The average user session consumes approx 1.6 KB of memory on the data collector. The average server consumes approx 210 KB of memory on the data collector.
Data collector will send an IMAPing every 60 seconds to ensure that the member server is still up and available to service user requests. Likewise, data collectors will perform an IMAPing to each other every 60 seconds to ensure the remote zones are still available.

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:
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:
HKEY_LOCAL_MACHINE\Software\Citrix\IMA\Runtime\GatewayValidationInterval
Note: Reference http://support.citrix.com/article/CTX112525/

Data Store
During normal farm operation, each Citrix server access the data store every 30 minutes to ensure their LHC is current. During server startup, the IMA Service queries the data store for initialization to ensures the LHC is consistent with the data store. This is the most CPU-intensive action for the data store.
A Farm with 1000 servers, 1000 published applications, 100 worker groups and 10 load evaluators, the IMA data store size requirement will be approximately 500 MB.
License Server

The license server uses approximately 4.5KB of memory for every session license and 39KB of memory for every start-up license that is in-use. The license server is capable of processing 248 license check-out requests per second. Over the course of 30 minutes, a single license server would be able to handle 446,400 users login.

XenApp server establishes a static connection to the license server and checks out a Citrix startup license when it is brought online. It consumes 1.68 KB of bandwidth and occurs for every server in the farm. When users login, the XenApp server requests a license from the license server. It consumes 1.04 KB of bandwidth for a license check-out request or check-in request.
Every XenApp servers will contact the license server in every 5 minutes plus interval to ensure its availability and its called as heartbeat . It consumes 366 bytes of bandwidth for each server. The grace period of the License server is 720 Hrs.

Web Interface
Intel Xeon dual core 2.2 GHz server with 2GB of RAM and HyperThreading turned on can handle 9.2 user requests per second.

Active Directory
Worker groups and their memberships are cached in memory in every IMA service for performance. This results in an increase in memory consumption of 8 KB for every worker group in the farm.

When Citrix policies are managed from the AD domain group policy, the sequence of policy refresh and update is as follows:
1. Change is made on the GPMC
2. Within 1½ to 2 hours, member servers pull and apply updates
3. Every 3 hours, AD replication occurs between domain controllers
4. Within 1½ to 2 hours, remote member servers pull and apply updates

When Citrix policies are managed from the XenApp management console, the sequence of policy refresh and update is as follows:
1. Change is made in AppCenter Console
2. Member server writes the policy change to the DS and updates its LHC
3. All servers pull policy information from the DS and updates their LHCs
4. within 1½ to 2 hours, member servers apply updates to the registry

For troubleshoot Citrix licensing issues we may need to monitor license check-ins and checkouts. The logging of check-ins and checkouts is disabled by default. We can edit the Citrix.opt file located in the C:\Program Files\Citrix\Licensing\MyFiles or C:\Program Files (x86)\Citrix\Licensing\MyFiles folder and add a pound sign (#) to the NOLOG OUT and NOLOG IN statements as:

#NOLOG OUT
#NOLOG IN
Save the file.

Citrix Servers may take a long time to recognize changes that have occurred on the license server or we have a problem where users are not able to login while Presentation Server is not connected to the licensing server or license server changes take long time to propogate, we need to check MPS-WSXICA_MPS-WSXICA.ini file.
When the IMA service on a XenApp Server starts, it contacts the license server to get the license information from the farm. IMA then caches this information locally to the MPS-WSXICA_MPS-WSXICA.ini file on the XenApp Server. This file contains product licenses, number of connection licenses, expiration dates and remaining grace period. By default, the XenApp servers poll the license server every 5 minutes. However, they only check to see if the license server is alive. The cached license information is actually updated every hour. If IMA is busy or unresponsive on a XenApp Server, it is not able to update the cached license record during that interval.

CtxLicChk is a License Server monitoring tool, a command line utility to test the License Server ability to dispense a license to a XenApp server.
We can leverage this tool as a Citrix Health Monitoring and Recovery Test to get alerted, if there is a license checkout problem.
Usage:
CtxLicChk <LicenseServer> <LicenseType>
Example:
CtxLicChk 10.1.2.3 MPS_ENT_CCU