The venerable Messaging Application Protocol Interface (MAPI) has been around a long time, and reports of its death have been greatly exaggerated. As the primary protocol used by Outlook since its inception, MAPI is well entrenched in Exchange deployments. MAPI traffic is actually a series of remote procedure calls (RPCs) that pass between the client and the server; the contents of these RPCs aren’t publicly documented by Microsoft, and they have changed the ordering and contents of the RPC payloads in several successive versions of Outlook to improve efficiency and security. MAPI connectivity can be established directly between the client and the server or through the RPC-over-HTTP proxy feature added to Windows Server 2003, Exchange Server 2003, and Outlook 2003. In addition, you can publish RPC through a firewall machine running Microsoft’s Internet Security and Acceleration (ISA) Server, which can do application-level inspection and filtering of the RPC traffic passing through it.

Outlook offers the richest feature set of all Exchange clients, in part because of the significant number of MAPI properties that have been implemented over time. These properties store data about messages, such as whether it’s been read or replied to; Outlook retrieves and caches properties when a message is copied to the Outlook client, then uses them in its interface.

Outlook Web Access is an HTTP-based web mail client that comes in two varieties. the “premium” version is designed for, and works only with, Internet Explorer for Windows. It delivers a client experience that’s surprisingly close to the full version of Outlook (including drag-and-drop message handling, type-ahead selection, calendar reminders, and access to public folders, rules, and the GAL), but it requires the use of IE, and some features depend on the S/MIME ActiveX control. The “basic” version of OWA will work on almost any other browser, as long as it supports JavaScript and frames. The basic version doesn’t have all of the functionality of the premium version, but it’s much more portable and uses somewhat less bandwidth.

Unlike the Exchange 5.5 version of OWA, which was a set of Active Server Page (ASP) files that used MAPI to fetch messages from the Exchange store, the Exchange 2000 and Exchange Server 2003 versions are implemented using a direct interprocess communications (IPC) layer called ExIPC that routes requests from the OWA pages to the Exchange store. One key feature that makes this work is that every item in the Exchange 2000/2003 information store is addressable by its own unique URL via WebDAV; the Exchange store also provides a complete rendering engine that can take the contents of a requested URL and render it appropriately for the client version and language used on the receiving end.

Compression is an ancillary benefit of OWA 2003. IIS 5.0 introduced the ability to use gzip compression to compress data before sending it, an ability long supported by Internet Explorer and most other browsers. When you enable compression, Internet Information Server (IIS) is responsible for compressing all the data it sends to the browser. In low-compression mode, IIS only compresses static pages like the OWA logon page; in high-compression mode, dynamic pages are compressed too. This can add significant CPU loading (on the order of 10-15%), but since most Exchange servers underutilize their CPUs, this isn’t a big deal. Compression requires Windows Server 2003, and all the users whose mailboxes are accessed through OWA must have those mailboxes on Exchange Server 2003 machines.

OWA uses WebDAV, but so do other clients. In particular, Microsoft’s Entourage for Mac OS X uses WebDAV to implement its Exchange support. However, WebDAV can be used for much more than messaging. For example, Office 2000 and later can use WebDAV to store or retrieve documents directly from Exchange folders; a wide variety of other command-line clients and libraries allow the use of WebDAV on Mac OS X, Windows, Linux, and other Unix variants. WebDAV clients can access all of the same properties as MAPI clients: some properties are explicitly exposed, while others can be requested by their hexadecimal property ID.

Interestingly, Exchange’s WebDAV implementation (provided by davex.dll) is separate from the one provided by IIS. The IIS implementation can be disabled without interrupting Exchange service, but if you remove or disable davex.dll your Exchange server will abruptly quit working.

These clients use the Internet protocol handlers that ship with Exchange; these handlers are actually built on top of the respective protocol implementations for IIS. There’s not very much to say about the implementation of these Internet-standard protocols; Exchange 2000 and Exchange Server 2003 provide the required functionality according to the POP3, IMAP4, and NNTP RFCs, and they provide a good deal of optional functionality as well. One important feature is Exchange’s ability to run these protocols over a Secure Sockets Layer (SSL)-protected connection; given the weakness of standard POP/IMAP/NNTP authentication, you should require this if you’re going to allow these protocols to be used from outside your corporate network. Most Exchange administrators disallow the use of POP3 and IMAP4 from the outside users, although some sites that need to give mobile users access will allow IMAP4 with SSL.

Examples of clients in this space include Outlook Express, Eudora (Mac OS Classic, Mac OS X, Windows), Thunderbird (Mac OS X, Windows, Linux), pine (Linux), VersaMail (Palm OS), and Aileron (Palm OS). The Windows Mobile and Pocket PC versions of Outlook also allow POP and IMAP connectivity, as does the standard Windows version of Outlook.

You want to be able to control which versions of Outlook connect to your Exchange servers using MAPI, to prevent users from running older, unpatched versions or from running beta versions. Or you may want to completely disable the use of MAPI.

