Microsoft Dynamics AX 2012 R2 Administration Cookbook

5 (1 reviews total)
By Simon Buxton
    Advance your knowledge in tech with a Packt subscription

  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Managing Users in AX 2012

About this book

Microsoft Dynamic is a powerful ERP solution for global enterprises to support industry-specific and various operational business processes. This single solution enhances various aspects of manufacturing, retail, service, and public sector industries. Due to its intriguing capabilities such as finance and supply chain management, business intelligence and reporting, and project management, it is one of the most widely used solutions, having been adopted by many organizations across the globe. If you are one of those who help organizations in administering this unique solution, this book should be in the tool belt of any AX developer to ensure compliance and simplify the ongoing management of the system.

Providing administrators who are involved in system administration and management with clear guidance on many administration tasks, this book is packed with systematic instructions of hands-on examples and in-depth explanations Even for experienced users, this book will serve as a great source of reference by providing new ways of working with Microsoft Dynamic through the book's easy-to-follow approach.

This hands-on guide looks at key administration tasks, explaining not only how each task is performed, but also why. You will be provided with practical guidance that will allow you to safely take advantage of the advanced technology in Dynamics AX 2012 in order to simplify and automate the ongoing management while maintaining compliance.

This practical book simplifies user management operations by automating the tasks of hiring new people—joining up HR and security roles through organizational hierarchies. In-depth explanations teach you about AX licensing and how to make the most of your license.

Management of models and the model store (including installing hotfixes and addons), as well as details of how they work are provided, along with practical guidance on the procedures required to reduce risk and downtime.

This book guides you through the key tasks in reporting and BI through in-depth knowledge of the Batch Framework and Alerting. Finally, important tasks in performance, system monitoring, and troubleshooting are provided with in-depth guidance and further reading.

With this comprehensive guide, you will be armed with all the tools and instructions you need to both manage the system and make better decisions as your company’s requirements evolve.

Publication date:
November 2013


Chapter 1. Managing Users in AX 2012

In this chapter, we will cover the following topics:

  • Creating a new Dynamics AX user

  • Creating a Claims (flexible authentication) user

  • Importing users from the Active Directory

  • Understanding the user request workflow

  • Defining user relations and basic roles in human resources

  • Assigning roles to users

  • Assigning profiles to users

  • Managing users through PowerShell commands

  • User groups, what happened?



The Dynamics AX client uses the Windows security context (effectively the user you are logged in to Windows as), as opposed to maintaining its own cryptography. This means when you open the AX client, there is no second login.

AX does, however, have the concept of a user, which is typically an employee that has an account in your Active Directory. This is required to grant the users access to log in to AX and to manage their roles, duties, and privileges (security access). It also affects licensing (refer to Appendix, Further Reading and Chapter 10, Setting Up and Managing Security, for further details). AX also allows you to create a relationship between users and employees. A user can be an employee, which is not enforced by the system. However, to use some of the functionality, you need to associate the user to an employee.

The decision of which users to import and their roles within the organization becomes apparent once you have designed your organizational structure. This will have been done as part of the implementation. You would only create or import users that specifically require access to Dynamics AX.

The following are the three types of users within Dynamics AX:

  • The Active Directory user

  • The Active Directory group

  • The Claims user (flexible authentication)

The following are the four methods of creating users within Dynamics AX covered in this chapter:

  • Creating independently using the User form

  • Importing from your Active Directory

  • Using the AX Management Shell (PowerShell)

  • User request workflow

Where appropriate, an equivalent PowerShell command will be offered. This will allow automation of administration functions. To use PowerShell, you need to install the management utilities and open the Microsoft Dynamics AX 2012 Management Shell.


The Microsoft Dynamics AX 2012 Management Shell is installed from the AX installation media by choosing management utilities.


Creating a new Dynamics AX user

This task explains the process of creating a user manually within AX, either as an Active Directory user or as an Active Directory user group.


This task can be performed using PowerShell commands within the Microsoft Dynamics AX 2012 Management Shell. This would not normally be done to create a single user, but as a part of a wider scheme where an organization may script the automation of user accounts from Active Directory. Refer to the Managing users by PowerShell commands section.

Getting ready

To create a user, you will need to log in to AX as a user with appropriate permission (for example as a system administrator) and your Windows user account must have the permission to query the Active Directory.


If you are using partitions, ensure that you are logged in to the correct partition (using the AX configuration utility or shortcut); please refer to Chapter 8, Setting Up and Managing Legal Entities and Partitions.

To create a single user, navigate to System administration | Common | Users. The following window will be opened:

How to do it…

We can create a new Active Directory user with the following steps:

  1. On the Users list page, click on User in the New button group on the action pane, as shown in the following screenshot:

  2. Some of the fields in the form are explained in the following table:

    User Id

    This is a unique identifier for the user within Dynamics AX and can be up to eight characters in length.

    An example for the user Joe Bloggs would be JB001

    User name

    The name of the user is not mandatory, but for actual users it should always be filled in.

    Network domain

    In this case (the Active Directory user), it is the domain in which the user resides. This can be the Fully Qualified Domain Name (FQDN) or the NetBIOS name (binary.local or binary in our example).

    If you are configuring a Claims- (or flexible-) based user, this is based on the authentication provider you are using.


    This is the user login name in the authentication provider. In this case, the user is in the Active Directory.

    If the user account is binary\joe.bloggs (or [email protected]), enter Joe.Bloggs in this field.

    Account type

    You can enter the following three options in this field:

    • Active Directory user

    • Active Directory group

    • Claims user

    Choose Active Directory user

    Default company

    This is the default legal entity for the users. This is kept the same, unless specified on the client configuration.


    This is to control whether the user can log into Dynamics AX. Checking this box saves the record and validates the information you have entered.

    If the user account cannot be found in the Active Directory domain entered, you will not be allowed to check this box.

    Only the enabled users can log in to Dynamics AX. Setting accounts to disabled allows you to temporarily revoke access for users or disables the accounts created in advance.

    Current partition is the default partition

    This is explained later in the book; You should normally check this box.


    Although the Default Company value (legal entity) is DAT, this should never be used since it may be deprecated in future releases of the software.

  3. Either enable the user or simply close the form (which will automatically save the record).


    Enabling the user or saving the record will cause AX to validate the information you have entered against the Active Directory service. If the user account cannot be found, you will not be allowed to proceed. If the validation succeeds, no message is displayed.

How it works…

Once you save the record (or check Enabled), the system will look up the account details entered in your Active Directory to validate the details entered and also to store those of the user (or the Active Directory group) and Security Identifier (SID).

The SID is a Globally Unique Identifier (GUID) that uniquely identifies objects in the Active Directory (including users and user groups).

The login process

Most AX implementations have more than one environment (testing, training, production, and so on). A method of accessing these environments will be established as part of the implementation and deployment configuration file shortcuts/AXC file, for example.

When you open the Dynamics AX client, it will determine which server it will connect to and validate that your Windows user account has access to log in to AX.

It does this by querying your Windows account details to obtain the account's SID, which is then used to locate your user account within AX.

If the account cannot be found, it queries the user groups that your domain account is a member of against the Active Directory groups created within AX. If a match is found, a user account will be created with the same permissions and settings as those assigned to the user group in AX.

There's more…

You can also create a new user from an Active Directory user group. This is a special case of user management, where all users in an Active Directory are granted access based on their user group in the Active Directory.

The concept is that you create a user group in your Active Directory for each role within AX and add the users into this group.

When the user in the Active Directory user group logs in to AX for the first time, it creates a specific user with the roles (and privileges) of the user group.

From that point, the user is an individual account and group membership plays no further role in the user management. Effectively, the user group acts as a template for the user.

To create a user group user, the steps are the same as per an individual user account, except for the following fields:

User Id

This is merely a unique ID, but using the AD user group is preferable


This is the user group, for example, AXAdmins

Account type

This is the Active Directory group

Once complete, closing the form will save the changes and validate that the Active Directory user group exists.

The following screenshot depicts an example of a user that is created this way:

Note the user ID is apparently random characters. This cannot be controlled through configuration. If you want to have control over the naming of the user ID, the value of using user groups is limited.

Creating an employee

This is beyond the scope of this chapter, but this is included to show what was configured in the Defining user relations and basic roles in human resources section later in the chapter.

First navigate to Human resources | Workers | Employees and then carry out the following steps:

  1. Click on Hire new worker, which causes AX to show the drop dialog shown in the following screenshot:

  2. Enter the details of the employee; if a duplicate name is found, you will be prompted to reuse it or create a new name.

  3. Check the Assign a position checkbox and then enter the position that the employee holds.

  4. Click on Hire new worker to complete the task.


Creating a Claims (flexible authentication) user

This method allows the access of Dynamics AX to users and services that are not a part of your Active Directory.

Getting ready

There are two main reasons to use Claims users: allowing external users (including suppliers and customers) to access the Enterprise portal and allowing external applications or web services access to the AX AIF (Application Integration Framework) services with non-Active Directory accounts. An example of this is a mobile application that requires access to AX services but cannot log in to the domain. You cannot use basic authentication with the AIF. Unless you want to write a set of proxy services to act as intermediaries, you need some way of accessing AX without using Active Directory accounts.


These users cannot log in to the AX client application directly. It is typically used to allow external parties (customers, suppliers, and so on) access to the Enterprise portal (SharePoint) or web services without creating Active Directory accounts.

The following example is for a mobile application that does not support the Active Directory accounts.

How to do it…

The method is the same as creating an Active Directory user, except for the following fields:

User Id

This is a unique ID, but you should create a strict standard that allows you to identify these accounts. If this is a series accounts for a warehouse management application, perhaps we could use WM001.


This is the user ID of the external user that the user or service uses to log in with, often an email address.


This is the name of the authentication provider. When your application logs in to the AX AIF service, it uses this, along with the user ID as the LogonAsUser property (this is explained later in the chapter).

Account type

This is a Claims user.


For Claims users, no validation of the details entered is performed when the record is saved or enabled.

