UA-44032151-3 page contents

Top 10 issues raised from Infrastructure Design Review


The Microsoft Premier Field Engineer team helps customer to proactively secure their Dynamics AX 2012 deployment with the Infrastructure Design Review. This service focus on hardware and software requirements to meet business needs. The assessment can help customer to secure the implementation phase for new installation, but also to anticipate increase of workload and user adoption.

Here are the top 10 issues gathered from Dynamics AX 2012 review delivered over the last year.

1. No High Availability for SQL Server database

It is quite difficult to understand this but in several occasions, no true High Availability is planned for the SQL Server instance hosting the Dynamics AX databases (OLTP and model). Sometimes hosting partner takes full ownership of this task and assume Geo-Clustering with disk mirroring on SAN layer will automatically guarantee no data loss. Geo-Clustering is a great option indeed but a Failover solution must be set up on the SQL Server instance for the Recovery strategy. With SQL Server 2012, you can leverage the Always On Availability Group to synchronize the primary instance to up to four secondary Replicas.

The recommended availability mode for OLTP database is Asynchronous for High performance, even though with this mode, you need to manually take care of the failover policy.

Please note that from SQL Server 2012, TempDB is now supported on local drive which gives you the opportunity to store TempDB files on Solid State Drives. This can improves performance for I/O access to TempDB and avoid any contention. The failover between Availability Groups should be transparent to the Application Object Server Service. However all transactions using TempDB may not be committed during Failover hence unexpected errors. Please check this blog article for details and update on this topic moving forward.

2. Oversize AOS Server resources

Microsoft Dynamics AX 2012 Application Object Server (AOS) is a native x64 application that can scale up to 64 CPU cores and use all the available memory. However, when using software virtualization, we prefer to limit the number of CPU cores per virtual machine (VM) to 8 and physical memory to 16 GB.

This template can be applied to all VM with one AX instance per VM and up to 150 users per instance. This is not a real limit but rather a best practice. Having proper monitoring in place prior to Go Live will help you understand the resources consumed by your AOS instance.

Note: Virtualization is indeed a strong recommendation because it helps to reduce maintenance cost and allow ore High Availability options. Regarding virtualization, you can access here the the detailed list of all supported vendor with Microsoft Windows Server.

3. Remote Desktop Servers: Scale Up vs. Scale Out

The key factor to size the Remote Desktop Server (RDS) is the memory usage consumed by all applications. The memory consumed by each AX session really depends on the usage and the customization. Different tests show that a standard Microsoft Dynamics AX client session will take from 100 to 250 MB of memory depending on the client configuration settings.  With other applications associated to Dynamics AX client, like Excel, Word and Internet Explorer, we can estimate an average of 300 MB consumed on average per AX Session.

With 2 GB allocated to the Operating System, you can then size the memory required per RDS server and estimate how many AX session can run simultaneously. At this point, you have two options for RDS scalability:
-       Scale Up: increase resources allocated per RDS server to host more AX sessions
-       Scale Out: multiply the number of server roles in the RDS farm.
The advantage of the Scale Out option is that more RDS server will be able to take over the additional workload if one RDS is no available.

4.    No Load balancing for AOS WCF Services

The AOS native clustering solution affects only the Remote Procedure Call (RPC)-based connections and does not let you load balance Microsoft Dynamics AX Windows Communication Foundation (WCF) services. To achieve scale and redundancy, you can configure AOS servers to use Windows Server Network Load Balancing (NLB) for Microsoft Dynamics AX WCFservices, especially for Reporting Services and Office Add-Ins.

It is also strongly recommended to monitor all AOS instances to correct the NLB configuration if one AOS instance is becoming unavailable. You can use System Center Operations Manager (SCOM). To configure NLB you have to follow this TechNet article.

5. Compatibility issues against Microsoft software

When reviewing the whole Dynamics Ax platform, one of the key requirement is to make sure every component is officially supported on every server role. That includes the whole Microsoft stack like Windows Server, SQL Server and SharePoint Server, but also the ISV solution and the different interfaces (Print Server, Web server, custom Retail, EDI interfaces…).

Because Microsoft product team run supportability test every quarter for in-market releases of Dynamics AX, you should regularly read the System Requirements for AX 4, AX 2009 and AX 2012 and subscribe the In-Market release blog. For example, as of today, the following products are only supported from AX 2012 R3: SharePoint 2013 Server with Service Pack 1, SQL Server 2014 and Windows Server 2012 R2.

You can also read the matrix of compatibility certification information from Partner Source.

6. Localization from Dynamics AX 2012 SYS layer

One of the main benefit of Dynamics AX 2012 is the possibility to have one single worldwide instance thanks to the extended localization support in the standard SYS layer. To find information on country localization coverage at feature level and across multiple versions, you can access the Localization Portal. This portal lists real time information for coverage of 35 countries. If the country you are looking for is not supported, you should contact local Partner to extend the localization specific to the market need.

For Pros and Cons on one single WW instance vs. regional instance, you can read this blog post written for Dynamics AX 2009 but still mainly relevant for Dynamics AX 2012.

7. No real estimation of user concurrency

One of the great benefit of Lifecycle Services is the Usage Profiler tool. Thanks to the tool, you can have a graphical representation of the user concurrency. This is very important when you have multiple remote site across multiple time zones and lot of different Batch Scheduling. This tool will help you estimate the peak of rich users and the maintenance windows at night or during the week end.

Here is an example with multiple time zones and batches. The goal is really to find the best ratio between peak of users and transactions and avoid oversizing the Dynamics AX servers, resulting in unused hardware and increase of total cost of ownership (TCO)


8. No strategic plan for long term topology

Before taking into decision regarding the future Dynamics AX infrastructure, it is necessary to draw the topology of all servers that will be in the scope of the solution. By listing all server roles, you will be able to simulate different clustering options based on the sizing requirement, as well as mitigate the cost of licensing and hardware for every roles. The following table is an example of one Dynamics AX topology:

Server in Production Nb of Server RAM (GB) V-CPU
SQL for AX data and models

1

32

16

SQL for SSRS and SSAS

1

32

16

AOS for AX Rich users

X

16

8

AOS for Batch, Workflow, AIF

X

16

8

SharePoint Server farm with  Help Server

X

8

4

Remote Desktop Server for AX  users

X

16

8

Management Reporter

1

16

4

Total

X

X GB  

 X vCPU 

In an ideal world, you would dedicate one virtual machine to each server role. But to reduce total cost of ownership, without impacting performance, you can try to add multiple roles within one virtual machines if the software requirement allows it, like version of .NET Framework or Windows Server. For example, Help Server requires Internet Information Services (IIS), so you may host it on the SharePoint farm.

No matter what are your choices, we strongly recommend you to dedicate the SQL Server instance for Dynamics AX databases so that tuning (Max Degree of Parallelism, Trace Flag) cannot impact other type of databases (SSRS, SSAS, MR, SP…).

Also Enterprise license is recommended for online index rebuild, for more details on comparing editions, please visit: http://www.microsoft.com/sqlserver/en/us/product-info/compare.aspx

9. Lack of Service Level Agreement

When reviewing the Disaster Recovery Plan (DRP), some customer only consider the Backup strategy of the Dynamics Ax database. But the goal should really to restore the whole Dynamics AX solution so end user can work again.

SLA can be defined with two KPIs: the Recovery Point Objective (RPO) is the maximum amount of data that can be lost and the Recovery Time Objective (RTO) is the amount of time required to restore the SQL Server instance. These two KPIs will help you setting up the right SQL Server Recovery strategy with Full, Transaction and Differential backups for example.

But in reality, every critical components should be part of the DRP with clear Service Level Agreement (SLA). Having the right clustering strategy for AOS and RDS servers will indeed guarantee the High Availability as expected, but you need to consider all other roles as well such as Help Server, Management Reporter, Reporting Services, Internet Information Services.

10. Understand Dynamics AX Servicing

Customer roadmap will not be always aligned with Dynamics Ax release cycle. Once the Dynamics Ax implementation project is started, you need to keep an eye on the upcoming release dates and all features provided.

Product

General Availability

Mainstream Retirement

Extended Retirement

Dynamics AX 2012

25/09/2011 09/10/2018 12/10/2021

Dynamics AX 2012 R2

19/02/2013 09/10/2018 12/10/2021

Dynamics AX 2012 R3

01/08/2014 09/10/2018 12/10/2021

Once you know which major release will be the baseline of your solution, you need to patch the latest Kernel. Please check the following blog article for latest announcement.

Regarding the Application Hot Fixes, since there are not cumulative like the Kernel Hot Fixes, only the Service Pack and Rollup are cumulative. So you need to proactively choose the relevant hot fixes not included in your rollup. You can use the Lifecycle Service Search tool to find the Application Hot Fixes based on the version of Dynamics Ax and keyword.

If you are interested in this service and if you are a Premier customer, you can read the datasheet and contact your Technical Account Manager.

Regards,
@BertrandCaillet

Principal Premier Field Engineer

Comments (5)
  1. Alexander Weurding | PerfXit.nl | PerfXit Group says:

    Great article ! thanks for sharing.

  2. Aijaz Qureshi says:

    Great article!

  3. Bertrand Desmarest says:

    Great post!! Thank you.

  4. Denis Macchinetti says:

    Nice article!

Comments are closed.

Skip to main content