Shadowing is a valuable tool released with Citrix Presentation Server, however, taking time to implement and delegate this ability to support personnel often falls to the bottom of the priority list.

Shadowing is a valuable tool released with Citrix Presentation Server, however, taking time to implement and delegate this ability to support personnel often falls to the bottom of the priority list. Enabling your first responders with the shadowing ability, and a basic understanding of Citrix, will help them to identify the source of a problem and thus decrease the amount of escalated calls. This article will go over the different methods of configuring shadowing (including order of precedence), shadowing utilities, shadow logging, and to conclude, a summary of best practices.

Terminology

Before we discuss the different methods of configuring shadowing, it’s worthwhile to make note of the different terminology Citrix and Windows use to describe the same functionality. In most cases the terminology breaks down like this. Citrix refers to shadowing as ‘Shadowing’ and Microsoft refers to shadowing as ‘Remote Control’. Further, when configuring shadowing you can decide whether or not to notify the user prior to beginning a shadow session. Citrix refers to this as ‘Notify ON or OFF’ and Microsoft refers to this as ‘Require User’s Permission’. Lastly you can grant your shadowers the ability to interact with the shadow session (in other words you can allow or prohibit the shadowers’ keyboard strokes and mouse clicks to interact with the user’s shadow session). Citrix refers to this as ‘Input On or Off’, Microsoft refers to this as either ‘View the User’s Session’ or ‘Interact with the Session’ depending on how remote control is configured. The following table summarizes the shadowing terminology.

Citrix

Windows

Shadowing

Remote Control

Notify ON or OFF

Require User’s Permission

Shadowing enabled: Input Off

View the User’s Session

Shadowing enabled: Input On

Interact with the Session

The Many Ways to Configure Shadowing

Moving on, there are seven places to configure Citrix Shadowing. With all seven methods you have the same three options to configure in regards to shadowing.

Shadowing Enabled or Disabled

Notify ON or OFF

Input ON or OFF

Again, depending on which method you use to configure shadowing, the terminology may vary. The functionality, however, is limited simply to the three options above. We will now take a look at the different locations shadowing can be configured.

1. Presentation Server Installation

During the Presentation Server installation you are presented with a screen to configure shadowing. By default shadowing is enabled. If you choose to prohibit shadowing at this point you will not be able to enable it later by any method but reinstalling Presentation Server. Further, at the installation point you have the option to force a shadow notification, as well as allow or disallow input into the shadowed session. If you enforce these restrictions at the installation point you will not be able to re-enable the feature by any other means but reinstalling Presentation Server. When deciding whether or not to prohibit shadow notification at the installation point, it’s necessary to take into consideration legal requirements of the country in which you are implementing shadowing. In some countries it’s illegal to shadow a user without notification, therefore, it makes sense to prohibit shadowing without notification at the installation point. In every other configuration method described below you can restrict shadowing options that have been enabled at the installation point, therefore if you’re not bound to any legal requirements it makes sense to allow shadowing without notification at the installation point, knowing you have the option to apply restrictions later. Also, if you want to enable logging for shadowing you must do this at the installation point as well. (Shadow logging will be discussed in detail later in this article.) The bottom line with configuring shadowing at the installation point is this: restrictions configured here are permanent and cannot be reversed by any method but reinstalling Presentation Server. If shadowing is installed without restriction, however, you can apply restrictions at will using the following methods.

2. Windows User Account Properties

In the Active Directory (AD) user account properties, Remote Control tab, you have the ability to ‘configure Terminal Services remote control settings’. Again, we can equate Windows ‘remote control’ with Citrix’s ‘shadowing’ in regards to terminology. On the Remote Control tab, you’re given the option to enable or disable remote control, enable or disable ‘require user’s permission’, and specify the level of control allowed over the user session. By level of control you can chose whether to view the user’s session or interact with the user’s session. (These options are akin to Citrix’s shadowing options of ‘input’ on or off and ‘notify’ on or off.) By default, in AD, the user account is configured to ‘enable remote control’, ‘require user’s permissions’, and ‘interact with the session’. Settings configured here will apply to all terminal services sessions whether RDP or ICA.

3. Windows Group Policy

