Slashdot Mirror
Windows Admins Need To Prepare For GUI-Less Server
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.'"
Often Windows servers are also used to run actual programs with GUI's, like you do on your home computer. Having them on server means you have access to much better bandwidth and your programs can run 24/7, and you can easily deploy more servers if you need to. If GUI's are completely removed then you would need to run desktop version of Windows on a server, which is far from ideal. Servers aren't just used for web servers and things like that, they are also used for supporting programs or having a remote location. Windows server with RDP works really well for that. Even Linux servers can have GUI, as it's easy to install X11 and some desktop environment.
So we are going back to command line and dumb terminals... how very retro
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.
We play the game with the bravery of being out of range
Those who do not understand UNIX are doomed to reinvent it, poorly.
Maybe call it Prompts from now on?
How are we supposed to play 3D pinball in the server room now?
try { do() || do_not(); } catch (JediException err) { yoda(err); }
I've been operating "without the GUI" for 2 decades now... never occurred to me that it was a problem...
Microsoft's intention is to just have GUI clients for admin, don't get your hopes up that they would actually raise the bar to have real computer sysadmins who can function from a command line
If you want to talk about server administration, you'd do well to remember that Novell didn't even give you many options on the console on the server. Most of the tools were run on the workstation. The whole point was that there wasn't much reason to ever sit at the server itself.
Do not look into laser with remaining eye.
I, for one, welcome our windowless windows overlords.
Imitation is the most sincere form of flattery. But now, what's the point to windows if there's no GUI?
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
What they actually recommended is running the GUI on the client.
Who wants to run a GUI on a server anyway?
Right, but when a huge chunk of your market is going to be businesses with 15-20 employees and no dedicated IT person, or if they have a dedicated IT person they're not actually a trained IT person, having a CLI only is utterly braindead. 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'.
Now admittedly, MS may be envisioning this is a 'off in the cloud' scenario, where even small businesses buy time on a professionally run server where that barrier to entry is immaterial. But that's a significant misread of a big blob of their market. All the attention this has been getting should have told them that.
I'm a professional CS guy. I'm getting a PhD in comp sci, and I used to be a dedicated IT guy. I consult and teach people how to do this stuff. When I consult, sometimes even at big outfits (think something like CBS or a hospital) their little offices or division that handle something in particular have a guy on staff who is the least technically incompetent person. They might have a degree in history, but be the youngest person on staff, or they're a gamer and know more about computers than say... anyone else. But they look at a CLI (correctly from their perspective) as something that died 20 years ago, and they have no desire to learn. Even kids in IT programmes are generally unprepared for this. And making them uninspired about your product before they've even started working doesn't seem like a great plan.
Windows server is less about technology and more about brand familiarity. Obviously Microsoft is completely unaware of this.
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???
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
Admins should just use the GUI tools remotely. That way they do not need remote desktop and GUI tools installed on the servers. This would provide the best of both worlds and make remote management for servers simpler. Most current admin tools can operate on remote servers. Microsoft could easily ensure all tools can operate remotely to make this transition easier for administrators.
Most competent Windows server admins don't need a GUI on the actual server anyway; between the RSAT (Remote Server Admin Tools) and Powershell, there's very little that you need to be "on the box" to do.
Most good Windows server admins can do almost everything via Powershell anyway - of course it would be much easier if Microsoft would write decent Powershell modules for DNS and DHCP so you didn't have to do everything via COM objects and dnscmd.
I'm pretty comfortable with a CLI, it's what I grew up with and use on a routine basis for many things. That being said there is a lot out there in terms of server based applications that are wholly dependent upon having a GUI.
Were not talking about simply rearranging the desktop here, were talking about removing the very interface that is depended on by an entire ecosystem of software. That market is easily in the billions of dollars per year. If your going to force all those developers and legacy applications to run as CLI only than your giving those companies an opportunity to re-evaluate the platform they use for a CLI based tool.
If your giving companies the impetus to decide what platform to use for a CLI based tool than many of them are simply going to switch to *nix support since there is a strong legacy ecosystem to support it. In other words if Microsoft were to do this for all of the Window Server based platforms it would be suicidal. That's a pretty poor business case and it simply doesn't make sense.
I think the far more likely case is that certain versions of Windows server will be available as CLI only (web platform etc), which they already are. I really have to question if the source of the story got their facts right, it doesn't make sense unless they didn't.
I like the move, but it will be difficult or impossible to run older (poorly written) applications that need a GUI to run.
"A plan fiendishly clever in its intricacies"- Homer Simpson
Finally the manager in our IT dept will have to get a clue.
I'm guessing he will do everything he can to hold off upgrading as he knows he wont be able to cut it.
I'm actually hoping he will get moved out so we can finally move to Linux.
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.
From TFA: "In addition to Server Core (the existing CLI from Server 2008) and Server Graphical Shell (the usual GUI), we are introducing a new experience in Windows Server 8 called the Minimal Server Interface."
Also from TFA: "Technically, the Minimal Server Interface is a full Windows Server install excluding Internet Explorer, Windows shell components such as the desktop, Windows Explorer, Metro-style application support, multimedia support, and the Desktop Experience."
In other words, you'll have a command-line only version, like you do today, a GUI version that behaves like the latest Windows desktop OS, and a GUI version that behaves like a locked down server is expected to behave (the "Minimal Server Interface"). Or at least that's how I read it.
The program can still have a configuration gui. You just need a remote client running on a client operating system or a web interface, which again you can access from a client platform.
Honestly most 'builtin' windows services can be remotely managed from a client platform machine already. This should be the preferred way. Generally if you as a matter of routine need to use a desktop session on your windows servers barring the ones specifically being used as terminal servers, you are doing it wrong.
Mistakes can happen more easily, and you are potentially exposing the system to attacks.
This is really a message to developers to make sure their server applications have remote management support, and that their main server processes can run on box where some the shell libraries, and some subsystems like GDI may not be present or otherwise not in a useable state.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
FTA:
"In Windows Server 8, users can transition between Server Core and Server Graphical Shell at any time, with a single command and a single reboot."
Don't they EVER learn? It took them literally years to be able to do application and driver installs without required endless reboots. Not poor windows admins need to reboot just to start the GUI?? Why on earth can't MS come up with the equivalent of "xinit" to kick off the GUI?? This is 1980s level functionality FFS!
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.
moox. for a new generation.
"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."
Is it? or is that theory just completely made up?
Just because the server doesn't locally have a GUI doesn't mean it wont allow RDP connections, and doesn't mean you wont just be able to use the likes of event viewer, IIS manager, or whatever, installed on your local system, to connect to and manage a remote server.
I don't think most people manage Windows servers locally anyway nowadays, most IT staff are too busy enjoying the fact they no longer have to get off their arse to go to the server room because they can do everything they need with a GUI from their desk. I don't see anything to indicate that side of things is changing - just that Windows Server will no longer by default sit their handling a locked GUI for local users no one ever fucking uses anyway whilst continuing to offer the console based management option that was introduced in what, Windows 2008 Server? even then I suspect, being Microsoft, the Windows GUI will only be a quick click or command away but will simply be initialised on demand, rather than always there.
"Novell, UNIX, VMS, MVS, OS/400,"
Don't forget Cisco.
"They've matured enough to now acknowledge they don't need a GUI"
Arguably they've simply returned back to the level of CLI functionality they had - then threw away - with Xenix. If MS had stuck with that OS and developed it as much as Windows has been developed since its initial incarnation then who knows how much more advanced its offerings would be today.
Some stuff, sure. But, if you maintain clusters of machines or need to do hugely repetitive tasks, a GUI can actually be a hinderance.
I have seen applications in which you might be administering literally hundreds of items, if not thousands ... for some maintenance tasks, you end up manually going through a GUI for hundreds of items one at a time to make a change. Which is boring, repetitive, and error prone. One of the advantage of doing things GUI-less is that it allows for automation of tasks more than a GUI.
Almost anything you need to run at a corporate level where you have a lot of them works way better if you can automate it ... I have seen people trying to make changed to a large number of SAN allocated volumes, and it's painful to watch someone go through the steps with a GUI, and it's a lot more error prone.
If you're talking about a single, stand-alone piece of software that doesn't devolve into having hundreds (if not thousands) of items to control, sure, a GUI is great ... but if you ever have to update hundreds of items at a time, the GUI paradigm can fall apart completely. I once had a task to do in which I had to modify around 75 things ... it took me about 4 hours of "click button, wait, click next button, wait" and made me want to kill the developers who had written it. Partly because there was no multi-select, and partly because if it was scriptable it would become an easy maintenance task -- without it, it's painful. And, it's not like they couldn't anticipate people would need to do this often and to a large number of items.
Even for some routine maintenance I need to do on some machine clusters, it's easier to write a batch script and use "sc" to start and stop services .. because I need to shut down and disable the exact same service on 15-20 machines, I need to do it right now, and I need to get them all down as close as possible. Logging into each machine and shutting these services down with Task Manager ... well, that's pretty much a time sink. Then when I need to start them all up, I've got a corresponding script. These are tasks that we do approaching daily in one or more clusters.
For years Windows has had the "GUI only" paradigm for most applications ... pushing more applications to be scriptable and run headless will go a long way to making many administrative tasks much easier to handle. It may take a bit of a learning curve, but being able to automate certain tasks eventually becomes a huge time save (so it saves money), and is a lot more consistent (which also saves money).
I applaud Microsoft starting to push application developers towards this ... because the sheer amount of items I've seen which can benefit from this has convinced me that we must spend countless man hours of someone clicking through a GUI when a script could do it in a few minutes. That tends to be hugely lost productivity that people could be spending doing other tasks.
Lost at C:>. Found at C.
Microsoft, the company for which the future is what everybody else is doing for more than 30 years.
Not at all. I have been many times accused of being a linux fanboy, but the NT kernel does somethings very well. The tragedy is that it is strapped to the windows userland. DOS on the other hand is a very simple OS with no scheduler, no real HAL, and pretty much is a sad copy of CPM.
This sounds like a solid move to me. I've been wanting for a long time for MS to separate IE from the GUI, and it's about time they did.
I am Bennett Haselton! I am Bennett Haselton!
The simple answer is that just like Unix servers and all other servers except MS you will configure it and monitor it on a workstation with a GUI, but never actually use the server directly ...
The server should not need a GUI, or a monitor, or a keyboard ... it should maybe need a little input when first setup to get it on the network then be totally configured from clients
I always wondered why Server versions of windows had a GUI (and so needed a graphics card...), a lot of Unix servers don't have one?
Puteulanus fenestra mortis
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'.
Exactly... In all likelyhood that person has no business administering a server. That is a large part of why there are so many problems, insecurities, etc... People who THINK they can administer something when in reality they have very little idea what they're doing.
... their little offices or division that handle something in particular have a guy on staff who is the least technically incompetent person. They might have a degree in history, but be the youngest person on staff, or they're a gamer and know more about computers than say... anyone else. But they look at a CLI (correctly from their perspective) as something that died 20 years ago, and they have no desire to learn. Even kids in IT programmes are generally unprepared for this. And making them uninspired about your product before they've even started working doesn't seem like a great plan.
Anything that helps keep "admins" that shouldn't be "admins" from pretending to be "admins" should probably be considered a Good Thing...
You should have used a CLI to automate your paragraphs, which restated the same few (valid) points 6 times. :)
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.
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. We see, in a programme with about 200 students, one or two kids a year like that (and this is in CS). I had to do a class thing yesterday which was basically an 'intro to our unix systems' for non CS kids. Basic stuff, make a directory, list contents that kinda thing. None of them had the slightest clue how to do anything on their own. I was starting from scratch, completely, they didn't even know what to search for on the web, or that such commands still existed. 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. It might take longer, but they've grown up with a GUI, so they'll use a GUI. My suspicion is their immediate impression of linux was 'antiquated'. That's not accurate of course, but that was the perception we created. MS should realize who their market is, and make better software and tools for them.
In general, I like this approach. However, my faith in Microsoft's ability to produce a sane design for CLI management is not high. They have been moving toward this for about 5-6 years now, so it shouldn't surprise anyone. However, working with Powershell is no walk in the park. Sometimes I think they assign commandlet design to different members of the team. Those team members (thousands of them!) work on the commandlets from their own point of view with little oversight into the syntax or object model.
For instance, the object types that you would expect out of one Powershell commandlet (after you figure out the syntax, that is) is not what the next command expects as input. This has been the most frustrating part of Powershell and I keep hoping that eventually they will attack this with a more holistic approach to produce something with a little more clarity and sanity.
Suddenly Win Admins everywhere switch to Linux because its "easier".
Place nail here >+
Right, but when a huge chunk of your market is going to be businesses with 15-20 employees and no dedicated IT person, or if they have a dedicated IT person they're not actually a trained IT person, having a CLI only is utterly braindead.
Might be it's time for 15-20 person companies that have a need to run a server to learn that having a skilled IT person is about as important as having a person who makes good business decisions. They don't call this the "information age" for nothing. Business today runs in information every bit as much as it runs on cashflow. Most companies wouldn't trust their cashflow to someone who doesn't know their way around a spreadsheet. Perhaps it doesn't make any more sense to trust their informationflow to someone who doesn't know their way around a command line.
'Course, it's not a big leap from that realization to "We should be using *nix for this." :)
Stop-Prism.org: Opt Out of Surveillance
True, but the GUI doesn't take 25% CPU or 30-50% of memory. Our cheapest, oldest servers are 32-bit and can only use 4 GB of RAM. Even then, the GUI environment probably adds 300 MB of memory utilization, which is rarely an issue for those servers than usually don't go over 2 GB of total memory utilization.
Intensive applications reside on servers with 76GB of RAM, where those 300 MB become a drop in the bucket.
When you start talking about really large numbers of servers and virtualization, you can see real savings by skipping the GUI. But the parent claiming that a GUI always takes 25% CPU and 30-50% of memory is frankly lying.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Please no, programs can actually be quite complicated. They aren't like web servers which you configure and leave running. Making them GUI-less will just complicate things and make it much harder to use. There's a reason we use GUI's now a days - it's better for some stuff.
How easy is it to deploy SharePoint automatically? How easy is it to automate the configuration and setup of new SharePoint servers? There are a few tools in the Windows world to automate clicks on various GUI elements...
In Linux, I can deploy complex database sites with a few lines of code in a fab file, or maybe a preseeded dpkg, or maybe bash scripts, or maybe a GET request with a few parameters to generate a config file for the specific server, or I can easily image the server and blow it to all the boxes I need, or...
I'll take the CLI way. Yeah--it might be a bit more painful to edit a TEXT file to configure a service instead of clicking the mouse--but if all you know is the security of point-and-click, maybe you shouldn't be a server admin...
Please name one scenario where point and click is a better way to configure your server than something like a text file or a scriptable CLI.
There's no place like
If, combined, will the 2300 cmdlets do as much as awk.
Nullius in verba
Worked for Novell. Oh, wait.
"Having them on server means you have access to much better bandwidth and your programs can run 24/7, and you can easily deploy more servers if you need to"
What?
Really what are you talking about? If you are running a GUI application on a server that is not just wrong but down right silly.
You need more bandwidth? Then you get it more bandwidth.
Now if you are talking about machines with more than one CPU and a lot of memory then sure. Those are called workstations. They may use the same motherboard as a server but they are not being used as a server.
A server needs a GUI like a submarine needs a screen door. If you are going to run anything like that on a server you should really use a VM anyway so that it will not take down the entire box when it crashes.
Anything on a server that you can get ride of like a video card means less heat, less power used, and less cost. It is also one less thing to fail. RDP? how much bandwidth does that take? A lot more than ssh and command line.
And that is why real tech companies use Unix/Linux for servers.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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.
There's no place like
It's not just the extra memory and cpu used, but the diskspace wasted by having the gui software present on disk... Then you also have to consider the fact that extra software means extra locations where security holes could reside, and therefore extra files that have to have security patches applied etc...
300mb and however much disk space may not be a lot on a single dedicated server, but it soon adds up...
Consider a VM environment where you have a large number of virtual servers running on a single physical box, that wasted memory is now multiplied by the number of virtual instances you have.
Also a VM doesn't have real video ram, it has to emulate it using system memory... So you have a virtual framebuffer sitting there displaying a graphical login prompt...
Also if you have an OS that cannot boot without a videocard fitted, then you have to include one in all of your servers... It will consume power, waste an expansion slot, and cost money... Not a big deal for one server, but soon adds up over a large number.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
No, the path to making better software is to make people understand the ramifications of their actions, and understand not to take those actions unless they understand the consequences, which Microsoft has, in my opinion, been horrible at.
Here's a great example: several times, I've been called in to undo the effects of Windows Load Balancing, a technology Microsoft created to do load balancing in the OS, rather than requiring a separate device. It works by tricking the switch into flooding all incoming packets to a virtual IP to all ports in the broadcast domain where that IP is located.
Once a few years back, I had to go to a "company town" in Indiana that was networked using bridging all over the place. Some consulting company set up a system for them that used three servers with WLB and plopped it right in the middle of this network. I looked at the instructions they followed - they were basically, "to set up WLB, click here, then next, next, finish".
The result of this: everything coming in to these servers was flooded everywhere, including out the 802.11b access points they used on their manufacturing floor. Over 40 MBPS worth. That didn't work too well.
The problem is that, by creating a nice simple interface where you get the impression that everything is SOOO EASY, Microsoft gives people with no clue the impression that they're Windows admins who know what they're doing.
I'll agree, in the aggregate, that it matters less whether there's a GUI or a CLI, but not having a quick and simple interface does help raise the bar a bit and provide a different view, so it doesn't look like the desktop a given clueless user feels familiar with.
A business with 15-20 employees that is still running their own server infrastructure is doing it wrong. smb's are now a target of a very aggressive marketing compaign to the them into the cloud. I expect such cases to disappear within the next 5 years.
US-UK-Israel: The real Axis of Evil
Since these two posts have got so much positive moderation one must assume there are moderators here who have absolutely no idea of how a server works.
Logging in remotely to a server has nothing to do with having a GUI. I do it routinely on my Linux servers using SSH. Using SSH my personal computer is working as a dumb text terminal, which is orders of magnitude faster than a VNC when you have a slow connection.
Having a GUI on the server will worsen your performance.
So, MS is going to make a shift towards more CLI. I had already heard rumours and stories that some configurations would have to be done on the Command Line. I may be a little cynical here, but consider the following:
Over the past while, the perceived value of having MS Certifications has dropped somewhat as MS Windows Servers become more easily configured. Now, Administrators will have to know some of the more arcane commands, and have a better understanding of how the systems work in order to properly configure Windows Server without the GUI's.
Aside from some of the improvements that folks have already mentioned, would this not also revitalize the revenue stream that MS gets from the training and certifications? And, make these certifications actually more relevent?
I'm baffled by this because the Windows command line is absolutely, positively useless in every way. It lacks a proper history function, proper tab completion, proper environment variables, it is not possible to configure most things with text files, scheduling tasks is practically impossible, the multi-rooted filesystem is an unfunny joke, and most of all Batch scripts are literally, not figuratively, the least useful form of programming I have ever seen, including taking a shit on a keyboard and hoping for the best. The entire Windows stack is completely inappropriate for use in any business, let alone as a server, and thinking of using it without the GUI makes me fear and hate it even more than I fear and hate Windows right now.
No. No, Microsoft, no. No, no, no. If you want to make the world a better place, here is a three-step plan:
1. Discontinue Windows. Burn it in a fire, and then apologize for it.
2. ???
3. The world is a better place.
I'm guessing that the reason for using a Windows server is to support some very Windows specific application(s) otherwise why bother? For almost any purpose Linux is better/cheaper/faster/more secure! Just like you would use Solaris for a Solaris-specific server application or NSK for something very critical/scalable. Windows has been eclipsed, and the GUI is compatible with existing code.
I killed da wabbit -Elmer Fudd
I had an OSX-server box with several mac minis for a couple years that I messed around with Xgrid for various tasks. It was more of a hobby, but one thing I liked was the Apple Remote Server toolkit. I had my choice, I could connect to my OSX server box with SSH and do everything command line like any other *iux box, or I could fire up the remote GUI tool on my PowerMac or PowerBook at the time and administrate the machine with the GUI, which was far more handy for some tasks.
I liked the either/or....
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Windows admins, welcome to the real world. You might want to brush up on your reference manuals.
Ok that was snarky, but geeze, as a Unix admin from a time before Winders, I've been waiting for this for a looooong time.
And as the admin of a loose collection of Linux and Windows now, I'm soooo looking forward to dumping Remote Desktop. Oooh, not having to wait for my desktop to load before running one command. It makes me feel all warm and tingly.
Finally, something to look forward to in Windows 8.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Spend your days supporting clients via your proposed method, and you'll quickly learn to appreciate Exchange as the most functional option available. Whether or not the protocol is standardized by IETF, it is VERY widely accepted as a standard now within the enterprise world. Any modern smartphone or even Mac will support Exchange out of the box, no Outlook required.
The only "correct" method is the one that works reliably and securely for your clients. Exchange has been for every environment I've worked in.
/* No Comment */