Pipelining is an important concept in PowerShell. Though the idea did not originate with PowerShell (you can find it used decades earlier in Unix, for example), PowerShell does provide the unique advantage of being able to pipeline not just text, but first-class .NET objects.
Pipelining has several advantages:
It helps to conserve memory resources. Say you want to modify text in a huge file. Without a pipeline you might read the huge file into memory, modify the appropriate lines, and write the file back out to disk.
Sometimes, as a developer, you want to be be able to keep track of free space on a drive, the size of a log, the load on your CPU, the number of users logged in, etc. With PowerShell, it is typically just a matter of finding the right cmdlet amidst the large (and rapidly growing) pool of cmdlets provided by Microsoft and by third parties. Then you just run Get-Foo to check details about the foo resource.
At the beginning of July, we welcomed our 3rd son into the world. As days past my wife and I would say, “wow, he’s 11 days old. Can you believe it?!”. I’m sure parents out there are relating to this!
This gave me an idea for a fun script that would get your age in years, months and days, tell you how many days until your birthday and your star sign.
PowerShell 5 brought class based DSC Resources, which majorly simplifies the process of writing custom DSC resources.
During my time working on some custom resources, I developed some tips a long the way which should save you some time and pain during your DSC journey.
The tips cover:
Structuring your class based DSC Resources Making it easier to get IntelliSense based on your DSC resources without constantly copying them into the module path Using PowerShell ISE IntelliSense when writing DSC configuration Troubleshooting resources which aren’t being exposed correctly from your DSC Module Testing classed based resources with Pester Head over to https://hodgkins.
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).
Having an understanding of your systems performance is a crucial part of running IT infrastructure.
If a user comes to us and says “why is my application running slowly?”, where do we start? Is it their machine? Is it the database server? Is it the file server?
The first thing we usually do is open up perfmon.exe and take a look at some performance counters. You then see the CPU on the database server is 100% and think _ “was the CPU always at 100% or did this issue just start today?
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:
After authoring last month scripting games puzzle, which involved some scripting around the Unicode standard, I decided to have some fun and write a PowerShell module which interacts directly with the online Unicode Database (UCD) to retrieve the main properties of characters.
Using this module you will be able to retrieve the following information for a single char or for every char in a given string:
Glyph name General category Unicode script Unicode block Unicode version (or age) Decimal value Hex value
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.