Consistent with AD practice, if something can be configured at the user account level, it can likely be accomplished through Group Policy. This holds true for Terminal Services remote control options. As you know, Group Policy can be configured globally in Active Directory or locally on each server through local Group Policy. (If both are configured the ‘LSDOU’ hierarchy, loopback processing, etc. comes in play.) To configure remote control in a more centralized fashion create or edit an existing Group Policy Object (GPO) in AD. Navigate to Computer Configuration | Administrative Templates | Windows Components | Terminal Services. In the Terminal Services folder you’ll find the option, ‘Sets rules for remote control of Terminal Services user session’. (The same policy exists in the User Configuration tree. Whether you want to use the Computer Configuration or User Configuration depends on how you choose to apply your policy.) Again, here you have the ability to enable or disable remote control, specify notification, and specify what level of control is allowed for the session.

The Terminal Services Configuration tool (tscc.msc or TSCC)) and the Citrix Connection Configuration (CCC) tool are two other places where shadowing (or remote control) settings can be configured. Within these tools you can configure both ICA and RDP connections. In fact both of these tools actually edit the exact same value in the registry, respective to the protocol. Each tool configures the shadow value located in the following location.

If you make a change in the TSCC to the RDP connection, Remote Control tab, the exact same change will be immediately reflected in the RDP connection properties of the CCC. The same is true in the reverse; if you change the connection properties in the CCC, the same changes will be reflected in the TSCC. The only difference between the Windows GUI and the Citrix GUI, in regards to shadow settings, is the terminology. The actual registry keys that each tool edits are the same. Since these tools edit the registry of a server, settings configured in the TSCC and the CCC are configured on a per server basis.

6. Manually Editing the Windows Registry

Since Group Policy is actually a GUI to editing the registry, it is possible to manually edit the Windows registry to configure shadowing. When you configure, ‘Sets rules for remote control of Terminal Services user session’, a ‘Shadow’ value is added to HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. (It’s curious that this value is named ‘Shadow’ versus ‘Remote Control’ but I digress.) It is also possible to manually edit the connection level settings that the TSCC and CCC configure. As we looked at earlier, the TSCC and CCC tools are actually editing the same ‘Shadow’ value in the registry.

Therefore it is feasible to manually configure each of your Presentation Servers for shadowing, however, you would lose the centralized administration of using Group Policy and this approach, naturally, is more labor some.

7. Citrix Policy

Another option to configure shadowing is to use Citrix Policies. To configure shadowing, create or edit an existing Citrix policy. (Creating a new policy is recommended). Within the policy, expand User Workspace | Shadowing. You’ll notice the Configuration rule is very similar to the ‘Configure shadowing’ screen at the Presentation Server install. Here you can elect to ‘Prohibit being shadowed without notification’ or ‘Prohibit Remote input when being shadowed’. The Permissions rule allows you to specify to whom you wish to grant shadowing abilities—the ‘shadower(s)’. After configuring your Citrix policy make sure to apply it by selecting the appropriate filter(s). The policy will take effect immediately for new connections established to the farm. Active session will not get the change until a new session is established.

It’s important to note that Citrix Policy information is stored in the farm datastore and therefore are controlled by the Independent Management Architecture (IMA) service. This is unlike the other methods of configuring shadowing we’ve discussed which edit the registry on the PS4 server. This is important to distinguish particularly if there is a conflict between settings configured in the registry versus settings configured in the datastore. Which setting will take precedence? This brings us to the next topic, Order of Precedence.

Order of Precedence

What happens if more than one method of configuring shadowing is in place with conflicting settings? Which settings will take precedence? As we discussed in the Citrix Policy section, Citrix Policy is controlled by the IMA service and stored in the datastore. All other methods of configuring shadowing are controlled in the registry. Therefore if situations exists where settings conflict, determining which setting will take precedence depends on whether one setting can ‘see’ the other. Citrix policies in the datastore can’t ‘see’ what’s configured in the registry and vise versa. So what settings will take precedence? We can understand this better by breaking this down into two hierarchies.

Hierarchy A: Registry

Hierarchy A includes methods which modify the Windows registry.

Windows Local or Group Policy

Connection level settings (TSCC/CCC)

User account settings

If more than one of these is configured, the order of precedence from highest to lowest (following the numerical order) is Windows policy over connection level settings over user account settings. Windows Policy will ‘win’, or take precedence, over connection level settings and so on.

Hierarchy B: IMA Service

Hierarchy B includes Citrix policy or policies which are stored in the datastore and controlled by the IMA service. If more than one Citrix policy is in place, the policy that takes precedence is the policy with the highest priority.

