Just to continue the interesting conversation a bit (and thank you for engaging), I've underlined a bit in your quote above.

On the not steering people towards DOS and Batch Files thing, I do understand that although I'd likely make the suggestion when it's actually appropriate (oddly enough, though, I do find it to be appropriate more often than not but that's me).  The key here is that you DO know that bit of "old stuff" and have a basis to measure something new against.  A lot of people aren't even aware that things like DOS and WMI exist never mind the power that's built into them.  Heh... I tried to explain to someone how to step through some files to do something fairly easy and I told them about "the FORFILES command in DOS".  Their question was "Ok... that's cool.  What's DOS"? <headdesk>

On the learning PowerShell thing, I have mixed feelings about it.  One of the reasons why I like SQL Server so much is that I don't have to write loops.  They're auto-magically built into things like the SELECT statement and I refer to those loops behind the scenes as "Pseudo-Cursor".  With PowerShell, I've found that it's mostly procedural and does require a fair bit of looping.  Even certain DOS commands, like FORFILES, have Pseudo-Cursors in them so I don't have to write explicit loops.  Yeah, I know... I'm lazy but in a good kind of way. 😉

I also find that a lot of people that are apparently more comfortable with procedural languages using PowerShell to do things in SQL Server that can be a whole lot easier to do within SQL Server if you just know how.  That's one of the primary points that I've been trying to make about using other things instead of using the thing that's old and has always been there.

On that note, there's been some incredible work done in PowerShell and you wouldn't expect otherwise from such a powerful tool.  For example, there's a code set for PowerShell called "DBATools" and, from what I've seen, it does have some awesome tools built in.  The trouble is, it's like an application... it's not currently (if I understand correctly) something that's built in and maintained by monthly updates to the operating system.  That means that it's yet another thing that you have to check for updates, isn't available on every machine, etc, etc.  There's also a fair bit of it that can actually be done in T-SQL itself and so I do.  I suppose that a part of the reason why I don't use it is that we're fairly well consolidated to keep license costs down and so I don't have to maintain hundreds of SQL Servers.  Someone that does would probably find more utility in the DBATools than I.  Still, it would be interesting to find out what happens when someone well versed in those tools are isn't allowed to use them (on certain government controlled secure systems, for example, although not a usual case).

Speaking of tools... OMG!  The things people buy simply because they don't know what's available naturally.  Backup software is one of those things that irks the hell out of me.  People will buy uber-flexible software (initial cost and yearly maintenance fees can cost a small fortune if you have a lot of servers) and then use it generically because they don't have anything special going on in their databases.  They don't realize how simple it is to write something to handle their generic needs because they don't actually know anything about T-SQL backups never mind what type of backups to make or when or anything on the subject of RPO or RTO.  They also never test their backups as a restore because they end up assuming that the 3rd party software somehow makes everything bullet-proof.

Then there's monster software like Web Methods.  One company that I've worked for bought it because the Enterprise Architect insisted that he didn't want to do ETL in SQL Server.  In case you don't know what Web Methods is, it's like SSIS on steroids.  So is the price and the learning curve.  The company spend $250K on the initial purchase, found out it actually didn't do everything they wanted, spent another $100K to buy an add-on, and what did they end up with?  A difficult to use, initial high cost with yearly maintenance fees, scheduler that calls T-SQL Stored Procedures to do <insert drum roll here> Bulk Inserts.  <headdesk> <headdesk> <headdesk> <major face-palm>.

Heh... a lot of people think I'm a Luddite.  I'm not.  I just can't see spending a whole lot of money either purchasing software or learning to build software using the latest cool-kid software when everything you need is already available, is frequently easier to use, and is just as frequently better to use.  People say "Well Jeff, just because you can do something in SQL Server doesn't mean you should".  Thinking to myself "Why the hell not?", my normal retort is "Well dude, just because you can do something in SQL Server, doesn't mean you SHOULDN'T.  Save yourself a shedload of money, lost time on learning curves, avoid the proverbial "Tower of Babel", and learn the tools you have".

Of course, almost everyone then walks away from the conversation shaking their head thinking "Jeff's a bloody Luddite" even after a demonstration of what can be done so easily and quickly because I know the tools that are already there.