Deploying from DevOps the right way: enabling External Deployment in OnPrem Business Central environments

It seems that lately, I’m only able to blog about something when I have a tool to share.. . That needs to change .. :-/. But not today. Today, I’m going to share yet another tool that we at the ALOps-team have been working on to serve many of our customers. And we decided to share it with the community. The tool is free, it will stay free … but, there is a …


The tool is a hack, nothing more than that. We simulate the behavior of what we think happens on the SaaS environment when you upload an Extension through the Automation API. So, the tool is “as is”, there is no official support other than me not want you to suffer problems with it ;-). There is a github where you can share your feedback.
The tool is dependent on how Business Central will evolve in this matter – and we hope this will “just work” for many updates to come. It will work on an decent install of Business Central. Not on any kind of Copy/Paste or other non-standard installation.

Deploying extensions from DevOps, without a build agent at the customer site

The official statement from Microsoft for deploying apps from DevOps to your OnPrem Customers is: install a DevOps build agent. As you might know, build agents sometimes act not the way you want – and having to maintain a bunch on infrastructure that is not 100% under your control, isn’t something that you want either. Customers might install a windows update, or .. do whatever that makes your release pipeline not run anymore…

But what if…

.. we could just enable the Automation API (because, as you know, there is an ability to publish extensions with it) for OnPrem customers, and use that in our DevOps for our CD pipelines?
Well .. using the Automation API to publish an extension, is quite the same as using the “Upload Extension” action on the “Extension Management” page in Business Central:

Thing is – that doesn’t work OnPrem. So in a way – the “Upload Extension” functionality in the Automation API doesn’t work OnPrem either. The action simply isn’t available. And if you would run page 2507 (which is the upload wizard page) manually, it would simply show you the following message when you would try to upload an extension:

So – the question is .. How do we enable “External Deployment”.
Well, it’s just a setting on the Server Instance, by pointing to some kind of API Endpoint that the NST will call when anyone would upload an extension.


So, we created a PowerShell module, that makes it pretty easy to enable the External Deployer on any OnPrem environment. In fact, with 4 lines of PowerShell, you’ll have it up-and-running! Run this PowerShell on the environment that is running your NST where you would like to deploy to.

1. Install ALOps.ExternalDeployer: this will install the PowerShell module on the machine

install-module ALOps.ExternalDeployer -Force

2. Load the module: this will simply load the necessary commandlets in memory:

import-module ALOps.ExternalDeployer 

3. Install the External Deployer: this will install an agent that will take care of the app-publish and install whenever you upload an app through the Automation API, or the upload page.


4. Link the ExternalDeployer to right NST: it will update and restart the NST with the settings needed for the External Deployer.

New-ALOpsExternalDeployer -ServerInstance BC


The easiest way to test it is to simply upload an extension through the Upload Extension wizard in Business Central. Thing is, in Business Central, the page isn’t accessible, but you can easily run any page by using the parameter “?page=2507” in the Webclient URL.
So – just run page 2507 to upload an Extension. Now, you’ll get this message:

That’s looking much better, isn’t it?
Next, since the “Deployment Status” isn’t available either from the “Tell Me”, you can also run that page by providing this parameter in the url: “?page=2508“.
Even if the upload would have failed, you get information in the page, just like you would in Business Central SaaS:

AND you can even drill down:

So .. It works! And this also means it will work through the Automation API. You can find all info on how to do that here:

And if you would like to do that with ALOps …

Well, pretty easy. There is an ALOps step “ALOps Extension API“, which has all necessary parameters to deploy. Just provide the right parameters, like:

  • API Interaction: Batch Publish (if you’d like to publish more than one extension at the same time)
  • API Endpoint
  • API Authentication

And you’re good to go! Here’s an example of one of our pipelines:

In our company, it’s all we use today. All deployments to all customers are using this external deployer. So rest assured – it’s well tested and very much approved ;-).

5.00 avg. rating (98% score) - 4 votes

Permanent link to this article:


5 pings

