Desktop, schmesktop: Microsoft reveals next WINDOWS SERVER Windows 10 has hogged the limelight this week, but Microsoft has also revealed a Technical Preview of Windows Server and its System Centre control freak. The releases aren't unexpected: Windows Server's last full version emerged in 2012 and while substantial updates have landed in the years since, Redmond's increasing ardour …
" it's rather like a UNIX shell but much more powerful and secure with lots of more advanced features."
Really? Get back to us when it can do full system job control. And I don't just mean silly cmdlets - I mean full blown standalone daemon processes/services control preferably wiith a readable syntax.
> Really? Get back to us when it can do full system job control.
For jobs control:
Debug-Job, Get-Job, Receive-Job, Remove-Job, Resume-Job, Start-Job, Stop-Job, Suspend-Job, Wait-Job.
Some of these have aliases for shorthand use:
gjb -> Get-Job, rcjb -> Receive-Job, rjb -> Remove-Job, rujb -> Resume-Job, sajb -> Start-Job, spjb -> Stop-Job, sujb -> Suspend-Job, wjb -> Wait-Job
For process control:
Debug-Process, Get-Process, Start-Process, Stop-Process, Wait-Process
Again, with aliases:
gps -> Get-Process, kill -> Stop-Process, ps -> Get-Process, saps -> Start-Process, spps -> Stop-Process, start -> Start-Process
You can start jobs on remote computers without first "shelling" into those. Output from the jobs are marshalled back to the controlling console. It even works if the remote job stops and query for a value (using Read-Host): The prompt will appear on the controlling console when you poll for output/status of the job.
Scripts can be workflows. Workflow scripts are restartable, even across system restarts.
So, between using a remote GUI admin interface and scripting, Windows Server is very well covered.
"Have/would/could you ever configure a simple IIS web+mail server (from "fresh") using just the command line? remotely? "
Easily.
"over SSH?"
God, no. Powershell can be run securely and remotely without having to resort to something as primitive and clunky as SSH with all that key management mess - and includes features like script code signing.
"um, so what do you guys sign your script code with? pens and paper?"
No you use Group policy and your AD PKI to automatically enrole and distribute trusted certs across your whole enterprise. A whole lot easier than the mess involved in doing that sort of thing in the Linux world...
and when those certs expire because some beancounter decides that $<lots> of money going to Experian etc is a waste of time and is of no visible benefit to the company?
What happens when the Security Auditors decide that your SSH keys are insecure and you have to move to TLS ones but your products don't support TLS Keys? (Cue months of upgrade angst)
What happens then smart guy?
How many windows admins really understand certificate administration?
For that matter, how many security admins really understand certificate admin?
Don't even get me started on Self Certification.
I now have lots of grey in my hair because of certificate problems. (spaces in names like DN="fred was here" are my current problem)
I have set up web servers on CentOS and Windows Server 2012 R2 using CLI. Setting up a running server with Wimdows is quicker. A few commands and it serves your URL. Setting up a secure and properly configured server is easier in CentOS.
This is because Apache comes with a human readable flat text config file. Perfect for use on the command line. Windows requires either eleventy squilling powershell commands, or impoting a pre-canned config.
In a windows world, you rely on a series of commands to read an xml config and then set that xml config. It's an irritating round of "20 questions" to troubleshoot and secure.
In a Linix world, you start at the top of the file and you read to thw bottom. The comments guide you and it's like stepping through a text-based wizard.
PowerShell is all about the power of rote memorization. You either speak and memorize the arcane language and it's commands, or you live with a collection of carefilly guarded (and horribly documented) command referencea beside you.
Linix is all about knowing a few key commands and then editing a squillion text files. And 95% of the configuration you need to do in Linux can be done in Webmin anyways, so there's no need to splaff about on the CLI, or to install a full-fat GUI.
For the care and tending of automated server farms, Puppet wrecks both CLIs. Anyone who trylu WANTS to configure servers from a script-like environment should be using Puppet, Chef or Saltstack, making rhe whole argument about which CLI environment is 'better' not only rediculous, but the surest way to detect people who haven't the foggiest fucking clue how to properly administer modern systems.
No you don't. Webmin is fully self contained. When you install it, it installs it's own web server.
wget the RPM, install the RPM, done. (Open hole in firewall if accessing remotely.) http://www.webmin.com/rpm.html
In my case, I usually install the repository, so I actually wget a bash script off my webserver and execute it. One line of code and I've not only downloaded and installed webmin, but set it up so that future versions will automatically update as part of the system.
It doesn't rely on your OS' native web server in any way. It's a separate set of executables, and you can indeed use Webmin to set up your web server once installed. :)
@Trevor Pott - same here on installing Webmin on everything now, and using the repo so it doesn't get stale.
Webmin's pretty cool overall. I had one situation recently with a chroot'd sftp config where I was banging my head on what I had missed on config (it was JUST like what I'd already done a couple times before successfully, but on older SLES versions), installed Webmin, did the config there and learned a couple of things by watching what it changed.
"Setting up a secure and properly configured server is easier in CentOS."
Then you are doing it wrong. IIS has defaulted to a fully running and secured config for at least the last several versions. So all you need to do is:
Install-WindowsFeature Web-Server -IncludeManagementTools -IncludeAllSubFeature
Wow. You're actually so bad at marketing that you don't even keep up with the party line. For the record, even your masters don't believe the lode of tripe you tried to shovel. Please check out their official documentation here which not only shows there is quite a bit of configuration to do to get IIS ready for production, but also shows that "IncludeAllSubFeature" is an absolutely stupid thing to do.
For anyone else reading this thread who wants a much better look at what's needed - and please, if you plan to use IIS don't listen to the anonymous liar - go here and read good, solid info from the pros.
"you can start jobs on remote computers without first "shelling" into those"
Err, guess what - rsh has been able to do that since 1983 though ssh has taken over the job in the last 10 years. Or did you think unix admins always had to log in first then type the command manually?
"So, between using a remote GUI admin interface and scripting, Windows Server is very well covered."
Please explain how executables that don't support .NET objects can be pipelined together in powershell or in fact have anything useful done with them at all.
"Really? Get back to us when it can do full system job control - And I don't just mean silly cmdlets - I mean full blown standalone daemon processes/services control preferably wiith a readable syntax.
Powershell has always been able to do that - and it's far more human readable and easier to use than say a BASH script.
See https://4sysops.com/archives/managing-services-the-powershell-way-part-1/
"Powershell is suitable for use on a Server - it's rather like a UNIX shell but much more powerful and secure with lots of more advanced features"
This has been tolled to death. That matter is quite subjective, and your statement is full of personal opinion stated as fact - like something a salesman would say.
There are many UNIX shells, and it's impossible to compare all of them with Powershell and come out with the conclusion that "Powershell is the bestest", without even knowing what problem you're trying to solve, and what the constraints of the environment are.
I don't use UNIX, so I know very little of their command prompts, but I have used Powershell and it's not as great as the sales teams (and fans who aren't even sys-admins) make it out to be. It's a competent scripting language that has an interactive prompt that, from my trials, can only be accessed while "on" the machine or over RDP. Also, users are unable to run scripts without the Administrators say so.
"That matter is quite subjective"
No it really isn't. Even advanced hybrid UNIX shells like PASH are not as fully featured as PowerShell. There are lots of features and functionality that PowerShell has that UNIX shells don't but almost nothing that Unix Shells have that PowerShell doesn't....
"Also, users are unable to run scripts without the Administrators say so."
Rubbish.
"from my trials, can only be accessed while "on" the machine or over RDP"
More Rubbish.
"don't use UNIX, so I know very little of their command prompts"
Yes, it is quite clear that you are commenting on something about which you don't have a clue.
> There are many UNIX shells, and it's impossible to compare all
> of them with Powershell and come out with the conclusion that
> "Powershell is the bestest",
Indeed, a comparison with the goal of crowning "the best" makes little sense. Not least because much of PowerShell makes sense mostly on Windows and would add little value on *nix systems. Conversely, the *nix shells with their line-text-centric processing is often at odds with Windows where you either need to control through APIs, XML or similar.
> ... has an interactive prompt that, from my trials, can only be
> accessed while "on" the machine or over RDP
Then you have not tried PowerShell since version 1.0. This first version had no built-in remoting, but could be used across SSH connections.
In PowerShell 2.0 a lot of remoting and job features were added. Many commands take a -ComputerName parameter where you can pass a list of hosts where the command should execute remotely but return the output to the controlling console. There is a general Invoke-Command that can execute commands, scripts, functions on remote machines simultaneously and marshal the output back.
This post has been deleted by its author
"Let's hope the version has a user interface suitable for use on a server..."
You mean a command prompt with Powershell by default and no GUI - just like the current version?
"don't you just love trying to hold the mouse over the exact right pixel to get the start screen to show up using server 2012 over RDP?"
No - I don't install a GUI. You don't need to. All the GUI tools can be run remotely if you prefer them to Powershell.
There are some non Microsoft products (These do exist you know) that require a whole lot more awkward configuration to work when there is no GUI on the host server. Then there are the security implications to consider. This makes running a GUI ( and GUI really), even that Metro abortion a whole lot easier than with no GUI.
One product I work on actually disables remote access to its critical bits from remote servers by default. IMOH this makes it a lot more secure OOTB. Yes you can fix the product and let remote users admin it but frankly that is one security nightmare I'd rather not have. Making local access a requirement is an extra security level that the hackers have to negociate. We actively restrict those users with one time passwords.
I really do not want to take a step backwards. The Security auditors would have an apoplectic fit if I proposed remote (non logged in) admin access to the system.
Obviously MS has made things easier for running MS products but these are not oused on our systems (No BizTalk, Sharepoint etc). They have enough problems accepting MSMQ that some of the things we connect to insist on using.
Anon for blindingly obvious reasons.
Surely, with Hyper-V clusters, you've always had that kind of capability?
Move VM's off one server. Migrate. Slowly move them back. Migrate the other servers. Job done?
I'm not in an industry where I see many highly-available clusters of a significant size but isn't the new capability really just a more-risky in-place upgrade that relies on everything working with no way back?
Don't ask that. You see Windows was famous for decades as being the OS that was easy to administer even if you had no clue how most of it worked. Microsoft walked away from that ages ago. Now it's :memorize your powershell" or "use some ancient horrible UI that even CA or Symantec would be embarassed by."
System Center isn't a selling feature, it's a prison sentence.
Why all the hate? It's the best thing Microsoft has done. Ever.
They completely fucked the GUI on Server 2012, so I dont even bother with that any more. Powershell and remote Powershell are the way forward if you are managing a Windows box. PowerShell 4 enables you to control everything the OS does. It's easy enough to learn the syntax and learning the commands is just a matter of repetition.
Seriously, its the only thing that's kept Windows alive on server. I imagine all the hate comes from BASH admins, who probably havent tried it.
I don't have hate for it. Powershell is great for windows automation tasks, and should have been introduced 15 years or so ago when MS was still a monopoly and sysadmins largely only wore a Windows hat (well the ones that weren't Novell). With the rise of Linux in the datacenter, I had to pick up BASH and Python, and now am over on the other side of the fence. So as it is now, you need cross platform languages. It would have been better had MS picked up Python, made libraries for it, and used it rather than introducing yet ANOTHER language for the toolkit. Windows Admin'ing doesn't pay as well, so *SHOULD* I fully pick up Powershell? For me the answer is no. I dawdle with it here and there, produce a few small scripts, edit on some others, but I really don't see the need to go all in on it.
I should have been more clear: with a few exceptions, PowerShell is generally despised as a means of day to day administration. It's not that it's utterly useless, it's just that for the two most common use cases - putting out fires or automating farms - it is surpassed by other toolsets. (The GUI for firefighting and Puppet/Chef/Saltstack for farming.)
PowerShell is a fantastic expansion of the CMD CLI. It's a great ancillary tool. But it's primary use is as "one tool in a toolkit consisting of many tools". In the role of "the only tool" or even merely "the primary tool", PowerShell fails.
PowerShell is ultimately good for A) getting at features MS neglected to put in the GUI or B) batch scripting. If you'd normally write is as a cron job, PowerShell can do the thing. Or, if you are trying to do a series of actions as part of an upgrade process/migration, PowerShell might be a good answer.
But for standardised deployments, policy pushes, standardised updates or even bulk migrations any of the proper automation/orchestration tools are just flat out better. And for those situation where you're fighting fires, an intuitive GUI is way better, especially for those instances where you're fighting fires on an application you haven't touched in months, or even since it was originally installed.
This is - to put it mildly - a different role than is served by the CLI in Linux. The CLI in Linux is much more mature, with a multitude of scripting languages grown around it, and the majority of application configuration done as flat text files, not as XML. (Systemd can die in a fire.)
So yeah, when people come out of nowhere and say stupid shit like "real sysadmins only administer servers with PowerShell" actual real sysadmins roll their eyes. It's not the correct tool for the day to day. It's a point solution to specific problems. It's good at that, but if someone tried to force you to use it as the only solution, you'd go mad.
And, quite frankly, I've met more than a few marketing-driven types who absolutely do try to force their sysadmins into PowerShell only management. They experience high turnover then start complaining loudly about "how hard it is to get IT talent".
Trevor, you claim that PowerShell is generally despised as a means of day to day administration".
That's a very unspecific and unverifiable claim. When I come across an admin who uses arcane tools or self-automates through the GUI by manually following "manuals", I always demonstrate to them how they can accomplish the tasks using PowerShell. And the response is generally overwhelmingly positive. So I have the exact opposite experience from you; although like yours it is still anecdotal.
PowerShell *is* the primary tool. Through the module feature it has quickly grown to become the hub of CLI administration on Windows boxes. I dare you to find an area that can not be administered using PowerShell.
> But for standardised deployments, policy pushes, standardised updates or even bulk migrations any of the proper automation/orchestration tools are just flat out better.
The right tool for the job. On Windows there is still group policies which remains the most important vehicle for pushing policies. PowerShell is not intended to replace GPOs. PowerShell *can* fill the gaps where group policies cannot reach.
> And for those situation where you're fighting fires, an intuitive GUI is way better, especially for those instances where you're fighting fires on an application you haven't touched in months, or even since it was originally installed.
> This is - to put it mildly - a different role than is served by the CLI in Linux.
If you are "fighting fires" in an application you haven't touched in months and find the GUI better for that, how come you think the Linux CLI is better for that? If your problem is unknown/forgotten instrumentation, *discovery* is what you are after. A GUI can certainly help you there, but I frankly cannot see how a *Linux CLI* would offer more discovery.
In fact, PowerShell offers *much more* in the discovery department than any Linux CLI or scripting language. Granted, you have to be familiar with a few central concepts of PowerShell: Modules, naming convention, Get-Member, Get-Help, Get-Command. However, these are very basic concepts that you are not likely to forget even if youjust use PowerShell occasionally.
> The CLI in Linux is much more mature, with a multitude of scripting languages grown around it, and the majority of application configuration done as flat text files, not as XML. (Systemd can die in a fire.)
More mature? How about *old*? Case in point: The arcane bash syntax with its convoluted parser that has placed hundreds of thousands systems at risk.
Yes, the Unix tradition is to use plain text files. The Windows tradition is to use APIs, possibly backed by XML files. There are advantages and disadvantages to each approach. Personally, I prefer the API approach as it makes it easier to create robust scripts and procedures that will also carry forward in versions, even if the underlying format changes.
If you are "fighting fires" in an application you haven't touched in months and find the GUI better for that, how come you think the Linux CLI is better for that?
Probably everything server related in Linux is geared towards CLI support. In most cases, the CLI in Linux isn't just the primary interface, it's the only interface. The GUI is a wrapper for the CLI, which mostly serves as a crutch for those moving from Windows.
Professionally, I'm a Windows Admin - I almost never go into the command prompt. If I do, it's cmd.exe (I'm an old DOS user). At home, I have a 3 Linode VPSs - they don't even have X installed. I just use the best tools for the job. Anyone who suggests operating Windows via the command line are either idiots, or liars.
"More mature? How about *old*?"
I have a Sanyo clock radio purchased in 1982 three months before I was born. It is still to this day my primary alarm clock and it still works like a hot damn.
I have an IBM model M purchased 8 months before I was born. It is still to this day my primary keyboard and it still works like a hot damn.
I have a set of stainless steel pots and pans purchased over a decade before I was born. They are still to this day my primary pots and pans and they still work like a hot damn.
I have a blender that was purchased 5 years before I was born. It is still my primary blender to this day and it still works like a hot damn.
Old?
Yes, please!
I can list hundreds of items that are in use in my house that are from before I was fucking born. That makes them well over 30 years old, and they are all still my primary items for those use cases. At various times I have bought "replacements" that were "newer" than each of them. Inevitably, each of those items broke beyond my ability to repair and I went back to the tried and true.
Newer isn't always better. If you cannot grasp that simple, fundamental truth then absolutely nothing else you write is worth listening to. Christ man, you live in a consumerist society, for fuck's sake. And you're peddling "old = bad"?
Read this and for the love of $deity get out and actually gain some worldly experience.
Next, you can go back and actually read what I wrote, and realize that my beef was with the fanboy asshats who propose PowerShell as the only - or at least the primary - means of administration on Windows server. More specifically, those who say stupid things like "GUIs aren't necessary because there's PowerShell", or who propose automating and orchestrating entire datacenters using nothing but PowerShell.
As for "why is Linux better", the poster above me got it dead to rights. Also: flat text > APIs any day of the week. APIs change and evolve, and not everyone is a programmer. Text files change too, but if you can't read you're useless for a systems administrator regardless of the interface.
If you honestly believe that APIs will always be backwards compatible you're naive and deserve what you get.
In all, you come off as someone horribly young. Naieve, easily led, and not having studied history so you can learn from it.
Pity, maybe if you had been born during an era of tools and devices that were generational you might appreciate the value of engineering for quality instead of designing for obsolescence.
I respectfully have to disagree with most of your sentiments there Mr. Pott.
It may be a result of my line of work involving a primarily Mircrosoft server fleet, AD and exchange, but I use Powershell every day, for a huge variety of tasks (not just fettling with servers). I have written scripts for various other parts of the IT dept, all in Powershell, and even other parts of the business.
Its value to AD and exchange is incalculable in my eyes when working with large forests and exchange environments (we employ over 10,000 people, across the world, 3 domains in a forest trust and an exchange cluster in each main region). The GUI is just laughably useless for managing this.
The only thing that I cant do with it is administer our small fleet of Linux machines. SSH for that.
But, go ahead. Stick with your old alarm clocks, saucepans (which I can only assume don't get used since the non-stick surface would have gone long before now) and old man attitude. If you want to use a keyboard that's older than the surface of the sun, thats fine. Just don't act like I should be doing the same, when there are much better NEWER things around.
Consumerism drives capitalism, which ultimately drives society forward (whether you like it or not doesnt matter). If we all clung to our beloved old shit all the time, the damn society would collapse. I think your designing for obsolescence has a ring of truth to it, but ultimately reeks of conspiracy nut theory when applied to technology as a whole.
This post has been deleted by its author
>> It doesn't look like Powershell 5 will be backported to Windows 7 or Server 2008/R2?
>Source?
hehe - curiosity got the better of me, and I had to look as well. Not only is it NOT for 2008r2, but its NOT for 2012 either (tough luck for those folks who are resource bound and unable to get the 2012 servers up to date. err damn, that's my shop as well....)
Check the bottom of the MS Powershell blog stating Win 8.1 and Server 2012r2 only....:
http://blogs.msdn.com/b/powershell/archive/2014/09/04/windows-management-framework-5-0-preview-september-2014-is-now-available.aspx
It is the *preview* that installs exclusively on 8.1 and Server 2012R2.
I was looking for a source on which platform the *final* product will be available on.
PowerShell 4 was *also* platform limited during the preview phase, but was backported afterwards.
The only thing I found was the current tech preview, which looks (to me) to be the last one before release, and no support indicated for anything other than the ultra current Win codebase. Without any indications to the contrary, I can't assume it will be backported, particularly with their push to get people to Win8.x based platforms. For admins, this would make for a good upgrade carrot...
Only time I ever use powershell is in exchange to add delegate access to new users across the rest of the mailboxs as a customer needs everyones personal calendar to be visible to everyone else (public folders were not an option).
I tweak the notepad ps script then blast it through exchange. Takes a matter of minutes to update 20 or so mailboxes with new users.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
