daxserver: Migrating security settings between different Dynamics AX 2012 instances

[Blog bot]

Источник: http://blogs.msdn.com/b/daxserver/ar...instances.aspx
==============

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 http://download.microsoft.com/downlo...vironments.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 http://download.microsoft.com/downlo...vironments.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




Источник: http://blogs.msdn.com/b/daxserver/ar...instances.aspx