Are Front-End/Back-End Servers Necessary?
Exchange 2000 is a lot smarter than I first thought. Since its folders and mailboxes are published to the Active Directory, it actually knows to look there before checking for local Exchange resources. Let me explain a lab I set up to demonstrate this, then we will dive in a little more. Here is a sample of “servers” in my lab:
In this Exchange 2000 Org, I have added mailboxes to each server. The Active Directory keeps these settings under an Exchange attribute on the Class object USER for each specific person having a mailbox. But if you look at the Exchange objects in the Users and Computers console, you see that the folders (in the default TLH) are also added into the Active Directory and are further identified by what server holds the master copy of the folder.
As you can see, this view represents specific system accounts and various public folders. When you add public folders, the related information is published in the Active Directory. Each Exchange Server in the routing group is notified of a hierarchy change and information concerning the folder structure is replicated.
In this case, I created a folder called OWATEST on Server2 and, within minutes, a folder was created on the M: drives of the two other Exchange 2000 servers.
Not only that, IIS on the other servers had begun to report the folder as well. So I now have a folder called OWATEST that is homed on Server2, but also appears to be on ServerA. This is where the magic lies; the data does not exist on ServerA, but the hierarchy does. Remember how this occurred in Exchange 5.5? The hierarchy was always replicated to the other servers. Well now in Exchange 2000 (using the default store) the servers can automatically redirect us to the appropriate server.
Here is an example of what I mean. I launched IE from the client machine, entered HTTP://SERVERA/PUBLIC/OWATEST, and hit the Enter key.
ServerA does a quick reference and sends me to the server that actually contains the data: Server2.
Cool, huh? This also works on mailboxes. By default, Exchange 2000/IIS servers will make a quick check to see which server holds the data, then the client is redirected. It does not matter how you create the folder. In this example, I created the folder using Windows Explorer. You can also create the folder with the OWA interface or custom interfaces.
The nice thing about this is that you can still have a single namespace and route folks to their mail server. Let me give you an example:
On ServerA, I added an additional IP Address of 10.10.10.50 to the NIC. Using DNS, I created a record for the a host named EXCHANGE and assigned the record to the 10.10.10.50 address.
Next, I opened the IIS console and changed the properties of the Default Web Site so that it does not use 10.10.10.50. More specifically, I told IIS only to use 10.10.10.1. Now, I could create a new web-site named Exchange on the same server and assign 10.10.10.50 to that site.
On the properties page of the new Exchange site, I instructed the site to redirect users to http://servera/exchange. There, we have now created a single name space for all email. Users need only to enter http://exchange and they will be sent directly to their mail.
Now imagine if your network looked like this:
In this scenario, you could use the same procedures for each server and allow each localized DNS server to point users to the appropriate server. In an environment with fast links, you could even consider DNS round-robin or some other way to provide DNS look-up for the server. The beauty in this is that users are always redirected to their server, which, in most cases, should be local. You will find out later that FE/BE servers will not do this for you.
|
