Years later, and after having been indoctrinated into the Microsoft Stack, I have hardly written any scripts or have had any need to, but that is changing.
My current place has a few bits of software that use Powershell and, some, lots of it. Its the tool/language of choice for the ALM framework developed in house, used to push software out from local environments to production environments (in some cases). The framework consists of 100s of scripts and XML configuration files, to map to the myriad of upstream test/integration environments and settings required therein, and it is plugged into TFS to allow CI and gated/manual deployments (no CD here yet!)
The ALM framework is in the process of being wound down and eventually something like Octopus deploy is going to be used in its place, with the ability to provide extensibility - ironically - using Powershell.
There are lots of arguments against the bespoke framework including things like why a company whose competitive advantage is not ALM software didn't use an off-the-shelf product, for one.
Apparently there weren't many (ALM frameworks/tools) about when a consolidated and consistent release framework to production was originally sought. There are aspects of it I like, but as it stands it is far too fragile and "indie" to be a serious candidate for continued use, but that's mostly a moot point.
Regardless, it has given me the chance to use Powershell and can be used really productively for the jobs you hate.
Turning on our distributed computer
As part of a re-platforming exercise, we are currently undertaking, of a large e-commerce application, often referred to as the old legacy ball of mud. We are ripping it to shreds (into a new world glass of sand?) and refactoring large parts of it into a distributed messaging based system.
NServiceBus is the technology of choice to provide pub/sub choreography and all of the benefits that come with it (resiliency, durability, scaling, error retries and SLAs to name but a few) , With this however, comes a new set of problems over an in-process monolith, not least administering the many smaller parts deployed out to n-number of bits of tin. Which is where this rambling is going toward making my point (sorry!)
Due to licensing issues, and with a consideration for allowing easy scale out, there is a need to host and administer lots of windows services (hosting NServiceBus endpoints) on lots of different servers. The ALM framework does this most of the time, but not always, leaving little choice of going through the rigmarole of waiting another 15 minutes to push out deployment, or turning on the bits needed out on the boxes.
NServiceBus provides "endpoints" which are effectively message handlers listening out for specific messages from other endpoints they have subscribed to or are being routed messages from (i.e. events and commands). Once they receive a message they will do something as a result, like persist some data or start off a process.
Considering that a typical arrangement of NServiceBus endpoints involves something called a distributor (dishing out work) on 1 box and 2+ workers (actually performing the work) on other boxes, its easy to see that if there are 40odd services in total, then in total there are potentially 120 services (housing the endpoints) which are going to have to be administered. As you can imagine, administering start/stop gets very tedious, very quickly in the services manager and this is where Powershell comes into its own.
The simple script above starts all the services on 3 the boxes named in the $computers array, which have the "OrganisationRootNamespace" in the name. This saves about 15 minutes of clicking and lots of sanity.
The stock library of Powershell has lots of commands providing easy programmatic access to common OS tasks such as registry editing and copying files. Before settling in for a big point and click-a-thon consider using scripting, for the jobs you hate.
Another thing to consider Powershell for is if you are automating deployment of software components, there are often requisite tasks that are needed, adding users to user accounts, copying files and perhaps pulling code from source control for example.
Powershell comes in handy again here. If you want to do more with Powershell you can load in managed .NET DLLs and have access to powerful APIs for things like TFS and Active Directory.
It can be argued that this can all be done in any .NET language, but
scripting is appealing for getting stuff up quickly, easier adoption/learning curve for noobs, and no need to use a *clunky* IDE.