7 Things You Need to Know About SharePoint Services

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.

#5: Exchange Needs to Accept SMTP Email from SharePoint
SharePoint relieves users from the pain of periodically checking various pages on the server to find out whether new content has been added or updated to Share-Point. To do so, it emails alerts whenever content of interest to the user changes (e.g., someone created a new task or changed an event on the calendar). If users complain that they aren't getting these alerts, you're looking at one of two probable causes: The Exchange server is refusing to accept these SMTP alerts, or you haven't configured SharePoint with the address of your Exchange server or other SMTP server. To configure SharePoint to send alerts, click the Configure default e-mail server settings link in SharePoint Central Administration and fill in the Outbound SMTP server and From e-mail address fields as appropriate. Specify the DNS name or IP address of an SMTP server that's reachable from your SharePoint server, and make sure the SMTP server can route email to internal employees as well as external addresses on the Internet (if your SharePoint site will be accessible to outside business partners such as consultants, contractors, or clients). Specify an email address that Share-Point can use as the From address for all alert emails. Next, make sure your SMTP server can accept anonymous SMTP connections from your Share-Point server.

Since email servers are typically locked down tightly because of spam, you might need to configure an exception for the SharePoint server in the email server's policy. I've also seen antispam solutions block SharePoint alerts, so make sure your SharePoint server is configured as a trusted sender. If you send SharePoint alerts out to external users who use other email servers, make sure your Share-Point server is listed as a trusted sender in the Sender Policy Framework (SPF) record in your DNS zone file, or that you route SharePoint alerts through an existing SMTP server already defined in your SPF record.

#6: You Can Link SharePoint Document Libraries to Exchange Public Folders
SharePoint document libraries provide a simple way to publish, share, collaborate, and maintain documents by using Web browsers or Web Distributed Authoring and Versioning (WebDAV)-enabled applications such as Microsoft Office 2003 and Windows Explorer. Wouldn't it be nice to be able to add new documents to a document library by simply emailing the document as a file attachment to the right address? You can do so by linking a SharePoint document library to a mail-enabled public folder in Exchange.

First, create the public folder in Exchange. Then, grant the SharePoint server Read access to this public folder. If your SharePoint application pool is running in the context of the NetworkService account (the default), simply grant the computer account in which SharePoint is running Read access to this public folder. Next, grant the appropriate users authority to post to the public folder, such as through a DL. Then, create an email address for the folder and configure the folder to receive email. Back on the SharePoint Central Administration page, click Configure virtual server settings. On the next page, click Default Web Site, then Virtual server general settings, and look for the EMail Enabled Document Libraries section, which Figure 2 shows. Enter the root URL of public folders on your Exchange server. (For example, in Figure 2, you'll see that my Exchange server is mtg1, so the full URL is http://mtg1/public.) Finally, you need to link a specific document library with the public folder. Browse to the document library in SharePoint and click Modify settings and columns, then click Change advanced settings, which displays the page you see in Figure 3. In the Public folder address field, simply enter the name of the public folder on the Exchange server. (In this example, the folder is named Documents.)

Now, when you send email to [email protected], Exchange will drop the email into the Documents folder. Then, SharePoint will check the email for attachments and copy any files to the Shared Documents library. The body of the message isn't copied to SharePoint, nor can you configure SharePoint to fill in any other fields you might add by customizing the document library. Public folder-to-document library integration applies only to file attachments. For further details about how to set up this integration, see the Microsoft article "Configuring E-Mail-Enabled Document Libraries" (http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stse15.mspx?mfr=true).

#7: Backing Up SharePoint Differs from Backing Up Exchange
Before you know it, users will be storing important, irreplaceable information in SharePoint, which means you have yet another application to back up. Although Windows Backup will natively back up Exchange Information Store (IS) data, most backup applications don't natively support SharePoint. The good news is that backing up SharePoint is easy, and you have two options.

The first option is to back up a SharePoint site from the command line by using the Stsadm tool (stsadm.exe). With Stsadm, you back up SharePoint to a specified file, which you then include in your usual filelevel tape backup. (For more information about using Stsadm, see the Microsoft article "Backup and Restore Options for Windows SharePoint Services" at http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsf20.mspx?mfr=true.) The second option (available if you're using SQL Server) is to include the SharePoint databases in your usual SQL Server backups. Because SharePoint stores all its content in SQL Server, SQL Server backups provide the fastest way to back up a SharePoint site. Stsadm lets you back up and restore individual Share-Point sites, whereas SQL Server backups occur at the SQL Server database level, which typically holds multiple SharePoint sites.

Ensure a Smooth Rollout
SharePoint keeps getting more enticing, and it's increasingly a good direction in which Exchange administrators can extend their skills. Make sure you understand the basics of IIS, and keep this article's tips in mind when you implement SharePoint to ensure a smooth rollout that leverages everything SharePoint, Exchange, and Outlook offer.