12

Nov

MOSS Email Enabled Lists – implementation best practice

SharePoint provides a fantastic feature in Email Enabled Document libraries and lists. This feature allows users to send email which is automatically incorporated into SharePoint lists or document libraries. Intergen is currently developing a solution for a customer where people can have appointments emailed to them, made available inside their calendars, as well as being displayed in a SharePoint library. This allows them greater collaboration amongst staff and visibility into other people’s schedules.

There are plenty of instructions available on the internet detailing how to configure SharePoint Email Enabled lists. However, many of these instructions don’t follow SharePoint or infrastructure best practices. This blog post won’t provide all of the specific detail to set up email enabled lists, nor will it attempt to re-write any of these instructions. What it will do is bring together two existing, well written articles to provide a complete set of best practice instructions for a successful and secure implementation.

It is a valuable article to publish, gauged by the number of blogs, contributions to blogs, and the amount of time spent looking for the “right way to do it”, where technologists are caught in the tug-of-war between providing feature rich applications, and following their best practice instincts. In this instance, it is apparent that a complete set of working instructions is not easy to find.

This TechNet library article provides a fantastic set of instructions to configure incoming email for Office SharePoint Server. It details specific changes to permissions on the SharePoint application server file system, to appropriate Active Directory Organisational Units, how to set up your local SMTP server, Exchange Server and your DNS implementation. It follows SharePoint best practice, providing instructions where the SharePoint Central Admin and Web Applications are in separate Application Pools, and these pools run using separate Application Pool users.

It also takes the high road, where Web Application Pool users don’t have local administrative access. Unfortunately, this article stops just short of providing a complete set of working instructions. Following these instructions, when creating a new Email Enabled Document Library or list, you will receive the error “Access is denied.” This error may be generated by the SharePoint Directory Management Service, attempting to access the Active Directory Organisational Unit to create the email contact, and the Application Pool user has incorrect permissions over the OU. This is an easier error to fix.

However, this same “Access is denied” error may also be generated on the SharePoint server, as the Directory Management Service attempts to access the Email Integration Web Service. This is a more difficult error to track down, what exactly are we denied access to, if it’s not the OU?

The simplest resolution? Just allow the Application Pool user local admin access on the SharePoint server. Which of course goes against SharePoint (and general web application) best practice, and defeats one of the reasons for separating out your Central Admin and Web Applications.

So, what does this user really require access to?

This Technet magazine article picks the needle out of the haystack, and superbly describes the process that is occurring, or not occurring in this instance. Access to the Central Admin Email Integration Web Service is controlled by the application pool configuration, which is part of the IIS metabase (or the applicationhost.config file in IIS 7). By default, access to the metabase is restricted to local administrators. So, rather than taking a broad brush approach and allowing local admin access, all that is required is to allow the application pool user access full control to the IIS metabase. This can be achieve in Windows 2000 with the Metabase Explorer, found in the IIS 6 Resource Kit, in Windows 2003 by CACLS, in Windows 2008 by ICACLS, or simply through Windows Explorer with NTFS permissions. The contact should now be successfully created in the OU.

A second step is required to the initial TechNet library article, which is detailed in the magazine article. On the Exchange server, it is necessary to “Automatically update email addresses based on the email address policy.” This completes the email integration required for the solution.

The combination of these two TechNet articles allows the application pool user access to the Active Directory Organisational Unit, the Web applications pool user access to the IIS metabase, and completes the creation of the email contact in Microsoft Exchange. Following both of these informative articles, you will be able to host a SharePoint Email Enabled list, following best practice, thus satisfying both your business, and your technical managers.

Hopefully you will have found this blog post first which ties these two TechNet articles together, rather than having researched the internet to find the two articles independently.

Posted by: Ashley Petherick | 12 November 2008

Tags: MOSS, SharePoint, Email Enabled Lists


Blog archive

Stay up to date with all insights from the Intergen blog