Stack Exchange

Windows Core Needs to be the Future

Kyle Brandt

It is pretty hard to get a bunch of system administrators together for any period of time and not have a conversation about command line for managing things. In my experience, command line always wins the debate for any medium to large installation. Microsoft caught on to this and has introduced powershell. From my own experience and people I have talked to, powershell adoption has been slow. Like powershell or dislike it, it is an interesting take on command line with its object oriented versus text-based approach. It is also quite powerful, so why the slow adoption?

In my mind it isn’t a problem with powershell itself, but rather a result of human nature, culture, and the Windows ecosystem. The problem lies in workflow, and I think the best way to illustrate this is to contrast Windows versus Linux administration. When managing Linux systems, scripting something flows naturally from the experience of trying things out in the first place. For example, lets say someone with some Linux experience (but not an expert) is building a piece of software and installing it on Linux for the very first time. The steps usually involve something like:

  1. Run the traditional, configure, make, make install from the command line. See what libraries or binaries are missing that are required to build, from the errors. Install them (often via yum or apt), keep doing this until it works.
  2. Possibly add some users to the system, adjust permissions etc with commands like useradd, chown, chmod.
  3. Edit some text files
  4. Set it to start at boot with commands like chkconfig or update-rc.d

As you do this more and more, you learn the patterns of what fails, and get the urge to automate it. Although things like puppet are the end goal these days, the next normal step is to write shell scripts to do this. This is the lynchpin of the whole experience, a shell script is just a little flow control, error handling, and a few variables on top of what you were already doing. With the Linux experience, scripting flows naturally as a next step in your experience. It is a gradual learning experience, and your previous experience of doing things manually taught you much of what you need to know to script it — what goes wrong, what to check, how to do everything you need to do. Even the first time tutorials on the web are almost always command line. From the second you start learning how to administrate a Linux box, you are learning how to script.

Unless you are extremely disciplined or have been taught Windows administration recently by a “benevolent” dictator, your first steps in Windows administration are via the GUI and Wizards. Don’t get me wrong, for many things this gets the job done faster and with far more ease. The generally accepted problem with the GUI though is that it doesn’t scale. When you want to scale in management you often turn to scripts (GPOs are very useful, but you are generally out of luck if what you want isn’t predefined.) With Windows, scripting these tasks is generally a complete departure from your previous experience. Scripting doesn’t flow naturally from previous experience, and scripting something is scary because of this. This means the windows ecosystem, due to human nature, is far less likely to produce administrators with scripting experience. Therefore, powershell adoption is logically slower. This also means administrators are less likely to be testing powershell and pressuring each other and Microsoft to improve it.

The cure to this workflow to me seems to be Windows Core since changing human nature isn’t easy. With Windows core, even though you can use the Management Console, you really have to start doing many things via the command line and powershell. With use of these tools, just as with the shell in Linux, scripting will flow naturally. The Catch-22 however though is that since adoption is slow, everything you need might not be available via command line options. At my company we haven’t used Windows core, but I’m hoping with Server 2012 it is time for Core, does anyone with more experience know if it is time for this shift?

Posted by Kyle Brandt (@kylembrandt) on August 28th, 2012
Filed under Editorial
«
»

  • I also complain that PowerShell is not a “shell” in a traditional sense. It is not a means of fully interacting with the OS. There is no ecosystem of text editors, mail clients, and other tools that are needed in the daily operation and administration of servers and even clients.

    I recently asked a rather high-ranking person within the PowerShell community about this. The response was that PowerShell is not really a shell environment, but rather an “automation engine.” In other words, not meant to truly replace the GUI for heavy Windows interaction.

    Perhaps that’s enough to cause Windows to scale as easily as its shelled counterparts. Perhaps. I don’t think it’s enough to change the culture much though.

    • Wesley,

      If I run powershell from console.exe (i.e the terminal window as opposed to PowerGUI, ISE, etc). I run vim from it. Sometimes I launch powershell from an alternate terminal like conemu (http://www.hanselman.com/blog/ConEmuTheWindowsTerminalConsolePromptWeveBeenWaitingFor.aspx http://code.google.com/p/conemu-maximus5/). When I need to manage files I usually use a nightly build of farmanager 3 as opposed to explorer.exe. I’ve also done a lot of this remotely with WinSSHD. I could run mutt/pine/elm if I wanted to. For package management I use chocolatey.

      The ecosystem is there, its been there for cmd.exe. The thing is powershell is more like running python or perl in an interactive mode as opposed to bash/zsh/ksh/etc. Its just that cmd.exe sucks, leading to interactive use of powershell being more popular.

      Honestly, the culture will change, its just not going to be exactly like unix. It is changing. More developers are scripting their build tasks and digging into msbuild. Some are discovering powershell. Its the developers that move into devops and then eventually to traditional ops that will change the culture, not the sysadmins.

      • furicle

         I too run powershell in a terminal window and use vim for text editing. But there’s a million tiny annoyances like tab completion and history files that drive (some of us) unix guys nuts, and since powershell is an add on feature rather than the default things are often harder in powershell than they are in the GUI.  To me the biggest issue is 99% of the time in *nix the config file is plain text and human readable, and companies expect admins to do just that. That’s almost the reverse of Win based stuff.  Powershell has 20 years of catch up to do, and a pretty large base of users who aren’t very enthusiastic about doing it.   I’m not sure if it’s ever going to get all the way there.

      • Michael Graziano

        The key here is getting Microsoft to realize that their customers (sysadmins) WANT a true, functional shell.  

        Once they get that through their heads I expect either the evolution of PowerShell into an integrated management environment more suited for “command-line” use, or the death of cmd.exe and its replacement with something more UNIX-y

        • I don’t see a point in killing cmd.exe. It would be like killing /bin/sh. Powershell is actually installed by default on all editions except for core server (but I’m ok with that, because its a meant to be super locked down by default).

          The thing is not every sysadmin wants a true fully functional shell. Those that do already have it. Just like those that want a package management system have chocolatey.

          There is very little I can’t do with PowerShell at the moment. Remoting has some limitations, but I can get around them with psexec/xcmd or WinSSHD. MSFT needs to ship their own SSHD that has built in AD, but I wouldn’t be surprised if that happens within 5 years and gives the changes back to Theo (if Theo plays nice).

          Honestly, being I can call a COM object, a .NET assembly, or inline .NET code, which can pinvoke the win32 API, there  is nothing I can’t do with a suffucuently ugly and long powershell one liner. There is not a “one true CPAN-esque repository,” so finding the module someone already wrote is sometimes difficult, but doable.

          Is PowerShell perfect? no. Does it improve upon unix shells and perl in some ways? Yes. Do I want a damn ssh daemon? Hell yes!

  • In Linux, when I want to install  postgres  on my server it is : sudo apt-get install postgres  and I’m up and running.  Rinse repeat for a whole lot of other things.

    On Windows Core, when I want to install SQL Server … I’ve just signed up for a world of dependency hurt and a ritual that is rather comparable to something found in Black Magic circles.

    • Rob,

      Out of curiosity, what are the dependencies? I wonder if installing express edition via chocolatey would fail.

  • Andomar

    Thanks for the insightful post!

    Another cause for slow uptake is that Windows skills don’t persist. If you learn how to automate Windows 2008, you expect that knowledge to be useless for Windows 2012. So it doesn’t make sense to become an advanced Windows scripter.

    On the unix side, my perl scripts from 1994 still run fine.

    • Guy Meler

      You are totally right! as I talking with linux sysadmins, usually, the single statement thay have about linux – is that this OS is persistent.

    • rahul g

      That is an excellent observation! Now with windows 2016 coming out – expect many similar changes

  • The root of the problem seems to be that Linux started with the command line and added GUIs later, whereas Windows did it the other way around. This means the command line tools lag behind the GUI development and even if they are quite well featured could still be called an “afterthought”. It sounds like Microsoft needs to develop the command line tools in parallel with the GUI advances. 

  • Ryan Ries

    This article and these comments suffer from a lack of the presence of a good Microsoft engineer and/or administrator.  As is common, this discussion so far has been a bunch of Linux admins complaining that Windows isn’t more like Linux, but not offering much substance to the discussion from a pro-Microsoft perspective.

     

    That said, I may be a Microsoft zealot, but I do understand and appreciate Linux. I think it’s a great, fast, modular, infinitely customizable and programmable operating system. So please don’t read this in anger, you Linux admins.

     

    First I want to stay on track and pay respect to the original article, about scripting on Windows. Scripting has been an integral part of enterprise-grade Windows administration ever since Windows entered the enterprise ecosystem. It has evolved and gotten a lot better, especially since Powershell came on the scene, and it will continue to evolve and get better, but we’ve already been scripting and automating Windows in the enterprise space since the ’90s. (Though maybe not as well as we would have liked back then.)

     

    But I will make a concession. There are Windows admins out there that don’t script. A lot of them. And I do view that as a problem. Here’s the thing: I believe that what made Windows so popular in the first place – its accessibility and ease of use because of its GUI – is also what leads to Windows being frequently misused and misconfigured by unskilled Windows administrators. And that, in turn, leads people to blame Windows itself for problems that could have been avoided had you hired a better engineer or admin to do the job in the first place.

     

    GUIs and wizards are nice and have always been a mainstay of Windows, but I won’t hire an engineer or administrator without good scripting abilities. Even on Windows you should not only know how to script, but you should want to script and have the innate desire to automate. If you find yourself sitting there clicking the same button over and over again, it should be natural for you to want to find a way to make that happen automatically so you can go do other more interesting things. Now that I think about it, that’s a positive character trait that applies universally to almost any occupation in the world.

     

    And yeah, it was true for a long time that there were certain things in Windows that could only be accomplished via the GUI.  But that’s changing – and quickly.  For instance, Exchange Server is already fully converted to the point where every action you take in the GUI management console is just executing Powershell commands in the background. There’s even a little button in the management console that will give you a preview of the Powershell commands that will be executed if you hit the ‘OK’ button to commit your changes.  SQL Server 2012 will be the first version of SQL that’ll go onto Server Core.  (About time.) The list goes on, but the point is that Microsoft is definitely moving in the right direction by realizing that the command line is (and always has been) the way to go for creating an automatable server OS. Microsoft is continuing to put tons of effort into that as we speak.

     

    However, just because scripting on Windows is getting better now doesn’t mean we haven’t already been writing batch files and VB scripts for a long time that do pretty impressive things, like migrate 10,000 employee profiles for an AD domain migration.

     

    I really love Server Core, but it’s just a GUI-less configuration of the same Windows we’ve been using all along. Any decent Windows admin has no trouble using Core, because the command line isn’t scary or foreign to them.  For instance, one of the comments on this article reads: 

     

    “The root of the problem seems to be that Linux started with the command line and added GUIs later, whereas Windows did it the other way around.”

    I think that’s false. Windows started as a shell on top on top of DOS – a command line-only operating system. DOS was still the underpinning of Windows for a long time and even after Windows was re-architected and separated from DOS, the Command Prompt and command-line tools were and still are indispensible. Now I will grant you that Linux had way better shells and shell scripting capabilities than Windows did for a long time, and Microsoft did have to play catch-up in that area.  Powershell and Server Core came along later and augmented the capabilities of and possibilities for Windows – but the fact remains we’ve been scripting and automating things using batch files and VB Script for a long time now.

     

    There was also this comment: “Another cause for slow uptake is that Windows skills don’t persist.”

     

    Again I would say false. I can run a script I wrote in 1996 on Server 2012 just fine, with no modification. Have certain tools and functions evolved while others have been deprecated? Of course. Maybe a new version of Exchange came out with new buttons to click?  Of course – that’s the evolution of technology. But your core skillset isn’t rendered irrelevant every time a new version of the software comes out. Not unless your skillset is very small and narrow.

     

    There was also this comment:

     

    “I also complain that PowerShell is not a “shell” in a traditional sense. It is not a means of fully interacting with the OS. There is no ecosystem of text editors, mail clients, and other tools that are needed in the daily operation and administration of servers and even clients.”

     

    As I mentioned earlier, there are fewer and fewer things every day that cannot be done directly from Powershell or even regular command-line executables.  And to the second sentence – I’m not sure if there will ever be a desire to go back to an MS-DOS Edit.exe style text editor or email clients… but I could probably write you a Powershell-based email client in an hour if you really wanted to read your emails with no formatted styles or fonts. J  

    • You say: “This article and these comments suffer from a lack of the presence of a good Microsoft engineer and/or administrator.”

      But I don’t see you actually pointing out anything wrong with the point I am trying to make in my post (and I also consider myself to be a good Windows administrator, not one of the best by any means, but certainly good).

       I don’t think I said, or at least didn’t mean to say, that Windows doesn’t have scripting options. My point is that scripting doesn’t flow naturally from the way admins usually learn how to administrate Windows. 

      • Ryan Ries

        Sorry that I came off brash.  I wasn’t trying to offend you or anyone else.

        What I’m trying to say is that I don’t agree that scripting and the desire to automate does not flow naturally from being a good Windows admin, and the people who have been relying solely on the GUI and don’t do any scripting need to stop it.

        • Okay, I basically agree with you. I think that falls under:

          “Unless you are extremely disciplined or have been taught Windows administration recently by a “benevolent” dictator, your first steps in Windows administration are via the GUI and Wizards.”

          The “recently” there is probably wrong. Great admins will automate even if it is more of a leap — I don’t disagree. But my point is that there usually is a lot more friction from GUI to script vs CLI to script. With Windows Core the discipline I am talking about would be enforced “by default”. You also learn what sort error handling to add from the interactive CLI. Although in theory there shouldn’t be a difference because the GUI doesn’t stop you from scripting, I believe in practice, due to human nature, this self discipline is rare.

          • Ryan Ries

            Agreed.  Bring on the Server Core!

          • SilentLennie

            I’m sorry guys, but I’ve still seen to often that installing non-Microsoft server software needs a GUI. They just won’t let themselves be scripted. And I don’t see that changing soon. Even certain drivers still have this problem.

  • Peter Mounce

    We’ve been using Windows Server Core 2008 for the last year or so in production, but enabling remote-management on the boxes so that they can be administered via the familiar GUIs.  That said, with the migration we’re doing to AWS, this is less of an option (because the servers are more ephemeral and expendable than actual metal) and so we’re writing much of our automation in ruby (since, well, it’s more pleasant, development-pain-wise than working in powershell).

    One thing that I wish MS would do is give up on WinRM and produce a credible ssh story.  ssh client, ssh server, integrated into the OS.  WinRM is workable for remote execution (but more than a bit painful to do any file transfers over), but this starts to break down in the absence of an Active Directory (or at any rate, we haven’t figured out how to make that work) in the picture.  We’re planning on not having an AD once we’ve migrated to AWS, because (and here I’m going second-hand; no direct experience) it would be too difficult to bring up and tear down (we intend to be able to launch our whole production stack from a command – but also give that ability far upstream in our pipeline, to the product development instead of just ops (after all, we’d only launch one, right?)).  I understand that WS-* is the enterprise-y solution to remote management, but…  well, it’s harder than it seems to need to be to actually get things done with.

  • Soonerdew

    Brilliant commentary. Major kudos for drawing such a clear point on the issue. The other side of the Powershell coin is that it assumes the user is comfortable working in its object-centric confines, which implies a developer-like mindset, yet the universes of syadmins and programmers rarely intersects but in the narrowest of ways. 

  • Steven McGrew

    I thought Powershell couldn’t be installed on Windows Core because of the .NET dependency?

  • I’m going to disagree. At the enterprise level, I concur. However, Windows Server is used by a lot of SHO setups. Most of these don’t have time for a full-time system administrator. That’s a large part of the ecosystem that’s completely ignored by this post.

  • kafka

    A related hurdle for PowerShell, I think, is that people who are comfortable with scripting are already using other tools, have been for years, and have little motivation to move to PowerShell. For example, I have been developing on and administering Windows boxes using Unix shells for decades; for the last dozen years Cygwin, others (like MKS) before that. I can see that PowerShell is indeed powerful, but it is not absolutely clear that it is better than bash with the whole Gnu/Linux toolset. Of course PowerShell is infinitely superior to the unusable cmd.exe and MS’s pitiful set of old CLI tools, but that does nothing to wean Windows people from the GUI to PowerShell. Meanwhile, the people like me who use a CLI all the time don’t particularly need PowerShell. And so PowerShell lacks experienced advocates.

  • Radu

    Calculatoare second hand, Laptopuri second hand, Imprimante second hand la preturi bune plus un nou concurs numai pe http://www.diabloscomputer.ro sau https://www.facebook.com/diabloscomputer