One of the attractive features in PowerShell v5 is PowerShellGet. This module includes commands which makes it easy to discover and install PowerShell modules from the Internet, or even your network. The modules are stored in online repositories. Microsoft maintains one called PSGallery. Typically you will use PowerShell commands to find and install modules. As a quick side note, while Microsoft appears to do some degree of review using the PowerShell Script Analyzer, there is no guarantee that modules you find online will work in your environment. That’s why the repository is untrusted by default. You can still download and install but you are accepting the potential risks. But that’s not the point here. It is pretty easy to download new modules, which includes DSC resources. However, new versions can be published to the online repository. As far as I know there is no notification mechanism. So you might have to periodically check to see if there are new versions available. Which means I wrote a tool.
I’m always on the lookout for new ways to do things. Often I’m trying to find a way to create something that is easy to use without requiring a lot of PowerShell scripting. I also like using the final result as teaching aids so even if you don’t need the end product, I hope you’ll pick up a trick or two that you can use in your own scripting projects. The task I had in mind today is a better way to get event log information. Not the events themselves, but rather the event log file. How many entries are in it? How big is it? How much of the configured log is being used? Here’s what I came up with.
If you do any amount of PowerShell scripting you have most likely heard about Visual Studio Code. This is a free cross-platform light-weight editor from Microsoft. VS Code supports multiple languages and is extensible. I’ve tried different versions since it was first released but never found a reason to jump from the PowerShell ISE. For my purposes the ISE works just fine plus I’ve customized it so much that it would be hard to abandon. But there is a new version of VS Code that is at least making it more tempting.
Recently I shared a replacement function I wrote for Test-WSMan. That version addressed some of the shortcomings in the original command, at least for me. After using it for a bit I realized I wanted a few additional changes so I now have version 2. The new version now supports multiple computer names. I also replaced the ProductVersion property with separate properties for the OS, Service Pack and Stack numbers. Continue reading More Improvements to my Test-WSMan Replacement
I saw a question on Facebook about how to get Test-WsMan to return a simple Boolean result. The Test-Connection cmdlet has a -Quiet parameter that makes this possible. But Test-Wsman does not. Certainly, you could script a comparable outcome. Here’s one way: Continue reading Friday Fun: A Better Test-WsMan