If I had to pick a favorite part of that article, it would be the bit that points out that sites that avoid PowerShell Remoting over security concerns will joyfully leave open a number of other attack vectors that are far easier to exploit.
If you need to convince someone else, here’s all of the resources that you’ll ever need. From what I’ve read of the experiences of others, I am apparently in a minority. I’m fortunate enough to work with a security department that is both practical and well-studied, so I’ve never had to make the case for PowerShell Remoting.
Uses a single well-known port (5985 for standard PSRemoting, 5986 for SSL PSRemoting).Source and remote machines validate each other as well as the initiating user.
There are several positives about PowerShell Remoting: There is quite a lot going on behind the scenes that we never see or need to be involved with. What I like best about this ability is that using PowerShell to control remote machines is so simple that most people don’t even realize that the technology is involved enough to have its own name: PowerShell Remoting. It is truly masterful at controlling multiple systems from a single console. PowerShell works just as well against a remote system as it does locally. Most of us started out using PowerShell on our local systems. So, while I can certainly agree that there is great value in a well-designed GUI and will continue to fight alongside everyone else attempting to push Microsoft toward doing the right thing, PowerShell is where serious administrators go to do serious work. With a well-designed command-line interface, you can routinely push a product to do things that even its engineers didn’t even conceive. No matter how powerful a GUI is, it locks you into the mindset of the person(s) that developed it. The more that I use PowerShell with Hyper-V, the better I feel about Microsoft’s virtualization stack overall. Whereas Hyper-V is embarrassingly lacking in GUI management options, it is the undisputed king in command-line control. What we do have available to us is PowerShell. Most egregiously, I cannot use any one of these tools by itself even for a typical day of Hyper-V Management. Azure Stack will require specialty hardware with more horsepower necessary to run itself than half of the world’s businesses need to run their entire operation, and it’s not yet released for production use anyway.
The Windows Azure Pack is too complicated for most regular administrators to have time to learn how to use, with a feature breadth to match. System Center Virtual Machine Manager’s sole redeeming quality is that it is not named “Microsoft Bob” - a fact which does not help VMM users in any way, but for which Microsoft Bob will be eternally grateful. Failover Cluster Manager can fill in many of the gaps missing from Hyper-V Manager, but its focus is failover clusters, not Hyper-V, and it is also locked to its Windows version. Hyper-V Manager is capable, but lacking in scope for anything more than a handful of hosts, and it’s version is locked to its Windows version. When it comes to GUI tools, our options are all just barely on the high side of awful. The most common complaints that I see regarding Hyper-V are somehow related to management.