Hubbry Logo
Remote Desktop ServicesRemote Desktop ServicesMain
Open search
Remote Desktop Services
Community hub
Remote Desktop Services
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Remote Desktop Services
Remote Desktop Services
Remote Desktop Services
View on Wikipedia
from Wikipedia
Remote Desktop Services
Other namesTerminal Services
DeveloperMicrosoft
Operating systemMicrosoft Windows
Service nameTermService
TypeRemote desktop software
Websitedocs.microsoft.com/en-us/windows/win32/termserv/terminal-services-portal

Remote Desktop Services (RDS), known as Terminal Services in Windows Server 2008 and earlier,[1] is one of the components of Microsoft Windows that allow a user to initiate and control an interactive session[2] on a remote computer or virtual machine over a network connection.

RDS is Microsoft's implementation of thin client architecture, where Windows software, and the entire desktop of the computer running RDS, are made accessible to any remote client machine that supports Remote Desktop Protocol (RDP). User interfaces are displayed from the server onto the client system and input from the client system is transmitted to the server – where software execution takes place.[3] This is in contrast to application streaming systems, like Microsoft App-V, in which computer programs are streamed to the client on-demand and executed on the client machine.

RDS was first released in 1998 as Terminal Server in Windows NT 4.0 Terminal Server Edition, a stand-alone edition of Windows NT 4.0 Server that allowed users to log in remotely. Starting with Windows 2000, it was integrated under the name of Terminal Services as an optional component in the server editions of the Windows NT family of operating systems,[4] receiving updates and improvements with each version of Windows.[5] Terminal Services were then renamed to Remote Desktop Services with Windows Server 2008 R2[6] in 2009. RemoteFX was added to RDS as part of Windows Server 2008 R2 Service Pack 1.

Overview

[edit]

Windows includes four client components that use RDS:

  1. Quick Assist (Windows 10 and later) and Windows Remote Assistance (Windows XP through Windows 8.1)
  2. Remote Desktop Connection (RDC)
  3. Fast user switching
  4. Windows Subsystem for Linux (via MSRDC)

The first two are individual utilities that allow a user to operate an interactive session on a remote computer over the network. In case of Remote Assistance, the remote user needs to receive an invitation and the control is cooperative. In case of RDC, however, the remote user opens a new session on the remote computer and has every power granted by its user account's rights and restrictions.[3][7][8] Fast User Switching allows users to switch between user accounts on the local computer without quitting software and logging out. Fast User Switching is part of Winlogon and uses RDS to accomplish its switching feature.[9][10] Third-party developers have also created client software for RDS. For example, rdesktop supports Unix platforms.

Although RDS is shipped with most editions of all versions of Windows NT since Windows 2000,[4] its functionality differs in each version. Windows XP Home Edition does not accept any RDC connections at all, reserving RDS for Fast User Switching and Remote Assistance only. Other client versions of Windows only allow a maximum of one remote user to connect to the system at the cost of the user who has logged onto the console being disconnected. Windows Server allows two users to connect at the same time. This licensing scheme, called "Remote Desktop for Administration", facilitates administration of unattended or headless computers. Only by acquiring additional licenses (in addition to that of Windows) can a computer running Windows Server service multiple remote users at one time and achieve virtual desktop infrastructure.[6][9]

For an organization, RDS allows the IT department to install applications on a central server instead of multiple computers.[11] Remote users can log on and use those applications over the network. Such centralization can make maintenance and troubleshooting easier. RDS and Windows authentication systems prevent unauthorized users from accessing apps or data.

Microsoft has a long-standing agreement with Citrix to facilitate sharing of technologies and patent licensing between Microsoft Terminal Services and Citrix XenApp (formerly Citrix MetaFrame and Citrix Presentation Server). In this arrangement, Citrix has access to key source code for the Windows platform, enabling its developers to improve the security and performance of the Terminal Services platform. In late December 2004 the two companies announced a five-year renewal of this arrangement to cover Windows Vista.[12]

Server components

[edit]

The key server component of RDS is Terminal Server (termdd.sys), which listens on TCP port 3389. When a Remote Desktop Protocol (RDP) client connects to this port, it is tagged with a unique SessionID and associated with a freshly spawned console session (Session 0, keyboard, mouse and character mode UI only). The login subsystem (winlogon.exe) and the GDI graphics subsystem is then initiated, which handles the job of authenticating the user and presenting the GUI. These executables are loaded in a new session, rather than the console session. When creating the new session, the graphics and keyboard/mouse device drivers are replaced with RDP-specific drivers: RdpDD.sys and RdpWD.sys. The RdpDD.sys is the device driver and it captures the UI rendering calls into a format that is transmittable over RDP. RdpWD.sys acts as keyboard and mouse driver; it receives keyboard and mouse input over the TCP connection and presents them as keyboard or mouse inputs. It also allows creation of virtual channels, which allow other devices, such as disc, audio, printers, and COM ports to be redirected, i.e., the channels act as replacement for these devices. The channels connect to the client over the TCP connection; as the channels are accessed for data, the client is informed of the request, which is then transferred over the TCP connection to the application. This entire procedure is done by the terminal server and the client, with the RDP mediating the correct transfer, and is entirely transparent to the applications.[13] RDP communications are encrypted using 128-bit RC4 encryption. From Windows Server 2003 onwards, it can use a FIPS 140 compliant encryption scheme, or encrypt communications using the Transport Layer Security standard.[3][14]

Once a client initiates a connection and is informed of a successful invocation of the terminal services stack at the server, it loads up the device as well as the keyboard/mouse drivers. The UI data received over RDP is decoded and rendered as UI, whereas the keyboard and mouse inputs to the Window hosting the UI is intercepted by the drivers, and transmitted over RDP to the server. It also creates the other virtual channels and sets up the redirection. RDP communication can be encrypted; using either low, medium or high encryption. With low encryption, user input (outgoing data) is encrypted using a weak (40-bit RC4) cipher. With medium encryption, UI packets (incoming data) are encrypted using this weak cipher as well. The setting "High encryption (Non-export)" uses 128-bit RC4 encryption and "High encryption (Export)" uses 40-bit RC4 encryption.[15] When setting the Security Layer to 'SSL (TLS 1.0)', Transport Layer Security up to version 1.2 is available.[16]

Terminal Server

[edit]

Terminal Server is the server component of Terminal services. It handles the job of authenticating clients, as well as making the applications available remotely. It is also entrusted with the job of restricting the clients according to the level of access they have. The Terminal Server respects the configured software restriction policies, so as to restrict the availability of certain software to only a certain group of users. The remote session information is stored in specialized directories, called Session Directory which is stored at the server. Session directories are used to store state information about a session, and can be used to resume interrupted sessions. The terminal server also has to manage these directories. Terminal Servers can be used in a cluster as well.[3]

