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.