If the account is for an external party, it may be governed by that party (for example, using Active Directory Federated Services (ADFS). The purpose here is to inform AX that we trust this membership provider (the Domain field) to authenticate the user (the Alias field).

Where we do control the usernames (for example, in the internal applications), we should be careful while choosing the naming conventions, as these can't easily be changed later (if at all).

Closing the form will save the record and complete the task.

How it works…

In your mobile application (this is not restricted to mobile devices, AIF HTTP integration ports would also use Claims users), the users log in with a user ID and password. Once they have logged in, they are classed as authenticated in your application. When this application tries to access AX, it will do so with the application's user account. Since you have entered these details within AX as a claims user, AX will trust that your application has authenticated the user.

There's more…

Here we will provide a working example of a sample mobile application logging in as a Claims user with the following assumptions:

  • AIF is installed and functioning

  • Visual Studio 2012 is installed (although for this test, any version that can connect to WCF services is sufficient)

  • Users have the knowledge of how to create a simple Windows console project

Creating a Claims user

We can create a claims user with the following details:

User Id



[email protected]



Account type

Claims user

We can configure an InventItem Service inbound AIF port by performing the following steps:

  1. Navigate to System administration | Setup | Services and Application Integration Framework.

  2. Click on Inbound ports. In the Inbound ports form, click on New and complete the form as follows:

    Some of the fields are discussed in the following table:

    Port name

    This is the unique identifier of the port. Naming of these ports is important. A good tip is to use the module or a functional area as the first part of the port name.


    This is the description of the port.


    Retain the default values in this field.


    Leave this field with the default value.


    The other fields are not important to this task, so we will not be covering them at this stage.

  3. Next, click on Service operations and move InventItemService.find to the left-hand side pane:

  4. Click on Close, and in the Inbound ports form, click on Activate.

The system will produce an InfoLog message listing the services that were started. At the end, it should state The port 'ItemsPort' was deployed successfully.

The Inbound ports form will now display the web service definition (WSDL) URI of the port. In my case, this is http://ZEUS:8101/DynamicsAx/Services/ItemsPort.

Creating a Visual Studio application

We can create a Visual Studio application by performing the following steps:

  1. Open Visual Studio 2012 and create a Windows Console C# application.

  2. On the project tree, right-click on References and select Add Service Reference, the following form will be opened:

  3. In the Address field, insert the WSDL URI from the Inbound ports form and click on Go.

  4. Enter a useful namespace for our reference and click on OK.

  5. Open the code file, Program.cs, so that we can write the application.


    The first part of the program is to declare our security context, which is the important part we are trying to demonstrate with Claims users.

    The first few lines of code of the Program.cs file are as follows:

    // Set up the call context to use our Claims user
    ItemReference.CallContext context = new ItemReference.CallContext();
    context.Company = "HHF";
    context.LogonAsUser = "MyAppAuthProvider\\[email protected]";
    context.Language = "en-gb";

    You should remember that our user has the MyAppAuthProvider domain and the alias . This is used as domain\alias when the application logs in to AX.

    The following code snippet is purely to demonstrate that the Claims user can log into AX and read the port we configured earlier:

    ItemReference.AxdItem myItem = new ItemReference.AxdItem();
    ItemReference.ItemServiceClient client = new ItemReference.ItemServiceClient();
    ItemReference.QueryCriteria criteria = new ItemReference.QueryCriteria();
    ItemReference.CriteriaElement itemIdCriteria = new ItemReference.CriteriaElement();
    itemIdCriteria.DataSourceName = "InventTable";
    itemIdCriteria.FieldName = "ItemId";
    itemIdCriteria.Operator = ItemReference.Operator.Range;
    itemIdCriteria.Value1 = "A";
    itemIdCriteria.Value2 = "Z";
    criteria.CriteriaElement = new ItemReference.CriteriaElement[1];
    criteria.CriteriaElement[0] = itemIdCriteria;
        myItem = client.find(context, criteria);
        if (myItem != null && 
            myItem.InventTable != null &&
            myItem.InventTable.Length > 0)
            foreach (ItemReference.AxdEntity_InventTable item in 
                   String.Format("Item Id {0} - {1}", item.ItemId, 
    catch (Exception e)
        Console.WriteLine(String.Format("Error {0}", e.Message));
  6. Finally, run the application in the debug mode (press F5).

The result

The result of this is that the application logs in to AX as the Claims user, not as the Active Directory user. You will also note that no password is required, as AX does not have its own cryptography and we trust that the application has already done the authentication for us.

Flexible (Claims) authentication is a much welcomed new feature for AX 2012. In the past, we had to write proxy services to do this authentication for us, and for the Enterprise portal, we had to add the external users as the Active Directory accounts in our domain.


Importing users from the Active Directory

This method allows you to import multiple users in a single pass by querying your Active Directory.

Getting ready

To import users, you will need to log in to AX as a system administrator and your Windows user account must have the permission to query the Active Directory.

Navigate to System administration | Common | Users | Users.

How to do it…

Users can be imported from the Active Directory through the following steps:

  1. On the Users list page, click on Import. This will open the Active Directory Import Wizard.

  2. Click on Next, which will display the following page:

  3. Complete the page as detailed as follows:

    The only mandatory field is the Domain name field. The other fields are the criteria to reduce the resulting list of users on the next page. This highlights the need to organize your Active Directory in line with roles that will have access to Dynamics AX. The following are the fields:

    The Search for fields

    The wizard lets you search for users based on user account details or user group membership.

    The wizard can't be used for adding user groups.

    If you select Search for AD User Groups, only Display name and Alias will be available. The result would be a list of users who are members of the groups matching the preceding criteria.

    If you select Search for AD Users, all fields will be available. The result would be a list of users whose account details match the preceding criteria.

    The criteria fields

    All other fields are criteria fields that filter according to the Active Directory account details based on the selected domain.

    If you leave a field blank, it will not be used as part of the criteria.

    If you specify a value, it is used as an exact (case-insensitive) match.

    If you specify a value with an asterisk (for example, Chris*), it will perform a wildcard search.

    The following is an example that will locate all users within the Design department:

    If the department is Design Dept, the user will not be found unless Design* is specified.


    This wizard also allows you to add the users to their roles (which determine their roles, duties, and privileges within Dynamics AX). Although this step is optional, it will save time if you do it at this point. Therefore, it may be easier to add users in batches by their role within AX.

  4. Clicking on Next will show the results of the query.

  5. For each employee you wish to import, check Import and when all required users are selected for import. Click on Next or go back to amend the criteria.

  6. On clicking Next, AX will produce a list of users that will be imported:


    The user ID is normally the AD alias, unless the alias is greater than eight characters. If this is the case, it is abbreviated. If this abbreviation results in a duplicate user ID, AX will add a number to make it unique.

  7. Click on Next to continue to user role selection, or go back to adjust the selections made:

    We now have the option to add the users to roles. As stated earlier, it will save time to add users in sets, by their role. This step can be skipped, especially if our process is to allocate the roles dynamically.

    Let's say we are adding the finance department to AX. We can add all the finance users in one batch, assigning the Accountant role to all. Once complete, we can move the managers in to the Accounting manager role.

    In the preceding example, Josh is a Product designer, but also in charge of IT.

  8. Once complete, click on Next and select the profiles that the users should be a part of, as shown in the following screenshot:

  9. Choose from the following options, remembering that we are setting the profiles for all users imported in this batch:

    No profile in all companies

    The role center will not be displayed on the home page of AX or the home page of the Enterprise portal. Choose this option if role centers are not configured or not in use within your organization.

    Same profile in all companies

    This along with the first option is the most common. The user gets the same profile in all companies.

    Company specific profile

    You can choose to have a different profile in each company; in this case, you can specify the role the user has in each company.

    The profile determines the role center for the user that is displayed on the home page when you start the AX client or open the Enterprise portal.

    This displays (among others) cues, tasks, metrics, and KPIs. Each profile provides a different set and layout to this page. The profiles in use by your organization should already be decided upon at this stage. If not, you can assign No profile in all companies.


    As standard, some work is required to make the role centers (profiles) work. Therefore, it is better to disable the profiles until they are set up and the employee roles are determined.

  10. Once complete, click on Next.

  11. On this final step, clicking on Finish will import the users with the settings you have specified. Clicking on Cancel will close the wizard without importing the users.

The users will now appear in the Users list page; you can double-click on a record to view the details and make any adjustments.

The system automatically adds the System user role. This is required for basic system functionality. The system will let you remove the System user role, but this is not recommended (as AX will warn if you try). If you intend to disable a user, uncheck the Enabled checkbox instead.


A faster method of enabling/disabling many users at a time is to do this from the Users list page and click on Edit in the grid in the ribbon at the top of the page.


Understanding the user request workflow

This describes the process where a user is requested, often by HR, and submitted to a workflow, designed to follow your organization's policies for creating a new user.

Getting ready

t is common for there to be many more employees than there are active users in the system. From time-to-time, Human Resources may request that an employee be given access to AX.

They do this using the user request feature.

How to do it…

The user request will be created by HR from the Employee or Workers list page by navigating to Human Resources | Common | Workers | Workers and by performing the following steps:

  1. On this form, in the top ribbon, navigate to User requests | Worker user request. The minimum is already filled in for you.

  2. Enter the e-mail address, if known. This can be used by the workflow to send them an e-mail when the account is created.

  3. Enter the role, if known. This can be assigned later, and even dynamically based on the employee's information.

  4. If you know the employee's Windows login details, enter them here as Domain\username.

  5. Press Ctrl + S, which saves the record enabling the Submit button as shown in the following screenshot:

  6. Click on Submit and then click on Close. This opens the workflow submission form.

  7. Enter any special details about this request and click on Submit.


    Note that the User alias field (which is optional, but required for automatic user creation) is the format of Domain\Account. If you specify an invalid account, AX will still create the account, but will mark it as disabled until it is corrected.

  8. Click on Close.

Requests can be seen and monitored by navigating to System administration | Common | Users | User request.


If you close the form without submitting, you can find it here and submit the user request to the workflow.

Once the workflow is completed (which can be automatic under certain conditions), the user will be created and attached to the correct security role.


If you have configured the allocation of roles to be automatic, the whole process of role allocation and user request can be largely automated (still maintaining compliance) based on the employee's position in the company.

How it works…

The user request process is intended to segregate roles between the requestor (HR, supplier via SharePoint user provisioning, and so on) and those authorized to create users.

The process relies on a workflow being created that can be configured to either prompt the appropriate user to perform the task or complete the task automatically.

This is a very powerful feature and highlights the need to have roles carefully assigned, avoiding potential security vulnerabilities, such as allowing a user to change their position, can potentially grant them system administrator rights if the automatic role assignment is used.

This should not deter you from using these features as there are significant benefits, especially in large organizations.

See also

  • An example of a user request workflow is detailed in Chapter 11, Setting Up and Managing Reports and BI.


Defining user relations and basic roles in human resources

Some features in AX require that your user account and employee record are linked. This is a good practice, and all users who are employees (or subcontractors) should be associated with an employee record. Without this link, some functionality will not work, especially within sales and marketing.

Getting ready

Log in to the Dynamics AX client as a system administrator, and navigate to System administration | Common | Users | Users.

All the users who are employees on a temporary or permanent basis should be related to an employee.

This process assumes we have created employees already part of the configuration of HR (Human Resources). If not, the process is described in brief in the See also section of this recipe.


To make the most out of Dynamics AX, HR should be configured to a suitable level and kept up-to-date (positions, status, and so on) as this has many uses outside of HR, including assisting with security role assignment.

How to do it...

For defining the relation between users and employees, perform the following steps:

  1. On the Users list page, select the user you wish to assign as an employee and click on Relations.

  2. Click on New.

  3. In the details section (the right pane), choose the employee/worker from the Person drop-down list.

  4. Close the form.


    The interface for this form suggests that you can have many employees linked to this user. This isn't the case, AX will not allow you to create a new record and link it to a different employee.

How it works...

On saving the record, AX creates a link between the employee and the user. This enables various features in the application, where an employee is relevant to the data (for example, a Project Manager for projects is a person responsible for the sales order for sales orders, presentation of information, and so on).

There's more...

If users are customers or suppliers, they can be added once the record is saved by pressing Ctrl + S.

A prime example of this would be the suppliers and customers who use your Enterprise portal, where you would create a user (typically, a claims user) for each staff member that requires access.


Assigning roles to users

This recipe will help to manually adjust the roles for specific users. This is discussed in detail from the role perspective in Chapter 10, Setting Up and Managing Security.

Roles equate to a set of duties and privileges to system functionality. The concept of a role is to simplify the process of configuring user security by providing preconfigured roles that we simply assign to the users.

This is repeated in Chapter 10, Setting Up and Managing Security, but the role has an impact on licensing. Moreover, it unclear from the system whether the roles you assigned are functional or enterprise.

Getting ready

If we used the Active Direct Import wizard, we may have already assigned roles to the user.

You will need to use this method under the following conditions:

  • You need to control the roles for the users by legal entity (or hierarchy)

  • You need to have added the user manually

This is done from the Users list page, which is found by navigating to System administration | Common | Users | Users.

How to do it...

Roles can be assigned to a user by performing the following steps:

  1. Open the Users list page and locate the required user.

  2. Click on Edit or double-click on the user, as shown in the following screenshot:

    We can chose to assign new roles, remove existing roles, assign organizations, and edit roles.

    Removing a role is straightforward. Highlight the role and click on Remove. The user doesn't have to be logged out for this to happen, but will need to log off to see the effects of any change to the user's security.

We can assign roles to the user by performing the following steps:

  1. Click on Assign roles, which will show a list of all the available roles as shown in the following screenshot:

  2. Check each role checkbox depending on the role the user should be a member of and click on OK. This closes the form and updates the User details form.


    Don't add many roles to a user, typically the system user role and their primary role(s). Many implementations develop their own roles to simplify the assignment of duties and privileges of a user.

How it works...

When a user logs in to AX, they do so with a default company (synonymous with legal entity in this context, but the term company is used), set either by the user option or the client configuration.

Once this is established, the system applies the privileges associated with the user's role in that company. If the role was granted to that company in a hierarchy, the privileges are also applied.

Setting up different roles for each company (Legal entity) is discussed in the next section.

There's more…

We should also assign organizations to the users. In this context, organization actually means legal entity or company in general terms. This feature provides the ability to assign the role to a section in our organizational structure (which means one or more legal entities).

In large organizations, a manager in one company might have less number of or no rights in another. Where this is the case, you can state for which companies the role applies.

By default, the role is assigned to all legal entities within your organization.

When AX is configured, you will create organization hierarchies, in which you define your organizational structure. This structure can place legal entities as children of a parent company (for example, a group company).

You can also configure your organizational structure to include the role security. If this is the case, the roles can be applied to nodes within the structure. Otherwise, this form simply lists all legal entities.

The structure in this example is as follows:

On the user details form, click on Assign organisations:

The default is Grant access to all organisations, which means all legal entities. To assign the role to a specific legal entity or sections of our organizational structure, choose Grant access to specific organisations individually.

The role can be assigned based on individual legal entities (the list in given in the preceding screenshot), or use the organizational structure designed for this purpose. This is preferable as we can then leverage the investment made in the organization's structure and get further benefits if this structure changes. If the structure is moved, the user's security is also updated.

In the following example, we shall use the structure by performing the following steps as it utilizes most of the features:

  1. Select Grant access to specific organisations individually.

  2. For the Select organisation hierarchy option, change this to the organizational structure you intend to use (which will be the most likely option). If you only have All legal entities in the list, no hierarchy has been published with the security role. An example is shown in the following screenshot:


    Although security can only be applied to a legal entity, you will see that hierarchy is not restricted to legal entities, and this case also includes business units. The reason is that you can place legal entities as children of a business unit (for example, you acquire a new company and want one of your business units to operate it).

  3. Select the node you wish to grant the role to.

  4. Choose Grant on a parent company to grant the user rights to the role in that company, and not in any child legal entity in the hierarchy. It is added, as shown in the following screenshot:


    Notice that Hierarchy is empty. Therefore, choosing Grant on a business unit makes no sense. Business units are not a data security boundary (you can't log in to a business unit). You would only use the business unit if it has (or is likely to have) legal entities as children and then choose Grant with children.

  5. Highlight the new assignment and click on Revoke to remove the assignment.

  6. Reselect the node and choose Grant with children; it again adds a single entry, as shown in the following screenshot:

If another legal entity is placed as a child of this legal entity in the Organisation hierarchy, the user will inherit this role in that legal entity also.

The same follows for adding access to business units (which is okay if we have child entities that are legal entities). To remove access, select the entry to be removed and click on Revoke.

In Chapter 10, Setting Up and Managing Security, we will discuss security in more detail. Assigning roles to users is fine for a single, one-off adjustment or to make a short-term fix to the security, but for larger organizations, it will more likely be done from the perspective of the role.


Just because AX allows you to do something, it doesn't mean it is always the best method of doing it!

See also

For more information on security, please see Chapter 10, Setting Up and Managing Security


Assigning profiles to users

A profile, simply put, is the home page the users see on the Enterprise portal or when they first log in to AX.

Getting ready

You need to log in to AX as a system administrator and your Windows account must have permission to use SharePoint (that hosts the Enterprise portal).

If the users were added using the Active Directory import wizard, this task would have already been done.

First, navigate to System administration | Common | Users | Users.

How to do it...

Carry out the following steps to assign profiles to users:

  1. On the Users list page, locate a user and click on Profile.


    If you want to see what the user will see with this profile, you can click on View role centre. This will open your web browser and show you a view of the role centre as seen on the Enterprise portal.

  2. Select the profile you want the user to be a member of and click on Add user. This will open up the following screenshot:


    This form doesn't acknowledge that it was opened in the context of a user, and prompts for entering the User ID value again, as shown in the preceding screenshot.

  3. Choose the user in the User ID field.

  4. To make the profile specific for one or more companies, choose Select companies, which enables the Companies grid (previously, we used the term legal entities, which is the term used for companies in the context of security).

  5. Mark the companies in which you wish to have this profile, and then click on OK.


    Only make the profile assignment per company if this is needed. The profile only determines the contents of the home page and does not affect the security rights of the user.

How it works...

The sole function of this is to determine what will be the home page for the user. The standard profiles are based on roles designed by Microsoft and may not match your organization's needs. You, therefore, may invest in having roles customized or developed for your organization matching your security roles. In AX, as is standard, they are divorced, allowing you to choose a profile to which the user has no access.


Managing users by PowerShell commands

As mentioned earlier, you can use PowerShell commands to manage users within AX. These commands come on their own when used to automate the management of user accounts from the Active Directory. Many management utilities can leverage PowerShell scripts. This joins up nicely with the user workflows.

Getting ready

To optimize the model store, you should prepare by carrying out the following steps:

  1. Ensure that you have the Dynamics AX 2012 Management Shell installed on the computer you wish to use.

  2. Ensure your Windows account has administrative permissions on the local computer.

  3. Ensure your Windows account has access to read from the Active Directory.

  4. Ensure your Windows Account is mapped to a user in AX that has system administrator rights.

How to do it...

The following steps need to be performed within the Microsoft Dynamics AX 2012 Management Shell, which is the PowerShell with the AX PowerShell commands preloaded:

  1. Open the Management shell.

    • For Windows 8 or Windows Server 2012: Search for Management shell and click on the result, Microsoft AX 2012 Management Shell

    • For Windows 7 or Windows Server 2008: Open Administration Tools from the Windows Start menu and open Microsoft AX 2012 Management Shell

  2. Create an AD user for Binary\Josh by using the following command:

    New-AXUser -AccountType WindowsUser -AXUserId Josh -UserDomain "Binary.local" -PartitionKey initial Enabled -UserName Josh -Company HHF
  3. Disable user Josh by using the following command:

    Disable-AXUser –AXUserId Josh
  4. Enable user Josh by using the following command:

    Enable-AXUser –AXUserId Josh –Server Zeus
  5. Make Josh the system administrator by using the following command:

    Add-AXSecurityRoleMember –AxUserId Josh –AOTName SysAdmin

How this works…

Each command communicates with AX via the management framework; it knows which AOS to connect to because of the active client configuration. You can't specify a server and database name here as you can for model store operations.

See also


User groups, what happened?

User groups were a central part of user security in all the previous versions of Dynamics AX. If you upgrade an earlier version of AX, these groups are maintained but no longer have any role in the assignment of security privileges. Microsoft has a developed a new security model that is no longer based on user group membership.

They still have some use in areas that haven't been integrated into the organizational framework for example, posting restrictions on ledger journals where you specify the user group that is allowed to post the journals.

Getting ready

You should be logged in to AX as a system administrator.

How to do it...

To create and maintain user groups, navigate to System administration | Common | Users | User Groups and carry out the following steps:

  1. Press Ctrl + N to create a new group.

  2. Enter the ID of the group, which is limited to 10 characters. For example, ICTrfApp, as shown in the following screenshot:

  3. Enter the description in the User group name field; for example, Intercompany transfer approvers.

  4. Select the Users tab.

  5. Select the users who are to be added to the group (press Ctrl or Shift to select multiple users), as shown in the following screenshot:

  6. Click on the chevron pointing left, or drag the mouse to the left list.

  7. When finished, continue creating new user groups or close the form.

How it works…

This simply allows you to associate a user with one or more user groups. The requirements of user groups will come from configuration workshops for features not associated with the organizational framework.

About the Author

  • Simon Buxton

    Simon Buxton has worked with Dynamics 365 for Operations since its earliest incarnations, starting out as a consultant and developer in early 1999 when Dynamics 365 for Operations was known as Damgaard Axapta 1.5. He quickly became a team leader at Columbus IT Partners and carried out one of the first Axapta implementations in the UK before joining a new reseller, Sense Enterprise Solutions, as its technical director. Sense Enterprise Solutions enjoyed a global reach through the AxPact alliance, where Simon was placed as AxPact's Technical Lead.

    Simon played a major role in growing the company into a successful Microsoft partner and was the Technical Lead on a number of highly challenging technical projects around the world, ranging from the UK, to Bahrain, to the USA. These projects include developing solutions for third-party logistics, multichannel retail, and eventually developing an animal feed vertical, as well as integrating Dynamics 365 for Operations into production control systems, government gateways, and e-commerce solutions, among others. Now, working with Binary Consultants, he was part of a team that implemented the first Dynamics 365 for Operations implementation with support from Microsoft as part of the Community Technical Preview program (CTP). The knowledge gained as part of this process led to the creation of this book.

    Simon has also worked on Mastering Microsoft Dynamics AX 2012 R3 Programming and Microsoft Dynamics AX 2012 R2 Administration Cookbook.

    Browse publications by this author

Latest Reviews

(1 reviews total)
Microsoft Dynamics AX 2012 R2 Administration Cookbook, MICROSOFT DYNAMICS AX 2012 R3 SECURITY are good for reference
Microsoft Dynamics AX 2012 R2 Administration Cookbook
Unlock this book and the full library for $5 a month*
Start now