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.
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).
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:
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?
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.
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.
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.
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.
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.
Try adjusting your search terms or browse all content.