Skip to comment form

    • rovelgoenne on June 18, 2020 at 9:54 am
    • Reply

    Great post! One question: is this also possible within a docker container?

      • waldo on June 18, 2020 at 12:20 pm

      Absolutely – we mainly use it within containers 😉

  1. Hi Waldo. This is a great feature – and tested it on my local where it did the job, However wee have a multitenant demo environment where it seams to try and publish to “default” tenant – is there any way you can use this in a multitenant environment. Thx.. Richard

      • waldo on June 22, 2020 at 3:25 pm

      It should work for tenants – we are using it for MT .. . How are you uploading your apps?

  2. Using the page 2507 as you describe directly from the role center (added as action in our demo role center).

    The funny part is that if I look at the error message that i get I can see that the tenant Id is “default” and that is why it fails.

      • waldo on June 26, 2020 at 12:18 pm

      At this point, BC doesn’t allow this, I’m afraid. So it’s also not possible in this version.. . We might have a workaround, but we’re not sure it will work. . .

  3. This is a great feature I must say. Thanks for the update.

    • Todd Scott on July 20, 2020 at 2:18 pm
    • Reply

    Is there a way to tell what BC Server Instances have been configured using New-ALOpsExternalDeployer -ServerInstance BC? I have a few customers on our server and would like to know which ones have been configured.

    • Todd Scott on July 20, 2020 at 2:50 pm
    • Reply

    Don’t suppose there is an API to import a FOB file?

      • waldo on July 20, 2020 at 4:04 pm

      Nope, sorry 😉

    • Robert on December 7, 2020 at 1:54 pm
    • Reply

    Okay, when you run New-ALOpsExternalDeployer it modifies the customsettings.config of the service tier to point at your service. This is okay, but I’m a little worried about the value of the “APIkey” you set. It’s obviously a pointer to the service tier, but there appears to be no actual authentication in it to prove that the connection as come from that service tier. This wouldn’t bother me too much if the port (7040) for deployment service were bound to localhost. However, it appears to be bound to and so will accept a connection from anywhere the firewalls allow.

    Is this correct, or does it have a way of configuring at least a simple magic-cookie into the configuration?

    • Mr. Dee on April 19, 2021 at 1:11 pm
    • Reply

    Hi there. If it’s free and as-is, why not release the code so others may learn / contribute in case we find something that doesn’t wor?

      • waldo on April 19, 2021 at 2:21 pm

      Because the code is not mine, and is based on a framework we don’t want to share.

      • Mr. Dee on April 19, 2021 at 4:24 pm

      OK, I understand. So if the deployer happened to happily deploy one app, but fails with HTTP500 on a second app, I have no real option to find out why?

      • waldo on April 19, 2021 at 7:00 pm

      Did you get that?
      The only thing it does it upload it in the Extension Management – which also happens in SaaS. So check the deployment status. Or your API endpoint.
      That should be all that can go wrong.

      Though, there is one more important part: the script that is installed when you install the module. The location, you can find with the command:
      cd (get-module alops.externaldeployer -ListAvailable).ModuleBase

      In de subdir “bin\PSScripts”, you’ll find the “deploy apps”. Changing the script changes the behavior of the externaldeployer, of course. Use at your own risk ;-). The deployapps will never result in an http-error, I guess. You just upload an app to an api, where the external deployer executes the PS script mentioned above.

      So .. basically, you have all code now :p

  1. […] Source : Waldo’s Blog Read more… […]

  2. […] might have read my previous blogpost on how to enable the “external deployment” in an OnPrem Business Central environment. Well, that post deserved an “extension” as I didn’t provide examples on how to […]

  3. […] might have read my previous blogpost on how to enable the “external deployment” in an OnPrem Business Central environment. Well, that post deserved an “extension” as I didn’t provide examples on how to […]

  4. […] might have read my previous blogpost on how to enable the “external deployment” in an OnPrem Business Central environment. Well, that post deserved an “extension” as I didn’t provide examples on how to […]

  5. […] Use Waldo's workaround and install straight from DevOps… This is the approach I recommend to everyone, if it is possible. In our cases it unfortunately […]

Leave a Reply

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

%d bloggers like this: