Exchange 2003 - Disaster Recovery Analyzer Tool (ExDRA 1.0)

Let's begin

The Exchange Server Disaster Recovery Analyzer collects configuration data and header information from your Exchange databases and transaction log files. ExDRA analyzes all database headers and creates a list of problems with your database and how to resolve problems with your Exchange databases.

ExDRA requirements

Component	Requirement
Operating system	Microsoft Windows 2000 Professional, Windows XP, Windows 2000 Server family, or Windows Server 2003 family required; Windows XP recommended
Computer and processor	Personal computer with 133-megahertz (MHz) or higher processor; 1.0-gigahertz (GHz) or higher processor recommended. Dual processors for topologies with more than 100 Exchange servers are recommended
Memory	256 megabytes (MB) of RAM required; 256 megabytes (MB) for every 50 Exchange servers in the topology recommended
Hard disk	10 MB of available hard disk space for tool installation; 2 MB of free space per server, per scan required for the data output
Display	VGA or higher-resolution monitor
Input device	Mouse or compatible input device
Messaging system	Mixed-mode or native-mode Exchange Server 2003, Exchange 2000 Server, and Exchange Server 5.5 system; Exchange Server 2003 recommended. Note: Pure Exchange Server 5.5 topologies are not supported
Dependencies	Microsoft .NET Framework 1.1 IIS Common Files

Download and installation

You can download ExDRA from here. After downloading you must install the package. Installation is easy. Simply follow the installation instructions.

Using ExDRA

Before you can use ExDRA you have to dismount the concerned Exchange Information Store if it is not already down under other circumstances.

If you want to check for ExDRA updates on every startup, select the option Check for updates on startup. Next clickGo to the Welcome screen and start the wizard.

Figure 1: ExDRA start screen

The Exchange Server Disaster Recovery Analyzer Tool scans your dismounted Exchange databases and transaction logfiles for shutdown reason and other problems. ExDRA is supported for Exchange Server 2000 Service Pack 3 and later and Exchange Server 2003.

Figure 2: ExDRA Welcome screen

Select Auto Detect to let ExDRA discover available databases and transaction logfiles in their default location on Exchange Server (C:\program filesexchsrvrmdbdata).

Select Manual Input (Advanced) to manually enter the path to the databases and transaction logfiles.

Figure 3: Select Auto Detect or Manual Input for examining the database location

Enter the Exchange Server Name (in this example LONDON) and as an optional component the name of a Domain Controller. If your currently logged on account doesn't have enough permissions to read the Exchange Server configuration, you can specify an account with proper permissions.

Figure 4: Enter Server and User Information

If your Exchange Server has multiple Storage Groups, you must select the Storage Group where the Exchange database to be checked is located.

Figure 5: Select the Exchange Storage Group

Next you must select the Exchange Server database to be analyzed. Only dismounted databases can be selected.

Figure 6: Select the Exchange Server database to be analyzed

It could take a while for ExDRA to inspect the selected database and transaction logfiles.

Figure 7: Take a short break until ExDRA has checked the database and transaction logfiles

The following page shows the analysis results of the ExDRA check. Because I only dismounted the Exchange database, ExDRA stated that the Database is in a Clean ShutDown state. There is some additional information to handle if you are unable to mount a database, even if the database is in a Clean Shutdown state.

Figure 8: ExDRA analysis results

After you clicked Next ExDRA will display some very useful information about the database like Log- and DB-Signatures and many more.

Figure 9: Detailed information about the database state

Now let's make the work a little bit harder for ExDRA. For the following example I dismounted the Exchange database named Crashtest and deleted the associated STM database file.

Figure 10: Select the Crashtest database

After some Database and transaction logfile processing ExDRA tells us that it could not find the Crashtest.stm file and shows us some possible solutions to locate a copy of the STM file if it is lost or to run Eseutil.

Figure 11: Detailed information about the database state

On the following page you can select a report to view Exchange Server Disaster Recovery Analyzer results.

Figure 12: exDRA Reports page

Conclusion

ExDRA 1.0 is the first version and has alot of potential to be a single place for administrators for disaster recovery purposes. The Exchange team plans to use ExDRA as an all in one place where an Administrator can handle disaster recovery, from recovery storage group management through to actually getting mailboxes back online.

Dual or Pass-Through Authentication in an Exchange 2003 Front-End/Back-End Setup

Introduction

When using Exchange Server 2003 in a front-end/back-end (FE/BE) setup you have to make some important decisions as regards to Outlook Web Access (OWA) user authentication. One is whether or not you’re going to make use of forms-based authentication. As many of you already know forms-based authentication (cookie authentication) provides several benefits, such as an OWA logon page where you can select between using a Private or Public computer (each having their own cookie timeout), as well as whether you want to use the premium (rich) or basic (reach) OWA version (see Figure 1 below).

Figure 1: Exchange 2003 Forms-based Authentication

If you choose not to use forms-based authentication you can still have the FE server authenticate the OWA users (dual authentication), instead of forwarding the authentication requests to the BE servers (pass-through authentication) in the organization.

Figure 2: Dual Authentication in an FE/BE Setup

No matter which method you choose the BE servers will always be involved in authenticating the users. Microsoft recommends you use dual authentication meaning that both the FE and BE servers authenticate the users. And this makes sense since users this way won’t be allowed access to the BE servers, unless they already have authenticated themselves to a FE server. If you choose to implement dual authentication you must enable basic authentication both on the FE and BE servers, but only if the FE server is located on the perimeter network (aka DMZ, demilitarized zone or screened subnet). If they are located on your internal network this isn’t necessary.

Note:If you don’t use dual authentication, implicit logons will not work. This means that any user will need to specify the full URL including their user name to log on to their mailbox. Explicit logons will work no matter which type of authentication method is chosen. Another disadvantage of using pass-through authentication is that public folder requests cannot be load-balanced.

If the front-end server is located on a perimeter network and you don’t allow RPC traffic from your perimeter network to travel through your intranet firewall, you are forced to forward the authentication requests directly to your BE servers (pass-through authentication). Needless to say you should only use pass-through authentication if you don’t have the choice of using dual authentication. As it’s considered more secure to allow RPC traffic through your intranet firewall then it is to allow anonymous requests to go directly to the BE servers, you should - if your security policy doesn’t allow RPC through the intranet firewall from the perimeter network - re-evaluate them.

Figure 3: Pass-Through Authentication in an FE/BE Setup

Note:It’s not recommended to place your FE Servers on a perimeter network; you should instead place any it on the internal network, and if possible publish the required Exchange services trough an ISA Server located on the perimeter network. In the past, it was popular to place the FE server on the perimeter network, and then open all required ports in the intranet firewall. Since the FE server needed to be able to communicate with both the Exchange BE servers as well as Global Catalog servers on the internal network, quite a few ports needed to be allowed through. I know an alternative is to configure IPSec, but this solution is a bit complex. Even though you may not have an ISA Server in your organization, you still should place the FE server on the internal network, and then open the required ports on the intranet firewall.

Another important thing worth noting is that client authentication by FE servers only supports the Basic authentication method. This is also true between FE and BE servers. It’s, therefore, absolutely mandatory to use SSL encryption between the clients and the FE server. If not, anybody with a sniffer utility attached to your Internet firewall could sit and watch the content of your inbound/outbound e-mail messages sent via the OWA client. The intruder could also see any usernames and password sent between the client and the FE server.

Configuring Dual Authentication

In order to use Dual authentication, you will need to enable Basic authentication on the FE server. The below, step by step instructions, will show you how to enable this authentication method.

1. Open the Exchange System Manager
2. Drill down to Servers | Server | Protocols | HTTP | Exchange Virtual Server
3. Right-click the Exchange virtual folder, then choose Properties
4. Click the Access tab, then Authentication
5. Enable Basic authentication (password is sent in clear text)

Figure 4: Authentication Settings of Exchange Virtual Folder

6. Click OK twice and close the Exchange System Manager

As you can see in Figure 3, it’s possible to specify a default domain. It’s recommended you type in your Default domain in this field as this will let your user’s logon to OWA without specifying the domain name as part of their username (domain\username). You could also let your user’s login with their User Principal Name (UPN) instead, if you want to do so, you need to type a backslash “\” in the Default domain field. When UPN login has been configured users will be able to login by typing user@domain.com in the username field.

Note:
When using UPN logins users can still login using the format domain\username.

If you choose to enable forms-based authentication, UPN logins will be enabled automatically.

Configuring Pass-Through Authentication

To configure an FE server to forward the authentication requests directly to your BE servers, also known as (Pass-through authentication), you would need to do the following:

1. Open the Exchange System Manager
2. Drill down to Servers | Server | Protocols | HTTP | Exchange Virtual Server
3. Right-click the Exchange virtual folder, then choose Properties
4. Click the Access tab, then Authentication (see Figure 4)

Figure 5: Configuring an Exchange 2003 Front-End to use Pass-through Authentication

5. Enable Anonymous access, and then remove the check mark in Basic authentication (password is sent in clear text)
6. Click OK twice and close the Exchange System Manager

Summary

In this article, I explained which authentication method is recommended in an FE/BE setup, where forms-based authentication hasn’t been configured, and where you don’t make use of ISA Server. I also showed you, step by step, how you configure each authentication method. Although you get some additional security by using dual authentication in an FE/BE setup, I highly recommend you think about investing in an ISA Server instead, as using an ISA Server is the optimal way of protecting your Exchange environment. Among many other things an ISA server provides application layer filtering, as well as gives you the possibility of pre-authenticating your OWA users (using forms-based authentication very similar to the Exchange forms-based authentication method) while keeping Single Sign-On (SSO) intact. Actually you can eliminate the Exchange FE server completely by introducing an ISA Server, as you can publish the Exchange back-end servers directly.

Exchange 2000 Front-End/Back-End

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.

Front-End/Back-End Overview

After you have installed your second Exchange 2000 server in the organization, you can elect to turn it into a front-end server. There are no settings involved for a back-end server, which basically operates as a normal Exchange 2000 server. In fact, there are no real front-end settings either. You are either an Exchange 2000 front-end server or a regular Exchange 2000 server, period.

We are going to track exactly what an FE server does and what it does not do. We’ll also look at the actual performance of a BE server with and without its FE counterpart. To help us do this, I put together another small lab.

First, let’s turn Server1 into the FE server. Making this change is the easiest thing you will ever do! Open the Exchange System Manager console and expand the Servers node under your org.

Right-click on the server you want to convert to the FE and place a check-mark in the This is a front-end server checkbox. Click OK and reboot the server to complete the transition. In our case, we selected Server1 and chose This is a front-end server.

So what have we done? By checking this box, we have instructed the server to no longer refer us to the server that holds the requested information. Now the server must perform the same look-ups as before, but now it will handle the authentication and all communication to the “BE” server. Let me demonstrate; first I try to open our OWA session from the FE server:

I enter the same information as before. Only this time I am prompted for a password.

Note: FE servers ALWAYS prompt for a password even if you already have a token in memory. FE servers only understand basic authentication. So if you have an in-house application and do not want to prompt the user for authentication, don’t use FE servers.

Next, instead of redirecting me to the appropriate Exchange Server, the FE server acts like the server it found in the back. Notice the Address bar shows an Exchange directory on Server1.

Guess what? Server 1 has no local store. I stopped all the services. There are a couple of ways to do this, the easiest is to simply stop ALL Exchange services and turn their start-up settings to manual. If you want to totally dismount the local stores, use the Exchange System Manager to dismount the public store(s). It is recommended that you leave the private store in place in order to generate NDRs, etc. In my example, I do both just to make sure no store is loaded.

In essence, Exchange Server is no longer running or even functioning on the FE server, Server1. What is functioning is a WebDAV redirector that still understands how to look at the Global Catalog for Exchange objects.

Remember our OWATEST folder? It is also addressable using the OWA interface and, as you can see, Server1 claims the folder is in its own local store (even though there is no local store.)

Front-End Redirection

As I mentioned before, Exchange Servers research the Active Directory to find Exchange objects. In a normal situation, the server that actually holds the data instructs the referring server to redirect the client. FE servers are told to respond as if they hold the data. In many cases, it is the BE server that tells the FE server what to do.

Following is a packet trace I did in the lab while a client requested an OWA session from the FE server. In this case, the mailbox was on ServerA. First, the client performs a DNS lookup for SERVER1.BRYANT.COM. The response comes and the client then performs a GET request for an OWA session. I started this whole process by accessing http://server1/exchange from Internet Explorer. (Remember that Server1 is the FE.)

The FE then tries to locate the appropriate BE server. This is done through a series of LDAP and DNS calls, as well as scattered RPC sessions.

Once the FE Server finds the appropriate BE Server, it begins to echo the client requests verbatim to the BE server.

You would expect the BE server to then respond with http://servera/exchange/mailbox information, but instead it tells the Front-End server exactly what to say to the client. The BE tells the FE to respond with http://server1/exchange information. Basically, the BE is doing a lot more than I thought it would.

I have already mentioned WebDAV in this article because this protocol is at the heart of Exchange 2000. WebDAV, an extension to HTTP, is an emerging protocol standard for performing basic file system operations across the Web using Distributed Authoring and Versioning (DAV). Because it is based on HTTP, it is an excellent way to code through firewalls. When used in conjunction with XMLHTTP, WebDAV can also define the XML post data structure. OWA for Exchange 2000 is a prime example of this combination. In fact, it is this combination that we analyzed earlier in this article.