In Windows Server 2008, it has been significantly overhauled. While logging in, if the user logged on to the local system using a Windows Server Domain account, the credentials from the same sign-on can be used to authenticate the remote session. However, this requires Windows Server 2008 to be the terminal server OS, while the client OS is limited to Windows Server 2008, Windows Vista and Windows 7. In addition, the terminal server may be configured to allow connection to individual programs, rather than the entire desktop, by means of a feature named RemoteApp. Terminal Services Web Access (TS Web Access) makes a RemoteApp session invocable from the web browser. It includes the TS Web Access Web Part control which maintains the list of RemoteApps deployed on the server and keeps the list up to date. Terminal Server can also integrate with Windows System Resource Manager to throttle resource usage of remote applications.[5]

Terminal Server is managed by the Terminal Server Manager Microsoft Management Console snap-in. It can be used to configure the sign in requirements, as well as to enforce a single instance of remote session. It can also be configured by using Group Policy or Windows Management Instrumentation. It is, however, not available in client versions of Windows OS, where the server is pre-configured to allow only one session and enforce the rights of the user account on the remote session, without any customization.[3]

Remote Desktop Gateway

[edit]

The Remote Desktop Gateway service component, also known as RD Gateway, can tunnel the RDP session using a HTTPS channel.[17] This increases the security of RDS by encapsulating the session with Transport Layer Security (TLS).[18] This also allows the option to use Internet Explorer as the RDP client. The official MS RDP client for macOS supports RD Gateway as of version 8. This is also available for iOS and Android.

This feature was introduced in the Windows Server 2008 and Windows Home Server products.

In October 2021, Thincast, the main contributor of the FreeRDP project, published the first Remote Desktop Gateway solution running natively on Linux.[19]

Roles

[edit]
Remote Desktop Gateway
Enables authorized users to connect to virtual desktops, Remote-App programs, and session-based desktops over a private network or the Internet.
Remote Desktop Connection Broker Role
Allows users to reconnect to their existing virtual desktop, RemoteApp programs, and session-based desktops. It enables even load distribution across RD Session Host servers in a session collection or across pooled virtual desktops in a pooled virtual desktop collection, and provides access to virtual desktops in a virtual desktop collection.
Remote Desktop Session Host
Enables a server to host RemoteApp programs as session-based desktops. Users can connect to RD Session Host servers in a session collection to run programs, save files, and use resources on those servers. Users can access Remote Desktop Session Host server by using the Remote Desktop Connection client or by using RemoteApp programs.
Remote Desktop Virtualization Host
Enables users to connect to virtual desktops by using RemoteApp and Desktop Connection.
Remote Desktop Web Access
Enables users to access RemoteApp and Desktop Connection through the Start Menu or through a web browser. RemoteApp and Desktop Connection provides users with a customized view of RemoteApp programs, session-based desktops, and virtual desktops.
Remote Desktop Licensing
Enables a server to manage RDS client access licenses (RDS CALs) that are required for each device or user to connect to a Remote Desktop Session Host server. RDS CALs are managed using the Remote Desktop Licensing Manager application.[20]

RemoteApp

[edit]

RemoteApp (or TS RemoteApp) is a special mode of RDS, available in Windows Server 2008 R2 and later, where remote session configuration is integrated into the client operating system. The RDP 6.1 client ships with Windows XP SP3, KB952155 for Windows XP SP2 users,[21] Windows Vista SP1 and Windows Server 2008. The UI for the RemoteApp is rendered in a window over the local desktop, and is managed like any other window for local applications. The end result of this is that remote applications behave largely like local applications. The task of establishing the remote session, as well as redirecting local resources to the remote application, is transparent to the end user.[22] Multiple applications can be started in a single RemoteApp session, each with their own windows.[23]

A RemoteApp can be packaged either as a .rdp file or distributed via an .msi Windows Installer package. When packaged as an .rdp file (which contains the address of the RemoteApp server, authentication schemes to be used, and other settings), a RemoteApp can be launched by double clicking the file. It will invoke the Remote Desktop Connection client, which will connect to the server and render the UI. The RemoteApp can also be packaged in a Windows Installer database, installing which can register the RemoteApp in the Start menu as well as create shortcuts to launch it. A RemoteApp can also be registered as handler for file types or URIs. Opening a file registered with RemoteApp will first invoke Remote Desktop Connection, which will connect to the terminal server and then open the file. Any application which can be accessed over Remote Desktop can be served as a RemoteApp.[22][24]

Windows 7 includes built-in support for RemoteApp publishing, but it has to be enabled manually in registry, since there is no RemoteApp management console in client versions of Microsoft Windows.[25]

Windows Desktop Sharing

[edit]

In Windows Vista onwards, Terminal Services also includes a multi-party desktop sharing capability known as Windows Desktop Sharing. Unlike Terminal Services, which creates a new user session for every RDP connection, Windows Desktop Sharing can host the remote session in the context of the currently logged in user without creating a new session, and make the Desktop, or a subset of it, available over RDP.[26] Windows Desktop Sharing can be used to share the entire desktop, a specific region, or a particular application.[27] Windows Desktop Sharing can also be used to share multi-monitor desktops. When sharing applications individually (rather than the entire desktop), the windows are managed (whether they are minimized or maximized) independently at the server and the client side.[27]

The functionality is only provided via a public API, which can be used by any application to provide screen sharing functionality. Windows Desktop Sharing API exposes two objects: RDPSession for the sharing session and RDPViewer for the viewer. Multiple viewer objects can be instantiated for one Session object. A viewer can either be a passive viewer, who is just able to watch the application like a screencast, or an interactive viewer, who is able to interact in real time with the remote application.[26] The RDPSession object contains all the shared applications, represented as Application objects, each with Window objects representing their on-screen windows. Per-application filters capture the application Windows and package them as Window objects.[28] A viewer must authenticate itself before it can connect to a sharing session. This is done by generating an Invitation using the RDPSession. It contains an authentication ticket and password. The object is serialized and sent to the viewers, who need to present the Invitation when connecting.[26][28]

Windows Desktop Sharing API is used by Windows Meeting Space and Windows Remote Assistance for providing application sharing functionality among network peers.[27]

Network Level Authentication

[edit]

Network Level Authentication (NLA) is a feature of RDP Server or Remote Desktop Connection (RDP Client) that requires the connecting user to authenticate themselves before a session is established with the server.

