Remote Desktop Services sessions from the server-side

When you use FastTrack scripts on the server-side, for example for Logon Scripts or application launchers, you can get the name and IP address of the remote client, the name of the executing published application (if not a full desktop session) and you can detect, if the script is actually running through an RDP session or not. This is extremely powerful information to have, because this means that you can differentiate your logon script and avoid unintended execution for remote users.

Under the "Remote Desktop Services Server" in the editor Engine Browser tree (see picture to the right), you will see that "RemoteSession", "ClientName", "ClientIP" and "ClientIPPart" are also present under "Citrix Server". This is because the intention is to provide transparency between RDP and ICA sessions with FastTrack scripts, because the desired logic is usually the same for both and with common functions and conditions, scripts will be shorter and simpler.

The ClientName function will return the name of the client executing the session regardless of RDP or ICA, whereas RdpClientName and IcaClientName will only work for one technology. The reason both are available is because "ClientName" makes sense in most cases and especially in common scripts like logon scripts, but for application launchers or similar, scripts are more readable when using an explicit function like RdpClientName.

The condition "RemoteSession" determines, if the executing script is running under an RDP or ICA session. If you want separate logic, there are two split conditions called "RdpSession" and "IcaSession" to determine, which is true, if any. In the simplest form, you can use the information to stop a logon script on ICA and RDP sessions:

Using the client name

Another example is that the we can use the client name to determine, if the computer running the session is a computer in the domain or not, as part of a logon script. We can do this by asking the Active Directory, if a computer account exists with the same name and then we can react to this. In the example below, we kindly remind the user that the Codes of Conduct for use of remote sessions applies and then we log the information to the server event log. We could have taken more severe steps, such as simply logging off the session or we could also just log the information server-side.
When an unknown client is detected, the warning is shown (see below) and an entry is logged in the server's event log.

Determining client location

You can also retrieve the IP address of the executing client. This information is especially useful for connecting printers and shares. If you look at the Logon Script examples, you will find examples, where location is determined by the IP address. When using the IPAddress or IPAddressPart functions, these return the IP address of the physical machine. When using remote session, we want to do the same, but we want to do it based on the IP address of the executing client. To solve this problem, we can simply use the ClientIP and ClientIPPart functions instead. These will first try to detect an ICA or RDP session and return the client IP address. If the session is not a remote session at all, the IP address of the physical machine is returned. The net result is that we can in general simply replace the functions and they will work as intended in all scenarios.

Remote Desktop Services client

You can from the client-side use FastTrack scripts to query information about the installed version of the RDP client. You can also start and control RDP desktop sessions, the same way that you can do with ICA sessions. Please have a look under "Remote Desktop Services Client" in the Engine Browser tree in the editor (see picture to the right).

Using installed RDP client information

As the RDP client is by default installed with Windows, it does not make sense to check for installation status of the client. But it would be very relevant to check, if Windows XP machines have version 6.0 or newer installed, to make sure there is client support for RemoteApps. To avoid problems, we could simply ask the user to contact the HelpDesk, if they have an older version through the logon script:
If the end user has a version older than version 6.x, a warning is shown that the user must contact the HelpDesk:

Starting sessions

You can start a desktop session either in a window or full-screen and you can query whether the session was successful or not. You can for example use this to build launch menus mixed between local applications and Remote Desktop and XenApp sessions. Have a look at the building a Thin PC page for an example of using a menu instead of starting Explorer.exe as the shell process.

The script below is a simple example, where first menu item starts the locally installed notepad. The second item starts a windowed desktop through an ICA session, the third item starts an RDP Remote Desktop and the fourth item starts notepad as a seamless Citrix XenApp server application. You can insert this example in the script editor by selecting "Remote Session Menu" in the "New Script" window.


Using the ShowRemoteDesktop command will result in a window like the one below (picture is scaled to 50%). When the user closes the window, the script continues, and the menu is therefore shown again. The condition "LastRdpSessionFailed" can be used to detect problems connecting or executing the session.