Update your Azure Sphere OS to 18.11 before Jan 15 2019

Azure Sphere

Update your Azure Sphere OS from 4.2.1 to 18.11 before January 15, 2019

Azure Sphere development kits became available in September of 2018. I had pre-ordered one and received it very quickly from Seeed Studio. I even wrote up my first impressions of it here.

On November 5 Microsoft announced that there was an OS update coming for the Azure Sphere development board the week of November 12.

After the release of 18.11, we encourage you to upgrade your device OS and SDK as soon as possible. After the release, devices that run the TP 4.2.1 release won’t receive any OTA updates for either device or application software. However, device authentication and attestation will continue to work to authenticate to Azure IoT Hub. TP 4.2.1 will continue to be supported until January 15, 2019. Thereafter, devices that are running the TP 4.2.1 OS won’t be able to authenticate to Azure IoT Hub.

Along with the change to the OS version naming, new Features were detailed here in the release notes;

    • Real-time clock (RTC). A Beta API enables applications to set and use the internal clock and leverages support for using a coin-cell battery to ensure the RTC continues to keep time when power is lost.
    • Mutable storage. A Beta API provides access to a maximum of 64k for storage of persistent read/write data.
    • External MCU update. A reference solution shows how your application can update the firmware of additional connected MCUs.
    • Private Ethernet. The MT3620 now supports connecting to a private, 10 Mbps network via the Microchip Ethernet part over a serial peripheral interface (SPI). This functionality allows an application running on the A7 chip to communicate with devices on a private network via standard Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) networking. Stay tuned to the Azure Updates website for more information about this capability.
    • Beta API targeting. Beta APIs are still in development and may change in or be removed from a later release. Starting with this release, we make them available for testing and feedback so that you can get a head start on using new features. You can target applications for either the production APIs or the production and Beta APIs.

Upgrading Azure Sphere OS to 18.11

The upgrade process is manual from 4.2.1 to 18.11. The details are described in the update section of the release notes here. Essentially the process is;

  • Update your Azure Sphere SDK
  • Move the Azure Sphere device to a System Software Only Group
  • Upgrade the Azure Sphere OS
  • Verify the devices status

With the updated SDK installed, running the commands was quick and successful.

Move Device to System Only Group
Move Device to System Only Group
Azure Sphere OS Updated
Azure Sphere OS Updated


You’ve got 10 days left to update your Azure Sphere OS before it will no longer be able to connect to Azure IoT Hub. The update is quick and painless (unless you have dozens to update).

Azure Sphere – Initial Setup, Configuration and First Impressions

Azure Sphere

In April this year, Microsoft announced Azure Sphere. This was the same week as I’d be preparing for a presentation I was giving on Azure IoT at the Sydney location for the Global Azure Bootcamp. When pre-orders became available from Seeed Studio I naturally signed up as I’ve previously bought many IoT related pieces of hardware from Seeed Studio.

Fast forward to this week and the Azure Sphere MT3620 device shipped. It’s a long weekend here in Sydney Australia and delivery wasn’t due until after the long weekend, but by some miracle the packaged was delivered on the Friday by DHL after only leaving China 3-4 days earlier.

What a great opportunity then to un-box it, get it configured and build the sample “Hello World” (Blinky) project.

Getting Started

Following the “Get Started Guide” here I was straight away perplexed as to why Visual Studio was required, when I’ve made the complete transition to Visual Studio Code.

It seems there isn’t support in the IoT Workbench Extension in VS Code for the MT3620 yet.

Azure IoT Workbench.PNG

After patching and updating my now out-of-date Visual Studio installation I was finally able to install the VS Tools for Azure Sphere.

Azure Sphere VS Tools.PNG

which also comes with the TAP Driver for communicating with the device via the USB port, which is necessary for setup.

TAP Driver.PNG

With that all done it needs to be connected to Azure Active Directory. For that I created a new user for use with Azure Sphere in my Azure AD Tenant and then proceeded to login to Azure AD with that account.

azsphere login

azsphere login.PNG


Successfully logged in (if you try with a Microsoft Account you’ll get a message indicating Azure AD is required), it prompts you to create an Azure Sphere Tenant.

Create Tenant

NOTE: Claiming the Device

Claiming the Device.PNG

With the Azure Sphere Device connected the Windows 10 computer you are executing the command from, as this is the first time setup an Azure Sphere Tenant needs to be created and the device claimed.

azsphere tenant create --name 
azsphere device claim

Claim Device.PNG

Connecting to Wifi

With the Azure Sphere Tenant created and the device claimed its time to connect it to Wifi.

azsphere device wifi show-status
azsphere device wifi add --ssid  --key

Connect Azure Sphere to Wifi.PNG

Checking the Wifi Connection Status after connecting provides the device connection status.

azsphere device wifi show-status

Azure Sphere Wifi Status.PNG

Checking the Azure Sphere OS Version against what is available shows it’s on the latest.

azsphere device show-ota-status

Azure Sphere OS Version.PNG

Blink Example Project

With the device now configured it was time to try out the sample project. Again following the instructions I first Enabled Debugging.

azsphere device prep-debug

Enable Azure Sphere Debugging.PNG

Following the example as per the Getting Started Guide I built the Blink Example project.

New Project Azure Sphere Blink Example.PNG

and ran it. It all worked as per the instructions. Pressing the A button with debugging enabled allow the state of the device (button) to be read and output.

Blink Example with Debugging.PNG


The setup was very quick, completely painless and just worked. So initial impressions are positive. My only gripe is that the Azure IoT Workbench Extension for VS Code doesn’t support the hardware. I’m hoping that comes soon.

Now to build something with it. What to build ……..

How to quickly copy an Azure Web App between Azure Tenants using ‘Zip Push Deploy’

In the last couple of weeks I’ve had to copy a bunch of Azure WebApps and Functions from one Azure Tenant to another. I hadn’t had to do this for a while and went looking for the quickest and easiest way to accomplish it. As with anything cloud based, things move fast. Some of the methods I found were too onerous and more complex than they needed to be. There is of course the Backup option as well. However for WebApps that is only available if you are on a Standard or above tier Plan. Mine weren’t and I didn’t have the desire to uplift to get that feature.


In this post I show my method to quickly copy an Azure WebApp from one Azure Tenant to another. I cover copying Azure Functions in another post. My approach is;

  • In the Source Tenant from the WebApp
    • Download the Automation Scripts for the WebApp
    • Using Kudu take a backup of the wwwroot folder
  • In the Target Tenant
    • Create a new Resource from a Template
    • Import the Deployment Automation Scripts from above
    • Modify for any changes, Resource Group, Location etc
    • Use Zip Push Deploy to upload the wwwroot archive and deploy it

Backing up the WebApp in the Source Tenant

Open your WebApp in the Azure Portal. Select Automation Script

WebApp Deployment Script

Download the Automation Script

Save Deployment Script

Select Advanced Tools

Kudu Adv Tools

Select the Site Folder then on the right menu of wwwroot select the download icon and save the backup of the WebApp.

Download WWWRoot Folder 3.png

Expand the Deployment Script archive file from the first step above. The contents will look like those below.

Expand the Deploy Script Archive.PNG

Deploy the WebApp to another Tenant

In the Azure Portal select Create a Resource from the top of the menu list on the left hand side. Type Template in the search box and select Template Deployment then select Create. Select Build your own template in the editor. Select Load File and select the parameters.json file. Then select Load File again and select the template.json file. Select Save.

Load Parameters then Template JSON Files

Make any changes to naming, and provide an existing or new Resource Group for the WebApp. Select Purchase.

New Template Deployment - Change Parameters

The WebApp will be created. Once completed select it from the Resource Group you specified and select Advanced Tools. From the Tools menu select Zip Push Deploy.

Tools Zip Push Deploy

Drag and drop the Zip file with the archive of the wwwroot folder you created earlier.

Drop WebApp ZipFile Export via Kudu

The zip will be processed and the WebApp deployed.

Deployed WebApp

Selecting the App in the new Tenant we can see it is deployed and running.

App Running.PNG

Hitting the App URL we can see that is being served.

Deployed App.PNG

This WebApp is the Microsoft Identity Manager User Object Report that I detailed in this post here.


In less that 10 minutes the WebApp is copied. No modifying JSON files, no long command lines, no FTP clients. Pretty simple. In the next post I’ll detail how I copied Azure Functions using a similar process.

Keep in mind if your WebApp is using Application Settings, KeyVaults, Managed Service Identity type options you’ll need to add those settings, certificates/credentials in the target environment.

Integrating Azure IoT Devices with MongooseOS MQTT and PowerShell

Introduction and Recap

In my last post here on IoT I detailed getting started with Azure IoT Hubs and registering an IoT device and sending telemetry from the IoT Device to the Azure IoT Hub. And doing all that using PowerShell.

If you haven’t read that post or worked through those steps, stop here, work through that and then come back. This post details configuring MongooseOS to receive MQTT messages from Azure IoT which is the last mile to making the IoT Device flexible for integration with anything you can think of.


The only change to my setup from the previous post is I installed the Mongoose Demo App onto my ESP8266 device. Specifically the demo-js App detailed in the application list here. Install is quick and simple on Windows using the MOS Tool. Details are here. I also enabled the Mongoose Dashboard on my Mongoose IoT Device so that I don’t have to have the IoT Device connected to my laptop when configuring and experimenting with it. Essentially check the checkbox for Dashboard when configuring the IoT Device when connected locally via a USB cable.

The rest of the configuration is using the defaults in Azure IoT with respect to MQTT.

MongooseOS MQTT Subscribe Configuration – Init.js

On your IoT Device in the MongooseOS init.js we need to configure the ability to subscribe to a MQTT topic. In the first post we were publishing to send telemetry. Now we want to receive messages from Azure IoT.

Include the following lines in your init.js configuration file and restart your IoT Device. The devices//messages/devicebound/# path for the MQTT Subscription will allow the IoT device to subscribe to messages from the Azure IoT Hub. 

// Receive MQTT Messages from Azure
MQTT.sub('devices/' + Cfg.get('device.id') + '/messages/devicebound/#', function(conn, topic, msg) {
 print('Topic:', topic, 'message:', msg);
}, null);

In order to test the configuration of the IoT Device I initially use the Device Explorer. It is available from GitHub here. The screenshot below shows me successfully sending a message to my IoT Device.

DeviceExplorer to IoT Device.PNG

From the Mongoose OS Dashboard we can inspect the Console Log and see the telemetry we are sending to the IoT Hub, but also the message we have received. Success.

Mongoose Device Log.PNG

Sending MQTT Messages from Azure IoT to MongooseOS using PowerShell

Now that we’ve verified that we have everything setup correctly let’s get to the end goal of sending messages to the IoT Device using PowerShell. Here is a little script that uses the AzureIoT Module that we used previously to assist with configuration automation, to send a message from Cloud to Device.

Update it for your Resource Group, IoTHub, DeviceID and IoTKeyName. Also the message if you feel the need (line 40).

Hello from the Cloud via PowerShell MQTT Message Received.

Cloud to Device ConsoleLog.PNG


Through the two blog posts I’ve detailed the creation of an Azure IoT Hub, registration of an IoT Device, sending telemetry from MongooseOS on the IoT Device to Azure IoT and now sending messages to the IoT Device from Azure, all via PowerShell. Now we have end to end connectivity bi-directionally, what can we do with it? Stay tuned for future posts.

Connecting to and Using the Azure MFA Web Service SDK Server SOAP API with Powershell


A colleague and I are validating a number of scenarios for a customer who is looking to deploy Azure MFA Server. One of the requirements from an Identity Management perspective is the ability to interact with the MFA Server for user information. That led us on the exploration of what was possible and how best to approach it.

The title of this post has pretty much given it away as to how. But why ? As Azure MFA Server is a product that Microsoft have acquired through the acquisition of Phone Factor, the usual methods of interacting with applications and services in the Microsoft Stack don’t apply. There is practically no information on how to use Powershell to interact with Azure MFA Server. So this blog post details what we’ve learned and how we have been able to get information out of Azure MFA Server using Powershell.

This post covers;

  • Connecting to the Azure MFA Web Service SDK
  • Searching for users in the MFA Database
  • Returning information about users in the MFA Database
  • Making a test call to a users phone via the MFA Server


There are a number of prerequisites that I’m not covering here as you can quickly locate many guides to installing/configuring Azure MFA Server.

  • You’ll need to have an Azure MFA environment (obviously)
  • Download the Azure MFA Web Service SDK
  • Install and Configure the Azure MFA Web Service SDK
  • If you aren’t using a Public SSL Cert on the Azure MFA Web Service SDK Server you will need to export the certificate from the Azure MFA Web Service SDK Server and import it to the Trusted Root Certificate Store on the workstation you’ll be using Powershell on to connect to the MFA environment.

Connecting to the Azure MFA Web Service SDK

Now that you’ve met the prerequisites listed above you can use Powershell to connect to the API. The URL is the DNS name of the Azure MFA Web Service SDK Server following by the SDK SOAP endpoint. eg. https://mfa.yourdomain.com.au/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx?WSDL

Try out the URL in your browser and using an account that exists in the MFA Server authenticate to the Azure MFA Web Service SDK Server. If it is setup correctly (including your SSL certificate)  you will see the following.

The simple script below will perform the same thing, but via Powershell. Update for your domain, username, password and URL for your MFA Web Service SDK Server.

Searching for users in the MFA Database

Now that we’ve setup a web services proxy connection to the MFA Web Service SOAP API endpoint we can start getting some info out of it. Searching for users uses the ‘FindUsers_4’ call. It has many parameters that can be set to alter the results. I’ve gone simple in this one and used ‘*’ as the criteria to return all users in the MFA Database. Alter for your purposes.

Returning information about users in the MFA Database

Using a slightly different criteria to the Search criteria above I returned one entry and set the $mfauser variable to them. I then use that in the GetPhone, GetUserSettings & GetUserDevices calls as shown belown to retrieve all the info about them.

Making a test call to a users phone via the MFA Server

Finally rather than just consuming information from the MFA environment let’s actually trigger something. Selecting an identity from our test environment that had the mobile phone number of a colleague associated with it, I triggered MFA Server to call them to authorize their session (which they hadn’t obviously requested). I may have done this a few times from the other side of the room watching with amusement as their phone rang requesting authentication approval 🙂

Full script snippets below.

Hope that helps someone else.

Follow Darren on Twitter @darrenjrobinson