Originally, if a user opened an RDP (remote desktop) session to a server it would load the login screen from the server for the user. This would use up resources on the server, and was a potential area for denial of service attacks as well as remote code execution attacks (see BlueKeep). Network Level Authentication delegates the user's credentials from the client through a client-side Security Support Provider and prompts the user to authenticate before establishing a session on the server.

Network Level Authentication was introduced in RDP 6.0 and supported initially in Windows Vista. It uses the new Security Support Provider, CredSSP, which is available through SSPI in Windows Vista. With Windows XP Service Pack 3, CredSSP was introduced on that platform and the included RDP 6.1 Client supports NLA; however CredSSP must be enabled in the registry first.[29][30]

Advantages

[edit]

The advantages of Network Level Authentication are:

  • It requires fewer remote computer resources initially, by preventing the initiation of a full remote desktop connection until the user is authenticated, reducing the risk of denial-of-service attacks.
  • It allows NT Single sign-on (SSO) to extend to RDP Services.
  • It can help mitigate Remote Desktop vulnerabilities that can only be exploited prior to authentication.[31]

Disadvantages

[edit]
  • No support for other credential providers
  • To use Network Level Authentication in Remote Desktop Services, the client must be running Windows XP SP3 or later, and the host must be running Windows Vista or later [32] or Windows Server 2008 or later.
  • Support for RDP Servers requiring Network Level Authentication needs to be configured via registry keys for use on Windows XP SP3.
  • Not possible to change password via CredSSP. This is a problem when "User must change password at next logon" is enabled or if an account's password expires.
  • Requires "Access this computer from the network" privilege, which may be restricted for other reasons.
  • The IP addresses of the clients trying to log in will not be stored in the security audit logs, making it harder to block brute force or dictionary attacks by means of a firewall.
  • Smart card authentication from one domain to another using a remote desktop gateway is not supported with NLA enabled on the end client.

Client software

[edit]
Main article: List of Remote Desktop Protocol clients

Remote Desktop Connection is a primary client for Remote Desktop Services. RDC presents the desktop interface (or application GUI) of the remote system, as if it were accessed locally.[33] Microsoft Remote Desktop was created in 2012 by Microsoft as a client with a touch-friendly interface. Additionally, several non-Microsoft clients exist.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Remote Desktop Services

View on Grokipedia
from Grokipedia
Remote Desktop Services (RDS), formerly known as Terminal Services, is a role-based platform in Windows Server that enables organizations to securely deliver virtualized desktops, RemoteApp programs, and session-based applications to users over a network connection using the (RDP). This technology centralizes processing and management in the datacenter, allowing multiple users to simultaneously access Windows-based resources from diverse devices such as PCs, tablets, and thin clients, while minimizing the need for local installations. In contrast, standard Windows client operating systems (such as Windows 10 and Windows 11 Pro, Home, or standard Enterprise editions) support only one concurrent incoming Remote Desktop session, which locks the local console; multiple concurrent sessions are supported on Windows Server with Remote Desktop Services (requiring CALs) or via Windows Enterprise multi-session exclusively in Azure Virtual Desktop environments. RDS supports a range of deployment models to meet varying organizational needs, including session-based desktops via Remote Desktop Session Host (RDSH) for high-density multi-user environments, pooled virtual desktops for dynamic resource allocation, personal virtual desktops for dedicated user assignments, and hybrid configurations combining these approaches. Key components include the RD Connection Broker for managing user connections and load balancing, RD Web Access for browser-based entry points, RD Gateway for secure external access over , and RD Licensing for compliance with client access licenses (CALs). These elements facilitate on-premises, cloud-based (such as Azure Virtual Machines), or hybrid deployments, with support for features like multi-monitor setups, profile management via Disks, and automation through Windows . The primary benefits of RDS include cost efficiency through server-side resource sharing, which reduces per-user hardware and licensing expenses; enhanced via encrypted RDP sessions, integration, and centralized data storage to prevent endpoint vulnerabilities; and improved user productivity by providing seamless, application-like experiences regardless of location or device. Originally introduced as Terminal Services in Terminal Server Edition in 1998 and rebranded in , RDS has evolved to address modern demands, including integration with for cloud-native virtual desktop infrastructure (VDI), though support for apps on RDS ended in October 2025 with extended updates available until 2028.

Introduction and History

Overview

Remote Desktop Services (RDS) is a technology integrated into that enables users to remotely access virtual desktops, applications, and session-based environments over a network using the (RDP). It functions as a role-based infrastructure, allowing administrators to host multiple user sessions on centralized servers, thereby facilitating the delivery of personalized desktops and apps without requiring local installation on client devices. The primary purposes of RDS include centralized management of applications and desktops, where updates and configurations are applied once at the server level rather than across numerous endpoints; improved security through resource isolation, which limits user access to only necessary components; cost efficiency via multi-user session hosting that maximizes server utilization; and support for hybrid work scenarios by enabling seamless remote connectivity. These capabilities make RDS suitable for organizations seeking to streamline IT operations while maintaining control over sensitive resources. Key benefits of RDS encompass reduced endpoint management overhead, as it minimizes the need for distributing software and patches to individual devices; enhanced scalability for enterprises through support for high-density user environments; compatibility with both on-premises deployments and Azure (IaaS) models; and tight integration with ecosystem tools such as for authentication and policy enforcement. As of November 2025, RDS remains widely adopted for secure remote access in hybrid work settings, even alongside cloud alternatives like , and benefits from the high-performance, AI-capable platform of 2025. The underlying RDP, in versions 10 and later, supports essential features such as configurations for extended workspaces, redirection to enable seamless copy-paste operations between local and remote sessions, and device mapping including USB redirection for accessing peripherals like drives and printers. These elements ensure a productive, native-like for remote users while maintaining secure, encrypted communication.

Historical Development

Remote Desktop Services originated as Terminal Services, introduced in the Windows NT 4.0 Terminal Server Edition released to manufacturing on June 16, 1998. This edition was developed as a joint effort between and , licensing Citrix's MultiWin technology to enable multi-user access to a single server for thin-client computing environments. The technology allowed multiple users to run Windows applications remotely on low-cost terminals, marking an early shift toward to reduce hardware costs and simplify . Terminal Services evolved through subsequent Windows Server releases, with significant enhancements in functionality and naming. In , released in , it was renamed Remote Desktop Services (RDS) to reflect its expanded role in supporting virtual desktop infrastructure (VDI) and remote applications, alongside the introduction of RDS-specific Client Access Licenses (CALs). Licensing transitioned from primarily per-device models to support per-user CALs, accommodating mobile workforces while requiring RDS CALs in addition to standard CALs. Key milestones followed in later versions. Windows Server 2012 introduced session collections for grouping resources and enhanced RD Web Access for streamlined remote connections, simplifying deployments for both session-based desktops and VDI. Windows Server 2016 improved VDI capabilities with enhanced graphics performance via Discrete Device Assignment (DDA). In Windows Server 2019, RDS added strengthened security features like improved device redirection controls and deeper integration with Azure for hybrid deployments. Windows Server 2022 brought hotpatching for reduced downtime. Windows Server 2025, released on November 1, 2024, includes general enhancements such as improved and hybrid cloud integration capabilities, with no major architectural changes specific to RDS. Over time, RDS shifted from legacy multi-user Terminal Services to emphasize VDI and RemoteApp programs, driven by advancements and migration trends.

