Discussion on:
View:
Show:
I heard mention that one of the features of Server Core will be that the GUI can be activated for troubleshooting purposes, then disabled again to maintain security. This reduces the attack surface any time the GUI is disabled, yet still allows admins to work with the GUI when they need to. Sounds like a win-win scenario to me.
You have to appreciate the Gnu/Linux model here. I log in remotely over ssh, then without any GUI environment running (or even installed) I can run whatever GUI apps I want off the server.
This is because the underlying graphic environment, "X," has a nifty setup: running X, my local machine is the X server, and the remote server I am working on is the X client. All the machine I am administrating needs to do is feed whatever data I ask for (including what the X server on my local machine asks for) so my local system can paint whatever GUI based app I happen to be running.
No graphic environment ever runs on the server. As I said, you don't even install a "desktop environment," you do install GUI-generating apps on it, eg wireshark, but again, the whole graphics subsystem is running on my laptop or whatever I'm sitting in front of.
I have always hoped Microsoft would come up with something similar. It can't be that difficult. I prefer to keep a server "headless," and Like Rickatron here, I'm not too smooth with powershell.
I don't foresee being able to invest enough time for me to be comfortable with powershell, that is having a solid sense that I'm doing things right and that the system is secure.
ps I beg of you please.. don't talk to me about cygwin.. just... don't. They don't tell you that by "$PATH" they mean the fastest route to the straight jacket and/or rubber room.
This is because the underlying graphic environment, "X," has a nifty setup: running X, my local machine is the X server, and the remote server I am working on is the X client. All the machine I am administrating needs to do is feed whatever data I ask for (including what the X server on my local machine asks for) so my local system can paint whatever GUI based app I happen to be running.
No graphic environment ever runs on the server. As I said, you don't even install a "desktop environment," you do install GUI-generating apps on it, eg wireshark, but again, the whole graphics subsystem is running on my laptop or whatever I'm sitting in front of.
I have always hoped Microsoft would come up with something similar. It can't be that difficult. I prefer to keep a server "headless," and Like Rickatron here, I'm not too smooth with powershell.
I don't foresee being able to invest enough time for me to be comfortable with powershell, that is having a solid sense that I'm doing things right and that the system is secure.
ps I beg of you please.. don't talk to me about cygwin.. just... don't. They don't tell you that by "$PATH" they mean the fastest route to the straight jacket and/or rubber room.
I've been a windows admin for more years then I can count, but over the years I've also picked up many other operating systems. Each brings it own benefits but honestly if your going to use a non gui core, go with someone that's already established and has the least downtime when it comes to patching, a linux distro.
I personally have not found the benefit of using a windows server core install.
I personally have not found the benefit of using a windows server core install.
On-demand, yes; but I'm not wild about doing that in the scope of troubleshooting.
Microsoft are engineering for 8 and the post 8 world. Powershell is utterly useless, requires enormous bucketloads of commitment, and is only viable to the very adept.net admins, and almost no one else. Its security is going to be utterly ruinous as most admins won't run it securily, and just wait until public copy + paste of foreign code bits. Most admins do not know what they are entering, or what the command will do. For the very few, adept .net code writing admins - powershell will be a boon. I've sat through endless hours of videos and tutorials, and I'm still not seeing what use it is. Get-process - bleh, brings me a static list of processes. Thats hopelessly worse than task manager. And yet they jump up and down when showing it.
But thats not being built for us. Microsoft is signing the terminal papers for many admins, and they know it. Their engineering is underwriting the azure and cloud structure they need to build and manage - and the fact its aimed at us between the eyes is obvious. I feel no need today to be friendly towards any such company. Its recent behaviour is one of complete arrogance, metro and powershell stupidity, and brash ignorance towards its customers and advocates. Metro, Arm, and Azure. All have their uses, but have no purpose in my legacy windows world. Or *my users* world. And for the first time ever, the truth is such arrogance can be paid back in spades.
But thats not being built for us. Microsoft is signing the terminal papers for many admins, and they know it. Their engineering is underwriting the azure and cloud structure they need to build and manage - and the fact its aimed at us between the eyes is obvious. I feel no need today to be friendly towards any such company. Its recent behaviour is one of complete arrogance, metro and powershell stupidity, and brash ignorance towards its customers and advocates. Metro, Arm, and Azure. All have their uses, but have no purpose in my legacy windows world. Or *my users* world. And for the first time ever, the truth is such arrogance can be paid back in spades.
Like Rick Vanover, the reason I moved away from Netware in the late 90's. I am not a code writer - if I was - I would be a programmer not a systems admin. Powershell is not something that I want to spend the next several years learning. The Windows GUI is what put NT4 on the map and what dethroned Netware as king of the hill. Why are we going backwards 15 years?
is two-fold.
The first is what I consider to be the REAL problem - resource usage. If a GUI is running, it is using up memory, consuming CPU cycles, and generally bloating the base of running code.
The second problem is that MANY people believe that a GUI is a less secure environement, because it will, of neccesity, contain a lot of code.
While the first problem IS valid, it is also a minor consideration for most modern servers. In fact, the the way that most networks are moving to virtuallize thier server environement is proof that the majority of servers have processing power available.
The second problem MAY be correct, but to my mind, the amount of added risk seems to be minor compared to the benefits in managing the server.
I have been in IT for a long time. My first experiences with an OS include CP/M, RS Basic, and UNIX at college. I graduated thru DOS and Win 3.11 to Win95 and NT, followed by Win2000 Server and Pro up to today's versions. In all that time, I have always counted the GUI to have been the single most effective advantage that administrators had over other OSes.
Like the majority of the members that have posted comments here, I just don't have the time (or inclination) to learn a command-line interface to control functions that I don't interact with on a daily basis. Even if I had the time to learn an esoteric set of command, I still prefer a GUI, because I have seldom fat-fingered a mouse click. It may take me a couple of seconds longer to click thru a series of menus and command applets, but if I typo a command it will have taken me just as long, and I DON'T have to worry that the typo will perform a command that will kill the server!
I will admit, however, that if Microsoft had ever incorporated an X-Windows style system, I would have been even happier.
The first is what I consider to be the REAL problem - resource usage. If a GUI is running, it is using up memory, consuming CPU cycles, and generally bloating the base of running code.
The second problem is that MANY people believe that a GUI is a less secure environement, because it will, of neccesity, contain a lot of code.
While the first problem IS valid, it is also a minor consideration for most modern servers. In fact, the the way that most networks are moving to virtuallize thier server environement is proof that the majority of servers have processing power available.
The second problem MAY be correct, but to my mind, the amount of added risk seems to be minor compared to the benefits in managing the server.
I have been in IT for a long time. My first experiences with an OS include CP/M, RS Basic, and UNIX at college. I graduated thru DOS and Win 3.11 to Win95 and NT, followed by Win2000 Server and Pro up to today's versions. In all that time, I have always counted the GUI to have been the single most effective advantage that administrators had over other OSes.
Like the majority of the members that have posted comments here, I just don't have the time (or inclination) to learn a command-line interface to control functions that I don't interact with on a daily basis. Even if I had the time to learn an esoteric set of command, I still prefer a GUI, because I have seldom fat-fingered a mouse click. It may take me a couple of seconds longer to click thru a series of menus and command applets, but if I typo a command it will have taken me just as long, and I DON'T have to worry that the typo will perform a command that will kill the server!
I will admit, however, that if Microsoft had ever incorporated an X-Windows style system, I would have been even happier.
Totally agree with pgit - Microsoft seem to want to rearchitect Windows Server away from a GUI altogether which is a massive step backwards. What they need to do is re-engineer it to along the lines of X windows or off-load the GUI to a management appliance. That at least partially addresses the overhead and security concerns over local GUIs but doesn't force everyone down into 1970's command line rubbish. Somethings are no doubt worth taking the time to write (or adapt someone elses) Powershell script for but I'd guess 99% of the stuff I do I'm quicker at by using the GUI and it's much easier to build in "are you sure?" type logic into a GUI workflow.
I can understand the desire for Microsoft to minimize the footprint. And for larger shops, this can make a lot sense.
But customers are all small shops and wish to do some "admin" work - aka tell me what to do. Server Core basically shuts them out. Hell, even shuts me out in some ways. Over 20 years ago, I made the move to a GUI (Windows 3.1) because I didn't have to memorize all the little damn option flags for the command line.
I guess I am getting too old. Sigh.
Tom
But customers are all small shops and wish to do some "admin" work - aka tell me what to do. Server Core basically shuts them out. Hell, even shuts me out in some ways. Over 20 years ago, I made the move to a GUI (Windows 3.1) because I didn't have to memorize all the little damn option flags for the command line.
I guess I am getting too old. Sigh.
Tom
I was too kinda skeptical about the core preferred installation method... feeling being lost and had to be a less lazy admin. It was until I used the RSAT for Windows 8. Compared with the earlier versions, it has improved a lot and turn your Windows 8 servers easy to administrate. The only problem with the current version, there is no remote console for ADRMS...
MS problem has never been that a GUI equals bloating.
Bloating comes from unnecessary services and software running right from the start.
And MS problem with GUIs is that they have always been so enmeshed with the server core that a GUI problem can get you a BSOD.
I don't think an OS ability to be reconfigured on the run is dependent on the absence of a GUI. It makes no sense.
Bloating comes from unnecessary services and software running right from the start.
And MS problem with GUIs is that they have always been so enmeshed with the server core that a GUI problem can get you a BSOD.
I don't think an OS ability to be reconfigured on the run is dependent on the absence of a GUI. It makes no sense.
I prefer the web gui over core. A wise teacher from my cert classes many years ago had a motto, "work smart not hard" and working in a command line environment just isn't easier unless you put the time into it.
does not mean that you can no long install Windows Server with a GUI. My thinking on this is that Microsoft is trying to get the Linux and Netware administrators to embrace them by offering a command line only OS. "See we have that too" mentality. Also when you think about virtualization, the Host OS does need to be small and streamlined. A GUI running on the Virtual Host would be a complete waste of resources that could otherwise be provisioned for use by the virtual machines and that is not to mention the monthly patches that you would have to put on the Host that would almost always require a reboot. Server Core to me is really geared towards being the Virtual Host and geared to give VMware a run for its money if they can get the High Availability capabilities that VMware currently has operational.
We are a relatively small shop with a mix of servers. Mostly we are a windows shop and just for an experiment a couple of years ago I installed one of my hyper-v servers as a server core install. My thinking was to see how it performed and see what my administration issues might be. Well I quickly discovered I couldn't install my backup software when the server was in server core, so that along with just finding it exceedingly faster to administer the server using the GUI I went back to a full blown install. I didn't see any noticeable performance gain from not having the gui...I wish Microsoft could take the same path that Linux has where the GUI is just another program that runs. With Linux for years you have been able to put the server into another run level and only fire up the GUI when really needed then shut it down again when not. Or as previous posters have said use an X Windows type approach where the server is on my computer...I have to agree that I would not enjoy going back to a command line interface.
Microsoft could have easily separated the GUI from the Server Core install and set it up as an external install. Meaning, server admins could run the GUI installed on a remote PC and interface with the server. That PC could interface with many servers. Problem solved.
I have been doing this for many years and i thought the whole ideal to adding the Gui was to make things easier and more error proof. I agree that some things especially adding large groups of data are much better suited to command prompt and power shell but day to day tasks and single use items are much easier and much more error proof in the Gui. Some of the best IT people I know are their own worst enemies when it comes to making changes outside the Gui. There is no feedback or display of what you have just done and tracking it down later can be a real pain in the butt. I work with many products other than servers that programming is done on a single line or command prompt type basis and the introduction of a gui or multiline progamming interface has always ended up being much more efficient and time saving in the end. It has been my experience in trouble shooting and fixing things that Ego tends to be the biggest problem as there is no way i did anything wrong has to be something else and many hours of time get wasted that way. Command prompt and power shell both seem to be more for the Ego based mentality as they tend to be the people that have the attitude that I can do it better this way then some sillyGui and they do not seem to understand that the Gui helps so much with the feedback you get from it that you are much better at your job using it then not. I feel that trying to not use the Gui is like taking a step backward. When security issues warrent it I understand the practicality of using a Core installation but otherwise I feel the Gui is way more helpful then it is detrimental
My thoughts on MS Server core have always been that it is a step back to the stone ages of server management. Yeah I know, it has the advantages of a small attack surface and implementing all kinds of read only stuff for branch office stand-ups, but in my mind it is just Microsoft making a go at the Linux server space. They are trying to crush Linux and grab the little bit of market share that they have gained a foothold on.
It is also conceals a veiled plan (maybe not so concealed) to open up another profit vector by requiring organizations to purchase licensing to all of their current and future flavors of Service Center management tools in order to effectively manage all of their server core instances of MS Server 8, 9, 10,.... It is just another cash cow for them and another cost for us. Personally, the reason I don't like Linux, as wonderful as it is, is because I do not want to have to memorize a huge set and subsets of cli crap, mounts and unmounts. Lets preserve all of those GUI developer jobs MS is trying to eliminate, and demand our shrinking GUI tool sets!
It is also conceals a veiled plan (maybe not so concealed) to open up another profit vector by requiring organizations to purchase licensing to all of their current and future flavors of Service Center management tools in order to effectively manage all of their server core instances of MS Server 8, 9, 10,.... It is just another cash cow for them and another cost for us. Personally, the reason I don't like Linux, as wonderful as it is, is because I do not want to have to memorize a huge set and subsets of cli crap, mounts and unmounts. Lets preserve all of those GUI developer jobs MS is trying to eliminate, and demand our shrinking GUI tool sets!
If, as the podcast reports, the GUI can be turned on and off at will then I don't see how there would be any difference between a server core install/license and a full server install/license, so maybe this will simplify things a bit.
My first intro to desktop computing was the Mac Plus, and I've been gui oriented since. My skills regarding Powershell and cmdlts is worse than sucko. As a gui person, I never learned to DOS or MSDOS, so if I need to use the CmdPrompt, unless I've used a particular cmd repeatedly, I need to look-up the cmd I should use. To me, server core installation appears to be a regression, not a technical advance. Sine I use gui for 99+% of my admin work, why would I want to learn Powershell at this point of my career (60+ and getting older and more curmudgeonly).
The MSFT blog post mentioned in the TR blog makes it pretty clear that the gui isn't going anywhere. Just run it remotely. But that's been standard advice for a while now and predates Core Server.
Don't administer a server from the server and several of your objections go away.
Don't administer a server from the server and several of your objections go away.
Since my primary role is not as a Windows server admin, but as a Linux/UNIX (hereafter *NIX) admin, I have a slightly different take on this argument. Anyway, here is my $0.02.
Microsoft would have been better served by making the GUI optional to begin with - back when resources were smaller and more scarce - almost every server we buy is overpowered for what we need it for - we almost can't buy a right-sized standalone server. However, I can also agree with the comment that I saw about wasting virtual resources when there is a very dense virtual environment.
The second thing that I would like to suggest is that PowerShell is not the same as the *NIX CLI - to me, it is like the COBOL of CLI - it's so wordy and all of its options are so long, that all of its efficiency is actually lost. Compare that to the very terse *NIX CLI environment where most options are one letter and there is a huge difference. I work in CLI most of the time and have done so now for nearly 20 years (holy crap - I don't even like the idea of what that suggests), but I'm terrible with PowerShell because it seems so alien to the way that regular *NIX commands work. I also learn new things about the CLI environment every day - there really is a lot to it. I also use a Linux GUI desktop to do those types of tasks when needed and try to use the right tool for the job.
I still think that knowing both the command line and GUI makes for a better admin. I'm sure that some people would disagree here, but this is where I almost think that Microsoft has done such a disservice to less experienced admins by convincing them that the CLI was never worth learning. Each method has its merits and both are worth knowing.
Microsoft would have been better served by making the GUI optional to begin with - back when resources were smaller and more scarce - almost every server we buy is overpowered for what we need it for - we almost can't buy a right-sized standalone server. However, I can also agree with the comment that I saw about wasting virtual resources when there is a very dense virtual environment.
The second thing that I would like to suggest is that PowerShell is not the same as the *NIX CLI - to me, it is like the COBOL of CLI - it's so wordy and all of its options are so long, that all of its efficiency is actually lost. Compare that to the very terse *NIX CLI environment where most options are one letter and there is a huge difference. I work in CLI most of the time and have done so now for nearly 20 years (holy crap - I don't even like the idea of what that suggests), but I'm terrible with PowerShell because it seems so alien to the way that regular *NIX commands work. I also learn new things about the CLI environment every day - there really is a lot to it. I also use a Linux GUI desktop to do those types of tasks when needed and try to use the right tool for the job.
I still think that knowing both the command line and GUI makes for a better admin. I'm sure that some people would disagree here, but this is where I almost think that Microsoft has done such a disservice to less experienced admins by convincing them that the CLI was never worth learning. Each method has its merits and both are worth knowing.
Had Microsoft started this way think of all the Blue Screens of Death you could have avoided.
Simple solution would be to have the system boot to cmd line and have a startx command available when needed. Might not reduce the patches but certainly would give you the benefit of a reduced foot print in RAM.
Simple solution would be to have the system boot to cmd line and have a startx command available when needed. Might not reduce the patches but certainly would give you the benefit of a reduced foot print in RAM.
I'm sure the idea here is that people will leave Linux in droves because now they can live in a Windows command prompt; this is a hope, or a dream, which is distinctly different than an idea.
I was a Master CNE; Novell was not just a better platform than NT, it wasn't even in the same game, and yet all my clients eventually converted from NetWare to NT, and waited 10 years before they could do things that NetWare did in the 80s. Why did this happen? Because of the appeal that low hanging fruit has to the masses: the ease of use. This is why people buy Macs. The masses are not interested in 250 new powershell commands at every turn that they can learn; they want to think less, not more. If you're not one of the masses, you're happily using some Linux variant already, by CHOICE. Microsoft is way, way, way off base here.
I was a Master CNE; Novell was not just a better platform than NT, it wasn't even in the same game, and yet all my clients eventually converted from NetWare to NT, and waited 10 years before they could do things that NetWare did in the 80s. Why did this happen? Because of the appeal that low hanging fruit has to the masses: the ease of use. This is why people buy Macs. The masses are not interested in 250 new powershell commands at every turn that they can learn; they want to think less, not more. If you're not one of the masses, you're happily using some Linux variant already, by CHOICE. Microsoft is way, way, way off base here.
Personally I see only 2 reasons to go cmd only, security and lack of resources. Years ago the cmd was king cause disk space and memory and CPU power was low. This has Looong since past, a GUI takes virtually no resources. There is a small argument for the cmd being more secure, however if some one is clever enough to get through your outer defences then the cmd is know entity and no challenge. Given the foregoing and the fact that generally having a GUI makes admin and troubleshooting easier why would you not install the GUI. Hey and the cmd is still there for all those tasks that are easier with it.!
I would need a solid and very convincing argument NOT to install the GUI
I would need a solid and very convincing argument NOT to install the GUI
I thought Windows was a GUI to make command line user friendly. I do full installs & disable what I do not need running all the time. The last thing I want or need to do is install windows a component & have to take down a prodection server to reboot the whole thing to use some component. Disk space cheap enough. I also copy the whole CD to the local drive so I don't have to spend hours looking for the wrong CD version or scratched beyond readable CD. Original CDs belong locked up safe for disasters. Having a server dedicated to application installs via the LAN is one way to go.
??? because there are still things you need a console. As you all know with Windows Server 2008 R2 and Service Pack 1, there is no supported way to administrate from a Windows 7 a WDS Environment because Microsoft never released a full working RSAT toolset. This Problem exists since 4 years now. Why should I expect that this will be better with all this new Server 8 consoles?
There's a real simple answer to #4 and there's a great quote from Don Jones about it, "Learn Powershell or learn how to say would you like fries with that"
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
