Understanding the Citrix MetaFrame Logon and Logoff Process
Written by Thomas Koetzing at Wednesday, 02 March 2005
The Windows logon and logoff process is a complex part of a Terminal Server environment, and these processes are complicated even more when Citrix MetaFrame Presentation Server is installed. However, knowing how these processes really work can cut down your troubleshooting time.
This article canít cover all aspects and every detail of the logon and logoff processes. However, it will take a look at these processes from an administratorís standpoint (as opposed to taking a developerís perspective).
The first part of this article covers the session initialization. It covers the steps that take place from the time a client tries to connect until the application shows up on the userís desktop. (Note that weíre only talking about the actual connection from the client to the server. We are not talking about application enumeration or load balancing since those activities take place before a client connects to a server.)
The second part of this article will cover the disconnection and logoff processes.
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 (as described in Citrix Knowledge Base article CTX102977.)
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 (See CTX543560). 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.
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:
It starts the Citrix seamless windows engine shell called wfshell.exe.
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.
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 through.
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
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).
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.
This article summarized the important steps and processes you see with Windows 2000/2003 and MetaFrame XP / 3.0. There are additional processes like Ctxhide.exe, but they are not big troublemakers. Unfortunately MPS 4.0 is going to majorly change the Citrix portion of this process, but thatís a story for another day.
Written by Guest on 2006-09-14 18:01:01th
Stops at Running logon scripts Written by Guest on 2008-06-04 11:41:03Executing: Run Group policy logon scripts stops for 10-15 seconds, nothing in the usernev log. Doing the same logon whit RDP is fast, doesn't stop at all. So what is the difference in the logon process in this phase in Citrix logon. Using PS 4.0, client 10.200. Same both for user, admin and direct to server or published application.