PowerShell articles, tutorials, and guides from community experts.
I’ve decided to bring #PSBlogWeek back! Brush off those PowerShell blogs and grease up those typing fingers….wait..don’t do that but at least stretch a little bit. If you’d like to write a great article on PowerShell on your blog to help contribute great content and get yourself some notoriety, #PSBlogWeek is how it’s done.
For full details, head over to my blog where I’ve outlined everything or head directly over to psblogweek.com for full details!
It’s been a long road, but we’re almost there! A couple of weeks ago we looked at how we can create an Azure Automation Account and add our own custom modules to the solution to be used in Azure Automation. Last week, we took a deeper dive into configuring a runbook to take in webhook data from an alert using Microsoft’s Operations Management Suite. Then we looked into the data itself to see how we can leverage it against our runbook to fix problems for us on the fly.
This week, we’re going to modify an existing function to use that webhook data directly.
Building on Webhook Data
We could actually build our logic directly into the runbook to parse the webhook data and then pass the formatted information to our function that we’ve made available in Azure. But I prefer to keep my runbooks as simple as possible and do the heavy lifting in my function. This makes the runbook look a little bit cleaner, and allows me to minimize my code management a little more. Also, Azure Automation Runbooks, as of this writing, don’t play nicely with parameter sets in them, so I might as well pass my data along to a command that does.
Originally, I had built a one-liner that allowed me to create an NSG rule on the fly to block and incoming traffic from a specific IPAddress. It was a fairly simple command. But today, we’re going to make it a little more robust, and give it the ability to use webhook data. Here’s my original code:
There’s been a lot of discussion on the Summit Slack channel around people proposing sessions for the 2018 Summit. I thought an explanation of how we put the agenda together would be useful for anyone thinking about submitting sessions.
First off though – if you’re thinking about submitting a session for the 2018 Summit then JUST DO IT! We are reserving a number of sessions for new speakers, as we always do. One of our goals for the Summit is to nurture the next generation of speakers. What better way to learn to speak about PowerShell than in front of the world’s greatest PowerShell audience. There is a balancing act between nurturing new speakers and having “big name” established speakers that we know will help draw an audience to the Summit.
So last time we learned how to upload our custom modules into Azure Automation so we can start using them in Azure Automation Runbooks. This week we’re going to take a look at configuring a runbook to see what kind of data we can ingest from OMS Webhook data, and how we can leverage that data to pass into our functions.
Creating the Runbook Script
So first off, let’s talk about basic runbooks and running them against objects in Azure. As previously discussed, when your automation account is created, it creates with it an AzureRunAsAccount. This account is configured to act on behalf of the user that has access to the automation account and the runbooks in order to perform the runbook task. In order to leverage this account, you need to invoke it in the runbook itself. You can actually find an example of this snippet in the AzureAutomationTutorialScript runbook in your automation account.
The PowerShell and DevOps Global Summit 2018 will be returning to the Meydenbauer center, Bellevue WA on 9-12 April 2018. PowerShell, and DevOps, experts from all over the world, including PowerShell team members, will once again join together to discuss and learn about maximizing PowerShell in the workplace in fast-paced, knowledge packed presentations. The Summit’s also the place to explore and further your knowledge of DevOps principles and practices in a Windows environment, make new connections, learn new techniques, and offer something to your peers and colleagues. If you want to share your PowerShell or DevOps expertise, then this is your official call to submit presentations for selection!
Automation and scripting has become a major part of IT in recent years. And PowerShell has played a giant role in the progression of that. Every year, the wonderful people at PowerShell.org put on the PowerShell + DevOps Global Summit, that always produces outstanding results from amazing speakers and attendees.
As many of you in IT know, convincing your manager to attend conferences usually depends on a few key factors: Cost and budget, content, and sometimes, experience or seniority in the company. And unfortunately, that last one may be a deciding factor far too often. This year, PowerShell.org is making it a priority to help extend, not only the content and knowledge that comes with attending the PowerShell + DevOps Global Summit, but also the experience that comes along with it.
Microsoft’s Operations Management Suite provides some exceptional tools for monitoring and maintaining your environments in both the cloud and in your datacenter. One of it’s best features, however, is its ability to leverage the tools that you’ve already developed to perform tasks and remediate issues using PowerShell, Azure Automation Runbooks, and OMS Alert triggers. In this series, we’ll be discussing how you can configure these tools to take care of problems in your own environment. Today, we’ll be talking about how you can take your own PowerShell Modules and upload them to Azure Automation.
Creating The Azure Automation Account
In order to create the Azure Automation Account, you’ll need to have create the automation account object in the target resource group, and the ability to create an AzureRunAs account in AzureAD. It’s also important to be mindful that not every Azure region has the Microsoft.Automation resource provider registered to it, so you’ll want the resource group to exist in the appropriate locale. You can check this with the Get-AzureRmResourceProvider cmdlet:
The planning for Summit 2018 has started – to be honest it started before Summit 2017 opened. We’ve reached the stage where we need to start thinking about the broad topics for PowerShell Summit 2018.
What do you want to hear about? Not the session titles, content and speakers but the broad areas of content you want us to include. We can’t actually promise to cover everything requested because we’re dependent on whats submitted when we open our call for topics towards the end of the month.
Looking at the agenda for Summit 2017 we had these very broad groups
PowerShell tool making
DSC and DSC resources
PowerShell Github repository
PowerShell v6
Remoting
Testing - Pester
Azure
PowerShell Functions
JEA
PowerShell v6
PowerShell on Linux
PowerShell modules
Regular Expessions
MSDeploy
PKI
Powershell Jobs, Workflows and runspaces
Nano server
PowerShell cmdlets - compiled and script
Are there any we should drop? Is there a topic we should include – this far out we can commission a specific expert speaker to cover a topic if required. This is your opportunity to help shape Summit 2018. Let us know what you think
I recently decided to ‘up my game’ with powershell and go beyond the simple scripts I’ve rolled out in the past.
So I simply want to share with you, the path I took to enhance my skills (inc. alot of practice)
Books:
Learn Powershell In A Month of Lunches
Learn Powershell Toolmaking in a month of Lunches
Windows Powershell In Action 3rd Edition
Online:
Advanced Tools And Scripting with Powershell 3.0 Jump Start
Writing Powershell Powershell DSC Resources And Configuration
Demo Code
PowerShell.org is an activity of The DevOps Collective, Inc., a US 501(c)(3) nonprofit public charity. We have no legal owners; by definition, we are owned by the US public. As a charity, it is a violation of US law for any individual or entity to gain a financial benefit (e.g., a profit) from the organization. Thus, we do not have shareholders or other owners.
We have two broad goals within the PowerShell and DevOps community:
Try adjusting your search terms or browse all content.
