I am frequently asked to demonstrate a variety of different
scenarios when I am out talking to customers.

There is a limit to what I can do with one laptop, so I created a
way to toggle between different environments quickly and easily.

This means I can demonstrate Workspace Manager to it’s full
potential without the need to carry a van full of equipment.

Stage One – Creating Managed Applications to launch a Remote Desktop

In my test environment, I am running both Citrix and terminal
services, so we need to create two Managed Applications from the RES Workspace
Manager console:

Let’s start with the Citrix Desktop

Point the command line to wfcrun32.exe, and the parameter should
point to the .ICA file (I use the Workspace Manager datastore to distribute the
ICA file)

When you have saved this, make a note of the Managed Application
ID:

Under settings, the Managed Application is enabled, but it is set
as hidden, and does not appear in help or as a new application.

This is because I do not want a shortcut to appear in the User’s
session, and I do not want my user to interact with it in any way:

The second option in my environment is a Terminal Server desktop
connecting via RDP.

The command line is pointed to mstsc.exe

Once again, I am leveraging Workspace Manager’s ability to
distribute my .RDP file.

Make a note of the Managed Application ID:

Again, the Managed Application is enabled but is hidden from the
user’s view:

Stage Two – Launching a Session or a Local Desktop

Not many people use this function within Workspace Manager, but
it’s truly a diamond piece of functionality – one of my favourite things in RES
Workspace Manager!

Basically it allows us to launch an application instead of a
desktop when a user logs on.

The offline option is left unchanged, as in my scenario, the user
will always launch a full desktop when they are not Online (a laptop user with
no connectivity for example):

Rather than calling a Workspace Manager application ID, I am
instead referencing an Environment Variable called %Online%

I have elected to launch this prior to all other actions – this is
because mappings, registry changes and setting policies etc… can take place in
the background.

It means that Users are not inconvenienced with having to wait at
logon time… and User perception is key when it comes to acceptance
J

Stage Three – Defining Locations and Devices

The next step is to create some Zones – this will allow us to
automatically detect the availability of our remote desktop infrastructure.

The desired state in my environment is reliant upon three different
zones:

The first zone is called remote host ICA & RDP Disabled:

It is based on one of the new rules Remote host/URL.

Using the & button, I am checking to ensure that both the ICA
listener (port 1494) and the RDP listener (port 3389) are not
reachable.

The second zone is called remote host ICA Enabled:

Based on the Remote host/URL rule I am ensuring that the ICA
listener (port 1494) is reachable and using the & button I am also
confirming that the RDP listener (port 3389) is not reachable:

Finally the third rule is called remote host RDP Enabled:

Based on the Remote host/URL rule I am ensuring that the RDP
listener (port 3389) is reachable and using the & button I am also
confirming that the ICA listener (port 1494) is not reachable:

Stage Four – Defining Workspace Containers

We also need to define some Workspace Containers, because we will
be applying different configuration based upon the device type.

This could be achieved by creating more Zones under Locations and
Devices, but Workspace Containers will be used elsewhere, so the chances are
that these have been defined already:

The first Workspace Container is named Citrix/Terminal Server/VDI:

The Citrix Server and Terminal Server (named SERVER in this
example) is a member:

The second Workspace Container is named XP Workstations:

The Workstation (named CLIENT in this example) is a member:

Stage Five – Creating Environment Variables

The next step is to create some environment variables to define the
Online state that we reference in Stage Two.

I have setup four variables all with the same name Online

Three variables apply to the workstation and dictate whether to
launch a local or remote desktop.

The fourth variable is kind of a loopback variable which applies to
the Citrix and Terminal Server – it stops things from going into a never ending
loop, or throwing an error unnecessarily:

So first of all, we’ll create a variable to launch a local desktop
on the Workstation.

This is for when the Citrix or Terminal Server is not reachable

The Value is blank, which means RES Workspace Manager runs as
normal

Required connection state is Online only:

Access Control makes it available to all users, and Locations and
Devices is referencing the remote host ICA & RDP Disabled zone that we
created in Stage Three:

This is applied to the XP Workstations Workspace Container:

The second variable calls Managed Application ID 121 as defined in
Stage One.

This is to launch a Citrix desktop for when the Citrix server is
reachable.

Required connection state is Online only:

Access Control makes it available to all users, and Locations and
Devices is referencing the remote host ICA Enabled zone that we created
in Stage Three:

This is applied to the XP Workstations Workspace Container:

The third variable calls Managed Application ID 122 as defined in
Stage One.

This is to launch a RDP desktop for when the terminal server is
reachable.

Required connection state is Online only:

Access Control makes it available to all users, and Locations and
Devices is referencing the remote host RDP Enabled zone that we created
in Stage Three:

This is applied to the XP Workstations Workspace Container:

The fourth variable is kind of a loopback variable which applies to
the Citrix and Terminal Server – it stops things from going into a never ending
loop, or throwing an error unnecessarily:

The Value is blank, which means RES Workspace Manager runs as
normal:

Access Control makes it available to all users, and Locations and
Devices is blank:

This is applied to the Citrix/Terminal Server/VDI Workspace
Container:

Stage Six – Toggling Citrix and Terminal Services on and off

This is not a stage you would need to implement in a live scenario,
because once it is setup, that’s the way it will stay, and the state of the
remote desktop and whether it is reachable or not would dictate whether the User
is connected to a remote or local session.

However, for demonstration purposes, it is nice to be able to
easily toggle between different scenarios.

I have toyed with several ways of achieving this.

Of course you can use RES Automation Manager and better still
Service Orchestration to achieve this, but typically in a demonstration scenario
you want immediate results, rather than having to waiting for the 30 seconds it
takes for a runbook to be executed.

There is no really slick way to do this, but for demonstration
purposes, I came up with the idea of creating three icons in the Quick Launch
area.

They are local desktop, Citrix desktop and Terminal Server desktop:

When they are clicked, each one runs a different .reg file (they
are set to run minimised to keep things tidy)

The local desktop icon calls a .reg file called OFF which sets
EnableWinstation for both ICA and RDP to zero (disabled)

The Citrix desktop icon calls a .reg file called ICA which sets
EnableWinstation for ICA to one (enabled) and RDP to zero (disabled)

The terminal server desktop icon calls a .reg file called RDP which
sets EnableWinstation for RDP to one (enabled) and ICA to zero (disabled)

It is important to note that when you boot your Citrix/Terminal
server, the values should be set to one, in order to prevent Citrix and terminal
server license errors and many other errors.

I achieve this with a fourth .reg file called ON which sets
EnableWinstation for both ICA and RDP to one (enabled)

This .reg file is called on my server at boot time through the

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

I have named the string aaListeners to make sure is appears at the
top of the list:

Once again, the .reg file is called with the /s switch which will
merge the file in to the registry, suppressing the standard “Are you sure?” and
“File merged” dialogue boxes:

This is a really neat and quite simple way to demonstrate some of
the advanced functionality of Workspace Manager.

Good Luck!