Registry versus IMA Service: Who Wins?

If you have a situation where methods configuring the registry are competing with Citrix policy controlled by the IMA service, the most restrictive setting will win.

Let’s consider an example. Assume a Citrix Policy is applied to a Presentation Server with ‘Prohibit Being Shadowed Without Notification’ configured. (These settings are stored in the datastore and controlled by the IMA service.) The shadower is forced to notify the user and they are able to input into the session. Assume you configure the ICA connection in the CCC by un-checking ‘inherit user config’, and selecting ‘input off, notify off’. (This configuration is stored in the registry). In this scenario we have ‘Registry versus IMA Service’ therefore the most restrictive settings apply. The result is ‘notify on’ remains the same (ignoring the ‘CCC notify off’) but ‘input off’ now takes affect. The following diagram illustrates this example.

In summary, precedence applies within each hierarchy ‘type’, either the registry or the IMA service. If both ‘types’ are in place, the most restrictive will win. Order of precedence can be confusing. If it’s ever in question which settings will take precedence simply set up a test scenario or two, play around with different configurations, and the precedence will be made clear to you.

Which Shadowing Configuration Method is best?

Determining which method is best for you is dependent on your environment, any security requirements you may have, and whether or not you have administrative rights to AD. In my opinion, any centralized administration option will always be a more efficient than manually configuring individual servers. Best practices will be discussed in more detail later.

Now that we’ve looked at the various ways you can configure shadowing, let’s look at the tools that your helpdesk, other administrators, and even users can use to actually perform shadowing duties.

There are three ‘out of the box’ utilities that come with PS4, the Shadow Taskbar, the Presentation Server Console (PSC) (the new name for the Citrix Management Console (CMC)), and the Access Suite Console. Each can be published as an application to whomever you would like to grant the shadowing ability. Before we examine each utility it’s important to mention cshadow.exe

Cshadow.exe

Cshadow.exe is a command line executable that acts as the shadowing engine for all three Citrix shadow utilities. It’s located in C:\Program Files\Citrix\System32 and is invoked anytime a shadow session is launched from the shadow taskbar, the PSC, or the ASC. If you launch a shadow session using any of the utilities mentioned and launch Windows Task Manager, you’ll see cshadow.exe running as a process. If you like to script, it’s feasible to use cshadow.exe from the command line to launch a shadow session.

In addition to cshadow.exe, before discussing the utilities, there is another important point to make regarding how you shadow a session. You can only shadow an ICA session from an ICA session. If the utility you are using to shadow detects that an ICA session does not exist (for example you are trying to shadow from server console session), it will launch an ICA session for you and ask for your credentials. To avoid having to re-enter your credentials for the shadower's ICA session, launch the shadow session from an already established ICA session. This rule applies to RDP as well.

With this knowledge, let’s look at the shadow utilities.

1. Shadow Taskbar

The Shadow Taskbar is a simple tool that installs with Presentation Server and provides the ability to shadow active ICA sessions. (You cannot shadow RDP sessions using this tool.) When launched it appears as a simple toolbar with one ‘Shadow’ button at the top of your screen.

Advantages

The Shadow Taskbar allows the shadower to shadow without having to be an Administrator in the farm. This is what Citrix refers to as ‘User to User’ shadowing. (Not adding additional Administrators may be considered an advantage to some, however, PS4 offers such granularity when adding Administrators that you can really lock down and limit what abilities a user has within a farm. In addition Citrix Policy provides additional security.)

The Shadow Taskbar allows you to have multiple shadow sessions launched at once and it also allows for many users to shadow a single session at one time. This may be useful for training purposes.

In terms of logging, if logging is not installed with Presentation Server, you do have the option of using a less robust method of logging within the taskbar that is not available within the CMC. (Shadow logging will be discussed in detail later in this article.)

Disadvantages

Most importantly, the Shadow Taskbar only works for shadowing active sessions. You are not able to view disconnected sessions or perform any session maintenance (such as logging off sessions, sending messages etc.) within this tool.

On occasion, I’ve experienced problems with the taskbar not enumerating clients list.

The Shadow Taskbar is an older tool that hasn’t really been updated since MetaFrame XP.

