Your SEO optimized title page contents

Installing Hotfixes – Please use the Update Installer

Greetings, Dynamics community!  We've all been there.  You are trying to resolve a problem in your production Dynamics AX deployment.  You discover a hotfix in LCS that should resolve the issue.  You also discover that there are hundreds of axmodel files that are included in the hotfix.

The clock is ticking and the pressure is on, so instead of running the update installer (AXUpdate.exe), you sift through the axmodel files and identify the code that you believe will fix your issue.  Now you apply the code into your environment, and suddenly you encounter new errors.

Using the method described above, even though it might appear that you're saving a lot of time, it is fraught with risk.  For example, you might accidentally miss a dependency; please see screenshot above.  Or, there might be an associated kernel hotfix that should have also been installed.  The only way a kernel hotfix is installed is to run the update installer.  This is really the only supported method when installing hotfixes - please run the update installer!  It will save you time in the long-run and will help maintain the stability of your system.  For a detailed description on how to install hotfixes and updates, please visit this link.

Thank you!



Comments (4)
  1. Inway-FH says:

    Could you do a follow up post with some details on how the dependent objects of a hotfix are determined? I’m guessing this is an automated process that produces false positives. For example I decided not to install KB4016611 because the hotfix size was over 1 GB and the list of conflicts reported by the installer was rather lengthy. But the actual change of the hotfix does not have any dependencies.

    1. Hi,

      It is actually quite a complex process that detects dependencies between object based on previous released fixes.

      You can read below some explanation from Dynamics AX 2009 but the tool has been improved a lot:


      1. Inway-FH says:

        Thanks for the response and the link. So I guess the explanation would be that the object with the change had previous changes from other hotfixes and the hotfix includes those and their dependencies. Makes sense, but it is hard to argue the effort of a very minor change (say one line of code) that can result in several days of work to merge and test all the changes from dependant objects. Especially if the change of the hotfix is actually independant from the changes of the previous hotfixes. I think in those cases implementation partners will continue to just grab the change from the hotfix without installing the hotfix.

        1. Hi,
          I understand the difficulties to patch the KB that is coming with many dependencies. However, I have to repeat once again that it is not supported to extract specific code from a KB. The following article on Customer Source explains it very well:


Comments are closed.

Skip to main content