The Disappearing Windows Server GUI: The PowerShell Takeover

Knowing Windows PowerShell is no longer a bonus for IT professionals who work with Windows Server -- it's a requirement. As Windows PowerShell becomes more prominent, the Windows Server GUI is fading away.

Every time I got busted skipping history class as a kid, I always got the same old lecture about how history is important because it repeats itself. My standard smug response was that I planned on working in technology, and there was absolutely no danger of historic technology making a comeback.

I still think that holds true, for the most part. After all, I'm not about to trade my quad-core PC for a Commodore 64, or give up my Blu-ray player to go back to using VHS tapes. Every once in a while, though, technology can be cyclical.

A perfect example of this is the command prompt. I grew up with DOS in the 1980s. By the time I graduated from high school, I was something of a DOS expert. My first professional writing gig involved writing about Windows 95. Even though Windows 95 was GUI-based, almost all of the DOS commands I knew still worked. As such, many of the articles I wrote back then involved command line-based configuration changes and various scripting techniques.

I had a close friend named Shamir who made fun of me on almost a daily basis. Shamir's beef with my work was that the command prompt was dead, and I should try to make my readers' lives easier by showing them how to do things through the GUI. My argument was that the GUI was lame and far too restrictive. In the end, I think we were both right.

Of course, that was a long time ago. Today it seems as though Microsoft is returning to its roots by placing a much greater emphasis on the command prompt in its server offerings and gradually getting rid of the GUI.

Obviously, saying that Microsoft seems to be "gradually getting rid of the GUI" is a big statement. When I say the GUI is going away, my statement is purely speculative. I talk to people in Redmond on a regular basis, and nobody has said anything about getting rid of the Windows GUI. Also, I'm only predicting the demise of the Windows Server GUI. It would be incredibly foolish for Microsoft to try to do away with the GUI for client versions of Windows, and I don't see any evidence of Microsoft trying to do that.

Enter Windows PowerShell
So, what evidence is there that Microsoft is trying to get rid of the GUI? Let's start out by talking about Windows PowerShell.

You probably know already that Windows PowerShell is a command-prompt environment that's built into Windows. It supports many of the old DOS commands, but is different from the Command Prompt window (which still exists).

Windows PowerShell offers various commands (which Microsoft refers to as cmdlets) that you can use to perform administrative tasks. Windows also gives you the ability to create Windows PowerShell scripts by adding individual cmdlets to text files and saving the files with the PS1 extension.

On the surface, Windows PowerShell seems completely irrelevant to a discussion of the GUI's future. After all, Windows PowerShell is really nothing more than a command-line environment. The Command Prompt window, which is similar to Windows PowerShell in many ways, has existed for many years, and it never signaled the demise of the GUI. So, what's so special about Windows PowerShell?

Windows PowerShell is a lot more flexible and much more powerful than the Command Prompt window. Furthermore, my predictions aren't based on what you can do with Windows PowerShell -- they're based on what Microsoft is doing with it.

Consider Exchange 2007 and Exchange 2010. Both versions contain two primary management tools: the Exchange Management Console and the Exchange Management Shell. The Exchange Management Console is a GUI interface for managing Exchange, while the Exchange Management Shell is a management tool that's based on the command line.

Microsoft built the Exchange Management Shell on top of Windows PowerShell. The folks in Redmond simply extended Windows PowerShell to support a few hundred additional Exchange-specific cmdlets. What's interesting, however, is that the Exchange Management Console is built on top of the Exchange Management Shell. In other words, whenever you perform an administrative action through the GUI, the GUI actually produces a series of Windows PowerShell commands, which it executes behind the scenes. In fact, the Exchange Management Console even goes so far as to show you the Windows PowerShell cmdlets that were used in performing the requested action.

On the surface, it would seem that Microsoft has simply given Exchange administrators two separate but equal management tools. However, this is simply not the case. As any well-seasoned Exchange administrator will tell you, the Exchange Management Console only exposes the most basic management functions. As such, there are many administrative tasks that you can only perform from the command line. Keep in mind that I'm not talking about tasks that are obscure. I'm talking about common management tasks that every Exchange administrator will have to perform sooner or later. One example of such a task is restoring data from a backup.

