Performance problems are unique from a Microsoft support perspective, in that they are generally not a typical break/fix issue.  We do not handle performance cases the same way as Break-Fix cases, and Performance cases are not troubleshot and left open until resolution. We can spend about 30 minutes reviewing your issue, but if in-depth troubleshooting, review of your environment, or analysis of logs is required, you will need to proceed in an hourly billable consulting service. The support case would still be chargeable at this point. 

 

It is important to note that in order to troubleshoot performance, we first need to define what "normal" performance would look like in the environment.  In order to do that, we would need to test with a fresh installation of Dynamics GP with no 3rd party products.  Then, we can use that performance testing as a baseline comparison for what the user is experiencing.

 

Once you have established a baseline for comparison, you can then install a 3rd party product and test after it is added.  If the performance remains the same, then you can move on to the next 3rd party product until/if a performance issue occurs.

 

If the performance issue still occurs even with a fresh installation (no 3rd party products or customizations), then you would need to continue troubleshooting by reviewing a dexsql.log, Process Monitor logs, etc. in the fresh baseline test installation.

 

If not, then you can focus on items specific to performance on a Terminal Server.

 

Please take the following into consideration per https://support.microsoft.com/en-us/help/872242/how-to-deploy-microsoft-dynamics-gp-and-microsoft-business-solutions-g  :    

 

"Microsoft Product Support Services supports the default configuration for Microsoft Dynamics GP. In this configuration, remote workstations start Microsoft Dynamics GP from the installation folder that is located on the terminal server. Remote workstations do not use user profiles or roaming profiles for the Dex.ini file or for the Dynamics.set file. Instead, remote workstations use the same Dex.ini and Dynamics.set files that are located in the installation folder."

 

"Do not use the local hard disk on the remote workstations for the placement of the Dex.ini file or of the Dynamics.set file. This configuration will create performance issues.

 

Notes

 

Many Microsoft Dynamics GP processes read back to the Dex.ini file.

 

Put the Dynamics.set file and all dictionary files that are listed in the Dynamics.set file onto the server that is running Terminal Server."

 

 

In other words, it is not supported to have the dex.ini, Dynamics.SET or any dictionary files that are listed in the Dynamics.set file in a location other than the installation folder ("C:\Program Files (x86)\Microsoft Dyamics\GP2018") when using Dynamics GP in a terminal server environment, and has been found to cause performance issues.

 

So in addition to using a fresh GP installation (you can still use the same databases) with no 3rd party products, we will also need to have local copies of the above files in the baseline test. 

 

There is functionality in Microsoft Dynamics GP 2013 or later, for administration of the dex.ini in a Remote Desktop Services (aka Terminal Server/Citrix) environment that would be recommended over making the dex.ini read-only or putting it at a shared location:

 

1. The first change is saving the per-user dex.ini settings to the GP system database instead of the dex.ini file used to launch the application. Using this functionality will keep each user from overwriting other user's settings in a shared dex.ini. In this configuration when GP is launched, the dex.ini file in the installations data folder is used to get the configuration information required before connecting to the GP system database. (i.e. data source, pathname, etc.) Once the user has connected to the GP system database, the per-user dex.ini settings for the GP user are read from the database and used.


(Details are that a per-user dex.ini is created with the persisted settings from the database and then used for the session, upon closing the session the current settings are persisted back to the database for future logins.)

This functionality is used by default for the GP web client, but must be manually enabled for desktop client installations. To enable this functionality, add theEnablePerUserIni=TRUE line to the installation folder's dex.ini file. (available in GP 2013 and later)


2. The second change is to not default in the last SQL user name by adding theDefaultLastUser=FALSE line in the installation folder's dex.ini file. (available in GP 2013 SP1 and later)

 

3. The third change is to disable the Server drop down field on the GP login window. In this case the Server field will default to the ODBC data source specified in the installation folder's dex.ini and can't be changed. This would typically be used if you have multiple data sources on the computer and don't want the user to use any of the other data sources. To enable this functionality, add theEnableServerDropDown=FALSE line to the installation folder's dex.ini. (available in GP 2013 SP1 and later)

 

Another item to note is that we have seen a handful of cases with performance issues when generating a Report Writer report in GP with Terminal Server and in the destination, choosing a ‘redirected’ local drive through the RDP session itself:

 

 

 

When saving to this redirected drive, the report generation is very slow.

When saving to the local file system or printing to screen, this happens at normal speed.

 

The issue here is that between Server 2008 and Server 2012, Remote Desktop Services underwent a complete rewrite and recode from the ground up. With this re-coding, many features changed and the overall RDP stack changed quite a bit. When you create a connection to that redirected drive in Server 2012, that connection routes through your user profile, rather than through a standard “network drive” type of connection, so any type of read-write operations to this redirected drive are going to be much slower than a read-write to a mapped drive or a UNC path of some kind. If you look at a network trace of this operation, you’ll see GP open an SMB connection to this location and try to hold it open for the duration of the report generation.

 

The only real workaround to this issue is to save the report to file on the file system of the RDP server, so somewhere like the desktop of the user profile, and then once the report is done processing, copy the entire report to the redirected drive or mapped drive. The performance slowdown specifically happens because upon running the Report Writer report, GP opens up a connection to the report destination, and holds this connection open throughout the entire report generation process. When the throughput to the destination is limited, this simply causes the entire process to take longer, as each set of ‘report generation’ code must wait for this slower redirected drive to responds.

 

If the user still experiences performance issues after all of the items as explained above, then we will need to follow the recommendations in the Performance White Paper:

https://mbs.microsoft.com/customersource/northamerica/GP/learning/documentation/white-papers/MDGP2010_WhitePaper_Performance  

Note the following from the Performance White Paper:

Terminal Server

Do not limit the amount of time that active, disconnected, and idle (without user input) sessions allowed on the server. It is important to leave any active Microsoft Dynamics GP clients running remotely intact. Data corruption can occur if Microsoft Dynamics GP is abruptly shut down as several windows have code on the window close event to complete data processing. Refer to the article below for more information regarding Terminal Server timeout and reconnection settings:

Configure Timeout and Reconnection Settings for Terminal Services Sessions
http://technet.microsoft.com/en-us/library/cc754272(WS.10).aspx

Microsoft Dynamics GP performance can be adversely affected if the user’s profile is setup to use a Home Path pointed to a network share, especially on network shares with slow connection speeds between the client workstation and the shared folder.

 

There are other Terminal Server specific items (and overall performance items) in the White Paper, so we still recommend reviewing the entire document when troubleshooting.