Innovation vs. Disruption

One common challenge we are facing with large Dynamics AX implementation is the Patching Strategy. Our Premier Mission Critical customers have clearly reiterated the importance of delivering innovation without disrupting their critical business processes. Financial and logistics processes must run continuously, with limited window allowed for system maintenance such as applying application fixes. This is especially true when business is running 24x7 on several time zones across the globe.

At the same time, there is also a strong requirement to keep Production environment stable to conduct performance optimization. So in a world of constant change, the goal is to find the right balance between keeping the product healthy by applying latest code improvement and bug fixing, and making sure the product continues to evolve as well along the customer roadmap. For example, Go Live is often done with few employees and core modules followed by multi year’s world wide roll out with many modules activated such as production and retail.

Product lifecycle

• Service Packs can be considered as major patch levels. Generally speaking it is the product at a certain patch level that forms the minimum supported build for Microsoft support. For Dynamics AX 2012, R2 and R3 can be considered as Service Pack.
• Cumulative Updates are regularly released for Microsoft products and these updates include bug fixes and improvements, however they do not influence the support lifecycle. Cumulative Updates area applied on top of Service Packs, not as a replacement to them. Therefore if you have AX 2012 RTM build, but you want to apply CU7 that was released after R2, you would need to apply R2 and then CU7. If however you are already at R2 level, but you have not applied any CU's, you only need to apply CU7 and not all CU's in order.

Best practices: consider SlipStream for fresh install to speed up the patching process. Slipstreaming places the patch files into the installation media so that they are installed as the new instance is being installed, so that you only run setup once, and you have a fully patched and ready to go instance. It is available from SQL 2008 SP2 and AX 2012 RTM. Below is a dynamic list of the latest build available for each version of Dynamics AX:

• Servicing Windows: Review all windows security patches bi-weekly and push update accordingly. Service pack and major update need to be tested before applying to production. These patches shouldn’t impact AOS however it is recommended to first run sanity check on User Acceptance Test (UAT) environment. Any major update (.Net Framework and Windows SP) may impact system so we should put in place a control windows update using Windows Server Update Service for all servers in Production. You can leverage the Service Update Management to improve business operations and decrease incidents while quickly and efficiently deploying software updates.

• Servicing SQL Server: Our recommendation is always to keep the build up to date in regards to the latest CU available of the latest Service Pack officially supported. Here is a great blog to find all released CU for every SQL Build. For example, as of today, August 22nd of 2014, SP2 is not yet officially supported with AX 2012. . Also please note lifecycle of SQL Server 2008 is now in extended support since July 2014 and that Windows Server 2008 and Visual Studio 2010 mainstream support will end in January 2015.

• Dynamics AX Lifecycle: Dynamics AX 2012 mainstream support was recently extended by two years to October 2018. But please be aware that Dynamics AX 2009 will go into Extended Support in April 2015. This means support is only provided if an extended support agreement is in place and deliverables are limited to security updates and non-security hotfixes (specific bug fix for a critical issue). Therefore, the goal of the Servicing strategy should be to keep all products within their mainstream support.

Tips: To see your version of kernel and Application build. Open the Dynamics AX Client, click the Help button and “about dynamics AX”. You can then click “show all models” to see models deployed in every layer.

Code Promotion

• For Kernel update, also known as Binary update, you can run the AXUpdate program to deploy the object and component via the Windows Installer Patch (MSP) file. These updates are cumulative and the tool will automatically find the roles (AOS, Client) already installed on the server. You should run the same tool to uninstall a specific component.
• Application hot fix is created to address specific issue, problem or customer scenario. There are two ways to deploy it: via the Cumulative Update or via individual Hot Fix package by importing application model (.axmodel) files into relevant patch layer (see below). All application hot fix model files should be installed by using AXUpdate program to automatically import the code into the right Patch layer.

Plan your layer strategy in the early stage of the development cycle to have one dedicated layer for conflict resolution when patching a new model (for example VAP for VAR). It is possible to customize the automated PowerShell scripts to create your build with the default models (ISV, CUS and VAR). In case the default names for each layer are already in used, you can update the PS script to avoid creating the model. Also please remember to run the AXImpactAnalysis tool in a test environment to analyze the impact of the update on customizations in your environment.

Dependencies

When looking at Application Hot Fixes in the Lifecycle Services Search tool, you can see the list of affected objects and dependent objects:

• Affected Objects are the ones that contain the actual code change solving the issue described in the KB article.
• Dependents Objects are all code change existing on the same branch from all previous hot fixes. It basically guarantees the consistency of the code base for all customers within one branch (AX 2012 R2 for example).

It is possible to manually extract the affected objects and import them in one of the customization layer (VAR or CUS) to avoid merging the dependencies installed in the SYP layer. But this basically means you’re taking ownership of the code and any side effect that might result from this integration. Because it can create regression and therefore cause data corruption, it is explicitly unsupported to manually import these application models.

Service Level Agreement

A Service Level Agreement (SLA) is an agreement between an IT Service Provider and a Customer. The SLA describes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. For Dynamics AX, provider of SLA are any application Partner releasing code, the hosting partner and the customer support desk. The overall SLA of the solution is the result of merging all these SLAs. To define yours, you need to have in mind the maximum amount of downtime acceptable to install update, the window of maintenance for every server role of your Dynamics AX solution and the additional staff and resources available to reduce downtime.

For Dynamics AX, these are typical three constraints to take into consideration when setting your SLA:

1. Understand time constraint when scheduling Batch around the clock in case multiple time zones exist
2. Estimate bottleneck from periodic business tasks like End of Year Financial Closing, Inventory Closing on all companies and Master Planning.
3. Identify overhead due to extensive Integration layer and other applications such as BizTalk, Application Integration Framework (AIF), other ERP legacy system, Web Services and Business Intelligence processes.

SLA commitments are measured in percentage of uptime per year: for example 99,999% (also known as "the five nine") means the total amount of unexpected downtime for business critical components cannot exceed 5 minutes and 15 seconds. You can prevent unexpected downtime with High Availability for every server roles such as SQL Server Always On. To reduce planned downtime and disrupt your business as little as possible throughout the maintenance of the whole Dynamics AX solution, it is required to have a defined Change Management process and Change Advisory Board (CAB). You can leverage the Microsoft Proactive Operations Program Configuration and Change Management for Dynamics AX to define such processes, establish best practices and manage your IT solutions with Microsoft Service Management Functions Operations Framework Guide.

Conclusion

1. Always plan to Go Live with the latest Cumulative Update available and supported for any Microsoft products, especially for SQL Server and Dynamics AX Kernel Build.
2. Proactively identify Dynamics AX Application Hot Fixes with Lifecycle Services Search tool and regularly plan an application patch to reduce downtime.
3. Define your core business SLA and validate commitments from all teams involved in the Support Escalation.

Regards,

@BertrandCaillet

Principal Premier Field Engineer