You simply cannot be an Exchange Server administrator without knowing how to use Windows PowerShell. Of course, this trend isn't just related to Exchange Server. Many of the current Microsoft server products are designed in a way that requires administrators to spend a considerable amount of time getting cozy with Windows PowerShell.

If you want to see more evidence that Microsoft is starting to really push administrators to learn Windows PowerShell, you need look no further than the Microsoft certification exams. All of the exams I've been involved with lately included a significant number of questions pertaining to specific Windows PowerShell commands. You probably wouldn't be able to pass some of these exams without knowing the Windows PowerShell-related material.

Server Core
By far the best evidence that I can cite for the eventual disappearance of the Windows Server GUI is the simple fact that Microsoft has already begun making the GUI an optional component. Windows Server 2008 and Windows Server 2008 R2 can both be installed in the usual way, but Microsoft also allows you to perform a Server Core installation. A Server Core installation is essentially a bare-bones installation without a GUI.

So, how do you use Windows Server without a GUI? You guessed it -- with Windows PowerShell. In all fairness, it's sometimes possible to use another server's management tools to remotely manage a server that's running a Server Core installation while using a GUI environment. Even so, you must perform the server's initial configuration by issuing a long series of Windows PowerShell cmdlets. Incidentally, there's a free third-party tool called Core Configurator that acts as a GUI for the initial configuration of a server core deployment. I reviewed the tool in last month's issue ("Cutting to the Core") and gave it a 10-out-of-10 rating. You can download the tool here.

You may wonder why anyone in their right mind would want to install Windows without the GUI. Although I personally like having a GUI, I've heard plenty of compelling arguments for ditching it. Probably the best reason is that when you get rid of the GUI, you reduce the server's attack surface.

Incentives for Adoption
Maybe it's just a coincidence, but it seems as though Microsoft may also be offering incentives for administrators to move beyond the GUI. For example, take a look at the way that Microsoft licenses Hyper-V.

Microsoft allows you to download Hyper-V Server 2008 R2 for free. However, the free version is a standalone product that doesn't include a GUI. If you want a GUI-based version of Hyper-V, you must invest in a copy of Windows Server 2008 or Windows Server 2008 R2 -- and these are definitely not free.

Why Is the GUI Going Away?
There's a lot of evidence pointing to the eventual demise of the Windows Server GUI. However, I can't just end this article without talking about the reasoning behind the GUI's great disappearing act. Even though I have no inside information from Microsoft on this matter, I can think of a few reasons why the company has started to lean more toward a command-line environment.

One of the reasons has to do with perception. Over the years, I've heard several different people refer to Windows Server as a "toy OS." Why? I think that perception may have started when administrators began to realize that you could play Solitaire on Windows NT Server, while the "more serious" OSes of the day such as Unix and Novell NetWare were primarily command-line based. In any case, this perception is something that Microsoft has never been able to completely shake -- though I doubt that it alone is enough to make Redmond pull the plug on the GUI.

Another, more plausible explanation has to do with the efficiency of managing large organizations. For example, if you needed to make a change to 1,000 user accounts, it's much faster to use Windows PowerShell commands than it is to manually modify each account one at a time through the GUI.

Server virtualization may also be driving the push away from the GUI. In a virtualized environment, the way you get the most bang for your buck is to make efficient use of your hardware resources. The server GUI consumes some resources, and by getting rid of the GUI you can allocate those resources to other tasks.

It's true that the amount of resources consumed by the host OS GUI is usually negligible. But sometimes a server may host more than a dozen guest servers, each of which may have its own GUI. Getting rid of the GUI on the host server -- and on all of the guest servers -- may free up a considerable amount of system resources.

A Gradual Disappearance
For now, Microsoft customers have the option of either installing a GUI-based version of Windows Server, or deploying Windows Server without the GUI. Even so, learning Windows PowerShell is no longer optional. There are simply too many management tasks that can only be performed from the command line. Even if the GUI never completely goes away, I expect the command line -- and Windows PowerShell -- to become increasingly more important to Windows server management.

