Microsoft Dynamics AX Configuration for Production

As we all are comfortable in setting up Microsoft Dynamics AX VM’s server since all the components are on single OS.

Normally we need to Plan our Microsoft Dynamics AX (TEST, UAT and Training Environments)

Let’s get started with Microsoft Dynamics AX Production Environment (PROD)

Make sure your AX environment is properly configured for a production environment.

This means SQL, AOS, SSRS, SharePoint, and Terminal Servers (TS) are properly set up.

Some specific notes:

•Verify your SQL Configuration – http://technet.microsoft.com/en-us/library/dd309734.aspx

•For your AOS, make sure debugging is not enabled, hot swapping is not enabled, X++ and CIL compile without error.

•If you are running on Virtualized hardware make sure to follow Microsoft/VMWare best practices for configuration.

•Latest available patches are installed.

If you are not yet live, and have some Visual Studio experience on staff, I highly recommend using the Benchmark Toolkit – http://www.microsoft.com/en-us/download/details.aspx?id=39082 to simulate a full load on your system. Additionally, make sure to test your Terminal/Citrix servers at full load.

If any of your infrastructure is Virtualized pay close attention to CPU load, I/O, RAM and Network.

Finding the bottleneck

The main idea here is that you are in production and are seeing problems and are looking for the current bottleneck.  Here is the path I use to find the issue:

Is the issue being seen by one user or multiple users?

•Multiple users:

1.Check SQL for Blocking/Locking, RAM, CPU, Disk Space and Disk utilization. 

There are many good packages to monitor SQL and your DBA should be monitoring this, however many companies don\’t have dedicated resources for this.  I always check here first.  For RAM and CPU issues, those should be easy to address.  Running out of disk space happens, make sure to check it.  For disk utilization – that one is complex depending on your setup.  If you are seeing locking/blocking regularly I recommend two things – first, make sure that nothing is running from a SQL standpoint (Backup, Maintenance, etc.).

Second, use the Dynamics Performance analyzer to determine the source – http://archive.msdn.microsoft.com/DynamicsPerf.

Lastly, check to make sure that any users have access to the SQL server are not running expensive queries. As a general rule, make sure that no one have ODBC access to your production database.

2.Check the AOS server(s). Look at RAM, CPU and Disk Space.  You should regularly be monitoring the RAM usage of the AOS service to determine what is normal for your environment. If overloaded, an AOS restart will fix the problem but Root Cause Analysis (RCA) analysis will be required.  If you are regularly seeing Memory issues, check your buffer settings are appropriate, check to make sure that a table caching is appropriate for the number of records in the tables. It is possible the settings from go-live are no longer appropriate based on record growth.

3.Terminal/Citrix – Look for CPU/RAM/Hard Disk issues. Check the number of users or maybe other applications on the servers are eating up the system resources.

4.SSRS – Check CPU/RAM/Hard Disk.  The service restarts regularly and can slow report processing down.  Here is a tool to make sure they keep running fast – http://blogs.msdn.com/b/axsupport/archive/2014/03/11/ax-content-warm-up-those-ssrs-servers.aspx

5.Check batch processing in AX – are there new batch processes which are using a lot of resources?

6.Check infrastructure – Network, Switches, etc.

7.Client issues – Are patches being applied or recently applied? Is a weekly virus scan running?

8.Is it month end or year end? The month end process involves a lot of intensive reports and processes. Can you move any of these to low activity times via batch processing?

•Single User:

1.What was the user doing in AX? Did they trigger a long running process? Have they recently closed AX via CTRL-ALT-DEL and are now trying the same process they were doing before? This can cause SQL issues. If not, see if you can replicate the issue in a test environment and determine via profiling what the issue is.

2.Like above, check the Terminal Server, Infrastructure, Patching and AV scans.

Note: If your system recently restarted, there can be a significant warm-up time to rebuild the cache.

Prevention

Code can cause many issues from too many database calls, poor use of indexes, over complexity.

Code needs to be performance tested.  The AX trace parser and tracing cockpit are very effective at finding the issue. 

•        http://blogs.msdn.com/b/axperf/archive/2011/08/15/walk-through-major-features-of-microsoft-dynamics-ax-2012.aspx

•        http://junctionsolutions.com/blogjuice/dynamics-ax-2012-trace-parser-setup/

SQL:

•Check the server and logs every day.

•Have a maintenance solution that updates the statistics daily (index fragmentation is not the be all and end all of performance – http://blogs.msdn.com/b/axinthefield/archive/2013/10/03/dynamics-ax-index-fragmentation-and-you.aspx)

•Make sure your indexes are appropriate. Both adding missing indexes and disabling indexes you do not use.

•Check max degree of parallelism is set to 1.

•Check growth rate of data file and logs – should be a set size
, usually between 200 and 500 MB.

Client:

•Client performance settings – http://blogs.msdn.com/b/axperf/archive/2011/11/07/ax2012-client-performance-options.aspx

•Database logging – this causes significant overhead and every setting should be scrutinized that the loss in performance is made up with the data.

AOS:

• Make sure that the AOS is periodically restarted.

• Make sure that the clients have the same kernel version as the AOS.

• Check Number Sequence allocations – http://blogs.msdn.com/b/axinthefield/archive/2011/06/12/determining-number-sequence-consumption-rates.aspx

•Check batch processing has enough power.