Seamless Application explained
One of the key features of Citrix besides using published applications; it’s also capable of using such an application in seamless mode. That means the application itself looks as if it’s been started from the local machine when it comes to the look and feel.
Running seamless applications was introduced with Metaframe 1.8 and has been very popular ever since. It is the least confusing way for an end user to experience an application over a citrix session, as he/she sees no difference between the citrix application and his/her local application. The default way of deploying a Citrix application has been set to seamless for a long time. As simple as seamless may sound, the technology behind it is not always as simple and can cause problems to get all of your applications to run flawlessly in seamless mode.
The technology behind the seamless application basically cloaks the part of the window that shows the application in a normal Windows shell.
For example, when opening the media player on your local XP machine in skin mode, it will look like this:
However, if you hover with your mouse over the top part of your media player, the actual window skin that is running the application, but was not visible, will appear:
The parts that were not supposed to be visible, like the min/max/close button section, the title bar, etc were made invisible using the same technology. Citrix uses this technology for all applications to give them a seamless look.
The main engine behind this technology is the wfshell.exe (that same engine that causes printer trouble when crashing and used up to Citrix MPS 3.0). All the settings used by wfshell.exe are stored in HKLM\SYSTEM\CurrentControlSet\Control\Citrix\wfshell
Later you will see that the fixes, in the form of registry keys, are stored in there also.
Breaking down the window
Like I said above, a window is made up of smaller parts, even if it looks to an end user as one window, like, for example, opening notepad.exe.
Sticking with notepad as an example, that would mean that the window showing notepad is called the “Parent Window”. If you type in some dummy data and close it, you will get a popup asking if you want to save the data. That popup is considered a “Child Window”. Since notepad is a very simple application, you can rest assured that more complex applications can have a lot of child windows. When killing the Parent window, the child windows are killed automatically. If they are not killed, they become orphans and need to be killed afterwards. (Will come back to that later)
Coming back to the notepad message box, that is a so called “Modal Window.” There are 2 types which exist;
- Applmodal (which means you cannot use another window from that app until answered)
- Systemmodal (which means you do not get access to the system, until answered)
The notepad example is an applmodal; just try it yourself.
Imagine what would happen if that popup got lost during a session. All you can do is kill the session and start from scratch. Losing the popup is called losing focus, as the popup needs to stay in front of the application window, and not somewhere behind it. Some applications can suffer from such behavior when running seamless. The applications most known to suffer from this are those programmed in Borland’s Delphi, and some vb applications.
Another example is a parent window creating an invisible child window. The seamless engine does not detect it, and when minimizing the application to the taskbar, it just disappears. It’s the same Delphi and vb that are known for creating such windows.
The registry key to fix this issue is:
Value Name: ClassName
Value Type: REG_SZ
Value Name: Type
Value Type: REG_DWORD
What can be done
Citrix has created registry keys to tackle the problem, of which the above one is a sample. They are divided into 2 types:
- Global registry flag. These affect all seamless applications on the server.
- Window specific registry flags. These affect the behavior of a window from an application. These type of keys are the most complex, and require you to know the Class Name of such a window. To find out the Class Name you need a tool like spy++ or winspector. (spy++ belongs to Microsoft Visual Studio and is not freeware, while winspector is freeware)
Citrix has created some kb articles regarding this subject, which are mandatory reading when it comes to this kind of troubleshooting. The first paper is the complete list of known seamless exception flags: http://support.citrix.com/article/CTX101644. The second paper is a short manual on how to use spy++ to find a window Class Name: http://support.citrix.com/article/CTX103137
When using winspector to find the Class Name, open the application on a desktop session, start winspector and in the menu go to “view, quick window info”.
When moving your mouse over the application, winspector’s Class cell will give you the Class Name of your application.)
You can find a copy of Winspector here.
When going over the global flags in the above kb article you will notice there is only one location for multiple flags, despite the fact that you may need more than one. At that point you will have to start counting up the values of the flags.
For example to use Flags 0x1 and 0x200: The value for SeamlessFlags would be 0x1 + 0x200 = 0x201
Or if you wanted to use Flags 0x1, 0x200 and 0x400 then: The value for SeamlessFlags would be 0x001+0x200+0x400 = 0x601
Finding out what your exact window issue is, and what the exact flag needed is (or a combination of flags, even mixing global and window flags) can be very time consuming and complex. If you have a Citrix support contract it could be worth calling Citrix support, as they handle such issues on a much more regular basis than you may.
Citrix has built up quite a few kb articles on specific applications and the key needed for that specific issue. Doing a thorough search on the Citrix knowledgebase and its forum is advised, to see if the exact problem occurred somewhere else, and a clear solution is already present.
When a seamless application is closed from the client side, the user no longer sees an application. It could happen however that not every process belonging to that seamless application is closed gracefully. (Due to an additional process started from the main application, or a glitch in the wfshell engine). This can result in a process not being closed and leaving the session open in the background, causing all kinds of trouble because the process consumes unneeded resources. You can find these ghost processes by opening up the Citrix Management Console, and going to the non fully closed session properties, and terminating the processes from that session one by one, until you get a graceful logoff, and thus have found the bad application. (Let’s call the bad application badapp.exe)
To tackle this, Citrix has created a registry key, which I think is one of the most used by now, but I will mention it anyway:
Value Name: LogoffCheckSysModules
Value Type: REG_SZ
If you happen to run into multiple bad processes, you can add them to the same key using the comma and no spaces: app1.exe,app2.exe,app3.exe, etc
A detailed kb article on this can be found here.
In this article I have talked about the seamless engine and what can go wrong. Some issues can be easily fixed with a simple key, and some will require a time consuming trial and error process to get the correct key or combination. Hopefully this will help you to find the answers to any seamless issues you may have, instead of just publishing it in a fixed window to work around it.