Architecture and Components

Server Roles

Remote Desktop Services (RDS) in relies on several core server roles that collectively enable secure, scalable access to virtual desktops and applications. These roles are installed and managed through Server Manager and can be deployed on physical or virtual servers, often in a farm configuration for and load balancing. Each role performs specific functions while interacting via protocols like (RDP) and to form a cohesive infrastructure. The RD Session Host role allows a single instance to host multiple concurrent user sessions, delivering session-based desktops or RemoteApp programs to users over the network. It supports resource pooling in high-density environments, where multiple users share the server's CPU, memory, and storage, enabling efficient scaling for organizations with many remote workers. This role is essential for session-based deployments and can be configured with collections to group applications and desktops logically. The RD Session Host communicates with the RD Connection Broker to report session availability and accept incoming connections, ensuring seamless user assignment to the least-loaded server in a . The RD Connection Broker manages user connections across RD Session Host servers or virtual desktop collections, performing load balancing, session reconnection, and clustering. It directs incoming requests to available resources, tracks active sessions to allow users to reconnect to their existing desktops from any device, and supports failover in clustered setups using shared databases such as the (WID) or external options like Azure SQL or SQL Server; however, WID is deprecated in 2025 and should be replaced with SQL Server for production environments. This role queries RD Session Hosts for load metrics and integrates with RD Gateway for external access routing, preventing overload and maintaining continuity during server maintenance. RD Connection Brokers can be deployed in pairs for redundancy, using matching certificates for secure inter-role communication. The RD Gateway role facilitates secure remote access from external networks by encapsulating RDP traffic within tunnels over TCP port 443 and UDP port 3391, bypassing traditional firewall restrictions. It authenticates users against and applies authorization policies before forwarding connections to internal RD Session Hosts or virtual desktops, reducing exposure of RDP ports to the . RD Gateway integrates with the RD Connection Broker to route sessions intelligently and supports load-balanced farms for , with all instances sharing configuration via a central database. This role communicates with other RDS components using TLS-secured RDP, ensuring encrypted data flow throughout the infrastructure. RD Web Access provides a browser-based portal for users to discover and launch RemoteApps and desktops without installing client software, leveraging (IIS) and on port 443. It authenticates users via forms or and generates RDP files for seamless connections to the RD Connection Broker. This role scales through load-balanced farms and requires synchronization with RD Gateway for external users, enabling cross-platform access including support for non-Windows devices. RD Web Access interacts with the RD Connection Broker to enumerate available resources, delivering a unified entry point for the RDS environment. The RD Licensing role serves as a centralized server for issuing and monitoring Remote Desktop Services Client Access Licenses (RDS CALs), enforcing compliance in per-user or per-device licensing modes. It tracks active connections across all RDS roles, revoking access if license limits are exceeded, and supports through deployment in availability sets or clusters. Every RDS deployment requires RD Licensing to validate user sessions against , with the role communicating license status to RD Connection Brokers and Session Hosts via internal protocols. This ensures legal and operational integrity without interrupting user access. The RD Virtualization Host role integrates with Hyper-V to provision and manage virtual machines (VMs) for Virtual Desktop Infrastructure (VDI) scenarios, supporting both pooled (shared) and personal (dedicated) desktops. It handles VM templates, user assignments, and lifecycle management, allowing dynamic provisioning based on demand. This role depends on the RD Connection Broker for connection brokering to VMs and communicates with RD Session Hosts in hybrid setups, using RDP for session delivery and Hyper-V APIs for VM control. RD Virtualization Host enables non-persistent desktops that reset after logoff, optimizing resource utilization in large-scale VDI environments. Inter-role communication in RDS occurs primarily over RDP with TLS encryption for , supplemented by for external-facing components like RD Gateway and RD Web Access. The RD Connection Broker acts as the central orchestrator, querying RD Session Hosts and RD Virtualization Hosts for availability via proprietary internal protocols, while RD Licensing periodically synchronizes with brokers to enforce CALs. RD Gateway and RD Web Access forward authenticated requests to the broker, which then establishes sessions on the appropriate host, creating a layered that balances , , and . These interactions support deployment models like session-based or VDI without direct user exposure to underlying protocols.

Deployment Models

Remote Desktop Services (RDS) supports several deployment models tailored to organizational needs, ranging from cost-efficient shared environments to isolated virtual desktops, with options for on-premises, cloud, or hybrid setups. These models leverage core server roles such as RD Session Host and RD Virtualization Host to deliver remote access, while and high availability features ensure reliability across varying user loads. Session-based deployment utilizes the RD Session Host role to enable multiple users to access shared resources on a single instance, providing isolated sessions for each user. This model is ideal for application delivery in scenarios with low hardware demands, such as task-oriented workflows or line-of-business applications, offering the highest user density and lowest per-user cost through multi-session efficiency and centralized management. VDI pooled deployment involves non-persistent virtual desktops pooled and dynamically assigned to users via the RD Virtualization Host integrated with , where desktops reset upon logoff to maintain . It suits environments requiring Windows client compatibility and application isolation for workers, balancing medium with flexibility. In contrast, VDI personal deployment assigns persistent, user-specific virtual machines that retain customizations, ensuring full desktop isolation at the cost of higher intensity. This approach is better suited for power users or developers needing tailored setups, such as those involving specialized applications. Hybrid models combine on-premises RDS components, like session hosts, with Azure Infrastructure as a Service (IaaS) for enhanced disaster recovery and scalability, allowing elastic capacity expansion during peak demands. Authentication integrates via Microsoft Entra Domain Services and Microsoft Entra Connect to synchronize on-premises with Azure, streamlining user access without manual replication. Scalability in RDS deployments is achieved through (HA) configurations using clustering for components like the RD Connection Broker, which supports load balancing across multiple nodes to distribute user connections and prevent single points of failure. Network bandwidth and storage considerations are critical, particularly for VDI, where Cluster Shared Volumes (CSV) provide shared storage in clusters to enable and . Prerequisites for RDS deployment include hardware meeting minimum thresholds, such as at least 8 vCPUs and 16 GB RAM for multi-session hosts handling light to heavy workloads, with additional GPU support for multimedia-intensive use cases. Operating system compatibility requires or later for session hosts and Windows client images for VDI; planning tools like the RDS planning poster and Quick Start guides assist in assessing user personas and infrastructure needs.

