Automating the update like...
Automating the update like…

Now that Microsoft will also update additional Dynamics 365 Finance and Operations Sandbox environments, partners and customers will only need to take care of updating cloud-hosted environments, as we’ve always done.

I’m sure each team manages this differently, maybe leaving it to each developer to update their VM, or there’s someone in the customer or partner side that will do it. That’s in the best cases, maybe nobody is updating the developer machines…

If you want to know more about builds, releases, and the Dev ALM of Dynamics 365 you can read my full guide on MSDyn365 & Azure DevOps ALM.

Today, I’m bringing you a PowerShell script that you can run in a pipeline that will automatically update all your developer virtual machines!

Update script

As I’ve already done many times, I’ll be using Mötz Jensen‘s to run all the operations.

This is the complete script:

Now let’s take a look at the steps.

Authenticating and getting environments

The first step will be authenticating to LCS with the Get-D365LcsApiToken cmdlet and getting a list of all our environments with Get-D365LcsEnvironmentMetadata. This includes the sandbox and prod environments, but don’t worry, these won’t be updated.

In the last line, we’ll be initializing an array to store the IDs of started environments in the next step.

Starting developer VMs

Now that we have a list with our environments, we need to start only the cloud-hosted ones. We will attain this by looping through the list we got in the first part and filtering on the EnvironmentType property where it equals DevTestDev. And using the Invoke-D365LcsEnvironmentStart cmdlet we will start each VM.

Next we will check if the operation succeeds, or it doesn’t. When we’ve done this for all VMs, we’ll call the Start-Sleep cmdlet and give 3 minutes to the VMs to start.

Trigger the updates

In the final part, we will start deploying the update to each running VM. Looping through the array we created in the beginning, we’ll use the Get-D365LcsEnvironmentMetadata command to get the status of the VM, and if it’s running we’ll start the deployment using the Invoke-D365LcsDeployment cmdlet.

If the operation succeeds, we’ll remove that environment from the array and continue, otherwise we’ll try again up until three times (note that everything is inside a Do-While loop).

And after this we should see all our dev VMs servicing on LCS.

Running it in a pipeline

Once the script is working, running it in a pipeline is totally trivial, and you can do it in a build or a release pipeline, it’s up to you. My pipeline looks like this:

Update pipeline
Dev update pipeline

I’m installing in the first step with the following script:

And in the second task, I’ll be running the update script we’ve just seen at the beginning of this post.

Of course, you can do it all in a single task, but I prefer to split it in two because it looks prettier to me.

Remember this isn't the kind of automation we're interested in
Remember, this isn’t the kind of automation we’re interested in

Some advice


Of course, if you run this in a pipeline DO NOT put the service account credentials there, either use an Azure Key Vault or a variable group with secret values in your pipelines’ library:

Update VMs using pipelines and 1
AZDO pipelines library variable group

Not so automated

Of course, the only really automagic part of this is the starting and updating of the VMs. When the servicing is done, you need to stop the VMs. You can also run a pipeline that stops them after X hours, that’s up to you.

Also, if servicing fails you have to resume the operations or fix whatever is wrong and resume them, that’s pretty manual.

And that’s all, I hope this helps, specially if you have lots of CHE VMs because updating all of them manually is a bit slow if you have to do it from LCS.


Receive an email when a new post is published

Write A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.