In this blog post, I would like to summarize the best practices to ensure High Availability (HA) for Microsoft Dynamics AX 2012 R3. This has been a critical subject for many customers because Dynamics AX is a mission-critical business application meaning that any downtime impacting end users will result in financial loss.

Business continuity doesn't come for free: it requires additional components, configurations and maintenance. So, before you engage yourself into a complete redesign of your architecture, first define the right level of uptime needed for your application and which service is critical: for example, you can define Dynamics AX client as business critical but not the financial reporting. Service Level Agreement (SLA) can be defined for every scenario and can help you decide the best option to choose from.

Below we are focusing on the database and application layers. However, for the hardware and platform layers, we do recommend virtualization to provide additional capabilities. Also, we are not covering all workloads of the product such as Retail and Enterprise Portal.

1. Operational database High Availability

There are two important Dynamics AX databases: the one hosting the the business data and the one for the code and metadata. Both are critical for the application and must always be available. If the Dynamics AX AOS cannot connect to these databases, it will simply stop running.

Solution: SQL Server AlwaysOn Availability Groups (AOAG). By putting the critical databases in one Availability Group and with the supported Synchronous mode, you allow an automatic failover from the Primary Replicas to the Secondary Replicas. To avoid the Primary Replicas node to be a new single point of failure (SPOF), you should configure one AG Listener as the entry point for all services: Dynamics AX Server Configuration Utility for the Application Object Server (AOS), SQL Server Reporting Services and Management Reporter Service configuration.

Tips: Please also ensure the service account running the AOS services has the right permission to all TempDB databases (Primary and all Secondary replicas).

Limitation: Secondary Replicas are Read only and therefore cannot be used for standard Dynamics AX 2012 Reporting Services. Change Tracking is not allowed on Secondary Replicas so Management Reporter Data Mart, Retail and Entity Store must still point to Primary Replicas databases. However, ad hoc SSRS reports not using the data provider class and standard Dynamics AX 2012 Business Intelligence objects support the Secondary Replicas: you need to create a Read Only Intent on the SQL Listener to route "read only" queries to the Secondary Replicas.

Note: there is a possible performance impact on Dynamics AX when Synchronous mode is used, for example when heavy batch jobs are running (processes like MRP). The scale of this impact depends on how fast the transactions can be committed to the secondary replica so the quality of the connection between Primary and Secondary replica is crucial for best performance.

2. Dynamics AX AOS High Availability

The Dynamics AX clients are connecting to the AOS servers using the Remote Procedure Calls (RPC) protocol. They are connecting to the TCP port (default 2712) of the AOS servers.

Solution: Setup an application Cluster containing all AOS instances in System admin > Setup > System > Cluster configuration. The first AOS in the client configuration utility will load balance all incoming sessions so that same number of sessions are hosted on each AOS of the cluster.

Scenario: when one AOS service is becoming unavailable, the sessions running on that AOS will be stopped automatically but each user will be able to start his client by clicking the same shortcut. The shortcut is calling the Dynamics AX client with the configuration file that contains all AOS included in the cluster.

Tips: You can create a dedicated load balancer AOS to be the single point of contact for new connections. This can be beneficial when there are many Business Connector calls.

3. Dynamics AX Services High Availability

Another communication between Dynamics AX client and AOS are the Windows Communication Foundation (WCF) calls, for example the Reporting Services workload. WCF services are hosted on WSDL port (default 8101) and a service endpoint port (default 8201) on every AOS server. The application load balancer, described in section 2 of this blog, does not include the WCF calls. Therefore all traffic will only be routed to this first AOS instance configured in the cluster, now becoming the SPOF.

Solution: create Windows Network Load Balancing (NLB) cluster with dedicated IP and list of hostnames and IP addresses for AOS. You must then setup the Dynamics AX Client Configuration to point all clients to this NLB. It will route all service clients to all AOS instances defined in the NLB cluster.

Process: first you need to create the NLB, then change the endpoint in the configuration file and refresh the client configuration:

