"Also just a ton of missing UI / tooling / integration work meant that most people heard about it, tried it, didn't see what the hype was about"
I think this depends on what component/system your trying to use. Recently I found myself using powershell (mostly via copy/paste) for what I consider simple one time system administration type duties. In the past I don't think microsoft would have shipped a product without a first class GUI to manage it (ignoring registry editing for "rare" tweaks). Now, it seems the prevalence of powershell allows some groups inside Microsoft to write a bunch of code without a functional UI, leaving the users to grub through what is effectively programming documentation to perform simple things like enabling/disabling a core feature of the product. I would expect from an architectural level, that microsoft would assure that the major functionality in their product is controllable both from the GUI as well as from the command line. That doesn't appear to be the case anymore than windows 8 can be used entirely from the metro/modern interface.
Frankly, its yet another erosion of what I considered to be Microsoft's strong points against Linux.
It's somewhat ironic in that one of the Microsoft's aims has been to solve the problem of having some features that were only GUI-accessible, meaning they were difficult/impossible to automate.
So PSh gets treated as the first-class interface with the GUI being a frontend to underlying PSh functionality. I've gotten away from Windows sysadmin work, but from what you're describing it sounds like they've swung the pendulum a bit too far in the other direction and no some of the GUI stuff isn't easily accessible.
Having both would obviously be ideal, but if you were to put a gun to my head and make me choose, I'd take the current situation of a lacking GUI every time, personally. All the times I'd run into situations where the answer was essentially "nope, can't automate that" in the past were beyond infuriating.
"All the times I'd run into situations where the answer was essentially "nope, can't automate that" in the past were beyond infuriating."
BTW: In the past (because I don't do a lot of this anymore either), GUI operations were automatable with one of the dozens of clones of the windows macro recorder. The ones I remember using had their own little scripting languages (which could be automatically generated/recorded) with simple variable substitution and control flows. The resulting scripts were callable from the command line/batch files. Those products overwhelmingly relied on the ability to walk the GUI resource trees and find things by id/name/some attribute and then send messages like clicking or typing to them. How well applications like this still work in a metro/modern environment I don't know. Although a google search indicates a number that are still available.
I think this depends on what component/system your trying to use. Recently I found myself using powershell (mostly via copy/paste) for what I consider simple one time system administration type duties. In the past I don't think microsoft would have shipped a product without a first class GUI to manage it (ignoring registry editing for "rare" tweaks). Now, it seems the prevalence of powershell allows some groups inside Microsoft to write a bunch of code without a functional UI, leaving the users to grub through what is effectively programming documentation to perform simple things like enabling/disabling a core feature of the product. I would expect from an architectural level, that microsoft would assure that the major functionality in their product is controllable both from the GUI as well as from the command line. That doesn't appear to be the case anymore than windows 8 can be used entirely from the metro/modern interface.
Frankly, its yet another erosion of what I considered to be Microsoft's strong points against Linux.