Shadow Session in ControlUp

ControlUp has developed a Script Action that takes advantage of the new shadowing method while we develop it into the product.

A ticket comes into your help desk. The user is doing the best they can to describe the problem; for some reason, they are unable to capture a screenshot of what’s going on. And you’re frustrated because you can’t see what’s happening.

The struggle is real, as they say. And this scenario is one that comes up all too often.

As a tech, you try and piece together the goings-on from sometimes vague, inconsistent, or seemingly nonsensical descriptions. One of the most memorable calls I have ever dealt with was a user who told me their application was pink. This was odd because the application was just a normal flat-grey. This was pretty incomprehensible.

The solution? I shadowed the user’s session.

Sure enough, there was an application with a pink ribbon bar instead of grey. Changing the color the ribbon bar was not configurable so this was odd. But the shadow also showed me something else. The desktop was huge! It turned out, the user had multiple monitors and there wasn’t enough graphics memory allocated to their session, so Citrix degraded the colors so the user could use the app. Because the shade of grey used in the ribbon bar wasn’t a part of the reduced palette it was substituted for pink. This was one example in my career how seeing a problem with my own eyes helped me understand the seemingly unbelievable.

In the end, the issue was the graphics memory limit was being exceeded for the session and the Citrix policy, “Display mode degrade preference,” was triggered. Ever since, I’ve been a proponent of setting the display memory limit to the maximum you can.

However, the whole process and discovery was helped tremendously by shadowing. It took me only seconds to understand the situation once I could see it with my own eyes.

Fast forward to today.

The evolution of shadowing a user session has become bloated with different possibilities with different complexities of implementations and different experiences.

Citrix simplified shadowing by offering their own implementation in XenApp 6.0/6.5 which did not carry forward with CVAD.

The most classic experience is using Remote Assistance — a feature originally made available in Windows XP. The user experience in getting a remote assistance session connected is poor, to say the least. But it is the most compatible, going back to Windows XP!

Even we at ControlUp implemented these legacy solutions, which continue to exist in the product.

That’s right, the ControlUp Shadow Session option under “Remote Desktop Services” *currently* only works with these legacy methods. At ControlUp, we recommend you use our “Get Session Screenshot” feature which works on all devices and against all protocols. But this does prevent you from controlling the target session.

There is a new game in town though.

The newest and best experience was introduced with RDP 8.1—With Windows Server 2012R2/Windows 8.1. Since Windows Server 2008R2 and Windows 7 are now end-of-life you can just start using the new Remote Shadow feature!

But… if you are still using a legacy operating system like Windows Server 2008R2 or Windows 7, you can still use the Remote Shadow feature by installing RDP 8.1 on your legacy systems.

ControlUp has developed a Script Action that takes advantage of the new shadowing method while we develop it into the product.

This script action leverages the new Remote Shadow method — completely seamlessly for you.

If you have administrative rights to the target machine then the Script Action will connect to the machine, check if the firewall is enabled and whether the proper firewall policies are enabled, check the policies applied to the machine, and automatically attempt to shadow based on those properties.

For instance, if you set some secure machines to require IT to ask for user consent then ControlUp will interrogate the machine and automatically adjust mstsc.exe to match those policies.

If your account can interrogate the firewall policies then the Script Action will check them and if they are not enabled it will generate an alert:

If no Shadow policy is deployed the Script Action will attempt to set the Shadow Policy based on the parameters you chose when you first ran the action:

If the Script Action is unable to interrogate the target device’s policies then it will still attempt to connect to the machine but in the most restrictive manner possible → View Only and Ask For User Consent.

What do you need to get this feature to work?

You need only two things to get this to work:

1) Configure a group policy setting across all devices you want to shadow with the type of shadowing you want.

2) If you have the Windows Firewall turned on, enable the RDP Shadow feature, or the same port and inbound connection on your third party firewall.

If no policy is configured on your target devices the script action will attempt to set the policies on the target device with the properties you specified when you ran the script. If it’s successful in setting the policies it will connect you in. If it’s unsuccessful in setting the policies remotely it will attempt a connection with the least privileges allowed (User consent required and view-only). If you have already configured policies, but the properties you selected for the shadow are more permissive (eg, you selected Remote Control but the machine is configured for “View-Only”) AND your account has permission to interrogate the policies remotely, your shadow configuration will be set to match the machine’s policies.

This shadow method works against the following protocols:

• RDP
• ICA
• PCOIP
• BLAST

It works against full desktop and published application sessions on a multi-user machine and CONSOLE sessions — that is single user machines. It works on Windows for Virtual Desktops (WVD) Sessions, it works against VMware Horizon sessions, it works against Citrix sessions, it works against physical PC’s! It just works!

Lets see what it looks like in action: