Share via

Migrating security settings between different Dynamics AX 2012 instances

  • Article

One of the common questions we deal with is around the migration of security settings between two Dynamics AX instances. To understand how you achieve it, let’s lay down the basics.

Security in Dynamics AX 2012 consists of roles, duties and privileges. These are stored as Metadata within the AOT. A user is then assigned to one or more security role(s) and based on that security role membership, they are able to get access to various parts of the system. This information is stored in the database in Dynamics AX 2012

In essence, when we talk of migrating security, we need to consider two different aspects.

  1. Migrating the security role information
  2. Migrating the user-role memberships

Depending upon what your configuration and setup is, you may want to do one or both of those above things. Let’s look at how you would these steps in the following sections.

Migrating the security role information

Changes to the behavior of roles, duties, and privileges also change the metadata stored in the AOT. These changes are reflected in the model that the person making the change is working in.

People in the following roles are most likely to modify security:

-         Security administrators with the responsibility for making changes to the security objects by using the Microsoft Dynamics AX client.

Changes made by the security administrator are most likely to be stored in the USR model.

-         Microsoft Dynamics AX developers.

Changes made by developers are most likely to be stored in the CUS or VAR models.

It is essential that the security administrator and developer collaborate to make security changes.

Scenario 1: Move security changes from production to staging

We recommend that you migrate security changes from the production to the staging environment before making further changes in the staging environment.

Follow the steps in the section Recreate the staging environment from the production system in the document https://download.microsoft.com/download/7/9/6/7964C5AD-2A28-4ACC-92D5-2BCC72B70C69/Deploying%20customizations%20across%20Microsoft%20Dynamics%20AX%202012%20environments.pdf.  

The advantage of this approach is that all the changes made from the production environment are brought over to staging and can be tested, compiled etc. in the staging environment before they are reapplied. Note that changes that were made in the production environment by an administrator cannot be uniquely identified in the staging environment.

Scenario 2: Move security changes from staging to production

To ensure that recent security changes made by the administrator will not be lost in the production system, we recommend that you back up the changes from the production environment, apply the changes from the staging environment to the production environment, and then recent security changes to the production environment

When you deploy on production, instead of the step where you import the staging model store, do the following:

1. Back up the security changes from the production environment by exporting the USR model from the USR layer of the production system (or the layer in which the security administrator made the changes).

2. Import the model store of the staging system that contains changes to security artifacts.

3. Reapply the original production security changes by importing the USR model file from step 1.

4. Recompile the production environment.

You can find additional information about managing customizations at https://download.microsoft.com/download/7/9/6/7964C5AD-2A28-4ACC-92D5-2BCC72B70C69/Deploying%20customizations%20across%20Microsoft%20Dynamics%20AX%202012%20environments.pdf

Migrating the user-role memberships

Below are the steps to move users and their role assignments between environments:

On the source environment:

  1. Open System Administration\Common\Data export/import\Definition groups
  2. Press New
  3. Enter definition group: UserRoles
  4. Click Clear
  5. Click Ok
  6. Click “Select Tables”
  7. Add tables “UserInfo” and “SecurityUserRole” and close window
  8. Click “Export to”
  9. Enter file name
  10. Select file type: Comma and click Ok. Confirm any other dialogs.
  11. Open the exported dat file, optionally remove lines for users that do not need to be imported on target environment such as Admin, Guest, etc.
  12. Move the exported .dat and corresponding .def file to target environment

 On the target environment

  1. Open System Administration\Common\Data export/import\Import
  2. Select the .dat file from step 12
  3. Switch to tab ‘Advanced’ and enable following options:
    1. Include shared tables: Yes
    2. Include system tables: Yes
    3. Update existing record: No
  4. Click ok
  5. Confirm dialog for import into related tables

Click Ok in the dialog to select which tables you want to delete before import, do not select any tables

Comments

  • Anonymous
    May 03, 2013
    Hi When we move the security changes from staging to production , we have faced a issue where the changes are not reflected immediately in the production. Are we missing some thing here will moving the changes ?

  • Anonymous
    May 06, 2013
    Anantha, when you say you moved the changes from staging to production, which part are you referring to - the metadata move or the migration of user-role memberships?

  • Anonymous
    October 16, 2013
    Very good and detailed information. Was really helpful in solving a major issue

  • Anonymous
    November 01, 2013
    Thank you Sunil. Glad it helped you.

  • Anonymous
    November 17, 2013
    Thank you Parth.  I have some more detailed questions about the approach if I may.  We have a requirement to have more than just the users and their particular role assignments.  The user options can vary between user types for example the user options that are displayed on the status bar and automated log-off, some of these items are defined in UserInfo.  Other data is defined in SysUserInfo, so on the import method above I presume that "default" SysUserInfo will be created (almost as if the user had been manually imported into that environment through the Import Wizard?). Secondly, for many the connection of the user to the worker record through the "user relation" defined by the Global Address Book is a key set-up for moving a set of users between environments, or even performing an environment set-up (especially where we are talking hundreds of users, in our own case we're talking thousands of users so manual set-up of that information is not practicable).  A user and worker together are required to perform system activities correctly, including workflow participation and approval.  Is there a more complete guideline that covers the area in full detail and is the Data Import eXport Framework advocated for this process?

  • Anonymous
    November 20, 2013
    We tried this Parth and the users came over but each user shows no roles in the UI. The interesing thing was that if I manually added one of their roles from the staging instance the entities were already correctly assigned. Our VAR is telling us - " I have had mixed results using data definition groups in AX as some keys on the table are joined by recIds which will be different from one environment to the next.  Also there is the risk that it may break other things, maybe user relations, etc., so it should be done in a test environment and proven out." He also said that instead of using the model file we can move our custom roles, duties, and privileges by exporting the project using an .xpo. We were hoping this would work but we aren't feeling that confident that it's fool proof. Thanks Rick

  • Anonymous
    February 26, 2014
    I'm experiencing the same issue as Rick. Once the migration is complete I do not see the roles associated with the user. Can you clarify if there are any additional steps after the data has been migrated? Zach

  • Anonymous
    March 14, 2014
    Just tossing out this idea: would a web server cache need to be cleared for the results to be seen?  Possibly explanation for some of the comments above noting they didn't see success (or at least right away).

  • Anonymous
    March 25, 2014
    axutil.exe refreshrolecache

  • Anonymous
    April 22, 2014
    I have found success utilizing Arbela's Security Manager: http://lnkd.in/bWbFJR2

  • Anonymous
    May 20, 2014
    We looked at Arbela's Security Manager which is essentially a wrapper around AX security and found it kind of buggy and confusing, so I wouldn’t recommend it. Just stick with standard AX security as that’s what we ended up doing.

  • Anonymous
    June 03, 2014
    I have tried but i can't see roles in destination server.. Please suggest...

  • Anonymous
    January 06, 2015
    I have tried above steps .. its big mistake .. m not able to see any module any screen.. i have logged in without any user role

  • Anonymous
    February 28, 2016
    I do as your guide but when I import, It's warning that "can not open this file"