Mastering Remote Desktop: Securely Access Your Windows Server from Anywhere

Table of Contents

Summary¶

This article addresses the support provided by Microsoft for running a Remote Desktop Connection session within another Remote Desktop Connection session, a concept known as nested Remote Desktop connections. This capability, enabled by Remote Desktop Protocol 8.0, is designed for specific scenarios and configurations. It is important to understand the conditions under which nested Remote Desktop sessions are supported to ensure optimal performance and avoid unsupported configurations. This document outlines the necessary client and server operating systems, Remote Desktop Protocol versions, and supported features for successful nested Remote Desktop connections.

The ability to nest Remote Desktop sessions can be beneficial in various IT environments. For example, users might need to access a virtual desktop environment and, from within that virtual desktop, connect to another server or application using Remote Desktop. However, it’s crucial to recognize that not all configurations are supported, and specific criteria must be met to ensure a functional and supported nested Remote Desktop setup. This article will delve into these specific requirements, clarifying the supported operating systems, Remote Desktop versions, and feature limitations for nested sessions.

Supported Configurations for Nested Remote Desktop Sessions¶

Microsoft officially supports nested Remote Desktop sessions under a specific set of conditions. These conditions pertain to the operating systems of both the client and server machines involved in the nested connections, the Remote Desktop Protocol version in use, and the features required for the nested session. The following table summarizes the supported configurations, outlining the compatibility requirements for a successful nested Remote Desktop experience. Understanding these requirements is essential before deploying or utilizing nested Remote Desktop sessions in your environment.

Condition	Requirement
Client Computer Version	Windows 11, Windows 10, Windows Server 2012 R2
Remote Desktop Version (Initial Connection)	Windows 11, Windows 10, Windows Server 2012 R2
Nested Remote Desktop Version	Windows 11, Windows 10, Windows Server 2012 R2
Supported RDP Features (Nested Session)	Basic graphics (Display), Keyboard and mouse input
Supported Connection Type	Full Remote Desktop, RemoteApp

This table clearly illustrates the operating system compatibility for all stages of the nested connection. Specifically, the client machine initiating the first Remote Desktop connection, the server hosting the initial Remote Desktop session, and the server for the nested Remote Desktop session must all be running one of the supported operating systems: Windows 11, Windows 10, or Windows Server 2012 R2. This uniformity in operating system versions is crucial for ensuring compatibility and functionality of nested Remote Desktop sessions.

Furthermore, the table highlights the limitations on supported features within the nested Remote Desktop session. For nested sessions, only basic graphics (display) and keyboard and mouse input are officially supported. This means advanced graphical features or functionalities that require more than basic input might not function correctly or are not guaranteed to be supported in a nested Remote Desktop environment. This limitation is important to consider when planning to use nested sessions for graphically intensive applications or tasks that rely on advanced Remote Desktop features.

Finally, the supported connection types for nested sessions are Full Remote Desktop and RemoteApp. This implies that users can either establish a full desktop session within another remote desktop session or access specific applications via RemoteApp within a remote desktop session. These supported connection types offer flexibility in how nested Remote Desktop is utilized, catering to different user needs and scenarios.

Examples of Supported Scenarios¶

To further clarify the supported configurations, consider the following practical scenarios where nested Remote Desktop connections are officially supported by Microsoft. These examples illustrate how the conditions outlined in the table translate into real-world use cases. Understanding these scenarios can help you determine if your intended use of nested Remote Desktop aligns with Microsoft’s supported configurations.

Scenario 1: Accessing RemoteApp Programs from a Remote Desktop Session Host¶

Imagine a scenario where users connect to a central Windows Server 2016 Remote Desktop Session Host (RD Session Host) server to access their primary desktop environment. Within this desktop environment, they need to utilize specific applications hosted on a separate Windows Server 2016 RD Session Host server. In this case, users can initiate a nested Remote Desktop connection from their initial RD Session Host session to the second RD Session Host server to access and run RemoteApp programs.

This scenario is fully supported because all involved operating systems (Windows Server 2016, which is compatible with Windows Server 2012 R2 in terms of RDP support for this feature) meet the version requirements, and the nested connection is used for accessing RemoteApp programs, a supported connection type. Furthermore, the basic graphics and keyboard/mouse input requirements for the nested session are also satisfied in typical RemoteApp usage. This setup allows for a layered access approach, where users first access a general desktop environment and then selectively access specific applications hosted elsewhere, all within supported nested Remote Desktop configurations.

Scenario 2: Utilizing RemoteApp Programs from a Virtual Desktop Environment¶

Consider another common scenario where users work primarily within a virtual desktop environment hosted on Windows 11 or Windows 10 virtual machines. From within these virtual desktops, users need to access specific legacy applications that are hosted on a Windows Server 2012 RD Session Host server. In this situation, users can establish a nested Remote Desktop connection from their Windows 11 or Windows 10 virtual desktop to the Windows Server 2012 RD Session Host server to run these RemoteApp programs.

This scenario is also supported as it adheres to all the specified conditions. The client operating system (Windows 11 or Windows 10 virtual desktop) and the nested server operating system (Windows Server 2012 RD Session Host) are within the supported versions. The connection type, RemoteApp, is also supported for nested sessions. This example demonstrates the flexibility of nested Remote Desktop in enabling access to applications hosted on different server environments, even from within virtual desktop infrastructures, while maintaining compatibility and support.

Important Considerations and Limitations¶

While nested Remote Desktop connections offer flexibility and can be beneficial in specific scenarios, it’s crucial to be aware of the limitations and considerations associated with this functionality. Understanding these aspects will help in planning and deploying nested Remote Desktop solutions effectively and avoiding potential issues.

One of the primary limitations is the restriction on supported features within the nested session. As highlighted earlier, only basic graphics and keyboard/mouse input are officially supported. This implies that applications or tasks requiring advanced graphics rendering, redirection of peripherals beyond keyboard and mouse, or other advanced Remote Desktop features might not function correctly or are not supported in a nested session. Therefore, it’s essential to evaluate the application requirements before relying on nested Remote Desktop for graphically intensive or feature-rich applications.

Another important consideration is the potential performance impact of nested sessions. Establishing and maintaining multiple Remote Desktop sessions can consume system resources, both on the client and server sides. Nested sessions, by their nature, add an extra layer of resource utilization. Therefore, it’s crucial to ensure that the underlying infrastructure, including network bandwidth, server processing power, and client machine capabilities, is sufficient to handle the demands of nested Remote Desktop sessions without compromising performance or user experience. Performance testing and capacity planning are recommended when deploying nested Remote Desktop solutions, especially for a large number of users.

Furthermore, while the scenarios described are officially supported, it’s always advisable to thoroughly test and validate nested Remote Desktop configurations in your specific environment. Variations in network configurations, application dependencies, and user workflows can introduce unforeseen challenges. Testing in a representative environment will help identify and address potential issues before deploying nested Remote Desktop in a production setting. It is also important to stay updated with Microsoft’s documentation and support articles for any changes or updates related to nested Remote Desktop support and best practices.

Do you have any experiences with nested Remote Desktop connections, or any questions about supported configurations? Share your thoughts and experiences in the comments below!