Features and Functionality

RemoteApp and Session-Based Desktops

RemoteApp is a feature of Remote Desktop Services (RDS) that enables administrators to publish individual Windows applications, such as or custom line-of-business software, allowing users to access them remotely as if they were installed locally on their devices. These applications run on an RD Session Host server, where the user interface and interactions are streamed to the client via the (), without displaying the full server desktop. Key integrations include support for file-type associations, so double-clicking a document on the local machine launches the remote app seamlessly, and printer redirection, which maps local printers to the remote session for printing from the hosted application. Session-based desktops, in contrast, provide users with access to a full remote hosted on the RD Session Host in multi-session mode, where multiple users share the same server hardware but operate in isolated sessions to maintain and . This model differs from Virtual Desktop Infrastructure (VDI), which uses dedicated virtual machines for single-user persistence, by enabling efficient resource sharing across concurrent users on physical or virtual servers. Sessions are managed to prevent interference, with each user receiving a personalized view of the desktop and applications. Configuration of RemoteApp and session-based desktops occurs through RDS collections, where administrators publish resources using the RD Connection Broker for load balancing and session orchestration, or via the RD Web Access portal for user self-service access. Publishing involves selecting applications or desktops in Server Manager and defining parameters such as session timeouts (e.g., active session limits to prevent indefinite resource use) and idle disconnects (e.g., automatically ending inactive sessions after a set period to free server capacity). Shadow sessions allow administrators to monitor or assist users in real-time by viewing or controlling active sessions, configured via settings under Remote Desktop Services > Remote Session Host > Connections, with options for user permission prompts or full control without notification. Advantages of these features include reduced bandwidth consumption, as only the application interface or desktop elements are streamed rather than full video feeds, making them suitable for lower-speed connections. Centralized deployment facilitates uniform updates and patching across all users from a single server, minimizing administrative overhead, and supports running legacy applications that may not be compatible with modern client OSes without local installation. As of 2025, App Attach (replacing the deprecated MSIX App Attach) enables dynamic application streaming in environments integrated with RDS, allowing apps to be attached on-demand to sessions for faster provisioning and reduced image bloat. Limitations arise in high-load scenarios, where multiple concurrent sessions on shared hardware can lead to or conflicts if applications are not designed for multi-user environments, such as those relying on unique per-machine registry keys. Graphics-intensive applications, like CAD software or video editors, may underperform without dedicated GPU acceleration on the RD Session Host, potentially causing lag or poor rendering quality. Client software, such as the Remote Desktop app, is required for connectivity, with details on access methods covered in relevant sections.

Virtual Desktop Infrastructure

Virtual Desktop Infrastructure (VDI) in Remote Desktop Services (RDS) enables the delivery of personalized virtual desktops by leveraging the RD Virtualization Host role to create and manage virtual machines (VMs). This setup supports both pooled desktops, where VMs are dynamically assigned to users, and personal desktops, which are dedicated to users for persistent configurations. The provisioning process for VDI in RDS begins with creating a master image of a Windows client OS, which is then used to clone VMs either through Preboot Execution Environment (PXE) booting for network-based deployment or differencing disks in to efficiently replicate the base image while minimizing storage usage. Automation is enhanced through integration with System Center Virtual Machine Manager (SCVMM), which allows for scripted VM deployment, scaling, and management across hosts. Pooled VDI assigns available VMs to users upon , with the reassigning desktops dynamically and reverting to snapshots after sessions to maintain a clean state, which supports higher user density of approximately 10-20 users per physical host depending on the workload. This model is cost-effective for environments requiring temporary access without data persistence. In contrast, personal VDI provides each user with a dedicated VM that retains customizations and data, often using User Profile Disks for persistent storage of user settings and files, making it ideal for developers or power users who require tailored environments. As of 2025, RDS VDI has seen enhancements including improved integration with for hybrid cloud-on-premises deployments, enabling seamless migration of workloads to cloud-based virtual desktops. Additionally, enhanced support for NVMe-oF storage in improves I/O performance for VM provisioning, while GPU passthrough and partitioning features in 2025 allow better handling of graphics-intensive applications by allocating dedicated GPU resources to VMs. Common use cases for RDS VDI include compliance-driven scenarios where VM isolation ensures data security and auditability, bring-your-own-device (BYOD) environments that provide secure access from personal hardware without compromising corporate resources, and migrations from physical desktops to virtual setups to centralize management and reduce hardware costs.

Security Mechanisms

Network Level Authentication

Network Level Authentication (NLA) is a security feature in Remote Desktop Services (RDS) that requires users to authenticate their credentials before a full (RDP) session is established, thereby preventing unauthorized access to server resources and mitigating risks such as denial-of-service attacks or man-in-the-middle exploits. This pre-authentication step validates credentials against using protocols like Kerberos or , ensuring that only verified users proceed to the logon screen. NLA leverages the Credential Security Support Provider (CredSSP) to encrypt and transmit credentials securely, reducing the by avoiding the allocation of session resources to unauthenticated connections. Implementation of NLA is straightforward and enabled by default on and later versions, including Windows Server 2025, where it is recommended for enhanced security in compliant environments. Administrators can configure it via under Computer Configuration > Administrative Templates > Windows Components > > Remote Desktop Session Host > Security, specifically by enabling the setting "Require user authentication for remote connections by using Network Level Authentication." NLA supports advanced authentication methods, including smart cards and certificate-based authentication, where users enter a PIN on the client side, and the credentials are securely forwarded to the server for validation. The protocol flow begins with the client initiating a TLS-secured channel to the server, followed by sending encrypted credentials via CredSSP for early verification. The server then authenticates these against using Kerberos (preferred in domain environments) or as a fallback, only proceeding to establish the RDP session if validation succeeds. This process integrates with modern security standards, using TLS up to version 1.2 to ensure robust encryption throughout. NLA requires RDP client version 6.1 or later, corresponding to , , or subsequent editions; older clients, such as those on SP2, are incompatible and will fail to connect unless NLA is disabled on the server, reverting to basic authentication. Introduced with and to address evolving needs, NLA has become a standard in RDS deployments, with mandatory enforcement in certain high-security setups for as of 2025.

Additional Security Features

