About Terminal Server, Citrix, Delphi and other stuff
One of the lesser known features of VMware ThinApp is that you can supply a Virtual Computer name.
This is documented as follows in the package.ini reference guide:
The VirtualComputerName parameter determines whether to rename the computer name, to avoid naming conflicts between the capture process and the deployment process.
However, in a Multi User environment such as Citrix XenApp or Microsoft’s Remote Desktop Services (Terminal Server), all connected users report the same computername.
If the application relies on unique computernames to handle tasks such as file and record locking, then the application will fail.
We can however set an Application Compatibility Flag in the registry to return the username instead of the computername.
To demonstrate this behaviour I wrote a small Test Application called TestAppCompatFlags.exe.
For this mechanism to work correctly the file twain_32.dll must be present in the Windows directory.
On Windows 2008 this dll should be copied from winsxs (side by side) to the windows directory as described in CTX123981.
On Windows 2003 the dll is already in the correct directory, however applications that are not Terminal Server Aware cannot find this dll because the Windows directory is redirected to the user profile. Citrix recommends copying twain_32.dll to each user’s profile directory but this will take up unnecessary space.
So what alternatives do we have?
When starting the application, the WOW subsystem (NTVDM) crashed with the message: “NTVM encountered a hard error.”:
After spending some time troubleshooting I remembered a similar issue from a few years ago where a DOS application worked fine from the Console but refused to work from an RDP or ICA session.
I was digging around in termsrv.dll yesterday when I noticed that there are some (well 372 to be exact) SSL certificates inside the Terminal Server binary (termsrv.dll):
Two of them seem to actually contain the private keys as well, but I am not 100% sure it may be just a certificate in another format.
In part 1 I’ve described the theoretical parts needed for a custom autologon application implementation.
But there are some practical problems which I will describe here.
1) I use the LsaLogonUser function to log in the user. However, if I do not pass not null for the LocalGroups parameter, msgina.dll fails to process the logon.
Why? Because it looks for the SE_GROUP_LOGON_ID SID and treat it as logon SID. So we have to add the logon SID manually:
Windows XP introduced the ability to use Fast User Switching (FUS from here on), which is implemented using Terminal Services.
But in some cases (i.e. when FUS is not enabled, or when you connect to the console in Windows 2003 server), the Winlogon process in an RDP session needs to transfer credentials to Session 0.
Although not documented in MSDN, the process of transferring credentials is described by Keith Brown in the June 2005 issue of MSDN magazine: Customizing GINA, Part 2.
Internally, winlogon.exe uses a Named Pipe, \\.\Pipe\TerminalServer\AutoReconnect, to implement both of these functions.
The pipe format is described in this structure:
I had a very interesting issue today on a new Citrix XenApp 5 farm. We went into production yesterday and we noticed a number of issues:
I took a look at the profiles first and noticed that the size growth was due to a Xerox subfolder in %APPDATA%:
As you may know, Fast User Switching (FUS) is not available (disabled) on Windows XP computers joined to a domain, Microsoft confirms this in kb280758.
However, Microsoft doesn’t tell us there’s an undocumented registry value that allows us to have FUS when joined to a domain!
To enable FUS you need to set the DWORD registry value HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ForceFriendlyUI.
It can also be set by Group Policy at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
When the value is set to 1, and LogonType key is also set to 1, it allows you to use a Friendly UI on a computer joined in a domain:
.NET .NET FrameWork Active Directory Altiris Automation Manager bug Citrix datastore Dell Delphi Excel Exchange Exchange2003 Exchange2010 Hack HP iOS Java LinkedIn Linux Lync Office Office 2010 Outlook Passat Password PowerPoint PowerShell RES RNS510 SasLibEx Security Terminal Server ThinApp TSAdminEx Unattended VBS VCDS Vista Visual Basic VMWare Volkswagen Windows PE Wordpress XenApp