Chapter 18. Configuring Email-Enabled Content and Exchange Server Integration

IN THIS CHAPTER

• Enabling Incoming Email Functionality in SharePoint
• Working with Email-Enabled Content in SharePoint 2007
• Understanding Microsoft Office Exchange Server 2007
• Planning for an Exchange Server 2007 Environment
• Integrating Exchange 2007 with SharePoint 2007
• Best Practices

One of the most impressive improvements to SharePoint 2007 is the platform’s capability to directly accept email messages and place their contents into SharePoint content, such as document libraries, discussions groups, and lists. This type of functionality has been highly sought by those looking for an alternative to Exchange public folders and those who want to use SharePoint as a messaging records platform.

In addition to serving as an ideal replacement for Exchange public folders, SharePoint 2007 was built with Exchange integration in mind, particularly with the latest version of Exchange—Exchange Server 2007. This chapter focuses on a discussion of the integration points between SharePoint 2007 and Exchange 2007, discussing step-by-step how to take advantage of email-enabled content within SharePoint, how to use Exchange as an outbound relay for SharePoint alerts, and how to integrate Exchange with Outlook Web Access for SharePoint.

A broad overview of Exchange 2007 is also in this chapter, discussing the components that make up Exchange infrastructure and giving a high-level view of Exchange 2007 design.

Enabling Incoming Email Functionality in SharePoint

As previously mentioned, SharePoint 2007 has the capability to process inbound email messages and accept them and their attachments as content for SharePoint document libraries, lists, and discussion groups. Indeed, SharePoint technically does not require the use of Exchange for this component, as it uses its own SMTP virtual server to accept email from any SMTP server, including non-Exchange boxes.

Integration with Exchange, however, has significant advantages for SharePoint. Most notably, new email-enabled content within SharePoint can be configured to have contacts within Exchange automatically created within a specific organizational unit (OU) in Active Directory (AD). This means email administrators don’t need to maintain the email addresses associated with each SharePoint list or document library in the farm.

Installing the SMTP Server Service on the SharePoint Server

The first step to setting up a SharePoint Server as an inbound email platform is to install the SMTP Server Service on the server itself. The process to install the SMTP Service in Windows Server 2003 is straightforward, and can be performed as follows:

1. Click Start, Control Panel, Add or Remove Programs.

2. Click the Add/Remove Windows Components button.

3. Select the Application Server component (do not check the box, just click once on the name of the component) and click Details.

4. Select the Internet Information Services (IIS) component (again, do not check the box, just select the name) and click Details.

5. Scroll down through the list and check the box next to SMTP Service, as shown in Figure 18.1. Click OK, OK, and Next.

Figure 18.1. Installing the SMTP Service.

6. Click Finish.

Configuring the Incoming Email Server Role on the SharePoint Server

After the SMTP Service has been installed on the server, inbound email can be enabled through the SharePoint Central Admin tool. Incoming email functionality can be configured in two ways—automatic mode or advanced mode. Automatic mode sets up inbound mail access using default settings, whereas advanced mode allows more complex configuration. Advanced mode should only be used if the SMTP Service is not used to receive incoming email but is configured to point to a different SMTP server.

To enable incoming email functionality in a SharePoint farm and configure it with the most ideal options, do the following:

1. Open the SharePoint Central Administration tool from the server console (Start, All Programs, Microsoft Office Server, SharePoint 3.0 Central Administration).

2. Click the Operations tab.

3. Under the Topology and Services category, click the Incoming Email Settings link.

4. From the Incoming Email Settings dialog box, shown in Figure 18.2, click Yes to enable sites on the server to receive email.

Figure 18.2. Enabling incoming email settings.

5. Set the Settings mode to Automatic.

6. Select Yes to use the SharePoint Directory Management Service.

7. Enter an Active Directory container where the new distribution groups and contact objects for SharePoint will be created. This OU must be created in AD in advance and the SharePoint service account must have rights to create and modify objects in this OU.