Remote Desktop Services (RDS) employs advanced encryption protocols to secure communications, with the (RDP) leveraging (TLS) 1.2 as the default in Windows Server 2025 through the Schannel Security Support Provider (SSP). This enhances handshake encryption and overall cipher suite strength compared to prior TLS versions, mitigating risks from deprecated protocols like TLS 1.0 and 1.1, which are disabled by default. Additionally, certificate-based authentication enables mutual verification between clients and servers, using certificates to authenticate the server's identity and prevent man-in-the-middle attacks during RDP sessions. For UDP-based connections, RDS supports (DTLS), which secures unreliable transport channels for multimedia redirection while maintaining low latency. Access controls in RDS extend beyond basic authentication through role-based policies enforced by the Remote Desktop Gateway (RD Gateway), allowing administrators to define granular authorization rules based on user groups, device types, and connection origins. Integration with (formerly Azure AD) further strengthens these controls by enabling (MFA) via the Network Policy Server (NPS) extension and policies that evaluate risk factors before granting session access. Monitoring and auditing capabilities in RDS include comprehensive event logging within the RD Connection Broker, which records session initiations, disconnections, and authorization events for forensic analysis and compliance reporting. Integration with Microsoft Defender for Endpoint provides real-time threat detection in remote sessions, scanning for , anomalous behaviors, and exploit attempts directly within virtualized desktops or session hosts. To mitigate known vulnerabilities, RDS incorporates patched RDP protocol stacks that address exploits like (CVE-2019-0708), a remote code execution flaw affecting older unpatched systems, through cumulative updates that enhance channel and input validation. Restricted Admin mode further limits credential exposure by preventing the transmission of full administrative privileges to remote hosts, requiring post-connection elevation only when necessary and reducing the from credential theft. In 2025, is enhanced by default-enabling Credential Guard, which uses virtualization-based to isolate and protect credentials from in remote sessions, and hotpatching, allowing updates without server reboots to minimize downtime and exposure windows.

Client Software and Connectivity

Windows-Based Clients

The built-in Remote Desktop Connection client, accessible via mstsc.exe, serves as the core tool for and 11 users to connect to Remote Desktop Services (RDS) hosts. It supports (RDP) versions 10 and later, enabling features such as multi-monitor setups where users can span sessions across multiple local displays for enhanced productivity. Advanced configuration options include persistent bitmap caching, which stores frequently used graphical elements locally to reduce bandwidth usage and improve performance during reconnections. Standard Windows client operating systems, such as Windows 10 and Windows 11 Pro, Home, or single-session Enterprise editions, do not support multiple concurrent incoming Remote Desktop sessions. These versions permit only one active remote session at a time, which locks the local console session. Multiple concurrent sessions are officially supported only on Windows Server configured with Remote Desktop Services (requiring appropriate Client Access Licenses for more than two connections) or through Windows Enterprise multi-session, which is exclusive to Azure Virtual Desktop environments and not available in standard on-premises client installations. The Remote Desktop app, available from the for and later, provides a modern interface for RDS connectivity with additional capabilities like workspace organization and feed subscriptions. Users can subscribe to Remote Desktop Web Access feeds via to automatically discover and connect to published resources, streamlining access to RemoteApps and desktops. It also supports dynamic , adjusting the remote session's resolution in real-time based on the local device's orientation or size changes. However, as of May 27, 2025, this app is no longer supported or available for new downloads, with recommending migration to the Windows App for continued functionality. The Windows App serves as the modern, unified client replacing legacy Remote Desktop apps across platforms. Configuration of these clients often involves editing RDP files (.rdp), which store connection parameters for reuse and customization. The default listening port is TCP/UDP 3389, though it can be modified in the .rdp file or via registry settings for security purposes. Display settings allow selection of resolution, , and full-screen modes, while local resource redirection enables sharing of drives, audio playback, printers, and USB devices between the client and remote session. Integration with Windows security features enhances usability and protection. Seamless sign-in supports Windows Hello for Business, allowing biometric or PIN authentication during RDP sessions via redirected capabilities. Network Level Authentication (NLA) is enabled by default for pre-session credential validation, reducing exposure to unauthorized access. support permits certificate-based logins, with the client prompting for PIN entry locally before transmission. Common troubleshooting involves verifying firewall rules, as blocks on port 3389 often prevent connections; tools like psping can test port accessibility from the client side. RDS clients support hybrid (formerly Azure AD) join, allowing clients to authenticate seamlessly to sessions on devices combined with on-premises , facilitating hybrid work environments.

Cross-Platform Support

Remote Desktop Services (RDS) provides client access across various non-Windows platforms through dedicated applications, web-based interfaces, and open-source implementations, enabling users to connect to remote sessions from diverse devices without requiring Windows-specific software. This support leverages the (RDP) for compatibility, allowing seamless integration with RDS hosts while adapting to platform-specific capabilities like touch interfaces and hardware accelerations. The web client for RDS, known as the Remote Desktop web client, offers HTML5-based access through RD Web Access, eliminating the need for software installation and supporting modern browsers such as Microsoft Edge and . It features a responsive, touch-optimized suitable for RemoteApps, including bidirectional functionality, file upload/download, and microphone redirection, though advanced features like multiple monitor support are limited compared to native clients. For mobile devices, provides the Windows App for / and Android, facilitating access to RDS sessions with platform-native gesture support, including touch and pen inputs on /. These apps include on-screen keyboards for input and support for local resource redirection such as cameras, microphones, and speakers; while biometric authentication like or is available for device login, it relies on underlying OS security rather than direct RDP integration. On macOS, the Remote Desktop app (now part of Windows App) delivers robust RDS connectivity, supporting optimization for high-resolution rendering and seamless scaling. Key features include file sharing via folder redirection, allowing local Mac folders to be accessed within remote sessions, and microphone redirection for audio input; the app is compatible with macOS 10.15 and later versions. The Windows App serves as the modern, unified client replacing legacy Remote Desktop apps across platforms. Linux users rely on open-source RDP clients such as and FreeRDP for connecting to RDS, with rdesktop providing support for core RDS features like session hosting. These tools enable basic remote sessions, including display and input redirection, but offer limited native integration with RDS-specific enhancements, such as advanced protocols, requiring manual configuration for optimal functionality. RDS maintains with legacy RDP versions (e.g., RDP 5.2 and later) to support older clients, ensuring in mixed environments. Third-party solutions like Citrix Receiver can integrate with RDS for hybrid setups, allowing cross-vendor access to published resources through protocol bridging.

Deployment and Management

Installation and Configuration

