Set up an Azure IoT Edge runtime in a minute

Azure IoT Edge runs on both Windows 10 and Linux, let’s talk about how to set up that Azure IoT Edge runtime.

The current LTS 1.1.* version of Azure IoT Edge still supports Windows containers on Windows devices.

The newest version of Azure IoT Edge, the 1.2.* version supports running only Linux containers on Windows. This is called EFLOW (Edge for Linux on Windows).

So, Microsoft supports both Linux containers on Linux and Windows too. Technically, you have to write only one solution running on both operating systems.

Still, you have to build and push separate container versions of the same logic based on the processor architecture.

Azure IoT Edge runs on most flavors of (Linux) operating systems that can run containers; however, not all of these systems are equally supported. There is documentation available with an up-to-date list of supported operating systems. Check out if your operating system gets either Tier 1 or Tier 2 support.

As an example, Ubuntu 20.04LTS is currently not officially supported in Tier 1.

Update 21-10-2021: During the recent Azure IoT Edge Summit – Technical Track it is announced Ubuntu 20.04 is on the product team near term roadmap and coming soon.

Still, the Azure IoT Edge runtime can be installed and is considered compatible.

That runtime is built up in a few parts:

  1. A daemon (process) that secures the runtime and start the local part of an Azure IoT Edge solution
  2. The open-source Moby container runtime where the modules will be hosted in
  3. A local directory structure for configuration

Regarding the installation of the runtime, you can follow the original documentation.

This guide does not point you to a simple installation. You need to have technical skills to roll out the runtime. And the rollout is done by hand.

Now, a script is provided and maintained by the Microsoft product team that can be used to automate the roll out of the runtime, including support for DPS.

Let’s check this out.

Before we start rolling out this script, there are some prerequisites:

  • The script can be used for a physical device or VM (e.g. in Azure)
  • DPS support is limited to symmetric keys. This way, Azure IoT Central is supported too.
  • Only Tier 1 operating systems are supported

Note: See GitHub for the most recent configuration tool and how to start the script.

I tried to roll it out on a Tier 2 device. We will see the result later on; short story: it will not work.

Creating a DPS enrollment

We start with creating an individual enrollment in an Azure Device Provisioning Service.

We select a symmetric key mechanism for an IoT Edge device:

I have to provide a Registration ID of this device. Normally this is an ID, identifiable to a specific edge device that makes the enrollment unique for that device (e.g. a serial number or mac address).

Once the enrollment is created, a primary (symmetric) key is made available:

Last but not least, we need the unique ID Scope of the DPS we want to connect to:

Please note down all three pieces of information: ID Scope, Device Registration ID, and one of the two symmetric keys.

Operating system

For this demonstration, I use a brand new VM in Azure. It is based on Ubuntu Server 18.04 LTS:

I have to access the device later on so I need access over SSH.

Warning: this SSH connection with an inbound port is vulnerable on the internet! Once the VM is rolled out, I directly have to limit access to the SSH port 22 by altering the firewall.

I fix the potential security issue by limiting access only from my own IP address:

Note: There are more adequate solutions like Azure Bastion or a private network. For now, this is good enough during the demonstration.

I use the Windows Terminal Preview app to access the VM:

This is a plain Ubuntu OS. There is no IoT Edge runtime installed and running yet:

Executing the script

Now, we have a VM and we have the IoT Edge device enrollment credentials.

Let’s fill in these credentials into the script:

wget -O \
&& chmod +x \
&& sudo -H ./ -s <IDScope> -r <RegistrationID> -k <Symmetric Key> \
&& rm -rf

This is a one liner. If you prefer multiple lines, use these four lines (again, do not forget to fill in the parameters):

wget -O
chmod +x
sudo -H ./ -s <IDScope> -r <RegistrationID> -k <Symmetric Key>
rm -rf

Notice it uses WGET to download the actual full script which installs both Moby and the Azure IoT Edge runtime, puts the credentials in the configuration, and it restarts everything.

If WGET is not yet installed in your OS, first run:

# apt-get install wget

Here are some screen prints that I took when running the script:

I have filled in the credentials. Notice the script starts at 15:17:54.

The script downloads all parts of the actual logic to execute:

Note: a log file is created alongside.

Note: there is a -nt or -telemetry-opt-out to prevent data being collected by Microsoft.

On this VM, the script downloads and installs and configures everything in just one go:

As promised, it only took one minute 🙂

Checking the installation

See that the Azure IoT Edge 1.2 runtime is there:

In the DPS, the device is now assigned to an IoT Hub following the IoT Hub assignment rules:

In the IoT Hub, the edge device is made available and connected:

Now, it’s up to you to actually deploy logic, zero-touch, by adding modules and routes.

When doing the first deployment, that will also roll out the Edge Hub module.

What about Tier 2?

It is well documented in the repository that only Tier 1 Operating systems are supported.

This is because there is a Tier 1 check in the script!

Because the original installation can be used for some Tier 2 operating systems too (no guaranty) I still tried it out:

Yes, the script is aborted, as documented.


Here, I demonstrated how to deploy using DPS and IoT Hub. The original documentation shows how to roll it out to IoT Central.

We can indeed roll out the Azure IoT Edge runtime with just a script that is maintained by Microsoft. So, keep an eye on future improvements.

That script can also be used as a reference if you want to start automating deployments yourself. This could be a start for your own production script where you add the extra production dependencies.

There are some limitations (You have to use a DPS, only symmetric keys are supported, it only works for Tier 1 devices) but this does not make the script less useful for demonstrations, workshops, or (automated) test environments.

Do you want to see a live roll-out video? Check out this Internet of Things show episode.