8. Enter the SMTP mail server for incoming mail, which is the SharePoint Server name in this example.

9. Under the setting for accepting messages from authenticated users only, click Yes, so that only authenticated domain users can send email to the server. This setting can be changed to No if you want to accept anonymous email from the Internet into the site content.

10. Scroll down the page and examine the settings listed in Figure 18.3. Check the box to allow the creation of distribution groups from SharePoint sites.

Figure 18.3. Configuring incoming email settings.

11. Enter a display address for the incoming email server. It should include the Fully Qualified Domain Name (FQDN) of the server name so mail messages can be sent to the server. The server in this example is server4.companyabc.com.

12. Finally, configure which email servers from which SharePoint site will accept email. Enter the IP address of any Exchange hub transport servers that will be relaying mail to SharePoint. In this example, 10.10.10.3 is the IP address of the Exchange 2007 server.

13. Click OK to save the changes.

Using the Directory Management Service

The Directory Management Service in SharePoint 2007 uses a timer job within SharePoint to automate the creation of contact objects. These contacts are automatically created to allow inbound mail to document libraries or lists within SharePoint to be automatically enabled.

For example, when a document library called Companyabc-doclib is created and selected to be email enabled, the SharePoint Directory Management Service automatically creates a contact object in Active Directory that has a primary SMTP address of [email protected]. This contact then inherits a secondary SMTP address of [email protected] through Exchange recipient policies.

After the contact is automatically created, users can send email to this address, have it flow through the Exchange server, which then forwards it to the SharePoint Server (the primary SMTP address). It is accepted into the SMTP Virtual Server on the SharePoint Server, and then imported into SharePoint via a timer job that runs on the server. In this way, all emails sent to that address appear in the companyabc-doclib document library.

---

Note

For the Directory Management Service to work, the SharePoint service account needs to have add and modify rights to the OU that is specified in the Incoming Email Settings page. If this account does not have rights to the OU, automation of these contacts will fail. In addition, the SharePoint Web Application must run under domain credentials and not as Local Service or Network Service.

---

Working with Email-Enabled Content in SharePoint 2007

After the SharePoint Server has been set up to allow inbound SMTP messages, specific SharePoint lists and document libraries can be configured to store the contents of the email messages, the attachments in the messages, or both.

Using Email-Enabled Document Libraries

To enable email for a document library in a SharePoint site, do the following:

1. From the document library, click Settings, Document Library Settings (see Figure 18.4).

Figure 18.4. Configuring document library settings.

2. Under the Communications category, click the Incoming Email Settings link.

3. From the incoming email settings for the document library, check to allow the doc library to receive email, as shown in Figure 18.5.

Figure 18.5. Enabling a document library to receive email.

4. Enter an email address. This email address will be added to the contact object that will be created in AD.

5. Select how to handle attachments, whether to save the original .eml file, and what type of security policy you will set on the document library. If messages can be received from any sender, this might open the document library up to spam.

6. Click OK. Usually within a few minutes after the contact object is created, the document library is ready to accept messages.

Configuring Email-Enabled Lists

To enable email for a list within a SharePoint site, a similar process is followed. In this example, a discussion group is email enabled:

1. From the discussion board, click on Settings, Discussion Board Settings.

2. Under the Communications category, shown in Figure 18.6, click on Incoming Email Settings.

Figure 18.6. Email enabling a discussion board.

3. Enter the same type of data as was necessary in the document library setup, such as email address, security policy, and whether to save the original emails.

4. Click OK to save the settings.

This same process can be followed for any document library or list within the SharePoint farm.

Understanding Microsoft Office Exchange Server 2007

Exchange Server 2007 is the evolution of a product that has been continuously improved by more than a decade of development. It has robust messaging capabilities, in addition to a dizzying array of new functionality. The one area of development that has always been missing in Exchange, however, has been the collaboration and document management capabilities. Attempts to build this functionality in Exchange public folders were short-lived, and Microsoft shifted development of this aspect of Exchange to the SharePoint products and technologies that are the subject of this book.

