2.1. Directory Management Service
Based on what we have covered already, users can
send email to lists or libraries, but there is one problem: how will
the users actually know or be able to find the email address for an
emailed enabled list or library? Of course, you can just provide it to
them, but a better solution might be to add it as a mail-enabled
contact within Active Directory. This would allow it to appear in the
Global Address List (GAL), which should enable users to find it much
easier.
Of course, you can always manually add contacts
directly through Exchange, and for a small number of lists or
libraries, this is the best choice. However, if you have a large number
and don't want to be burdened with having to create new contacts, an
automated option is available: the Directory Management Service.
With Directory Management Service enabled, when a
list or library is enabled for incoming email, SharePoint will
automatically create a mail-enabled contact for you. Figure 6 shows the configuration options when you enable this service.
The first text box asks you for the organizational
unit (OU) in Active Directory. This becomes the container for these
newly created contacts. As shown in Figure 6,
we're using an OU named SharePoint. To keep your SharePoint contacts
separate, do not use a container that is used for non-SharePoint
contacts or user accounts.
For SMTP server, just enter the fully qualified domain name for the SharePoint SMTP server.
In addition to creating contacts, Directory
Management Service can also create and synchronize distribution groups
in Active Directory. This would allow you to keep SharePoint group
membership and distribution group membership consistent. Note that
these groups in Active Directory are not automatically created and must
still be individually approved by a SharePoint farm administrator.
With these settings in place, when a user specifies
that a new list or library is to be email enabled, SharePoint will
create the contact in Active Directory. Before this works, there is one
additional configuration step that must be done. The Windows account
that creates the contact is the identity account that is running the
Central Administration v3 application pool. This account must be
granted read, write, and create permissions to this OU in Active
Directory.
To identify the proper account, start IIS Manager on
the web server that is running the Central Administration website.
Expand down through the server name and click Application Pools. In the
list of application pools, select the one named SharePoint Central
Administration v3. In the Actions pane, select Advanced Settings. You
will be presented with a Settings dialog like the one shown in Figure 7.
The account is the one listed next to Identity. Note
that these steps are for Windows Server 2008. If you're running Windows
Server 2003, the steps are similar.
With the account known, you can finally delegate (or
grant) permissions to it within Active Directory. To do this, start
Active Directory Users and Computers. If the OU container that you
specified earlier has not been created, create it now. Then,
right-click the container and select Delegate Control from the context
menu. A wizard should start.
For Users And Groups, enter the account name.
For Tasks To Delegate, select Create A Custom Task To Delegate.
For Active Directory Object Type, accept the default setting.
For Permissions, check Read, Write, and Create All Child Objects. The screen should look like the one shown in Figure 8.
|
There is a drawback to Directory Management Service
that you should be aware of. In most cases, it will be your end-users
who are probably configuring their lists and libraries to be email
enabled, and they can specify any name they want. With Directory
Management Service enabled, this name will automatically be published
as a contact and be visible by everyone in the organization. Whether
unintentional or malicious, this may be an unsuitable name. You must
weigh the risks here and determine whether you want complete control
over the names that are published.
|
2.2. Troubleshooting Incoming Email
As you can see, configuring incoming email can be
complex. Here are a few troubleshooting tips that may help you solve
why incoming mail is not working properly.
To identify whether the problem is with SharePoint or Exchange, take a look at the SMTP service's drop folder (by default, C:\Inetpub\mailroot\Drop)
on the SharePoint web server. If you see files in here, Exchange
routing is working properly, and the problem is most likely with
SharePoint.
The program that picks up
and processes the messages from this Drop folder is the Windows
SharePoint Services Timer service. This is a regular Windows service
and should be running under the same account that is the identity for
the Central Administration application pool. This account will need the
Modify NTFS permission to the Drop folder to ensure that it can read
and then delete these files.
Enable logging for the SharePoint SMTP Service.
Review the SharePoint logs. By default, these are stored here:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS
