Echelon/NES Smart Meters – dabbling the hardware v1.00


Unfortunately we are still awaiting the release of the MEP protocol from NES (Networked Energy Services) as mentioned in previous blog entries. This will release us from the Non-Disclosure Agreement (NDA) keeping all this a secret to you.

…but while we wait, we could introduce you to our hardware prototype.

MEP ESP32 version 1.00 – front
MEP ESP32 version 1.00 – back

In our first few attempts we got the connector totally wrong.

Apparently the footprint we used while doing our PCB design numbered the pins 2 columns in 3 rows, while NES numbered them with 3 columns in 2 rows:

Our pin numbering f**k up

Naturally we messed that up! Luckily we actually did some sanity testing before just inserting this prototype into the meter, and we did discover the error and simply connected with some wires to quickly fix it.

We wrote about the pin connections previously, but just to recap:
Pin 1: Ground
Pin 2: Enable. Set to +5VDC or +12VDC to tell the meter the MEP interface is active
Pin 3: TXD (meter’s serial receive pin)
Pin 4: RXD (meter’s serial transmit pin)
Pin 5: Power. +24 or +26VDC (max 1W) from meter
Pin 6: Not used / no connection

Note: It depends on the hardware model of the meter if pin 5 supplies 24 or 26VDC.

Due to the wires, we could move on with the software… While awaiting a new prototype PCB from JLCPCB… But let us explain a bit about the hardware prototype:

The ideas behind this hardware are quite simple:

  • The ESP32 is a 3.3VDC device, it needs the voltage from the meter reduced in an efficient way as we need the 1W it can deliver (we use a Chinese buck converter to keep it simple).
  • We need to be able to program the ESP32 in circuit (so we don’t need to program it before soldering it / de-solder it if something goes wrong). So the primary serial interface of the ESP32 is routed to the unpopulated 6 pin connector at the edge of the print.
    To program the ESP32 we need to put it in programming mode. The resistors and capacitor next to it is for that…
    Luckily the ESP32 also have a second serial interface we can use to communicate with the meter now we use the first one for debugging and in circuit programming.
  • The meter is RS232, the ESP is 3.3VDC TTL – so how do you convert that? A Max3232 can do just that, it is 3.3VDC too (it got a Max232 brother that is 5VDC). It has a built in boost converter that boosts the 3.3VDC back up to the signals level of RS232.
    The capacitors surrounding it is for this boost converter.
  • The meter also requires a Enable pin to be set high. Luckily the Max3232 got a second receive/transmit logic. We can just use the second transmit logic to make an Enable pin controlled by the ESP32. Only problem is that is should probably not go negative (like RS232 will), but we fix that with a diode.

Not much to it – or is it really this simple?

Stay tuned for an update on the next hardware version of ESP32 MEP…. Coming to real soon now…

Echelon/NES Smart Meters – NES to the rescue

Networked Energy Services logo

As mentioned in our previous post, we we stuck. We had a 3rd party module which were clearly communicating with the meter through RS232. We knew the hardware interface, but we had no idea about the protocol…

In pure desperation we opened a support ticket with the current owner of the technology – NES (Networked Energy Services). We did not expect any feed back – or at least no help. Surely they know the port and the protocol, but we did not expect us beeing able to reach out to them directly… We more or less expected that they would simply redirect to our power company or power grid/meter owner…

In fact they responded positively to our request, and soon setup a teams call between us and a Senior Vice President. During the meeting they simply wanted to know if we were tinkering or doing a commercial product, but as soon as it was established that this was in no way commercial, they were prepared to offer their full help.