The Presentation Server Console (PSC) or Citrix Management Console (CMC) is another method of shadowing. When shadowing from the PSC, another step that needs to take place for shadowing to work is to add your users who will be ‘shadowers’ as MetaFrame Administrators. This sounds scarier than it is, because with PS4 you can get very granular with what permissions you grant to whom. The Add MetaFrame Administrator wizard is a great tool that walks you through the process of adding individual users or security groups and assigning privileges. At minimum, your user or user group must have View Only selected as a privilege type in order to shadow sessions. If you would like your shadowers to have the ability to log off sessions etc. select the Custom privilege type and grant specific tasks accordingly. Once shadowers have been added at MetaFrame Administrators they can use the PSC to shadow sessions. You can shadow multiple sessions from the PSC if the PSC is launched natively. You can only shadow one session at a time if the shadow session is initiated from a published version of the PSC. Let’s consider some Advantages and Disadvantages of using the PSC to shadow.

Advantages

When the PSC is used for shadowing, all session types are visible to shadower including active, disconnected, and RDP session information. (RDP sessions cannot be shadowed from the PSC, however, session information is available.)

Much more functionality is available to the shadower in regards to interacting with the session. For example, the shadower has the ability to log off sessions, reset sessions, send messages to the user they’re shadowing, etc. The ability to administer or view session information in this way can be controlled in a granular fashion therefore you can choose to allow or prevent certain functions depending on how much control you wish to delegate.

If you would like your shadower to have the ability to view farm level information in addition to session information, you are able to provide this with the PSC.

Multiple users can shadow one session. As with the Shadow Taskbar, this may be useful in training circumstances.

Disadvantages

If you do not allow logging at the Presentation Server install, no logging options are made available through the PSC. See the section entitled ‘Shadow Logging’ for more information.

The Access Suite Console

Citrix’s new MMC-based management snap-in, the Access Suite Console (ASC), is another tool available to shadow users. With regards to shadowing, the Access Suite Console acts very similar to the PSC, and therefore the same advantages and disadvantages apply. However, there are a few additional advantages and disadvantages listed below. Also, as with the PSC, You can shadow multiple sessions from the ASC if the ASC is launched natively. You can only shadow one session at a time if the shadow session is initiated from a published version of the ASC.

Advantages (in addition to the PSC)

From the Access Suite Console you can shadow both ICA and RDP sessions! (This is cool.)

The ASC can connect to multiple farms at once.

Disadvantages (in addition to the PSC)

Using the Access Suite Console you must constantly deal with the slow initialization and discovery process.

Other Shadowing Utilities

Quick ShadowIn the days of MetaFrame XP a utility called ‘Quick Shadow’ was released. This is a simple tool available from the Citrix Developer Network (CDN) which allows user to user shadowing by username. To my knowledge this tool has not been updated for PS4. You can also download the code to Quick Shadow and create your own shadow utility.

Terminal Services ManagerWindows Terminal Services Manager (TSM) is another utility used to shadow sessions, or ‘remote control’ (in the context of Windows terminology) sessions. This tool will allow you to remote control RDP sessions, however, you can still view ICA session information within this tool. Remote controlling an RDP session from a Terminal Service console session will not work, you must launch the TSM within a RDP session that is not a console session for it to work.

Moving on from the various shadowing utilities, let’s look at what Citrix has to offer in terms of Shadow logging.

Shadow Logging

When installing PS4 you have the option to select ‘Log all shadow connections’ at the Configure Shadow screen. With this option checked, all shadowing events--whether shadowing via the PSC, ASC, or the Shadow Taskbar--will be recorded in the Event Viewer of the PS4 server where the user session (or the ‘shadowed’) exists. The events appear in the Application log as MetaFrame Event, in the category of ‘Shadow Session’. Events such as when and who requests a shadowing request and when a shadowing session is terminated are examples of information logged. Some specific examples of shadowing events captured in Event Viewer are as such.

Event ID: 1006 The requested session is not configured to allow remote control.(7051)

The problem with this logging is that these event log entries will be scattered throughout your Citrix environment. To consolidate shadowing events into a single location, a 3rd party tool is needed. (Microsoft offers a free tool called EventCombMT which accomplishes this.)

