Yeah, it's a widely accepted de facto method for interacting with the GUI. While in Server 2012, it feels like all GUI elements are just wrappers for Powershell cmdlets, most 3rd party tools have only a graphical interface.
Server 2003 doesn't support Powershell 4 or newer, nor .NET 4.5.1 or newer, and so IIS6 and other old Windows features have limited CLI interfaces.
Most Powershell cmdlets work on Server 2008/R2, but remote (WinRM) isn't enabled. There's a quick command to enable, but that's a security hole like leaving WMI open to the internet, and so is hard to push on secure environments.
RDP gives KVM, and that's been enough for decades.
Maybe for tasks in s small show or on a specific server, but you'll find that most enterprises have automated tools for provisioning, deployment, patching, etc.
I would phrase that more like: Most enterprises believe they have automated tools etc. Sure, the desktops are controlled centrally, but most corporations i have been working with in the last 15 years have had very limited tools to deploy servers.
Most of the time, i have seen these projects get implemented, but then die out when they start to consider all the old in-house apps. In the last one i was at, they implemented the tools, but ended up using it only for basic system setup and patching. Any application was installed by hand and managed by hand.
Server 2003 doesn't support Powershell 4 or newer, nor .NET 4.5.1 or newer, and so IIS6 and other old Windows features have limited CLI interfaces.
Most Powershell cmdlets work on Server 2008/R2, but remote (WinRM) isn't enabled. There's a quick command to enable, but that's a security hole like leaving WMI open to the internet, and so is hard to push on secure environments.
RDP gives KVM, and that's been enough for decades.