Apparently NES is working on opening the reading part of the protocol up, so our timing was perfect. Unfortunately they were settled about how to do this and how to approach it. So they needed us to sign a Non-Disclosure Agreement (NDA) to get access to the full documentation. As the NDA only covered un-released documentation, they promised to work on figuring out how and what to release asap so the NDA could be lifted. While writing this, we have received the finished documentation for the IR-interface (which we cannot use for anything in Denmark as N1 claims it is fully encrypted, and N1 will NOT release the encryption keys due to security considerations). Also we have received a preliminary draft of the MEP documentation, so we trust this WILL in fact be released soon (according to NES the deadline is Q4 2021).

We can reveal a few things about the protocol – which is more complex than we expected. The meter has around 80 tables you can read and/or write to and around 30 procedures you can call (individually and/or as part of an atomic transaction). We are told not all tables and procedures will end up in the public documentation, but the full protocol supports stuff like: writing to parts of the meters display, report data from other meters via MEP and let the meter report it to the grid. Let the grid send firmware/files to you module. Read out all aspects of the power delivery – like consumption, quality, outages etc. The meter can even send and receive alarms if something unexpected happens or ask you for measures if you configure it to include data form other meters (i.e. water, heat etc.) in it’s reports to your net company…

If this was just a matter of only allowing reading from the meter it would be simple, but unfortunately some of the reading required setting up stuff and writing procedure calls to tables… And the reading the results from other tables. So it is far from simple and NES need to make sure that the parts released is just enough without beeing too much…

Note: although MEP is unencrypted a password is needed. There are 3 levels of security in the MEP protocol. The password is used as part of a digest (checksum) calculated on the data packages and reply. It is used to make sure the requester has the proper access, but also that the sent and received packages are not corrupted during transmission.

  • No key required: The lowest level of security. Don’t give access to much
  • MBK: MEP Basic Key (MBK), formerly also known as Base Encryption Key (BEK)
  • MAK: MEP Advanced Key (MAK), formerly also known as Open Media Access Key (OMAK)

These keys should be provided by your power network operator (i.e. N1). Those are the ones owning your meter and the cable to you house.

Regarding N1 they are only willing to give us the MBK, but it is fine as it can be used to read most values from the meter. We were told that the MBK is shared between meters, while the MAK is a individual key per meter.

