Set-D365Admin command is not working on a new cloud hosted dev environment

[jrrld]

Tried to execute Set-D365Admin "[email protected]" seems not working on a newly deployed cloud hosted dev environment.

Could you please confirm if this command will work on newer cloud hosted dev environment provisioned though LCS?

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/access-instances#frequently-asked-questions

[FH-Inway]

Hello @jrrld , thanks for reporting this. The Set-D365Admin cmdlet uses the same functionality that the standard Admin user provisioning tool uses. Since Microsoft does not support that tool anymore on LCS provisioned environments, the cmdlet won't work either on those environments.

That said, the Microsoft documentation describes in https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/access-instances#how-can-i-fix-my-existing-environment-when-my-environment-is-in-a-failed-state-or-i-am-getting-sign-in-errors the steps that need to be taken after the Admin user provisioning tool was used on a LCS provisioned environment to fix the issues caused by it.

Would you be interested in working with us to modify the cmdlet so that it executes those steps when it is executed on a LCS provisioned environment?

@Splaxi Do you have concerns about enabling the cmdlet to do something that Microsoft does not want us to do anymore? My thought is that as long as Microsoft provides documentation on how to do it anyway, it is fair game for the d365fo.tools 😄

[jrrld]

Hi @FH-Inway, thanks for your reply. I don't have any experience modifying cmdlet, but I am willing to help to make it work on newer dev boxes.

Thank you.

[jrrld]

Hi @FH-Inway, my colleague tried to deploy a 10.0.25 dev box and Set-D365Admin command works on his end. But my dev box for some reason does not allow me to sign in ("Error: AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application.")

[FH-Inway]

@jrrld The issue occurs when the user/e-mail that is used with the Set-D365Admin cmdlet or the Admin user provisioning tool is in a tenant that is different from the tenant of the user who deployed the LCS environment. I suspect that your colleague used an e-mail from the same tenant, which is why they don't have the issue.

Could you try to do the steps from https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/access-instances#how-can-i-fix-my-existing-environment-when-my-environment-is-in-a-failed-state-or-i-am-getting-sign-in-errors to validate that those resolve the issue?

[Splaxi]

@FH-Inway

As long as there are official guidelines and docs to support what we are doing, then everything is fair game in my book 😉 But I must say that it feels like Microsoft has had quite some support incidents where customers and partners have ended up in a unsupported scenario. Otherwise they would be removing the file and write e-mails, when they see that a LCS deployed VM is re-configured to different AAD.

As long as the original cmdlet is working on VHD based developer machines, we should keep it as is. But we can totally work towards supporting the new guidelines and docs article.