When Outlook makes a MAPI connection to the Exchange server, it reports its version number. These numbers can be retrieved from the Exchange System Manager (check the Logons object under any mailbox database to see which clients are logged on to that particular database). For a more comprehensive list of versions, see the Exchange & Outlook Build Info page (http://www.cdolive.com/build.htm) maintained on the CDOLive web site (use the column marked Exchange Admin Build).

As it starts up, the information store service checks for the presence of the Disable MAPI Clients value in the registry. If this key is present, the list of values provides a list of MAPI client versions that will be prohibited from connecting to the store. Almost all versions of Exchange 2000 and 2003 support this feature. Although it was not present in Exchange 2000 RTM, it was added in Version 6.0.4418.63 of the store.exe binary, which was a pre-SP1 hotfix. As long as your servers are running Exchange 2000 SP1 or later, you can use this capability.

Formatting the string correctly can be slightly complicated, due to the multiple formats and values used by the various versions of Outlook over the years. In general, it is easiest to note the version number reported by Exchange System Manager and use that. MS KB 288894 describes this technique but is slightly confusing when explaining how to determine the version string.

MS KB 328240 (How to put server-side restrictions on clients that are used to access Exchange 2000 mailboxes), MS KB 288894 (Feature to Disable MAPI Client Access), and CDOLive: Exchange & Outlook Build Info (http://www.cdolive.com/build.htm)

You want to control the attachment types available to Outlook users on your servers.

If you want to change attachment blocking settings on a single computer to allow additional attachment types to be viewed, the process is quite straightforward. To change attachment blocking settings for Outlook on one computer, do the following:

You can also use the Outlook Administrator Pack to apply attachment blocking settings to multiple computers. You do this by creating a public folder named Outlook Security Settings, then installing a custom form in it and using that form to edit the security settings you want applied to your Outlook clients. Settings you apply in this manner will override settings on individual client machines.

If you choose to use this method, the first step is installing the Outlook Administrator Pack:

Once you’ve installed and registered the Outlook Administrator Pack’s components, you have to create a public folder to hold the security settings:

After you’ve created the public folder, you can instantiate the settings form and use it to create some security settings:

As a technical solution to what is largely a behavioral problem,^[1] Outlook 2000 SP1 and later checks the file type of each message attachment against an internal list of file types. A default list is included with the product; you can override or customize this list using an Exchange public folder or local registry settings. There are two types of blocked files:

When you attach a file to an outgoing message, Outlook checks the file type against the level 1 list. If you’ve attached any level 1 files, you’ll get a dialog that warns you that the recipients may not be able to open the attachment. Clicking Yes in this dialog sends the message as is.

When you receive a message that contains a level 1 attachment, your Inbox displays the paperclip in the attachment column to let you know that the message has an attachment. When you open an email message containing an attachment, the attachment is blocked, and the Outlook InfoBar warns you that the attachment is untouchable. The File→ Save Attachments command (as well as the View Attachments command on the shortcut menu you see when you right-click) will show only those attachments that aren’t blocked, rendering them completely inaccessible. When you open the message itself, you’ll see the same warning, but you can still get to all attachments whose extensions aren’t on the banned list. If you receive a message containing a level 2 file as an attachment, the attachment will appear normally. However, when you try to open it, you’ll get a warning dialog telling you that it’s a bad idea to run the attachment directly and offering to let you save it to disk.

Recipe 8.4 for blocking attachments in OWA, MS KB 837388 (How to configure Outlook to block additional file name extensions), MS KB 829982 (Cannot open attachments in Microsoft Outlook), MS KB 284414 (The recipient receives an “Outlook blocked access to the following unsafe attachments” error message when you send an e-mail message that contains a shortcut to a file in Outlook 2002 and Outlook 2003). Microsoft’s web site shows a longer list of Level 1 default file types (http://office.microsoft.com/en-us/assistance/HA011402971033.aspx)

One or more of your Outlook clients have folders whose names appear in the wrong language.

When you create a new mailbox, it’s empty—but at some point, the information store has to create the user’s server folders (including Inbox, Outbox, Sent Items, and Deleted Items). All users have these folders, no matter what client they use. In addition, users who log on with a MAPI client will get additional folders (including Calendar, Notes, Tasks, Contacts, and Journal) when they log on. The language in which these folders are named will depend on several factors:

If you have them available, the old Exchange 4.0 and 5.0 clients can also be used to correct folder names, as can MDBVU32.exe.

MS KB 325625 (XGEN: How Special Folder Names Are Assigned for Multiple Language Clients in Exchange 2000 Server) and MS KB 325626 (XGEN: How Special Folder Names Are Assigned in Outlook Web Access (OWA))

You want to restrict OWA 2003 users’ ability to open attachments.

OWA 2003 adds attachment blocking that works very much like the Outlook equivalent described in Recipe 8.2. OWA 2003 gives you three modes of attachment blocking.

Recipe 8.2 for blocking attachments in Outlook; Chapter 3 of the Managing Client Access to Exchange Server 2003 Guide (Microsoft)

You want to control whether OWA 2003 users can access documents stored directly in public folders.

Exchange has long allowed you to store documents directly in public folders—not as attachments to a public folder post, but in the same way that you’d put a document in a filesystem folder. These documents are called freedocs and have a message class of IPM.Document (instead of the IPM.Post type used for regular postings). OWA 2003 changed the way that OWA users interact with them. In OWA 5.5 and OWA 2000, users could directly open freedocs; OWA 2003 changed this behavior because freedocs might contain macro code that would be executed on the OWA machine when the document was opened.

However, this default restriction is a serious inconvenience for sites that use a lot of freedocs, so Microsoft thoughtfully provided a way to turn it off. The default setting is safer, and you should leave it alone unless you actually need to grant your users access to freedocs. In that case, the next safest approach is to enable freedoc access only from back-end servers.

MS KB 834743 (“HTTP 403 (Forbidden)” error message when Exchange 2003 users try to use Outlook Web Access to access a freedoc that is located in a public folder)

You want to control use of the OWA 2003 spellchecker.

The spellchecker built into Outlook Web Access 2003 can help you spellcheck your outgoing mail in a variety of languages including Arabic, Danish, Dutch, English (Australia, Canada, United Kingdom, or United States), Finnish, French, pre- or post-reform German, Hebrew, Italian, Korean, Norwegian, Spanish, and Swedish.

By default, the ability to use spellchecking is enabled for all users. OWA’s spelling checker has both a client and a server component. The server component processes the flagged words in the message, while the client component searches for the flagged words. There’s also an XML component to communicate between the client and server.

OWA’s spellchecker ignores a number of words and types of words, including the following:

Regrettably, there’s no way to customize the word list that OWA’s spellchecker uses, so you can’t add your own custom terms to the dictionary.

Users can configure Outlook Web Access to automatically check their outgoing messages before they’re sent. Simply choose the Options banner from OWA’s navigation pane and check the box marked Always check spelling before sending. If you prefer to prevent your users from checking spelling, you can create a registry key and disable all spellchecking (although we can’t figure out why you’d want to do that!).

MS KB 825430 (Overview of the spelling checker in Outlook Web Access for Exchange Server 2003), MS KB 841657 (Additional Outlook Web Access spell-check languages that are included in Exchange Server 2003 Service Pack 1), MS KB 822699 (“Outlook Web Access Was Unable to Check the Spelling on This Item Due to an Error” Error Message when you use the spelling checker)

You want to enable the use of SSL on your OWA 2000 or OWA 2003 server.

SSL has been around a long time, and so has OWA. By now, there really shouldn’t be an Exchange administrator anywhere on Earth who thinks it’s OK to run OWA without requiring SSL (unless you’re just running OWA on your corporate network). Why? OWA can use two primary authentication modes. Basic authentication obscures the credentials by base64 encoding them, but it doesn’t protect them from eavesdroppers. Integrated Windows authentication uses either Kerberos or NTLM authentication, but it only works with specific browsers that support it, and it’s normally restricted to use on corporate networks. Accordingly, OWA 2003 enables both types of authentication. However, basic encryption alone really isn’t safe for use on the Internet, since each authentication response contains an obscured user name and password that can be easily unobscured by an attacker who can eavesdrop on the connection. To protect against such eavesdropping, any OWA server that’s reachable from the Internet should have SSL enabled and required. In fact, SSL must be enabled to use form-based authentication or RPC over HTTPS.

Note that neither EAS nor OMA support SSL connections. See MS KB 817379 for details.

Recipe 8.8 for setting up form-based authentication, MS KB 839357 (How to redirect an HTTP connection to HTTPS for Outlook Web Access clients), MS KB 816794 (How to install imported certificates on a Web server in Windows Server 2003), and Chapter 2 of the Exchange Server 2003 Client Access Guide:

You want to enable form-based authentication (FBA) for your OWA 2003 servers.

The idea behind FBA is simple, but understanding it requires some background. If you’ve used the Exchange 5.5 version of OWA, you probably remember its logon form, which was embedded in an HTML page. The Exchange 2000 version of OWA did away with this logon page; instead, when you try to log on to Exchange, your browser would prompt for logon credentials. In Exchange Server 2003, you get to choose the approach you prefer—but which one is better? The difference between these two approaches is significant but subtle.

When a web browser gets an authentication request from a server, it has to ask the user for credentials. After the user types his credentials in, the browser could make him type them over and over again for subsequent pages; instead, browsers cache the credentials and send them for each subsequent page. This is easy for the user, but it raises some potential security problems. If the credentials are protected using basic authentication, an attacker could easily capture them from an unencrypted connection. Even if the connection is encrypted, there’s no good way to force the browser to “forget” the credentials after a set time period has passed—leading to the sadly common situation where user A logs on to OWA, leaves the machine, and has user B come along and continue their OWA session.

FBA attacks this problem by eliminating the browser’s access to credentials. When you use the OWA 2003 logon page, your credentials are sent as form fields to the Exchange server, but the communication is protected by SSL (which is why FBA requires SSL). The user name and password arrive at the server, which uses them to authenticate you against the Exchange mailbox you’ve requested access to. If the authentication request succeeds, the OWA server sends an encrypted cookie back to your browser. The browser supplies the cookie on each subsequent page reload, and the server can decrypt it and see if it’s valid. Net result: credentials are only sent once, and the rest of the time the cookie is passed from client to server. Better still, the server controls the contents of the cookie, so it can include a time stamp. By checking the time-stamp value each time the cookie is presented by the browser, it’s possible to set session time limits (as described in Recipe 8.10); once the timestamp indicates that the cookie has expired, the server redirects the user to the logon page to get a new cookie.

Recipe 8.10 for setting OWA’s session timeout limits, MS KB 830827 (How to manage Outlook Web Access features in Exchange Server 2003), Chapter 14 of Secure Messaging with Exchange Server 2003 (MS Press), and Chapter 2 of the Exchange Server 2003 Client Access Guide (http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3ClientAccGuide/7ff636d5-a97d-4ac9-a090-10eb428ccf83.mspx)

You need to allow users to change their passwords through Outlook Web Access.

Out of the box, OWA doesn’t provide a method for users to change their passwords. For users who log on to a domain every day, that’s no problem, since they can always change their password directly from their workstation. However, anyone who uses OWA remotely will be out of luck unless you provide them a method to change their passwords when necessary.

Once you have enabled SSL on your OWA server, you can allow your users to change their password through OWA. SSL is required because Microsoft correctly reasoned that allowing people to set up a mechanism to change passwords without it would be insecure. The password-changing mechanism itself is implemented by IIS, and IIS includes all of the necessary components; you only have to enable them. OWA can expose a convenient button to change the password, but only after you make the registry change described above.

Recipe 8.7 for setting up SSL, MS KB 321582 (The Outlook Web Access Change Password Options Does Not Function), MS KB 314308 (You cannot change your password in OWA if the front-end server and the back-end server are running different types of operating systems), MS KB 833734 (You experience various problems when you use the Password Change pages in IIS 6.0), and Restarting IIS (http://www.microsoft.com/resources/documentation/iis/6/all/proddocs/en-us/wsa_restartingiis.mspx), which has some good information on iisreset

You want to adjust the time out for OWA 2003 user’s session.

When you use FBA, as described earlier, the server generates a timestamped, encrypted cookie that it can use to determine when the user’s OWA session should time out. OWA 2003 distinguishes between trusted clients, which are presumably secure, and public clients, which are machines (like airport kiosks or public-access terminals in hotels) that can’t necessarily be trusted. There are separate timeout values for each of these client types, controlled by the two registry values previously described. Of course, since OWA can’t tell what kind of client it’s running on, the ultimate selection of a client type comes from the radio buttons on the OWA logon page: clicking Public or shared computer tells OWA to apply the public client timeout value, and clicking Private computer causes the trusted client timeout to apply.

Recipe 8.9 for setting up FBA, Chapter 2 of the Exchange Server 2003 Client Access Guide:

You want to easily administer the Outlook Web Access parameters on your Exchange server, using Microsoft’s Outlook Web Access Web Administration (OWAAdmin) utility.

The OWA Web Administration Tool provides easy access to advanced OWA features that previously had to be changed by editing the OWA server’s registry. This graphical interface is so useful that it provides in one succinct interface almost all the OWA settings available in other recipes in this book! The tool uses Windows Management Instrumentation (WMI) calls to make registry and metabase changes on remote Exchange servers, and presents a friendly interface to change advanced settings. The OWA Web Admin Tool must be installed on a machine running IIS 5.0 or higher that is a member of the OWA server’s domain. If you are running the tool on a machine running SharePoint Team Services (STS), you must exclude the OWAAdmin virtual directory from the STS ISAPI filter. The OWAAdmin tool requires you to have a security certificate installed on the IIS machine, but not to worry: it will install a three-year certificate for you if one is not found during the installation process. The cert uses the NetBIOS name of the machine, so if you access the OWAAdmin site with the machine’s IP address, you will get a security alert advising that the name doesn’t match the certificate.

The Customization settings allows for quick setting of some of the more tedious of configuration tasks for Outlook Web Access servers: selecting feature sets by segmentation, and setting a default color and font scheme. Table 8-3 contains a list of the settings available in the Outlook Web Access Web Administration Tool.

Recipes in this chapter on individual OWA 2003 settings and MS KB 300432 (How To Promote a Member Server Running IIS to a Domain Controller Running IIS) should be followed if running the web administration tool on a Windows 2000 domain controller

You want to create a new theme or skin for OWA 2003 to make it more compatible with your organization’s existing web applications.

In Exchange Server 2003, OWA has become an extremely mature web-based messaging application, which is why so many companies use it. One of the biggest requests about OWA was a way to make it easier to brand it with custom graphics, colors, and other visual elements; Microsoft responded by providing the ability to easily create additional themes. The process is, in theory, simple: create your new theme elements, put them in the proper place on the server, and register them so OWA knows to offer them. As always, the devil is in the details. Creating new themes is not difficult, but when you do so, you must remember that you are working with a complex web page and that changes that seem small can have a large impact on the final result’s appearance.

To change the basic theme, you’ll need to make changes to one or more of the ten files detailed in Table 8-4. For the most part, you shouldn’t try to change the size of the graphic elements; you will either throw off the spacing or cause the element to be scaled oddly to fit into a predetermined space. Be aware that the graphic elements with a width of 1 pixel are tiled horizontally to create the display element; this drastically reduces file sizes and bandwidth use.

Registering your theme can be somewhat tricky. Although you only have one registry entry to create, the contents of the string must be properly formatted. If you make an error, Exchange will not create a log entry or otherwise tell you that something is wrong. You will merely be unable to choose your theme. The fields can come in any order but must be separated by semicolons and need to be formatted as follows:

The purpose of a theme is to customize a few basic elements, not to allow you to completely change the look and feel of any element on the form. If you want to make changes to the various icons and elements not included in a theme, you can find the files in the Program FilesExchsrvrExchwebimg directory. These files are the same regardless of theme and language. You can make changes to them, but you should again be careful to make sure that your replacement graphics are the same dimensions to avoid unintentional spacing conflicts. You should also back up these files before you change them and keep copies of your changed files, as they will be replaced by any service pack.

For a more complete branding project, you can change the logon.asp file that is initially displayed for form-based authentication. A common reason for this modification is to provide a list of regional front-end servers for companies that are spread over multiple locations, to allow users to select the front-end server closest to them easily. Microsoft does not support these modifications, so be sure to save a copy of the default files in case you need OWA support from them. There are multiple versions of these files, one for every language supported on the server. They are written in complex ASP code, so make sure you understand and thoroughly test your changes. In addition, be aware that installing a service pack or hotfix may overwrite your changes.

Recipe 8.13 for designating a default theme, and the Customizing Microsoft Outlook Web Access white paper:

You want to restrict your users to a specific theme or set of themes in Outlook Web Access.

Whether you create custom themes or just wish to specify one of OWA’s default themes, you can choose to restrict users’ ability to change the theme they see. Once this change is applied, users will no longer be able to see the Appearance section in the OWA Options page. This is an all-or-nothing customization; you can’t both set a default and still allow users to change it.

Recipe 8.12 for creating your own themes, Recipe 8.11 for using the OWA Web Administration tool, and the Customizing Microsoft Outlook Web Access white paper:

You need to allow access from mobile devices using Outlook Mobile Access (OMA) or Exchange ActiveSync (EAS) but you have SSL or form-based authentication enabled on your Exchange virtual server, which is not supported by EAS and OMA.

There are two basic problems that can happen when you try to enable mobile devices and SSL/FBA on the same virtual server:

There are two possible solutions: deploy a separate front-end server for your mobile clients (see MS KB 818476 for more details) or create a new virtual directory with different authentication settings. The steps in this recipe create a separate virtual server just for mobile client WebDAV access; because IIS stores authentication settings on a per-virtual-server basis, the new virtual directory can have different settings that work properly. The change should be transparent to your mobile clients—other than the fact that their users will notice their connections start working!

MS KB 817379 (Exchange ActiveSync and Outlook Mobile Access errors occur when SSL or forms-based authentication is required for Exchange Server 2003) and MS KB 818476 (You can configure either Exchange Server 2003 Standard Edition or Exchange Server 2003 Enterprise Edition as a front-end server)

Some of your users have mobile devices that aren’t on the list of officially supported OMA devices, but you want to use them anyway.

OMA supports a fairly broad range of mobile devices, but they can’t support every potential device. In general, phones or handhelds that implement the Openwave browser, Microsoft’s Pocket Internet Explorer, or the Ericsson, Nokia, or Symbian browsers are supported. The canonical list of supported devices is located at http://www.asp.net/mobile/testeddevices.aspx?tabindex=6. Microsoft periodically releases update packages called device updates (DUs) that add support for additional devices; you can get the latest DU from the supported device page.

If you want to try using a device that you think should be compatible, you can toggle the Enable unsupported devices flag. When the setting is off, OMA will refuse to talk to any device not supported by the DU version on that server. When you turn it on, you can connect to OMA with any device you like, and if it’s not supported, OMA will ask you to click OK on a confirmation page that reminds you that your device isn’t supported.

MS KB 821835 (Overview of Mobile Devices That Are Supported by Outlook Mobile Access in Exchange Server 2003), Chapter 3 of the Exchange Server 2003 Client Access Guide (Microsoft), Chapter 8 of the Exchange Server 2003 Deployment Guide (Microsoft), and http://blogs.msdn.com/conrad/archive/2005/01/21.aspx (Disable OMA via Hosted Exchange)

You want to preconfigure your Exchange server with proper mobile carrier information for Exchange ActiveSync users.

To save your users the trouble of having to figure out what their mobile phone carrier’s SMTP-to-SMS gateway address is, you can preconfigure your server with the proper entries, allowing ActiveSync users to pick their carrier from a drop-down list. After selecting their carrier, users can simply type in their telephone number, and Exchange Always-Up-To-Date (AUTD) notifications will be delivered to their mobile device.

Table 8-5 lists the most commonly used Smartphone carriers in the United States; depending on your location and carrier, you may need to contact them to get the correct gateway information.

MS KB 833745 (Exchange Always Up-To-Date Notifications do not work with your mobile device)

You want to disable ActiveSync’s certificate checking on a Windows Mobile device.

For setup and troubleshooting purposes, it can be useful to temporarily disable your Windows Mobile device’s verification of certificates against its list of trusted sources. This allows you to use untrusted certificates that you’ve created internally, or procured from sources other than the large commercial services, without individually adding the root certificate to the device. SSL encryption is still used for communications between the device and the Exchange server, but error messages will not be generated. Once you’re finished testing and configuring your environment, you can either upgrade to a trusted commercial certificate or add the server’s private root certificate to your Windows Mobile device.

Recipe 8.18 for installing a root certificate for use with Exchange ActiveSync and MS Download Center Disable Certificate Verification Utility (DisableCertChk.exe) download at:

You want to install a root certificate on a portable device for Exchange ActiveSync users.

Windows Mobile 2002 and 2003 smartphones ship with root certificates installed for the major certification authorities, but many enterprises wish to issue their own root certificates for use with Exchange ActiveSync, VPN, or web services. Microsoft has made the Smartphone Add Certificate Utility available to allow users to add this root certificate authority to the device’s trusted certificate authority list. However, the utility will not work on phones that are application-locked by the mobile carrier; instead, the carrier must sign and distribute its own version of the utility. At the time of this writing, only Verizon has issued a signed version of the utility, available as VZW_SPAddCert.exe from the Microsoft Download Center. If you run through the steps in this recipe and are presented with an error message indicating that your smartphone is locked, you should contact your mobile carrier for assistance.

Recipe 8.17 for disabling checking of root certificates, and MS KB 841060 (How to add root certificates to Windows Mobile 2003 Smartphone and Windows Mobile 2002 Smartphone)

You need to configure your Exchange server to allow users to connect with POP3 clients.

POP3 is a client-centric protocol that allows for simple retrieval of email from a user’s inbox to a local message store on the client. Many administrators think of POP3 as an outdated, insecure protocol, but it has the advantages of being extremely lightweight and present as a client protocol on nearly every platform from personal computers to PDAs and cellular telephones. POP3 services can provide wider access to email resources for your increasingly mobile users, and can be more securely and flexibly implemented by understanding the available settings.

You can configure multiple POP3 virtual servers on your Exchange server. This is useful if you have a subset of users who wish to limit a POP3 server to plain text delivery for mobile devices that either do not support HTML email or may be charged by the byte for traffic. To configure an additional POP3 virtual server, simply bind a new TCP/IP address to a network adapter, and use that address to access the virtual server. By default, POP3 traffic occurs on port 110 for plain, unencrypted text, and SSL traffic occurs on port 995. Your network should be configured to allow the appropriate traffic to traverse freely if you use POP3.

Recipe 8.20 for configuring IMAP4 access, Recipe 8.22 for controlling which users can use POP or IMAP, MS KB 823024 (How to Use Certificates with Virtual Servers in Exchange Server 2003), and MS KB 319574 (How to Use Certificates with Virtual Servers in Exchange Server 2000)

You want your users to be able to use the Internet Message Access Protocol (IMAP) to receive mail from your Exchange server.

IMAP4 allows messaging clients to retrieve their data from the server and download the data to the local client machine. IMAP4 works in both online and offline modes, is more of an interactive protocol than POP3, which does not support manipulation of mail on the server. While IMAP4 does not have nearly as much functionality as MAPI, in cases where MAPI cannot be used, IMAP4 is a reasonable solution for mail retrieval. By default, IMAP4 traffic occurs on port 143 for plain-text, and SSL traffic occurs on port 993. Your network should be configured to allow the appropriate traffic to traverse freely if you use IMAP4.

Recipe 8.19 for configuring POP3 access, Recipe 8.20 for controlling which users can use POP or IMAP, MS KB 823024 (How to Use Certificates with Virtual Servers in Exchange Server 2003), and MS KB 319574 (How to Use Certificates with Virtual Servers in Exchange Server 2000)

You want to use set up a newsgroup feed and populate the Exchange Internet Newsgroups public folder hierarchy.

The Exchange 2000 NNTP implementation is a functional (though no-frills) implementation of the NNTP protocol and it hasn’t changed appreciably in Exchange Server 2003. You should always gain explicit permission from your news peers before configuring a feed, although many ISPs offer a newsgroups feed as part of a high-bandwidth (T-1 or higher) circuit package.

You should never need to create NNTP feeds to propagate groups within your Exchange organization; the public folder replica and replication mechanism provides finer control and follows your organization’s routing group topology. As such, there should usually be one well-defined interface between your Exchange organization and external news feeds. Also be aware that NNTP feeds can only be used for groups under the Internet Newsgroups folder in your default public folder tree; they cannot be used to replicate other public folder hierarchies with foreign systems.

News feeds are asynchronous by default; any articles generated within your organization propagate to external news server through outbound feeds, while all externally originated messages come in through incoming feeds. In addition, incoming feeds have two types:

It is not uncommon to configure multiple Exchange news feeds for a peering agreement with a single provider. Many newsgroup providers have large farms of high-speed dedicated news transit servers for redundancy; your organization may need to permit incoming connections from multiple servers (news01, news02, news03, etc.), all of which will use the same Path ID header to prevent replication loops. The corresponding outgoing feed will often go to yet another FQDN, usually a DNS CNAME pointing to multiple servers. When configuring these kinds of peering feeds, be sure to adjust the unique path ID generated by the remote server field on the General tab of the feed property sheet.

Although you can adjust the feed subscription on both push and pull feeds, it is only relevant to pull feeds; push feeds will accept all messages given to them, so be sure the peer has an accurate list of which groups to offer. Group subscriptions can be fully qualified group names (e.g., news.admin.net-abuse.blocklisting) or simple wildcard pattern matches (e.g., news.admin.* provides all of the groups in the news.admin hierarchy).

The interaction between the NNTP flood-fill protocol and public folder flood-fill replication can provide all sorts of potential trouble if you have feeds with multiple external peers. While having multiple peers is a traditional method to ensure faster, more complete Usenet propagation, you should be careful to use the same server to handle all feeds involving a given group to avoid the potential for replication errors and loops. This practice also ensures that you will never have more than one copy of a given message transmitted to your organization, thus saving bandwidth.

Using Exchange directly to exchange newsgroups with external systems may not be the right solution for your organization. A full Usenet feed transmits over 1 TB of data per day, most of which is binary groups, and the use of the NNTP streaming protocol extensions can make a noticeable difference in the speed and quality of newsgroup propagation over WAN links. If you require a full feed, specialized filtering (such as anti-spam or anti-virus checking), efficient use of your WAN bandwidth, or a greater level of redundancy for your newsgroups feeds, then you should probably investigate using specialized NNTP transit software on a dedicated host to handle your newsgroup feeds from the outside world. You can then provide a sanitized feed from this machine to your Exchange organization over your local high-bandwidth network. Additionally, you can investigate the use of the Exchange master/subordinate feed settings, which allow you to establish a group of Exchange servers that loosely work together as a single entity. Since the NNTP service cannot be clustered, this allows greater redundancy for the organization.

MS KB 266652 (How to Configure the NNTP Service, Part 1), MS KB 268092 (How to Configure the NNTP Service, Part 2), MS KB 319346 (How to create and manage newsfeeds in Exchange 2000 Server), and MS KB 328453 (HOW TO: Increase NNTP Reliability by Using a Master/Subordinate Arrangement in Exchange 2000 Server)

You want to control access to your Exchange S erver from non-MAPI clients, allowing some users to use IMAP, POP, or HTTP and preventing others from doing so.

In Active Directory, the settings for POP3, IMAP4, and HTTP access to a user’s mailbox are stored in the multivalued protocolSettings property in the user object. The format of each value takes a funny-looking format that uses the section character (§, ASCII 167) as a field delimiter.

POP3§<enableFlag>§<defaultsFlag>§<encodingFlag>§<symbolSet>§<
               rtfFlag
               >§Â§Â§
IMAP4§<enableFlag>§<defaultsFlag>§<encodingFlag>§<symbolSet>§1§1§0§0
HTTP§<enableFlag>§<defaultsFlag> §Â§Â§Â§Â§Â§

The first two flag values are fairly straightforward:

Finally, the <rtfFlag> values control whether or not Exchange will use RTF (and thus generate the infamous winmail.dat attachment):

Note that the steps provided in the GUI solutions are also applicable for IMAP4 and HTTP; while the actual service name changes, the steps for each protocol are identical. In the interests of simplicity, we’ve only included the steps for disabling the POP3 protocol.

MS KB 252459 (Retrieve Properties of User Objects with ADSI and ADO) and MSDN documentation for Platform SDK: Active Directory Schema

You need to log the specific protocol transactions of HTTP, NNTP, or SMTP sessions.

Although most Exchange deployments use some version of Outlook (and thus the MAPI protocol) for the majority of their clients, the ability to access Exchange resources via Internet standard protocols such as HTTP, NNTP, and SMTP allows many users to make use of a wide variety of other messaging software. It is much easier to troubleshoot difficulties with these clients and services with a detailed log of the protocol transaction; as an example, comparing logs of an SMTP conversation from an Exchange server and from the remote SMTP sender will provide an immediate pointer toward the trouble caused by a Cisco PIX firewall with the SMTP fixup feature enabled (see Recipe 8.24).

One method to spot these kinds of problems is to use a network packet sniffer, but this approach has many drawbacks, not the least of which is the necessity to manually decode the relevant information from the raw packet capture. On the other hand, most packet sniffers allow you to specify filters and reduce the fire hose of information down to a stream you can drink from without drowning, but you still may have to parse the resulting information by hand, although some packet sniffers do packet/session reconstruction for you.

Since Exchange wraps and extends the HTTP, NNTP, and SMTP components of IIS, there is another alternative: using the built-in logging capabilities of the appropriate virtual server. While you might not want to enable protocol logging for normal operation, as it can use disk and CPU resources and may slow down a busy virtual server, it is a valuable troubleshooting tool that can be easily enabled from within Exchange System Manager (or the Internet Services Manager for an HTTP virtual server).

Since protocol logging is enabled and disabled per virtual server, the performance hit can cause problems on a high-traffic server that only has the default virtual servers configured. One way to avoid this problem is to put some thought into configuring multiple virtual servers, as appropriate, to segment your traffic. For example, a bridgehead server for the external SMTP connector could probably benefit from a separate SMTP virtual server specifically for external traffic; whenever protocol logging is turned on to troubleshoot problems with external systems, none of the communications with the other Exchange servers in the organization will be logged. This needs to be balanced against the need to simplify the configuration as much as possible.

Protocol logs can be created in four formats: W3C Extended format, Microsoft IIS format, NCSA Common format, and ODBC. Oddly enough, the preferred format (and default) is the W3C Extended format. This format gives a rich set of properties across multiple protocols; while not every property is supported by every protocol, each property is used in the same way for each protocol that supports that property, allowing your administrators to use their familiarity with one protocol to read logs from another.

The first three formats are ASCII text files; the ODBC format writes each entry as a separate record to a preconfigured data source, allowing easy integration of logs from multiple sources into one central database, which can then be searched and filtered using standard database queries. Table 8-6 describes all the possible fields of the W3C Extended format.

The following sample HTTP log sample shows the beginning of an OWA login:

1  #Software: Microsoft Internet Information Services 6.0
2  #Version: 1.0
3  #Date: 2004-10-29 02:11:58
4  #Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem 
   cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) 
   cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes 
   cs-bytes time-taken 
5  2004-10-29 02:11:58 W3SVC1 exch01.thecabal.org 10.0.0.20 GET /exchange/ 
   - 80 - 10.0.0.10 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+
   NT+5.1;+SV1;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322) - - EXCH01 401 2 
   2148074254 337 402 30
6  2004-10-29 02:11:59 W3SVC1 exch01.thecabal.org 10.0.0.20 GET /exchange/ 
   - 80 THECABALdevin 10.0.0.10 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+
   6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322) - - 
   EXCH01 200 0 0 1694 2121 420
7  2004-10-29 02:11:59 W3SVC1 exch01.thecabal.org 10.0.0.20 GET /exchange/
   devin/ Cmd=navbar 80 - 10.0.0.10 HTTP/1.1 Mozilla/4.0+(compatible;+MSIE+
   6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322) sessionid=
   664eb14a-bc2b-4239-a688-d0197f094aff:0x409 http://exch01.thecabal.org/
   exchange/ EXCH01 401 2 2148074254 337 515 50
8  2004-10-29 02:11:59 W3SVC1 exch01.thecabal.org 10.0.0.20 GET /exchange/
   devin/Inbox/ Cmd=contents 80 - 10.0.0.10 HTTP/1.1 Mozilla/4.0+(compatible;
   +MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.0.3705;+.NET+CLR+1.1.4322) 
   sessionid=664eb14a-bc2b-4239-a688-d0197f094aff:0x409 http://exch01.thecabal.
   org/exchange/ EXCH01 401 2 2148074254 337 523 100
9  2004-10-29 02:11:59 W3SVC1 exch01.thecabal.org 10.0.0.20 GET /exchange/
   devin/ Cmd=navbar 80 THECABALdevin 10.0.0.10 HTTP/1.1 Mozilla/4.0+
   (compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.0.3705;+.NET+CLR+
   1.1.4322) sessionid=664eb14a-bc2b-4239-a688-d0197f094aff:0x409 http://
   exch01.thecabal.org/exchange/ EXCH01 200 0 0 17646 2234 420
10 2004-10-29 02:11:59 W3SVC1 exch01.thecabal.org 10.0.0.20 GET /exchange/
   devin/Inbox/ Cmd=contents 80 THECABALdevin 10.0.0.10 HTTP/1.1 Mozilla/
   4.0+(compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+CLR+1.0.3705;+.NET+
   CLR+1.1.4322) sessionid=664eb14a-bc2b-4239-a688-d0197f094aff:0x409 http://
   exch01.thecabal.org/exchange/ EXCH01 200 0 0 19616 2242 390

Lines 5 through 10 of the HTTP log sample show the initial requests; the browser is a member of the domain and the OWA server is not using form authentication, so the request is authenticated using NTLM credentials on the second successive request. Lines 7 through 10, in particular, show how the various requests are broken over the cs-method, cs-uri-stem, and cs-uri-query fields.

The following sample NNTP log shows a short NNTP session:

1  #Software: Microsoft Internet Information Services 6.0
2  #Version: 1.0
3  #Date: 2004-10-29 02:14:55
4  #Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method 
   cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken cs-
   version cs-host cs(User-Agent) cs(Cookie) cs(Referer) 
5  2004-10-29 02:14:55 10.0.0.10 <user> NNTPSVC1 EXCH01 10.0.0.20 119 - - - 0 0 0 0 
   21642 NNTP - - - -
6  2004-10-29 02:16:45 10.0.0.10 thecabaldevin NNTPSVC1 EXCH01 10.0.0.20 119 post 
   thecabal.test - 240 600 70 6 108522 NNTP - - - -
7  2004-10-29 02:16:56 10.0.0.10 thecabaldevin NNTPSVC1 EXCH01 10.0.0.20 119 article 
   1+<[email protected]> 1 220 0 669 11 119689 NNTP - - - -
8  2004-10-29 02:17:11 10.0.0.10 thecabaldevin NNTPSVC1 EXCH01 10.0.0.20 119 quit - - 
   205 0 35 6 134621 NNTP - - - -
9  2004-10-29 02:17:11 10.0.0.10 thecabaldevin NNTPSVC1 EXCH01 10.0.0.20 119 - - - 0 0 
   0 0 134621 NNTP - - - -

Line 5 of the NNTP log shows the initial nonauthenticated connection from the client. In line 6, the user creates a new post to the thecabal.test newsgroup. In line 7, this article is retrieved and read. Lines 8 and 9 show the disconnection from the server.

The following sample SMTP log shows an incoming message:

1  #Software: Microsoft Internet Information Services 6.0
2  #Version: 1.0
3  #Date: 2004-10-29 02:12:25
4  #Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method 
   cs-uri-stem cs-uri-query sc-status sc-win32-status sc-bytes cs-bytes time-taken 
   cs-version cs-host cs(User-Agent) cs(Cookie) cs(Referer) 
5  2004-10-29 02:12:25 10.0.0.30 cli01.thecabal.org SMTPSVC1 EXCH01 10.0.0.20 0 EHLO - 
   +cli01.thecabal.org 250 0 317 22 431 SMTP - - - -
6  2004-10-29 02:12:46 10.0.0.30 cli01.thecabal.org SMTPSVC1 EXCH01 10.0.0.20 0 MAIL - 
   +from:<[email protected]> 250 0 43 30 381 SMTP - - - -
7  2004-10-29 02:12:56 10.0.0.30 cli01.thecabal.org SMTPSVC1 EXCH01 10.0.0.20 0 RCPT - 
   +to:<[email protected]> 250 0 36 33 0 SMTP - - - -
8  2004-10-29 02:13:34 10.0.0.30 cli01.thecabal.org SMTPSVC1 EXCH01 10.0.0.20 0 DATA - 
   <[email protected]> 250 0 137 179 34910  
   SMTP - - - -
9  2004-10-29 02:13:36 10.0.0.30 cli01.thecabal.org SMTPSVC1 EXCH01 10.0.0.20 0 QUIT - 
   cli01.thecabal.org 240 75399 73 4 0 SMTP - - - -

Line 5 of the SMTP log shows the initial connection, which uses the EHLO Extended SMTP greeting. Because the cs-username field shows the FQDN of the SMTP client, this connection is not using SMTP authentication.

Lines 6 through 8 show the submission of the message: MAIL FROM and RCPT TO to provide the envelope information and DATA to submit the message itself. At each step, the incoming message passed the various connection, sender, and recipient checks, as shown by the sc-status codes of 250 (OK). Line 9 shows the disconnection.

When trying to write scripts to control protocol logging, you will find a distinct lack of information on how this can be done. In theory, it’s a simple matter of selecting the desired physical server, protocol, and virtual server, then adjusting a few properties in the IIS metabase to control the particular parameters; in reality, there are undocumented interactions with the Exchange extensions to the IIS protocol components. Protocol logging is disabled by default and should be enabled only during troubleshooting and on only the specific virtual servers involved because it has the potential to impact production performance severely. Therefore, we have only included information on enabling protocol logging through the GUI.

Recipe 7.26 for testing the SMTP server through a manual telnet session, MS KB 257265 (General troubleshooting for Exchange 2000 transport issues), MS KB 821910 (How to troubleshoot for Exchange Server 2003 transport issues), and:

for a reference on the properties in the various logging formats

You have a Cisco PIX firewall solution, and you want to make sure that you can send and receive SMTP mail from your Exchange server through it and want to ensure that it is configured to work properly with your Exchange deployment.

On the Cisco PIX, disable the MailGuard (“SMTP fixup”) feature on the PIX firewall, which is on by default. Run the following command from the PIX command line:

no fixup protocol smtp 25

While the Cisco PIX firewall is generally a capable firewall, the MailGuard SMTP proxy feature has long been a source of problems, not just for Exchange, but for SMTP servers in general. The MailGuard functionality works by acting as a semi-transparent proxy for incoming SMTP sessions. MailGuard replaces the outgoing connection banner with a characteristic string of asterisks. Note that even if you believe in the value of banner obfuscation, the PIX-provided banner is distinctive and will immediately alert any potential attacker to the nature of the protection you are using.

It also restricts the incoming SMTP verbs to HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT. It will not allow any other verbs, even valid ESMTP verbs. This will break much of the higher-level SMTP functionality taken for granted in today’s Internet:

These features are highly desirable in many organizations, so if you want any of them, you must rely on other methods to protect your Exchange server. If you don’t want your Exchange server to talk directly to the Internet (and many Exchange administrators don’t), your best approach is to deploy a dedicated border mail router system using a reliable, secure MTA package that contains support for the functionality you need.

Two such packages are Postfix and SendMail; both are fast, reliable mail routing packages with a variety of features that make them a perfect front-end for an Exchange organization. Additionally, both support LDAP directory lookups, which allow them to integrate better with your Exchange organization and reject mail for nonexistent recipients by using direct queries to Active Directory. They can also do lookups via the the NIS server capability in the Windows Services for Unix. Both packages can be run on a Windows server using the Cygwin Linux subsystem.

MS KB 275575 (Client SMTP Authentication Is Enabled, But Relay Does Not Work, Error Message: 550 No Relay Allowed), MS KB 295164 (SMTP Clients Receive Relaying Prohibited Error Message When Authenticated Relay Is Enabled), and MS KB 320027 (Cannot send or receive e-mail messages behind a Cisco PIX firewall)