Having a platform that enables ChatOps can be a game changer. You can quickly see changes, alerts, build status, discussions, emergency chats, and more, all in a single, searchable interface. If you can sift through the gifs. Bots are a hot topic these days, and and it’s well worth checking out Matt Hodgkins bit on integrating PowerShell with Hubot. Bots are a great alternative to trying to spin up a web front end for PowerShell. On top of bots, systems like Slack often offer a wealth of integrations, allowing you to hook into systems like Nagios, PagerDuty, GitHub, Trello, and many others. Occasionally, you might have something that doesn’t integrate natively. Maybe you want to integrate Slack messages into your SCOM command notification channel, your CI/CD build process, orchestration system, configuration management systems, or even ad hoc scripts. If you’re using Slack, check out the Slack API methods, or an incoming webhook. With the API in particular, you can do some handy stuff! If you like the idea of re-usable tools and abstraction, check out PSSlack, a PowerShell module that we’re starting to build out, which can simplify sending messages, searching messages, and more.
By the time you are using PowerShell to automate an increasing amount of your system administration, database maintenance, or application-lifecycle work, you will likely come to the realization that PowerShell is indeed a first-class programming language and, as such, you need to treat it as such. That is, you need to do development in PowerShell just as you would with other languages, and in particular to increase robustness and decrease maintenance cost with unit tests and–dare I say–test-driven development (TDD). I put together several articles on getting started with unit tests and TDD in PowerShell using Pester, the leading test framework for PowerShell. This series introduces you to Pester and provides what I like to call “tips from the trenches” on using it most effectively, along with a gentle prodding towards a TDD style. Part 1: Getting Started with the Pester Framework Starting with the ubiquitous “Hello, World”, this introduces Pester, showing how to execute tests, how to start writing tests, and the anatomy of a test. Part 2: Mock Objects and Parameterized Test Cases To be able to create true unit tests, you need to be able to isolate your functions and modules to be able to focus on the component under test; mocks provide great support for doing that. Another topic of “power” unit tests is making them parameterizable, i.e. being able to run several scenarios through a single test simply by providing different inputs. Part 3: Validating Data and Call History The final part of this series provides a “how-to” for several other key parts of Pester: how to validate data, how to determine if something was called appropriately, and how to address a particular challenge with Pester, validating arrays. I’ve included a library for array validation to supplement Pester. For a more general treatment of unit tests, I refer you to Roy Osherove’s canonical text on the subject, The Art of Unit Testing.
Long has it been known how to easily document your PowerShell source code simply by embedding properly formatted documentation comments right along side your code, making maintenance relatively painless…
But if you advanced to writing your PowerShell cmdlets in C#, you have largely been on your own, either hand-crafting MAML files or using targeted MAML editors far removed from your source code. But not anymore. With the advent of Chris Lambrou’s open-source XmlDoc2CmdletDoc, the world has been righted upon its axis once more: it allows instrumenting your C# source with doc-comments just like any other C# source: All of the above provides fuel for Get-Help, i.e. providing help one cmdlet at a time. But we are a civilized people; we also need a web-based version of our full custom PowerShell API. That is, a hierarchical and indexed set of Get-Help pages for all the cmdlets in our module. For this task, my own open-source effort, DocTreeGenerator, nicely fills the gap, requiring very little beyond the doc-comments described above to do the complete job. I have written extensively on using both XmlDoc2CmdletDoc and DocTreeGenerator, and just this week, released a one-page wallchart that shows how all the pieces work together: Here’s the link to get you started on this fun journey: Unified Approach to Generating Documentation for PowerShell Cmdlets
Trying to get your code to look good when reading it later can be tricky For line breaks in function scripts, there are two out-of-the-box options: First, you can break a line after the pipe key, which is an elegant and easy-to-read approach. Second, you can arbitrarily break a line with a back tick mark, which you will find left of the number 1 on a standard US keyboard. **It looks like this: ** But did you know that the back tick is a hack? The back tick means, “literally interpret the next character,” or also said, escape the following character.” For example, you might want to literally reference a quotation mark “ in a path name, but because it’s inside “” for strings, you need to literally interpret it: “”PATH”” – it’s hard to see, but squint. But here’s another takeaway: if you use the back tick to create a line break, make sure there’s no space after it; otherwise, the space – not the carriage return – will be the escaped, literal character! So here’s are some examples of what works and what doesn’t: First, no line breaks - works like a charm, but if we add a few more pipes and parameters this could get ugly.
Here is the long awaited post of my third installment of where I revisit my script and provide some explanation as to why I did the things I did in regards to synchronizing Active directory groups. As always feedback is welcome. Link is here
In this post I elaborate the steps that I went through to build the function to extract users into alphabetical order. I talk about the problems I face and how I resolved them. I also post snippets of my code that I used so that new people can see how I wrote it. I’m hoping that this help the new people that are out there. Biggest tip in the post is what the secret sauce is on how to pass results from one cmdlet to another. As always always pleased to know people’s thoughts. Link here.
I thought I would post my learning experiences as a person that has very little programming background. Don did say in one of the TechEd’s a few years ago that even a beginner could share their experiences with others. So I thought that I should contribute with the approach that I use to write my scripts so that other people starting to begin their Powershell adventure could benefit. The scenario in this case is to do with three Active Directory security groups and synchronizing with a master Active Directory security group. Link to blog post here.
Are you intimidated by scripting? Does PowerShell seem too much like programming to you? You aren’t a developer, why should you learn this mumbo jumbo? It turns out, PowerShell is quite easy to get started with. Can you run ipconfig? Do you know how to give someone instructions? You could probably pick up the PowerShell basics in a month of lunches or so. Don’t believe me? I spent a few minutes to compare a simple task in four languages. PowerShell is a single, easy to understand command. Python is two lines and starts to include some syntax like .(). We won’t even look at the C example here, but check out this C# code that simply reads and prints out the content of a file:
There is a lot of documentation out there for interacting with Microsoft Office including Outlook, Excel, Word, etc with Visual Basic for Applications (VBA). A lot of time you may only be able to find VBA examples. VBA’s require template files to be sent to the desktop and are a real hassle when trying to automate across multiple machines. There are not many A to B examples of translating VBA to PowerShell so I took a problem I had solved in the past and presented the before and after. Hopefully it will provide enough information to allow others to convert VBA code into PowerShell for their scenarios. You can check out the full article on PowerShellBlogger.com.
If you are not on Office 365 or have a tenant set up with Microsoft yet, now is the time to reserve your tenant name! With utilizing Office 365, a lot of administration is only available from a PowerShell session. There is a mix of outdated information on what you actually need to install and execute in order to connect to all of the Office 365 services. As a result, I accumulated and wrote up the current download requirements and commands to connect and administer every Office 365 service from one PowerShell session. I hope this saves everyone a lot of time and effort! Head over to PowerShellBlogger.com to read the full article here.
