Exchange Server 2007

Never Out of Touch with Exchange 2007

Joshua Trupin


At a Glance:

  • Improvements to Outlook Web Access
  • Unified Messaging in Exchange Server 2007
  • Security with ISA Server 2006

Years ago, online communication was basic. You sent e-mail through POP3 and SMTP. Simple enough. Of course, needs change. Today, organizations need to give employees the

flexibility to work when and how they choose, and they need to do it securely. Microsoft® Exchange Server 2007 has several built-in features that address these needs, including Microsoft Office Outlook® Web Access (OWA) and Unified Messaging. Let's look at these two key components of Exchange Server 2007 and how they outpace previous versions to create a more powerful communications platform for today's enterprise.

OWA has been part of Exchange since version 5.5. To be honest, the first versions were a bit clunky. They were an answer to the problem of accessing an Exchange mailbox with a Web browser, but they did it without much of the functionality provided by Outlook.

With the improved OWA that came along with Exchange Server 2003, things started to look up for end users. The browser-based experience felt a lot more natural, almost like you were working in a client program. OWA for Exchange Server 2007 goes even further, with a complete rewrite of previous versions, allowing it to build upon other recent technical innovations like RPC over HTTP and ASP.NET 2.0.

For instance, consider how OWA does its rendering. Previous versions of OWA were rendered by the mailbox server, during the store process. This added extra load to the mailbox server, potentially causing other slowdowns in the system. Outlook Web Access 2007, in contrast, renders data through ASP.NET, on Client Access Servers (CAS). This moves the page processing off the mailbox server, improving performance.

The work performed on the front end has also changed. In previous versions of Exchange, the OWA HTTP requests would be proxied to the appropriate mailbox server. Exchange Server 2007 reduces traffic associated with OWA by fetching data directly from the appropriate mailbox server through RPC. This is the same process, more or less, that allows you to use Outlook on a client that's not on a virtual private network (VPN) connection into your enterprise. The mailbox information is then rendered by OWA. Exchange Server 2007 can also proxy OWA requests, but instead of sending them directly to mailbox servers, it will forward them to other CAS servers.

Figure 1 shows the architecture of OWA on Exchange Server 2007.

Figure 1 How OWA Accesses Exchange Server Resource

Figure 1** How OWA Accesses Exchange Server Resource **(Click the image for a larger view)


The revamped architecture of Exchange Server 2007 includes expanded options for administering OWA. You can use the Exchange Management Console or use the Exchange Management Shell. Configuration settings are stored in several places.

Exchange Management Console lets you access most of the possible configuration settings, such as enabling or disabling features using segmentation, attachment blocking, authentication, and accessing features like the calendar, Task List, and spellchecking. Anything that can be achieved in the Exchange Management Console can also be done using Exchange Management Shell tasks.

In addition, the Exchange Management Shell allows you to create and delete new virtual directories for OWA. You can also get finer control over per-user segmentation settings and change the default language setting, among others.

The Windows registry is the default store for forms-based authentication time-outs. (These settings are not available through Exchange Management Console or the Exchange Management Shell.) Through Active Directory® you can access OWA-specific settings like attachment blocking and segmentation. The IIS Metabase contains any settings (authentication, GZIP) that influence the behavior of IIS. And web.config holds ASP.NET settings such as "maxuploadsize," which controls the uploading of OWA attachments.


OWA provides several choices for authentication at the server. After setup, security defaults to forms-based authentication. This, however, can be boosted in several ways as needed to conform to your organization's requirements. IIS will perform authentication against Active Directory to ensure that the user who is coming through has matching domain rights. You can also use basic authentication, digest authentication, RSA SecurID, or even SmartCard sign-in to access e-mail.

The strongest level of security for OWA is Windows Integrated, combining Kerberos and NTLM. In fact, Windows Integrated is required for Outlook Web Access 2007 Web Part access, as well as for CAS proxying between Active Directory sites. It also provides an extra benefit for users accessing OWA on an intranet—it provides single-sign-on with Windows client authentication, so you don't have to log onto OWA if you're already a trusted user.

If you use forms-based authentication, the default, OWA will automatically time out after a period of inactivity. Depending upon the user's choice of public or private machine (when asked on login), the timeout might be 15 minutes (for public machines), or it could be as much as 8 hours (for a private computer). The choice of public versus private machine is important for your users, because other security settings can also be configured differently depending upon this setting. You can, for instance, block attachments on public machines, or change authentication time-outs. Forms-based authentication is, basically, a four-step process as shown in Figure 2.

Figure 2 Authentication Process

  1. Clients send request to the server, unencrypted.
  2. Servers send an encrypted cookie back to the client.
  3. Servers keep discarding and creating new encryption keys, keeping the three newest keys in memory.
  4. Clients that send requests with an out-of-date encryption key which is still in memory get a new cookie encrypted with the newest key.
    Clients that send requests with an out-of-date encryption key which has been discarded and timed out must log on again.

msExchQueryBaseDN is the mechanism used to limit certain users to see only a subsection of the address book in OWA. msExchQueryBaseDN is stamped on Active Directory user objects and points to an Address List (AL) or an Organizational Unit (OU). This AL will be used as the Global Address List (GAL) for the user, and the user will see a GAL including only user accounts in this OU. You can set msExchQueryBaseDN using LDAP.

Backward Compatibility

The heart of Outlook Web Access in Exchange Server 2007 is the CAS, and the CAS model has been built up to provide the best possible interoperability with servers running earlier versions of Exchange. To ensure that this works, you should always deploy or upgrade your CAS servers before upgrading their associated mailbox servers.

An Exchange 2007 server with the CAS role can be used to connect to mailboxes on Exchange 2000 and Exchange 2003 servers. RPC over HTTP and Exchange ActiveSync® will both continue to work with a partial site upgrade. OWA and WebDAV will also work if you access them through the /exchange, /public, or /exchweb virtual directories. You can create custom OWA virtual directories for these earlier versions on Exchange Server 2007 as well.

ISA Server 2006 Is Your Friend

Outlook Web Access takes a number of steps forward in Exchange Server 2007, but it can be improved even further by pairing it with Internet Security and Acceleration (ISA) Server 2006.

ISA Server 2006 is an integrated edge security gateway. At the same time that it helps protect your site from Internet-originating threats, it also provides secure remote access to applications and data. Since that's also the goal of OWA, pairing the two gives you that most fabulous of all computing concepts, synergy. (For more background information on ISA Server, take a look at

ISA Server 2006 provides several benefits to the harried Exchange administrator. For instance, the Web Publishing Load Balancing (WPLB) feature lets you balance loads using HTTP cookies. You can ensure client-server affinity even when the client IP changes. ISA Server 2006 also provides GZIP compression and decompression, allowing you to analyze traffic or offload compression from Web servers. With ISA Server 2004, you had to make a choice: you could either use HTTP compression with OWA, or you could use forms-based authentication with ISA Server. Happily, ISA Server 2006 supports both simultaneously.

In addition, you can perform OWA link translation through ISA Server. If someone puts an intranet link in OWA e-mail, ISA Server can translate it to a proper Internet link. This can be quite useful, but you have to remember to publish the intranet links to the same ISA array that is publishing OWA.

Perhaps most importantly, ISA Server 2006 performs preauthentication to help protect your network at the perimeter. Preauthentication is intended to ensure that no rogue HTTP traffic reaches your servers. If the traffic that is being directed to your CAS is in fact valid, ISA Server will rush it along from the perimeter to the domain. (Perimeter servers sit outside the intranet domain, blocking traffic that doesn't belong in there. Your CAS shouldn't be deployed in the perimeter domain; it needs to be on the intranet domain so that it can access Active Directory user accounts.)

Troubleshooting Outlook Web Access

Outlook Web Access 2007 features new tools that improve monitoring and troubleshooting. A monitoring task runs automatically on the CAS server. The task tests connectivity for each mailbox server, as well as testing OWA logons. Exchange Server 2007 also provides far more detailed Event Log messages and Performance Counters.

