About Terminal Server, Citrix, Delphi and other stuff
I needed to connect remotely via Remote Desktop to a Windows Server 2012 machine.
I received an rdp file that was configured to use an RD Gateway server:
However when trying to connect from my Windows 7 laptop (x64) machine, I got the following error message:
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%:
.NET .NET FrameWork Active Directory Altiris Automation Manager bug Citrix Dell Delphi Excel Exchange Exchange2003 Exchange2010 Hack HP iOS Java LinkedIn Linux Lync MSI 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