Historical guide to session shadowing in Windows Server 2012 R2, covering the GUI, command-line syntax, and the policy setting that controls consent behaviour.
This is another post that deserved a proper rewrite. The feature was useful, the original markdown was broken, and the article stopped before it explained the operational trade-offs clearly.
Beginning: why shadowing mattered again
Windows Server 2012 R2 reintroduced session shadowing for Remote Desktop Services, giving administrators a supported way to view or control a live user session for troubleshooting and assistance. That mattered because support teams had missed the feature in earlier RDS transitions and often fell back to less elegant workarounds.
Shadowing could be done either through the GUI or from the command line.
Middle: the two supported ways to shadow a session
GUI method
From Server Manager, open the session collection, locate the user session, right-click it, and choose Shadow. At that point you can decide whether to:
- View only
- View and control
- Prompt the user for consent
That was the easier path for help-desk style administration because it required no session ID lookup if you were already working in the RDS console.
Command-line method
The command syntax is the part most administrators remember, because it gave them a quick route into the session once they knew the ID:
mstsc.exe [/shadow:<SessionID> [/v:<ServerName>] [/control] [/noConsentPrompt]]
The switches meant:
/shadow:<SessionID>starts the shadow session/v:<ServerName>targets a specific RDS host if required/controlallows input, not just viewing/noConsentPromptattempts to connect without prompting the user
To find the correct session ID in PowerShell, the useful command was:
Get-RDUserSession |
Format-Table Username, UnifiedSessionId, SessionState, HostServer, ApplicationType `
-GroupBy SessionState -Wrap
Then connect with:
mstsc /shadow:<ID> /control
If your policy allows it and the scenario justifies it, you can also add:
/noConsentPrompt
Policy control
The consent experience was governed by the Group Policy setting:
Computer Configuration
> Administrative Templates
> Windows Components
> Remote Desktop Services
> Remote Desktop Session Host
> Connections
> Set rules for remote control of Remote Desktop Services user sessions
That setting determined whether administrators could view only, take control, and whether the end user had to approve the session first.
End: the operational caution
Shadowing is powerful, but it is also intrusive. Even in older RDS estates, the sensible default was to require consent unless there was a strong support or security reason not to. If you disable consent, document the decision and control who has the right to use it.
Closing thoughts
The feature is old, but the support pattern is still familiar: identify the session, connect with the right level of control, and use policy to decide where the approval boundary sits. The article now says that clearly and the broken code fence is gone.