The Exchange Server Best Practices Analyzer (see our coverage at has been improved to alert administrators to relevant warnings and errors if OWA is not configured correctly. You can also produce OWA usage reports from IIS logs through the LogParser tool (covered in the October 2006 issue at

Unified Messaging

Where OWA addresses the needs of the mobile business, Unified Messaging consolidates different forms of messaging in a unified place (hence the clever name). Right now, e-mail lives on Exchange Server. Voice (phone calls, voice mail) is available on a telephony server. You get your e-mail on your desktop, and you pick up voice-mail through your phone. And don't even get me started on fax messages!

Exchange Server 2007 Unified Messaging lets an organization deliver e-mail, voice and fax data into a single inbox, where users can access it all through Outlook and OWA. Unified Messaging goes the other direction as well: users can access voice-mail, e-mail, contacts, and calendars over the phone with Outlook Voice Access.

For the systems admin, Unified Messaging simplifies messaging by combining your Exchange and telephony infrastructures to give you one store solution, one directory, and one transport. The overall level of complexity is reduced when each person has a single mailbox.

The best part of all? This can be done with your existing servers, and if you know Exchange Server 2007 and telephony the learning curve is pretty flat. The features of Unified Messaging are integrated with Exchange—you use the same security model and the same inboxes. You can even access your voice-mail and faxes through OWA.

Figure 3 shows the architecture of unified messaging in Exchange Server 2007 with the Unified Messaging server role installed. Take a good look at it (there may be a quiz later), and then let's look at the Unified Messaging architecture in more detail.

Figure 3 Unified Messaging Pulls Together Voice, Fax, and E-Mail Communications

Figure 3** Unified Messaging Pulls Together Voice, Fax, and E-Mail Communications **(Click the image for a larger view)

When you're setting up Unified Messaging in an enterprise, there are a lot of elements to be aware of. Exchange Server contains objects that represent telephony hardware. These objects can then have their relationships defined within the Exchange Server environment. The Exchange Server Unified Messaging system objects include the UM Server, UM Dial Plan, UM IP Gateway, and UM Hunt Group, as well as the UM Mailbox Policy and UM Auto Attendant. Let's take a gander at how each of these objects justifies its existence.

The UM Server object is created in Active Directory where the UM server role is installed. It lets an admin control the setup and properties of an Exchange Server 2007 Unified Messaging deployment. UM Dial Plan is the basic administrative unit within Unified Messaging, representing how extensions are used internally. All users within a Dial Plan can reach all others simply by dialing their extension. If you are tying together other locations, each one will typically have its own Dial Plan.

The UM IP Gateway object represents a physical Voice over Internet Protocol (VoIP) gateway, or a Session Initiation Protocol (SIP)- enabled IP Private Brach Exchange (PBX). A unified messaging server can receive calls from an IP/VoIP gateway device. A UM Hunt Group links an IP Gateway with a UM Dial Plan. After a Hunt Group is configured at the PBX, a UM Hunt Group is created in Active Directory to represent this. You can configure the Hunt Group to provide load balancing across IP gateways. These gateways, in turn, can provide load balancing by associating a single UM Hunt Group with multiple gateways. UM Mailbox Policies are analogous to voice mail Classes of Service. They include a Dial Plan and properties that set operating policies for users and groups.

The UM Auto Attendant can be associated with a single UM Dial Plan. It can be customized to perform several tasks, such as custom prompt recording and defining tasks for different days and times. Auto Attendants can be scoped using address lists.

Figure 4 shows how these six Unified Messaging objects work together.

Figure 4 Interaction of Unified Messaging Telephony Objects

Figure 4** Interaction of Unified Messaging Telephony Objects **(Click the image for a larger view)

Setting It Up

Once a user has an Exchange Server 2007 mailbox, the admin must enable it for Unified Messaging. To do this, the admin must associate the mailbox with a UM Mailbox policy and an extension number, both within the Dial Plan. The PBX must also be configured to route the call to Unified Messaging on an RNA (ring, no answer). The PBX will first route the call to the user's extension. Then, if RNA occurs, the call is routed to the VoIP gateway, and then on to the Unified Messaging server.

Unified Messaging is scalable. You can add as many circuit-switched PBX channels and UM servers as you need to achieve capacity. When you use VoIP gateways, IP-based calls will be delivered to Exchange Unified Messaging. Since this is new functionality for many businesses, you should do a full round of network analysis to make sure your IP network has the bandwidth to handle both data and voice.

A typical Exchange Server 2007 Unified Messaging server can handle between 50 and 200 concurrent IP calls and up to 200 incoming voice and fax calls (these are set to 100 by default). You can build out additional Unified Messaging servers if you need more capacity than this, or if you want to increase your fault tolerance.


So there you have it! Exchange Server 2007 provides two features, Outlook Web Access and Unified Messaging, that together provide huge benefits to an organization. Outlook Web Access lets you securely access e-mail from anywhere, and Unified Messaging allows users to access their e-mail, voice mail, fax messages, and other mailbox data that can end up in their Exchange 2007 mailbox.

Joshua Trupin is the Executive Editor of MSDN Magazine and TechNet Magazine. He has written numerous articles for MSJ, MIND, MSDN Magazine, and TechNet Magazine, as well as a book, Hoop Stats: The Basketball Abstract.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.