A while ago, I wrote a post: Why can't I run Microsoft Dynamics GP via ODBC over a WAN? which discussed the reasons why Microsoft Dynamics GP will not work well when trying to use an ODBC (Open Data Base Connectivity) connection over a WAN (Wide Area Network). The post mentioned that the only support method for running Microsoft Dynamics GP in a WAN environment was by using Terminal Server.

With Terminal Server and its clients, all the processing is performed on the Terminal Server. The only processing handled on the client is drawing the screen and communicating with the Terminal Server. The communication between the Terminal Server and the client is just the screen data to be displayed and the keyboard and mouse inputs back to the server. If the Terminal Server is slow, processing will be slow and screen refreshing might be affected. If the connection between the Terminal Server and the client is slow, processing will be fast and only the screen refreshing will be slow.

Note: Citrix sits on top of Terminal Server and provides additional functionality. So when Terminal Server is discussed it refers to both Terminal Server with and without Citrix.

Today, I want to discuss some generic troubleshooting steps for when there are performance issues on a Wide Area Network. These steps are not product specific and could be applied to any system using a similar configuration.

The diagram below represents a simple system with the following components:

• A SQL Server (SQL) (with the Dynamics Application installed on it).
   
• A Terminal Server (TS) (with the Dynamics Application installed on it).
   
• Both servers are connected via a LAN (Local Area Network) (100Mbps/1000Mbps) connection.
   
• Also on this LAN there are two types of client machines: A LAN Workstation (with the Dynamics Application installed on it), and a LAN TS Client (which connects to the Terminal Server to run the Dynamics Application).
   
• Then there is some sort of Router device connecting the LAN to the WAN (Wide Area Network).
   
• The WAN could be a dedicated line or a VPN (Virtual Private Network) over the Internet.
   
• Finally, connecting via the WAN is a WAN TS Client (which also connects to the Terminal Server to run the Dynamics Application).

When there are performance issues being seen by the WAN TS Client, there are some generic troubleshoot steps to narrow down where the bottleneck is and therefore where the effort needs to be focused.

Let's walk through the points to check:

1. On the SQL Server, run the application and test if the performance is slow. Test both when the SQL Server is under load and not under load.
   
   If the SQL Server is not under load and the application is slow, there could be an issue with how the application is coded that makes it inefficient or the task is just really big.
   
   If the SQL Server is under load and the application is slow, it could be that the SQL Server is overloaded or not running at peak efficiency. You'll need to look at CPU, memory and hard drive usage.
   
   If the application runs fine on the SQL Server, continue to next step.
   
   
2. On Terminal Server, run the application and test if the performance is slow. Test both when no additional users are on the server and when many users are active.
   
   If the Terminal Server only has one user and the application is slow, there could be an issue with the LAN connection between the two servers.
   
   If the Terminal Server has many users active and the application is slow, it could be that the Terminal Server is overloaded. You'll need to look at CPU, memory and hard drive usage.
   
   If the application runs fine on the Terminal Server, continue to next step.
   
   
3. On the LAN Workstation, run the application and test if the performance is slow.
   
   If the application is slow, it could be an issue with the LAN connection, application configuration (eg. shared dictionaries on LAN), or the Workstation is underpowered.
   
   If the application runs fine on the LAN Workstation, continue to next step.
   
   
4. On the LAN TS Client, run the application and test if the performance is slow. Test both with lots of screen updating and with lots of processing.
   
   If the application is slow for activities with lots of screen updating, it could be an issue with LAN connection.
   
   If the application is slow for activities with lots of processing, it could be an issue with the performance of the Terminal Server.
   
   If the application runs fine on the LAN TS Client, continue to next step.
   
   
5. On the WAN TS Client, run the application and test if the performance is slow. Test both with lots of screen updating and with lots of processing. Also Test with both only one user connected via the WAN and with many users connected.
   
   If the application is slow for activities with lots of screen updating with one user, it could be an issue with WAN connection.
   
   If the application is slow for activities with lots of processing with one user, it could be an issue with the performance of the Terminal Server.
   
   If the application is slow for activities with lots of screen updating with many users active, the issue is very likely to be bandwidth on the WAN connection.
   
   If the application is slow for activities with lots of processing with many users active, the issue is very likely to be that the Terminal Server is underpowered for the number of users.
    

If there is a problem with the WAN connection it could be related to latency (how fast data travels), bandwidth (how much data travels) or quality (how much data is corrupted or lost). Also with a WAN connection you need to have a look at how much bandwidth you have and what is using it.

If there are other processes using the WAN bandwidth there might not be enough left to service the WAN TS Clients (once divided by the number of clients). For example: copying large files across the WAN will use a lot of bandwidth. Use of the WAN for VOIP (Voice Over IP) communications will not only use a lot of bandwidth, but VOIP packets also have priority over data packets when transmitted.

Printing of large reports using a Terminal Server when the report is printed to printer on the other side of the WAN connection can use lots of bandwidth. Another activity that can cause heavy bandwidth usage is streaming of audio or video.... no more listening to Internet radio all day.

If the WAN performance issue occurs at specific times, then check if any automated backups or file copying is occurring at the same time.

Note: One other issue to look at for a WAN environment is the location of the User Profile and Home Drive for a user. If the User Profile and/or Home Drive for a user is stored on the other side of a WAN connection, slow performance accessing the User Profile and/or Home Drive is very likely.

An excellent reference for performance issues is the Microsoft Dynamics GP 2010 Performance Whitepaper:

• Optimizing and Maintaining Performance for Microsoft Dynamics GP 2010 (PartnerSource)
• Optimizing and Maintaining Performance for Microsoft Dynamics GP 2010 (CustomerSource)

This post is designed to help you diagnose where the bottleneck is. Once you known where to investigate, work with the appropriate professionals to get the issue resolved.

David