Exchange Server 2007 as a ClientServer System

Exchange Server 2007 as a Client/Server System

The technology industry has overused the term client/server to the point that it is almost meaning-less. To put it simply, there are two kinds of networked applications: shared-file and client/server. The typical Exchange and Outlook deployment is a client-server messaging system and always has been. However for people just getting involved in Exchange Server deployments, these concepts should be reviewed.

Shared-File Applications

Early networked applications were all based on shared-file systems. The network shell that let you load your word processor from a network server and also allowed you to read from and write to files stored on a server. At the time, this was the easiest and most natural way to grow networked applications.

Microsoft's first e-mail product, Mail for PC Networks, was a shared-file application. You run a Windows, OS/2, DOS, or Macintosh client application, which sends and receives messages by accessing files on a Microsoft Mail for PC Networks post office that resides on a network file server. The front-end application and your PC do all the work; the server is passive. Figure 2.10 shows a typical Microsoft Mail for PC Networks setup.

Figure 2.10: Microsoft Mail for PC Networks is a typical shared-file electronic messaging system.

Easy as it was to develop, this architecture leads to some serious problems in today's networked computing world:

• Changing the underlying structure of the server file system is difficult because you have to change both the server and the client.

• System security is always compromised because users must have read and write permissions for the whole server file system, which includes all other users' message files. Things are so bad that in some cases a naive or malicious user can actually destroy shared-file system databases.

• Network traffic is high because the client application must constantly access indexes and hunt around the server's file system for user messages.

• Because the user workstation writes directly to shared files, the server-based files can be destroyed if workstation hardware or software stops functioning for some unexpected reason.

• Often the client program would open these shared files and lock them for use. This frequently prevented important data files from being backed up.

Shared-file applications are in decline. Sure, plenty of legacy (that is, out-of-date) applications will probably live on for the data-processing equivalent of eternity, but client/server systems have quickly supplanted the shared-file model. This is especially true in the world of electronic messaging.

Client/Server Applications

Though they have some limitations of their own, client/server applications overcome the shortcomings of shared-file apps. So today, networked applications increasingly are based on the client/server model. The server is an active partner in client/server applications. Clients tell servers what they want done, and if security requirements are met, servers do what they are asked.

Processes running on a server find and ship data to processes running on a client. When a client process sends data, a server receives it and writes it to server-based files. Server processes can do more than simply interact with client processes. For example, they can compact data files on the server or - as they do on Exchange Server - automatically reply to incoming messages to let people know, for instance, that you're going to be out of the office for a period of time. Figure 2.11 shows how Exchange implements the client/server model.

Figure 2.11: Microsoft Exchange is based on the client/server model.

Client/server applications are strong in all the areas in which shared-file apps are weak:

• Changing the underlying structure of the server file system is easier than with shared-file systems because only the server processes access the file system.

• System security can be much tighter, again because only the server processes access the file system.

• Network traffic is lighter because all the work of file access is done by the server, on the server.

• Because server processes are the only ones that access server data, breakdowns of user workstation hardware or software are less likely to spoil data. With appropriate transaction logging features, client/server systems can even protect against server hardware or software malfunctions.

As good as the client/server model is, it does have some general drawbacks. Client/server apps require more computing horsepower, especially on the server side. With Exchange, you should plan to start with very fast Pentium or better machines, lots of RAM, and plenty of hard disk and tape backup capacity - and expect to grow from there.

Client/server applications are more complex than shared-file apps. This is partly because of the nature of the client/server model and partly because of the tendency of client/server apps to be newer and thus filled with all kinds of great capabilities that you won't find in shared-file applications. Generally, you're safe in assuming that you'll need to devote more and more sophisticated human resources to managing a client/server application than to tending to a similar one based on shared files.

The good news is that Microsoft has done a lot to reduce the management load and to make it easier for someone who isn't a computer scientist to administer an Exchange system. I've looked at many client/server messaging systems, and I can say without any doubt that Exchange is absolutely the easiest to administer, even in its slightly more complex 2007 implementation. Exchange Server 2007 includes both a graphical user interface and a management shell that organizes the processes of management very nicely. With these interfaces, you can do everything from adding users to assessing the health of your messaging system.