Taking the history of development with Exchange into account, SharePoint 2007 is the collaboration piece of Exchange that has always been missing in the platform. Because of this codependence between the platforms, many Exchange environments are considering deploying SharePoint 2007, and vice versa. Subsequently, an in-depth knowledge of Exchange 2007 is highly useful for SharePoint administrators. This section of this chapter focuses on a high-level overview of what Exchange 2007 is and how it fits within a SharePoint 2007 environment.

Outlining the Significant Changes in Exchange Server 2007

The major areas of improvement in Exchange Server 2007 are focused on several key areas. The first is in the realm of user access and connectivity. The needs of many organizations have changed and they are no longer content with slow remote access to email and limited functionality when on the road. Consequently, many of the improvements in Exchange focus on various approaches to email access and connectivity. The improvements in this group focus on the following areas:

• Access anywhere improvements—Microsoft has focused a great deal of Exchange Server 2007 development time on new access methods for Exchange, including an enhanced Outlook Web Access (OWA) that works with a variety of MS and third-party browsers, Outlook Mobile improvements, new Outlook Voice Access (OVA), Unified Messaging support, and Outlook Anywhere (formerly known as RPC over HTTP). Having these multiple access methods greatly increases the design flexibility of Exchange, as end users can access email via multiple methods.
• Protection and compliance enhancements—Exchange Server 2007 now includes a variety of antispam, antivirus, and compliance mechanisms to protect the integrity of messaging data. These mechanisms are also useful for protecting SharePoint email-enabled content from viruses and spam.
• Admin tools improvements and PowerShell scripting—The administrative environment in Exchange 2007 has been completely revamped and improved, and the scripting capabilities have been overhauled. It is now possible to script any administrative command from a command-line MONAD script. Indeed, the GUI itself sits on top of the PowerShell scripting engine and simply fires scripts based on the task that an administrator chooses in the GUI. This allows an unprecedented level of control.
• Local continuous replication and cluster continuous replication—One of the most anticipated improvements to Exchange Server has been the inclusion of local continuous replication (LCR) and cluster continuous replication (CCR). These technologies allow log-shipping functionality for Exchange databases, allowing a replica copy of an Exchange database to be constantly built from new logs generated from the server. This gives administrators the ability to replicate in real time the data from a server to another server in a remote site or locally on the same server.

Outlining Exchange Server 2007 Server Roles

Exchange Server 2007 introduced the concept of server roles to Exchange terminology. In the past, server functionality was loosely termed, such as referring to an Exchange Server as an OWA or front-end server, bridgehead server, or a mailbox or back-end server. In reality, there was no set terminology that was used for Exchange server roles. Exchange Server 2007, on the other hand, distinctly defines specific roles that a server can hold. Multiple roles can reside on a single server, or there can be multiple servers with the same role. By standardizing on these roles, it becomes easier to design an Exchange environment by designating specific roles for servers in specific locations.

The concept of server roles is not unique to Exchange because it is also included as a concept for SharePoint servers, with roles such as Search and Index, Web, Database, Excel Services, and the like driving design decisions for SharePoint.

The server roles included in Exchange Server 2007 include the following:

• Client Access Server—The Client Access Server (CAS) role allows client connections via nonstandard methods such as Outlook Web Access (OWA), Exchange ActiveSync, POP3, and IMAP. CAS servers are the replacement for Exchange 2000/2003 front-end servers and can be load balanced for redundancy purposes. As with the other server roles, the CAS role can co-exist with other roles. This is useful for smaller organizations with a single server, for example.
• Edge Transport Server—The Edge Transport Server role is unique to Exchange 2007, and consists of a standalone server that typically resides in the DMZ of a firewall. This server filters inbound SMTP mail traffic from the Internet for viruses and spam, and then forwards it to internal hub transport servers. Edge transport servers keep a local Active Directory in Application Mode (ADAM) instance that is synchronized with the internal AD structure via a mechanism called EdgeSync. This helps to reduce the surface attack area of Exchange.
• Hub Transport Server—The Hub Transport Server role acts as a mail bridgehead for mail sent between servers in one AD site and mail sent to other AD sites. At least one multiple hub transport server within an AD site needs to contain a server with the Mailbox Server role, but there can also be multiple hub transport servers to provide redundancy and load balancing.
• Mailbox Server—The Mailbox Server role is intuitive. It acts as the storehouse for mail data in users’ mailboxes and down-level public folders if required. It also directly interacts with Outlook MAPI traffic. All other access methods are proxied through CAS.
• Unified Messaging Server—The Unified Messaging Server role is new in Exchange 2007 and allows a user’s inbox to be used for voice messaging and faxing.

