Flow and Azure Automation, working in harmony!
Recently, the Microsoft Flow action Azure Automation was released, allowing us to interact with Azure Automation from Flow.
Although since early releases of Microsoft Flow we’ve been able to interact with Azure Automation by creating WebJobs, it has proved that many technical staff are not yet familiar with these. I believe this partly has a hand in why we haven’t yet heard the amount of integration stories between Microsoft Flow and Azure Automation as first anticipated.
To me, the integration between Microsoft Flow and Azure Automation means we can now fill in the gaps where there may not be a Microsoft Flow action available yet. It allows us to run scripts on demand or on a schedule. All that being said, let’s focus on the now.
Today, I’ll be creating a Flow that is triggered manually and requires user input; on execution of Flow it will start a run job in Azure Automation. This job will be executing a PowerShell script to reset a user’s password.
If we think of the scenario where a Desktop Support Technician is walking by the good old water cooler and a staff member pulls them aside and says ‘Hey, IT guy… can you help? I can’t login. I forgot my password… again. Can you reset my password?’ Rather than the wonderful person in support being required to go back to their desk and log back into Office 365 to reset the user’s password, they can simply enter the user’s email and execute the Microsoft Flow to reset it for the forgetful employee. Super simple! While this example is valid for the moment, there may well be an action released to reset a user’s password in the near future. But the focus of this blog post is that, while there are many actions available in Microsoft Flow, there may not yet always be one available to meet your particular business need – that’s where Azure Automation could fill the gaps!
Okay, let’s start – we will need to have an Azure tenancy, along with Azure Automation Service added. I won’t go into these basic steps as there is plenty of information about these on the web.
Right, so you’re now in Azure and you’ve added the Azure Automation Service and created a runbook. For this Demo, I’ve created a runbook called ‘ResetUserPassword’
Before we can start, we will be requiring the MSOnline Module so we can access the Office 365 tenancy, so let’s go ahead and add this in.
Access your Azure Automation account and click Assets > Modules
I can now either browse or search the Gallery to find the MSOnline module I’m looking for. Click Import and the module is now available for use.
Next, we will be required to set up our credentials for our Office 365 tenancy. From the Azure Automation left hand panel click Credentials > Add a credential. When adding your credentials, you will be required to provide a friendly name (this is important for when we are creating our script), and the username and password for the Office 365 tenancy. In this example as I am resetting a users password I have an account with Administrator privileges. Depending you’re requirement you may need to use a service account or equivalent with elevated privileges.
Now that both the module and credentials have been set up for the Office 365 tenancy, we can begin writing the PowerShell script that will be resetting the user’s password.
For demo purposes, I have written this script directly into the browser and tested with the testing panel, which proves a little slow and clunky at times, but overall an okay way to test.
When creating Azure Automation scripts that are to include parameters to be provided from other applications, I find it best to start by adding in these parameters as the first things to write.
As I am looking to reset a user’s password, I want to pass the user’s email, so I will be setting up a string variable named $UserEmail – pay particular attention to this parameter name as it will be required in Flow to pass the parameter to Azure Automation.
Param ( [Parameter (Mandatory= $false) [String] $UserEmail = "", )
Once you have added your parameter it’s time to add the authentication details to connect to your Office 365 tenancy. In this example I’m doing this in two small lines of code.
$creds = Get-AutomationPSCredential -Name 'MyDemoTenant’
Note: the name ‘MyDemoTenant’ is the friendly name created when you first added your Office 365 credentials above; this adds the credentials to a secure variable that we can use to connect to Office 365.
Connect-MsolService -Credential $creds
If you happen to jump ahead and are testing as you go, you will most likely find that you cannot access and pass the parameters through Microsoft Flow to Azure as intended. I find that the parameters are not available either for consumption in Azure Automation or transmitting to Microsoft Flow until both the Azure runbook and a version of the Flow is published. This could be a bug and something soon to be ironed out, but it did require me to publish both before I could work with the parameters.
TIP: You may need to publish your runbook and Flow to access the parameters.
Now that the script is written and ready to go, let’s head over to Flow and provision a new personal Flow.
Login to Flow from: https://flow.microsoft.com/
Click Create new Flow > Create from Blank.
Now that a new Flow has been provisioned we can begin to configure our Flow.
As I am intending to reset a user’s password, I have selected ‘Flow button for mobile’ which will be used to pass on the user email address on the user account’s password to be reset.
Select the trigger ‘Flow button for mobile – Manually trigger a flow’
Once you’ve added the manual trigger action you will need to give the input a name and description; in this example I will be using UserEmail as the input name.
Now that the trigger is added, it’s time to add an action. In this example i’ll be using the Azure Automation (Create Job) action which allows me to fill out start my ‘ResetUserPassword’ runbook created earlier and pass on the UserEmail parameter
So, we now have all the components we need to start wiring everything up!
As the Azure Automation action is added, you will need to logon with an account to your Azure tenancy. This can be the Azure tenancy connected with your Office 365 account or separate, it’s entirely up to you.
Fill out the details for the Subscription, Resource Group, Automation Account & Runbook Name.
The bit we are paying attention to is the Runbook Parameter that is now available to us: ‘UserEmail’. This becomes available once we have selected the RunBook name and it has recognised that the Runbook is requiring a parameter.
Select inside of the parameter input field and you will see that a whole range of options become available on the right hand side of the page. Select as the input name the name you created as part of the ‘Flow button for mobile – Manually trigger a flow’ trigger that you created.
IMPORTANT – I’m not sure if this is a bug while the Azure Automation action is in preview, but to get this working I did need to publish the Azure Automation PowerShell script first so that the parameter was available for consumption.
So now we have the parameter (user email address) executing and passing to our runbook, it’s time to finish off the script by adding in the Office 365 PowerShell goodness.
Param ( [Parameter (Mandatory= $false)] [String] $UserEmail = "" ) Write-Output "connecting to the demo tenant" $creds = Get-AutomationPSCredential -Name 'MyDemoTenant' Connect-MsolService -Credential $creds #Resets the user password to Password1 temporarily, but is forced to reset the password on next logon Set-MsolUserPassword -UserPrincipalName $UserEmail -NewPassword "Password1" -ForceChangePassword $true
So, now that both our flow & azure runbook’s are published it’s time to give it a go. I’ve installed the Flow app on my mobile, and as you can see there’s an awesome interface to start a new manually executed flow.
How easy is that!!!! If you have any questions please leave a comment.
Until next time.
See another one of our recent posts about – Azure Automation – What it is? Why should I use it?