Category: Testing

Microsoft Flow, Microsoft Forms and Azure AD – what can we do?

Recently, I have been playing around more and more with Microsoft Flow – which is a tool designed to Automate processes and tasks. In a previous post I used a tool called Stringify to automate a number of Smart Home actions. Microsoft Flow provides a similar environment and allows integration between processes and tasks.

I was impressed from the first time I played with Microsoft Flow at how powerful the tool could be – and immediately set to work creating a simple flow, which I am going to demonstrate here.

Onboarding a new Azure AD User, by filling in a simple online form – the Flow will:

  1. Create the AD User Account based on the username we specify
  2. Set the users password based on a password we specify
  3. Add the user to either the “Staff” or “Student” Department
  4. Send an email notification with the account details ready for use

The key here is that this process can now be carried out, with commonality and uniformity, by someone with no technical knowledge of Azure AD at all.

To start this process – we need a Form. I’ve created a simple form in Microsoft Forms to capture all of the information above, to integrate this into Microsoff Flow. Creating forms is super simple in Microsoft Forms – I’ve created a basic new user data gathering form for our Flow below:

Now – when this form is filled in, we have the information captured that we will need for our Flow. The next step is to start building the Flow. To do this, log into Microsoft Flow and click on “Flows” and then “Create from Blank”:

Next up, we need to add a Trigger – this is an event that will cause our Flow to run. In our case – it will be when a new submission to our Form is received. Just search for Forms and then you’ll see the options required:

When we have selected “When a new response is submitted”, we then see the first step in our Flow has been added:

We need to tell Flow which Form to use now – because I am signed into my Microsoft Account, any forms I have in my account are shown in the drop down list:

Now we have our trigger, we need an action to follow – in this case, we need to get the Form response details. Do do this, just click on “New Step” (shown above) and then search for Forms:

You’ll see now that we need to select our Form again, so that the correct Form is associated with this step in the Flow:

When we add this Form you’ll notice we also have to specify a “Response Id”. In our case, this needs to be Dynamic Content – so that each response is processed by our Flow. When we click into the Response Id area – a new Window will open where we can select Dynamic Content, and then click “See more” – we can then select “List of response notifications…”:

Upon selecting this – Flow will recognize that we want to carry out an action for each response we get – and an “Apply to each” section will be automatically created:

Now we can start creating the Azure AD elements of our Flow, to do this, click on “Add an action” above, and then search for “Azure AD” – we will start by creating the user:

Once this element has been added we can start adding Dynamic Content from our Form to the new user section of the Flow – you’ll notice that when you click into areas that support Dynamic Content, the Dynamic Content window will show as below:

Once completed, we have the following in place for our user creation step:

Next I am going to configure a simple email notification – to let me know what’s been created. We can do this with the “Add an action” option, and then search for “email”:

We can then use Dynamic Content, as we did before, to create an email based on the response to our Form:

Important: Obviously using this method is bad security practice (username and password in the same email) – and in this case is used just to give an idea of the capabilities of the Flow. In production use, using something like the Office 365 “Send an Email” is better – as this supports sending to different addresses, so for example, the username and password can be sent to different lists or addresses. For example, the username to the new user, and the password to the manager (without the username).

Finally – we can test our Flow. To do this, it’s just a case of filling in the Form created earlier:

We can check that our Flow has run from the Flow web interface:

And also – drill down into exactly what was run by clicking on the “Succeeded” (or Failed) in Run History – below you can see some of the variables my Form data contained:

The next step is to check that an Azure AD user has actually been created:

Bingo – everything looking good here… and below we have the user with the details from our Form correctly filled in:

Finally – we can check to confirm we have been emailed the confirmation message with the details of the user account:

As you can see – the Flow has worked as expected, and we now have an Azure AD Account and email notification to go with it. Whilst this is really just scratching the surface of what we can do here – it gives an idea of where we could take this type of automation. A few things I can immediately think of for this type of new user scenario:

  • Add to numerous AD Groups – based on checkboxes in a form
  • Create an O365 Mailbox – based on username/names
  • Provide a welcome email to the mailbox
  • Notify a Slack or Teams channel that a new user has been created, for example “Please welcome [Username] to the department!”
  • Interact with one of the many 3rd party systems supported in Flow – for example adding the user to a CRM system, or SAAS application

Hopefully this has been interesting – and congrats for making it to the end of this post!

Smart Home tinkering – Using Stringify, Nest Cameras, and TP-Link Plugs to simulate house activity based on camera detections

First of all – Happy New Year, I hope 2019 is already going great for you!

This write up focuses on the use and integration of three things; Nest Cameras, TP-Link Smart Plugs and Lights, and Stringify (a tool that allows the creation of IOT Flows). The combination of all three provides a powerful way to create security routines and outcomes based on various triggers. I should point out, I’m fairly wary of the security implications of IOT devices in general, so for me I like to see them as a way to augment, rather than replace, traditional security products.

In this article I am going to demonstrate an integration routine I have setup recently:

  • When my Nest Camera(s) detect a person between the hours of 2300 and 0600, a Stringify Flow runs, which turns on lights in correct order to simulate a person coming downstairs. The routine then waits for a time period, and turns the lights off in the reverse order, to simulate a person going back upstairs. Finally, a push notification is sent out that provides an alert that the Flow has been run to a mobile phone.

To create this type of setup you need three things:

  • Cameras – I am using the Nest Outdoor Cameras
  • Smart Lighting/Plugs – I am using TP-Link Products, both plugs and bulbs
  • An IOT Tool to link the triggers to actions – I am using Stringify

It’s worth noting that you could use a number of different tools to achieve the same result – for example IFTTT works in a similar way to Stringify, and there are lots of IOT Camera and Lighting products out there.

So – how do we set this up?

To start – we need some cameras, here’s one of my Nest Cameras:

I have a few of these setup around the house – so pretty much anyone near the house is picked up by the cameras. Next, we need some smart lighting to allow for the lighting to come on. For this I have two products in use; TP- Link Smart Plugs and TP-Link Smart Bulbs.

Next, we need to create a Stringify Account – to do this you need to download the app for your device and sign up. Once completed you can create Flows and add Things, which are, in brief:

  • Flows – sequences of events/actions that are run by triggers we define
  • Things – these are the IOT devices we have added to our account

Before we can create a sequence, we need to add Things to our account – which is done by tapping on the + sign:

Next we can add accounts for our various smart devices – this will vary depending on what devices you are using, but for me it was just a case of adding my Nest and TP-Link accounts:

Once this is done, the devices/accounts show up in the home screen within Stringify:

We’re now good to go and can setup our first Flow. To do this, we need to open the Stringify App, and click on “Flows”, and then on the + symbol to create a new flow:

From here, we can start to build out a Flow. Here’s an overview of a completed Flow to give you an idea – we can then drill down into the building blocks that form this Flow:

As you can see – the Flow mainly comprises timers, and light actions (turning a light on or off). We can break this Flow down into 5 main sections:

Essentially the above Flow can be broken down into a few key elements:

  1. A trigger – or in this case, a trigger and a time variable. Both must be met for the sequence to run. In my case, it is that the Nest Camera must detect a person (not just activity – the ability to determine a person or just motion is a feature of the Nest cameras), and the time must be between 2300 and 0600. Unless both conditions are met the sequence won’t progress any further.
  2. The “Person coming down the stairs” sequence – this is just lights and timers that wait for time periods before kicking off the next light. So the first light comes on, then the sequence waits, and then the next light comes on, and waits, and so on…
  3. A wait – purely to act as a waiting time before the next element runs – effectively to simulate a person being downstairs doing something.
  4. The “Person going upstairs” sequence – again this is just lights and timers, so it simulates the lights going off as if someone was going upstairs. Exactly the same as element 2 but in reverse.
  5. This is the final element, AKA letting me know – a push notification, so my phone is alerted that the sequence has been run. This is a useful step as it allows me to be alerted to the fact that the sequence has run (so I have awareness) , and also to see what caused the sequence to run (I can make sure it was a legitimate activation and there is no cause for concern).

Using an automation sequence like this is great way to turn smart home products into a smart security feature. There are loads more possibilities you can create with Stringify too – for example, a few other things you could do with this sequence alone:

  • Integrate this sequence with other smart home products – for example using SmartThings you can connect to Siren/Strobe devices to trigger an alarm. For example if a person is spotted in your garden between a certain time range. All house lights come on and a siren going off is a good deterrent too, and certainly attracts attention!
  • Integrate this sequence with an Amazon Echo – for example “Alexa, I am leaving for work” turns off lights, but should a person be detected outside a radio starts playing inside, and a light comes on – to simulate someone being at home. Or turns lights on and off randomly during darker hours.

Or you could use a sequence like this to trigger smart home items during a danger scenario – for example, if Smoke is detected (via something like Nest Protect) then all house lights come on, regardless of the time of the day, and anything like a TV or Radio connected to a smart plug turns off. (So the only noise heard is the smoke alarm).

Hopefully this has been useful and gives an idea of how powerful the integration of these types of devices can be when linked with the right system to automate them. Until next time – thanks for reading! 🙂


