In today’s world we’re receiving an enormous amount of e-mail.
A lot of the e-mail I’m receiving during the day (and night) is about errors happening in our cloud environment and sometimes someone needs to follow up on this.

At the moment this is a real pain because there’s a lot of false-positives in those e-mails due to the lack of configuration and possibilities in our monitoring software. The amount of e-mails is so painful, most of us have created email rules so these monitoring emails ‘go away’ and we only check them once per day. Not really an ideal solution.

But what if I told you all of this pain can go away with some serverless magic and the power of Microsoft Teams. Sounds great, right?

How to integrate with Microsoft Teams?

This is actually the easiest part if you’re a developer.

If you’re already running Microsoft Teams on your Office 365 tenant, you can add a channel to a team to which you belong and add a Webhook connector to it. I’ve created a channel called `Alerts` on which I added an `Incoming Webhook` connector.


After having saved the connector you’ll be able to copy the actual webhook URL which you need to use in order to POST messages to the channel.


In order to test this webhook, you can spin up Postman and send a POST request to the webhook URL.

The only thing you need to specify is the `text` property, but in most cases adding a `title` makes the message a bit prettier.

	"title": "The blog demo",
	"text": "Something has happened and I want you to know about it!"

When opening up the Teams you’ll see the message added to the channel.image

That’s all there is to it in order to set up integration from an external system to your Team.

How will this help me?

Well, think about it. By sending a POST to a webhook, you can alert one (or more) teams inside your organization. If there’s an event which someone needs to respond to, like an Application Insights event or some business logic which is failing for a non-obvious reason, you can send this message real-time to the team responsible for the service.

Did you also know you can create so-called ‘actionable messages’ within Teams? An actionable message can be created with a couple of buttons which will invoke an URL when pressed. In Teams this looks a bit like so:


By pressing either one of those buttons a specified URL gets invoked (GET) and as you can probably imagine, those URL’s can be implemented to resolve the event automatically which has triggered the message in the first place.

A schematic view on how you can implement such a solution is shown below.


Over here you’re seeing an Event Grid, which contains events of stuff happening in your overall Azure solution. An Azure Function is subscribed to a specific topic and once it’s triggered a message is being posted on the Teams channel. This can be an actionable message or a plain message.
If it’s an actionable message, a button can be pressed which in its turn also sends a GET-request to a different Azure Function. You want this Function to be fast, so the only thing it does is validate the request and stores the message (command) on a (Service Bus) queue. A different Azure Function will be triggered, which will make sure the command will be executed properly by invoking an API/service which is responsible for ‘solving’ the issue.
Of course, you can also implement the resolving logic inside the last Azure Function, this depends a bit on your overall solution architecture and your opinion on decoupling systems.

How will my Azure Function post to Teams?

In order to send messages to Teams via an Azure Function, you will have to POST a message to a Teams webhook. This works exactly the same as making a HTTP request to any other service. An example is shown over here.

private static readonly HttpClient HttpClient = new HttpClient();

public static async Task Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "InvokeTeams")]
    HttpRequestMessage req,
    ILogger log)
    var message = await req.Content.ReadAsAsync<IncomingTeamsMessage>();

    var address = Environment.GetEnvironmentVariable("WebhookUrl", EnvironmentVariableTarget.Process);
    var plainTeamsMessage = new PlainTeamsMessage { Title = message.Title, Text = message.Text };
    var content = new StringContent(JsonConvert.SerializeObject(plainTeamsMessage), Encoding.UTF8, "application/json");
    await HttpClient.PostAsync(address, content);

public class IncomingTeamsMessage
    public string Title { get; set; }
    public string Text { get; set; }

private class PlainTeamsMessage
    public string Title { get; set; }
    public string Text { get; set; }

This sample is creating a ‘plain’ message in Teams. When POSTing a piece of JSON in the `IncomingTeamsMessage` format to the Azure Function, for example, the following.

	"title": "My title in Teams",
	"text": "The message which is being posted."

It will show up as the following message within Teams.


Of course, this is a rather simple example. You can extend this by also creating actionable messages. In such a case, you need to extend the model with the appropriate properties and POST it in the same way to Teams.

Even though Teams isn’t something I develop a lot for (read: never), I will spend the upcoming weeks investigating on how to update our DevOps work to the 21st century. By leveraging the power of Teams I’m pretty sure a lot of ‘manual’ operations can be made easier, if not automated completely.

Normally when you are creating new appointments via Outlook in your organization you are inviting everyone who should join the meeting. This works quite alright, but not something I wanted to do for a couple of meetings I am planning. The meetings I’m organizing are optional to everyone inside the company, therefore I don’t want to spam the inbox of everyone with a meeting most of them (probably around 95%) aren’t interested in.

What I want to do is share the appointment with all of the people inside (or outside) the organization via a shared portal, like Yammer, SharePoint, Slack, etc., and let them choose to add or ignore the meeting.

Sounds easy right?

Normally you will do this by opening the meeting, save it as an ICS file and share it.


However, this didn’t work for me this time!

When people opened this ICS file in Outlook, they were not able to send a response as the meeting was stating “As the meeting organizer, you do not need to respond to the meeting.” with a big button shown in the ribbon saying “No Response Required”.


This struck me as quite strange as sending the invitation by inviting people (the normal flow) does work properly.

Because an ICS file is just a text file I decided to open up the file in my favorite text editor. Somewhere in this file I could see a line describing the organizer (me).

ORGANIZER;CN="Jan de Vries":invalid:noemail

Apparently my e-mail address wasn’t added to this line. I decided to change the `invalid:noemail` to my e-mail address and save the file.

ORGANIZER;CN="Jan de Vries"

This time, after opening the newly saved ICS appointment in Outlook, all appears to be working fine again.


The Accept/Tentative/Decline buttons are back, there’s an e-mail address stated at the end of my name. I can also acknowledge the appointment is working as I’ve received multiple `Accept` mails in the past couple of days.

Hope it helps. If someone had written about this earlier (and I was able to find the post on it) it could probably have saved me quite some time!

For our automated deployments we have several Azure Organizational accounts in place. These are created within the Azure Active Directory.

Because these accounts are meant for services, we don’t want them to inherit the default password policy for renewing their passwords every X days. Lucky for us, you can configure this via PowerShell. A short how-to is written on MSDN.

The thing that isn’t written (or referenced) over there is how to run the MSOL cmdlets.

I kept getting the messages `The term 'Set-MsolUser' is not recognized`. By searching a bit on this error I found a thread on the Office365 community forums where someone mentioned the “Microsoft Online Service Module for Windows PowerShell”. This set me off to searching in the right direction. Apparently you need to install a (new/extra) PowerShell module on your system in order to use the MSOL cmdlets. These cmdlets are part of the Office365 and Exchange Online services. A page with download links is provided by Microsoft Support. They provide a link to the Microsoft Online Service Sign-in Assistant for IT Professionals and the Azure Active Directory Module for Windows PowerShell (32-bit and 64-bit).

Once installed, you are finally able to use the MSOL cmdlets. Keep in mind though, you have to connect to the MSOL services first using the connection cmdlet.

Connect-MsolService -Credential $azureADCredentials

After connecting to the service, you can change the service account it’s password behavior to `Password Never Expires`.

For reference, this is the script I’ve used when changing the service account password policies:

function Set-CustomerAzureSubscription($subscriptionName)
    $azureSubscriptionSecurePassword  = ConvertTo-SecureString -String $azureSubscriptionPassword -AsPlainText -Force
    $azureCredentials = New-Object System.Management.Automation.PSCredential($azureSubscriptionUsername, $azureSubscriptionSecurePassword)

    Add-AzureAccount -Credential $azureCredentials
    Get-AzureSubscription | % { Write-Host "Customer subscription: $($_.SubscriptionName)."}
    Write-Host "Selecting $($subscriptionName) as default Customer subscription."
    Select-AzureSubscription -SubscriptionName "$($subscriptionName)"

function Set-PasswordNeverExpiresForServiceAccounts($serviceAccountUsername, $serviceAccountPassword)
    $azureADCredentialsSecurePassword  = ConvertTo-SecureString -String $serviceAccountPassword -AsPlainText -Force
    $azureADCredentials = New-Object System.Management.Automation.PSCredential($serviceAccountUsername, $azureADCredentialsSecurePassword)
    Write-Host "Connecting to MSOL"
    Connect-MsolService -Credential $azureADCredentials

    Write-Host "Password never expires status of $($serviceAccountUsername)"
    Get-MSOLUser -UserPrincipalName $serviceAccountUsername | Select PasswordNeverExpires
    Write-Host "Setting password never expires status of $($serviceAccountUsername) to 'true'"
    Set-MsolUser -UserPrincipalName $serviceAccountUsername -PasswordNeverExpires $true
    Write-Host "Password never expires status of $($serviceAccountUsername)"
    Get-MSOLUser -UserPrincipalName $serviceAccountUsername | Select PasswordNeverExpires

Set-CustomerAzureSubscription $devSubscription
Set-PasswordNeverExpiresForServiceAccounts $devServiceAccount $devPassword

Set-CustomerAzureSubscription $accSubscription
Set-PasswordNeverExpiresForServiceAccounts $accServiceAccount $accPassword

Set-CustomerAzureSubscription $prodSubscription
Set-PasswordNeverExpiresForServiceAccounts $prodServiceAccount $prodPassword