More and more companies are rolling out Windows SharePoint Services to exploit the product's Web-based collaboration, information-sharing, and workflow capabilities. Microsoft once positioned Exchange Server as its workflow and collaboration tool, but the company's Exchange road map now focuses Exchange exclusively on messaging, and SharePoint has assumed the role of Microsoft's workflow and collaboration technology.
As you might know, SharePoint is a very different animal from Exchange, and although you'll find integration points between SharePoint, Exchange, Outlook, and Microsoft Outlook Web Access (OWA), they come with a few important caveats. Given that Exchange administrators are typically the go-to people for rolling out and administering SharePoint, you would do well to heed these seven points I've come up with in regard to supporting all these technologies.
#1: SharePoint Is an IIS Application
End users and management frequently confuse SharePoint with its overall relationship to Exchange and Outlook, thanks to the way marketing hype presents these technologies as occupying a seamless environment. Under the hood, however, SharePoint is a distinct application. Like OWA, SharePoint is a Microsoft IIS application, but instead of accessing Exchange, SharePoint stores all its content in a Microsoft SQL Server or Microsoft SQL Server Desktop Engine (MSDE) database. Therefore, if you need to be able to perform full text searching of content (including uploaded documents), you must use SQL Server or implement Microsoft SharePoint Portal Server. Internally, SharePoint uses an Internet Server API (ISAPI) filter, but it's primarily implemented in ASP.NET, so that advanced configuration of SharePoint sometimes involves modifying XML files that ASP.NET uses. Although not strictly required, some familiarity with ASP.NET and XML will help you if you need to perform more advanced SharePoint administration tasks, such as customizing SharePoint or installing extensions called Web Parts. A basic IIS understanding is a must.
#2: SharePoint Integrates Tightly with AD
Like Exchange, SharePoint leverages Active Directory (AD) for user accounts and authentication. You can reuse groups already defined in AD for controlling access to resources in SharePoint. For example, you might already have an HRStaff AD security group that you use to control access to HR documents on the file server and as a distribution list (DL) in Exchange. Suppose you create a new announcement list in your SharePoint site for the purpose of allowing HR to post job openings to company employees. You can use the same AD group HRStaff to give HR employees access to the announcement list.
However, although Exchange supports both security and distribution groups from AD, SharePoint lets you use only security groups; you can't use Distribution Groups (DGs) to control access to SharePoint resources. I recommend using security groups anyway, because only security groups let you control access to objects (e.g., files, folders, SharePoint resources, SQL Server tables), and Exchange is happy to distribute email to members of either type of group.
#3: Don't Install SharePoint on a Server Already Running OWA
It's ostensibly possible for SharePoint and OWA to coexist on one server, but I don't recommend it unless absolutely necessary. SharePoint disables Kerberos authentication, which OWA requires, and some environments encounter problems associated with the default IIS behavior of reusing HTTP connections. To address these two conflicts, see the Microsoft article"Exchange Server 2003 and Outlook Web Access Issue" (http://www.microsoft.com/exchange/support/e2k3owa.mspx).
Another concern involves the fact that, by default, both SharePoint and OWA install into the Web site that IIS creates by default on your system. Because SharePoint's ISAPI filter—stsflt.dll—intercepts all incoming requests, users will get a 404 Page Not Found error when they try to access OWA. To overcome this problem, you'll need to configure Share-Point to not intercept requests to OWA's virtual directories. To do so, you configure the directories as excluded paths. To manage excluded paths, go to Administrative Tools and open SharePoint Central Administration. Select Configure virtual server settings and click Default Web Site. Finally, click the Define managed paths link, which displays the Define Managed Paths page that Figure 1 shows. On this screen, you'll see all the virtual directories you need to configure as excluded paths.
#4: SharePoint Integrates with Outlook—but Only One Way
SharePoint provides Web-based sharing of lists for helping teams coordinate their activities. SharePoint lists include prebuilt list types such as tasks, contacts, and calendar events, but you can also build your own custom lists. Although Web access is a great way to make information available to everyone on the team, some users will inevitably want access to this information when they're offline or through Outlook, in which they're accustomed to handling tasks, contacts, and calendar items. The good news is that SharePoint contacts and calendars are accessible from Microsoft Office Outlook 2003—but in read-only mode. Outlook caches a local copy of SharePoint contact and calendar event lists that you specify, letting you perform such tasks as viewing SharePoint calendars alongside your Outlook calendar, even when you're offline. But to update any SharePoint information, you'll have to wait until you're back online and can access the SharePoint server. At this time, Outlook 2003 doesn't integrate with SharePoint tasks.