Creating test users for an isolated D365FO Development VM

 In Dynamics 365, Dynamics AX

As part of developing a new functionality in D365FO, it is necessary that a third person (normally a consultant or a key user) tests such functionality in order to validate it (mark it as “good, it works”). Ideally, it should be done using both data and permissions as realistic as possible. An interesting option is being able to test it directly in the Dev VM itself, before releasing to other environments, so those changes can be quickly done and tested, and development and validation can be considerably speeded up.
Usually, this can be done just by starting D365FO web client from Visual Studio, setting a certain VS project as “Startup project“:

Inside of it, setting an object as “Startup object“:

Y clicking “Start“:

But sometimes this is not enough. If we want to test this functionality under a certain permissions set, we cannot do it this way: by definition, admin user (which is the one logged from Visual Studio) is not applied any security role. So, we cannot do any test with it. We need to test it with another, non-admin user, to which we can assign such permissions.
To do so, we can, following this order:

  1. If we’re already working from Visual studio, we already have it. But if not, we must set admin user (which, as mentioned above, is the effective user when launching web client from Visual Studio). To do so, we must use “Admin User Provisioning” tool provided in the VM (Note: it is necessary that admin user email belongs to any AAD domain):From now on, we should be able to log into D365FO web client using this email and password. Once we’re in, we can check that we’re in as admin user by checking upper right corner in the web browser: 

  2. Now, we must create test user (which will NOT be admin user). To do so, we browse “System Administration>Users>Users“, and click “New“:
    Notice that, in this version, authentication has moved from Active Directory to Active Directory Federation Services (ADFS). Making it simple, it means that we must additionally specify an authentication provider for the newly created user:
  3. As DEV VM is “isolated” (not belonging to any Windows domain), we can use an email to identify the user. We’ll write such email both in “User name” and “email” slots. For Authentication Provider (“Provider”) slot, we’ll have to use:
      1. If email AAD domain has its own authentication provider, we’ll user its URL (e.g., If we dont’ have this information, we’ll probably have to ask for it to IT department.

    If AAD domain has not its own authentication provider, then:

    1. If user email AAD domain is the same as admin user AAD domain:
    2. If it’s not (i.e., it belongs to another AAD domain), we can user AAD generic auth provider:, being XXXXX.XXX email domain (e.g,

    There is another interesting option, which is using a Microsoft account: as an example, this is the one we’re using when logging Skype. In this case, authentication provider URL follows “another AAD domain” pattern, this is,, for XXXXX.XXX to be email address domain.
    En este ejemplo hemos usado una cuenta (que es una cuenta Microsoft). Tendremos entonces que asignar como proveedor de autenticación Si tienes una cuenta en, o aún conservas una antigua de, puedes usarlas:

    Theoretically, this should work for any email address which is linked to a Microsoft account. In our tests, we’ve been able to use a email account, which has been previously linked to a Microsoft account. Please notice that password must be the one for Microsoft account, not the one for email acccount which, as a generar rule, is NOT the same as email account password (for and, however, it is).

    Now,we can assign the new user necessary security role, as necessary. As a minimum, it will need “System user”.

If we did it well, from now new user will be able to log into VM D365FO instance to perform any tests according to granted permissions.

Enjoy 😉

José Miguel Guisado

Recommended Posts

Leave a Comment