Bonus Links: Want to get started with PowerShell? Check out our sister site's Professor PowerShell column by Jeffrey Hicks for great, hands-on tips for digging in to PowerShell and Windows administration. Here's just some of the recent ones to get you started:


comments powered by Disqus

Reader Comments:

Mon, May 28, 2012 mike cleveland

"About time. My Linux server at home is installed without GUI. its just easier to set up and maintain that way." I agree with this, but the MS GUI is exactly wat has allowed me to learn and (at least try) to master the linux CLI, because i didn't have to learn another one. I knew whenever I had to log back into an MS machine I could do whatever I needed to do because I had that GUI. Now do i have to spend time learning another CLI after i learned Cisco and Linux?

Wed, Mar 7, 2012

Go Download PowerGUI (Totally Free) from Quest - all the GUI front-end on PowerShell you will ever need (I am the CIO of a major SaaS company and it is the primary tool I supply to all my Admins)...

Sat, Jan 14, 2012 AT San Diego

I appreciate the article. I had heard rumors but hoped they weren't true. We use SBS in our 23 person company. I didn't see SBS specifically mentioned in the article or comments. I hope that SBS will be retaining it's GUI environment. I am hoping that this move to Power Shell is aimed at Enterprise or medium sized companies. I work and am the system administrator and I don't want to take my personal time to learn, in essence a dramatic increase in command line code. I thought it rather inconsistent that the author found a 3rd party company that provides a GUI based installation application for Server. Why would MS retrogade to the point that 3rd parties are providing the service that clients want? Then the other thought for me is do I stay with MS or look at Linux? If I have to ramp way up on the learning curve for Power Shell, why not learn Linux instead? Two friends of mine run Linux, doing everything SBS is doing. They swear by it. Well, maybe I am worried for nothing. I've been happy with our little SBS 2003 box. Maybe the girls and boys in WA will practice the "Keep It Simple Stupid" principle that applies to me; (and I gather from peers of mine) a lot of other small business IT guys as well. When discussing our IT needs and plans the owner (smiling thank God)always tells me to remember we are a construction business, not a computer business.

Thu, Dec 22, 2011 Dan Iowa

Those who think Powershell is not intuitive are missing something. It's actually very intuitive. Sure you will probably not know what every cmdlet does, but you don't need to. That's like saying the GUI is rediculously complex and unintuitive just because you don't know how to use every possible GUI program out there. You only need to know a few things to get started. Verbs are standardized for the most part, so get-verb is a good start. Get-help and help are also good tools to know. get-command is helpful. Get-member is useful for exploring objects that you are working with. Pretty much everything else can be figured out as you need it, by exploring Powershell.

Thu, Dec 22, 2011 Dan Iowa

Powershell is not the death of a GUI. It's the evolution of the shell. The GUI is built on powershell to ensure that everything is scriptable. It's not that the GUI was bad, but that automated management too often meant waiting for some third party to come up with a product that would give you programatic access to certain data or configuration settings perhaps in some COM object. IT admins do not often want to be sitting there doing things in the GUI during the wee hours of the morning. We want to script things to happen, and wake us up only if there is a problem. By exposing things as .Net objects, and in turn through Powershell built on .Net objects, and then where appropriate, in a GUI tool built on Powershell, you ensure that all of this can be well managed.

Wed, Dec 21, 2011 Rick G Montana

Why we are making giant leaps backwards in technology and sophistication is beyond my comprehension. I worked with DOS, OS/2, Novell 2.2 and up - and Linux before the GUI really hit with the Apple and even Windows 286/386. The whole point of the GUI was to make things easier and more intuitive for those not as experienced and familiar. I certainly enjoyed being the expert but that should not hold back the masses from being able to implement their own solutions to real world business problems without an advanced education or twenty plus years of experience with the command line. I think Powershell is great as an optionsal tool, but having it thrust upon me when I am constantly still trying to learn a constantly evolving amss of updated OS'es and apllications, is making me rethink what products I want to use in the future. I can no longer manage Exchange as well as I could when using the earlier versions, and the same goes for SQL, and most every other Microsoft product. To move in reverse is rediculous as it slows down the rate of adoption as well as the usefullness of the product. Somebody at Microsoft needs to wake up.