Any or all of these roles can be installed on a single server or on multiple servers. For smaller organizations, a single server holding all Exchange roles is sufficient. For larger organizations, a more complex configuration might be required.

Planning for an Exchange Server 2007 Environment

It is important for a SharePoint administrator to understand the deployment options for Exchange if considering integrating SharePoint with an Exchange environment. This is particularly important as both applications can make heavy use of the Active Directory domain service. An in-depth look at Exchange 2007 itself is subsequently ideal.

Planning for Exchange Active Directory Design

Because Exchange Server 2007 uses Active Directory for its underlying directory structure, it is necessary to link Exchange with a unique Active Directory forest.

In many cases, an existing Active Directory forest and domain structure is already in place in organizations considering Exchange 2007 deployment. In these cases, Exchange can be installed on top of the existing AD environment, and no additional AD design decisions need to be made. It is important to note that Exchange 2007 can only be installed in a Windows Server 2003 Active Directory forest. Windows 2000 forests are not supported.

In some cases, an existing AD infrastructure might not be in place, and one needs to be deployed to support Exchange. In these scenarios, design decisions need to be made for the AD structure in which Exchange will be installed. In some specific cases, Exchange may be deployed as part of a separate forest by itself, as illustrated in Figure 18.7. This model is known as the Exchange resource forest model. The Exchange resource forest is often used in an organization with multiple existing AD forests.

Figure 18.7. Understanding the Exchange resource forest model.

In any case, AD should be designed with simplicity in mind. A single-forest, single-domain model, for example, will solve the needs of many organizations. If Exchange itself is all that is required of AD, this type of deployment is the best one to consider.

---

Note

The addition of Exchange 2007 into an Active Directory forest requires an extension of the AD forest’s Active Directory schema. Considerations for this factor must be taken into account when deploying Exchange onto an existing AD forest.

---

Microsoft has gotten serious recently about support for Exchange Server across multiple forests. This was previously an onerous task to set up, but the capability to synchronize between separate Exchange organizations has been simplified through the use of Microsoft Identity Integration Server (MIIS) 2003. MIIS now comes with a series of preconfigured scripts to replicate between Exchange forests, enabling organizations which, for one reason or another, cannot use a common forest to unite the email structure through object replication.

Planning for the Mailbox Server Role

The Mailbox Server role is the central role in an Exchange topology as it is the server that stores the actual mailboxes of the user. Subsequently, mailbox servers are often the most critical for an organization, and are given the most attention.

With the Enterprise version of Exchange, a mailbox server can hold anywhere from 1 to 50 databases on it. Each of the databases is theoretically unlimited in size, although it is wise to keep an individual database limited to 100GB or less for performance and recovery scenarios.

---

Note

In large organizations, a single server or a cluster of servers is often dedicated to individual server roles. That said, a single server can also be assigned other roles, such as the Client Access Server role, in the interest of consolidating the number of servers deployed. The only limitation to this is the Edge Server role, which must exist by itself and cannot be installed on a server that holds other roles.

---

Planning for the Client Access Server Role

The Client Access Server (CAS) role in Exchange is the role that controls access to mailboxes from all clients that aren’t Microsoft Outlook and that don’t utilize MAPI connections. It is the component that controls access to mailboxes via the following mechanisms:

• Outlook Web Access (OWA)
• Exchange ActiveSync
• Outlook Anywhere (formerly RPC over HTTP)
• Post Office Protocol (POP3)
• Interactive Mail Access Protocol (IMAP4)

In addition, CAS servers also handle the following two special services in an Exchange topology:

• Autodiscover service—The Autodiscover service allows clients to determine their synchronization settings (such as mailbox server and so forth) by entering in their SMTP address and their credentials. It is supported across standard OWA connections.
• Availability service—The Availability service is the replacement for Free/Busy functionality in Exchange 2000/2003. It is responsible for making a user’s calendar availability visible to other users making meeting requests.

Client access servers in Exchange 2007 are the equivalent of Exchange 2000/2003 front-end servers, but include additional functionality above and beyond what front-end servers performed. In addition, one major difference between the two types of servers is that CASs in Exchange 2007 communicate via fast RPC between themselves and mailbox servers. Exchange 2000/2003 servers used unencrypted HTTP to communicate between the systems.

---

Note

In addition to providing HTTP access to Exchange data, CASs fulfill an important role in regards to SharePoint. They provide a direct link to SharePoint sites via the Outlook Web Access interface. Indeed, the Exchange 2007 version of OWA does not even include the capability to access public folders, but instead only allows SharePoint access as an alternative. This illustrates Microsoft’s continuing drive to replace public folders with SharePoint.

---

Planning for the Edge Transport Role

The Edge Transport role is new in Exchange 2007 and is a completely new concept. Edge transport servers are standalone, workgroup members that are meant to reside in the DMZ of a firewall. They do not require access to any internal resources, save for a one-way synchronization of specific configuration information from Active Directory via a process called EdgeSync.

Edge transport servers hold a small instance of Active Directory in Application Mode (ADAM), which is used to store specific configuration information, such as the location of hub transport servers within the topology. ADAM is a service that is often known as Active Directory Light, and can be thought of as a scaled-down version of a separate Active Directory forest that runs as a service on a machine.

The Edge Transport role provides spam and virus filtering, as Microsoft has moved the emphasis on this type of protection to incoming and outgoing messages. Essentially, this role is a method in which Microsoft intends to capture some of the market taken by SMTP relay systems and virus scanners. The market has traditionally been dominated by third-party products provided by virus-scanning companies and Unix SendMail hosts.

In large organizations, redundancy can be built into Edge Transport services through simple round-robin DNS or with the use of a third-party load-balancing service between requests sent to the servers.

Planning for the Hub Transport Role

The Hub Transport role is responsible for the distribution of mail messages within an Exchange organization. At least one Hub Transport role must be defined for each Active Directory site that contains a mailbox server.

---

Note

The Hub Transport role can be added to a server running any other role, with only two exceptions. It cannot be added to a server that is an edge transport server, and it cannot be added to a server that is part of a cluster node.

---

Several special considerations exist for hub transport servers, as follow:

• Multiple hub transport servers can be established in a site to provide redundancy and load balancing.
• Exchange 2007 built-in protection features (antivirus and antispam) are not enabled by default on hub transport servers. Instead, they are enabled on edge transport servers. If needed, they can be enabled on a hub transport server by running a Management Shell script.
• Messaging policy and compliance features are enabled on hub transport servers and can be used to add disclaimers, control attachment sizes, encrypt messages, and block specific content.

Planning for the Unified Messaging Role

The Unified Messaging role in Exchange 2007 is a new concept for Exchange technologies. This role allows fax, voicemail, and email to all be integrated into a user’s mailbox.

The Unified Messaging role can be installed on multiple servers, although it is recommended that it only be installed when the infrastructure to support it exists in the organization. The Unified Messaging role requires integration with a third-party Telephone Hardware provider. As Exchange 2007 progresses, this role will become more important.

Understanding a Sample Deployment Scenario

A better understanding of Exchange server roles can be achieved by looking at sample deployment scenarios that utilize these roles. For example, Figure 18.8 illustrates a large enterprise deployment of Exchange that takes advantage of all the unique server roles.

