How Microsoft Dynamics GP’s 3-tier Architecture Deployment Can Resolve Performance Issues

Most Microsoft Dynamics GP installations are scripted as follow: Microsoft SQL Server is installed on the designated database server; the Dynamics GP server client application is installed and all company database objects are created on the database server; user workstations are installed and configured. In addition, standard database and application maintenance procedures are put in place, and may even go as far as setting up a few database and application maintenance plans to address regular maintenance operations.

After a few months of production deployment and intense transaction processing, you call back your Microsoft partner with the all too familiar "my system is acting very slow!" concern. During the following weeks, your DBA spends time -- he does not have -- with your Microsoft partner chasing down what seems to be an ever-growing problem with an all-too-distant solution. At the end of those two or three weeks, you are still where you began with still a slow system, notwithstanding  the typical "you need more processors" or you "need more memory" suggestions to improve performance. Then you ask, "What else could we have done?"

The answer to that last question from my point of view is... a lot more! The above sets the stage for the focus of this article.

Much of what I do revolves around remediation, and not always of failed implementations. I must admit, the majority of Microsoft partners will do a very good job in advising their customers. However, it's a fact of life that challenges experienced in a production environment will never be equal to those experienced during the systems implementation phase. The reason is simple: transaction processing loads are not the same. This is the reason why Microsoft Dynamics GP was also conceived ...