Wed, May 11, 2011 Steve

The biggest laugh I have is that Microsoft think IT people are clever enough to figure out this massive Masonic handshake known as Powershell and dumb enough to not realize that "the cloud" is simply a result of their running out of things to bloat their software with and sell new versions of it, so they're moving to a subscription-based model so they can still make money. Wrong, on both counts!

Fri, Apr 29, 2011 Adam Edinburgh

Powershell has the look and feel of a modern Unix shell but uses object technology. This makes it more flexible and not format-dependent. that's all there is to it and the PS bashers say more about themselves than anything else.

Fri, Apr 22, 2011 Gatzke MN

I am not a programmer so I cannot comment on whether or not PowerShell is a "ridiculously complex and non-standard programming language" or a "pathetic failure" as others here have called it. I just know I dislike it. It's cryptic and not at all intuitive. I'm not saying it's not useful sometimes. I have created some scripts that have proved very useful. I don’t have a problem with its inclusion in Windows server products but what I really object to is the removal of features from the GUI that can now only be used in PowerShell. One of my jobs is being an Exchange admin and there are so many features that I used to be able to do in the GUI that now have to be scripted. I'm talking about simple things like seeing a list of mailbox sizes on my servers. I used to be able to click on a column header in the GUI and sort by size and just browse to see who had a large mailbox. Now I have to run it in PowerShell and pipe it to a list or a text file. It's not that it's all that hard to do but why isn't that in the GUI? It used to be there so why was it removed? That would be so much easier to do AND to view onscreen in the GUI. It makes no sense to me. It used to be that (nearly) every Exchange command was available in the GUI and most could be scripted for large organizations that needed to run a command on many accounts etc. Now it's been reversed and every command is available in PowerShell and only some in the GUI. Brien mentioned in the article that PowerShell makes it easier to "make a change to 1,000 user accounts" than using the GUI. That's true, but who needs to make changes to 1000 user accounts even occasionally? This is just one more example of Microsoft trying to make their server products fit into the enterprise when many, dare I say the majority, of Windows shops are still small organizations with fewer than 500 users. I have nothing against making Windows server enterprise friendly but don’t downplay the importance of smaller shops and the GUI. If it can be done in PowerShell it should probably be available in the GUI. I'm just sayin'.

Wed, Apr 20, 2011 Alan Douglas Toronto, ON, Canada

"PowerShell is a ridiculously complex and non-standard programming language." AMEN TO THAT!!! With all the technological advances of the last 40 years, it's ridiculous to take a tremendously rich feature set to a command-line environment. (I'm assuming it's feature-rich, because the proponents of PowerShell keep saying so.) If it's such a whiz-bang development, someone out there should be able to design and build a whiz-bang GUI for those of us that have trouble remembering 60-zillion commands and combinations of parameters. Just sayin'.

Wed, Apr 13, 2011 Nissim Salinas USA

Enough already with your unending attempts to convince people that PowerShell is a powerful and useful technology. In reality PowerShell is a pathetic failure, just as Windows Vista was. The longer Microsoft persists with its denial and abdication of reality the more painful and damaging coming to terms with the truth will eventually be. PowerShell is a ridiculously complex and non-standard programming language, the kind that would be developed by a bunch of self-important eggheads who are utterly disconnected from the requirements of high-end users. This seems to be the common thread to Microsoft's current crop of developers: producers of unusable hogwash. Instead of using a well-established, well-known model, such as Basic/PHP (simple), C# or Java-like (structured), or JRuby/Jython (high-power functional languages) the developers of PowerShell "invented" an obtuse, convoluted and excruciatingly non-standard language. I have been programming since 1984 and I still can't make heads or tails of PowerShell. Wake Up! No one other than those promoting PowerShell are using it, because it is an unusable, difficult and pompous failure. The only thing PowerShell is good at is being a borderline vulgar indicator of how far removed Microsoft is from its user base. As a result, nowadays people shrug at the mention of Microsoft. That is because all practical creativity and usable innovation is everywhere else. It's amazing that Unix/Linux have had Bash and C-Shell for so long, whereas Microsoft, after all this hoopla, and after decades and decades of unkept promises, all they can come up with is this turd called PowerShell. This is just more evidence that at Microsoft, as far as technology goes, nobody is at the wheel. What a pity!

