MyXenApp

Citrix XenApp can scale to meet the most demanding and complex business environments. This information helps to maximize the business requirements to provide a scalable and high availability infrastructure while delivering on-demand access to applications and information for the enterprise.  The requirements and associated solutions are consistent with the business needs and challenges that are common to most large scale organizations.

How much storage is needed for the Citrix Datastore?

The Database file size during initial farm creation is around 1184 KB. Adding a server to the farm required 88 KB.
Application publication with 10 Citrix servers with 500 users with default icon required 296 KB.
Application publication with 10 Citrix servers with 5 user groups with default icon required only 40 KB.
Application published in 32-bit color icon required 24 KB. Application published in 256-bit color icon required 48 KB.
Creating a worker group required 2 KB. Creating one load evaluator required 8 KB. Apply load evaluator for 10 servers required 16 KB.

Creating a farm with 1000 servers and 1000 published applications, 100 worker groups to serve as applications silos and 10 load evaluators, the IMA data store size requirement will be approximately 500 MB.

A published application with 32-bit icon consumes about 65KB of memory  on the data collector. The average user session consumes approximately 1.6 KB of memory on the data collector. The average Citrix server consumes approximately 210 KB of memory on the data collector.

Resource utilization of the License server?

A single license server can adequately handle the load placed on it by a thousand servers and tens of thousands of users.  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. In a given scenario with all users logging in over the course of 30 minutes, a single license server would be able to handle 446400 users.

When a XenApp server comes online, it establishes a static connection to the license server and checks out a Citrix startup license. Also every 5 minutes, the XenApp servers will contact the license server to ensure it is still available. This action consumes 1.68 KB of bandwidth and occurs for every server in the farm. Once a startup license is checked out, the server holds this license until it is taken offline or the license server location is changed.

When a client logs in, the XenApp server requests a license from the license server on behalf of the client. The amount of bandwidth consumed for a license check-out request or check-in request is 1.04 KB. Every 5 minutes, each XenApp server exchanges a heartbeat with the license server to check license server’s availability and it requires the bandwidth of 366 bytes for each server. The timing of the heartbeat is based on the start time of the IMA Service.

Web Interface server requirement

The number of users that a single Web Interface server can support is dependent on the processor speed rather than the number of processors in the system.  Web Interface server with Windows 2008 R2 / IIS 7.0 / Intel Xeon X3360 dual core 2.2 GHz processor with 2GB of RAM is able to handle 9 user requests per second. Approximately the Web Interface server can service 30,000 users per hour.

Knowing Group Policy Management refresh intervals

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

Resource utilization of IMA Communications

After the XenApp server starts, every 30 minutes the local host cache will perform a consistency check to ensure it is in sync with the Datastore. Every 60 seconds the Data Collector will send an IMAPing to  ensure the  member server is alive.

Planning worker groups

Adding 200 worker groups will increase 2.5 seconds for the management console discovery time, while 500 worker groups increase the discovery time by 4.2 seconds. Worker groups and their memberships are cached in memory in every IMA service for performance. This will increase the memory consumption of about 8 KB for every worker group in the farm.

net stop winmgmt
c:
cd %systemroot%\system32\wbem
rd /S /Q repository

regsvr32 /s %systemroot%\system32\scecli.dll
regsvr32 /s %systemroot%\system32\userenv.dll

mofcomp cimwin32.mof
mofcomp cimwin32.mfl
mofcomp rsop.mof
mofcomp rsop.mfl
for /f %s in (‘dir /b /s *.dll’) do regsvr32 /s %s
for /f %s in (‘dir /b *.mof’) do mofcomp %s
for /f %s in (‘dir /b *.mfl’) do mofcomp %s

Recompile Citrix .MOF files:
cd %programfiles%\citrix\system32\citrix\wmi
for /f %s in (‘dir /b *.mof *.mfl’) do mofcomp %s
net start winmgmt

1. From VSphere client clone existing production Citrix server.
2. Remove the network adapter and power on the VM.
3. Run the SysPrep by selecting Generalize
4. Update the hostname and join to a WORKGORUP
5. Disable the Citrix IMA and Citrix MFCOM services.
6. Reboot the server.
7. Apply a new IP address.
8. Connect the production network adapter.
9. Join to the domain.
10. Move the server to the corresponding OU in Active Directory.
11. Update the registry keys: HLKM\Software\WOW6432Node\Citrix\IMA\Runtime\Hostname = {Citrix Server Name}
12. Uninstall and Install Antivirus software.
13. Recreate the Local Host Cache (dsmaint recreatelhc).
14. Reboot the server.
15. Change the Citrix IMA and Citrix MFCOM services from Disabled to Automatic. Start both services.
16. From Citrix AppCenter console check if the new server is available.
17. If Citrix System Monitoring Agent is installed, stop Citrix System Monitoring Agent service.
18. Rename RSDATR.FDB file to RSDATR.FDB_old located in “C:\Programdata\Citrix\System Monitoring\Data”.
19. Start Citrix System Monitoring Agent service.
20. Move the Citrix XenApp Servers to correct folder location in Citrix AppCenter console.

