[IDEA] YAML files to automate the provisioning of a Power Platform environment with creation of the service connection

[rpothin]

To be able to use a Power Platform environment in your ALM process, we need 3 things (if we want to use service principal authentication):

• a Power Platform environment (obviously)
• an application user on your Power Platform environment
• a Power Platform service connection in your Azure DevOps project

One way to achieve all this is with YAML files.

[BenediktBergmann]

Can we provide those within a YAML? Is this not stuff we have to do manually?

[rpothin]

Using the Azure DevOps CLI, it is possible to create a service endpoint using a configuration file (https://docs.microsoft.com/en-us/azure/devops/cli/service-endpoint?view=azure-devops#create-service-endpoint-using-a-configuration-file).

For the Power Platform environment provisioning and the creation of the application user for the service principal connection, I think there is different ways to achieve this.
The one I am working on is with the "Create environment" action in the Power Platform Build Tools. It seems that with that way it automatically creates the application user for the service principal connection. But for now, I am a bit stuck on this point because I created a sandbox environment on a trial tenant (without capacity for that kind of action) and know I am unable to delete it. I created a support request to see if I can have some help from Microsoft.

[rpothin]

I was in a meeting today were we talked about the management of applications registrations for the service principals.
One point came up: it is better to have a dedicated application registration for each environment.

Even if I can understand some reasons around that idea (security for example), I am not sure it will help to automate the provisioning of environments (even if we could, in theory, automatically generate application registrations with the right access).
Obviously if you work with a set of environments and that never change it will be ok.

As best practice, we could imagine having an application registration per category of environment.
Example:

• 1 application registration for dev environments with 1 environment by team member
• 1 application registration for test environments with 1 environment for UI unit tests and another for integration unit tests
  ...

What do you think @BenediktBergmann ?

[rpothin]

Can you confirm to me that the Create Environment task of the Power Platform Build Tools has been updated recently @BenediktBergmann? (see the screenshot below)

It seems that there is now everything we need to manage the creation of new environments directly from a pipeline.
What do you think?

[BenediktBergmann]

That is actually a good first step at least. I am still missing the option to install several languages. We usually have English as the base language and swedish as an additional language.

[rpothin]

Indeed, I think it is a good first step even if it does not cover all your requirements around languages.

Do you know if it is possible to add languages using PowerShell or a REST API?

[BenediktBergmann]

Regarding your comment about the App Registrations:
I don't see a problem with using different App Registrations for different environments. We just have to choose the correct connection. But I don't get the point in doing so either. What I have seen is one App Registration for Production and one for all the other environments. Feels like an overkill to have one per environment.

Regarding the language:
Unfortunately, I haven't found a possibility to do so, yet. There are not functions for that in none of the tools I look at at least.

[drivardxrm]

Hi Guys, you can look at this powershell package.
https://github.com/seanmcne/Microsoft.Xrm.Data.PowerShell

I never try this particular method but there is a function called 'Enable-CrmLanguagePack' that does exactly this.

We use this package regularly in our release pipelines for things like : disable autosave or other system settings

----EXAMPLE POWERSHELL SCRIPT---------
Param(
[string]$connectionstring
)

Write-Output "Installing Microsoft.Xrm.Data.PowerShell"
Install-Module -Name Microsoft.Xrm.Data.PowerShell -Scope CurrentUser -Force

#Write-Output "Installing Microsoft.CrmSdk.XrmTooling.CrmConnector.PowerShell"
#Install-Package -Name Microsoft.CrmSdk.XrmTooling.CrmConnector.PowerShell -Scope CurrentUser -Force

Write-Output "Connecting to CRM"
$conn = Get-CrmConnection -Verbose -ConnectionString "$($connectionstring)"

Write-Output "Fetching organizationid"
$organizationid = (Get-CrmRecords -EntityLogicalName organization -conn $conn -Fields organizationid).CrmRecords[0].organizationid

Write-Output "Changing setting on organization: $($organizationid)"

Set-CrmRecord -EntityLogicalName organization -conn $conn -Id $organizationid -Fields @{"isautosaveenabled"= $false; "isexternalsearchindexenabled"= $true; "useskypeprotocol"=$false}

$org = Get-CrmRecord -EntityLogicalName organization -conn $conn -Id $organizationid -Fields isautosaveenabled,isexternalsearchindexenabled,useskypeprotocol

---

[BenediktBergmann]

Thank you so much for the hint (again).

I will try it. I also found the request that is needed for installing/enablind languages - Its ProvisionLanguageRequest

[BenediktBergmann]

@drivardxrm: Another question you might have some tips on. Have you managed to opt an environment into the early access via a script?

[drivardxrm]

@BenediktBergmann that would be a very good one. Not sure if it's (easilly) scriptable.
I tried to enable it on a dev environment here is what I found with my good'ol friend Fiddler ;)

Here is the request that is sent when you click on the Enable button:
https://admin.powerplatform.microsoft.com/api/environments/{GUID_OF_ENV}/features/October2020Update/enable?geo=Na
*geo=Na must standfor NorthAmerica
**I guess Each update will have there own url (ex. October2020Update, April2021Update) etc..

The tricky part would be to assess when the upgrade process is finished in order to put it in a release pipeline.

By analyzing the request sent by the admin portal I think this could be achieved.
After enabling the feature, this request is sent at regular interval
https://admin.powerplatform.microsoft.com/api/environments/{GUID_OF_ENV}/features?geo=Na

The response gives the status of the upgrade in the AppsUpgradeState property
Upgrade in progress

Upgrade finished

Hope this helps,

[rpothin]

@BenediktBergmann I agree with you about the app registrations. I am like you and I think that one app registration per environment is overkill.

@drivardxrm thank you for the help!

Guys, perhaps we could create other issues for the points you talked about and keep this one for the first version of a group of yaml files for the provisioning of an environment with creation of a service connection. What do you think?

[rpothin]

@BenediktBergmann I have created the following issues for the other ideas we discussed in the thread of this one:

• [IDEA] Automate the installation of several languages for a Power Platform environment #14 Automate the installation of several languages for a Power Platform environment
• [IDEA] Automate the activation of the early access to a new major release for a Power Platform environment #15 Automate the activation of the early access to a new major release for a Power Platform environment

@drivardxrm I hope you will be ok with the fact I put the information you gave us in the description of these new issues.

[rpothin]

During the last tests of the YAML pipeline prepared for this issue, I always got an error about the 'canada' location that does not exist...

It is a really strange error.

I am currently doing my tests on a trial tenant without capacity, so perhaps the error come from that (there is a note regarding this point in the Microsoft documentation).

I will try to make other tests in a tenant with some capacity in the next days to see if the pipeline works better there.

[BenediktBergmann]

@rpothin: Please let me know if I could assist with something here. I might have access to different tenants with capacity.

[rpothin]

Thank you @BenediktBergmann, I found a place with capacity to make more tests.

But if you can test the pipelines in the current PR in a tenant where you have some capacity it could be great 😊

[rpothin]

I have been able to make a test in a tenant with capacity, but unfortunately, I get the same error: The region 'canada' is invalid. Please enter the valid region or select from the picklist

You can find below some details around the error I got configuring a simple pipeline with the Classic UI:

[...]
2020-12-14T03:22:33.3388178Z ##[debug]Token for https://service.powerapps.com/ is either missing or expired. Acquiring a new one.
2020-12-14T03:22:34.1624160Z VERBOSE: InProcBindingRedirect: 4 - looking to resolve assembly: System.Management.Automation.resources, 
2020-12-14T03:22:34.1625268Z Version=3.0.0.0, Culture=en-US, PublicKeyToken=31bf3856ad364e35
2020-12-14T03:22:34.2365287Z ##[debug]Leaving D:\a\_tasks\PowerPlatformCreateEnvironment_9788ca49-dc8f-4d6b-bd5a-bab0fed0bc0c\0.0.23\CreateEnvironment.ps1.
2020-12-14T03:22:34.2428060Z ##[debug]Caught exception from task script.
2020-12-14T03:22:34.2462329Z ##[debug]Error record:
2020-12-14T03:22:34.3052614Z ##[debug]Get-RegionKey : The region 'canada' is invalid. Please enter the valid region or select from the picklist
2020-12-14T03:22:34.3064747Z ##[debug]At D:\a\_tasks\PowerPlatformCreateEnvironment_9788ca49-dc8f-4d6b-bd5a-bab0fed0bc0c\0.0.23\CreateEnvironment.ps1:223 char:25
2020-12-14T03:22:34.3076810Z ##[debug]+         $locationName = Get-RegionKey -Region $locationName
2020-12-14T03:22:34.3090705Z ##[debug]+                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2020-12-14T03:22:34.3102266Z ##[debug]    + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
2020-12-14T03:22:34.3114142Z ##[debug]    + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-RegionKey
2020-12-14T03:22:34.3125235Z ##[debug] 
2020-12-14T03:22:34.3143680Z ##[debug]Script stack trace:
2020-12-14T03:22:34.3177909Z ##[debug]at Get-RegionKey<Process>, D:\a\_tasks\PowerPlatformCreateEnvironment_9788ca49-dc8f-4d6b-bd5a-bab0fed0bc0c\0.0.23\CreateEnvironment.ps1: line 21
2020-12-14T03:22:34.3189335Z ##[debug]at <ScriptBlock>, D:\a\_tasks\PowerPlatformCreateEnvironment_9788ca49-dc8f-4d6b-bd5a-bab0fed0bc0c\0.0.23\CreateEnvironment.ps1: line 223
2020-12-14T03:22:34.3200656Z ##[debug]at <ScriptBlock>, <No file>: line 1
2020-12-14T03:22:34.3211925Z ##[debug]at <ScriptBlock>, <No file>: line 22
2020-12-14T03:22:34.3223421Z ##[debug]at <ScriptBlock>, <No file>: line 18
2020-12-14T03:22:34.3234785Z ##[debug]at <ScriptBlock>, <No file>: line 1
2020-12-14T03:22:34.3253657Z ##[debug]Exception:
2020-12-14T03:22:34.3292856Z ##[debug]Microsoft.PowerShell.Commands.WriteErrorException: The region 'canada' is invalid. Please enter the valid region or select from the picklist
2020-12-14T03:22:34.3349518Z ##[error]The region 'canada' is invalid. Please enter the valid region or select from the picklist
2020-12-14T03:22:34.3351268Z ##[debug]Processed: ##vso[task.logissue type=error]The region 'canada' is invalid. Please enter the valid region or select from the picklist
2020-12-14T03:22:34.3364813Z ##[debug]Processed: ##vso[task.complete result=Failed]
2020-12-14T03:22:34.3844172Z ##[section]Finishing: Power Platform Create Environment 

Do you have an idea regarding this error @BenediktBergmann ?

I did not find anything about the Get-RegionKey PowerShell function that seems to be at the origin of this error...

[rpothin]

Just to avoid any confusion, I want to precise I am using the out-of-the-box Power Platform Create Environment action of the Power Platform Build Tools extension in that scenario.

[mjfara]

Having the same issue, any workarounds?

[rpothin]

Hey @mjfara,

I created a support request few weeks ago, but it is still in investigation.
As soon as I will have good news to share with you, I will post it here.

[mjfara]

Thanks I'd appreciate that.
A final blocker for our team is being able to reset or spin up a clean build environment using a service principal for authentication.

[rpothin]

@mjfara there is perhaps a workaround using one of the latest versions of the Microsoft.PowerApps.Administration.PowerShell module in PowerShell.

I will try to make some tests this weekend and I will let you know the results.

I think you are at the right place for what you are trying to achieve. The goal of this issue is to prepare a pipeline in yaml to facilitate the creation of a new environment with its service connection in Azure DevOps.

[mjfara]

Ya we've been using a workaround in powershell, but we have to be logged in as a user, since the service principal does not have access to environments outside of the one it is associated with. Seems like we need a tenant-level service principal or something similar.

But as you mentioned, having this all in the yaml pipeline would be ideal.

[rpothin]

Hello everyone,

For your information, the error I had with the Power Platform Create Environment action in the Power Platform Build Tools extension for Azure DevOps seems corrected.
I will try to resume my work on this issue in the upcoming days to be able to merge it to the main branch.

[rpothin]

Hello everyone,

My last tests tonight have shown a new error in the Create Environment task of the Power Platform Build Tools extension.
The Domain name provided is not used...

I will try to push this issue to Microsoft to be able to resolve it as soon as possible.

[Olivia-devops]

Hello @rpothin,

I also use the PowerApps create environment task in Azure DevOps and get the error: The region 'canada' is invalid. Please enter the valid region or select from the picklist.

I noticed that you mentioned Microsoft.PowerApps.Administration.PowerShell, but I don't know how to use it. Would you mind telling me more about it? Any help would be appriciate.

[rpothin]

Hey @Olivia-devops,

I am sorry I did not answer earlier.
I have made a test yesterday using the Create Environment task in the Power Platform Build Tools extension, but did not took the time to answer 😓
I got an error (different of yours) but the environment was created not taking account of the Domain name provided. Obviously, it is not the expected behavior.

I will try to contact Microsoft to let them know that the fact the Create Environment task in the Power Platform Build Tools extension is so unstable make it impossible to use...

In the same time, we can use:

• Microsoft.PowerApps.Administration.PowerShell > New-AdminPowerAppEnvironment
  • I am currently working on something that could help you understand how to use it: New-DataverseEnvironment
  • Here is another example showing you how to use it: workspace-initialization-when-issue-assigned.yml - Add Power Apps account & Create Power Apps environment step
• Microsoft Power Apps CLI > Admin > create - I do not currently have examples for this one, but I will need to take a look at it in the future

I hope all this will help you.

[Olivia-devops]

Hello @rpothin, thank you very much!