Thu 28 Feb 2008
Aaron has a nice post about the command line interface of Server Manager in Windows Server 2008. I have been blogging about the graphical interface of Server Manager a while back. I somehow forgot to mention that Server Manager has a command line version. So I am taking this chance to make up for my omission, although the main intent of this post is to express my view about the value of these new command line capabilities of Vista and Server 2008 in general.
The fact that I forgot to mention it is typical for me because I am not really a friend of the Windows command prompt. On Linux, it is just the opposite. I usually don’t even install KDE or Gnome on a Linux box. But from my point of view, Windows is just not made for this kind of administration. That’s why it is called Windows and not ComanndOS.
However this doesn’t mean that Server Manager’s command line capabilities don’t make sense at all. Actually, they can be very useful under certain circumstances. Usually, they come into play when you have to perform a certain task on many servers. But then you wouldn’t really use these commands on a prompt. Instead you would write a little script that does the job for you.
Usually, when I write such a script, I would try things first on the command prompt in a test environment. This is why such command line extensions of graphical tools can be quite useful. Scripting with Microsoft applications was always possible via APIs. The difference then is that you usually can’t just run a quick test on a command prompt if you write a program this way.
The same applies to PowerShell. The real power of PowerShell is that you can play with the commands while you write a little application. However, when things get a bit more complicated I prefer writing a real program with Visual Studio. So PowerShell like SERVERMANAGERCMD scripts are good for relatively simple automation tasks.
I know, there are many admins who disagree with me here, especially those who grew up in a UNIX environment will feel more at home on the command line. So to a certain degree, it is just a matter of taste if you work on the command prompt or with a GUI. However, I claim that under Windows in most cases you are simply faster with a graphical tool.
Takes one of Aaron’s examples:
SERVERMANAGERCMD -install TS-Terminal-Server,TS-Licensing,TS-Session-Broker -restart
I am not only referring to the fact that commands under Windows and also PowerShell tend to be quite long winded and will just cause finger arthritis in the long run. My point rather is that nobody memorizes such a command for a longer time. If you have to perform the same task after a month or so, you will start wondering if it was “TS-Session-Broker”, or was it just “session broker”? or maybe “TS-Sessionbroker”?
If you are an adventurous admin, you might just try and correct your command afterwards. But usually, you end up checking the manual. Then, you edit your command again, only to find out that Server Manager didn’t really do what you wanted because there was a typo in your command. If you are lucky, Windows would just respond with an error message. If this isn’t just your day, you would have seriously damaged some hundred servers.
One argument often put forward is that you can do more on the command prompt than with a GUI. This might be true in some rare cases, but can hardly be the reason for working always on the command prompt. And in some environments the opposite is true. For instance, you can’t configure server roles with Servermanagercmd.
It is also a big misunderstanding that you have somehow a more technical knowledge of the underlying processes if you work on the command prompt. Whether you understand what you are doing or not doesn’t depend on your typing skills, but on the time you invested to learn about the technical structure of your environment. Pasting a command from a manual and changing some of its parameters doesn’t really require geek knowledge.
That said, I certainly welcome the new command prompt capabilities of Vista and Server 2008. They are very useful in automating tasks in cases where the corresponding graphical tool doesn’t offer (yet) this functionality.
But, then, we usually talk about scripting and not about working on the command prompt. If you need a script for a certain task, it usually means that the developers of an application still have work to do to extend the graphical capabilities of their program. Scripting is nothing else than doing the job for your software vendor. Good graphical tools already come with all the automation you need. After all, every kind of program is only about automation. That’s why computers are so useful.
Thus, if someone from Microsoft tells you that PowerShell really rocks because you can automate all kinds of tasks with it, you can just respond that this is the very idea of any programming language. So I hope that in the future, Microsoft will add a feature to Server Manager that allows you to install server roles on multiple servers with just a mouse click.
The achievement of Windows and other graphic-oriented operating systems is that they made working with computers more human. Graphical interfaces mean more work for computers, but less for humans. Going back to the good old times of MS DOS is certainly not an option.
How about you? Are you working often now on the command prompt because of these new command tools? Or are you just using them to write scripts and continue your daily work like before with graphical tools?
Newsletter: 
Loading ...
(fanboy warning–i’m slightly biased)
Good article overall but I have to take exception with two points.
Above you talk about how you can do things faster in bash than in any CLI Windows because the commands are too verbose, or opaque or not robust enough. And you seem to lump PowerShell in with CMD.EXE and that’s what mystifies me.
PowerShell tackles the verbosity issue very well with aliases and shortened parameters. Aliases are self-explanatory. A shortened param is the shortest unique string of a parameter. e.g. “ls -r” is equal to “Get-ChildItem -recurse”. This works because recurse is the only param to that cmdlet which starts with an R. When you have conflicts, you just type as many letters required to make it unique.
The opacity/usability issue and robustness are handled by posh with the built-in help files, tab-completion on parameters, and detailed error objects, and the “-whatif” parameter supported on many cmdlets.
The second statement I disagree with is how you discount scripting because it is either something the vendor should’ve done or something that can be done with any programming language.
I wonder if you are just trying to pick a fight with that one. If so, it worked.
As a long time system administrator, I can tell you that most of the time, developers have no clue what sysadmins need. If they knew what we wanted, then maybe they would put that stuff in their app–but maybe not, those sorts of things aren’t very sexy and marketing doesn’t care about that stuff. Besides–who knows what sort of weird combinations of stuff you’ll want to do with umpteen different packages from various vendors. There’s no way my needs can be met perfectly, and why should I wait for someone else to fix it if I have the tools to do so myself?
And programming languages, while they handle the same sorts of tasks as scripting languages, there really core design differences. The focus is on totally different job functions. Besides, why would I design, compile, test, fix, compile, test, etc. a program when I can bolt together modular scripts interactively? Besides, scripting languages are a higher level than most programming languages, and that appeals to sysadmins who do not want or need to learn an API.
I do have to agree with you about servercmd…Obviously the timing did not work out such that they could have done all of what was needed consistently with PowerShell or they would have done that. As it stands, the “everything aside from powershell” CLI functions in windows is sub-par. It’s getting better though.
thanks
Hal, co-host, PowerScripting Podcast
It would have been nice to have driven Server Manager via PowerShell, we would have had access to the monitoring features as well, but unfortunately PowerShell was’t an included feature until too far down the track.
In most cases, I find I get things done faster via the command line, but I think the best reason for using command lines tools whereever possible is consistency. GUI tools make it too easy to make mistakes.
Hal, thanks for your comprehensive comment. It is ok to be biased, I am biased, too.
PowerShell is certainly a much better shell than CMD. But like any other command shell, it suffers from the same problems I described in my post.
The aliases are certainly a good way to prevent finger arthritis. But they don’t solve the much bigger problem of memorizing all those commands. Maybe that is not a problem if you are working with a limited number of commands. That is, if you are a specialist for just one field, say IIS administration, then you won’t have this problem. However, software is getting more and more complex. Hence the commands you need get more complex, too. And if you have to consult a manual first, you are already slower than with a GUI.
I agree that one often needs scripts because of the shortcomings of graphical tools. However, I don’t think that software vendors don’t know what kind of task we have to do. Usually, they just include those features the majority needs. So if you have a special problem, you have no other choice but to program your own solution. But it is a matter of fact that management tools are getting more and more sophisticated. The number of software vendors offering tools for administrators has been growing dramatically in the last years. And if there is a tool that solves your problem, it is always cheaper to spend some money on it than having to do it yourself. Any kind of programming is extremely expensive because it is often very time consuming.
Aaron, why do you think that GUI tools are more prone to mistakes?
All in all, I think working on the command prompt, PowerShell or CMD, is a step back. I am looking forward to far more advanced graphical interfaces like Microsoft surface, 3D interfaces or maybe even with VR (virtual reality). Talking to a computer on the command prompt seems to be quite old-fashioned for me.
I went ahead and blogged my rebuttal and provided a link back here for those who want to read your article. http://halr9000.com/article/467
Server 2008 & PowerShell discussion, continued
My long reply to a long reply was getting a bit…long, so I thought I’d move it here. Much easier to do the editing in Live Writer anyhow.
You can find the original article and several comments from myself and the author at this blog pos…
I’m another who takes exception to the base idea that if you need to script a task, the GUI didn’t provide enough options/flexibility.
I beleive that there are a lot of cases where, if you built up a GUI that could do everything a scripting interface allows, you would have something so byzantine and baroque that simple tasks would be difficult to accomplish - especially for those who are less experienced in the sysadmin craft.
I fully agree that you should have a base understanding of how the underlying tech works, and you should be able to visualize what is that you want your script/GUI actions to accomplish (and how the technology building blocks will go about making it happen) *before* you begin typing or mousing your way through telling the system to do the task.
But with a complex scripting language *or* GUI, and a full understanding of what it is you want to accomplish, there will probably still be points where you need to stop and think about syntactical issues, or look up the syntax. With a checkbox in a GUI - does that checkbox add the property, or remove it? Press the HELP button to find out!
I find it is handy to have two CMD/PS windows open - one for the script I am writing or commands I am entering, another for running help commands to see the syntax of the command I am about to enter. If you only have one cmd window, you can type out half a command from memory, then be staring at the blinking cursor, wondering about syntax of the next clause in your statement. This is partly why some people have a perception of the CLI as being less productive than the GUI, where you have more in view - and where help buttons pop new windows.
You tossed off the idea that any programming language can aqccomplish the same sorts of automation that scripting can. Again, I beg to differ. Shell activities, where your script needs to run various programs, parse their output into something another program can use, then perhaps parse the output of that - these are fundamentally different than the sort of programing you’d do in c# or some similar language, where most or all of the time, the universe of interaction is *within* the program doing the work.
Finally, the idea that the GUI is “more human.” Well, doesn’t this depend on the human? Some folks love their GUIs - but others feel more comfortable at a command line. I don’t think that GUI = one size fits all. Same is true for CLI. Having both worlds available makes me more comfortable as an admin, not less. Although at the ned of the day, when I need a succinct and authoritative way of documenting the actions I have performed, I would prefer writing out the CLI commands as opposed to a long document full of ‘click Next. Now click the Advanced button on the window labelled Foo, scroll the list and …’ (you get the point, I hope).
I could go on about this at length, but I’ll end here. Thanks for a thought-provoking article.
Bryan, I didn’t say that you can build a GUI that allows you to do everything you can with a scripting language. What I said is rather trivial. A certain script you wrote just extends the functionality of the operating system or maybe Active Directory or Exchange. This functionality could have been included in the corresponding GUI tools. So scripting is nothing else but programming. You add features.
I don’t understand why you think a C# program shouldn’t be able to take the output of another program as its input, though. We do this all the time.
I think that GUIs are “more human” because they are easier to handle for humans. If you want to talk to a computer using PowerShell, you have to invest a considerable amount of time first. If you want to talk to a computer in binary code, you have to invest even more time, but it costs the computer less time to process it. GUI’s are more advanced user interfaces and that’s why computers need a considerable amount of time to process this kind of input. The next generation of user interfaces will cost even more processing time, but they will also mean less work for humans. That’s what I meant.
Sorry for taking so long to reply. And thanks for the feedback!
I didn’t mean to suggest that a c# program CANNOT take output, parse it, feed it to something else. Obviously it can. The difference is that scripting environments/languages are designed with this as a regular task. So it takes a lot less coding to actually *do* it. Also, you can do it interactively - type out your command, hit enter, watch it run. No compile step.
I’m certainly not saying CLI should replace GUI. Both have their place. But I would be very loathe to administer any OS which provided no CLI at all! No matter how many features it has, there will always be something we need to do today, for which that exact feature has not been implemented yet, and a compiled language with an IDE is overkill.
To respond to your other points would just be a repeat of what I already said, so … nahh.
Bryan, I agree that scripting languages have advantages over compiler-based languages. For smaller projects, I would prefer a scripting language. For large projects I want a sophisticated IDE. I also agree that both, CLI and GUI, have their place. I guess we disagree only with respect to the kind of tasks where a CLI comes into play. My point of view is very simple: Only use a CLI if you can’t perform the task with a GUI.