Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
GUI Microsoft Windows Technology

Windows Admins Need To Prepare For GUI-Less Server 780

msmoriarty writes "We knew Windows Server 8 was going to be a departure for Microsoft, including an 'optional' GUI, but in a blog post made earlier this week, the Windows Server team said that working without the GUI will be the 'recommended' method, and is telling developers not to assume a GUI will be present. According to Windows consultant and author Don Jones, this is a big hint to Windows admins that they better get used to not having a GUI in future releases. From the article: 'I'm well aware that many Windows admins out there aren't looking forward to a GUI-less server operating system from Microsoft. ... I'm sure Microsoft has, too.They're proceeding anyway. We have two choices: adapt or die.'"
This discussion has been archived. No new comments can be posted.

Windows Admins Need To Prepare For GUI-Less Server

Comments Filter:
  • Core (Score:4, Interesting)

    by Sir_Eptishous ( 873977 ) on Friday January 13, 2012 @11:19AM (#38686006)
    We've been running out DC's as Core for a year now. It was a tricky setup/configure, and management also takes getting used to. However, it's not that bad. Just use your custom mmc for remote management, works great.
  • The Ancient Battle (Score:5, Interesting)

    by Spinlock_1977 ( 777598 ) <Spinlock_1977@yahoPARISo.com minus city> on Friday January 13, 2012 @11:33AM (#38686236) Journal

    GUI vs. Command Line. I lived through that argument in the 80's and 90's. With a GUI, syntax problems go away - IF you can figure out how to find/launch the GUI. On the command line, all commands are available in one spot, but the syntax can be challenging. We really just traded one problem for another.

    But for those of us who run production shops, a GUI isn't scriptable and is therefore not testable. Command line scripts can be tested in an offline environment, emailed around, put under version control, and printed out for enjoyable bathroom reading. Who doesn't love command line scripts???

  • Re:Not a problem (Score:3, Interesting)

    by Abalamahalamatandra ( 639919 ) on Friday January 13, 2012 @11:40AM (#38686358)

    Part of the appeal of a windows server is that the poor dude who is asked to do all the IT stuff, but isn't actually an IT guy has a much lower barrier to entry in understanding 'Windows that happens to be a server' than trying to understand 'LAMP'.

    No, that's part of the problem of a Windows server, in my experience.

    Although I suppose I shouldn't bitch too much, as it's made me quite a bit of money over the years fixing the idiot braindead mistakes these "poor dudes" make.

  • Re:Not a problem (Score:5, Interesting)

    by Hadlock ( 143607 ) on Friday January 13, 2012 @11:48AM (#38686494) Homepage Journal

    Having CLI only potentially means that someone could administer the server from abroad, so long as there is someone in the building who the admin can call to cycle the power and swap the backup tapes every so often. My buddy does this via linux for two 50+ person non profits in Seattle.... from his sailboat in Houston. The only reason he's not doing this for more groups is that the market is fairly saturated with guys like him already... working from the CLI.

  • by Anonymous Coward on Friday January 13, 2012 @11:49AM (#38686508)

    The idea that powershell is superior to a posix shell is laughable. The syntax is inconsistent, arbitrarily long and arcane. It's like perl and python decided to have a baby with old money. It's disgusting.

    Get-Comment-Text | LaughOut-Loud | The-CommentIs-Over

  • by DJRumpy ( 1345787 ) on Friday January 13, 2012 @12:06PM (#38686868)

    You are missing the point. When forced to use your local connection to work, you are limited by the slowest link (your computer). When you VNC into a host server and us the GUI there, you are limited by the servers connections, which typically tend to be in gigabytes, not kbits. It was simply poorly worded, but anyone who's worked remotely via VNC understands the principle. You use the hosting VNC target to do your heavy network lifting and your local laptop/desktop as a dumb terminal to get you into the host server. It doesn't increase your bandwidth per-se but instead increases the bandwidth available to you while removing your slower local link from the equation.

  • by Hatta ( 162192 ) on Friday January 13, 2012 @12:43PM (#38687486) Journal

    Which means I can use one of the internal-only address ranges to layout my home network, be secured behind a firewall, and not have my network layout be made obvious to anyone else. Which is good, because I have two different sub-nets and two different wifi hotspots in my house.

    There's nothing about having a globally unique IP address that implies that your network layout would be obvious to anyone outside your network.

    Since I only get one public IP from my ISP, that covers exactly what I need. I'm sure the greedy bastards would like to charge me for each computer I have, but tough.

    If we had IPv6 we would all have as many ips as we needed free of charge. This is the only problem for which NAT is an appropriate solution.

    Are you implying there's a downside to NAT for a home user?

    Sure, two desktops can't seed torrents (or host any other services) without manual configuration of the router. It wreaks havoc on VOIP for instance.

    And I can't even begin to tell you the number of large corporations I've worked at with computers all addressed within these ranges. Not having them routable to the rest of the planet is actually a useful thing.

    You don't need to have NAT to have those addresses non-routable. You just need your firewall to drop all traffic to those addresses.

  • Re:Not a problem (Score:5, Interesting)

    by darkpixel2k ( 623900 ) on Friday January 13, 2012 @01:03PM (#38687842)

    So the path to making better software is to make it more obfuscated and less user friendly? Making it easier for those poor dudes is what MS has been doing for 20 years, and why they finally made some inroads into the market.

    Or read a different way, the path to having a more powerful, secure, stable, and easy to manage server is to actually have people that know how to admin a server--Windows or Linux.


    I run into 'Windows Admins' all the time who only know a few point-and-click things. The moment stuff breaks they are clueless. Every time I run into a Linux admin, they know their shit *and* they know how to properly admin a Windows server. (Or if they haven't touched Windows in years or decades, they will be frustrated but they can figure out the problem because they grok *how* shit works because Linux doesn't abstract them from it.)

    This is not a bash on truly good Windows admins--there are lots out there, but they cost a lot, just like good Linux admins. Microsoft has simply created a market for low-cost morons who can call themselves 'admins', but they really aren't. I have several friends who are 'web designers' because they bought Microsoft Front Page. There isn't a chance in hell they could design a 'Web 2.0' style site. HTML5 is just a confusing bunch of characters ending with a number to them.

    If Microsoft's change eliminates the short-bus admins, good. I can spend less time going in a fixing their crappy mistakes when companies realize their mistake and scream for help, and I can start working on 'fun' projects to help automate and reduce monotony for other employees.

    20 years old today have no clue how to use a command line unless they are from the 1% of users that have a linux desktop at home.

    And that 1% are probably more qualified to admin a Linux or Windows server than the remaining 99% who only know point-and-click. They probably also know a lot more about 'advanced' things like how TCP/IP works, they understand a lot of the protocols like POP3/SMTP/IMAP, HTTP, or even understand how to debug a program that's crashing, etc...

    These are kids in physics, math, biochem, and they didn't know how to make a directory without a GUI. Admittedly, that's why we're teaching them the CLI stuff. But they won't use it.

    I had an IT colleague a few years back trying to work with a CSV file that had some strange embedded UNICODE characters in it. Excel was having problems reading the data. After several hours of dorking around with Excel, Notepad, and a few other GUI tools the file was handed to me--I used tools that aren't available on Windows (hexdump, sed, csvtool) and stripped the characters out, transformed the file to their requirements, and handed it back to him in about 4 minutes. I spent another 15 minutes automating the process of grabbing this automated CSV dump from a Windows app, doing the stripping and conversion, and then e-mailing the results. He wasted *hours* because he--apparently like your students--didn't think the CLI was valuable and GUI tools would solve his problem.

    This person now has something like 30 minutes free *every day* where he can work on stuff that will earn the company money instead of dorking around with Windows failures.

  • by dave562 ( 969951 ) on Friday January 13, 2012 @02:41PM (#38689406) Journal

    "In Windows Server 8, the recommended application model is to run on Server Core using PowerShell for local management tasks and then deliver a rich GUI administration tool capable of running remotely on a Windows client."

    http://blogs.technet.com/b/server-cloud/archive/2012/01/11/windows-server-8-server-applications-and-the-minimal-server-interface.aspx [technet.com]

    In other words, it sounds a lot like where Novell was in the mid-1990s and where *nix has been forever. The server will no longer be a workstation. The server is the server and the admin tools reside elsewhere.

    I am not happy about this given the cluster fuck that is Server Core and the sub-par command line that they have delivered with it in 2008 R2. As long as they get their act together and provide the full set of MMC tools, it will be fine. Knowing Microsoft the server team will be different from the team developing the management apps. Half of the tools will work from GUI and the other half will require doing it from the console. Of course they won't do something simple like SSH, so we are going to have to have OOB management, or direct physical access.

    In all seriousness though, there are serious flaws to this line of thought. Who the hell wants to work on file system ACLs from the command line? Who wants to setup user accounts and security groups from the command line? There certain basic admin tasks where having a GUI, and features like auto-complete are a godsend. Now granted, for large scale user adds or modifications you should be scripting them. But for one off adds, or looking at the resultant set of policy for complex ACLs with a lot of inheritance, the idea of doing it from the command line just sucks.

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Working...