Citrix 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 XenApp application (if not a full XenApp or XenDesktop desktop session)
and you can detect, if the script is actually running through a Citrix
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.
If you look under "Citrix Server" in the Engine Browser tree (see picture to the right) in the editor, you will see that
"RemoteSession", "ClientName", "ClientIP" and "ClientIPPart" are also present under "Remote Desktop Services Server". This is because the
intention is to provide transparency between ICA
sessions with FastTrack scripts,
because the logic wanted is in most cases the same for both and common functions and conditions will therefore result in much shorter scripts.
The ClientName function will return the name of the client executing the
session regardless of ICA or RDP, whereas IcaClientName and RdpClientName 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 IcaClientName.
The condition "RemoteSession" determines, if the executing script is running under an ICA or RDP session. If you want separate logic,
there are two split conditions called "IcaSession" and "RdpSession" 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:
If RemoteSession Then Exit
Some of these features, including the RemoteSession check, are also used by the Logon Script Wizard that can check for Citrix Receiver
installation status and launch conditions. The Logon Script Builder is essentially just a script generator.
Using the client name in a custom script
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.
If Not ComputerExists [ClientName] Then
LogEvent Remote Logon,External logon by [UserName] from client
named [ClientName] from [ClientIP].
ShowMessage You are connecting
to the network from an external computer. Remember that codes
of conduct applies!
When an unknown client is detected, the warning is shown (see below) and an entry
is logged in the server's event log.
Note that the client name may be mapped to a generated client name, when running a session
through a web interface. This is a configurable behavior; please refer to CTX111851
for more information.
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.
You can from the client-side use FastTrack scripts to query information about the installed version of
Citrix Receiver. You can also start and control Citrix Receiver desktop and application sessions, the same way that you can do with
Remote Desktop sessions. Please have a look under "Citrix Client" in the Engine Browser
tree in the editor (see picture to the right).
Using installed Citrix Receiver information
In the simplest form, you can use the information to pause a logon script and
warn the user that he or she will not be able to execute ICA sessions at all:
If Not IcaClientInstalled Then
ShowErrorMessage You do not have Citrix Receiver installed. Contact HelpDesk.
You can also use the installed Citrix Receiver version information to warn about
obsolete ICA client support after server upgrades.
An example of using the client version information as part of a logon script
to check and warn the user about older versions could look like this:
If Not IcaClientInstalled
ShowErrorMessage You do not have
Citrix Receiver installed. Contact HelpDesk.
If [IcaClientVersionMajor]<13 Then
ShowErrorMessage You have an
old version of Receiver installed. Contact HelpDesk.
If the end user has a version older than version 13.x, a warning is shown that
the user must contact the HelpDesk like the one below.
Citrix Receiver was formerly known as Citrix ICA Client and the versioning is
kept across name changes. Citrix Receiver 3.2 is therefore the ICA client version 13.2,
Citrix Receiver 2.0 is ICA client version 12.0, etc.
Citrix sessions from the client-side
You can start ICA desktop and application sessions and you can query status information,
when the session has ended. 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 are two commands to start a published application (which can also be a published desktop)
and it is important to understand the difference. Let's look at how a session is normally established:
The user logs on to the web interface, which serves a list of applications available to the user. The web interface
asks the XML Broker for the application list and it also asks the XML Broker to select the server that
has the least load to host the session. The RunIcaApp command does the same thing, but without the web interface.
So basically you can script your way around the web interface and you can specify credentials when using the command.
The RunIcaAppDirect command will bypass the XML Broker and start a session on a specific server directly and
is therefore typically only useful for administrators. In small environments with only one server, the
XML Broker and XenApp server are one and the same, but it it still best practice to use the RunIcaApp command
in case there will be more servers at a later date.
Observe that the ShowIcaDesktop and ShowFullIcaDesktop commands are not
for published desktops, but for direct access to a
specific server. To access a published desktop from any server, the RunIcaApp must be used and pointed to a published desktop. In
case of published desktops, the DisableSeamlessIcaMode should be called first to avoid a seamless session.
There are collections available to get information from the XML Broker. The IcaApplications collection
will return a list of available applications, which is the same list the web interface would serve.
So we could build our own menu to ask the user to select an application and start a session based on the choice.
The below in an example of these, where the XML Broker has the IP address 192.168.1.8.
You can insert this example in the script editor by selecting "XenApp Launcher" in the "New Script" window.
Set App = [Menu Select
If Not VarIsEmpty App Then RunIcaApp
The script below is a an example, which mixes local applications, XenApp sessions and
Remote Desktop sessions. The 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. Note that in this example,
the XML Broker port is 8080. This is just to demonstrate the syntax, as the default
port 80 is often set up to be a different port, because of another web applications
using port 80 on the XML Broker server.
If Not IcaClientInstalled Then
ShowErrorMessage You do not have Citrix Receiver installed. Please contact the HelpDesk.
Set Selection=[Menu Select item,Document|Notepad,Screen|Acme Server 1,Screen|Acme
Server 2,Process|Acme App 1,Stop|Exit]
Switch [Var Selection]
Case Acme Server 1
Case Acme Server 2
Case Acme App 1
When an ICA session has finished, you can use the "LastIcaSessionFailed" condition to determine success. If the condition is true, the
function "LastIcaError" contains the error message.