Powershell - Super commands [Invoke-WebRequest]

If you've been playing around with Powershell modules, you've undoubtedly run into the problem of keeping your modules, deployed all over the place on multiple servers, up to date with the latest version.  Powershell scripts and modules don't normally fall under traditional application life-cycle management (ALM) processes, so unless you/your organization apply targeted and specific effort toward managing these objects via ALM, you know what a pain mismatched versions can be.  We can save the debate over ALM for another day, but the simple fact is, that keeping scripts and modules updated can become tedious.
In my world, I've addressed this problem through the use of an updater module and the very powerful cmdlet called "Invoke-WebRequest".

Invoke-WebRequest is documented here:
https://msdn.microsoft.com/en-us/powershell/reference/4.0/microsoft.powershell.utility/invoke-webrequest

I built a command line app to generate my Powershell script body with all the components I normally use.  Part of these components is the loading of the updater module.  Once the script has checked that it's running with admin rights and the updater module is loaded, the method in the updater module is called to ensure that the main module is up to date with the latest version.  The updater module simply makes a call to Invoke-WebRequest like this:

C:\> Invoke-WebRequest -Uri http://www.sharepointmvp.net/ulsviewer.zip -OutFile C:\data\UlsViewer.zip

The above example simply pulls a zipped copy of ULSViewer down from the internet, so you can test it for yourself.  In my case it looks something like this:

C:\> Invoke-WebRequest -Uri http://master-server/Utils.psm1 -OutFile C:\Program Files\WindowsPowerShell\Modules\Utils.psm1

This will update the module which is then loaded into the script to provide all the latest features of the script.  Now it's important to understand the potential security risk of doing this.  The master-server location of the module has to be well protected and tightly controlled.  Failure to do so, could result in someone planting some malicious script code into your module and then distributing it to all your servers.  Remember that convenience and security are polar opposites.  When you increase one, you necessarily decrease the other.

Nevertheless, through this implementation, I am able to manage a central source module for my helper methods that is then re-used in all my scripts.  Fixing a bug once, fixes it everywhere.  Conversely, breaking a method in the module once, also breaks it everywhere. :-P

I'm sure you can come up with many more useful ways of using Invoke-WebRequest.  Let me know in comments about some of your favorite ways to leverage this powerful cmdlet.

Later
C