In this article I will go into shadowing on Citrix. Simple to setup and simple to use is the general feeling about it. Making a bad installation choice or not fully grasping all the locations where shadowing can be configured, could lead to surprising results. This article should help you in fully understanding the shadowing functionality, and the best way to use it. It is focused on novice Citrix administrators setting this up for the first time.
Introduction
The basics are simple. Enable shadowing and publish the cshadow.exe to the end user allowed to shadow. Then you notice the numerous locations that shadowing needs to be enabled, and even after enabling it on all those locations it still does not work. Let’s go a little deeper on all those options and see where things can go wrong.
The installation process
During the installation of Citrix, the setup routine asks for the following choice to be made:
This is one of the most important questions during the setup, as the choice is irreversible. If you select “prohibit shadowing” here, no chance it will ever work, regardless of the options you activate later.
So what’s the deal with that, as all other options in Citrix can easily be changed afterwards? This functionality was requested by Citrix banking customers quite a few years ago. They needed to be 200% sure that their system administrators would not be able to look onto the employee screen to grab confidential information. To my knowledge there is no way around it, other than a reinstall of Citrix altogether.
Who Wins
Citrix shadowing functionality can be set in local or domain policies, in “Citrix Connection Configuration” and in the user’s profile settings. Sounds confusing, but they all end up as the same choice in the end (and as a registry setting on the server). In all locations you set the enablement to on/off, the interaction of the shadower to on/off, and the input to on/off.
So what if you’re setting this in multiple places, because you have 3 available? Well, the system just looks at the most restrictive one in total. So if you want to keep things simple, make up your mind in which location you want to set this and stick to it.
What about the new Citrix Presentation Server 4 policies on shadowing? Same thing there, but just policy driven. It gives you some extra flexibility by using policy priorities, but the basics are the same. When having multiple shadowing policies configured, the same principle applies here: the most restrictive policy will win. Policies are stored in the IMA database.
So what if your environment has settings in the classic way, and in the new CPS4 policy method?
Things get a little confusing when they get mixed, just keep in mind that combined, the same rule applies: the most restrictive settings win. I can only advise you if you’re in CPS4, to stick with Citrix policies only, just to keep a grip on the configuration location.
Katie Koepke goes into detail of the precedence in this in her article here.
Logging
Are you considering logging shadowing usage in any way? Get ready for some extra work.
First thing you MUST do, is enable this logging in the same location during the installation as the shadowing enable option. Once that is set, you basically activate the logging of shadowing events to the event viewer. And you better get ready for some serious event log pollution as we now have the 1000 for the request, the 1001 for the stop, the 1002 for the failed, the 1003 for the access denied, and the 1006 for the not configured. To top it off, you’re on your own in getting some usable data out of that. You’d better get a nice event viewer events reader tool like the this one to turn it into readable data.
Forgot to tick that box during install, but still want to get some logging? Well, fortunately, the shadow taskbar has a logging option in the options setting, that does not require the setting I mentioned above during the install of Citrix. That logging mechanism is a lot cleaner then the event viewer, and creates a nice simple overview of the shadowed sessions.
Shadowing tools
The shadow taskbar (wshadow.exe) is one of the most used published applications to shadowers.
It’s scriptable sister is called cshadow.exe but functionality forces you to enter the session id you want to shadow, and that requires quite some scripting logic to be written to make it useful, as the session id from the user to be shadowed differs each time. The most powerful option in the cshadow scripting usage as I see it, is the “many to one” shadowing, as with this you can preconfigure the shadowing published app to use a batch file that includes the script to call cshadow.exe towards a session id. All the person has to do, that needs to be shadowed by multiple people, is to enter the session id being used at that moment into that batch file. (You can use the “query” command for that).
Unfortunately, the CMC and/or ASC is only useful for metaframe administrators (not users) when it comes to shadowing. It would make a nice add-on if the cmc could be deployed as a shadowing tool for end users, without them having to be Citrix administrators.
Whatever you decide to use, make sure to train the shadowers for this application, before they click on anything they can get their hands on. Training the shadowees is useful; try to teach them the popups they can get when being shadowed (instead of clicking “deny” as soon as they get the chance). Explain how the technology works, as they will be less afraid of it, and this could even persuade them to use it to train co-workers on a new application, saving the company money, and proving your ROI for the Citrix solution. (Again, shadowing is not an administrator tool only, but can be an application just like any of the others).
The performance trigger
One of the most amazing Citrix shadowing behavior out there, is when a user complains about having really bad performance during a session. The administrator shadows the session and the performance is excellent. The shadow session is dropped, and the end user’s performance is terrible again. Does this have to do with the administrator having more rights to the system, so that performance is much better? Is it worth doing a filemon and and regmon session to find out what that is? No, not really.
As soon as the administrator takes over the session, that session becomes leading, and the shadowee becomes a sort of a spectator to the screen. The administrator is usually near the server. I never was able to fully find out what that behavior was under the hood, but what I do know, is that shadowing is absolutely the wrong tool to monitor bad performance an end user is having. Just use it to troubleshoot application problems, or for training purposes, not for screen refresh problems. Since bad performance is usually a latency problem, the best tool for this is to monitor the session with the Citrix SMCC tool, available here. A view from the console:
Fighting latency noticeable on the screen refresh is another ballgame, talked about here.
What if Basic Shadow Functionality is not Enough?
Shadowing today has not really evolved regarding functionality the last few years. We have more and more ways to start shadowing, and to pull users from the list, but if you’re on a large environment and have a lot of end users who need to be able to shadow specific other end users and only be allowed to see those users at all, and not the full list, there is only 1 product out there that can do the trick. That product is called IShadow, and can be found on the IShadow website. Where RDP and Citrix shadowing use the normal user credentials for setting up shadowing, IShadow uses impersonation technology, giving you much more power on configuration and possibilities, where Microsoft and Citrix shadowing don’t.
Conclusion
As simple as the shadowing functionality may sound, I hope the above information has taught you a little on what to expect from shadowing, and the best way to use it. The locations to set shadowing are numerous, but hopefully now you know where to look and know the consequences of a tick.
