To deploy RDS in either manner, you will be able to start with the Windows Server Remote Desktop Services “Quick Start” deployment. The server should already have a static IP address, be named and joined to the domain. From Server Manager Add Roles and Features. Select Remote Desktop Services installation. Then choose Quick Start. Nov 26, 2019 justgoogleit wrote: I suppose it depends on if any services use the fqdn of the server to run the service. If it's just a standard RDS install without too much on it- there shouldn't be any issue with using Server Manager locally or via RSAT to rename the PC and set a static IP. To configure Remote Desktop Services correctly for internet access or any time where firewalls are used, it is useful to know what ports are required. The information / taxonomy is broken down by role service/component, and lists all inbound/outbound ports used.

By default, when a user closes the RDP/RDS session window in a terminal client (mstsc.exe, RDCMan or Remote Desktop HTML5 web client) by simply clicking the cross in the top right corner without logging off, his session goes into disconnected mode. In this mode, all apps, open files and windows are still running on a remote desktop server and consuming resources.

By default, a user’s RDP session in Windows may stay in the disconnected state until terminated by the user or administrator, or until the computer is restarted. It is quite convenient, since a user may any time connect to his old remote desktop session and go on working with running programs or open files.

In the following screenshot you can see that the disconnected user sessions on the RDS server running Windows Server 2016 are using about 40% of the server RAM. Also, these sessions may block open files on your file servers, cause problems of incorrect saving of data in the apps, roaming profile folders or on User Profile Disks.

Using the quser command, you can view when a user RDP session was started, how long it was idle and the current session state.

To automatically terminate disconnected RDP/RDS sessions in a specified period of time, you need to set session limits (timeouts) correctly.

If you use an RDS server, you can configure session timeout parameters in the RDS collection settings on the Session tab.

Specify the time period, after which you want to kill a disconnected remote desktop session, in the End a disconnected session option (by default, a session period is unlimited – Never). You can also set the maximum time of an active session (Active session limit) and end an idle session (Idle session limit). These hard timeouts are applied to all sessions in the RDS collection.

You can also set the limits of an RDP session in the properties of a local (lusrmgr.msc) or domain user (dsa.msc — Active Directory Users and Computers).

In Windows Server 2012 R2/2016/2019, you can set RDP session timeouts using Group Policies. You can do it either in the domain GPO editor (gpmc.msc) or in the Local Group Policy Editor (gpedit.msc) on an RDS server or client (if you are using a desktop Windows edition as a terminal server).

The settings of RDP session timeouts are located in the following GPO section Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits. The following Remote Desktop timeout settings are available:

• Set time limit for disconnected session;
• Set time limit for active but idle Remote Desktop Services sessions — the policy allows idle RDP sessions to be terminated that have no user input (like moving a mouse or typing something on a keyboard);
• Set time limit for active Remote Desktop Services sessions — it is the maximum time of any RDP session (even an active one), after which it gets disconnected;
• End Session when time limits are reached — sets the time, after which an RDP session will be terminated (logoff) instead of disconnecting it;
• Set time limit for logoff of RemoteApp sessions.

By default, these options are not configured. To automatically terminate disconnected RDP user sessions in 8 hours, enable the Set time limit for disconnected session policy and select 8 hours in the dropdown list.

Save the changes and update the Group Policy settings on your RD host (gpupdate /force). New timeout settings will be applied to new RDP sessions only (you will have to end the current RDS sessions manually).

• MaxDisconnectionTime
• MaxIdleTime
• MaxConnectionTime
• MaxDisconnectionTime
• RemoteAppLogoffTimeLimit

In Windows Server 2008 R2, you could also set RDP session timeouts using a special console: tsconfig.msc (RD Session Host Configuration). It was enough to open the console and right-click RDP-Tcp -> Properties. The settings of session limits are located on the Sessions tab. However, there is no such console in newer Windows Server versions (although you can manually copy tsadmin.msc and tsconfig.msc files and use these consoles on newer Windows Server versions as well).

Remoteapp Remote Desktop Services Is Currently Busy

Remote Desktop Services (RDS) is the platform of choice for building virtualization solutions for every end customer need, including delivering individual virtualized applications, providing secure mobile and remote desktop access, and providing end users the ability to run their applications and desktops from the cloud.

RDS offers deployment flexibility, cost efficiency, and extensibility—all delivered through a variety of deployment options, including Windows Server 2016 for on-premises deployments, Microsoft Azure for cloud deployments, and a robust array of partner solutions.

Depending on your environment and preferences, you can set up the RDS solution for session-based virtualization, as a virtual desktop infrastructure (VDI), or as a combination of the two:

• Session-based virtualization: Leverage the compute power of Windows Server to provide a cost-effective multi-session environment to drive your users' everyday workloads.
• VDI: Leverage Windows client to provide the high performance, app compatibility, and familiarity that your users have come to expect of their Windows desktop experience.

Within these virtualization environments, you have additional flexibility in what you publish to your users:

• Desktops: Give your users a full desktop experience with a variety of applications that you install and manage. Ideal for users that rely on these computers as their primary workstations or that are coming from thin clients, such as with MultiPoint Services.
• RemoteApps: Specify individual applications that are hosted/run on the virtualized machine but appear as if they're running on the user's desktop like local applications. The apps have their own taskbar entry and can be resized and moved across monitors. Ideal for deploying and managing key applications in the secure, remote environment while allowing users to work from and customize their own desktops.

For environments where cost-effectiveness is crucial and you want to extend the benefits of deploying full desktops in a session-based virtualization environment, you can use MultiPoint Services to deliver the best value.

App-v Remote Desktop Services Rds Client

With these options and configurations, you have the flexibility to deploy the desktops and applications your users need in a remote, secure, and cost-effective fashion.

Deploy Your Remote Desktop Environment | Microsoft Docs

Next steps

Remote Desktop Server Setup

Here are some next steps to help you get a better understanding of RDS and even start deploying your own environment:

• Understand the supported configurations for RDS with the various Windows and Windows Server versions
• Plan and design an RDS environment to accommodate various requirements, such as high availability and multi-factor authentication.
• Review the Remote Desktop Services architecture models that work best for your desired environment.
• Start to deploy your RDS environment with ARM and Azure Marketplace.