WebDAV and pure HTTP are currently the only (programmers) protocol that FE servers can “proxy” to BE servers. Let me repeat that:

FE servers will only process WebDAV requests destined for an Exchange 2000 Web Storage Sytem. FE servers will not proxy CDO, ADO, MAPI or any other programming protocol other than WebDAV.

Performance

Network Considerations

There are none. What I mean by that is you must place FE servers in the same domain as their BE counterparts. As we saw in the protocol traces, the FE must also be able to find your internal DNS Server, Active Directory Domain Controller, and a Global Catalog for your domain. The FE server uses these tools, and RPC in many cases, to find and talk to the BE servers.

Also, a FE server does not care where you came from. Its sole intention is to proxy your requests. It will not make a determination of your LAN, access speeds or anything else. The FE server will look in AD to find the source you are requesting and proxy the request to that server on your behalf. Essentially, there are no load-balancing characteristics nor can the server provide your mail if your mail server is unavailable.

Here is my one-sentence summary:
If you are creating WebDAV applications and need to prompt users for authentication information and have no specific performance SLAs (for example, folks entering from the Internet), and expect tens of thousands of people to use this application then FE/BE is what you want!”

Internet Access Example:

This model is exceptional for a company who wishes to use OWA as the default mail access, especially if this access will be available from the Internet. In this configuration, there are no Exchange stores directly exposed to the Internet. Moreover, the first firewall needs only to open port 80 to allow users to connect to the FE server. You will however, need to open quite a few ports between the FE and BE servers to allow for DNS, LDAP, and quite possibly RPC traffic. This should be pretty easy with a direct IP map that allows the FE greater access to your network.
Server Performance

So, what exactly does an FE server offload from the BE servers:

• Authentication As I mentioned earlier, FE servers only support basic authentication. If you are using SSL, the FE will handle this as well. SSL adds a tremendous amount of overhead on transactions. In most cases, it doubles or more than doubles the processor usage on the server and the amount of data that is sent over the wire.
• Controls Your custom applications will use a set of tools or controls for the client. The FE server acts as an IIS server and provides the controls you specify to the HTTP client.

How much load is actually taken from the BE server? Here is a short performance snapshot

The peak on the left was generated when a client entered http://server2/exchange directly to access mail. The peak on the right was generated when the client entered http://server1/exchange and accessed data on Server2 through the FE server. As you can see the load on the server is slightly lower when accessed this way. Based on this data, routing clients through an FE does not dramatically reduce the load on the BE servers. The bottleneck will continue to be on the BE servers (in most cases.) The overall recommendation is one FE to four BEs. This should provide good balance.

As a general rule, add BE servers as you would normally to overcome capacity issues on the mail-servers. Add FE servers to provide redundancy to the browser clients (think of it as an IIS server farm.)

I recommend that you perform more thorough tests when identifying potential volume on your servers.

Summary

FE/BE is not the cure-all for application development. It is great for a lot of things, and not-so-great for other things:

• Unless all Public Folders are fully replicated, it will probably take two HTTP queries and hashing to find the server with the data.
• You have little control over where users are redirected. If FE servers are placed in Dallas, BE servers in Dallas will probably be used for data access even though a replica exists closer to the user.
• A BE server that returns to service may not be known to the FEs for 10 minutes
• FE/BE does not support NTLM or Kerberos. The users will always be prompted for a user name and password at the start of the session.
• Only Basic HTTP 1.1 authentication is supported by FE/BE
• The supported FE client protocols include HTML/HTTP, POP3, IMAP4, NNTP, WebDAV, FrontPage and Office Server Extensions protocols, H.323 and T.120. The server-to-server protocol services include SMTP, NNTP, and X.400. CDO and ADO is not supported in an FE/BE configuration.

Let’s consider the big picture; how many applications are you going to run? What is the best way to publish all applications in your environment?

Here’s one idea: DNS provides an excellent way to use a single namespace for applications. By providing site specific entries such as http://application, users can be assured that they are always being directed to the appropriate server—and the closest server for that matter.

In this scenario, a degree of load-balancing becomes a matter of design. If traffic loads are high, build an application server that is closer to the user population. Load-balancing will occur over the enterprise with little to no restrictions. The application determines its availability and replication schedules. If a local site needs fast access to the application, a local server is built and a local DNS entry is added for the application. Each site can determine if clustering is required and no additional servers are required.

If you are considering creating WebDAV applications for access to data behind a firewall, FE/BE is absolutely your best choice.