Server manager runs powershell under the hood?

This topic contains 3 replies, has 3 voices, and was last updated by Profile photo of Garegin Asatryan Garegin Asatryan 2 years, 6 months ago.

  • Author
    Posts
  • #15721
    Profile photo of Garegin Asatryan
    Garegin Asatryan
    Participant

    Hello

    I have seen the claim that administrative GUI wizards in Server 2012 are really running powershell commands under the hood. I am dubious to this claim. because as everyone knows, a well designed application should call upon an API, not use the CLI as an API. Is is really running posh commands in the background or simply display those commands for the user's convenience.
    to quote wikipedia.

    With PowerShell, graphical interface-based management applications on Windows are layered on top of Windows PowerShell.

    To show you more what I'm talking about
    http://www.tmrepository.com/trademarks/cliisapi/

  • #15722
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    AD Administrative Center is a GUI wrapper around PowerShell commands. I don't think Server Manager falls into that category, but Exchange tools might.

  • #15724
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Server Manager (as of Win2012 at least) indeed uses PowerShell under the hood for many, if not all, operations. If you run Get-PSSessionConfiguration on a Win2012 server, you'll even see the Server Manager workflow endpoint that Server Manager uses.

    But you misunderstand what that means. PowerShell isn't a CLI, actually. "Commands" are well-formed .NET classes, and you set properties (parameters) and call methods to make them do things. What you see as a CLI is actually a layer between you and the real PowerShell engine – a way for you to execute those class' methods without writing an entire program to do so.

    When a program like Server Manager, Exchange Management Console, ADAC, and so on "host" PowerShell, they're instantiating the PowerShell engine – which is a large .NET class. They feed it "commands" and it runs them – but it's just running .NET class methods. So it really IS using an API; it's just an API that can also be exposed via a CLI that a human can use.

    What makes PowerShell unique is that very construction. Tools like Server Manager aren't just running external command line utilities like "ping." You're right – that would be inefficient, because those commands output text, and text is a poor API. But that isn't what PowerShell is, and that isn't what it does. PowerShell isn't a fancy new Cmd.exe, nor is it a "Windows version of Bash" or some other shell. It's a unique system that exposes modules of code through a consistent, normalized API, **AND** exposes them through a human-friendly CLI.

    When you run PowerShell.exe, that's not actually PowerShell. That's the console host – an application that accepts your commands, parses them, and translates them into that underlying API. It deals with displaying the results in text, rather than making a tree view, icons, or some other display – which is what some other hosting applications, like the Exchange Management Console, do.

    Be dubious no more.

  • #15827
    Profile photo of Garegin Asatryan
    Garegin Asatryan
    Participant

    thanks for the mega thorough answer. another question. as everyone knowns powershell is notable for piping objects instead of text. If you are familiar with the Unix Hater's Handbook, the lack of this functionality is outlined in the chapter 8 (csh, pipes, and find). Are there any examples of shells with this capability outside of powershell.
    Here is a quote from that chapter

    Indeed, while pipes are useful at times, their system of communication between programs—text traveling through standard input and standard output—limits their usefulness. First, the information flow is only one way. Processes can't use shell pipelines to communicate bidirectionally. Second, pipes don't allow any form of abstraction. The receiving and sending processes must use a stream of bytes. Any object more complex than a byte cannot be sent until the object is first transmuted into a string of bytes that the receiving end knows how to reassemble. This means that you can't send an object and the code for the class definition necessary to implement the object. You can't send pointers into another process's address space. You can't send file handles or tcp connections or permissions to access particular files or resources.
    At the risk of sounding like a hopeless dream keeper of the intergalactic space, we submit that the correct model is procedure call (either local or remote) in a language that allows first-class structures (which C gained during its adolescence) and functional composition.

You must be logged in to reply to this topic.