February 21st, 2008Setup Incoming E-mail in Just 5,000 Steps!
Okay, that might be a bit of an exaggeration. Unfortunately, setting up this feature wasn’t as easy as the documentation suggested. Then again, is it ever that way!?
Incoming e-mail is a feature which allows users to e-mail an address and have the content of that e-mail appear in a document library, discussion board, or any other list supported under SharePoint.
In my opinion, this is an extremely valuable piece to the SharePoint deployment puzzle. I would go so far to say that it is a crucial piece to every SharePoint configuration.
Let’s face it. Most people communicate widely via e-mail. To leave that source of knowledge and documentation nested in a neat folder within your inbox, is downright neglegent! Plus, most end-users have been trained, and have become comfortable, with navigating your e-mail system. Outlook (or any other mail client) is the perfect front end to encourage users to post their information into their respective SharePoint site.
But, of course, you know all this.
Why then, was this crucial piece of configuration such a BEAR to setup? Two reasons:
1. Microsoft needed to make this configuration path a little more clear, consistent, and stable.
2. I need to learn just what the heck I’m doing!
So in order to enrich the community (and help me remember how I did all this), I give you my steps for setting up incoming e-mail on a discussion board list:
NOTE: If you are not the demi-god of your IT dept and do not have access to everything, know that you are going to have to get a couple people involved. Namely, the person that supports your Active Directory structure and the person that supports your DNS server (probably the same person [maybe it's you!]). You will also have to have access to configure the web front-end server of your SharePoint configuration running Central Administration. Hopefully you at least have access to that. If you don’t, I shed a tear for you. I know you cringe at the thought of having to ask your network administrator for help, but just bite the bullet and walk over to his/her desk and beg mercilessly for his/her help.
1. The first thing I did (ahem my network admin. did) was create an Organizational Unit (OU) called “SharePoint Distribution” in the local domain of our Active Directory Schema. He placed this OU under the OU called “Groups” (don’t ask me why, that’s his job!)
2. He then right-clicked on the SharePoint Distribution OU and selected “Delegate Control…”. This opened the Delegation of Control Wizard. He specified the user name of the account that is running the application pool for our Central Administration.
NOTE: If you don’t know what your’s is, go to the front-end web server that is running your CA and under IIS > (your server) > Application Pools, find your the Application Pool that is running your CA. Right-click > Properties… and click on the Identity tab. The user name specified here will be the account that you are going to want to use. Ours is “sp_farm”.
Back to the Delegate Control wizard.
He added “sp_farm” as the account, clicked Next and specified “Create a custom task to delegate”, then selected Next.
Under the Active Directory Object Type screen, he selected: “This folder, existing objects in this folder, and creation of new objects in this folder”, then selected Next.
Under the Permissions screen, he selected “General”, “Property-specific”, and gave the sp_farm account “Write” access.
Now the sp_farm account has the ability to create contacts in the SharePoint Distribution OU.
3. Now we needed to configure our DNS server. I had him create a dns record entry for sharepoint.<our_internal_domain>.org and had him point it to the IP Address of our web front-end server running CA.
4. I then logged on to the web front-end server, stopped the Default SMTP Virtual Server, then completed the following steps:
A. Right-click on Default SMTP Virtual Server > New > Virtual Server…
B. Name: sharepoint.<our_internal_domain>.com > Next
C. All Unassigned > Next > Answer “Yes” to the prompt that comes up
D. Home Directory: C:\inetpub\mailroot
E. Domain: sharepoint.<our_internal_domain>.com > Finish
5. I then had to log into Central Administration. Under Operations > Topology and Services > Incoming e-mail settings I specified the following parameters:
NOTE: Under “Active Directory container where new distribution groups and contacts will be created:” I specified:
“OU=SharePoint Distribution,OU=Groups,DC=<servername>,DC=local”
6. I’m finally ready to set this thing up! So I went to my SharePoint site and navigated to my discussion board list. In this case, I am working with a Discussion Board for our Database Team. I then selected Settings > Discussion Board Settings.
I then clicked on the link “Incoming e-mail settings” under the communications heading. I configured the following parameters:
In this case, I have configured an e-mail address of dbaod@sharepoint.<our_internal_domain>.org to be used for this discussion board list.
Upon, selecting OK, it then….
BAM! (Melodramatic music playing)
I got a blanket “Error in application” response from SharePoint. Hmmmm, yes…very descriptive.
“There must be some sort of permission issue!” I thought. After hours and hours (did I say HOURS?) of frustrating blowing away and re-configuring, all it took was a simple restart of my web front-end server. You know the one that is running CA? Anyway, that is what worked for me.
Conclusion:
Now that it is working. When I click OK to save the “incoming e-mail settings” on my discussion board settings page. The contact “Database AOD DBA AOD Discussion Board” gets created under the “SharePoint Distribution” OU. It takes some time but, eventually, the e-mail address of “dbaod@sharepoint.<our_internal_domain>.org” get specified in the properties of this contact as well.
Now when an e-mail is sent to this address, an .eml file gets generated and sent to the drop folder on our Web front end server (you know, the one running CA). An SPTimer service grabs that file and posts it up on the appropriate SharePoint list. This process takes about 60 seconds for us.
By the way, Todd Klindt’s Blog has some useful information on all of this. Also, the white paper from Combined Knowledge is very helpful.
February 21st, 2008 at 5:25 pm
[...] Setup Incoming E-mail in Just 5,000 Steps [...]
February 22nd, 2008 at 9:17 am
Good article.
I too am getting Error in application, did iisreset and that didn’t correct it. Checked Event Viewer/Application and no sign of anything wrong.
Got any ideas? I thought it might have been a permission issue at the Farm Account level with Active Directory, so I gave it full control and that didn’t do it. When I setup the information for the AD portion in Step 5 it passed the test and went on to make merry.
Any ideas as to where I might look to see what’s going on?
February 22nd, 2008 at 9:36 am
Argh! That is exactly the problem I was having. Aside from all the stuff you probably have already seen, from my blog and others, I have no suggestions.
I’m sure you have checked (and re-checked) that you are using the correct Central Administration Application Pool Account. From what I read, this is the most common reason for this problem. Specifying the wrong account, that is. Also, I’m not sure the fact that you were able to get past step 5. neccessarily means that your CA App Pool account is allowed to create a contact in the OU. It just means that the OU is available.
The frustrating thing about this problem, as well, is that it is an error occurring with the Application (read Application Pool), so it does not end up in any log or the Event Viewer from what I’ve seen.
I really wish this part of it was more consistent. I know this doesn’t help, but know you are not the only one I’ve seen with this problem.
I will continue to post anything that I might find in regards to this. Please do the same!
February 24th, 2008 at 4:58 am
[...] in SharePoint Set content type at the folder level in SharePoint SharePoint 2007 Permissions Matrix Setup Incoming E-mail in Just 5,000 Steps! How to create your own custom 404 error page and handle redirect in SharePoint 2007 (MOSS)? How to [...]
February 28th, 2008 at 4:15 pm
I’ve got the incoming email going into the list, but only if the list is setup to accept email from anyone. If it’s only from list members, then the email doesn’t show up, even when sent by a list member.
The only step I left out was the “Use the SharePoint Directory Management Service to create distribution groups and contacts” as I don’t have control over the AD, and I understand that to be related to delivery of mail to sharepoint, not authentication of the incoming email.
February 28th, 2008 at 7:43 pm
John Moreno -
Interesting. I’m not quite sure what might be happening. The trick here is discovering how SharePoint authenticates incoming e-mail (you’re probably thinking “duh!”). If you are not using the Directory Management Service, and you believe that it’s not required, I would suggest that you check your logs.
Here is what I would do.
1. Open up the drop folder of the SMTP server.
2. Open up your Logs folder (assuming you have logging enabled in CA, the default folder should be C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS)
3. Send a test e-mail
4. Watch the .eml file arrive in the drop folder (if it doesn’t arrive in a few moments somethings wrong with the SMTP)
5. If the .eml file arrives, wait for the OSWTIMER.exe service to grab the .eml file (may take up to a minute)
6. If the OSWTIMER.exe service grabs the .eml file, it should disappear from the drop folder. Wait for the latest .log file’s size to increase, then open it. Try to look for any entries in regards to what happened to the .eml file!
If you figure out the solution, please reply back here.
February 29th, 2008 at 9:47 am
Travis,
Yeah, that’s what I did…
“Warning An error occurred while processing the incoming e-mail file c:\inetpub\mailroot\drop\dea7081701c87af600000016.eml. The error was: Access denied. You do not have permission to perform this action or access this resource..”.
Which might be helpful if I knew what “this resource” referred to…
Elsewhere I’ve read that the mail needs to go through Exchange in order to be authenticated, but there’s no explanation as to exactly what that means (and I am sending through an Exchange server).
February 29th, 2008 at 12:15 pm
I know it is has been documented in a few blogs and white papers that setting up the SharePoint Directory Management Service is not necessary. In other words, you do not have to route through exchange in order to get incoming e-mail to work.
All I can say to that is, that I received the SAME exact error you’re getting before I enabled this service and had SharePoint configuring contacts on my exchange server. Then everything seemed to just “work”.
I’m not quite convinced that this functionality has been fleshed out completely by Microsoft. Just yesterday, all my aliases configured for each of my lists were “lost” even though they were represented in the SharePoint content databases. All my aliases WERE in the database (I could see them on the back end), but when I sent an e-mail, the log file noted: “Unknown alias”
I’ve just finished the task of disabling, then re-enabling, each list; essentially rebuilding the configuration I already had.
Maybe in Service Pack 1 they will….oh wait…
March 11th, 2008 at 9:01 am
Well, I have what might be another clue….
One of the white papers on setting up sharepoint 2007 says:
] If you choice to go this route you can leave the setting at
] “Operations > Active Directory Settings for E-Mail Web Service”
] blank.
But that’s not on the Operations page or anywhere else…at least that I have found.
March 11th, 2008 at 9:35 am
Good point John, I have read that on Todd Klindt’s Blog as well.
Really, everything that I’ve read states that the Directory Management Service should be creating a contact to be viewed in your organization’s Global Address List which, of course, you may not even want anyway!
However, AD may be required if you want to filter incoming e-mails based on authenticated users. I haven’t found any documentation that states this clearly, this is just an assumption.
March 20th, 2008 at 6:46 am
How about this??
I get errors like this:
“An error occurred while processing the incoming e-mail file C:\Inetpub\mailroot\Drop\34be946101c88a8300000005.eml. The error was: Access denied. You do not have permission to perform this action or access this resource..”
But only for a specific person from a specifier copier which is used for scanning to PDF and having its internal SMTP send to a valid email-enabled document library with a valid email address that works for other people on other copiers.
WHAT is the ‘resource’ in this error message??
Thank you, Tom
March 20th, 2008 at 7:26 am
Tom:
I’m sure you’ve checked this, but have you set the list to only “accept e-mail messages based on discussion board permissions”?
If the list is receiving other e-mails but not ones from this specific user (or source), the only thing that would stand to reason is that this user alias does not have access to post to the discussion thread.
But then again this stuff, sometimes, follows no sort of reasonable logic
March 20th, 2008 at 8:26 am
Oh yes, I have checked that. This user can send to this exact same document library email address from another copier in the same room, same subnet.
Is the referenced ‘resource’ the involved document library??
Thank you, Tom
March 20th, 2008 at 8:47 am
Tom:
I would venture to guess that when the error message refers to the “resource” that it is referring to the document library. Although, that is just a guess.
I wonder if you could open the .eml file in the drop folder before the OSWTIMER.exe grabs it. Compare the header information with an .eml file from the copier that is working.
Possibly the offending copier is adding extra information in the header of the e-mail?
March 20th, 2008 at 11:24 am
I can try with the drop folder…problem is the physical distance between the copier and the PC I’m at. I’m monitoring SMTP logs now and maybe that will turn up something.
Thank you, Tom
March 21st, 2008 at 7:28 am
Well, I’m stymied now. This specific user can successfully send to the document library if the paper to be scanned to email is on the GLASS, but not if the same paper is transmitted through the copier’s document feeder. For now I’m giving up because there is another copier which this user can successfully use.
Reviewing SMTP logs doesn’t help much, they are un-decipherable.
Thank you, Tom
May 13th, 2008 at 3:52 pm
Travis,
I can’t get emails routed to my SharePoint server from my exchange server. SMTP on SharePoint and incoming email works fine because I can drop a email into the c:\inetpub\mailroot\pickup and it shows up in the drop folder, then gets posted in the SharePoint document library. So emails are not getting delivered correctly. In trying to resolve my issue, I noticed you did some things that other sites I’ve read didn’t.
Namely, creating a new SMTP virtual server, but need some clarification on the following….
- In Step 3, is that a host or alias record being created for sharepoint..com?
- In Step 4, you created a new SMTP virtual server named sharepoint..com, but in the image it shows “.org” instead of “.com”…which one is correct?
- Why did you decide to use “.org” for the name space for SharePoint? Could I just use the server’s FQDN?
I’m not sure if this is where my problem lies, but I’ve also read about maybe needing to create MX records or use an SMTP connector. Do you think I’ll need any of these?
Thanks!
May 13th, 2008 at 7:54 pm
Daniel:
– Step 3 was a typo. I edited my post (I know that’s taboo, but hey I’m not a reporter or anything!). As far as being a host or alias, I’m pretty sure it was an alias. It was a DNS record I had our MCSE “admin guy” put in for us. Essentially making sharepoint..kdhcd.org resolve to the IP of my SMTP mail server.
- .org only because of our organization’s internal domain. (I hide that info because I like my job).
- As far as the FQDN, I would imagine you could use that as long as it points to where your SMTP server resides.
A guess is that your issue is related to a DNS resolving situation. Try pinging your FDQN; does it resolve your SMTP server?
June 26th, 2008 at 3:19 am
Hi guys
I’ve been fighting with the “Error In Application” error as well, and eventually relented from using the “least privileged” configuration of having separate accounts for our CA and web apps, to just having one service account that runs both. That sorted the problem creating Contacts in AD, but if we disable incoming email for a specific list, it still gives the dreaded “Error In Application” error, the Contact is not deleted, and the list remains email enabled. Any ideas? Using the farm account, i can manually delete the Contact from AD, so I don’t think it’s permissions….?
December 19th, 2008 at 4:03 am
About the “Error in Application” when configuring a list to receive mail, I solved it the account that runs the Application Pool of my SharePoint site as an Administrator (added to the local Administrators Group in Windows). Then I set up the incoming mail for that list without any problems. After that, I removed the user account form the Administrators Group, and everything works just fine. Jope it helps.
March 12th, 2009 at 9:18 pm
Guys,
I did exactly as said by the Combined Article. Thanks Steve.
Yes, it do creates contacts in the OU then emails do come to DROP folder.
BUT
The emails still there in drop folder without dissapearing. And it does not get publshed in the sharepoint lists….
I have setup all as said in article. What my concern here is either SMTP or SharePoint being cracky…
Anyone for my rescue?…
April 13th, 2009 at 11:08 am
Here is an interesting article on how to debug incoming email.
http://home.dzeee.net/blogs/sp/Lists/Posts/Post.aspx?ID=14