Finance | Project Operations, Human Resources, ...

automate start and stop environments through Microsoft Dynamics Lifecycle Services (LCS)

(0) Share

Report

Posted on by skyjacker

Is there a way to automate the starting and stopping of environments through Microsoft Dynamics Lifecycle Services (LCS). I know I can turn off and back on the VMs from the Azure console, but it does not reflect the stopping and starting of the VMs in the LCS URL.

I have the same question (0)

All responses (7)

Answers (0)

Suggested answer

nmaenpaa 101,160 Moderator on at

Like (0)

Report

There's an API that you can call:

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/database/api/v1/reference-start-stop-environments

One way to call them is using D365FO.Tools community tools: https://msdax.wordpress.com/2021/01/11/d365fo-tool-automating-start-and-stop-environments/

Was this reply helpful? Yes No
skyjacker 10 on at

Like (0)

Report

I dont know how to do API calls to the LCS environment.

For the D365FO tool, I keep getting this error message,

[08:56:54][<Unknown>] Unable to locate the %ServiceDrive% environment variable. It could indicate that the machine is either not configured with D365FO or that you have domain joined a local Ti

er1. We have defaulted to c:\

[08:56:54][<Unknown>] This message will show every time you load the module. If you want to silence this message, please add the ServiceDrive environment variable by executing this command (rem

ember to restart the console afterwards):

[Environment]::SetEnvironmentVariable("ServiceDrive", "C:", "Machine")

[08:56:55][Invoke-Authorization] Something went wrong while working against Azure Active Directory (AAD) | The remote server returned an error: (400) Bad Request.

WARNING: [08:56:55][Invoke-Authorization] Stopping because of errors

Was this reply helpful? Yes No
nmaenpaa 101,160 Moderator on at

Like (0)

Report

And what exactly did you do before you got this error message? What command did you run? Did you look in d365fo.tools documentation?

Was this reply helpful? Yes No
skyjacker 10 on at

Like (0)

Report

I ran this command:

Get-D365LcsApiToken -ClientId “cdbb2d84-bf0b-406f-9195-xxxxx” -Username “xxxxx” -Password “xxxxx*” -LcsApiUri “lcsapi.lcs.dynamics.com” | Set-D365LcsApiConfig -ProjectId 136xxxx

Was this reply helpful? Yes No
Motz Jensen 190 on at

Like (1)

Report

Without knowing all the details, here is a link, that the entire community is using as reference for these things: ariste.info/.../

It is a wall of text, but you should be able to see how he made sure the Registered Application in the Azure AD was created correctly. Which brings me to some of the things that you should look into:

Do you already use the Registered Application for any of the official tasks in Azure DevOps? This is to tell us if you have configured the basis inside Azure AD, or we have to ensure that you have all the details in place.

Did you grant the "Dynamics Lifecycle services" API permission for the Registered Application?

Did you "Allow public client flows" under the Authentication inside Azure AD?

Are you sure that the LCS instance that you're assigned to is in fact the US based and not one of the 8 other available instances?

Try it one more time, the command that you shared. But right after it fails, write:

$error

and share the output from that.

Was this reply helpful? Yes No
skyjacker 10 on at

Like (0)

Report

Do you already use the Registered Application for any of the official tasks in Azure DevOps? This is to tell us if you have configured the basis inside Azure AD, or we have to ensure that you have all the details in place. -- No

Did you grant the "Dynamics Lifecycle services" API permission for the Registered Application? -- Yea

Did you "Allow public client flows" under the Authentication inside Azure AD? -- Yes

Are you sure that the LCS instance that you're assigned to is in fact the US based and not one of the 8 other available instances? -- Now do I find which instance I am assigned to?

Try it one more time, the command that you shared. But right after it fails, write:

$error

and share the output from that. -- [15:40:44][Invoke-Authorization] Something went wrong while working against Azure Active Directory (AAD) | The remote server returned an error: (400) Bad Request.

WARNING: [15:40:44][Invoke-Authorization] Stopping because of errors

Was this reply helpful? Yes No
Suggested answer

Dieter 127 on at

Like (0)

Report

I've experienced the same error when I was trying to execute a data restore from a D365 F&O tier 5 to a tier 2 environment.

"[Invoke-Authorization] Something went wrong while working against Azure Active Directory (AAD) | The remote server returned an error: (400) Bad Request."

The issue here was the password. It included a $ sign, which made the script think it was a variable and for reason left it out of the password value.

Also keep this in mind when entering the arguments in a DevOps pipeline. If the password has a $ sign in it, don't use double quotes.

Was this reply helpful? Yes No