On-demand application delivery with Citrix XenApp

How application virtualization and session virtualization work

Citrix XenApp is an on-demand application delivery solution that comprises application virtualization and session virtualization technologies.

Understanding application virtualization

Citrix application virtualization technology isolates applications from the underlying operating system and from other applications to increase compatibility and manageability. As a modern application delivery solution, XenApp virtualizes applications via integrated application streaming and isolation technology. This application virtualization technology enables applications to be streamed from a centralized location into an isolation environment on the target device where they will execute. With XenApp, applications are not installed in the traditional sense. The application files, configuration, and settings are copied to the target device and the application execution at run time is controlled by the application virtualization layer. When executed, the application run time believes that it is interfacing directly with the operating system when, in fact, it is interfacing with a virtualization environment that proxies all requests to the operating system.

 XenApp is unique in that it is a complete system for application delivery, offering both online and offline application access through a combination of application hosting and application streaming directly to user devices. When users request an application, XenApp determines if their device is compatible and capable of running the application in question. The minimum requirements of a target device are a compatible Windows® operating system and appropriate Citrix client software. If the user device meets minimum requirements, then XenApp initiates application virtualization via application streaming directly into an isolated environment on the user’s device. In the event that the user device is not capable of running a particular application, XenApp initiates session virtualization.

Understanding session virtualization

Session virtualization uses application streaming to deliver applications to hosting servers in the datacenter. XenApp then connects the user to the server to which the application has been delivered. The application then executes entirely on the server. The user interacts with the application remotely by sending mouse-clicks and keystrokes to the server. The server then responds by sending screen updates back to the user’s device. Whereas application virtualization is limited to Windows-based operating systems at this time, session virtualization via XenApp allows any user on any operating system to access any application delivered by IT. As a result, XenApp enables Windows, Mac, Linux, UNIX, thin clients, iPhone®, Windows Mobile® devices, and even Symbian- and Java-enabled devices to run any applications using session virtualization. Furthermore, session virtualization leverages server-side processing power which liberates IT from the endless cycle of PC hardware refreshes which are typically needed to support application upgrades when using traditional application deployment methods.

Using application virtualization and session virtualization together

In both application virtualization and session virtualization, user interaction with the application is seamless. Printers, drives, peripherals, and even the clipboard work in the exact same manner as if the application were installed. As a result, XenApp reduces the cost of application management and related costs by up to 50 percent and enables a better-than-installed experience for users when compared to traditional application deployment models.

Read More

Session initialization in Citrix

No matter how an ICA session is invoked (Program Neighborhood, Web Interface, double-clicking an ICA file, etc.), the ICA client engine (wfica32.exe for Win32 clients) fires up and loads the module.ini file from the root folder of the ICA Client. The module.ini file defines the specific capabilities that the ICA client should or can use. Therefore, when troubleshooting, it’s possible (and useful) to change settings in the module.ini to change the capabilities of the ICA Client. For example, you might chose to disable specific client drives (DisableDrives=A,D,F) or to enable server drives in a pass-through session (NativeDriveMapping=TRUE).

The following screen shot has highlighted the module.ini section where the virtual drivers that get loaded by the ICA client are specified. For testing purposes you could just choose to remove a specific virtual driver all together. This will prevent the client engine of loading the specific virtual driver, for example SmartCard, SpeechMike, ClientAudio etc.
 

Some virtual drivers (like clipboard functionality) are “built into” the client engine. Removing the word “Clipboard” from that VirtualDriver line will only disable the Clipboard on a client basis.
Once the ICA client works out which drivers it will use, it starts a connection with the server via port 1494 (even with session reliability enabled). The server responses with “7F7FICA” for an ICA handshake as shown in the next screen shot. During the handshake the client sends its list of capabilities (virtual channels supported by the client) to the server.



Next, (still before anything shows up in any admin console or on the client desktop), the TSCAL license verification is made. If the license cannot be verified then the session just ends. Even though this is by design it’s still very confusing for most people.

