ALOps.ExternalDeployer: Deployment failed if 2 BC versions installed on one server

[petertijsma]

Hi,

Since a few days, we now have a Test BC20 instance installed on our server next to a couple of BC18 instances.

I've now also setup the ALOps External Deployer using the command: New-ALOpsExternalDeployer -ServerInstance CLIENT-CLEANBC20

But, now when i check the release pipeline for our BC18 instance, all of a sudden the deployment fails. When checking the deployment status page, it gives this error:

The Dynamics 365 Business Central Server Administration tool can only manage version 20.0. The ServerInstance 'MicrosoftDynamicsNavServer$ODATA-ACP' is Version '18.0.30479.0'

Isn't it possible to use 2 versions on one machine when using the ALOps Extension API?

When deep diving the Powershell scripts, is see that a Server Instance could be provided as parameter, but no clue from where I could set this up. Currently it looks like it's not provided at all:

2022-08-06T09:15:56.0853070Z *** Import NAV/BC Management DLL's
2022-08-06T09:15:56.0904831Z *** ServiceTier not specified, loading default assemblies.
2022-08-06T09:15:56.0959682Z *** Default Assemblies not found. Load via BC-Artifacts
2022-08-06T09:15:56.0997064Z *** Install/Update BCContainerHelper [https://github.com/microsoft/navcontainerhelper]
2022-08-06T09:15:56.1035137Z *** Check BcContainerHelper
2022-08-06T09:15:56.1347914Z *** Load BcContainerHelper
2022-08-06T09:15:56.2918143Z BcContainerHelper version 2.0.19
2022-08-06T09:15:56.9553768Z 
2022-08-06T09:15:56.9554630Z ModuleType Version    Name                                ExportedCommands                                             
2022-08-06T09:15:56.9555100Z ---------- -------    ----                                ----------------                                             
2022-08-06T09:15:56.9555547Z Script     2.0.19     BcContainerHelper                   {Add-FontsToBcContainer, Add-GitToAlProjectFolder, Backup-...
2022-08-06T09:15:56.9590783Z ##[command]"Get-BCArtifactUrl" 
2022-08-06T09:15:56.9591190Z Name                           Value                                                                                   
2022-08-06T09:15:56.9591521Z ----                           -----                                                                                   
2022-08-06T09:15:56.9591855Z select                         Latest                                                                                  
2022-08-06T09:15:56.9592188Z type                           OnPrem                                                                                  
2022-08-06T09:15:56.9592523Z country                        W1                                                                                      
2022-08-06T09:15:56.9593345Z 
2022-08-06T09:15:56.9593399Z 
2022-08-06T09:15:56.9593588Z  -select: Latest -type: OnPrem -country: W1
2022-08-06T09:15:58.9847950Z *** Platform: C:\bcartifacts.cache\onprem\20.4.44313.44365\platform
2022-08-06T09:15:58.9880578Z *** Localisation: C:\bcartifacts.cache\onprem\20.4.44313.44365\w1
2022-08-06T09:15:59.0164386Z *** BC Management DLL: C:\bcartifacts.cache\onprem\20.4.44313.44365\platform\ServiceTier\program files\Microsoft Dynamics NAV\200\Service\Microsoft.Dynamics.Nav.Management.dll
2022-08-06T09:15:59.0557618Z *** BC App Management DLL: C:\bcartifacts.cache\onprem\20.4.44313.44365\platform\ServiceTier\program files\Microsoft Dynamics NAV\200\Service\Microsoft.Dynamics.Nav.Apps.Management.dll
2022-08-06T09:15:59.0755091Z *** BC NCL Management DLL: C:\bcartifacts.cache\onprem\20.4.44313.44365\platform\ServiceTier\program files\Microsoft Dynamics NAV\200\Service\Microsoft.Dynamics.Nav.Ncl.dll
2022-08-06T09:15:59.3560534Z *** BC Types DLL: C:\bcartifacts.cache\onprem\20.4.44313.44365\platform\ServiceTier\program files\Microsoft Dynamics NAV\200\Service\Microsoft.Dynamics.Nav.Types.dll
2022-08-06T09:15:59.3573025Z *** Batch Publish Extensions
2022-08-06T09:15:59.3584816Z   * Artifact Path  : F:\ADOAgents\Agent1\_work\r28\a\_OGDT Core
2022-08-06T09:15:59.3757557Z *** Resolved Path  : F:\ADOAgents\Agent1\_work\r28\a\_OGDT Core
2022-08-06T09:15:59.3769722Z *** Get Available Applications from [F:\ADOAgents\Agent1\_work\r28\a\_OGDT Core].
2022-08-06T09:15:59.3817667Z *** Get [*.app] files recursive from [F:\ADOAgents\Agent1\_work\r28\a\_OGDT Core]
2022-08-06T09:15:59.3853935Z *** Found [1] files.
2022-08-06T09:15:59.3864476Z *** Extract App detail from [F:\ADOAgents\Agent1\_work\r28\a\_OGDT Core\PrintVis Business Central\Optimum Group_OGDT Core_18.6.202232.7836_APP.app]
2022-08-06T09:15:59.4732694Z *** Installing Applications:

Thanks,

[Arthurvdv]

Not sure if this is helpful, but in our release pipelines include the server instance in the ALOps Extension API configuration (for example in the printscreen this is D365BC17_BE_TEST_WS).

So the API Endpoint can be constructed like this;

https://<hostname>:<port>/<service_instance>/api

[petertijsma]

Hi Arthur,

Yes, we also do that, (it won't even work without it), but still, the server instance is not passed through to the ALOps External Deployer, so it doesn't know which DLL's to pick

[petertijsma]

Additional information:

What I also found out is that the agent pool used for deployment, is the same pool as we use for our build pipelines. Since we now started creating a build pipeline for BC20, the bcartifacts folder has now also updated with bc20 artifacts. It seems that the ALOps Extension API is getting the latest from this bcartifacts folder, regardless of the NST version it needs to deploy to.

Then again, when I check the deployment to our Production (PRD) environment, all goes well.

That would indicate it's not related to the Agent the ALOps Extension API is running on.

The difference must then be the ALOps External Deployment service on the actual NST server, since on our TST/ACP NST server we have BC18 & BC20 running, but on our PRD NST Server only BC18

[petertijsma]

Tried something out, which seems to work. Altough I don't really understand why since i trust the External Deployer opens a new PS session on each deployment.

I added the following to the _Deploy-ALOpsNAVApp.ps1 on the service tier where both BC18 and BC20 is installed, right before the ALOps.ExternalDeployer is loaded

#> Added new
$modules = Get-Module -Name Microsoft.Dynamics.Nav*
foreach ($module in $modules) {
    Remove-Module -ModuleInfo $module
}
#< Until here

Import-Module -Name "ALOps.ExternalDeployer" -Verbose:$false | out-null

All now seems to work fine?

2022-08-19T15:11:56.7829Z *** Package Data File => [C:\Users\svc_navision\AppData\Local\Temp\tmp9837.tmp.app]
2022-08-19T15:11:56.7889Z *** ServerInstance = [ODATA-ACP]
2022-08-19T15:11:56.7939Z *** ContainerId = []
2022-08-19T15:11:56.7969Z *** Tenant = [default]
2022-08-19T15:11:56.8019Z *** Loading ALOps.ExternalDeployer
2022-08-19T15:11:57.5259Z *** Loading assemblies from: [C:\program files\microsoft dynamics 365 business central\180\service]
2022-08-19T15:11:57.6710Z  * App.ID        = 86f674f1-0913-437a-955d-d6e5b062ce46
2022-08-19T15:11:57.6740Z  * App.Name      = OGDT Core
2022-08-19T15:11:57.6790Z  * App.Publisher = Optimum Group
2022-08-19T15:11:57.6860Z  * App.Version   = 18.6.202234.9196
2022-08-19T15:11:58.3170Z  => Publishing App 'OGDT Core v18.6.202234.9196'
2022-08-19T15:11:58.3230Z *** Publish per Tenant
2022-08-19T15:12:28.2105Z *** Get Tenants
2022-08-19T15:12:28.4865Z *** Sync Tenant default
2022-08-19T15:12:28.5365Z *** Sync App [OGDT Core] on tenant [default]
2022-08-19T15:12:32.1125Z *** Tenant Dataupgrade default
2022-08-19T15:13:21.7124Z *** Install App [OGDT Core] on tenant [default]
2022-08-19T15:13:21.8944Z  * UnPublishing Old App 'OGDT Core v18.6.202232.7836'.
2022-08-19T15:13:22.4974Z 
2022-08-19T15:13:22.5054Z **************************************
2022-08-19T15:13:22.5094Z 
2022-08-19T16:11:30.4896Z *** Package Data File => [C:\Users\svc_navision\AppData\Local\Temp\tmp1FDF.tmp.app]
2022-08-19T16:11:30.4916Z *** ServerInstance = [CLIENT-CLEANBC20]
2022-08-19T16:11:30.4946Z *** ContainerId = []
2022-08-19T16:11:30.4976Z *** Tenant = [default]
2022-08-19T16:11:30.4996Z *** Loading ALOps.ExternalDeployer
2022-08-19T16:11:30.9756Z *** Loading assemblies from: [C:\program files\microsoft dynamics 365 business central\200\service]
2022-08-19T16:11:31.0926Z  * App.ID        = 86f674f1-0913-437a-955d-d6e5b062ce46
2022-08-19T16:11:31.0976Z  * App.Name      = OGDT Core
2022-08-19T16:11:31.1016Z  * App.Publisher = Optimum Group
2022-08-19T16:11:31.1066Z  * App.Version   = 20.1.202234.9212
2022-08-19T16:11:31.4076Z  => Publishing App 'OGDT Core v20.1.202234.9212'
2022-08-19T16:11:31.4096Z *** Publish per Tenant
2022-08-19T16:11:39.4317Z *** Get Tenants
2022-08-19T16:11:39.5967Z *** Sync Tenant default
2022-08-19T16:11:39.6598Z *** Sync App [OGDT Core] on tenant [default]
2022-08-19T16:11:42.0086Z *** Tenant Dataupgrade default
..
..
..

[Arthurvdv]

I’ve never experienced this problem myself, but could be related to this: https://github.com/HodorNV/ALOps-External-Deployer/issues/4

[petertijsma]

Looks indeed like the same issue @Arthurvdv

[petertijsma]

Ok, so the previously mentioned solution didn't work.....

Current state:

[waldo1001]

It might indeed be an issue with the external deployer - we'll have a look.

[waldo1001]

We checked, and all seems to be good. Problem now is that we can't repro the problem.

From the screenshot, it seems the ExtDepl is wrongfully installed.

Dit you really install it correctly for every server instance? you need to run New-ALOpsExternalDeployer -ServerInstance BC for every NST. Did you do that?

Can you test this for all your NST's?

import-module ALOps.ExternalDeployer 

Get-BCServicePath -ServerInstance <YourServerInstance>

That should give back the right path

or you can test with:

import-module ALOps.ExternalDeployer 

Import-ALOpsNavManagementDlls -ServerInstance <YourServerInstance>

That will load the dlls - so you can check which ones are loaded.. .

[petertijsma]

First one:

All looking good.

Second one:

Still looking ok, except that of course the BC20 DLL's are already loaded and therefore the BC20 dll's are not active.

But this is what i believe exactly the issue. Somehow the ALOpsExternalDeployer is keeping the BC18 dll's in memory when it does a deploy on the BC20 instance and fails.

Fot now I solved it by simply restarting the ALOpsExternalDeployer right before the deployment task. This makes sure the dll's are released, but it's not the best way. This is working though, so now both the BC18 and BC20 deployments succeed (as long as they don't run at the same time of course...)

[waldo1001]

I think you gave us a clue on how we can solve it .. .

[waldo1001]

In the next release (pushed today), we did implement this, so please give us feedback next week!

[petertijsma]

Just wondering: How to find out if the new version is active / or activate this?

[AdminHodor]

Dear @petertijsma , @Arthurvdv ,

Could you please check the latest version of "ALOps.ExternalDeployer". We some major changes to the way it works. From v1.45 the ExternalDeployer is compatibel with BC v21.

Install-Module -Name ALOps.ExternalDeployer -Force

Install-ALOpsExternalDeployer -ServerInstance "BC200" -ListenPort 7000
Install-ALOpsExternalDeployer -ServerInstance "BC210" -ListenPort 7001
Install-ALOpsExternalDeployer -ServerInstance "CLIENT-CLEANBC20" -ListenPort 7002

Every NST now gets its own "External Deployer" instance, which mitigates the Powershell-Runtime mixups between versions.

Kind regards,

[petertijsma]

@AdminHodor Installed for 4 instances on one server:

• 2 Version BC18
• 2 Version BC20

Will check how it runs tonight