Implementing Outlook Web Access with Exchange Server 2003

General Information

With Exchange Server 2003 you can use Standard Edition or Enterprise Edition of Exchange Server to provide Web Access with a Frontend Server. That is quite different in comparison to Exchange 2000 Server where you had to use Enterprise Edition to provide it. But before thinking of implementing a Frontend Server you should first consider your network infrastructure. Do you have a DMZ (also known as perimeter network)? What kind of firewall(s) do you have? Are you using an ISA Server 2000 or any other application layer firewall? Especially using ISA Server 2000 you have some tricky functions providing a good way to securely configure OWA Access over the ISA Server. For more information on ISA Server implementations please refer to the articles of Tom Shinder on this website.

Preparing Exchange Server 2003 for OWA

Your Exchange Server 2003 generally behaves as Backend Server and every user has HTTP as an allowed protocol. So you do not have to configure anything on your Backend Servers unless you want to prevent some of your users from accessing their mailbox using OWA. This can be done quite easily via Active Directory Users and Computers in the user properties.

Figure 1:  Enabling OWA for a user

The next step is installing and configuring your Frontend Server. The easiest way to do this is to install it as a second Exchange Server in your organization. After that we should enable it to act as a Frontend Server. This can be generally done in the properties of your Exchange Server in Exchange System Manager.

Figure 2: Configuring a Frontend Server

If we choose this configuration the server changes from using the DAVEx process (to act as Backend Server) to the ExProx process (acting as Frontend Server). The next step is to reboot the server to make the changes take effect.

Then we should go through the following steps to make the Frontend Server a genuine Frontend by disabling all unnessecary services. On your Frontend Server you must have the following services running, every other service may be stopped without any trouble.

• HTTP-Service
• SMTP-Service
• Exchange System Attendant
• Exchange Routing Engine

You really do not need to run the Exchange Information Store, because there should not be any public folders or mailboxes on your Frontend Server. The best practice is to dismount and delete all databases on your server and then disable the Exchange Information Store Service.

After you have successfully placed this server in the perimeter network (also known as DMZ) we now have to configure the appropriate ports on the firewall(s) to make our server run.

On the intranet firewall (which connects the DMZ and the internal network) we have to open the following ports:

• For Exchange Communication:
  • Port 80 for HTTP
  • Port 691 for Link State Algorithm routing protocol
• For Active Directory communication:
  • Port 389 for LDAP (TCP and UDP)
  • Port 3268 for Global Catalog Server LDAP (TCP)
  • Port 88 for Kerberos Authentication (TCP and UDP)

Note: You should now configure the DSAccess service for perimeter networks on your Frontend Server. At first you should disable the check for available disk space at netlogon by using RPC. This can be done by changing the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: DisableNetlogonCheck
Value Type: REG_DWORD
Value Data: 1

In addition to this you should prevent DSAccess from pinging domain controllers. This can be done by creating the following key on your Frontend Server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: LdapKeepAliveSecs
Value Type: REG_DWORD
Value Data: 0

Then you should configure your Exchange Frontend Server to connect to the DC and GC you want by editing the server properties in Exchange System Manager.

• For DNS communication:
  • Port 53 for DNS (TCP and UDP)
• For RPC communication:
  • Port 135 – RPC endpoint mapper (TCP)
  • Ports 1024 and higher for RPC services

Note: You can limit RPCs across the firewall by editing the registry of all your DCs. You should now change the registry setting of the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters Registry Value: TCP/IP PortValue Type: REG_DWORDValue Data: (available port)

If you are using IPSec between Frontend- and Backend Servers you have to open:

• Port 500 for IKE (UDP)
• Port 51 for Authentication Header (AH)
• Port 50 for Encapsulation Protocol (ESP)

If you want to provide high availability for your Frontend Server you could do this by configuring the Network Load Balancing Service (NBL) to act as a virtual cluster. NLB will then make sure that users connect to a running Frontend Server. Then every user connecting to OWA will connect to the virtual cluster and will then be redirected to one of your Frontend Server nodes.

Implementing Security for Outlook Web Access

If you have successfully implemented your Exchange Front-End Server constellation for providing Outlook Web Access for your users, you may be concerned about security matters. HTTP connectivity is not very secure and authentication information is always on the net as clear text. In addition to this, Outlook Web Access authentication is generally session based. This means if you do not logoff and close your browser you remain logged in. Especially in public web access areas where users are unable to close the browser window it becomes quite easy for other users to read and send emails in the name of a company user.

Providing a secure HTTPS connection with an SSL server certificate is quite easy to implement. The most interesting decision is whether to use a web server certificate from an internal certificate authority or to buy one from a well-known trust center like Verisign or anyone else. This certificate must then be installed on your OWA server.

Figure 3: Installing a Web Server Certificate on an OWA Box

Now you can choose between a secure channel and a non-secure one. If you would like to require 128-bit encryption, just check the appropriate box and it runs. But do not forget that some countries have laws that only allow 40-bit encryption (e.g. France). 

With a new feature in Exchange Server 2003 you can make your OWA connections more secure. This feature is called “Form-based Authentication” which means you can configure a cookie timed-out session connection. This can be quite easily implemented as shown in the following picture below.

Figure 4: Enabling Form-based Authentication

After enabling this feature you have a default setting of 10 minutes as the timeout value for a client session. Then you must re-logon to get a new cookie and new OWA access.

Note:  You can change the default timeout by changing the following registry setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
Registry Value: PublicClientTimeout
Value Type: REG_DWORD
Value Data: (possible setting decimal)

and

Registry Value: TrustedClientTimeout
Value Type: REG_DWORD
Value Data: (possible setting decimal)

On both registry values the possible settings will vary from 1 – 4320 (minutes). After changing these settings you have to restart your W3SVC service.

With the setting of compression you have the possibility of speeding up your connections, if you can make sure that your OWA clients are aware of the following requirements:

• Windows 2000 or later
• Internet Explorer 6.0 with the cumulative of November 2002 or Netscape Navigator 6.0 or higher
  
  

Summary

When establishing a secure way for users to access their mailboxes via the internet, you can implement Outlook Web Access but you have to make sure that everything in your OWA implementation is well planned so that you do not open more doors in your “Swiss Cheese” (your firewall) than needed. This article provides you with a deep drill-down view on how to secure your OWA implementation with the most secure state-of-the-art configuration today.

Configuring ISA Server 2004 as an Exchange Frontend Server in the DMZ (Part 1)

Ever since ISA Server 2004 has been available, there have been quite different opinions on which is the best design strategy for publishing Exchange Server 2003 services securely on the web. Within this drill down we will delve a little bit deeper into the configuration details on how to make your Exchange Server 2003 publishing as secure as possible using ISA Server 2004 taking into consideration the ideas of the Exchange product team.

If you would like to read the next part of this article series please go to Configuring ISA Server 2004 as an Exchange Frontend Server in the DMZ (Part 2).

With former versions of Exchange Server, the best practise was placing an Exchange Server Front-end box in the DMZ. This meant that a lot of ports had to be opened on your firewall to allow the communication between the front-end server in the DMZ network segment and the back-end servers in your internal network. This was a very insecure configuration because if this server had been hacked by someone it could be quite easy to get access to the internal network services. Therefore a lot of companies did not want to publish anything due to security reasons.

With the release of ISA Server 2004 this has changed because of the new features where you can publish every Exchange Server 2003 service with the best security available. A few leading security experts suggest using the design covered in Tom Shinder's articles found here:

• http://www.isaserver.org/tutorials/Creating-Multiple-Security-Perimeters-Multihomed-ISA-Firewall-Part1.html

Within this drill down we will delve a little bit deeper into the configuration details on how to make your Exchange Server 2003 publishing as secure as possible using ISA Server 2004 taking into consideration the ideas of the Exchange product team.

Defining the Exchange Server Design

If you are planning your Exchange Server 2003 Design with the aspect of publishing Exchange services on the web for your employees, it is very important to make sure that your Exchange Server box does not have any direct access to the internet. This means that we need a DMZ or something similar, which means you will have to protect your internal network by placing a not quite secure network in front of it – the demilitarized Zone.

The DMZ does not mean that you will have to have two firewalls (a front end and a back end one), the DMZ can be connected to your current firewall as a third network. The most important thing is that you will have to make sure that the traffic from outside your network has to be routed through the DMZ and that no direct connection from outside to inside will be possible and vice versa.

Exchange vs. ISA Server as Front-end

But what is the reason for using ISA Server 2004 instead of Exchange Server 2003 in the DMZ? The reasons are quite easy:

1. More security due to Firewall Rules
2. Secure Webserver Publishing with great Application Filters
3. No need for adding it to the domain due to the functionality of acting as RADIUS Client
4. Lower Costs than an Exchange Server 2003 License

