Learn ways to give your Exchange users easy access to SharePoint content
As former members of a small IT shop in a large organization, we served as both Exchange and SharePoint administrators. When replacing our old Active Server Pages (ASP)-based corporate intranet, we decided to bring Microsoft SharePoint technologies into our existing Windows environment and create a corporate intranet that improved collaboration and communications among end users by integrating SharePoint and Exchange. You can configure Exchange and Windows SharePoint Services or Microsoft SharePoint Portal Server (referred to here, respectively, as SharePoint Services and Portal Server) to enable similar collaboration capabilities in your environment by using Web Parts and features that let Exchange users access SharePoint document libraries and view Exchange public-folder content in SharePoint. We'll focus on integrating Exchange Server 2003, Microsoft Office Outlook 2003, Share-Point Portal Server 2003, and the version of SharePoint Services that's included in Windows Server 2003, although if you're using earlier versions of any of these products, you can still integrate them to a lesser degree. (For more information about integrating SharePoint data into Outlook 2003, see the Web-exclusive sidebar, "Bringing SharePoint to Outlook" at http://www.windowsitpro.com, InstantDoc ID 93700.)
Page Viewer Web Parts
Web Parts, the programmable and configurable portions of SharePoint portal sites, are an important means for enabling Exchange-SharePoint integration. One Web Part that you'll find useful in giving your Exchange users access to SharePoint is the Page Viewer Web Part, which is part of SharePoint Services. The Page Viewer Web Part, which functions like an IFRAME element in a Web application and works with all versions of Exchange and Microsoft Outlook Web Access (OWA), enables the display of any Web page-content from within a Web part. You can set the Page Viewer Web Part to display an OWA page via a SharePoint site.
You can use the Page Viewer Web Part to let users view public folders from within SharePoint and without having to open Outlook, as Figure 1 shows. To do so, you set the URL of the Page Viewer Web Part to the URL of the target public folder. If you want users to see only the contents of the particular folder and not the left folder pane (i.e., the entire list of public folders), as Figure 2 shows, simply append the cmd=contents parameter to the end of the public folder's URL.
To prevent OWA from displaying a logon prompt within a Page Viewer Web Part, be sure to enable Windows Authentication on your Exchange server. (Of course, this works only if the user's computer is part of the same domain as the SharePoint server or if the SharePoint server is in a trusted domain.) If you're attempting to connect to the Exchange server through a SharePoint portal from an external location, you'll want to set up a single sign-on (SSO) solution, which uses a Kerberos authentication token. There are many such Web-access-management solutions, such as RSA Security's RSA Access Manager. (You can find out more about RSA Access Manager in the RSA white paper RSA Access Manager: Secure Web Access Management Solutions for Microsoft Windows Environment, which you can download at http://www.rsasecurity.com/ node.asp?id=1186.)
Be aware that in a production environment, you'll want to install Share-Point on a different machine than the one Exchange and OWA are on. As you're probably aware, Microsoft IIS must be installed to host the OWA client sessions. If you're using OWA, you need to be careful when installing SharePoint into your current Exchange environment. In SharePoint, the Internet Server API (ISAPI) filter in SharePoint handles all incoming URLs (i.e., directs a URL to the requested folder path) and also lets you exclude certain paths from browsing. The ISAPI filter's actions effectively prevent a non-SharePoint Web application from running on the same server without some additional setup and configuration. Although you can exclude Exchange 2003 directories and folders from browsing in Share-Point, it's better to run Exchange and SharePoint on different hardware.
Exchange Web Parts in Portal Server
Portal Server ships with Web Parts that provide discretely configurable bits of functionality, such as event lists and drop-down menus, and includes four Exchange-specific Web Parts that enable SharePoint-Exchange integration: My Inbox, My Calendar, My Tasks, and My Mail Folder (their respective definition files are owainbox.dwp, owacalendar.dwp, owatasks.dwp, and owa.dwp). These Web Parts don't work with SharePoint Services and are supported only in Exchange 2003 and later. By placing one of these Web Parts on an individual's My Site in Portal Server, you can grant the user a Web view of his or her Inbox, Calendar, Tasks, and other Exchange mail folders. (Note that users of Internet Explorer—IE—5.0 or later will see a different view of Exchange Web Parts than users of other browsers, so you'll need to keep in mind which browser(s) your users are using when you plan your SharePoint site's layout.) Figure 3 shows the Web Part list that's displayed in the Web Part Tool Pane in SharePoint, and Figure 4, shows what the user sees via the My Mail Folder Web Part.
When you configure Exchange Web Parts on your SharePoint site, you need to set up each Web Part with the Exchange server's Web address (this is the same URL a user would type into a browser to access OWA) and the individual user's Exchange username. The My Mail Folder Web Part also requires the actual Exchange folder name in a folder/subfolder format. If the specified folder happens to be a calendar or task list, the items in the My Mail Folder Web Part are displayed as they would in the My Calendar or My Tasks Web Parts. This behavior occurs because all the personalized Exchange Web Parts are basically Page Viewer Web Parts with some specific formatting applied. Finally, when you add the Exchange Web Parts to a SharePoint site, be sure to add your Exchange server's OWA URL to the trusted Local Intranet sites on the client machines. Doing so helps prevent multiple logon prompts.
Setting up Exchange Web Parts can be tricky, depending on your IT staff's SharePoint skill level. One source of help is Kristof De Causemaeker's solution for developing your own Web part with Microsoft Visual Studio to set up your portal's MyInbox Web Parts automatically. You can find this solution on his blog, The SharePoint Factory, at http://spsfactory.blogspot.com/2005/12/how-to-configure-your-myinbox-webpart.html.
If the Exchange Web Parts don't meet your needs, or if you're working with SharePoint Services, you could develop your own Web Part or use a third-party SharePoint Web Part such as the My Workplace for Outlook Web Part from CorasWorks (http://www.corasworks.net/products/web parts/outlookintegration.asp) and the WSS Mail Web Part from Blue Dog Limited (http://www.bluedoglimited.com/downloads/default.aspx). My Workplace for Outlook lets you view Outlook data in SharePoint sites, display a single-page summary of Outlook data in an "Outlook Today" format, and download SharePoint contact, task, and event information directly into Outlook, whereas WSS Mail functions essentially the same as Portal Server's My Inbox Web Part.
Viewing Document Libraries via Explorer
Although our company's users are generally familiar with Web applications and the idiosyncrasies of working in a particular Web browser, most are far more comfortable working with Windows Explorer, the My Documents folder, and network shares. Fortunately, SharePoint lets users connect to document libraries through Windows Explorer, which gives the users a comfortable view into the SharePoint libraries.
To access a SharePoint document library via Explorer, you simply click the link to a Web folder in the user's My Network Places folder, as Figure 5 shows. Although this view is convenient for users, it poses a potential problem. A document added to a library via an Explorer-style drag-and-drop operation doesn't prompt for metadata (e.g., a status column indicating a document's review status). Therefore, examine the document library's columns to know what metadata your document library might require before adding these Web folders to your users' My Network Places.
To enable users to access Share-Point document libraries via Windows Explorer, you can either do so by using a Group Policy Object (GPO) or by adding a Web-folder link to your SharePoint document library to your users' list of My Network Places. To add a Web folder manually, open the My Network Places folder and start the Add Network Place Wizard. To learn more about using a Windows 2003 GPO to provide access to document libraries via Explorer as well as where to get the latest Group Policy Management Console (GPMC), visit the Windows 2003 Group Policy section on TechNet (http://technet2.microsoft.com/windowsserver/en/technologies/featured/gp/default.mspx).
Email-Enabled Document Libraries
Most Exchange users are familiar with using Exchange public folders as a repository for publicly available messages and documents. SharePoint's ability to capture and display messages helps it fit easily into your users' culture. Users can save important email in public folders and SharePoint document libraries. To save an email message in a document library from Outlook 2003, you simply select File, Save As from inside the message, and you'll see a screen like that in Figure 6. Notice that you can save a message in multiple formats, such as an HTML or email file type. When you save the message, choose the correct Network Place that corresponds to a document library to save it in, and future users of that document library can read the message as if it had been saved in a public folder.
Another easy way to help users become more comfortable with Share Point is to create an email-enabled document library. This is really a mail-enabled Exchange public folder that uses built-in SharePoint functionality to copy all message attachments into a SharePoint document library. Because the public folder actually has an email address assigned to it, any user can post new documents in the document library.
Thanks to the flexibility of Exchange's security settings, you can even allow users who typically wouldn't have permissions to post to the SharePoint document library—such as users outside your organization—to do so. Documents in the mail-enabled public folder are automatically inserted in the document library, which displays the document, the From address, the original message's subject, and the date and time the attachment was copied to the document library. A mail-enabled public folder can be especially useful with Microsoft Office InfoPath forms and XML information. Users simply mail the XML document to the email address associated with the public folder, and the document is automatically copied to the document library, where it's available for automated aggregation and reporting.
When planning your email-enabled document libraries, you need to consider a few points. Email and accompanying attachments can cross firewall boundaries, so that any user or external sender can post new documents, but this capability also exposes SharePoint to possible spam messages and viruses. To protect your SharePoint portal, be sure to set up junk email filters in Exchange and virus scanning in both SharePoint and Exchange. Controlling access rights to the email-enabled document library is a double-duty task, as you now have to administer security rights on the document library itself via SharePoint Services and the public-folder posting-security rights via the Exchange user management tools. A good practice is to use your Active Directory (AD) groups to help with the management of both SharePoint cross-site groups (i.e., custom security groups that can be applied to more than one Web site) and Exchange.
Public folder postings that are mailed to a public folder frequently contain both the document attachment and text in the message body. However, only the attachment is copied to the document library in SharePoint. If you want to save the message text in the document library, you need to save it manually into the library via a Network Places link or an HTTP path.
Since documents are actually copied from the Exchange public folder to the SharePoint document library, storage requirements on the server are doubled as the document is now stored both in Exchange and Share-Point. Consider using quotas to control the size of the SharePoint site. Otherwise, you might find yourself frequently cleaning up the public folders.
One final point to keep in mind: Using email-enabled document libraries is a one-way process. New documents and updates to documents aren't copied from the Share-Point document library back to the Exchange public folder. This is also true of the Exchange Web Parts: You can't use the Web Parts to create new messages, tasks, or calendar events; only to view a mail folder's contents.
As you've seen, several methods exist for integrating Exchange/Outlook and SharePoint. By giving users the ability to view the contents of their mailboxes, email attachments, or public folders from within SharePoint, you can help them become more comfortable working within the Share-Point interface and better use the collaboration features of both technologies.
Microsoft Office System Business Value White Paper, especially Appendix A
Microsoft technical overview of Windows Security Services
SharePoint Resource Kit
Windows Server 2003 Group Policy section on TechNet http://technet2.microsoft.com/windowsserver/en/technologies/featured/gp/default.mspx
The SharePoint Factory