Home > Blog > Moving Security Role Objects in Dynamics AX from One Layer to Another

Moving Security Role Objects in Dynamics AX from One Layer to Another

We ran into a scenario where we had to make some changes to security roles in Dynamics AX that were created in a different layer than we were currently doing development work. We want to do all of our development in the VAR layer which is what we have hooked up to Team Foundation Server (TFS). The security role objects in question, were originally created in the USR layer. We needed to move the security role objects before we could get our changes into TFS, so they could be shared across environments. What we learned is that once you remove a security role object, all of the users that were assigned to the role no longer have it. We needed to create a process to assign the users to the new role created in the VAR layer.  To prevent a very manual process once migrating the changes to production and other environments, we created the process I will outline below.

Process for Moving Security Role Objects in Dynamics AX

This is a one-time process that needs to be run when moving the code between environments. It is a quick process to run that takes a matter of minutes, instead of the hours of manual work assigning users to roles.

The development steps can be summarized as:

1. Record the old/current IDs of the security roles to be moved
   a. We created a table that will store the NewId, OldId, RoleName, and an IsUpdated (yes/no) field.
   b. We created a job that will loop through the security roles and populate the table with the id (into the OldID field) and role name.
2. Create a duplicate object of the security role in the target/desired layer.  For us this was the VAR layer
3. Delete the current security role object in whatever layer it resides in.  For us this was the USR layer
4. Remove the CopyOf from the name of the duplicated role created.  This will ensure that the new role is named the same as the old.
5. Record the ID given to the new security role object.  We created a job to do this.  After updating the role with the newID the job went through the list of users that were assigned the old role ID and created a record assigning the user the new role ID.  A second part of the job assigned the user to specific companies if that is how the old role was setup.

When doing a code migration with the new security objects between environments the steps below need to be taken:

1. Run the job that populates the table with oldIDs and role names
   a. You will have to import the xpo file in order to do this.
2. Import the new modelstore
3. Run the job that updates the newIDs and then assigns the users to the new role.
4. Test your changes

Through all of our testing and security changes we learned that the issue above is only for security roles. All other security objects (privileges, duties) move just fine between layers. For those all you have to do is steps #2-4 from the development steps above.

Download the Free AX Role Mover Tool

If you've run into this issue check out the free AX add-0n Role Mover tool we've created and made available for download.

Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.

Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.