Invoke-D365LcsEnvironmentStop "Unauthorized in starting a new deployment in LCS"

[harishmohanbabu]

Hi,

Trying to create a PS script for stopping a Tier1 VM. It is a simple PS script which has parameters for values such as client Id, user name, password etc.

Below is the snippet where I obtain the access token first and then the command for stopping the environment.

#Obtain oAuth access token from Azure active directory
Get-D365LcsApiToken -ClientId $ClientId -Username $UserName -Password $Password -LcsApiUri $Uri -Verbose | Set-D365LcsApiConfig

#Stop the environment
Invoke-D365LcsEnvironmentStop -ProjectId $LCSProjectId -EnvironmentId $EnvironmentId -LcsApiUri $Uri -RetryTimeout "00:01:00" -Verbose

And finally receive the below error -

[DBG]: PS C:\windows\system32>> 
VERBOSE: [13:23:46][Start-LcsEnvironmentStartStopV2] Invoke LCS request.
VERBOSE: POST https://lcsapi.lcs.dynamics.com/environment/v1/stop/project/<LCS Project ID>/environment/<Environment ID> with 0-byte payload
[13:23:47][Start-LcsEnvironmentStartStopV2] Error status code Unauthorized in starting a new deployment in LCS. Unauthorized. | The remote server returned an error: (401) Unauthorized.
WARNING: [13:23:47][Start-LcsEnvironmentStartStopV2] Stopping because of errors

The user is configured as environment owner in the LCS project and manually is able to start/stop the environment from the LCS. Any suggestions on how to resolve this issue, please. Thanks,

[FH-Inway]

Could you share the value of the -LcsApiUri parameter that is used?
Other than that, I'm not seeing any issues. You can try to check the output of Get-D365LcsApiConfig if that reveals anything out of order.

[harishmohanbabu]

The LcsApiUri is below -

$Uri = "https://lcsapi.lcs.dynamics.com"

[FH-Inway]

That looks like the default url, so that should be fine.
Are you sure the app registration is set up correctly (e.g. has the correct permissions)?

[FH-Inway]

Also let us know the version of the d365fo.tools module and the PowerShell version.

[FH-Inway]

Just tried the cmdlet with the newest version of d365fo.tools. Good news, it still works, so the issue is most likely caused by your setup.

One more thought, did the user login at least once into the LCS project?

[harishmohanbabu]

Hi,

PS version is 5.1.

d365.tools module is latest version as this was installed only this week.

Screengrab of the API permissions screen is below. Can you confirm this is correct, please.

[FH-Inway]

The permissions are correct, but I can see that admin consent does not seem to have been granted.

[harishmohanbabu]

Hi,
Thank for your replies so far. It took me a while to resolve the admin consent issue with the customer. Now, this permission has been granted.

However, regrettably I still get the below error -

[18:05:28][Invoke-Authorization] Something went wrong while working against Azure Active Directory (AAD) | The remote server returned an error: (400) Bad Request.
WARNING: [18:05:28][Invoke-Authorization] Stopping because of errors
VERBOSE: [18:05:28][Get-D365LcsApiToken] Total time spent inside the function was 00:00:00.4370005
VERBOSE: [18:05:28][Invoke-TimeSignal] The command 'Invoke-D365LcsEnvironmentStop' was already taking part in time measurement. The entry has been update with current date and time.
VERBOSE: [18:05:28][Invoke-TimeSignal] The command 'Start-LcsEnvironmentStartStopV2' was already taking part in time measurement. The entry has been update with current date and time.
VERBOSE: [18:05:28][Start-LcsEnvironmentStartStopV2] Invoke LCS request.
VERBOSE: POST https://lcsapi.lcs.dynamics.com/environment/v1/stop/project/<PROJECT ID>/environment/<ENVIRONMENT ID> with 0-byte payload
[18:05:29][Start-LcsEnvironmentStartStopV2] Error status code Unauthorized in starting a new deployment in LCS. Unauthorized. | The remote server returned an error: (401) Unauthorized.

Can you confirm if any further permission is required, please.

Thanks,

[FH-Inway]

Hm, tough one. Maybe @Splaxi has an idea?

I'm wondering why the error message says "Unauthorized in starting a new deployment in LCS". That doesn't seem to make sense for an API call to stop an environment.

I fear it will take some effort to narrow down possible causes. Try different users. Try different environments. Try different LCS projects. Try using the API directly. Try another app registration. Try to make the call from a different environment (maybe its some kind of firewall issue?).

You could also try asking the question in a different community or open a support request with Microsoft, though I recommend you try first to reproduce the issue with a direct API call. Microsoft will not support the d365fo.tools, though I'm almost certain that the issue is not with them.

Finally, is this you? https://www.yammer.com/dynamicsaxfeedbackprograms/#/users/318605615104
If so, I can direct message you there and offer to take a look in a screen sharing, if you are up for it.

[Splaxi]

So the "Unauthorized in starting a new deployment in LCS" is coming from the LCP API, which would indicate that you now have access to the API itself.

Could you try run some of the other commands for the API?

https://github.com/d365collaborative/d365fo.tools/blob/master/docs/Get-D365LcsEnvironmentMetadata.md
https://github.com/d365collaborative/d365fo.tools/blob/master/docs/Get-D365LcsEnvironmentHistory.md

If they are successful, then we can narrow things down a bit. Let me know how it goes. 🤞

[psdgal]

Hello,

we are experiencing the same issue while trying to deploy a package with Invoke-D365LcsDeployment. Also, Get-LcsEnvironmentMetadata does not work.

Other cmdlets, such as Get-D365LcsAssetFile are working fine.

Any idea why? Admin consent has been granted to the application.

Note: this project is in the European portal. Maybe this can be the issue? Anyone that can reproduce or has any experience with that?

[Splaxi]

You would need to share what API uri/url's that you are trying to work against.

And yes - if the project is in the EU geo, almost all LCS api's needs to be using the eu.lcs.dynamics.com notion.

[psdgal]

Yes,

we are using the following LCS API URI:

https://lcsapi.eu.lcs.dynamics.com

Snippet example:

$PSDefaultParameterValues = @{ '*-D365*:EnableException' = $true }

$tokenSplat= @{
    ClientId = 
    Username = 
    Password = 
    LcsApiUri = "https://lcsapi.eu.lcs.dynamics.com"
}

Get-D365LcsApiToken @tokenSplat | Set-D365LcsApiConfig -ProjectId xxx
Get-D365LcsDatabaseBackups

[Splaxi]

And you're sure that the username and password isn't MFA enforced?
You are sure that the ClientId (Registered Application / Service Principal) has the correct settings, in terms of API permissions and consent?
Not using a 3. party identity provider like OKTA?
Did read the ALM bible by Ariste, to make sure that you didn't skip some important setting? https://ariste.info/en/dynamics365almguide/welcome

Is it possible for you to proved that the above code works, against the US based LCS? I know it will be another customer and other details, but it will make it easier to compare settings and other stuff.

[psdgal]

It was as simple as assigning Project Owner to the service user in the project settings. Many thanks for the help anyway :)

[FH-Inway]

@psdgal Thanks for the feedback. The Environment Manager role for the service user should also work.

@harishmohanbabu I reread the issue and had a new idea: If you try to deploy to a T1 environment, check its topology. Not all topologies allow deployment (I'm sure this is the case for the Build + Test topology, but others might have that restriction as well).