In previous versions of StoreFront servers (2.6 or older), Citrix recommended to manually modify the hosts file on each StoreFront server to map FQDN of the load balancer to the IP address of the specific StoreFront server or the loopback address.

This is necessary because an HTTP session is created during the explicit login process between Receiver for Web and the authentication service and Receiver for Web communicates with StoreFront services using the base FQDN. If the base FQDN were to resolve to the load balancer, the load balancer could potentially send the traffic to a different StoreFront server in the group, leading to authentication failure.

By doing this Receiver for Web always communicates with the StoreFront services on the same server in a load balanced StoreFront deployment.

You can set loopback options using PowerShell. Enabling loopback negates the need to create host file entries on every StoreFront server in the server group.

Example – Receiver for Web web.config file:
<communication attempts=”2″ timeout=”00:01:00″ loopback=”On” loopbackPortUsingHttp=”80″>

Example – PowerShell command:
& “c:\program files\Citrix\receiver storefront\scripts\ImportModules.ps1”
Set-DSLoopback -SiteId 1 -VirtualPath “/Citrix/StoreWeb” -Loopback “OnUsingHttp” -LoopbackPortUsingHttp81

From StoreFront 3.0, we can enable loopback in the StoreFront Console.

Classic Receiver Experience

To help you smooth the transition, StoreFront 3.0 supports the classic Receiver experience and when we upgrade from StoreFront 2.x to 3.0, the UI for the existing Receiver for Web sites will remain as the classic green bubble UI. When you create new Receiver for Web sites after the upgrade, users will see the new unified UI.
We can enable the new unified UI by selecting the Disable Classic Receiver Experience and Set Unified Experience as Default in Receiver for Web site.

Google Chrome Support without NPAPI

Google Chrome on Windows and Mac is fully supported without Netscape Plugin Application Programming Interface (NPAPI) in StoreFront 3.0. Receiver for Windows 4.3 and Receiver for Mac 12.0 support this features.

No Need of Editing Hosts File

Previously, as stated here, Citrix recommends that you modify the hosts file on your StoreFront servers to ensure that Receiver for Web always talks to the local StoreFront server instead of the load balancer. In StoreFront 3.0, we leverage a new feature in the .NET Framework 4.5 to implement loopback communication between Receiver for Web and the rest of StoreFront Services. This is configurable using PowerShell cmdlet

Syntax:
Set-DSLoopback [-SiteId] &lt;Int64&gt; [-VirtualPath] &lt;String&gt; [-Loopback] &lt;String&gt; [[-LoopbackPortUsingHttp] &lt;Int32&gt;]

Example:
Set-DSLoopback -SiteId 1 -VirtualPath /Citrix/StoreWeb -Loopback OnUsingHttp -LoopbackPortUsingHttp 81

Delegating Authentication to the Backend Providers

StoreFront 2.x communicates with the Active Directory to authenticate users. So the domain hosting StoreFront servers should have one-way external trust to the domain hosting the backend XenApp farms/sites. This may not be possible in some deployments. StoreFront 3.0 has the capability to delegate authentication to the XenApp farms.

Treating All Desktops as Applications

In earlier StoreFront, Desktops and applications are treated differently and are placed in a separate tabs in Receiver for Web. To keep published Desktop in the same tab with published applications, we have to add the TreatAsApp keyword to the published desktops. StoreFront 3.0 enables you to configure treating all desktops as applications at the store level without the need of adding the TreatAsApp keyword to all the published desktops

Integrated Monitoring Service for NetScaler

Before StoreFront 3.0, we have to install add-on package on the StoreFront server to support NetScaler monitoring. Now from StoreFront 3.0 it is integrated in StoreFront 3.0. It is installed and enabled by default. You can use PowerShell commands to modify the settings of this service or disable this service.

To check the URL for this service, use the cmdlet:

Set-DSServiceMonitorFeature -ServiceUrl https://localhost:444/StorefrontMonitor