Azure Storage Sync – the easiest branch office file sync solution?

Azure Storage Sync provides the means to synchronise files from various locations into an Azure Storage account and to endpoints running the Azure Storage Sync agent. In this post I will give a quick overview of how it can be setup to service branch office requirements whereby VPN connectivity does not exist. For further information see here: Here’s my environment which I will be testing with:

Both of my “Branch offices” are actually VMs running on my home lab – but on isolated networks, so they can only communicate outbound to the internet with no LAN access.

Essentially – the goal for this article is to show how to configure Azure Storage Sync to replicate files between Branch Office 1 and Branch Office 2, using Azure Storage as the intermediary.

There are a number of key components to this deployment:

  • An Azure Storage Account – this is where our file share will be hosted
  • An Azure File Share – this is where our replicated data will reside
  • An Azure Storage Sync Group – this is where the synchronisation will be configured and managed
  • Two installations of the Azure Storage Sync Agent that will sit on our Branch Office servers

To start, I have created a folder on Branch Office 1 called “HeadOfficeDocs” – this is the folder that I want to replicate, and it contains a couple of folders and files of “business data” that we need replicated across to Branch Office 2:

Next – we need to setup an Azure Storage account, and an Azure File Share to host the data. First up, I will create a storage account:

Once this has been deployed we can create a File Share – this is where our replicated data will reside:

Next we create a file share and give it a quota:

Once this has been created, we can setup the synchronisation! To do this, we need to create a new Azure File Sync resource:

And fill in a few details – note that the location should be the same as where your Azure File Share is hosted:

Once this has been created, we can access the Storage Sync Resource and create a Sync Group:

A Sync Group defines the sync topology that will replicate our files – so if you require different sets of data replicated then you will need to use different sync groups. For example we could sync completely different sets of data, but on the same or different file servers, in completely different locations, using the same Storage Sync Resource, but separate Sync Groups. This provides plenty of flexibility, and the option use the local file servers (in our Branch sites) to act as a cache for the Azure File Share, and thus reduce the amount of data that is replicated within the topology:

Creating the Sync Group is easy – just a few basic details to fill in; the Storage Account we have created, and the File Share that will host the data:

Once this is completed – we have the basics for our topology in place, and we need to register our first server into the topology. The registered servers pane will be blank at this point, as we have not yet installed the Azure File Sync Agent onto any Servers:

To start the process – log onto the first server and download the Azure File Sync Agent from this URL: Installation of the File Sync Agent is straightforward and simple – just keep clicking next (you can input proxy settings if you require)… the only configuration is the account we wish to associate the server to, which is completed after setup:

Just click “Sign in” and then follow the instructions – you’ll need to sign into your Azure account, and will then be prompted to select the Azure Subscription, Resource Group, and Storage Sync Service we are registering this server to:

Once this is done – just click “Register”. (You may get prompted to sign in again here – I did) – once completed, the registration process is completed:

Our newly registered server now shows up in the “Registered Servers” pane:

Next we need to configure the Sync Group – so that this server is added and starts to replicate data into our topology. To do this, browse to the Sync Group settings:

From here, we can add the server:

This is just a case of selecting the server from a drop down, and then entering the path where our data exists. Note – I am not using Cloud Tiering here as I want all data on all replication points within the topology:

Once this is done – our server is added to the Sync Group, initially it will show as provisioning, then pending, and then as healthy:

If we now look in the Azure File Share – we can see that the data from the server has been replicated into the Cloud:

So – we now have a single server in a replication topology between itself and an Azure File Share. If I add a new folder to the Branch Server – we see this replicated onto the Azure File Share after a short time:

Next – I will deploy the Agent to a new server (in another Branch) to test out the replication and initial sync. To do this it’s just a case of installing the Agent exactly as we did before – and ensuring that we register this server to the same Storage Sync Service. Once this has been completed, we register the server again (exactly as before – but with a different path if required) and then we will start seeing data being synchronised:

Note that I have used a different path – you can change this on a per server basis if you require, so there is no need to have all servers setup in an identical disk arrangement. If we look in the Sync Group pane after a short while for the sync to take place, we can see both servers are setup:

We can also see that the data has been replicated to the 2nd Server I have added:

Bingo – we now have a working topology that will keep data in sync between our offices using Azure File Sync. No VPNs required, no complicated configuration, just two Agent installations, and some basic Azure Configuration. This provides a simple and effective way to keep branch site data in Sync and provides a number of potential use cases whereby complicated setups would otherwise be required.

Until next time, Cheers!