• On each Remote Desktop Host Server, add two values "wcflbservername" (with NLB virtual name) and "wcflbwsdlport" (with WSDL port) in the registry subkeys: SoftwareMicrosoftDynamics6.0Configurationnew_configuration_name for both HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE
• Open the Dynamics AX Client Configuration Utility, open the tab "connection"
• Click "refresh configuration" and restart the AOS. This should modify the WCF.config file and rename the endpoint to reflect the virtual name of the NLB instead of the AOS.Note: You also need to configure this new "Services NLB" for Management Reporter. Open the Configuration Console, click File, Configure and Select "Add Microsoft Dynamics AX 2012 Data Mart". Click Next and replace the AOS Service Port and AOS port (TCP)

Tips: here is a great example of script to automatically remove the failed AOS host instance from the AOS NLB cluster.

4. Operational Reporting High Availability

For Reporter Server Database: you can place them in the SQL AOAG, same as the Report Data Source (Dynamics AX) if you wish. The Secondary Replica must be kept synchronized at deployment time, and always be updated in case of configuration changes (permissions, roles…).

• Limitation: keep in mind the Report Data Source cannot be set to the Read Only Secondary Replicas because standard Dynamics AX reports require a writeback access. Only Ad Hoc SSRS reports can leverage the Secondary Replicas with the Read Only Intent mode.
• Tips: Reporting Services will not automatically use a different replica for the Reporting Services database when failover occurs. A custom script is needed to automatically update the SSRS configuration after the failover.

For Reporting Services: create another a new NLB for the SSRS instances deployed in scale out mode. Deploy the Dynamics AX Reporting Extensions on each Report Server. This implies that in the Dynamics AX application, all AOS must be listed and configured against the new RS NLB under System Administration - Settings - Business Intelligence - Report Servers.

• Tips: Configuring SQL Server Reporting Services scale-out deployment in a Network Load Balancing cluster (White Paper).
• Note: another option is to use one way transactional replication for near real-time reporting. But we don’t recommend it because it requires much more maintenance like choosing tables to be replicated,  and recreating the publication in case of database schema change.

5. Analysis Services High Availability

For the  services: Analysis Services can rely on NLB solution in scale out mode.

For the database: Analysis Services natively supports Windows Server Cluster Service (WSCS) so you also leverage the AlwaysOn Availability Group.

Tips: you can have near real time data without impacting the operational database. Because processing and querying are read-only workloads you can configure the data source connection to use a readable secondary replica.

6. Financial Reporting High Availability

Management Reporter (MR) database: metadata such like report library, building blocks, configuration and generated financial reports. The solution is to change the recovery mode to FULL and add the MR Reporter database to the AlwaysOn Availability Group. If encryption is used, you need to apply the same configuration on the other node to ensure business continuity after failover.

MR Data Mart: when the database becomes unavailable, integration tasks simply fail and new reports cannot be generated. The DataMart can easily be regenerated from the source. If the instance hosting the DataMart is brought back online within three days of failure, the integration tasks will resume and automatically process all the changes and posted data from AX since the failure happened.

MR Application Service: create multiple instances of the Service across servers. When deploying services, specify the existing database created during first installation. Then create an MR NLB cluster for load balancing. To make sure all menu items in the client are launching the Report Designer with the right URL, you need to manually update the value of the MR Configuration Console with the NLB address and then publish the server connection to AX (update hidden field in AX ledger parameters table).

Tips: you can create an SQL script to ensure the right MR configuration is set up in Dynamics AX when SQL failover occurs. You can also use this script to convert the master key for encryption when MR DB fails over.

MR Process Service generate reports and handle integration. You can deploy it to multiple servers. However, the process itself is managed in MR Database and you cannot have duplicate or overlapping tasks within the same instance. There is no Load Balancing available but if one instance goes down, others can pick it up and provide business continuity.

Regards,
@BertrandCaillet
Principal Premier Field Engineer