If your power network operator is N1, the procedure is to ask the power company (the ones you actually buy your power from) to ask N1 provide the read-only key for reading out power consumption electronically (they can do this by using a N1 webform created for this purpose. You also need to provide your name/address, and probably also installation no. and meter no. And off cause your e-mail address.

At the time of writing this is the current state of the project:

  • We have a full documentation of the MEP protocol – which we unfortunately cannot share due to the NDA. NES is working on sharing part of this, which again will allow us to share our code!
  • We have a partial documentation of the IR protocol. NES is working on publishing this too so we can link to it. According to N1 it has no use in Denmark as the IR communication is encrypted and they won’t release the keys.
  • We have a working MEP-prototype hardware with an ESP32
  • Although our software is still work-in-progress, we have all the pieces to the puzzle and are able to send requests to the meter (or at least most of them) and get meaningful replies back from it. Due to the NDA we are NOT able to share the software at this point in time

Rest assured that we will share the software and related knowledge/hints as soon as the NDA is lifted… Follow our blog to get notified when this happens…

In the meantime we could probably soon share our hardware… Stay tuned 🙂

Echelon/NES Smart Meters – the secret interface

The secret MEP 2020 renewed our interest in communicating with our Echelon meter. During a session by Thomas Ljungberg Kristensen, WelcomeSecurity ( the different possibilities and the legislation was briefly covered and he inspired us to push harder to get some kind of access.

If you are following these posts, can read Danish and have a Smart Meter you would like to connect to – this page (created by Georg Sluyterman) might be of interest to you: BefriDinElmå

As mentioned in the previous post we already started the process of getting further information from N1. The useable information was sparse and hidden in a lot of mis-information, but in hindsight we know that this was probably not on purpose, but simply because the N1 organisation and staff did not have the full picture of the solutions and/or simply did not know better. This simply seemed to be new to everyone involved…

N1 confirmed that the IR solution was encrypted and there were no way they could supply us the encryption key. Supposedly there were a hidden port behind a cover at the bottom of the meter, and we should purchase a “Izar / M-bus PCB” for it. We were a bit skeptical, but did find a hidden 6 pin interface in a plastic drawer on our meters… So it seems there were some truth to this…

N1 told us that a company called Develco had been involved in the developments, but had sold off the solution to an unknown 3rd party… Gert discussed a bit with N1 if they could claim that we could simply order this PCB, when it was nowhere to be found and they could not tell us where we could buy it… Is something REALLY for sale when you cannot buy it? 🙂

After researching this further Izar and M-Bus interfaces seemed to be a dead end… But researching “Develco”, hidden interfaces and solutions further we found this! (local copy of the PDF can be opened from here if the external link ever disappears)…

But wait a minute – this document does not mention “Izar” nor “M-Bus”!!! Insted new terms like “Multi-purpose Expansion Port (MEP)” and “ZigBee” is introduced. What the heck is a MEP port?

According to the document the Danish company Develco was actually involved in a project with EnergiMidt (parts of EnergiMidt are now N1) and NES (Networked Energy Services). And apparently as part of selling all these Echelon Type 83331-3IAAD (and similar model) meters in Denmark, a new plastic cover was developed providing access to the MEP screw terminals from a small “drawer” in the meter! It seems this solution is available for most (if not all) Echelon Type 83331-3IAAD (and similar model) meters in Denmark.

Unfortunately it was very hard to get in touch with Develco. We tried multiple times writing them, calling them etc. Finally Graves managed to convince a sales guy that we represented a company interested in purchasing SEVERAL PCBs to follow multiple plants power consumption more closely…. Only to discovere that the PCB never was produced as anything but a prototype / proof of concept… They would be happy to start production up for us , if we would only place an order of of 10,000 pieces or so…. Yet another dead-end…

The MEP “drawer” is well hidden. We did not know it was there before we found this document. As far as we know other tinkers investigating this also did not find it (or at least the few we spoken with afterwards didn’t know about it). This is simply a well hidden “secret” in plain sight. It looks like part of the cover, but it is actually a separate piece of the plastic you can pull out and it is prepared to receive a small PCB that connects to a 6 pin standard 2.54mm pin header. When you know it is there, it is obvious – we just didn’t notice it previously…

We tried to investigate the 6 pin interface, but it is hard when you have nothing communicating on it – and no idea what exactly to look for. If we could just open the sealed meter to reverse engineer – but that is illegal.

At least we found this in a manual forwarded to us (although it is marked CONFIDENTIAL), but it does not tell us how the pins are routed to the 6 pin header:

M-Bus and MEP screw terminals behind the sealed cover on the Echelon/NES meters

Inspired by Thomas – we pushed harder – and (we cannot reveal from where) “suddenly” we had a prototype of the so-called “Izar/M-Bus PCB”. This was really a breakthrough. We immediately tested it in a couple of Echelon meters, which immediately recognized it with a small “M” in the display. And according to the available documentation – that is the “icon” for a MEP device (Multi-purpose Expansion Port) and not a M-Bus device… So Izar/M-Bus appears to have been mis-information… This is in fact a MEP/ZigBee PCB…

MEP / ZigBee module

Anyway – with a working PCB to reverse engineer and the above table, we soon found this pin-out of the “secret” 6 pin header (pins from top left to bottom right as seen when you look at them in the “secret” drawer in the meter:

  • Pin 1: MEP_COM_GND (ground)
  • Pin 2: MEP_COM_ENABLE (+5v or +12v on this pin will tell the meter to enable the interface)
  • Pin 3: MEP_COM_RXD (meter serial receive pin)
  • Pin 4: MEP_COM_TXD (meter serial transmit pin)
  • Pin 5: MEP_PWR (+24/+26VDC power from meter. Note: This is max 1watt!)
  • Pin 6: Not used / no connection

And also the above table confirms that MEP is a quite simple serial (RS232) based protocol.

Based on this we were soon able to capture communication with a small PCB between the meter and a couple of USB RS232/DB9 interfaces (like these)… We soon realized the serial communication parameters 9600,n,8,1 and to our surprise the protocol seemed binary and far more complex than expected…

During our early research we stumbled across this GitLab project. Looking at it, it seems MEP is a kind of clear text protocol with quite simple commands, but we soon realized this was another “rabbit hole” or we simply do not understand the code in the project. Anyway – it seems we cannot get any usable knowledge from that project.

We tried to research the protocol, but the only stuff we could find was that Echelon at some point sold training in this, and then references to this document “Echelon Corporation (2010c) MEP Device Developer’s Guide, Version 078-0372-01G, San Jose.”.

We also tried to reverse engineer it based on the recorded packages sent and received between the MEP/ZigBee module and the meter – but this was clearly outside our skillset. We had NO idea what was sent and received…

We were giving up after “hitting this wall” of the secret MEP protocol…

…and in our desperation we reached out to what we thought was the most unlikely party to help us (no, not N1) – stay tuned for our next post :-)…

Echelon/NES Smart Meters – the beginning

Echelon logo

This will be a multi part post as we spent the last year in collecting all the pieces of the puzzle to connect to and get data from our Echelon Type 83331-3IAAD meter. Like others trying to do this, we hit a lot of “red tape”, lack of knowledge from involved partners, confusions and even deliberate mis-information. But in the end we actually succeeded and now have all the pieces to complete the puzzle. We are working on finalizing a tinker solution, but are still under a NDA (Non-Disclosure Agreement from the current technology owner NES (Networked Energy Services). Luckily NES is working hard on releasing the required information as open source through OSGP Alliance (OSGP is short of Open Smart Grid Protocol). We have been promised this will happen “soon” (and have received drafts of the documents – so we are pretty sure it will happen soon). This is the start of the process that hopefully will make it possible to share the knowledge with you.

Shoutout to the guys and girls at the just finished Thank for a great gathering and for listening to our Echelon stories… And an additional shoutout to Georg Sluyterman, who is running BefriDinElmå and is beta-testing our prototype in his Echelon Power Meter.

For a few years Graves and Gert have been trying to create a solution to read out our power consumption from our so-called Smart Meter: Echelon Type 83331-3IAAD.

Initially we hoped to be able to read the meter data through the IR (Infra Red) “eye” on the meter. This seems to be possible on meters from other manufacturers, (i.e. Kamstrup) and HAL9K even shared the required hardware for it.

We spent quite some time on this “rabbit hole”, but eventually found internet sources mentioning this interface is encrypted and you need to obtain a key from your power network provider to decrypt this interface on our Echelon meter. It seems this interface is used during production of the meter and have a bunch of features. Unfortunately our guess is also that the security of this port has been compromised as our power network provider N1 simply refuses to hand over the required keys. We have not found any real evidence of this, but if you have any information regarding this, please enlighten us in the comments :-).

At this point in time we reached out to our power company, which referred us to N1. We started pushing N1 for information on how to integrate with the meter (as you are supposed to be able to do this by law) and keys for the IR port, but is seemed like a dead end. Others have tried with no success – and we did expect kind of the same result… We thought that the guys at N1 withheld information from us on purpose… Today we know it is more likely they simply did not have much usable information and only knew that they would/could not hand out the IR encryption keys.

The obvious next step was to start counting the LEDs blinking on the meter. Other have successfully implemented this very simple interface, and we know it is possible to follow the power consumption by counting the LED blinks, and maybe even get the real time consumption by measuring the blinking frequency. Although this will work and we also went down this path for a while, it is not really a nice solution. You cannot read the exact counter shown on the meter and get other available information etc.

During our research we also found that our power network provider (N1) at least at some point might have offered an electrical interface pulsing the same way as the LED. Apparently you had to rent it for a monthly fee… In other words, not for tinkeres like us….

The ironic part is that the meter in fact have screw terminals for different interfaces (M-Bus and something called “MEP” – we’ll discuss that in our next post), but on our meter they are hidden behind a protected/sealed cover. And you are NOT allowed to break the seals in any way. It is simply illegal for consumers to do that in Denmark.

At this point in time we kind of gave up… Apparently it is not possible to get to the meter data in a real usable/electronic way. And N1 is not providing much help….

…or rather – we gave up for a while – stay tuned for our next post :-)…

Echelon/NES Smart Meters – rebooted


We have been quiet for a while. Not because we have not been tinkering, but because we’ve been very busy tinkering.

To be precise we’ve been tinkering with our Echelon type 83331-3IAAD Smart Meters (power meters) and how to read out the consumption in a nice way…

Echelon type 83331-3IAAD Smart Meters (power meter)

At the Danish gathering 2021 we’ll be presenting a session (Friday @ 16:00 CET) about our process and the current state of this project. See you there?

It is yet to be determined how much details we can share because we are currently under NDA (Non-Disclosure Agreement) with the product owner NES (Networked Energy Services) about the details… But that will hopefully change soon.

Are you interested in communicating with your Echelon Smart Meter?

Stay tuned for more info. on how to do it… coming to very soon now…

Game On – or Game Over?

ALTris app logo

A few weeks ago Erik Hougaard challenged me (or I challenged myself?) in comments on one of Erik’s YouTube videos to re-implement my C5Tris game for Microsoft Dynamics C5 in AL for Microsoft Dynamics 365 Business Central (BC).

Off cause BC supports Java Script control add ins, but downloading a Java Script Tetris clone and simply calling it in a BC JavaScript control add in would not really be a challenge at all.

The true nature of the challenge must be to create a playable Tetris clone in AL, controlled by AL and only use a minimum amount of HTML and Java Script.

On top of that the game should probably be implemented with very few AL objects, to limit the footprint when installing. And why not add controls with the cursor keys and game sound effects now we are busy anyway?

Challenge accepted!

In this link you will find a ZIP-file with the source code, but if you just want to install the app in your BC, you can just download the app file here!

If you just want to see it – well here we go (disclaimer: I’m a developer, NOT a gamer!)

ALTris was developed in BC14, but as BC apps are compatible with other versions it should be installable and playable on other versions too. It probably also helps that I’m not using a bunch of calls to the standard BC base application. I didn’t find any usable – probably Microsoft didn’t think of BC as much of a games platform :-).

Feel free to use the code, look into the code, change the code, complain about the code or whatever you prefer as long as you keep my name, SIMTEQ A/S and links to my LinkedIn and SIMTEQs homepage in there.

Use this code on your own risk and costs…. and enjoy!

* 2020-09-08: Found and fixed a few spell bugs (text only), so we are now at version 🙂

No online help in Microsoft Dynamics Business Central 2019 wave 1 (aka BC14) On-Premises

Dynanmics 365 Business Central logo

Did you also wonder where the English and Danish (and probably other languages as well) help pages went?

In Microsoft Dynamics Business Central 2019 wave 1 aka Business Central 14 (and possible newer versions) after the RTM-release in April 2019, the help simply does not work out-of-the-box anymore.

It seems Microsoft are more focused on the SaaS solution these days and the On-Premise version is suffering a bit from it.

Note: I’ve actually contacted Microsoft about these help issues, but due to the SaaS focus and the help beeing a community effort now (see, they are actually NOT planning to fix this! Also they are trying to reduce the size of the install DVD.
That is an unofficial answer though, so if we all report it, they might change their minds :-). For now this is something you need to repair in your installation yourself – i.e. by following this blog post…

This is actually two “errors”:

(1) If you have selected the en-US language and you try to open the help using the icon or CTRL+F1 you get this:

Server Error in '/' Application.
Runtime Error
Server Error in ‘/’ Application. – Runtime Error

…actually this is quite easily fixed. The English language is per default installed in “C:\inetpub\wwwroot\DynamicsNAV140Help\help\en”, but BC is trying to open it from “C:\inetpub\wwwroot\DynamicsNAV140Help\help\en-US”. So let us just create a link:

C:>cd C:\inetpub\wwwroot\DynamicsNAV140Help\help

C:\inetpub\wwwroot\DynamicsNAV140Help\help>mklink /d en-US en
symbolic link created for en-US <<===>> en

Volume in drive C has no label.
Volume Serial Number is C6AF-373F
Directory of C:\inetpub\wwwroot\DynamicsNAV140Help\help
06/23/2020 07:03 AM
06/23/2020 07:03 AM ..
03/30/2020 10:53 AM da-DK
03/30/2020 10:53 AM en
06/23/2020 07:03 AM en-US [en]
01/31/2020 07:11 AM 22,060 feedback.js
03/30/2020 10:53 AM local
01/31/2020 07:11 AM 79 shortcutCold.gif
2 File(s) 22,139 bytes

…problem solved 🙂

2020-10-05 GL: Please see Jani Kivilähde’s comment below: “For fix (1), the use of SYMLINK breaks the search in Help Server. Windows Search does not traverse SYMLINKs.”. So the correct fix is – as mentioned by Jani – to rename or copy the folder.

