Tag Archive: dynamics


The official System Requirements for Microsoft Dynamics GP 2018 document from Microsoft does not give Network requirements. So some companies may forget to ask or be tempted to think it doesn’t matter.

In fact, you must be aware that:

Dynamics GP is supported only when client and SQL databases are on the same Local Area Network (LAN).

Wide Area Networks (WAN), Virtual Private Networks (VPN), or any other variant is not supported and will cause at minimum poor performance, and at worst corrupted data.

A minimum of 1GBps LAN is required for normal GP performance.  This also means that notebook users should be discouraged from using Wi-Fi to run Dynamics GP.  CAT5 cabling is the minimum acceptable connection.

If you have a mix of speeds with LAN and WAN/VPN users, it gets even scarier.  Dynamics GP tags each transaction with a Dex Row ID and that next number is reserved until the transaction is complete.  If you have a local (fast connection) client and a remote (slow connection) client processing orders simultaneously, there is a possibility that these IDs could be assigned to the wrong transaction depending on whose transaction completes faster, which would corrupt the transaction.  That is a very simplified layman’s description but should serve to show the importance.

As faster internet speeds become more cost-effective it gets more tempting to put space between client and servers or put the SQL server in a data center, but even if your network card says 1Gbps, it is not going to achieve that speed over a lossy WAN or VPN with a likely maximum of 50-200Mbps.

  • If you are implementing Microsoft Dynamics GP for the first time, make sure you review the system AND network requirements carefully.
  • If you are already running Microsoft Dynamics GP and you are thinking of making a change to your network make sure you contact your Dynamics GP Partner to review your plans BEFORE making any changes.

Additional resources:

short article on the problem of running database applications over WAN. Terminal Services is one solution when users and the database(s) reside in different locations.  The Dynamics GP Web Client is another solution, but still requires a second collocated server for the underlying GP Client, IIS, and connection management database.

This article by Dave Musgrave is the best explanation on the subject of WAN ODBC communications.

“You do not have permission to open this file.”  This error is always, always, always in reference to insufficient permissions on a shared folder or file, usually a forms or reports dictionary.  This behavior could happen when users are forcibly disconnected from a network resource, or unsynchronized AD Catalog Server permissions are accessed causing a conflict in access rights.  We usually see it when a new GP user has not been granted sufficient rights (Read/Write/Modify) in the shared file area (usually GPShare).  This issue may also present itself as an “Unknown Dictionary Error” if it appears prior to SQL login.
The GP launch chain of events is as follows:
  1. GP opens with Dynamics.exe calling business logic dictionaries listed in the Dynamics.set file.  Some of these paths may be on a different server.  No SQL connection is attempted, requested, or required at this point.
    1. If all dictionaries are accessible and open for read/write operations,  the application launch proceeds to validate the SQL user.  If dictionaries do not have proper permissions or are inaccessible, the login fails with the “You do not have permission to open this file” error.  Note that depending on domain file sharing policies, if a terminal server still shows the user running a copy of Dynamics.exe, a domain group policy may deny the user access to a second copy of the file, which would yield the same error since access would be specifically denied.
  2. Once Dynamics.exe loads all the logic specified by the SET file, the SQL login screen opens for the user.
  3. Data is provided by the SQL Server databases, and windows are loaded from the logic dictionaries mentioned in #1 above.
  4. To finish the operations scenario, GP transactions are client/server, with GP requesting as much data as necessary to satisfy the query which is then processed on either client or server depending on the transaction.  This is done through many ‘top 25’ queries until the desired data has been received to guard against large blocks of data transmitting at one time possibly overloading the network.  This constant request for data and the validations against it are the reason that server and client must reside on the same LAN.

GP & SQL Compatibility

I replied to a GPUG question earlier today from someone wanting to use SQL 2016 with GP 2015.  It bears repeating here and applies to similar situations as well.

When Microsoft says not compatible, they mean it. It may work, but it’s not supported. If you do run into an issue with compatibility down the road, you have just burned all bridges, since you won’t likely be able to restore it later to a supported SQL version. At that point you can only hope that you’ve kept a copy of databases from the earlier SQL version and reenter everything from that point, or start over. It’s usually a deprecated function is specified in GP coding that will be the problem, and the only fix is to rewrite the software.

For years I was the “Damn the torpedoes, full speed ahead” guy, the one that could always trick the system into making it work after a client broke it, but after seeing the destruction and mayhem it can cause down the road (read potentially hundreds of consulting hours), it’s wise to trust Microsoft’s compatibility list. It’s there for a reason.

It should have been an easy upgrade…  Dynamics GP 9.0 to GP 11.0, but I needed to get 9.0 to latest Service Pack to run the GP 11 (2010) upgrade.  It would not install, so I turned off DEP, turned off UAC, it still failed.  I even pulled out my bag of tricks, copied the server-side folder to a workstation replacing the existing GP (after zipping the original folder).  It updated the application, but there was nothing in Utilities to allow me to update the databases.

Since Microsoft no longer supports GP 9.0, KB searches came up empty, but in researching, I came across a Blog entry referring to updating .NET 1.1 Framework to SP1 and also referenced a non-existent KB.  I downloaded and updated .NET to SP1, accepting the warning that it had compatibility issues with Server 2008, and it completed the framework install successfully.  I re-launched the GP 9 MSP, and IT RAN!

Hopefully this helps others in this situation.

Do you find that each time you log into Management Reporter on Terminal Server or Citrix, you need to re-enter your login and default company?  The reason those are lost between sessions is that their user profiles are set up to delete temporary files and folders on exit.  This unfortunately is where Management Reporter coders chose to put the configuration files that hold that information from session to session. Making the issue more difficult is the fact that Management Reporter coding requires a SQL user login per company, so it’s not a single sign on as it was in FRx.

Constantly adding your login information can be quite frustrating.  We and a number of others have asked Microsoft to change the location of the user configuration file to a different location.  The request is pending.

However, we can tell you how to change the settings so that deleting temporary files and folders on exit is turned off.  (Note: It actually needs to be that way for GP in the event a user is posting and the connection to the Terminal Server drops.  If the session is left running on the Terminal Server, the posting will continue normally.  If the setting to delete is enforced, the session is forcibly closed resulting in a hung posting or data corruption.)

The environmental variables that hold the MR settings are %APPDATA% and %LOCALAPPDATA%.  Some GP functionality also depends on these variables.  User accounts should have the ability to read and write to these variables and they should be retained, not deleted.  On a Windows 7 workstation those variables point to c:\users\User_Name\AppData and \AppData\Local.  In a roaming profile frequently used for Terminal Server\Citrix users, these variables may reside on a completely different server, requiring cross-server security changes.

Bottom line, it’s not an easy fix.  But it can be done. And it is one of this things that will make your users very happy.

Originally posted on http://www.erpsoftwareblog.com/2012/07/management-reporter-tip-how-to-maintain-logins-and-default-company-settings-between-sessions/

This relates immediately to a server install I was performing, but is something to keep in mind.
1. Don’t try to use SSRS (SQL Server Reporting Services) Reports in GP if SQL is an Express version of 2005, 2008, or 2012. According to GP 2010 System Requirements, SQL Express is supported for everything but Analysis Cubes. I spent too much time trying to get it to work until I came across a Blog post flatly stating that it does not work. Even running GP as a local administrator and logged in with the SQL sa account, I continued to get the error that I did not have permission to install to that location. I did set security in the Reports Site Settings (you need to run IE as administrator the first time to add yourself), gave our user, domain admins, and domain users full access to everything, then repeated the permission settings for folder security. I even went so far as to set security permissions on the file folder structure in Windows Explorer – same error. As I stated, the Blog post was sufficient to put a halt to my efforts.
2. The client wanted to use SQL 2012, which for GP2010SP3 supports. However, Management Reporter would not validate on SQL 2012 to allow creation of the databases. In this case, Management Reporter System Requirements DO state SQL 2005 or 2008 are supported, with no mention of 2012.

One additional note – You will have little or no trouble installing Management Reporter Server components if you download and pre-install the Access 2010 Runtime and Access Runtime SP1 from Microsoft Downloads. If you don’t run those first, setup will hang on the MR Server configuration windows. If it’s a 64-bit OS, install 64-bit Access Runtime and SP. If Office 32-bit is installed on the server, you cannot just run the 32-bit Access Runtime install, because it senses a mismatch between the Windows Server and Office platforms. The only option is to uninstall MSOffice 32-bit and then install the 64-bit Access Runtime. You will then need to install Office (Word, Excel) as 64-bit.