![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
liam_on_linuxI have spent a lot of time and effort this year on learning my way around the current generation of Windows Server OSs, and the end result is that I've learned that I really profoundly dislike them.
Personally, I found the server admin tools in NT 3 and 4 to be quite good, fairly clean and simple and logical - partly because it was built on LAN Manager, which was IBM-designed, with a lot of experience behind it.
Since Windows 2000 Server, the new basis, Active Directory, is very similar that of Exchange. Much of the admin revolves around things like Group Policies and a ton of proprietary extensions on top of DNS. The result is a myriad of separate management consoles, all a bit different, most of them quite limited, not really following Windows GUI guidelines because they're not true Windows apps, they're snap-ins to the limited MS Management Console. Just like Exchange Server, there are tons and tons of dialog boxes with 20 or 30 or more tabs each, and both the parent console and many of the dialogs containing trees with a dozen+ layers of hierarchy.
It's an insanely complicated mess.
The main upshot of Microsoft's attempts to make Windows Server into something that can run a large, geographically-dispersed multi-site network is that the company has successfully brought the complexity of managing an unknown Unix server to Windows.
On Unix you have an unknown but large number of text files in an unknown but large number of directories, which use a wide variety of different syntaxes, and which have a wide variety of different permissions on them. These control an unknown but large number of daemons from multiple authors and vendors which provide your servers' various services.
Your mission is to memorise all the possible daemons, their config files' names, locations and syntaxes, and use low-level editing tools from the 1960s and 1970s to manage them. The boon is that you can bring your own editors, it all is easily remotely manageable over multiple terminal sessions, and that components can in many cases be substituted one for another in a somewhat plug-and-play fashion. And if you're lucky enough to be on a FOSS Unix, there are no licensing issues.
These days, the Modern way to do this is to slap another layer of tools over the top, and use a management daemon to manage all those daemons for you, and quite possibly a monitoring daemon to check that the management daemon is doing its job, and a deployment daemon to build the boxes and install the service, management and monitoring daemons.
On Windows, it's all behind a GUI and now Windows by default has pretty good support for nestable remote GUIs. Instead of a myriad of different daemons and config files, you have little or no access to config files. You have to use an awkward and slightly broken GUI to access config settings hidden away in multiple Registry-like objects or databases or XML files, mostly you know or care not where. Instead of editing text files in your preferred editor, you must use a set of slightly-broken irritatingly-nonstandard and all-subtly-different GUIs to manipulate vast hierarchical trees of settings, many of which overlap - so settings deep in one tree will affect or override or be overridden by settings deep in another tree. Or, deep in one tree there will be a whole group of objects which you must manipulate individually, which will affect something else depending on the settings of another different group of objects elsewhere.
Occasionally, at some anonymous coder's whim, you might have to write some scripts in a proprietary language.
When you upgrade the system, the entire overall tree of trees and set of sets will change unpredictably, requiring years of testing to eliminate as many as possible of the interactions.
But at least in most installs it will all be MS tools running on MS OSs - the result of MS' monopoly over some two decades being a virtual software monoculture.
But of course often you will have downversion apps running on newer servers, or a mix of app and server OS versions, so some machines are running 2000, some 2003, some 2008 and some 2008R2, and apps could span a decade or more's worth of generations.
And these days, it's anyone's guess if the machine you're controlling is real or a VM - and depending on which hypervisor, you'll be managing the VMs with totally different proprietary toolsets.
If you do have third-party tools on the servers, they will either snap-into the MS management tools, adding a whole ton of new trees and sets to memorise your way around, or they will completely ignore it and offer a totally different GUI - typically one simplified to idiot level, such as a enterprise-level backup solution I supported in the spring which has wizards to schedule anything from backups to verifies to restores, but which contains no option anywhere to eject a tape. It appears to assume that you're using a robot library which handles that automatically.
Without a library, tape ejection from an actual drive attached to the server, required a server reboot.
But this being Windows, almost any random change to a setting anywhere might require a reboot. So, for instance, Windows Terminal Services runs on the same baseline Windows edition, meaning automatic security patch installation - meaning all users get prompted to reboot the server, although they shouldn't have privileges to actually do so, and the poor old sysadmins, probably in a building miles away or on a different continent, can't find a single time to do so when it won't inconvenience someone.
This, I believe, is progress. Yay.
After a decade of this, MS has now decided, of course, that it was wrong all along and that actually a shell and a command line is better. The snag is that it's not learned the concomitant lessons of terseness (like Unix) or of flexible abbreviation (like VMS DCL), or of cross-command standadisation and homogeneity (although to be fair, Unix never learned that, either. "Those who do not know VMS are doomed to reinvent it, poorly," perhaps.) But then, long-term MS users expect the rug to be pulled from under them every time a new generation ships, so they will probably learn that in time.
The sad thing about the proliferation of complexity in server systems, for me, is that it's all happened before, a generation or two ago, but the 20-something-year-olds building and using this stuff don't know their history. Santayana applies.
The last time around, it was Netware 4.
Netware 3 was relatively simple, clean and efficient. It couldn't do everything Netware 2 could do, but it was relatively streamlined, blisteringly fast and did what it did terribly well.
So Novell threw away all that with Netware 4, which was bigger, slower, and added a non-negotiable ton of extra complexity aimed at big corporations running dozens of servers across dozens of sites - in the form of NDS, the Netware Directory Services. Just the ticket if you are running the network the size of Enron or Lehman Brothers, but a world of pain for the poor self-taught saps running single servers of millions of small businesses. They all hated it, and consequently deserted Netware in droves. Most went to NT4; Linux wasn't really there yet in 1996.
Now, MS has done exactly the same to them.
When Windows 2000 came around, Linux was ready - but the tiny handful of actual grown-up integrated server distros (such as eSmith, later SME Server) have never really caught on. Instead, there are self-assembly kits and each sysadmin builds their own. It's how it's always been done, why change?
I had hoped that Mac OS X Server might counteract this. It looked the The Right Thing To Do: a selection of the best FOSS server apps, on a regrettably-proprietary but solid base, with some excellent simple admin tools on top, and all the config moved into nice standard network-distributable XML files.
But Apple has dropped the server ball somewhere along the line. Possibly it's not Apple's fault but the deep instinctual conservatism of network and server admins, who would tend to regard such sweeping changes with fear and loathing.
Who knows.
But the current generation of both Unix and Windows server products both look profoundly broken to me. You either need to be a demigod with the patience and deep understanding of an immortal to manage them properly, or just accept the Microsoft way: run with the defaults wherever possible and continually run around patching the worst-broken bits.
The combination of these things is one of the major drivers behind the adoption of cloud services and outsourcing. You move all the nightmare complexity out of your company and your utter dependence on a couple of highly-paid god-geeks, and parcel it off to big specialists with redundant arrays of highly-paid god-geeks. You lose control and real understanding of what's occurring and replace it with SLAs and trust.
Unless or until someone comes along and fixes the FOSS servers, this isn't going to change - it's just going to continue.
Which is why I don't really want to be a techie any more. I'm tired of watching it just spiral downwards into greater and greater complexity.
(Aside: of course, nothing is new under the sun. It was, I believe, my late friend Guy Kewney who made a very plangent comment about this same process when WordPerfect 5 came out. "With WordPerfect 4.2, we've made a good bicycle. Everyone knows it, everyone likes it, everyone says it's a good bicycle. So what we'll do is, we'll put seven more wheels on it."
In time, of course, everyone looked back at WordPerfect 5.1 with great fondness, compared to the Windows version. In time, I'm sure, people will look back at the relative homogeneity of Windows 2003 Server or something with fondness, too. It seems inevitable. I mean, a direct Win32 admin app running on the same machine at the processes it's managing is bound to be smaller, simpler and faster than a decade-older Win64 app running on a remote host...)
Personally, I found the server admin tools in NT 3 and 4 to be quite good, fairly clean and simple and logical - partly because it was built on LAN Manager, which was IBM-designed, with a lot of experience behind it.
Since Windows 2000 Server, the new basis, Active Directory, is very similar that of Exchange. Much of the admin revolves around things like Group Policies and a ton of proprietary extensions on top of DNS. The result is a myriad of separate management consoles, all a bit different, most of them quite limited, not really following Windows GUI guidelines because they're not true Windows apps, they're snap-ins to the limited MS Management Console. Just like Exchange Server, there are tons and tons of dialog boxes with 20 or 30 or more tabs each, and both the parent console and many of the dialogs containing trees with a dozen+ layers of hierarchy.
It's an insanely complicated mess.
The main upshot of Microsoft's attempts to make Windows Server into something that can run a large, geographically-dispersed multi-site network is that the company has successfully brought the complexity of managing an unknown Unix server to Windows.
On Unix you have an unknown but large number of text files in an unknown but large number of directories, which use a wide variety of different syntaxes, and which have a wide variety of different permissions on them. These control an unknown but large number of daemons from multiple authors and vendors which provide your servers' various services.
Your mission is to memorise all the possible daemons, their config files' names, locations and syntaxes, and use low-level editing tools from the 1960s and 1970s to manage them. The boon is that you can bring your own editors, it all is easily remotely manageable over multiple terminal sessions, and that components can in many cases be substituted one for another in a somewhat plug-and-play fashion. And if you're lucky enough to be on a FOSS Unix, there are no licensing issues.
These days, the Modern way to do this is to slap another layer of tools over the top, and use a management daemon to manage all those daemons for you, and quite possibly a monitoring daemon to check that the management daemon is doing its job, and a deployment daemon to build the boxes and install the service, management and monitoring daemons.
On Windows, it's all behind a GUI and now Windows by default has pretty good support for nestable remote GUIs. Instead of a myriad of different daemons and config files, you have little or no access to config files. You have to use an awkward and slightly broken GUI to access config settings hidden away in multiple Registry-like objects or databases or XML files, mostly you know or care not where. Instead of editing text files in your preferred editor, you must use a set of slightly-broken irritatingly-nonstandard and all-subtly-different GUIs to manipulate vast hierarchical trees of settings, many of which overlap - so settings deep in one tree will affect or override or be overridden by settings deep in another tree. Or, deep in one tree there will be a whole group of objects which you must manipulate individually, which will affect something else depending on the settings of another different group of objects elsewhere.
Occasionally, at some anonymous coder's whim, you might have to write some scripts in a proprietary language.
When you upgrade the system, the entire overall tree of trees and set of sets will change unpredictably, requiring years of testing to eliminate as many as possible of the interactions.
But at least in most installs it will all be MS tools running on MS OSs - the result of MS' monopoly over some two decades being a virtual software monoculture.
But of course often you will have downversion apps running on newer servers, or a mix of app and server OS versions, so some machines are running 2000, some 2003, some 2008 and some 2008R2, and apps could span a decade or more's worth of generations.
And these days, it's anyone's guess if the machine you're controlling is real or a VM - and depending on which hypervisor, you'll be managing the VMs with totally different proprietary toolsets.
If you do have third-party tools on the servers, they will either snap-into the MS management tools, adding a whole ton of new trees and sets to memorise your way around, or they will completely ignore it and offer a totally different GUI - typically one simplified to idiot level, such as a enterprise-level backup solution I supported in the spring which has wizards to schedule anything from backups to verifies to restores, but which contains no option anywhere to eject a tape. It appears to assume that you're using a robot library which handles that automatically.
Without a library, tape ejection from an actual drive attached to the server, required a server reboot.
But this being Windows, almost any random change to a setting anywhere might require a reboot. So, for instance, Windows Terminal Services runs on the same baseline Windows edition, meaning automatic security patch installation - meaning all users get prompted to reboot the server, although they shouldn't have privileges to actually do so, and the poor old sysadmins, probably in a building miles away or on a different continent, can't find a single time to do so when it won't inconvenience someone.
This, I believe, is progress. Yay.
After a decade of this, MS has now decided, of course, that it was wrong all along and that actually a shell and a command line is better. The snag is that it's not learned the concomitant lessons of terseness (like Unix) or of flexible abbreviation (like VMS DCL), or of cross-command standadisation and homogeneity (although to be fair, Unix never learned that, either. "Those who do not know VMS are doomed to reinvent it, poorly," perhaps.) But then, long-term MS users expect the rug to be pulled from under them every time a new generation ships, so they will probably learn that in time.
The sad thing about the proliferation of complexity in server systems, for me, is that it's all happened before, a generation or two ago, but the 20-something-year-olds building and using this stuff don't know their history. Santayana applies.
The last time around, it was Netware 4.
Netware 3 was relatively simple, clean and efficient. It couldn't do everything Netware 2 could do, but it was relatively streamlined, blisteringly fast and did what it did terribly well.
So Novell threw away all that with Netware 4, which was bigger, slower, and added a non-negotiable ton of extra complexity aimed at big corporations running dozens of servers across dozens of sites - in the form of NDS, the Netware Directory Services. Just the ticket if you are running the network the size of Enron or Lehman Brothers, but a world of pain for the poor self-taught saps running single servers of millions of small businesses. They all hated it, and consequently deserted Netware in droves. Most went to NT4; Linux wasn't really there yet in 1996.
Now, MS has done exactly the same to them.
When Windows 2000 came around, Linux was ready - but the tiny handful of actual grown-up integrated server distros (such as eSmith, later SME Server) have never really caught on. Instead, there are self-assembly kits and each sysadmin builds their own. It's how it's always been done, why change?
I had hoped that Mac OS X Server might counteract this. It looked the The Right Thing To Do: a selection of the best FOSS server apps, on a regrettably-proprietary but solid base, with some excellent simple admin tools on top, and all the config moved into nice standard network-distributable XML files.
But Apple has dropped the server ball somewhere along the line. Possibly it's not Apple's fault but the deep instinctual conservatism of network and server admins, who would tend to regard such sweeping changes with fear and loathing.
Who knows.
But the current generation of both Unix and Windows server products both look profoundly broken to me. You either need to be a demigod with the patience and deep understanding of an immortal to manage them properly, or just accept the Microsoft way: run with the defaults wherever possible and continually run around patching the worst-broken bits.
The combination of these things is one of the major drivers behind the adoption of cloud services and outsourcing. You move all the nightmare complexity out of your company and your utter dependence on a couple of highly-paid god-geeks, and parcel it off to big specialists with redundant arrays of highly-paid god-geeks. You lose control and real understanding of what's occurring and replace it with SLAs and trust.
Unless or until someone comes along and fixes the FOSS servers, this isn't going to change - it's just going to continue.
Which is why I don't really want to be a techie any more. I'm tired of watching it just spiral downwards into greater and greater complexity.
(Aside: of course, nothing is new under the sun. It was, I believe, my late friend Guy Kewney who made a very plangent comment about this same process when WordPerfect 5 came out. "With WordPerfect 4.2, we've made a good bicycle. Everyone knows it, everyone likes it, everyone says it's a good bicycle. So what we'll do is, we'll put seven more wheels on it."
In time, of course, everyone looked back at WordPerfect 5.1 with great fondness, compared to the Windows version. In time, I'm sure, people will look back at the relative homogeneity of Windows 2003 Server or something with fondness, too. It seems inevitable. I mean, a direct Win32 admin app running on the same machine at the processes it's managing is bound to be smaller, simpler and faster than a decade-older Win64 app running on a remote host...)