If the logging option is not checked at installation, you cannot log shadowing events in Event Viewer unless Presesentation Server is reinstalled. You do have the option, however, of a less robust method of logging shadow events from the Shadow Taskbar only. In the Shadow Taskbar, right click anywhere on the bar and select Logging Options. Here you can check to ‘Enable Logging’ and specify a Log File Path on your Presentation Server. Enabling logging here does not enable the same logging you are prompted with at installation (which logs events in Event Viewer). This creates a very simple log file that basically only tells you when and who launches the Shadow Taskbar and when and who starts a shadowing session and who is being shadowed. Below is a sample from the output log where helpdesk1 is the shadower and user1 is the shadowed.

If you configure shadowing to notify the user (or require user’s permission), an Application Popup event will be recorded in the system log but it will only record the request of the ‘shadower’ and nothing else. For example:

Application popup: Remote Control Request : <domain>\helpdesk1 is requesting to control your session remotely.Do you accept the request?

Summary: Best Practices for Configuring Shadowing

In summary, what are the best practices for configuring shadowing? This depends largely on your environment, your security requirements and whether or not you have admin rights to AD. You can combine any number of scenarios discussed in this article.

The best way to configuring shadowing is to do the following.

Create a Group Policy to define your connection-level settings and apply it to your Citrix Servers OU.

Create a Citrix policy, name it ‘Shadowing’ for example. In the Configuration area define connection level settings, if you would like more restrictive settings than set at the OU level. In the Permissions rule grant your help desk administrators, or those who will be shadowers, permission to shadow connections where the policy will be applied.

Apply your Citrix policy (or policies) to your Presentation servers

Add your shadowers as MetaFrame Administrators with limited access to the environment.

Publish the PSC to your shadowers or publish the ASC if you will be shadowing RDP sessions.

Train your shadowers.

Why do I feel this is the best approach? Defining the connection-level setting in Group Policy will centrally define connection level settings for both RDP and ICA sessions. If you won’t be shadowing RDP sessions then define your connection level settings in the Citrix Policy only to centralize your administration. I prefer applying Citrix Policy (and Group Policy for that matter) at the server level versus at the user level because I find it to be more simplistic and easier to troubleshoot.

I like the PSC over the Shadow Taskbar for many reasons. Namely, I like for my help desk to have the ability to view and administer sessions beyond just interacting with active sessions. I particularly want them to be able to log off a disconnected session for instances when a user has a corrupt, disconnected session that they keep getting reconnected to. This is an easy function to delegate out and not something I want to spend time on. Further the PSC offers much more information about the farm and the environment. It’s been my experience that the more the support personnel understands about the environment the better they are at helping end users solve issues that otherwise are escalated to me. We can control the PSC so granularly that I feel comfortable extending certain functionality within the tool. Finally, publishing the PSC versus installing it on each shadower’s workstation is an obvious choice to provide centralized administration.

I prefer the PSC over the ASC because I don’t like to deal with the slow initialization and discovery process associated with the ASC. I find this tool to be more cumbersome to administer sessions, however, if you need to shadow both RDP and ICA sessions the ASC is definitely the way to go. The functionality the ASC brings to shadow both protocols is cool technology. As the ASC matures (like being able to edit the datastore), I think this will be the preferred administration tool over the PSC. Today, however, I find the PSC to be more efficient in terms of shadowing ICA sessions. Once you have shadowing configured and ready to go, simply train your shadowers and you’re ready to delegate this useful functionality!

Join the conversation

8 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

Good job on breaking down the shadow feature! Its ironic that the company who's made "centralization" a centerpiece of their business model is still unable to come up with a single unified (yes, centralized)management tool.

Shadowing in the MPS world is unnecessarily complicated and confusing.

Good job on breaking down the shadow feature! Its ironic that the company who's made "centralization" a centerpiece of their business model is still unable to come up with a single unified (yes, centralized)management tool.

Shadowing in the MPS world is unnecessarily complicated and confusing.

I know that iShadow supplements shadowing and session management for Citrix MetaFrame and Microsoft Terminal services...

Can you configure a local group policy on the ICA Client side that prevents ICA Shadow Sessions? There should be some control on the ICA Client side to block these invitations from going through. Or prevent the Shadow Sessioner from being able to see auto-mapped network drives back into an internal network when shadowing a session.

Install was done by another admin and there are a bunch of servers that we cannot shadow. Would like to know how PS3 was installed relative to the shadowing option as we've checked everything else in terms of policies and permissions.

I must agree with some of the other posters that this is *way* too complicated. I tried to disable user confirmation for an account used to run a shopfront display and it just didn't work. I went through all the options above trying everything and the darn prompt still occurred.