(2) If you on the other hand have selected the da-DK (Danish) language – or presumable any other language besides en-US, you’ll get this error:

404 - File or directory not found.
404 – File or directory not found.

…and if you have a look at the server in the destination folder “C:\inetpub\wwwroot\DynamicsNAV140Help\help\da-DK”, you’ll discover why:

Slim da-DK help (missing files)
Slim da-DK help (missing files)

Actually, I’ve checked most versions of the Danish install DVD, an the .cab-file with help files are only included in full on the RTM version – NOT in all the CU versions (you’ll find the .cab-file on the DVD in the folder “Installers\DK\WebHelp\DynamicsNAV140Help\help\da-DK”). In the RTM-version the .cab-file is above 4MB in file size, while it is only 18KB on the CU versions.

So this solution is – either build your own html-files from the GitHub repository mentioned in the link I mentioned in the beginning of this post (, or (preferable) download and copy the files from the RTM DVD.

Note: The latter solution is probably the preferred one, because you then get the exact help files matching your BC version. The GitHub repository might contain functionality not yet introduced in your major version.

Another note: the .cab-file or “Cabinet File” is actually a .zip-file, so you can rename it to .zip to open it in Windows or simply open it with 7-Zip or similar archiving utility. And then copy the contents to the correct language help folder.

Yet another note: In the “old days” where this worked out-of-the-box, the translated help files was typically NOT updated with each CU release. That makes sense as CUs rarely contains a lot of new functionality and it is probably quite expensive to keep the translations updated.

And a final note: I’ve not confirmed this issue for Microsoft Business Central 2019 wave 2 aka BC15 and/or 2020 wave 1 aka BC16. But as this might be caused by Microsoft prioritizing SaaS, it might be the same story in all versions after BC14. Hopefully we will be able to extract the help from the RTM versions…

As always: These fixes comes with NO warranty. Use this completely at your own risk and costs. Also it would probably be a very good idea to make a copy of the existing installation before overwriting or adding anything.

Extra hint – can you search in your help? If not, did you remember to:

  • enable Windows Search on your IIS help server (WindowsServer Manager)
  • verify that the Windows Indexing Service is running (Windows Task Manager)
  • verify the help folder is included in the indexing (Windows Control Panel)

Running Microsoft SQL Server 2019 Developer Edition in a Docker Windows Container

Note: This work is based on the “Official Microsoft repository for SQL Server in Docker resources” found here:

Unfortunately this has not been updated to run Windows ServerCore 1890 and Microsoft SQL Server 2019 – so this is what this blog post is about…

Note 2: We are only taking about minor changes here – so I’m not in ANY way trying to claim credits for these scripts – all credits goes to the original author for these scripts – see the above mentioned official link!

Note 3: If you try to use the official Microsoft SQL Server Developer Edition image and you get the error “The container operating system does not match the host operating system.”, it is probably because that image is not Windows Server 1809 compatible. This will also solve that as this image is based on the “” Windows Server image.

Enough notes for now :-). Let’s roll with this – first you need to create these two files:


# 2020-05-11 GL

LABEL maintainer "Gert Lynge"

# Download Links:
ENV exe ""
ENV box ""

ENV sa_password="_" \
    attach_dbs="[]" \
    ACCEPT_EULA="_" \

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]

# make install files accessible
COPY start.ps1 /

RUN Invoke-WebRequest -Uri $env:box -OutFile ; \
        Invoke-WebRequest -Uri $env:exe -OutFile SQL.exe ; \
        Start-Process -Wait -FilePath .\SQL.exe -ArgumentList /qs, /x:setup ; \
        Remove-Item -Recurse -Force SQL.exe,, setup

RUN stop-service MSSQLSERVER ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\supersocketnetlib\tcp\ipall' -name tcpdynamicports -value '' ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\supersocketnetlib\tcp\ipall' -name tcpport -value 1433 ; \
        set-itemproperty -path 'HKLM:\software\microsoft\microsoft sql server\mssql15.MSSQLSERVER\mssqlserver\' -name LoginMode -value 2 ;

HEALTHCHECK CMD [ "sqlcmd", "-Q", "select 1" ]

CMD .\start -sa_password $env:sa_password -ACCEPT_EULA $env:ACCEPT_EULA -attach_dbs \"$env:attach_dbs\" -Verbose

…and “start.ps1”

# 2020-05-11 GL

# The script sets the sa password and start the SQL Service
# Also it attaches additional database from the disk
# The format for attach_dbs




if($ACCEPT_EULA -ne "Y" -And $ACCEPT_EULA -ne "y")
	Write-Verbose "ERROR: You must accept the End User License Agreement before this container can start."
	Write-Verbose "Set the environment variable ACCEPT_EULA to 'Y' if you accept the agreement."

    exit 1

# start the service
Write-Verbose "Starting SQL Server"
start-service MSSQLSERVER

if($sa_password -eq "_") {
    if (Test-Path $env:sa_password_path) {
        $sa_password = Get-Content -Raw $secretPath
    else {
        Write-Verbose "WARN: Using default SA password, secret file not found at: $secretPath"

if($sa_password -ne "_")
    Write-Verbose "Changing SA login credentials"
    $sqlcmd = "ALTER LOGIN sa with password=" +"'" + $sa_password + "'" + ";ALTER LOGIN sa ENABLE;"
    & sqlcmd -Q $sqlcmd

$attach_dbs_cleaned = $attach_dbs.TrimStart('\\').TrimEnd('\\')

$dbs = $attach_dbs_cleaned | ConvertFrom-Json

if ($null -ne $dbs -And $dbs.Length -gt 0)
    Write-Verbose "Attaching $($dbs.Length) database(s)"
    Foreach($db in $dbs) 
        $files = @();
        Foreach($file in $db.dbFiles)
            $files += "(FILENAME = N'$($file)')";           

        $files = $files -join ","
        $sqlcmd = "IF EXISTS (SELECT 1 FROM SYS.DATABASES WHERE NAME = '" + $($db.dbName) + "') BEGIN EXEC sp_detach_db [$($db.dbName)] END;CREATE DATABASE [$($db.dbName)] ON $($files) FOR ATTACH;"

        Write-Verbose "Invoke-Sqlcmd -Query $($sqlcmd)"
        & sqlcmd -Q $sqlcmd

Write-Verbose "Started SQL Server."

$lastCheck = (Get-Date).AddSeconds(-2) 
while ($true) 
    Get-EventLog -LogName Application -Source "MSSQL*" -After $lastCheck | Select-Object TimeGenerated, EntryType, Message	 
    $lastCheck = Get-Date 
    Start-Sleep -Seconds 2 

…and then you have to run these docker commands (replace “<path to a directory with the above mentioned two files>” with the path to the above mentioned two files: dockerfile and start.ps1 – and “<password>” with the sa-password you want):

docker build --memory 4g --tag dabbler/mssql-server-windows-developer:winsrv1809-sql2019 "<path to a directory with the above mentioned two files>" 

docker run --name SQLServer2019 -e ACCEPT_EULA=Y -e sa_password=<password> -p 1433:1433 -d dabbler/mssql-server-windows-developer:winsrv1809-sql2019

If you are lucky, you will now have a running SQL Server 2019 Developer Edition and you can connect directly to it with Microsoft SQL Server Management Studio directly on the host running Docker (use “SQL Server Authentication” with host: “localhost”, login: “sa” and the password stated above).

Installing Microsoft Dynamics 365 Business Central with AzureSQL

Dynanmics 365 Business Central logo

As described here, it can be kind of a Catch-22 to try to install Microsoft Dynamics 365 Business Central if you don’t have a local SQL Server, but want to use AzureSQL.

Although I know the approach in the before mentioned Kine Info blog post works, I came across a easier solution during my struggles with this issue.

Although the installer setup.exe does not have a “Postpone Server Startup” setting in the GUI, it actually support it.

You just need to create a configuration and hit Save before actually starting the installation. You can do that when you finish filling out all the settings on the setting page (the one with port numbers, database server and database name etc.). After you saved the configuration, close the setup.exe installer.

Now open the XML file you saved, locate the “PostponeServerStartup” setting and change it’s default value of “false” to “true”:

<Parameter ID="PostponeServerStartup" Value="true"/>

Now restart setup.exe and load the configuration – and start the installation. The installer will not try to start the service tier, so it won’t fail that and roll back the installation.

We can only hope that Microsoft at some point will add this option to the setup.exe GUI :-).

2020-02-28 Update: I’ve suggested it to Microsoft. It is not a high priority issue (because of the above described workaround). For anybody interested it has been logged with internal Microsoft ID 346773.

Review: Introduction to the Modern client

Introduction to the Modern client

“Introduction to the Modern client” is a comprehensive, well written and excellent book for readers wanting an introduction to the new Modern client for Microsoft Dynamics 365 Business Central.

Peik Bech-Andersen not only introduces the Modern client and its role centers. He also walks us through the different elements of a role center and give us an easy to understand overview of the considerations, possibilities and tasks in adjusting the role center to the different requirements of a company, a department or even for an individual user.

Throughout the book Peik gives valuable hints and describes the complete life of role center and profile adjustments – starting from a developers tasks in adding parts to a role center page, via consultants and super users possibility to add or hide parts of a profile and he finishes off with the personalization options for individual users.

In the book you get information regarding best practices and unique bonus information about various subjects including notifications and utilizing/re-using the build in Business Charts – all based on Peik’s longstanding experience as a solution architect.

Peik’s full circle on the Modern client, role centers and profiles give “Introduction to the Moderns client” a very wide target audience.

I have no problems in recommending this book to readers ranging all the way from new Microsoft Dynamics 365 Business Central users (e.g. as course material), over experienced NAV users, super-users and consultants, to skilled NAV developers with the need to get familiar with the new Modern client and identifying when they need to add to the role centers and when to let the consultants handle it.

You can buy the two books at the Dynamics Book Store:

Introduction to the Modern client as PDF download
Introduction to the Modern client as paperback