Installing and configuring Remote Desktop Services (RDS) on or later requires meeting specific prerequisites to ensure compatibility and performance. The server must run Standard or Datacenter edition, as these support the full RDS role suite. For multi-server deployments, servers should be joined to an domain to enable features like centralized user management and collections, though single-server setups can operate in workgroup mode with limitations. Hardware recommendations include at least 2 GB of RAM per concurrent user session for light workloads, scaling up to 4-8 GB for more demanding applications, alongside sufficient CPU resources such as 2 physical cores per or 4 vCPUs with for session hosts. Firewall configurations must allow inbound TCP port 3389 for (RDP) traffic, with additional ports like TCP 445 for if needed. The installation process begins in Server Manager, where administrators select Manage > Add Roles and Features to initiate the wizard. Choosing Role-based or feature-based installation allows selection of the target server, followed by adding the Remote Desktop Services role and its sub-roles, such as Remote Desktop Session Host for hosting sessions or Remote Desktop Connection Broker for managing connections. For quick deployment, the Remote Desktop Services installation option under Scenario-based installation guides users through selecting Standard Deployment for session-based desktops, automatically installing necessary roles across designated servers. Alternatively, scripting enables automated setup; for instance, the New-RDSessionDeployment cmdlet installs and configures the required roles for a session-based deployment on specified servers, while New-RDSessionCollection creates a session collection post-installation by specifying session host servers, collection name, and user groups. Configuration involves creating and managing collections to organize resources. In Server Manager, under Remote Desktop Services > Collections > Tasks > Create Session Collection, administrators define pooled or personal collections, adding RD Session Host servers and specifying properties like the default desktop size and security layer. User and group assignments occur via the collection's Properties dialog, using Authorization Manager or Active Directory groups to grant access, ensuring only authorized users can connect. Tuning session behaviors relies on Group Policy; navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits to set policies such as maximum disconnection time or idle session limits, preventing resource exhaustion. For VDI collections, similar steps apply under Create Virtual Desktop Collection, integrating with Hyper-V or other hypervisors. To detect dead or unresponsive client connections, administrators can configure the keep-alive connection interval on the Remote Desktop Session Host. Navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections, enable the "Configure keep-alive connection interval" policy, and set the desired interval in minutes (range 1 to 999999). This setting specifies how often the server sends keep-alive packets to the client to verify connection status. Alternatively, the equivalent setting can be applied directly via the registry key HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\KeepAliveInterval (REG_DWORD), with the value representing the interval in minutes. This policy is supported on Windows Server 2008 R2 and later versions with the Remote Desktop Session Host role. Performance optimization focuses on and network efficiency. Adjust CPU throttling via under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Limit maximum amount of CPU resources to set per-session limits, typically 70-80% to avoid overload. allocation should align with user density, monitoring via or to ensure no paging occurs. For network quality, implement (QoS) policies to prioritize RDP traffic, using tools like the QoS Packet Scheduler in to guarantee bandwidth for UDP ports 3389-3390 in multimedia scenarios. Monitoring tools such as the query user (quser) command or Query Session in provide real-time session insights, helping identify bottlenecks. Common pitfalls during setup include certificate mismatches for TLS encryption, where self-signed certificates trigger warnings; resolve by deploying valid certificates from a trusted CA via the RD Connection Broker's Deployment Properties. (CAL) mismatches arise if unactivated licenses are installed, leading to session limits after 120 days—activate via Remote Desktop Licensing Manager post-installation. Troubleshooting leverages under Applications and Services Logs > Microsoft > Windows > TerminalServices, checking for errors like authentication failures or resource shortages.

Licensing and Scalability

Remote Desktop Services (RDS) deployments require both a Windows Server Client Access License (CAL) for general server access and an additional RDS CAL to enable remote session capabilities on the session host servers. The RDS CALs are managed and enforced through a dedicated Remote Desktop Licensing server, which issues licenses to users or devices upon connection and tracks compliance. A 120-day grace period allows initial testing and deployment without immediate CAL enforcement, after which unlicensed connections are restricted. RDS CALs are available in two primary models: per-user and per-device. The per-user model assigns CALs to individual user accounts, making it suitable for roaming users who access RDS from multiple devices; these CALs cannot be revoked once issued but allow reassignment after a 90-day period, with temporary licenses valid for 60 days. In contrast, the per-device model licenses specific endpoints, ideal for fixed workstations or kiosks, permitting up to 20% revocation of issued CALs and 90-day temporary licenses. CALs are version-specific, requiring compatibility with the target version—such as Windows Server 2025 CALs working with 2025 or earlier servers, but not the reverse—to ensure across deployments. To upgrade RDS CALs using Software Assurance (SA), which entitles users to the latest version of CALs under qualifying agreements such as Enterprise Agreement or Open Value, first ensure the Remote Desktop Licensing role is installed via Server Manager > Add Roles and Features > Remote Desktop Services > Remote Desktop Licensing, and that the license server is activated. Open the Remote Desktop Licensing Manager (licmgr.exe), right-click the license server name, and select Install Licenses. In the wizard, choose the appropriate license program (e.g., Enterprise Agreement, Open Value), select Automatic connection method or phone activation, and enter the Volume Licensing agreement number or authorization number. The wizard contacts the Microsoft Clearinghouse, which issues the latest-version CALs based on SA coverage; this process may result in new CALs being added alongside existing older ones temporarily. For cleanup, contact Microsoft Volume Licensing Support to request revocation of old CALs, providing details of the license server. Cost management for RDS involves choosing between perpetual licenses for RDS CALs, which entail a one-time purchase for indefinite use (often in packs of five CALs, with prices varying by reseller), while the Windows Server OS can use subscription options like Azure pay-as-you-go via Azure Arc without upfront core-based commitments (minimum eight cores per virtual machine). Perpetual licenses can be augmented with Software Assurance for upgrade rights. Integration with bundles licensing for applications on RDS via shared computer activation but does not include RDS CALs, necessitating separate purchase for server access. Usage auditing is facilitated by the Remote Desktop Licensing Manager, which generates reports on CAL issuance, temporary licenses, and over-allocation to maintain compliance and optimize costs. Administrators can review per-user or per-device reports to track active sessions and ensure alignment with purchased licenses, helping avoid penalties during Microsoft audits that may examine up to three to five years of usage. For scalability, RDS supports horizontal scaling by deploying multiple Remote Desktop Session Host (RDSH) servers in a farm, distributing user sessions via load balancing to increase capacity and provide redundancy against failures. Vertical scaling enhances performance by allocating more CPU and memory resources to individual RDSH servers or virtual machines, accommodating higher loads on fewer hosts. In Azure (IaaS) environments, scalability can be achieved by deploying multiple RDSH instances in a farm, with load balancing via the RD Connection Broker. Monitoring tools such as counters—for instance, those tracking user input delay, CPU usage, and memory consumption—enable proactive identification of bottlenecks to guide scaling decisions. In 2025, RDS licensing extends support for hybrid scenarios through Azure Arc integration, allowing on-premises CALs to apply in cloud environments and enabling features like hotpatching for security updates without reboots, which reduces operational downtime and associated costs.

References

  1. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/overview
  2. https://learn.microsoft.com/en-us/windows/win32/termserv/terminal-services-is-now-remote-desktop-services
  3. https://learn.microsoft.com/en-us/azure/virtual-desktop/windows-multisession-faq
  4. https://support.microsoft.com/en-us/topic/announcing-the-retirement-of-microsoft-365-apps-on-rds-a0b0e4a9-8f0a-4b0e-9b0e-0b0e4a9-8f0a
  5. https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2025
  6. https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-configure-clipboard
  7. https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-configure-usb
  8. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/understanding-remote-desktop-protocol
  9. https://news.microsoft.com/source/1998/06/16/microsoft-releases-windows-nt-server-4-0-terminal-server-edition/
  10. https://www.sciencedirect.com/science/article/pii/B9781931836531500055
  11. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-client-access-license
  12. https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-in-windows-server-2016
  13. https://www.techtarget.com/searchwindowsserver/tip/Windows-Server-2019-RDS-updates-a-boon-for-remote-work-needs
  14. https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
  15. https://www.centron.de/en/tutorial/windows-server-2025-new-features/
  16. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-roles
  17. https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server
  18. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-gateway-role
  19. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/desktop-hosting-logical-architecture
  20. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/session-host-virtual-machine-sizing-guidelines
  21. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-connection-broker-cluster
  22. https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/virtualization-hosts
  23. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-supported-config
  24. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-poster
  25. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-create-collection
  26. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/connection-configuration-in-terminal-server
  27. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/shadow
  28. https://learn.microsoft.com/en-us/azure/virtual-desktop/app-attach-overview
  29. https://redmondmag.com/articles/2015/07/01/rds-rapid-deployment.aspx
  30. https://learn.microsoft.com/en-us/azure/virtual-desktop/terminology
  31. https://blogs.windows.com/windowsexperience/2025/06/18/strengthen-business-resilience-with-windows-365-and-azure-virtual-desktop/
  32. https://medium.com/@leoyeh.me/architecting-resilient-storage-with-windows-server-nvme-of-refs-and-s2d-for-regulated-industries-c6f8dea1f422
  33. https://redmondmag.com/articles/2024/06/11/windows-server-2025-gpu-partitioning.aspx
  34. https://azure.microsoft.com/en-ca/resources/cloud-computing-dictionary/what-is-virtual-desktop-infrastructure-vdi/
  35. https://www.nutanix.com/info/what-is-vdi
  36. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/rdc-6dot1-client-update-terminal-services
  37. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732713(v=ws.11)
  38. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-allow-access
  39. https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-and-remote-desktop-services
  40. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-certificates
  41. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpemt/5aa61c5c-e864-4ec6-bd80-e1df51555a48
  42. https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-nps-extension-rdg
  43. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/log-files-to-troubleshoot-rds-issues
  44. https://learn.microsoft.com/en-us/defender-endpoint/deployment-vdi-microsoft-defender-antivirus
  45. https://support.microsoft.com/en-us/topic/customer-guidance-for-cve-2019-0708-remote-desktop-services-remote-code-execution-vulnerability-may-14-2019-0624e35b-5f5d-6da7-632c-27066a79262e
  46. https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard
  47. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mstsc
  48. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-protocol-settings
  49. https://learn.microsoft.com/en-us/answers/questions/2316223/windows-11-remote-desktop-app-%28not-mstsc-exe-the-o
  50. https://learn.microsoft.com/en-us/answers/questions/3934602/rdp-keeps-crashing-when-starting-a-new-session
  51. https://learn.microsoft.com/en-us/answers/questions/2133589/options-to-support-multiple-rdp-sessions-on-window
  52. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/remote-desktop-windows-urdc
  53. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/whats-new-windows
  54. https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-app-to-replace-remote-desktop-app-for-windows/4390893
  55. https://techcommunity.microsoft.com/blog/windows-itpro-blog/prepare-for-the-remote-desktop-client-for-windows-end-of-support/4397724
  56. https://learn.microsoft.com/en-us/windows-app/get-started-connect-devices-desktops-apps
  57. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/ports-used-by-rds
  58. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/change-listening-port
  59. https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-properties
  60. https://learn.microsoft.com/en-us/azure/virtual-desktop/redirection-remote-desktop-protocol
  61. https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/rdp-sign-in
  62. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/compare-remote-desktop-clients
  63. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/rdp-error-general-troubleshooting
  64. https://learn.microsoft.com/en-us/windows/client-management/client-tools/connect-to-remote-aadj-pc
  65. https://learn.microsoft.com/en-us/entra/identity/devices/howto-vm-sign-in-azure-ad-windows
  66. https://learn.microsoft.com/en-us/windows-app/compare-platforms-features
  67. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-web-client
  68. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/whats-new-ios-ipados
  69. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/whats-new-macos
  70. https://learn.microsoft.com/en-us/previous-versions/remote-desktop-client/client-features-macos
  71. https://apps.apple.com/us/app/windows-app/id1295203466
  72. https://bitlaunch.io/blog/the-best-rdp-clients-for-linux-in-2025/
  73. https://learn.microsoft.com/en-us/azure/virtual-machines/linux/use-remote-desktop
  74. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-deploy-infrastructure
  75. https://learn.microsoft.com/en-us/powershell/module/remotedesktop/new-rdsessioncollection?view=windowsserver2025-ps
  76. https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/remote-desktop/session-hosts
  77. https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-bandwidth
  78. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/troubleshoot-remote-desktop-disconnected-errors
  79. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-activate-license-server
  80. https://learn.microsoft.com/en-us/answers/questions/5641981/upgrade-remote-desktop-cals
  81. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-install-cals
  82. https://www.microsoft.com/licensing/guidance/Windows-Server-2025
  83. https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-pay-as-you-go
  84. https://learn.microsoft.com/en-us/microsoft-365-apps/deploy/deploy-microsoft-365-apps-remote-desktop-services
  85. https://www.octopus.cloud/blog/dos-and-donts-of-rds-licensing
  86. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-scale-rdsh-farm
  87. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-and-design
  88. https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-rdsh-performance-counters
Add your contribution
Related Hubs
User Avatar
No comments yet.