If the client has or gets a valid TSCAL, the server’s WinLogon.exe process calls the GINA (and any linked GINAs, like ctxgina.dll when MetaFrame is installed) and the user is presented with the logon GUI. Once the user credentials are validated via csrss.exe, WinLogon downloads the user profile. (Here is a nice article about profiles http://www.windowsitpro.com/Windows/Article/ArticleID/41654/41654.html)
The GINA then calls UserInit.exe which is responsible for setting up the user’s environment (restoring net uses, etc.). When Terminal Server is installed, UserInit queries the registry key AppSetup located in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon and executes all the programs listed in that key. By default this is limited to UsrLogon.cmd, although MetaFrame XP adds cmstart.exe to the list and MetaFrame version 3 adds CtxHide UsrLogon.cmd, and CmStart.exe. (Those of you who’ve been using Terminal Server for awhile will remember that UsrLogon.com is a hold-over from the early days when application compatibility scripts were used. See Microsoft article Q195950.)
The last thing UserInit does is launch the user’s shell as specified in the registry. By default this is explorer.exe, although you can change it to whatever you want and have some fun with your colleagues by changing theirs to progman.exe.
Once the shell is fired up the final steps take place, including items listed in the run registry keys and the programs from the Startup folder.
There’s a great utility from SysInternals called “AutoRuns” that you can run on a server to quickly and graphically show you all the things that run automatically when a session is started.



Everything on the server side that we’ve mentioned so far is Microsoft only. It applies if you’re connecting via a standard Terminal Server / RDP session or via a MetaFrame ICA session, (For more detail on WinLogon, UserInit, Csrss, and other Windows processes, take a look at Microsoft Knowledge Base article Q263201.)
Now let’s take a look at what happens when Citrix is thrown in the picture. As we mentioned earler, UserInit also executes the CmStart.exe process. CmStart.exe is the Citrix Client Manager Starting Utility and it’s responsible for two things:

1. It starts the Citrix seamless windows engine shell called wfshell.exe.
2. It launches the Citrix Client Manager (cltmgr.exe ) that’s used to keep the ICA client up to date.

The following screenshot is of Systernals’ Process Explorer running during a MetaFrame session start.



Let’s take a closer look at these processes and what they each do.
Citrix Client Manager Starting Utility (CmStart.exe)
CmStart is responsible for launching the seamless engine which means no seamless windows without CmStart.exe in the AppSetup Key! This missing entry will not stop a desktop session from working though.

Citrix Seamless engine (wfshell.exe)
One of the things wfshell is responsible for is to autocreate the client printers. If you are using third party printer drivers (HP, Canon, Lexmark etc.) instead of original printer drivers that come on the Windows CD then you might see some of the following issues:

• Crashes of wfshell.exe (CTX102634)
• High CPU spikes of wfshell.exe
• Slow logons
• Printer being not mapped

Advice: Don’t use third party printer drivers. Instead, use mappings from the printer matrix at http://www.printingsupport.com and at least don’t use PCL6 Drivers an advice by Stefan.

Citrix Client Manager (cltmgr.exe )
Cltmgr.exe is launched right after wfshell because it uses a virtual channel (VDCM.dll, ClientManagement) to get the client version from the version.dat file. Problems with the retrieving of the ICA client version and the update might have the following effects:

• Crashes of wfshell.exe
• Slow logons (without updating the client)

Advice: If the Client Update feature is not used, you should disable the client update database on every Citrix server (Start | Run | cudutil.exe | Database | Properties | uncheck enable).
Session Termination
When closing a published application or logging off from a desktop session, the most important parts are terminating the user processes and unloading the user’s registry hive from the system registry.
In a desktop session the termination of the processes is done by csrss.exe. With published applications the seamless engine is responsible for closing the applications and sending the logoff message to csrss. Under certain circumstances this might not work and ends with a user’s session remaining active on the Citrix Server, although we’ll discuss this more later.
In some cases the user’s registry can not be unloaded during the logoff. This issue is very famous in the community and the solution is to use the Microsoft’s UPHClean service. (Be sure you’re using the most current version.) If the unload process doesn’t work as expected, then the profile gets stuck on the server (a bit different with Windows 2003). This then impacts the logon process, especially with anonymous users.

Read More

Command to know in which server is the Web Interface installed.

How to know in which server is the web interface installed?

First copy psinfo.exe from PSTOOLS to your desktop(or any folder) and execute the below command.

psinfo \\servername/ -s  | find "web interface"
ex: psinfo \\mycitrixserver/ -s | find "web interface"

If you have more number of servers, you can use the same command in a batch script and use it.

Create a text file called citrixserverlist.txt and update all your citrix servers list into that text file. Now copy the below script into citrixservers.bat and run it.

Batch Script is as follows:

@echo off
for /f  %%i in (citrixserverlist.txt) do psinfo \\%%i/ | find /i "Web interface"
pause

Read More

Enabling Pass through Authentication in Citrix

You can pass user credentials to Web servers on the secured network configured for Basic, Digest, or Integrated Windows Authentication. This feature avoids requiring users to enter their credentials multiple times to access Web resources. For example, if a team Web site in your organization is configured for Digest Authentication, you can pass the credentials with which users log on to the Access Gateway to that site. If you do not enable the URL address to support Digest Authentication, users might be required to log on to the Web site.

Note that the authentication required for a Web site is determined by the settings of the site’s host Web server.
When configuring a Web resource, you can enable its URL addresses to use one of the following methods of pass-through authentication:

Basic authentication: Credentials are passed to the Web site in plain text.

Important: Because credentials are passed in plain text, consider using SSL for Web sites that use Basic pass-through authentication.

Digest authentication: Hashed credentials are passed to the Web site using Digest Authentication.

Integrated Windows authentication: Hashed credentials are passed to the Web site using Integrated Authentication. NTLM or Kerberos authentication is used, depending on your Web server configuration.

Caution: When using any of the three pass-through authentication methods, the target Web application is first presented with the credentials with which the user logged on to the Access Gateway. Accessing Web sites that require a second, differing set of credentials through Access Gateway can result in the caching of the second set of credentials.

To specify pass-through authentication for a Web site

1. Click Start > All Programs > Citrix > Management Consoles > Access Management Console
2. In the console tree, select the Web resource and under Common Tasks, click Edit Web resource.
3. On the URL Addresses page, select the Web site’s URL and click Edit.
4. In the Authentication types supported area, select the authentication method being used by the Web site.

Disabling passthrough authentication on Citrix PNagent

Occasionally as an administrator, you want to be able to log onto via our Citrix PNAgent with different credentials for testing. Depending on your farm setup, pass-through authentication is most likely enabled, and hence your client will be the same. To disable this on your workstation.

1. Open the registry and browse to: HKLM\System\CurrentControlSet\Control\NetworkProvider\HwOrder
2. Open ProviderOrder string, delete the entry PnSson
3. Now browse to HKLM\System\CurrentControlSet\Control\NetworkProvider\Order and delete the entry PnSson
4. Reboot

Read More

The license list is incomplete. An error occurred while getting the information. Error Code: 2c1/800a001a

Symptoms

The license list is incomplete. An error occurred while getting the information. Error Code: 2c1/800a001a.

Possible Causes

1. The server name was changed.
2. The IP address was changed.
3. The server in question could possibly see the data store and some of the ZDC’s, but not all of them.
4. The server in question must be able to talk to all ZDC’s in the farm.
5. Make sure all the ZDC’s and the data store server can resolve the DNS name of the server with the problem.
6. The license information in the datastore is corrupted.
7. A license has been recently been added and the Refresh of the Management Console has happened prior to the completion of the license addition. Wait a short time and Retry the license query.



Action/Resolution
1. Recreate the local host cache (LHC).
2. Use CTX107800 – DSCHECK Version 5.15 to fix any possible datastore corruption.
3. Run queryhrto see if there is corrupt information. If there is a corrupted entry, locate the corrupt Host ID and make a note of the number. Run queryhr –d <Host ID number> and press Enter.
4. Ping the server in question by IP address.
5. Ping the server in question by name. If the name does not resolve and the ping is unsuccessful, it is a DNS issue.
6. Ensure there are no relevant hotfixes that may address license issues. This is not necessarily a complete list. CTX104982 – Readme - Service Pack 4 for MetaFrame XP 1.0

The IMA Service failed to start because of license group corruption in the data store.

Note: This fix prevents corruption in the data store but it does not correct any corruption that may already exist. You need to check for corruptions present in the data store and correct them using the appropriate tools.

Read More

How to securely redirect to Web Interface in Citrix

As default Web Interface should be used with SSL encryption (HTTPS) enabled, since users are sending credentials overt the wire. This is even more important when using WI internally because researches showed that most attacks are coming from inside.
Difficult part is that users are not very familiar with typing httpS...

1. After the Server certificate was applied to IIS, SSL should be disabled
   IIS Manager | Default Web Site | Directory Security | Edit secure communications | Disable SSL
   
   
2. Next is to enable SSL ONLY for Web Interface and every other site/folder you like.
   IIS Manager | Default Web Site | Citrix | MetaFrame | Directory Security | Edit secure communications | Enable SSL
   
   
3. Redirect user to Web Interface via secure channel
   When Web Interface 3.0/4.x was set as default Web Site, then the file webinterface.htm is placed in the IIS root (default %RootDrive%\Inetpub\wwwroot). Now the following line needs to be changed:
   
   window.location="Citrix/MetaFrame/";
   
   to
   
   window.location="httpS://FQDN_WI_SERVER/Citrix/MetaFrame/";

This way user can connect to FQDN_WI_SERVER using port 80 (HTTP) but they will be redirected to WI using HTTPS. Direct connection to http://FQDN_WI_SERVER/Citrix/MetaFrame/ will fail, since SSL is required. If direct connect should also supported, then a bit more scripting is required.

Read More

Nondisruptive upgrade of VMFS-3 to VMFS-5

In vSphere 5 the VMFS filesystem has been updated to version 5 (currently 5.54). In vSphere 4.1 update 1 the VMFS version was 3.46.

In earlier versions of ESX, live upgrades of VMFS, or in-place upgrades, haven't been an option so to upgrade VMFS, basically a new LUNs had to be created and then VMs could be migrated to these new LUNs.

With vSphere 5, VMFS can be upgraded nondisruptively. This is done for each LUN by going to:

Datastore and Datastore Clusters -> Configuration -> Upgrade to VMFS-5.

It is a prerequisite that all connected hosts are running vSphere 5. The upgrade itself takes less than a minute (at least in a small test environment).

In VMFS 5, there is only one block size which is 1 MB. However, when upgrading from v3 to v5, the block size remains what it was before (see the last screendump). In the example below, the 8 MB block size is retained.

The new maximum LUN size is 64 TB - but a single .vmdk file can still not exceed 2 TB minus 512 bytes. The only way to have larger .vmdk's than 2 TB is to create an RDM and mount it as a physical device (as opposed to virtual).

Read More