If you are installing Exchange Server 2003 as front end server in your environment you will have to make sure that there are enough ports open to be able to contact Active Directory directly and join your Exchange Server Organisation. For more information you could have a look at my article “Implementing Outlook Web Access with Exchange Server 2003” (http://www.msexchange.org/tutorials/OWA_Exchange_Server_2003.html). This will help you to understand the configuration in detail.

ISA Server 2004 now has the great opportunity to act as a RADIUS client. This means that you can configure it to talk to the internal RADIUS- or IAS-Server on one of your internal infrastructure servers. This means you will have an infrastructure that only needs a maximum of two additional ports to contact Active Directory for authentication purposes.

The Internet Authentication Service (IAS) is Microsoft’s implementation of RADIUS Service that you probably know from Routing and Remote Access Services or IEEE 802.1x Authentication. RADIUS is a standardised secure way to contact your internal directory service for authentication. When it is being used, your employees only have to have one password in mind for internal and external authentication using Active Directory.

In addition to this the great Application Filters on your ISA Server firewall provide a good and easy way to get rid of hackers or anything else in your internal network.

And a third good reason is that the cost for a license of ISA Server 2004 Standard Edition is not as high as for Exchange Server 2003 Standard Edition.

Preparing the Exchange Organization

If you now want to prepare your complete network infrastructure for this design you will have to make sure that the following structure will work properly.

Figure 1: A good and secure configuration for publishing Exchange Services to the Internet

So here are the steps that you will have to prepare to make things work:

1. Install and configure Internet Authentication Services (IAS) on one (or for high availability more than one) Windows Server 2003 systems.
2. Open the RADIUS ports (in general 1812 and 1813) on your firewall for communication from ISA Server to IAS Server and vice versa.
3. Make sure that your ISA Server can access your internal servers for DNS.
4. Install Windows Server 2003 SP1.
5. Harden your Server System using the Security Configuration Wizard (SCW) to prepare your system for the highest available security settings.
6. Install ISA Server 2004 SP2 on your new Server.
7. Place it in the DMZ.

After having tested your environment you will now be ready to configure your system to publish all Exchange Server 2003 based services. This will be shown in the second part of this article coming soon.

But why should we still use a front end server in the LAN segment? The reason is quite simple, it is just because you are able to publish one single URL to all your employees even if you still have more than one back end server available.

Conclusion

With the great combination of Exchange Server 2003 on Windows Server 2003 and ISA Server 2004 you will have a good, easy and secure solution to be able to publish your Exchange Server 2003 services on the internet with a minimum amount of risks. You will be able to ensure that all your employees (if needed) can communicate with your messaging and collaboration system anywhere in the world without any barriers.

Due to security reasons and for patching purposes you will need to implement a change management process in your company network to have all your servers (at least these ones connected to the Internet – directly or indirectly) updated with all fixes, patches and service pack that are available. Here Windows Server Update Services (WSUS) or any other patch management mechanism may help you to make your servers the most secure ones that have been possible yet.

To make sure that your configuration is as secure as it could be you will now have the opportunity to do some testing in order to hack your firewall and if you have configured everything based on Microsoft’s expectations there will not be any problem on security in general. Lots of companies have successfully configured this and are happy with their new services published to the internet for the almost well known roaming users all around the world.

If there are still further questions please do not hesitate to contact me.

If you would like to read the next part of this article series please go to Configuring ISA Server 2004 as an Exchange Frontend Server in the DMZ (Part 2).

Using the Microsoft Exchange Server User Monitor (ExMon) tool

Why use ExMon?

There’re several reasons why you would want to use ExMon in your environment, like mentioned above you can view, evaluate and gather real-time data about your users, which can be quite handy as it will help you as an Exchange Administrator better understand current client usage patterns and plan ahead by being proactive and perform the proper upgrades for the future.

Although ExMon is capable of showing you quite a comprehensive set of information about your users, you should bear in mind the tool at the time of this writing only is capable of showing MAPI traffic and load, not other protocols such as OWA, POP3 and IMAP.

ExMon is capable of showing information such as IP addresses used by clients, Outlook versions and mode (cached mode or classic online mode) , Outlook client-side monitoring data and resource use (CPU usage, Server-side processor latency, total latency for network and processing with Outlook 2003 MAPI clients and network bytes.

Installing Microsoft Exchange Server User Monitor

Start by grabbing a copy of ExMon here.

Note:ExMon is supported on Exchange 2000 Server SP2 and higher, or Exchange Server 2003 SP1.

Now navigate to C:\Program Files\ExMon and execute ExMon.msi. The ExMon Installation wizard will fire up (seeFigure 1) and you can simply click Next.

Figure 1: Executing the ExMon Installation Wizard

Read and accept the agreement and click Next as shown in Figure 2

Figure 2: Reading and accepting the End User Agreement

Now select the Installation folder (default should be just fine) then click Next as in Figure 3.

Figure 3: Specifying the Installation Directory

Let the installation process complete and click Finish.

Figure 4: Finishing the Installation Wizard

Before we can move on and begin playing with the ExMon tool we need to do one more thing, and that is to add two registry keys - RpcEtwTracing and UsePerformanceClock to the registry (see Figure 5). Luckily you don’t have to do this manually as the ExMon installation throws an ExMon.reg file into the installation directory, which you can simply double-click on or run through a command prompt window. It’s mandatory to add these keys in order for ExMon to collect data, and my guess is they will be added automatically as part of the installation wizard in a later ExMon build.

Figure 5: ExMon registry keys

Using ExMon

Now that we got ExMon properly installed let’s fire up the tool by executing the ExMon.exe file from the installation directory (C:\Program Files\ExMon). This will bring us the screen you see in Figure 6 below. As you can see we, when the first update occurs, gets a list of currently connected MAPI clients listed by resource usage.

Figure 6: Tracing MAPI clients in ExMon

As shown in Figure 6 above ExMon by default collects data in one-minute intervals, however this can easily be adjusted by clicking the up and down buttons to the right of Update Interval (min) in the ExMon toolbar. The update interval can be anything between 1 and 30 minutes, if you want it do be more than 30 minutes you should use another data collection method. You can stop or start traces by using the play and stop buttons in the toolbar or alternatively click File > Stop or Start. You can save statistics by clicking the floppy disk icon in the toolbar or File > Save Statistics in the menu.

As you can see in Figure 6 above there are 3 different views to choose between:

View type	Description
By User	Aggregates data about individual user’s consumption of server resources
By Version	Aggregates data about the client MAPI version
By Clientmon	Aggregates data which can help Exchange administrators quantify individual user’s experience with Outlook 2003 (previous Outlook versions is not supported with Clientmon).

Table 1: ExMon View types

Note:Although this article demonstrates how you collect data directly with ExMon (which is the simplest method for short-term data collection) you can as well configure ExMon to collect data with the System Monitor or by using command-line tools. For more details on how this is accomplished see the ExMon documentation located in the ExMon installation directory.

The data collected by ExMon is by default saved in Event Trace Log (.ETL) files in the installation directory (C:\Program Files\ExMon), as can be seen in Figure 7 below.

Figure 7: ExMon Data Collection to Event Trace Log (.ETL) Files

Exporting Data with ExMon

All the data collected by ExMon can be exported to a comma-separated text file (.CSV) which again can be manipulated with a program such as Excel, Access or even SQL Server. This is done by running ExMon in a Command Prompt window with either -SU, -SV or -SC. For example the below command exports the By User data to a .CSV file in a directory named Data under the ExMon installation directory:

ExMon.exe –SU “C:\Program Files\ExMon\data\ByUser.csv”

For further details on exporting ExMon data, again see the ExMon documentation.

The dreaded Unknown StartTrace Error (183) Message

Before you start using the ExMon tool I thought I would tell you about an issue you should be aware of. There have been several cases where different Exchange administrators, when executing ExMon.exe, got an Error 183 message (shown in Figure 8), and actually I also had the pleasure of dealing with it on one of the Exchange 2003 SP1 servers, I’ve been using the tool on (after testing it out in my test lab of course).

Figure 8: Unknown StartTrace Error (183)

The Error 183 message can happen if ExMon crashes or is killed while collecting data, the reason being the Exchange trace continues. Personally I got a bit scared when I saw the trace just continued, but fortunately I later found out it had a limit of 512 MB where the trace will stop collecting automatically. The reason for the 183 error message is quite simple, it’s because when you try to execute ExMon (after a crash or after the process somehow got killed) it will start a new trace, while the old one is still tracing (ExMon only supports one trace at a time).

Alright I don’t want to use this tool unless I know how to fix this problem without rebooting my Exchange production server, I hear you grumble.

I fully understand! I personally had big problems finding out how to stop the Exchange trace, until I was informed of a comment (thanks to Exchange MVP Michael B. Smith) to the ExMon blogpost at You Had Me at EHLO (aka Exchange team blog), where Chris Mitchell (Software Design Engineer from the Microsoft Exchange Performance Engineering Team) did a great comment informing how you can stop a trace using Tracelog.exe which can be found in the Microsoft Driver Development Kit (DDK) for Windows 2000 Server or the Windows Server 2000 Resource Kit. You simply open a command prompt window and execute the following command:

Tracelog -stop “Exchange Event Trace”

Also see Figure 9 below.

Figure 9: Stopping an ExMon trace using Tracelog.exe

Note:Make sure the ExMon.exe process isn’t running while stopping the trace.

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.