Microsoft Azure* provides an incredibly powerful and flexible backend for your IoT solutions. In this lab, we will configure a robust collection of services to mimic the real world solutions you may implement yourself. With the number of services we will configure, it is helpful to first understand what those services are, and to gather the configuration details we will need for them in advance. Having done so, the configuration of the services themselves will be much easier. By being consistent on how we organize our resources as well as where we deploy them and how we name them, our job of working with them and managing them is made much simpler.

The following diagram provides an overview of the architecture we will be implementing:

Common Resource Group

We will be placing all of the Azure resources we provision in this lab into a single Resource Group (link). Resource groups are a core concept in the Azure Resource Manager (link) technology used by the Azure platform. Resource Groups allow you to keep all the resources related to a solution in a single organizational container. This in invaluable when securing, deploying, and removing the resources.

Common Location or "Region"

We want to make sure to deploy all of the resources we create into the same Azure data center, or Region (link). This will help to ensure that the resources have low latency connections to each other (for example, the web application can directly access the sql database), as well as keep our costs low by reducing the amount of data leaving a the data center and incurring any data egress charges.

That means that we need to select a region that supports all of the services we will use in our solution. You can review the list of Products available by region to verify that the services required by this lab are available in the region you want to use. The services used in this lab include:

  • Microsoft Azure* IoT Hub
  • Azure Stream Analytics
  • Azure Event Hubs
  • Azure Storage
  • Azure SQL Database
  • Azure Web Apps
  • Azure Function Apps
  • Azure PowerBI Embedded

At the time this is being written (October 2016), the following regions have all of the required services. THIS LIST WILL GROW OVER TIME. You are welcome to review the Products available by region to see if any additional regions provide the resources needed. Otherwise, simply pick the region from the list below that is closest to you, and ensure that you choose that region for each resource you deploy.

  • West US
  • North Europe
  • West Europe
  • Southeast Asia
  • Australia Southeast

Common Naming Convention

We will be provisioning a number of resources in this lab. Some of these resources require globally unique names. In addition, we need to be able to refer to those resources in the lab documentation. To facilitate that, it is strongly recommended that you use the naming convention outlined here. In the architecture diagram above, you will see that resources have been named with a <name> prefix, and then some resource specific name.

Choose a <name> prefix that is unique to you. It is recommended that you use something like your initials. For example if your name where Jane Q. Doe you might select jqd as your name prefix. To add a little more uniqueness you could add in your two digit birth month. For example, if Jane was born in October she might use jqd10. Some resource names must be at least six characters or longer. Having a prefix that is 4-6 characters long will help ensure our names meet the minimum length.

You can choose anything you like, but it must help create unique names, and it should be short because you'll be typing it a fair amount.

For the purposes of this lab's examples, we'll use the mic16 prefix, short for Microsoft Intel Camp 2016.


Service Descriptions

The following table is a summary of the Azure services you will create in the lab, to help you better understand the role of each service. DO NOT rush into creating these services on your own. We will walk through step-by-step instructions in the sections below.

Service Name Description
The Device Intel® NUC, Arduino 101* (branded Genuino 101* outside the U.S.) & Grove* Sensors The Intel® NUC is our Device. It get's sensor values from the Arduino 101 and Grove sensors that are attached. We use an easy graphical development environment called Node-RED on the Intel® NUC to help the Intel® NUC send messages with sensor data to the cloud, as well as to receive messages from the cloud and act on them.
Resource Group <name>group Azure Resource Groups provide a convenient way to organize all of the Azure resources for a solution into a single container. The Resource Group can then be a unit of deployment, a securable collection, and an easy way to delete all of the resources in the group in a single operation. We want to make sure that all of the resources we create in this lab are placed in the <name>group resource group.
IoT Hub <name>iot Provides a way for devices (like the Intel® NUC with Arduino 101 in our lab) to send and receive messages in the cloud. Backend services can read those messages sent by our devices, act on them, and send messages back to the device as needed.
IoT Hub Device Identity <name>IntelIoTGateway This is the id we will use for our device's identity in the Azure IoT Hub Device Identity Registry. Normally you would use a system generated globally unique value like a GUID for your device identities, but for the lab it will be much easier if we use a friendlier human readable name.
Stream Analytics Job <name>job The Azure Stream Analytics Job provides a way to watch messages coming into the Azure IoT Hub from our devices and act on them. In our case it will forward all messages off to a SQL Database so we can report on them, but it will also watch the temperature sensor values in those messages, and forward them to an Event Hub if they exceed a pre-defined threshold temperature.
SQL Server <name>sql The Azure SQL Server instance will host our Azure SQL Database. Other than creating it to host our database. This is also where the administrative login for our SQL Server is defined, as well as the server level firewall rules that we will configure to allow connections from the Internet.
SQL Database <name>db This will store the dbo.Measurement table and a couple of views. The Stream Analytics Job above will forward all temperature messages sent to the IoT Hub into this table, and the Web Application and Power BI Embedded Reports will then query that data to provide reports on the temperature data.
Event Hub Namespace <name>ns This is the Service Bus Namespace that hosts our Event Hub. We really won't do much with this directly, we just need one to host our Event Hub for us.
Event Hub <name>alerts The Event Hub is an internal messaging queue that we will use to pass along temperature alert messages. The Stream Analytics Job will watch for temperature messages with sensor values that exceed a predefined temperature threshold and forward them off to this event hub. We'll then create an Azure Function to read the messages out of this event hub and send alerts back to the device.
Storage Account <name>storage A few of the services require a storage account for their own purposes. This account exists purely as a resource for those services. We won't use it directly for our own purposes.
App Service Plan <name>plan The App Service plan provides the execution environment (servers) for our Web App and Function App. We can scale our App Service Plan up or down as needed to get give those services the resources they require to perform as desired.
Web App <name>web The Azure Web App is where we will deploy our Node.js application that provides the web site for our solution. We can then go to this site to view temperatures from our devices queried from the SQL Database
Function App <name>functions The Azure Function App contains the TempAlert function. A single Function App can contain many functions. We'll just have one.
Function TempAlert The TempAlert function will be triggered automatically whenever a new message is sent to our <name>alerts event hub. It will then read those messages, retrieve the id of the device it was sent from, and then send a message through the IoT Hub back to that device to let it know that its temperature has exceeded acceptable levels. The device can then sound an alarm by turning on its buzzer.
Power BI Embedded Workspace Collection <name>collection Power BI Embedded Collections are what you configure in Azure to host one or more Power BI Embedded Workspaces.
Power BI Embedded Workspace system generated guid The Power BI Embedded Workspace is where we can upload one or more reports.
Power BI Embedded Report TemperatureChart The TemperatureChart report is a pre-built report that displays device and temperature data from the <name>db Azure SQL Database. It is provided as the TemperatureChart.pbix Power BI Desktop file in the lab files. We'll upload this report into our Power BI Embedded Workspace and then embed it in the UI of our Web Application. Users viewing the web application in their browser can then see that report.

Documenting Your Choices

We'll document the choices, names, connection strings, keys, etc. for the resources we create into a text file called myresources.txt. This file is in the root of the HOLs/ folder wherever you copied or extracted the lab files for this lab to. By documenting key pieces of information here it will make it much easier to retrieve them later. You often need a connection string, or key for a resource long after you created it. By recording the values here it keeps you from having to navigate back through the Azure Portal every time you need to retrieve a value.

You could really edit myresources.txt with any text editor, but we'll be using Visual Studio Code for a number of tasks throughout this lab, so we'll take the opportunity here to get it open:

1. Open Visual Studio Code (if you don't have it installed you can download it for free for any platform from

2. From the Visual Studio Code menu bar, select File | Open Folder..., navigate to the folder where you extracted the lab content for this workshop, and select the HOLs folder.

3. In the Explorer panel, click on the myresources.txt file to open it. In the file, you can see numerous placeholders for information you will be collecting throughout this lab:

Note: You may notice that the colors used by your instance of Visual Studio Code don't match the colors shown in the screenshots in this documentation. The screenshots here were taken with Visual Studio Code's Color Theme set to Light+ (default light). If you want to change yours to match (not required), from the Visual Studio Code menu bar select File > Preferences > Color Theme, then in the command palette drop down, select Light+ (default light).

4. Take the time now to update the myresource.txt file with appropriate values for the:

Note: when replacing placeholders throughout the lab, make sure to remove the < and > symbols at the ends of the placeholder as well.

  • Naming convetion prefix
  • Region (data center)
  • Resource Group Name

For example, here's the section with the mic16 prefix, and West US region selected: