Microsoft Server Products are bad for business!

I have been using various Windows Server platforms for a good decade now. I’m not a MCSE, but I know my way fairly well around Windows 2000 and 2003. Yet I’ve never been able to completely shed the feeling of looking for a needle in a haystack when something goes seriously wrong and Windows gives an error message such as: “Error code 00000050, parameter1 a04bd7e8, parameter2 00000000, parameter3 8089c425, parameter4 00000000” in the System Log as the reason for mysterious, repeated reboots. Perhaps if I were a MCSE I would know how to go about debugging such a problem in a more methodical fashion than the “shot-in-the-dark-debugging” I often have to employ in such situations, and thus reach a conclusion (and a fix) in a reasonable amount of time. But maybe it would take just as much effort, MCSE or not; the Windows Server products keep the administrator at an arm’s length when it comes to divulging their inner workings, or at least they seem to run any diagnostic information through an obsfuscator of some kind. Oftentimes having a good reference library and good web mining skills aren’t enough and the only remaining option is to contact the support – which costs money.

Microsoft also often recommends against running various functions (mail, database, directory controller to name a few) on a single server, no matter how small the environment. Domain Controller should have its own box. So should SQL Server, and (of course) Exchange. And the web server often doesn’t run well in a box with any of the above. Naturally you need an operating system license for all of the servers with dedicated functionality. A SQL Server license costs about $6,000 (per CPU). Exchange starts from about $1,100 for five users, etc. Why does anyone want to pay such high prices when better (more powerful, simpler to maintain) options exist? Support! But if you chose an open source alternative (such as, for example, FreeBSD or Linux for the operating system, MySQL for database, Apache for web server, Postfix for mail server…) you wouldn’t need support nearly as often, assuming you have an equally competent administrator for both environments.

My latest harrowing experience with Microsoft Server products was with Exchange 2003 Standard. I was faced with a server reinstall. The server is also a DC, and realizing the potential unexpected interactions between the various components I did a fair amount of research before starting the reinstall. Alas, this did not help. Exchange’s web access bombed completely even though the install was technically “clean” and the different components were carefully installed in the recommended order, and patched to the current patch levels.

I ended up blowing OWA2003 away, redirecting webmail to a FreeBSD server, and setting up Squirrelmail via IMAP to Exchange which worked right off the bat without any messy configuration issues with ASP.NET accounts. And the users have a more versatile web-mail interface than what OWA2003 would’ve offered.

As a result of this experience I’ve decided to move the LAN in question away from Exchange — into Postfix on FreeBSD. And yes, the same UNIX server will also handle intranet web, MySQL databases and external domain DNS services (for DNS there will be a secondary elsewhere) with little effort. It also says something about Exchange that the lengthy list of Postfix’s configuration parameters feels very straightforward when compared to Exchange’s configuration (having used both products now for several years). Postfix’s numerous configuration options give a very fine-grained control over how the MTA should function. If something goes wrong, Postfix (and Dovecot which I’ll use for IMAP/POP interface) tells you what’s wrong. And should I be totally stumped, Postfix’s excellent support community (mailing list) provides almost instantaneous solutions to even the most complex questions.

It is quite apparent that Microsoft is targeting Exchange primarily to large corporations considering that the production version of Exchange 2007 only runs on 64-bit Windows servers. Such organizations can also afford to throw money around for “Exchange administrators” whose whole job is to maintain the mail server. Perhaps it’s not wasted money, large organizations often have complex enough mail systems so that dedicated individuals or even teams are necessary. But when implementing Exchange in a smaller environment—except for perhaps the wizard-driven SMB-version (which keeps the admins at broomstick’s length away)—the heavier demand for Exchange management is still there even though the mail volume is lower. Small and medium-size organizations can save incredible amounts of money in license fees and in hardware investments simply by choosing Open Source software that will do the job in most cases much better than Microsoft’s Server Products. I would venture to say that Postfix, for example, offers more detailed control over how the mail is processed than Exchange while at the same time offering lower management complexity, a lot more power, and less need for ongoing maintenance.

Going forward, I will be recommending a mixed solution for the SMBs: Windows desktops (XP, for now) with Windows domain to centralize logins and to facilitate file sharing. That takes two Windows servers for most SMB LAN environments (one generally suffices performance-wise, but a second system is recommended for AD backup and it also functions as a backup server in case the primary server fails. For mail, database, ftp, LDAP, external DNS, and web, however, I’m recommending UNIX servers. My personal preference is FreeBSD, but Linux will work just as well. Again, perhaps two servers which can share and mirror operations under normal circumstances and function as backup for each other in event of a hardware failure. Total of four boxes (or two if cost is a concern and an outage stemming from a system failure isn’t devastating to the business) configured as described will create a very versatile system with a high degree of stability.

I end this post with two, somewhat connected observations: First, externalizing spam filtering is a good idea. Katharion provides excellent functionality, and around the end of the year they will also include webmail access to users’ email which is cached for thirty days. This doubles as a backup mail service for internal SMB mail servers. I’ll write more about Katharion in a future post.

Second, it may be time to ditch Outlook as well. Why doesn’t Outlook 2007 provide secure IMAP connections?! If team calendaring is not needed, Thunderbird looks like a much better choice (and even if calendaring and contacts are needed, they can be implemented with other available products).

Edit: Outlook 2007 does offer TLS for IMAP connections (Tools > Account Settings > [select profile] > Change > More Settings > Advanced > Use the following type of encrypted connection: [None/SSL/TLS/Auto]).  Unfortunately, Thunderbird continues to have a number of issues, not least of which is the somewhat clumsy and aged-looking GUI which makes the program less flexible and comfortable to use than Outlook. Outlook’s superiority isn’t completely unexpected: while I maintain that Microsoft Server Products are overpriced, underperforming resource-hungry bloatware, I also recognize that their desktop software is pretty good (excluding Vista.. I really hope they get it right with Windows 7). The Office Suite is very well designed, and VisualStudio is a stellar development tool. Now if MS fixed the HTML rendering problem in Outlook 2007…

To recap: Windows for the desktop, domain controller (obviously), and for Windows LAN file sharing. UNIX for mail, database, web, DNS and other applications requiring good performance, configurability and security on the internet.

2 thoughts on “Microsoft Server Products are bad for business!”

  1. Excellent information. It’s refreshing to find someone who looks at the issues rather than the brand name when choosing software. I simplify further, to “Windows for the desktop, UNIX/Linux for servers” and I use samba for file sharing. You didn’t mention what your experience of samba has been, and I’d welcome your take on it.

  2. I haven’t used Samba much.. yet. But interestingly I just installed Samba for the purposes of the setup I wrote about in this article. File sharing tends to be fairly stable on Windows (besides the inherent “need” for Windows to be rebooted at least every couple of weeks – fortunately Microsoft security updates take care of that. 😉 But moving any feature away from Windows server platform is a welcome one. Unfortunately there doesn’t seem to be a viable alternative for ActiveDirectory when a Windows LAN is configured to use a Windows domain. What makes the situation doubly frustrating is the fact that ActiveDirectory is “Microsoft’s implementation” of LDAP, and probably strategically Microsoft has prevented ActiveDirectory information from being replicated, say, to OpenLDAP. Thus if users on Windows LAN also need to access UNIX-based resources, the UNIX services must authenticate against the ActiveDirectory! 🙁 There are some solutions (which come at cost) like Symark’s powerADvantage product that externalizes the login data from ActiveDirectory — but I’m not sure whether powerADvantage has the functionality to replicate the logins, either (which means the logins for the whole network would still need to live on Windows platform only). More on this (as well as on Samba) later!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.