Otto Helweg has a cool blog entry about how he uses PowerShell to monitor Web Sites HERE. This isn’t a professional product but there are a couple of websites that he cares about and this quick and easy script tells him what he needs to know. It monitors a set of websites, looks for content to validate the page and then logs results and send email alerts when things go pear-shaped.

We have an internal website for PowerShell and it is really embarrassing for the distribution list to be the first time you know about the problem. This is a perfect tool to run to get some situation awareness of critical resources. Give it a try – I think you like it.

Hat’s off to Otto!!

I want to highlight and expand upon the notion that this is not a professional Web Site Monitoring tool. There are lots of great products that you can buy that do much more comprehensive monitoring. If your job was on the line, then you need a heavy duty tool like that.

The thing about most of our jobs is that we usually deal with a wide range of issues/problems. Some of those are super critical and need the big gun solutions – a product, a systems program with specs and functional review and test plans. Others are important – solutions need to be right and they need to be formal. Others are informal – solutions need to work (mostly). A TON of issues are ad hoc – solutions are very short lived. Bruce Payette once said “the lifespan of 99% of scripts begins at the prompt and ends at the carriage return“. The conclusion here is that the nature of the problem determines the nature of the solution.

We designed PowerShell so that it would be the appropriate technology for the widest range of problems possible. This is simple economics. Given that you have a range of problems and thus need a range of solutions, it is a better investment of your time and effort to learn one tool that spans a wide range vs. a set of tools that are focused on one particular range. Anyone with a UNIX background will recognize the problem instantly. You start out thinking that it is a simple problem that you can solve with a KSH Script. It turns out to be a bit more involved so out comes the AWK/SED man pages and you rewrite portions of the script. That works for a while but then you want it to do a bit more so you throw the whole thing away and rewrite it in Perl. Then it catches on and people want to ship it so you throw that away and rewrite it in C/C++.

PowerShell provides and supports strong naming, consistent aliasing, “just-enough” parameter specification, wildcarding, undeclared arguments/variables, etc to allow a very productive ad hoc environment for doing very powerful things very quickly.

PowerShell provides the ability to provide verb-noun names, full parameter names, named arguments, etc to allow quick and informal self-documenting scripts for easy maintenance and sharing with other people.

PowerShell provides typed and constrained arguments and variables, digitally signed scripts, rich error handling, support for –WHATIF and –CONFIRM, easy access to powerful datatypes and APIs (WMI, XML, ADSI, ADO, .NET, etc), etc to allow very formal scripts for environments where it really matters whether it works or not. (We always imagined the Admins who run the Servers at the Federal Reserve Banks. I bet you a dollar that it matters whether those scripts work or not. [BTW – if you are an admin running the servers at a Federal Reserve Bank – I would love to visit you and see what your world is really like]. While we are on this tangent – we think of the Admins at the Fed when we think through how to ensure the PowerShell is Production Quality. We think of Admins running Servers at the CIA when we think through how to ensure that PowerShell is secure [I’d love to visit you folks as well].)

We are pretty happy with the dynamic range of PowerShell V1 (actually I’m amazed by its breadth). That said, this is an attribute that we spend considerable time on and will continue to work at.

Cheers!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx