For some reason it’s not straight-forward to create new credentials for an existing Service Principal account in Azure Active Directory using PowerShell.

I’m using PowerShell, because I’m not an Azure AD admin in my current organization, but as a developer, I am able to create and manage service principal accounts. This is extremely convenient, because we use them for automated deployments to Azure.

We started using Azure DevOps release management about a year ago, and thus I recently encountered the first credential expiration of a service principal that was used by Azure DevOps to deploy resources to Azure. This makes sense, because service principal credential lifetime defaults to one year.

I’ve started working with Azure DevOps (previously known as Visual Studio Team Services – VSTS, previously known as Visual Studio Online…).

I’m using it to automated Azure deployments in some projects.

In our setup we have several different environments (dev, test, prod, etc.). Depending on the project, the environments are either Azure Resource Groups or completely different Azure subscriptions. In any case, we have created service principal accounts in our Azure Active Directory, that have the necessary Contributor roles to those subscriptions or resource groups, where they should be able to deploy resources.

The service principals have been added to Azure DevOps as Service Connections, so that we have a service connection for each project and environment.

We want to use a Release Pipeline for each project. Each Pipeline has a stage per environment.

Releases are triggered using package management (in these projects we don’t use VSTS for source control and build). Instead, our build server generates NuGet packages and uploads them to Azure DevOps package management, and this triggers the release process.

In that post, I also showed how to create a Device Enrollment Group within the Device Provisioning Service (DPS). That’s all very nice, but the purpose of IoT Hub and the DPS is to connect devices. So let’s go ahead and do that.

First of all, the device needs its own certificate, which is trusted by the root CA certificate configured in the DPS device enrollment group.

At the very least, it is necessary to have a root Certificate Authority (Root CA) that can be used to sign device certificates.

The devices authenticate with the DPS using a device certificate which is signed by the root CA. That way, the DPS can verify that the device is allowed to connect to the DPS and be provisioned for communicating with the Azure IoT Hub.

It is better if the root CA is used to sign an intermediate CA certificate, which in turn can be used to sign the device certificates. Depending on the need, there can be a chain of intermediates.

The reason for the intermediate certificates is that it makes it easier to see who or what signed a device certificate. If it should become necessary to revoke the intermediate, only a subset of device certificates will stop functioning.

While it is possible to use a public CA as the root CA, it is not necessary. It is possible to create a root CA certificate on your own and use that for DPS. The whole area of X.509 certificates is complicated, so it may be a good idea to consult with professionals in the field before rolling your own CA.

This blog post is the first part of a series that will include C# code to create a certificate chain. The finished project also includes a sample showing how to let an IoT Hub device provision itself without factory-installed certificates or Hardware Security Module based tokens.

I recently wanted to create an Azure Resource Manager (ARM) template with a number of interdependent resources. This post contains a number of “Things I Learned”. Hopefully, you can avoid some of the problems I had.

The resources were:

SQL server and database

Azure function app

Azure web app for an ASP.NET Core site

Storage account

Application Insights instance for the web app

Application Insights instance for the function app

In my previous post I described a place to get detailed logs about Web App site extension installation. I had spent a long time to figure out the reason that the installation of the Application Insights site extension failed.

While trying to figure out a problem I had when using an ARM template to deploy a web app to Azure, I found a nice debug log that contains the full steps that the web app makes to install site extensions.

In the first part of this series I wrote about what Azure Application Insights (AI) can do and how to add extra information to the tracking telemetry your application sends to AI.

The solution that I wanted to add AI tracking to was a Windows Service with self-hosted WCF services. One service is the server side of a SOAP service where the caller defined the SOAP WSDL, and the other WCF service is a single method that receives raw XML as a http POST message. To track each request to the WCF service, I decided to use a message inspector.

I’ve previously (1, 2, 3) posted about Application Insights when it was part of Visual Studio Online. It has been moved to the Azure portal, and now has a slightly different API.

It can be used to detect crashes, tracks performance issues and usage of mobile apps, web apps and more.
I’ve used it on a few web sites hosted in IIS or on Azure, and it works great.
For ASP.net web sites, it’s really easy to set up and get going. There the VS2015 integration to it makes it really seamless, and if you can follow a few wizard steps, there is no additional setup needed.

However, if you don’t have a mobile app, an ASP.net site on Azure or local IIS or a J2EE application, then there are no wizards, and no easy setup.

I have an Azure Cloud service which consists of web and worker roles. To make it quicker to update the cloud service whenever I’ve made changes to it, I want to deploy it from Visual Studio Online.

I already use VSO for source control for this project, and I have previously used the XAML based build process in VSO. Since I was going to move the project from one Azure account to another (from my play/test account to the business account), I decided to change the build process.