SharePoint, Office 365, Azure, and Other Musings…
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 