Valerio Di Giampietro

Personal Web Site

Microsoft Exchange: complex and dangerous by design

I am not a fan of Microsoft products, I don’t like their complexity and the “dangerous by design” philosophy; recently I switched company and I am involved in implementing a data center for a public institution based primary on Microsoft Technology. One of this product is Microsoft Exchange; after many years of Unix System Management experience I didn’t believe how flawed Exchange was until I red by myself the official Microsoft Exchange documentation (Microsoft Exchange Server 2003 Resource Kit).
Some items that really surprised me are the followings:

  • to make some configuration change the book suggest to modify the registry, but it makes a big warning:
    Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved.
    How can a system be designed to be so easy destroyed by e simple configuration change error? I have never seen before a configuration change that can destroy an entire system!
  • for other configuration changes the book recommend using ADSI Edit (Active Directory Service Interfaces) but, again, a big warning is clearly printed:
    If you use the ADSI Edit snap-in and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Windows 2003, or the entire Active Directory forest.
    Oh Oh! ADSI Edit seems more powerful than a nuclear weapon! What really worries me is that if someone has been able to design a system so flawed in these simple issues than many other dangerous flaws will be hidden everywhere in the system!
  • anyway Exchange seems a very complete and powerful system able to manage a very huge number of mailboxes. You can divide the Exchange installation among many servers, like front-end servers and back-end servers. You would expect to put front-end servers on your DMZ network, but wait! the official Microsoft documentation says:
    Given that the Exchange servers are domain members and require considerable connectivity to various domain services, it is not a recommended practice to place Exchange servers in the perimeter network.
    Thank you Microsoft!, you recognize that Exchange is so flawed that it is better to use a Linux server directly exposed to Internet!
    The problem is that the “Front End” servers need to communicate with Active Directory (using many ports) and with “Back End” servers, using RPC and dynamically assigned ports; this means that you cannot have a firewall in between (or you need to open almost everything on the firewall between the DMZ network and your LAN).
    To be honest Microsoft has a solution to this issues, you just need to increase exponentially your configuration complexity adding a new Active Directory forest in the perimeter network!
  • Given this kind of complexity, Microsoft recommend to setup a test environment. You could think to setup Microsoft Exchange, Active Directory and a mail client on the same machine. But wait! may be you have done something similar on Unix 30 years ago, but Microsoft is a different beast and official documentation gives these nice suggestions:
    • installing Exchange 2003 directly on the domain controller running Active Directory works under almost all circumstances, for this reason Microsoft recommend implementing a separate server for Active Directory. Microsoft knows better than us what the phrase under almost all circumstances really means!
    • the book anticipate your thoughts and warns you: you might be tempted to install Outlook 2003 directly on the test server to eliminate the requirement for an extra workstation, but you should not do so because this results in an unsupported configuration. Why? the MAPI subsystem that is installed with Exchange 2003 differs from the MAPI subsystem that is included in Outlook. The problem seems that they have used the same name for a DLL file and the same function names in Exchange 2003 and in Outlook, but with totally different meanings: an “apple” or a “pear” in Exchange 2003 is a totally different fruit in Outlook, but the names are the same! Microsoft seems to not have learned yet that same name, in every environment, must have same meaning

I would be able to continue with other examples, but I think this is enough to understand complexity and unreliability of Microsoft Exchange, but what really surprise me is that many companies (including my current client) is using it and spending a huge amount of money in licensing and in paying peoples like me to implement this software.

Leave a Reply

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