Tue, Apr 12, 2011 Roy McCollum NM

Recursive entry ring a bell or history will repeat itself? I remember 30 years ago when everyone begged for a GUI front end and BASIC was so slow and not a valid programing language. So why not the best of both being at hand. I think we have an author that has no real history of computing. my2CentsWorth

Wed, Apr 6, 2011 Dong

Re Thomas, How come XAML has anything to do with Powershell?

Wed, Apr 6, 2011 Dave Perth

This is all about the separation of layers of code (GUI v's app) for testing and admin (automation) and doesn't mean the GUI will disappear. GUI's are problematic for automating testing as well as handling bulk admin functions so Microsoft in it's wisdom has taken this to heart for the benefit of all including to the level of supporting old DOS and linux commands (translated under the covers to standard powershell commands). As explained to me recently by a Microsoft Tech, the gui for the more recent products like SharePoint 2010 simply translates into powershell commands anyway. I think there are some tools around that capture your gui commands and generate the resulting script to be run natively in powershell for automating rollout of Sharepoint, etc.

Tue, Apr 5, 2011

You are missing the big picture. PowerShell was created with the purpose of supporting .NET; therefore, the future is not a non-GUI OS, but a .NET-based OS. There will always be a GUI yet new development techniques dictate the behavior you noticed. Decouple the UI from the process. You are way off base.

Tue, Apr 5, 2011 K.Kong 602

Another drawback of GUI is difficulty in support, especially supporting newbies. Tech: "Click the Start button" Newbie: "Where is the Start button" Tech: "On the bottom left of the screen" Newbie: "I can't find it" It turns out that one of many possibilities: a. The PC has the task bar auto hidden b. The task bar was moved to the right edge from the default bottom edge. After spending some time and having located the Start button, Tech: "Click Start, look for My Computer, right click it and select Properties." Newbie (after a while): "I have looked and looked and gone into every sub menu but I can't find My Computer." It turns out that the Start menu has been customized not to show My Computer. The list goes on and on.

Tue, Apr 5, 2011 Sheldon Gill Australia

Powershell gives you management scriptability as well as flexibility. As you mention, it's easier to select hundreds or thousands of accounts that meet some criteria and apply changes to them using a textual interface. A big part of the change is also, in my view, about delivering reliable product. Server software needs to be robust and reliable. Its easier to write and extensively test lots of cmdlets as opposed to a GUI program. The task of writing cmdlets scales more readily across a large developer team, Automated test tools deal better with them and than GUI interfaces. It can also make the task of developing a GUI easier for your company, in that the GUI team can focus on the user interface issues.

Tue, Apr 5, 2011

About time. My Linux server at home is installed without GUI. its just easier to set up and maintain that way.

Tue, Apr 5, 2011 mtcoder VA

It makes sense, the functionality provided is amazing versus trying to waste time to create a user interface for each function. Powershell even works wonders with desktops. For example: we needed to find a cd that was lost on the work floor. We knew it was in a machine but which one we didn't know. So we took 10 minutes and wrote a script spun up every machine and checked to see if media was in the disk drive and to report back the title of the media into a text file. Poof worked great we got what we want. No way to build a gui for that type of thing.

Tue, Apr 5, 2011 Thomas Visel Austin

MS's reversion to DOS-like script underpinnings should be no surprise. They have done almost exactly the same thing in the transition from VS2003 to VS 2010. The GUI-based Resource Editor with its attendent Properties lists has largely been displaced by XAML, the loose equivalent to PowerSHell. I am doing a lot of detailed hand-coding these days, but it's in XAML rather than using the GUI. Hopefully it's simply a technology transition as MS learns the ropes, not a targeted endpoint!Thomas

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.