Hi there, question regarding incoming email capabilites. We are currently trying out SharePoint but are stuck on one major aspect. We have setup an organization unit within our active directory and enabled SharePoint's directory management service. Further (and most importantly), the same machine is also acting as the POP3/SMTP server. We do not have Microsoft Exchange.
We are only able to receive incoming email to a list/document library/site, when we manually create the contact in the organization unit. If we try to enable incoming email right from the SharePoint, the email alias is not passed onto the organization unit in active directory - we're getting an "error in application" error message, which tells us there is a permission problem.
Right now, we're being told that incoming email is not possible w/out an exchange server - can anyone confirm if this is a correct statement? If it is not correct and we should be able to utilize incoming email and have the alias successfully passed onto the organization unit inside our active directory (with sharepoint successfully passing on the alias to the OU and us not having to manually create it in the OU), can anyone suggest what we might be doing wrong? We have been on the phone w/ MS Tech Support for probably a total of 12 hours, still w/ no resolution that sells us on this product.
Any help would so greatly appreciated!
I posted yesterday with (almost) the same issue - getting an "error in application" error when trying to enable a list to receive mail:-
We are running Exchange though - but I read somewhere that if you aren't using Exchange, you at least need to run /adprep portion of Exchange setup to extend your AD schema to supports the fields that SharePoint tries to write to. That may be why yours if failing - SharePoint is trying to write attributes to AD that aren't defined in AD. Wish I knew why mine isn't working ;-) Seems like a common problem but no simple solution....
Hey NAC - cool hope you come right! I've made some progress with our issue - I changed our web application's account via Central Admin to use the same account we're using for the farm. It's not security best-practice, but it seems that the general consensus on the forums is that this is the only solution.
I can now enable a list for incoming mail, and the Error in Application error is gone, and a Contact gets created. However, if I try to disable the list again, i get Error in Application and the Contact is not deleted. If i log on with the farm account to AD Users and Computers, i can manually delete the Contacts - so it's very odd. Have posted here if you interested in following the thread:-
all the best,
I'm encountering exactly the same problem of Raymond.
I can enable the doc library to receive emails, the contatc is created, but I can't modify the email address or disable the doc library to receive emails, I get the "error in the application" error.
I have all the web app and sharepoint-related services running with the same account.
The account is local administrator on the SharePoint box (sigle-host installation, for testing)
This account is also owner of the OU where the contact are created.
I already spent (wasted) so many hour on this issue!
I also read all other related threads on this issue but none of the suggestions solved the problem.
Hope some lucky or clever fellow will come up with a solution!
Played about with this some and I found that the only way I could get Sharepoint to de-provision the Contact in AD and Exchange was to make the service account (which should be the same as the account used for Central Admin) Domain Admins.
I also made the account Recipient Admin in Exchange 2007 as well.
I know this is not ideal and not sure that I will leave it setup like this in our organisation. There must be a right in there somewhere and if you have chance to find it then do let me know.
Otherwise the only other option is to manually delete the contact in AD and then you will find you can de-provision the email address off of teh list or library in Sharepoint.
Hope this helps some.
I found this to be right solution:
Add the Delete Subtree permission for the Central Administration application pool account (Dom\MOSS_FARM). This is necessary to enable administrators to disable incoming e-mail on a list
1. In Active Directory Users and Computers, click the View menu, and then click Advanced Features.
2. Right-click the organizational unit MOSS Contacts and then click Properties.
3. In the Properties dialog box, click the Security tab, and then click Advanced.
4. In the Permission Entries section, double-click the Central Administration application pool account Dom\MOSS_FARM.
5. In the Permissions section, under Allow, select Delete Subtree and Click OK to close the Permissions dialog box.
6. Click OK to close the Properties dialog box.
- Click OK to close the Active Directory Users and Computers plug-in.
Fernando has got the right idea.
Although in my case (MOSS 2007 SP1) the contact object did not fully inherit the rights I granted to the application pool account in the OU. I had to modify the ACL of the object (through the GUI of course). Even after I added the delete child objects permission it still failed when I tried to disable mail so I changed the permissions to Full Control and it worked.
I Haven't had the time to look at all of the potential permissions that may need to be set (and there are a boat load of them). temporarily changing them to Full Control isn't an issue if all you are going to remove them or (as said before) just delete the contacts yourself then you can turn off inbound email since there are no objects to delete.
If you are still dealing with this issue, installing Service Pack 2 solved these problems for me.
If you don't plan to install SP2 then keep the following in mind:
- No, you do not need Exchange
- Delegate Full Control of the OU to the Application Pool account running Central Admin
- Delegate Full Control of the OU to the Application Pool account running the user application if different from the Central Admin one
- Full Control delegation includes the Delete Tree permission mentioned on my previous post and will solve the problem of creating the contacts and deleting them when the library changes email address or is email disabled.
Both of you. (Lloyd, Fernando)Don't propose your own posts as answers. Wait for *someone else* to do so. THEN I will look at them.(and Fernando, when I've turned off your proposal of your own post don't propose it again, that just gets you added to my black list)
WSS FAQ sites: http://wssv2faq.mindsharp.com and http://wssv3faq.mindsharp.com
Total list of WSS 3.0 / MOSS 2007 Books (including foreign language) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx
I am sorry for my lack of etiquette. It is not on purpose.
when I have "propossed" one of my own posts as answers I did so to imply it was a tried and tested solution (as oppossed to a simply educated guess. I see now that is not the purpose of the "propose" button. sorry.
But, since we are on the subject, how do I post a solution to a problem I have had and solved? Asking a question seems not to be the right option.