Until a Dynamics GP web client becomes a reality—and perhaps even beyond its arrival—there will be a need for remote access to Dynamics GP through a thin client application such as Remote Desktop. Windows Remote Desktop Services (formerly known as Terminal Services) is a session-virtualization tool that allows interaction with remote applications, providing a reliable and responsive user experience that would otherwise be impossible. Though Internet connection speeds have increased exponentially in recent years, applications not specifically designed to be Internet-enabled typically don’t perform well over Wide Area Network (WAN) connections. Part of this is application design, but the general problem is latency—the amount of time it takes for data to travel between two points—and is affected by unavoidable network delays.
The route data must travel from your Dynamics GP SQL Server, and your GP client is largely out of your control when you’re on a WAN connection. It likely doesn’t provide a very good user experience. Remote Desktop Services (RDS) addresses this problem.
RDS is included with Windows Server 2008 R2 and is available as Terminal Services in versions of Windows Server as far back as Windows NT 4.0. This post addresses this feature in Windows Server 2008 R2, but nearly all of the concepts are generally applicable to earlier versions.
Adding the Remote Desktop Services Role
There are two easy ways to add the RDS role: from the Initial Configuration Tasks page or from Server Manager.
The Add Roles Wizard guides you through the process of adding RDS.
Select the “Remote Desktop Services” role.
You will need to at least install the Remote Desktop Session Host (RDS) service. Windows Server 2008 R2 also supports advanced features that may or may not be applicable to your environment and are beyond the scope of this post.
Ideally, you should install RDS before you install Dynamics GP, because Windows will handle application installation differently on a server with RDS and will enable those applications to run correctly in a multiuser environment. If you experience issues with applications installed prior to RDS, reinstalling them may resolve those issues.
Without addressing too many technical details about Network Level Authentication (NLA), you will generally not encounter compatibility issues if all of the clients connecting to the server are running the latest Remote Desktop Client version. If you have users with an older RDC that cannot be upgraded or you are uncertain how users might be connecting, you may need to disable the NLA requirement.
Although it’s relatively easy to install RDS, keep in mind you are required to purchase the appropriate Client Access Licenses for devices or users accessing the server. This screen lets you choose the type of licensing you’d like to use. You can use RDS for 120 days before you are required to provide licenses, but you will need to set up a Remote Desktop license server.
You can specify which users will have access to the RD Session Host at any time. I would recommend spending time planning for user access so you can enter that information here, but as part of ongoing administration, you will need to be able to do it later. User administration is discussed below.
You can provide a richer client experience for the user by enabling audio and video playback or the Windows Aero interface. However, all of these features increase system resource and bandwidth usage, limiting how many users can use the server. If the only application being shared on this server is Dynamics GP, you will not need to give your users any of the additional RDS client features.
You will be able to review installation selections before committing them.
You may be required to restart your server after installation. In the next post, we will continue the process of configuring users.
For more information about using RDS with Microsoft Dynamics GP, please contact our support center at firstname.lastname@example.org.