Automating Azure AD B2B Invites with Approval Workflow

The Problem

Users want to collaborate with external parties. You have a few options to accomplish this:

  • Share anonymously
  • Share with any authenticated user
  • Share with existing authenticated user
  • Share with organization only

None of these work well when security and scale are required.

The best of both worlds would be to allow your end users to request access for an external user and then to kick off an approval workflow. If approved by the appropriate parties, a B2B invite will be automatically sent to the desired email address. Once invited, the user can then share with that account. This is assuming you have your org configured so sharing is only possible with existing external accounts.

The Solution

With an Office 365 subscription, you get a product called Microsoft Flow. Most people just equate this to being Microsoft’s attempt at creating an IFTT knock off. However, it’s so much more than that. You can, in essence, build out an entirely server-less API that you can interact with. It’s much closer to Azure Functions or Azure Logic Apps than IFTT.

In this blog post, I’m going to walk you through creating a Flow with an approval process to automatically add B2B users to your Azure AD tenant. Let’s go!

Initial Trigger

In order to make our Flow run, we want a trigger that provides it with input. There are many ways to do this, but I’m using a Microsoft Form (also part of O365). When the form is submitted, the flow will grab the values and do “stuff” with it.

First, go to the Forms app from (or just go to Once there, click the button to create a new form. You can build your form to request whatever information you’d like. Here’s what I have and use in my Flow.

Now that the form is created, lets move over to Flow to get to the meat and taters. Buckle up, it’s a bit lengthy.

Flow Build

Head on over to again and find the Flow app. If you don’t see it, make sure you have the license assigned.

NOTE: For security reasons, you should create a new Flow Environment to create this (and future) Flows in. This will allow you to control who in your organization can access and run the Flow. Otherwise, everyone in your org can potentially be given access to view the Flow.

Create a new Automated – from Blank Flow

Now fill out the Flow name and choose the When a new response is submitted option as the initial trigger.

Once you have created the empty Flow, choose the Form that you created in the trigger.

Before we can continue, we need to hop over to Azure AD to register an App, grant it permissions and generate a secret (password) that we can use in our Flow for programmatically interacting with Azure AD.

Head over to –> Azure Active Directory

Now go to App Registrations

Click on New Registration and fill out the details

Once created, save the Application ID and Tenant ID for later

Now we need to assign the App some permissions. It only needs enough access to perform the actions required. Step through the screenshots below to setup the App permissions.

Add API permissions to the app so it can interact programatically
Microsoft Graph is the API used for interacting with Azure AD
Use Application permissions so this can operate without user interaction.
Grant these permissions to the app. The User.Read is there by default.
Grant consent for all users (otherwise this won’t work)

Ok – Now that the permissions are squared away, lets create a secret that we can use to authenticate with. Go to Clients and Secrets in the app.

Create a new Client Secret

Give it a meaningful description and choose an expiration time that meets your requirements. Just know the Flow will break will the secret expires until you generate a new one and update the Flow. Make sure you copy the secret for use later (keep it somewhere secure like a password manager)

Head on over to page two for more…

Pages: 1 2 3

Disappearing Windows 10 Event Logs After Feature Update

I’ve recently read a few tweets stating that Windows 10 is blowing away log files after installing feature updates (such as the latest Fall Creators update). While at first glance, this may seem to be the case, it’s actually a false statement. I believe this misconceptions stems from the fact that many don’t know that feature update is NOT a patch or service pack like the OS’s prior to Windows 10. Instead, it is an entire OS upgrade. What’s really happening is that new event logs are being created, but your old event logs are still accessible.

  1. When a feature update is performed, Windows creates a backup of your previous build in C:\windows.old
  2. All of the previous event log files are available in C:\windows.old\windows\system32\winevt\logs
  3. In an enterprise enviroment, feature updates are typically scripted and not left to the automatic updating process built into Windows
  4. To prevent from losing historic event logs, a sysadmin could easily run a post-update script to copy those old event logs to a more permanent location. Maybe something like C:\windows\system32\winevt\logs\previous build

Here’s a little screenshot as proof that the event logs remain after a feature update: