SharePoint, Office 365, Azure, and Other Musings…
March 15, 2019 Leave a comment
As promised, here are my slides from the North American Collaboration Summit 2019 presentation from yesterday, “Using Azure Runbooks to Automate SharePoint Tasks”
October 4, 2018 Leave a comment
I am pleased to announce I will be speaking at SharePoint Saturday San Juan on November 3rd.
Register today at http://www.spsevents.org/city/sanjuan/sanjuan2018
The Microsoft Office 365 and Cloud community invites you to the second 365 & SharePoint office on Saturday to be held in San Juan.
It is a totally free event in which you will find technical and development sessions focused on Microsoft Collaboration tools such as SharePoint, Office 365, Integration with Azure, Power Apps, Flow, Project, Planner, OneDrive, Delve, SharePoint Framework, Power BI, Dynamics CRM, Blockchain among others. We will have the company of MVPs and specialized technical leaders in each of the different types of talks.
I will be presenting Using Azure Runbooks and Microsoft Flow to Automate SharePoint Tasks
Runbooks are a feature of Azure Automation that allow you to execute workflows from within Azure or remotely to automate processes. Microsoft Flow allows you to attach to certain activities in SharePoint and across other platforms, to perform a task when a certain condition is met. In this session, you will learn how to link SharePoint Online, Microsoft Flow, and Azure Runbooks in order to execute scripts automatically against your SharePoint tenant, or really, perform or automate any task.
Hope to see you there!
October 4, 2018 Leave a comment
I am pleased to announce I will be speaking at SharePoint Saturday New England. Taking place on Saturday, October 20th, at the Microsoft office in Burlington, MA.
Register today at https://spsnewengland.org/
Carrying on the great tradition of SharePoint Saturday started by Michael Lotter, Susan Lennon, and Kevin Israel on January 10th, 2009 in Virginia Beach, we hope to welcome you to SharePoint Saturday New England.
Join New England area SharePoint architects, developers, and information workers for SharePoint Saturday: an educational, informative and lively day filled with sessions from other SharePoint professionals, MVPs, and Microsoft employees. SharePoint Saturday is FREE, open to the public and is your chance to immerse yourself in SharePoint right here in New England!
I will be presenting Using Azure Runbooks and Microsoft Flow to Automate SharePoint Tasks
Runbooks are a feature of Azure Automation that allow you to execute workflows from within Azure or remotely to automate processes. Microsoft Flow allows you to attach to certain activities in SharePoint and across other platforms, to perform a task when a certain condition is met. In this session, you will learn how to link SharePoint Online, Microsoft Flow, and Azure Runbooks in order to execute scripts automatically against your SharePoint tenant, or really, perform or automate any task.
Hope to see you there!
March 2, 2018 2 Comments
If you’re calling an Azure runbook, it is sometimes useful to be able to get the Job ID, say, to report back and update the source that initiated the call to a runbook. This is a quick post on how to access that ID in PowerShell.
You can access it via the following:
$PSPrivateMetadata.JobId.Guid
And the output:
February 26, 2018 2 Comments
I have only probably a small number of PowerShell scripts that I have written that do not need to import some library/module (I refer to them as both libraries and modules in this, as they are libraries of cmdlets). More often than not, I am working with SharePoint or Azure, and need to utilize cmdlets from one of those libraries to do what I need to do. So, what if you need to use PowerShell modules in your Azure Automation runbooks?
In this post, I am going to show you how to import and use PowerShell libraries in your Azure Automation Accounts.
First, we’re going to need to create an Azure Automation Account, if you don’t already have one…
In the Azure Portal click on New, and then search for Automation, and click on it in the drop-down.
It should select the Automation Account
So scroll down to the bottom and click on Create
Give it a Name, select the Subscription, give it either a new Resource Group or use an existing… and a Location (what Azure region is this going to run in?) and I do not need a Run As account for this, so I am going to select No… and then, I click on Create at the bottom.
If you don’t have Automation Accounts in the list of blades (the main left hand side menu in the Azure Portal), you can click on All Services at the top, find it under Monitoring and Management, and click on the star next to it 
You should now see it in the list of Favorites
Click on the blade, and you should see your new Automation Account
Click on LibraryImportTest, the Automation Account we just created.
Now that we have our Automation Account, lets take a look at the modules. Scroll down under the Automation Account, and look under Shared Resources
You’ll see Modules and Modules gallery. Click on Modules.
You can see that there are quite a bit in there already:
You can also see the version number, so you know what version, say, of the Azure library you are using. You can also Update Azure Modules (if you have a Run As account enabled, which we didn’t do for this test).
You can also click on a module, such as Azure, and you can see that there are 673 cmdlets, or Activities in this module. By clicking on See more at the bottom of the Activities window, you can see the full list of cmdlets.
So, by default, we get the following modules provided by Azure:
Which makes sense… because we’re using PowerShell in Azure. Now, what if we need something more? Click on Browse Gallery. There are MANY modules available in the gallery, so you may not need to import them yourself.
For example, the SharePoint Patterns and Practices library is one I have used in several blog posts recently about Azure Runbooks… search for SharePointPnP
You can see all 3 (Online, 2013, and 2016) libraries are available! Click on one of them…
To import the module into your Automation Account, click on Import at the top
And then click OK. When completed, you will see a notification that it was imported successfully 
That doesn’t mean its there yet… it is still importing. It will bounce you into the module import screen
And once its complete, it will give the overview as well as the list of cmdlets (Activities)
Easy right? This is the same as the PowerShell Gallery.
You can also notice, when you’re in the PowerShell Gallery, you can also deploy to Azure Automation
When using this method, you can either import it into an existing Automation Account, or, create a new one:
Now… what if the module you have is NOT a part of the PowerShell Gallery?
Now lets say, there are come cmdlets I need that are not in the gallery, such as Gary LaPointe’s PowerShell-SPOCmdlets.
A search does not return anything…but I happen to have the module installed locally. So, I first zipped up the folder (the default location for this particular library is C:\Program Files (x86)\Falchion Consulting, LLC\SharePoint Online PowerShell)
Back in Azure, under Modules, click on Add a module
Select the file from your computer, and click on OK
And click on it in the Modules list, it will likely still say Importing…
Now we wait for the import to complete… this takes a few minutes…
And once complete… you can see that you now have the module and all associated cmdlets for use in your Automation runbooks:
“Do I still need to import my modules in my Azure Automation PowerShell scripts?” No. If you have a module loaded for that specific Automation Account, it will be automatically available, so there is no need to specifically import the module in the script itself.
February 23, 2018 Leave a comment
I have been playing around with Azure Automation Runbooks as of late. For one I was working on, I am using a SharePoint list to kick off a flow, and that flow reaches out to my Azure Runbook via a Webhook, which in turns runs some PowerShell using the SharePoint PnP Library to create some list entries, as well as a site or two, depending on the request.
Since I have just been testing this functionality out, I’ve had my credentials under which the script runs and connects to SharePoint under a few variables.
$username = "geoff@domain.com"
$password = "!!!MySuperSecurePassword!!!~)()_($!@)(&$_)*($&@)*"
And then converting those to PowerShell credentials
[SecureString]$securePass = ConvertTo-SecureString $password -AsPlainText -Force
[System.Management.Automation.PSCredential]$psCredentials = New-Object System.Management.Automation.PSCredential($username, $securePass)
And then connecting to SharePoint
Connect-PnPOnline -Url $url -Credentials $psCredentials -ErrorAction Stop
Now that I have my testing near completed, I no longer wanted to store my username and password for my service account in the script itself as variables. In fact, I want to be able to use multiple credential sets if needed, depending on the tasks that need to be completed. In comes Azure Automation Credentials.
I’ll skip the step of creating an Azure Automation account, I covered that in my last post related to this. Since the
If you go into the Azure Portal, and go into your Azure Automation account, you will see under Shared Resources, a section called Credentials
Click on Add a credential
Enter in a Name, Description, and then the User name and Password for the credentials you wish to use.
And then click on Create
Now that we’ve created our credentials… we can use them! In this example, I am just using a test script to ensure it works…Let’s go over to our runbook.
You can see here in my example script, that instead of the code I used above, I am using:
Get-AutomationPSCredential -Name "MyAccount"
Where MyAccount is the name of the credential we just configured. Let’s now go test it out… go over to the Test Pane and click on Start
I am showing some output just to confirm that the script is indeed running, and it is getting PS Credentials, etc.
And did we get context?
Indeed we did! It works! I surprise myself sometimes… so there you go, this is how you can use Azure Automation Accounts and Automation Credentials to store and retrieve username and password pairs and use them in your Automation Runbooks.
Geoff Varosky's Blog 