
excited is an understatement
Microsoft's Windows Server 2012 is out. For many systems administrators, the question about this latest iteration of Microsoft's server family is not "What's new?" but "Why care?" Server 2008 R2 is a great operating system, while Server 2012 bears the stigma of Metro and the Windows 8 controversy. But the answer to "why care" …
I disagree: I work in backup and I'm seeing (albeit anecdotal) more and more demand for Hyper-v backups, it appears that MS is offering serious competition to VMware at this level at least.
Also - If MS are offering features in Windows for which you have a few legacy proprietary RISC UNIX servers kicking around in a predominantly Windows estate, it'll win those tasks from legacy UNIX.
You can't use the Powershell 3 cmdlets with SharePoint 2010, so basically this version is useless for SP2010 until MS decide to bring out a new update.
Also, one of the other best new features is the ability to go back to a core or full version of the OS, or an intermediate 'minimal server interface' which will just give you a PS console, and the Server Manager interface. Additionally, you can now choose not just to remove roles and features, you can actually get rid of them altogether, meaning a reduced attack surface. As much as I hate Microsoft, I have to admit, Server 2012 is a great OS. Shame about the Metro though...
All well and good but let's not forget one big downside when using the UI:
Metro (TIFKAM).
It's not all that hot on a desktop but on a server it's pointless. There are no server specific tiled apps so every time you click on something just end up back on the desktop. Stupid. It'd also be nice if just once MS could avoid radical changes to UI layout on applications as well. Administering a server is hard enough without buttons and menus being rearranged and removed.
But it runs well enough from what I can tell.
You shouldn't really be installing the GUI on a Win2012 server, even if you do (and I have to see what it's like) the metro interface is pretty good, I would suggest better on a server desktop. It's basically six or so buttons for what you really need to do and that's it. The vast majority of GUI configuration is done through the server manager or the control panel, both of which are run from the desktop.
>You shouldn't really be installing the GUI on a Win2012 server
In our environment that would be a pain. We are a software development team so none of us are 'highly qualified experienced adminstrators'. We're just a bunch of guys who have to have various test environments to run our product on. The advantage of a GUI is that you can usually muddle your way through whereas a console typically uses arcane and obtuse syntax. We do use PowerShell for some things because our product integrates with Exchange and SharePoint but for everyday maintennance a GUI is far easier to live with.
In any case - they gave us a GUI. Why saddle it with an additional pointless 'front end'?
@AndrewC - Use the GUI then, you have the option to install it, but you also have the option to not install the GUI and do all of your GUI management of the server from a workstation. You can use Win7 or Win8 as management workstations, IIRC.
You could claim that the start menu is a pointless front-end to the desktop of other versions of Windows, it's pretty much the same as the modern UI, particularly on a server where there is no dynamic update of the tiles.
"Does somebody just go through the Reg forums clicking downvote buttons, or what?"
It's the "or what" I'm afraid. What they do is click on your name, which takes them to a list of all your recent posts, and *then* they go down the list clicking downvote buttons.
El Reg, would it be possible to limit the number of votes someone can make in a given time period?
Yes, the GUI option is a stripped down version of the modern UI, with a desktop button, command line, admin tools. In practice it's just a start menu replacement, like on Windows 8, but can AFAIK as I've not tried it, I think it can be beefed up by adding all the components required to make it into pretty much a full on Windows 8 desktop.
> Metro (TIFKAM).
Interestingly, you might be right on execution, but since people don't do "real" work on servers I would expect that a touch interface GUI to be more relevant than on a desktop for the kind of admin tasks that people might perform on them.
It will be interesting to see how this pans out.
> It will be interesting to see how this pans out.
It just occurred to me that perhaps it could be reminiscent of the old NetWare UI. People with a specific task click a tile, do it and exit? I don't think the current GUI really lends itself to that but I can see how a traditional multi-window desktop might not be needed for someone who knows exactly what they are doing.
The old NetWare UI was ugly but actually the menus made it pretty obvious what you had to do most of the time.
I wonder if the author has actually used any of the stuff he mentions himself.
First PowerShell; going from 2 to 3 isn't an upgrade, its a fscking downgrade. Because Microsoft has released an incomplete product. The reasoning behind it was good: make sudden components more modular and as such allow for more differences. For example; the (excellent) help section now has options to comply with the systems UICulture. Or put in normal words: localized systems will now have the option to get localized help.
And because PowerShell 3 now keeps an online help repository it makes it really easy to distribute new updates to the help section(s) and provide new translated help sections.
Only one small problem.... Microsoft never thought about what would happen if a localized system (say nl-NL) only had the default (en-US) help section because the translations weren't available yet. Worse: they also never stopped to think if users actually wanted to get localized help or a whole environment for that matter. When using the help command I can't specify a language for example...
Resulting in, you guessed it, a totally broken PowerShell experience. The only way to fix things is to manually copy "localized directories" yourself. So copying "en-US" to "nl-NL" every time a change is done. And that's only talking about the help system, don't get me started here...
IIS8? This is Microsoft we're talking about, do you really think that they'll keep that locked into Server 2012? Give it a rest and when all the bugs have been found and removed it'll become available for other platforms as well. You see; Microsoft has realized that in order to get their IIS more out on the Internet they need to make it more appealing. One option to do this is providing free (!) versions which anyone can use, something totally unheard of some years ago.
So... Patience, it'll come.
As for the rest of the features (Hyper, iSCSI, SMB); all very good new developments I'm sure, but do those really justify a whole new server?
I wouldn't be surprised if some companies would get into 2012 because they have to (EOL of the old server) but it also wouldn't surprise me if other companies would skip this line entirely, just like they're seem to do with Windows 8. The Metro tie-in will certainly influence those kind of decisions IMO.
that when I read an article about Microsoft implementing new operating system features, in this case SMB3.0. I immediately think of gleeful hackers rubbing their hands together.
News like this should really fill IT professionals with hope and inspiration, not worry.
All it does is give the average Wintard pundit an orgasm while they scream "We're as funky as linux! Oooo OOooo look at me getting HEADless".
Kudos to M$ for giving it a try, but Powershell is Slow, very limited in functionality, very poorly documented and has very limited support by non-M$ applications.
Fix these problems and I'll gladly become a powershell user.
"... Powershell is Slow, very limited in functionality, very poorly documented and has very limited support by non-M$ applications..."
You've not actually used it, have you? Because the first three are utter rubbish and, it's increasingly supported by 3rd parties. Vmware and Symantec at the top of the list, with many others coming online, particularly with the release of 2012.
Maybe it's not the fastest to open, but the documentation is excellent, particularly the online help and the functionality is by no means limited. I run a powershell script at home which in four or five lines reads the serial port, performs some maths on the XML file it gets fed from the serial port and outputs HTML to a web server. You can pass things round as objects and format them as you choose at the point you need formatting. There are some extremely powerful technologies in powershell.
I did find some of the documentation being a little flaky moving from the good stuff in V2 to the early V3.. I suspect MS will be fixing this soon..
Definitely agree it's got a lot of power on Windows platforms.. I even stopped using Perl as my language of choice on Windows when it PS found its feet. Still use it on *NIX though.
"It makes a great storage system for heterogenous environments and a wonderful network storage point for VMware servers."
Have a Windows Server as the back end NAS for your VMWare servers? Haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha *breathe* haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha haha
And a storage system your legacy UNIX servers too - so you can have have proper filesystem ACLs via NFS 4.1 - and proper clustering / failover - DR site Replication - and data deduplication....All those bolts ons for UNIX / Linux (except dedupe - which AFAIK doesnt even exist in a Linux distribution) that are a native part of Windows Server....
"you use Windows as your web server" jokes officially end here..
Until next week..
Windows server has always be better for for Active directory, exchange and some Windows client related stuff, as you would expect of products that are inexorably tied together. however, other servers, have always beaten Windows server for pretty much everything else. Especailly IIS.
MS seems to have made some inroads into catching up. Then we can wait another 4 years while the rest of the world leaves MS in the dust again.
This doesnt seem to have changed a thing.
I started a massive virtualization project earlier in the year. I decided we would go with SCVMM and called Microsoft for pricing. I was directed to a distribution partner and given some information on existing 2008 pricing, but as of 2012 the who shebang gets integrated into a single, much higher-priced, product.
But no pricing was available. Well, maybe, but it's gonna be like $36,000. Or less. Or more. Wait, what exactly did you need?
Six flapping months. SIX MONTHS of back-and-forth between me, distributor, and Microsoft to finally find out Microsoft wants to CHARGE ME engineering time to design my already-design solution for me. I raged. I've already designed the solution, I just need a flipping SKU for the proper product so I can get a price and quote this project which is now six months old.
I called into VMWare and had SKU and retail price quote the same day. Haven't looked back.
I like Hyper-V. I'm not completely sold on 2008's way of redundancy which uses Windows Clustering (server-level) versus VMWare's way (virtual machine-level.) But, it's free and it works. But if you wanna fly, you gotta buy, if you can get the pricing.
Paris, first hits free, too.
OK, Windows needed more scriptable ways to accomplish tasks, but making GUIs just a layer above a bunch of powershell scripts just made them slow, cumbersome, and with bad error reporting - they really look now like some crappy Linux applications. Both GUIs and cmdlet should call directly the same APIs to ensure no matter who you're performing a task, the fastest and better way is used.
Win 2012 doesn't seem slow like other GUIs on top of command lines to me (NetBackup Java console, I'm looking at you) the big advantage that you get from this approach is that it is always possible to do something form the command line that it is possible to do from the GUI. Contrary to popular belief, MS have been very good at this and the last time that I can remember something that you could only do from the GUI was in the NT4 days. However this approach will make sure that absolutely everything can be done from the command line and in a more optimised manner than some of the previous registry hacking from scripts you had to do.
If you publish the same APIs through a cmdlet or GUI you can always perform the same task either way. What it is stupid is having a GUI that instead of calling the API directly calls a script engine that executes a script and then have to capture and parse output to understand what happened instead of being notified of errors by exception handling directly. It's why I always hated Oracle that does the same, often spawning a shell to invoke an executable that runs Java to invoke a Perl script.... it just make everything slower and when an error occurs usually the only way to understand what's wrong is to read tons of logs. Just publish those damned APIs, and call them directly. That's why sysadmin buys later better management applications...
>If you publish the same APIs through a cmdlet or GUI you can always perform the same task either way. What it is stupid is having a GUI that instead of calling the API directly calls a script engine that executes a script and then have to capture and parse output to understand what happened instead of being notified of errors by exception handling directly.
That aptly demonstrate how little you understand about PowerShell. Caught in your *Nix way of thinking you cannot comprehend that it can be done differently.
Unlike scripting on *Nix, a fundamental concept of PowerShell is how it can be *hosted* inside an application. Instead of stupidly formatting and parsing text as with *Nix shells, a hosted PowerShell can act directly on the host application in-memory objects.
Unlike *Nix shells, PowerShell was *designed* to create commands, functions and scripts which can be reused by a hosting application, like the Exchange admin GUI. Absolutely NO parsing is necessary. The hosting interface is rich, supports in-memory objects and may for instance operate directly on the lists of objects displayed by the application.
You cannot compare it to an application which invokes a separate process to execute command lines. The cmdlets *are* the API. The big idea that you cannot comprehend is that this way the developers only need to implement the functionality *once* as cmdlets. The GUI application may use Get-<noun> cmdlets to retrieve lists of objects, and Set/Add/Register/Install-<noun> and others to implement actions operating directly on the returned objects.
The problem is more likely to be internal to MS. They want to avoid gui tools sneaking around doing things the scripts can't. So you decree that you have to call scripts and you gain consistency at the cost of speed. For an enterprise, that's often worthwhile.