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.
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:
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.
