Your SEO optimized title page contents

Patching Strategy for Dynamics AX

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.
Products Released Lifecycle Start Date Mainstream Support End Date Extended Support End Date
AX 2012




AX 2012 R2




AX 2012 R3




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.



   Patch Layer





  User modifications, such as reports.



  Modifications that are specific to a company




  Value Added Resellers modifications specified by customers



  Where an Independent Software Vendor creates their own solution



  Used by distributors to implement vertical partner solutions.




  Reserved by Microsoft for future patching or other updates



  Modifications to match country or region specific legal demands



  Lowest level where standard application can never be deleted

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.


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.


  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.




Principal Premier Field Engineer

Comments (10)
  1. Hi Martin,

    Thank you for the comment.

    From AX 2012 R3, you can benefit from the new Update Installer tool connected to your Lifecycle Services project:…/dn715994.aspx

    It allows you to select application KB per:

    • Fix Type (Major Feature, Regulatory, Important, Optional)
    • Module

    • License Code

    • Region.Country

    and of course Business Process Model if already defined in LCS.



  2. Martin says:

    Hey Bertrand,

    thanks for the article!

    Now if you're looking for another blog post idea:-)  We have one environment, which we try to keep up to date as much as possible (as it contains the development environment for our most popular Ax module).

    What I would like is an ability to script the installation of all missing KBs (latest kernel + all missing apps) every month or two. In fact, something like the old DIS layer in Ax 4.0, just automatically deployed together with the kernel….. I know, most likely not possible right now as we have to create support cases for each KB – or is there actually any chance to implement something like this?

    Kind regards,


  3. Toni Feldinger says:

    @Rene: I fully agree!

  4. Rene Fauland says:

    Just an example:

    KB123456 with code changes in, lets say, 3 classes.

    But the KB itself includes the half AOT, because of all the dependencies.

    Yes, there are reasons for this, of course, but there should be also alternative ways for the customers.

    It would be interesting what others think about this



  5. Rene Fauland says:

    well i really agree, but i bet most people are doing it in a reactive manner.

    and in real company world there's not always the time to do it proactively.

    …not with this count of hotfixes in short time and current options how to do it 🙂

  6. Hi Rene, that is exactly my point: because applying Application Hot Fix can be difficult in an AX instance with multiple ISVs and VARs models, the idea is to always check the Hot Fixes available on Lifecycle Services based on keyword, object name, and apply them together and proactively instead of applying Hot Fixes in production in a reactive manner with less time for proper testing.

    Regards, Bertrand

  7. Rene Fauland says:

    Same with windows/security updates…

    "Proactively identify Dynamics AX Application Hot Fixes with Lifecycle Services Search tool and regularly plan an application patch to reduce downtime."

    That's not really easy with the current options (setup, manual extraction…), or am i wrong?

    And i'm talking about customized systems, not out of the box AX 🙂

  8. Hi Yair, thank you for your comment. I understand your statement, and it is true that regression can be found and that's why it is critical to perform relevant testing prior any release into production.

  9. Yair K. says:

    I cannot agree with your SQL Serve recommendation ("always to keep the build up to date in regards to the latest CU available"). More than once there are cases of released CUs containing serious bugs. e.g. 2008 R2 SP2 CU6/2008 SP3 CU11/ (index corruption), 2008 SP1 CU7/8 (SSRS), 2012 SP1 CU3 (SSIS), 2008 R2 SP2 CU11+ (RCSI, fix exists but unreleased as of now), etc. Sometimes, these bugs are only fixed around the next CU or later. IMHO it is by far better to be at least two months behind the latest release (and if there are no more releases – wait two months after the last one and only then install it).

  10. Tommy Skaue says:

    Great post, Bertrant! Thanks for this!

Comments are closed.

Skip to main content