Enabling Users after a database refresh is a pain. Let's automate that away.

Re-enabling users in UAT after a data refresh from PROD can be annoying, especially if  you have to be granted access to the environment administrator's account. Let's work through one way of creating a pipeline in Azure DevOps to re-enable a list of users using D365.FO Tools, PowerShell and a few OData tricks.

First, Create an App Registration

You can use this link for a walkthrough. We only need a client ID and a client secret. Nothing else needs to be configured in Azure. This should be created in the same tenant as the environment we want to connect to.

Next, Add the App in F&O

Use this link to add the App Registration in F&O. We should select the environment administrator for the F&O user to guarantee that we'll always have access with a user that can manipulate other users. If we select a user that isn't enabled after a database refresh, our script won't work as expected.

Next, define the parameters for the Pipeline

The pipeline will have 3 major parts: The list of users to create/enable then apply sysAdmin to, the PowerShell doing the work, and the pipeline. All required assets can found here.  First, let's update the user list. users.csv should contain the users we want to create/enabled by user Id, Email, and identity provider. Next, we'll need to update enableUserPipeline.yml with appropriate variable values for the given environment. the YAML file has examples for each variable. If you have multiple non-prod environments, you will need one pipeline per environment to get this behavior. YAML pipelines cannot be passed in a variable from the pipeline definition in DevOps. Lastly, the PowerShell script requires no changes. It simply does what it's told with the given inputs for security and actions. 

That's It!

Once you get this setup, you'll be able to run this against 1 environment and the PowerShell script will create or enable all users in the .csv file then grant them sysAdmin. All you need to do is download everything here, update it for your environment(s), import the YAML into a build pipeline in Azure DevOps and you can grant yourself access. This is based on this article by Marijan Huljic but takes a slightly different approach.