How to overcome the limitation ‘Deployment on Build VM is restricted’.

[udaymuppana]

Hi Team,
I might be referring to a known restriction from LCS API.
When I try to install the deployable package on Build VM (LCS Environment Sub-Type = Build) usingInvoke-D365LcsDeployment command, I am receiving the following error message
“ Deployment on Build VM is restricted ”

But I am not expecting the error message when the asset id belongs to Microsoft (GA or PEAP).
Any thoughts/techniques, on how to overcome this restriction.

Thanks in advance!!

[FH-Inway]

I don't think you can, because build environments are used to create deployable packages. To enable this, they need to control their state, i.e. they need to make sure that only functionality by Microsoft exists when they start the build. This way, they can differentiate between Microsoft functionality and your customizations.

If you really wanted to, you could download the deployable package from LCS using Get-D365LcsAssetFile and Invoke-D365AzCopyTransfer. Then install it with Invoke-D365SDPInstall.
Though I would strongly advise against doing so. This will break your build.

Maybe take a step back and tell us first why you want to do this?
A common scenario is third party packages and there is guidance on how they should be added to the build: Manage third-party models and runtime packages by using source control

[fhoo]

I agree with Florian about it's not possible, but not quite with the arguments why it is not possible through the API...

I don't see any difference in calling the deployment through the API compared to doing it manually through the LCS UI.
But also with the DevOps Pipeline Tasks it is not possible to start the deployment of a Service Update automatically, so I guess there is nothing the tools can do to circumvent this restriction.

And according to the replies in your Yammer thread, I'd not expect that anything will change.

[FH-Inway]

@fhoo is right and I misunderstood the question. I agree that the LCS API should allow the same actions that are available in the LCS UI. But unfortunately, they don't appear to do so and Microsoft does not seem to want to change this. And since the d365fo.tools are "just" a wrapper to more conveniently call the LCS API, we cannot change this either.
You can still use the workaround I described above. If you can ensure that it will only be used to install Microsoft packages, you should be good to go.

[udaymuppana]

Thanks @fhoo and @FH-Inway for your replies.
Actually, we are developing a small APP/UI internally to automate the package installation across all VMs in the organization.
The idea is to save time/efforts for these installation by introducing some automation, But unfortunately, BUILD-type VMs have big limitations. At least it is not possible even with the Asset Deployment task.

I requested Joris & Lane Swenka on Yammer , thread but unfortunately, Joris moved to another team, and this request lost the track.

If MS eliminates this limitation, This is really helpful for full-fledged automation.

Any suggestions from this forum, how to make this happen :)
@Splaxi

Regards,
Udaya Bhaskar.

[FH-Inway]

As I wrote above, you can do it by not using LCS. Instead, execute a PowerShell script directly on the BUILD environment that installs the package. Again, just make sure that this is only used to install packages with Microsoft updates and not any custom code.

If you really wanted to, you could download the deployable package from LCS using Get-D365LcsAssetFile and Invoke-D365AzCopyTransfer. Then install it with Invoke-D365SDPInstall.

I would also argue that the time and effort saved for automating at most seven updates a year on build environments may not be a good ROI for the time and effort involved in getting this to work. Doing it manually only takes a minute. Even times seven and assuming you maintain several build environments, we are talking at most a couple of hours a year. On the other hand, implementing an automation, testing it and maintaining it in several customer projects will take many hours if not days. Don't get me wrong, I'm all for automation, but I doubt this is your biggest manual task that could be automated.

[Splaxi]

You can roll your own solution using agents from inside Azure DevOps. They are installed locally on a specific VM, and then you can run PowerShell code. So if you can get things to work in powershell, directly on the VM, via a RDP connection - then the agents is the way to go.

But I'm going to say the same as Microsoft and @FH-Inway - Are you looking at the right problem? Are you using the right tools OR processes (human, tools, business) to solve whatever you are facing?

[udaymuppana]

Apologies for the delayed response, due to project switchings and holidays in between, I did not get time.

In principle, I believe I am looking at the right problem :). But I am not sure about the process/tools to pick.
I think similar design limitations is also there with "Asset Deployment task in DevOps pipeline" in context of Build VM.

I agree I am supposed to deal with MS directly. Thanks all for your valuable responses @Splaxi , @FH-Inway , @fhoo .

[udaymuppana]

Hi @Splaxi ,
Can you throw little light on your earlier proposed solution (Agents+ PowerShell based solution), I am interested in implementing it.

Do mean, build agents are trcik here ? Build agents also validating/limiting these package installations?
Excuse me in case my understanding is wrong.

Thanks in Advance.

[Splaxi]

How to get started with an Agent:
https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-windows?view=azure-devops

I would recommend that you start out with a small trivial task, to get a feeling on how things are working. Something like listing all users in the D365FO database or similar. When that works, from a pipeline, then you can focus on the real task at hand.

[FH-Inway]

@udaymuppana Take a look at https://www.yammer.com/dynamicsaxfeedbackprograms/threads/1842733917790208, the comments made today on that topic might be of interest to you.

[udaymuppana]

HI @FH-Inway , We lost access to yammer community for a couple of weeks due to some cross-geo limitations.
My IT team is still working on fixing it.

Is it possible to paste the screenshot of that yammer conversation here please.

Thanks,
Udaya Bhaskar.

[FH-Inway]

That would be a lot of screenshots, since it also includes a recording :)
I will try to summarize:

• The thread is about planned feature deprecations for some LCS functionality (this information is also public by now, see https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/get-started/removed-deprecated-features-platform-updates#lifecycle-services-lcs-features-deprecated-in-august-2022)
• Originally, they planned to deprecate the build topology for cloud/customer hosted environments, but thankfully, they postponed that

Regarding the build topology, @laneswenka writes:

In terms of the Build topology, we are investigating merging it with the Develop topology so that you can have a single topology to deploy and you can choose whether to connect it as a build agent. There is some work for us to do to merge these things together cleanly but that is likely the route we will take in the short term.

Remembering your question, I then asked:

Would this also remove the current behavior that prevents some deployable packages (most importantly service/quality updates) to be applied on a build environment when using the LCS API?

To which Lane answered:

Great point on the servicing aspect, we'll need to evaluate and see if there is still reason to keep that restriction in place if the Dev topology is registered as a build agent.

[udaymuppana]

Thanks a ton, @FH-Inway , these are really interesting points :).