Figure 18.8. Examining an enterprise Exchange deployment.

In this design, the following key deployment features are illustrated:

• Cluster continuous replication (CCR) clusters of Exchange mailbox servers are distributed between the two main locations.
• Dedicated hub transport servers distribute mail between the two major sites in San Francisco and Zurich.
• Medium-sized sites, such as Kiev and Lisbon, make use of combined mailbox/hub transport server systems.
• Client access servers are set up in the two main sites to provide two Internet presences for OWA and Outlook Anywhere.
• Edge transport servers process inbound and outbound mail in the DMZ locations in San Francisco and Zurich.
• Unified messaging servers exist in the main hub sites and are provided as a service for users in those locations. The servers are directly connected to PBX systems in those locations.
• Smaller sites, such as Minneapolis, Odessa, and Singapore, have their mailboxes hosted in the two hub locations and use the CASs with Outlook Anywhere to access their mailboxes remotely.

Integrating Exchange 2007 with SharePoint 2007

In addition to allowing inbound mail access from Exchange directly into SharePoint libraries and lists, SharePoint 2007 and Exchange 2007 also contain several other integration points. These include the capability to relay outgoing alert messages through the Exchange server and the capability for personal sites to link directly to Exchange inboxes, calendars, and other information directly from a SharePoint site.

Using an Exchange Server as an Outgoing Email Server for SharePoint

SharePoint needs an external SMTP server to relay alerts and reports to farm users. This server needs to be configured to allow access and relaying from the SharePoint server. To set up an outgoing email source within a SharePoint farm, do the following:

1. Open the SharePoint Central Administration tool from the server console (Start, All Programs, Microsoft Office Server, SharePoint 3.0 Central Administration).
2. Click the Operations tab.
3. Under the Topology and Services category, click the Outgoing Email Settings link.
4. From the page shown in Figure 18.9, enter the FQDN of the outbound SMTP server (the Exchange server). Enter a From address, a Reply-to address, and leave the character set as the default. Click OK to save the settings.

Figure 18.9. Enabling an outgoing email server.

Linking to Calendars, Contacts, and Inbox Items in Exchange 2007 from SharePoint Sites

SharePoint 2007 web parts provide smooth integration with Exchange Outlook Web Access (OWA), allowing for inboxes, calendars, and other mail data to be accessed directly from a SharePoint site. SharePoint 2007 contains built-in web parts to link to Exchange OWA content and integrates best with Exchange 2007 OWA. Older versions of Exchange, such as Exchange 2003 OWA, are supported, but the integration is not as tight.

Using SharePoint 2007 to Replace Exchange Public Folders

As previously mentioned, SharePoint 2007 is listed as the successor to public folder technology in Exchange 2007. SharePoint functionality has slowly been replacing all of Exchange’s public folder functionality, and is close to providing all of the functionality that was previously provided by public folders. With the concept of email-enabled content, where emails are automatically added to content libraries and lists, SharePoint moves even closer to this goal.

Summary

SharePoint 2007 is the missing collaboration side of the Exchange 2007 platform, providing Exchange users with advanced document management and portal capabilities. With the capability for email-enabled content, SharePoint allows administrators to receive inbound emails directly into document libraries and lists, further extending the capabilities of the platform.

In addition to email-enabled content capabilities, SharePoint 2007 has other strong integration points with Exchange 2007, including outbound alert forwarding and OWA inbox and calendar web parts. It is subsequently not a surprise when Exchange 2007 and SharePoint 2007 are often installed together in many environments.

Best Practices

• Use the Directory Management Service to automate the creation of AD contacts that correspond to email-enabled content on the SharePoint server.
• Restrict receiving email messages only from the IP addresses of Exchange Servers to avoid having your SharePoint Server used as a relay for spam.
• Replace public folders with SharePoint technologies wherever possible, as Microsoft is deprecating support for public folders in the near future.
• Incorporate SharePoint 2007 design concepts with Exchange 2007, so that both components can fit into an overall messaging and collaboration strategy.