1.5 Some things that Microsoft still has to do

---

Exchange is a great messaging platform with lots of wonderful features. Its management infrastructure continues to improve, and you can connect Exchange to almost any other messaging system on the planet. On the face of it, it does not sound as if Microsoft has a lot more work to do with Exchange. Of course, we know that Microsoft wants to bring Exchange into a new generation and use a common storage engine, so there is plenty of engineering work on the horizon, but there are still a few things that Microsoft might have addressed in Exchange 2003.

1.5.1 Administrative flexibility

Most complaints center on administrative flexibility. Exchange began with a directory that forced administrative rigidity insofar as you could not easily change the shape of an organization after you installed servers, because server objects included organizational detail in their directory names. It was not until 1998 that Microsoft produced the Move Server Wizard to allow administrators to move a server from one site to another within an organization or to another organization. Even with the tool, the process was long and arduous and often as attractive as performing do-it-yourself brain surgery. Great hopes focused on Exchange 2000, when the Active Directory promised to liberate Exchange from the chains imposed by its own directory. Unhappily, while the situation is better, some gaps still exist. For example:

• Windows 2003 supports domain renaming, but you should not attempt to rename a domain (yet) if Exchange 2000 or 2003 servers are present. Microsoft plans to address this problem in the near future.

• You cannot move servers between domains within the same forest, so you have to decommission and then reinstall the server in the desired location.

• You cannot move servers between Exchange organizations. This implies a move between forests, because you can only have one Exchange organization per forest, which is in turn a further restriction on administrative flexibility.

• You cannot move servers between administrative groups.

Many of these restrictions exist because of the close dependency between Exchange and AD. For example, if you were able to drag and drop a server from one administrative group to another, the AD would then have to replicate the new organizational structure to every DC in the forest. If replication fails, then some servers will not have knowledge of the current organizational structure and may not be able to route email if a bridgehead server or a connector was involved in the move. If you have the right administrative permissions, you can drag and drop a server from one routing group to another, so it seems as if similar operations exist within Exchange.

Being able to drag and drop objects to change organizational structure is a nice user experience. However, you can imagine the possible replication complexity that results from a series of moves where an administrator first moves a server to one administrative group, realizes that was a mistake, and then moves the server to the place the administrator really wanted it to go. Scenarios such as this make Microsoft reluctant to implement any form of movement unless it is happy that it can perform the operations without affecting the overall stability of the messaging system.

1.5.2 Collaboration

Microsoft has always wanted to make Exchange a platform for collaboration, but while it has been very willing, it has have also been terribly unsuccessful. The original play was on public folders, when Microsoft promised that you could accomplish great things by linking public folder storage with intelligent electronic forms. Public folders certainly store items, but the electronic forms never quite lived up to the promise of intelligence, and the original vision faded rapidly. Public folders have since become the great dumping ground for Exchange data. They can be useful, but do not expect to accomplish more than you can with a well-managed network file share. We return to the topic of public folders in Chapter 7.

Frustrated by the failure of public folders and driven by an intense need to be competitive with the Lotus Notes collaboration platform, Microsoft has launched many other collaboration initiatives around Exchange, including attempts to make Exchange a platform for workflow and intelligent document routing. It is fair to say that implementers greeted each initiative with less enthusiasm, leading us to a situation where the advent of the Instant Messaging and Conferencing Server add-on products for Exchange 2000 sank without trace very quickly.

Thankfully, Microsoft seems to have concluded that Exchange is great at messaging and awful at collaboration, so it should focus on maximizing the strengths and leave collaboration to other products, such as its SharePoint technologies, which it may integrate with Exchange in the future. Hopefully, we will see public folders fade away into history and Microsoft will replace them with something more functional, more flexible, and more powerful-perhaps in Kodiak. Given the focus on SharePoint technology, it would not be a surprise to see Microsoft move in that direction as a replacement for public folders. Of course, focusing on messaging is a double-edged sword, because there are many alternative email servers available today. If Exchange is "just" an email server, why would you not move to another platform instead of upgrading to Exchange 2003 (or even more to the point, from Exchange 5.5 to Exchange 2000)? The answer is that it is still easier to move within technology generations than from one technology to another and the way that Outlook 2003 and Exchange 2003 now work more intelligently with each other makes the combination the best on the market.

1.5.3 Application development

How many APIs can a single product support? The answer is unclear, but Microsoft has certainly given Exchange every chance to lead in this category. Beginning with MAPI (several variants, including Simple MAPI and Common Messaging Calls), going on through interfaces such as Exchange Routing Objects, OLE/DB, several variations of CDO including CDOEXM (and not forgetting Outlook's programming model), and associations with Windows-driven APIs such as ADSI and ADO, life for an Exchange developer is a veritable alphabet soup. The problem here is simple. Given Microsoft's past record of introducing APIs and then moving on, what interface should a developer use to build code? MAPI is the only interface that has truly persisted from day one of Exchange.

Perhaps some relief is on the horizon. The advent of Microsoft .NET and the focus on XML and SOAP as the preferred mechanisms for general data interchange within the .NET framework mean that Exchange has to support XML and SOAP, especially with an eye on Kodiak. The result is that we see the introduction of Exchange Server Objects (XSO) in Exchange 2003 to support SOAP access to Exchange functions.

1.5.4 Too many servers

Another issue that Microsoft has to address is the apparent support inside its development groups for the "one server, one application" approach to life. In the Windows NT 3.51 era, when hardware was much slower than today, this attitude was understandable, but it is hard to comprehend today. For example, in 1996 the first deployments of Exchange proceeded on 100MHz servers equipped with 128 MB of memory and 4 GB of disk. These servers supported 250 to 400 mailboxes, and administrators did not rush to install anything else on the computer. Hardware improved over time, and so did the operating system, yet the almost subconscious idea lingered that you could only run one server application per physical computer. Microsoft has not helped by engineering server applications that cannot coexist, such as SharePoint Portal Server 2001 and Exchange 2000, but at least we now see initiatives such as server virtualization and partitioning becoming more common. The servers of today are far more powerful than the mainframes of even the recent past, so it is unacceptable to discover that you need multiple servers to run all the applications you need. The result is that everyone seems to deploy too many Windows servers, which drives up cost, administrative complexity, and even licensing fees when you deploy additional servers to manage and protect the extra servers. Microsoft needs to architect products to coexist together and then develop solid development and testing procedures to force this to happen. After all, if the world's biggest software development company cannot do this, who can?

1.5.5 Security

Securing Exchange is perhaps the area of biggest administrative change in the product's lifetime. Administrators used to worry only about file-level viruses that could infect their servers through floppy disks or network shares. Now, it is a constant battle against email viruses, hacker attacks, IIS meltdowns, spam, and all the other problems that seem to occur in an increasingly virulent world. Microsoft has improved Exchange 2003's capabilities so that the server can better filter incoming messages, protect distribution lists, and accommodate antivirus software, but this area is going to remain a challenge for both Microsoft and system administrators. The bad guys keep on getting smarter and the good guys have to run to keep up.

---