SharePoint User Group UK

Steve - This is a very good whitepaper.  Thank you for taking the time to put it together.  There remains one issue I have yet to overcome, however: according to the information supplied, the AD account assigned to the central administration app pool must have sufficient rights to create and maintain an AD entity.  By default, the system creates this app pool with Network Service as the owner, which does not have rights in our systems to effect AD.  There exists an account which meets all the requirements and I have assigned it to that application pool.  Unfortunately, doing so locks me out of the central administration console and the ability to create e-mail distribution lists via SharePoint remain disabled.  I was wondering if you had any insights on this.

Steve - thanks very much for this excellent how-to... I tried this today with WSS and the system works very well. The only thing is that with WSS (not MOSS) I believe there is no directory mgmt service, so you will need to create the contacts in your exchange organisation by hand, But then if you're not using MOSS, your site might be small enough that this isn't a problem. It isn't a problem for us as we don't want to mail enable all the lists.

Couple of caveats which you are welcome to include in your whitepaper:

If your exchange set-up uses a smarthost to send email (like a mailmarshall gateway) rather than DNS you will need to create a SMTP connector in exchange. Include the FQDN of your WSS server in the address spaces tab and forward all emails to your WSS server's SMTP server.

Also, my WSS service account didn't, by default, have access to delete the items from the mail drop folder, and every few mins the SP timer service would add duplicate items to the news list again . So it's necessary to give the wss service a/c full control on the IIS Drop folder.

Hope this helps you and thanks for your help...

Thanks for the comments guys. As for the App Pool using the network service did you install as a standalone installation ? It is not recommended to use this type of account for SharePoint App Pools. It should be a domain account. And the App Pool that is running central admin must have the rights to create objects in the OU where the incoming mail settings are configured to create the contacts and DL.

Also thanks for the WSS update , I was not aware that WSS did not have the directory management service. and thx for the tip on the WSS account issue. However I am not sure why the service account in WSS was not an admin on the file system. Strange that , must be an installation issue with WSS only.
I knew I stayed in Portal for a reason :)
I have added the the issues around DNS and MX records and smtp connectors to my whitepaper already as recommended by another poster. Thx.

Thanks again for this. I tried it with a calendar list last week, and you can send outlook appointments to the address and it picks up dates and times, locations etc all from the meeting request - fantastic.

I've also mailenabled an announcement list, but I was wondering, is there a way to include the "Expires" field in the email. Setting mail expiry doesn't do it... (Guess it's not *that* clever)!

Hello,
Very informative work, indeed. I did all the steps you have mentioned but everytime I try to enable a library with this function I get this error: "Error in the application". And a very self explaining that one :(
Do you have any ideea what can be wrong? I use MOSS2007B2TR and SQL 2005 on the same machine, Win 2003 SP1 as DC and Exchange 2003SP2 on another machine.
Thanks in advance.

hi,

the whitepaper was great, but am having a major problem since enabling the incoming e-mail service - I can't create and new libraries or sites. I keep getting the http 404 error if I create libraries that are e-mail enabled. Likewise if I create a new site, when I go to the link, I get the standard http 404 page cannot be displayed error. Both errors go away if I turn off the incoming e-mail service.

Any ideas??

The generic " Error in the application" is usually caused by the central admin app pool not having the necasary rights in AD to create a new object. you can do this in AD by using delegated contol. - right click the AD or OU and run the delegate control wizard.

Steve

I have no idea why you are getting the 404 error. Thats a new one on me and I have never seen the error posted in the newsgroups either.
Does the event log say anything ?

Steve

The only thing in the event log is Event ID 3351, which is a generic error saying access denied to SQL server - this has been coming up since we installed sharepoint but doesn't seem to affect anything. No other errors in the event log. We've actually just started from scratch and redone the incoming e-mail settings and now we get the "Error in Application" error when we create the library but still the 404 error for new sites and can't access any of them

Becky.

Steve, I have done the delegation but with no results. What exactly are the rights to be enabled? The only error I get is: The Execute method of job definition Microsoft.Office.Server.UserProfiles.WSSSweepSynch (ID ...) threw an exception. More information is included below.

Object reference not set to an instance of an object.

Any ideeas? Thanks for helping.

Beckyn , I am thinking there is a permission error here.Check the accounts that you are using for the App pools has rights to both AD and SQL then. Are you using domain accounts or network service ? you should be using domain accounts.

Steve

Valupe , no idea I am afraid. I have not experienced that error when using my setup.

Hi Steve,

I'll double check on that and let you know - unfortunately I'm not the super technical one!

Becky.

Hi Steve,

just checked and we are using domain accounts.

Becky.

Well, I am really going mad about this. I have just reinstalled the whole server, going to RTM. But, the same problem appears. I'm 99% sure that the problem is on the DC and AD settings but there is no error, whatsoever in any of the logs, except the SharePoint own logs. Every atempt to create an object in the OU failes, no matter what I try.
Please tell what are the exact rights that the SharePoint Central Administration application pool account needs. Please try to think about this. I did gave full control on the OU, but without any improvement.

Thanks for the help.

It requires Create Object right. Try delegating create and modify object rights to the active directory level rather than the OU and see if that helps.
If this still fails try giving the account admin rights to just proove its a permissions error.

Most certainly it's a rights issue. After I gave every posible rights on the OU to the SharePoint Central Administration application pool account, it started working BUT only on the SharePoint Central Administration Site. No matter what else I try, on the main site it doesn't work. I did give the same set of rights to the site collection application pool account and also to the SSP account but without any results. I am going completly mad about this.

Correct , it has to be the central Admin App pool account. this is why I specifically mention this in my whitepaper. No other account is used by the directory service management.

This is correct. But why it isn't working on other site collections? It works perfectly on the Central Administration Site, but crashes on any other site collection. And I do not like the ideea of changing the site collection application pool account to be the same as the Central Administration Site. Any ideeas?

No , the central admin App Pool is used to create the contacts for ALL Moss Site collections. When you mail enable the doc library it is the responsibility of the directory service management to create the contact on behalf of the site. no matter which site collection it is. If it works for one site collection and not the other there is something else wrong. Unfortuntely I have never seen this error in the way you are describing it ie. one site collection works and the other does not.

OK, I got it working now. How? Doing exactly what Microsoft says not to. I created a new web application running under the same account as the Central Administration Site application pool.
Of course the MOSS now yells at me: "The account for Central Administration is being used by some other web application. The application pool account used by Central Administration has update permissions on all Windows SharePoint Services components within the farm, and should not be the same account used for any other content web application. Central Administration application pool account should be unique."
But the incoming mail works. Now, what should I do? Investigate further or continue the deployment like this? What are the exact consequences of running under the same accounts?

I have exactly the same problem as vulupe. I use SQL Server 2005, Exchange Server 2003 and MOSS2007B2TR. I configured a list vor EMail Enabling using the great White Paper and grant delegation rights for all administrative MOSS Users.
Seems to be a bug in Share Point Server 2007. I hope the problem will be solved soon because I need this feature for some new project sites to setup.

Ronald, try this: put the account you use for the web application in the local administrators group, on the MOSS2007 box, as well as give this account the read/write rights on the OU, along with the account for Central Administration . That did the trick for me. Hope it helps you as well.

@vulupe Thank you for your reply, but unfortunately it don't work :(
I granted read/write rights on the OU, put all administrative moss users as local administrators on the moss server AND the SQL Server, but I always get 'Error in Application'.
Any other idea ?

Does it work on the Central Administration web site? Creat a doc lib in there and test it first. That's how I got the first results. Give full control on the OU to the account that runs the Central Administration app pool and put the account into the local admins group. Should work.

problem solved ! I tried to restart IIS, but it hung.
I rebooted the moss server and now it works ! There is a configuration problem with external mails, but I think I'll solve it soon.
Thank you very much for your help !

Glad to be of assistance.

i am trying to follow the white paper but cant seem to get the AD Container correct. I have setup sharepointOU on exchange and my other settings are:

Domain:myhomedom.local
Exchange: v2003 SP2 called beehive
MOSS: sharepoint

What do i enter into the OU..DC settings?

Thanks

Hi Simon , you should be using the syntax
OU=sharepointOU,DC=myhomedom,DC=local

Steve

Hi All, I have follwed this to the tee and the new contacts are being written to the OU. However, emails that I try and send to the list get returned so I think I need to do the SMTP Connector thing in Exchange - does anybody have any info on the exact configuration for this?

Thanks in advance

Hello,

I have foudn that the only way I can get this to work is to make my app pool account a domain admin? I have tried to delegate control at the OU level and the top level in AD but I still get the application error? My app pool account is just a member of domain users, is there anything else I should do with the account to make this work with making the account a domain admin?

Regards,

Mark Wilson

Hello,

I have the problem too: my app pool account is Network service and has been given rights on my OU but I keep on getting the generic " Error in the application".
As my box also happens to be the PDC, I guess that the Network Service has sufficient rights.
Isn't it possible that rights are not the only problem here?

Thanks in advance
Eric

The problem here Eric will be use of the network service account. You need to assign a domain account to the central admin app pool account and then give this account rights to the AD.

Thanks Steve!
I have created a new account for the central admin app pool and now it works.
But I have now the same issue than vulupe: it works from the central admin site only and keeps on crashing from the public site. I've restarted IIS without success.
I think I'll do what vulupe did and run the public site with the admin app pool too...

I followed the steps above and was still getting an "error in application" even though I used a domain account as the central admin application pool account and granted that account full control over the OU in AD (even though Windows reccommends against this) and all child objects.

I turned off custom errors and turned on the call stack in web.config and the errow was something like DirectoryManagement.Update("prevcontactstring1","aftercontactstring2") leading me to strongly suspect it was a problem updating AD.

After I reset IIS a few times I restarted the web server, then it really started to go crazy. The site worked in general but when I tried to change the e-mail settings on a list it said

"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond "

then after a few minutes the error changed to

"The request failed with HTTP status 401: Unauthorized."

even though I didn't do anything but reload the page. I can't make any rhyme or reason out of this. I followed the steps exactly and even got it working before.

Hi Steve,
I followed exactly your prescription to enable incoming emails....but still not working.
My configuration : 2 DC/DNS + 1 Exchange server (DC) + 1 MOSS 2007 server (member server).
As you said, by default the account of App Pool is Network Service.
My question is : the Network Service is local or from AD? If it is local impossible to add to an OU of the AD.....
Then it is normal to have access problems on the AD.
I changed the App Pool account by a domain account, gave it all the rights on the OU in my AD (it is in the enterprise administrator group...I can't do more I think).....
And now impossible to connect on the MOSS with any AD accounts except with the local administrator of the MOSS server.....
Very strange.....
Anyway, i connected on it with this account and trying to enable on Home the incoming e-mail.....same problem
Any ideas coz i am blocked and completly losted...
My kingdom for a solution :)
Thanks a lot.
Regards

Yes, I've had the same problem when I've tried to run the public site with a domain account: Impossible to connect to the MOSS anymore.
so the question become: where can we find a list of  "Network service" rights so we could create an AD account accordingly?

Did you change the App Pool identity in Central admin - Operations - service accounts ? this is the only way plus the stsadm command that you should change service accounts in sharePoint. If you did this direct in IIS App Pool then you would not have updated the Config DB and thus created more errors.
Also I have always made this central admin app pool account a local admin on the Moss server as well.
Bottom line though is that 90% of all the problems I get with this configuration is a permissions error somewhere. The catch is finding at which point this is , sharePoint - Local server - domain - AD , they all need to be checked. plus I would never advise using Network service or local service for any sharepoint service accounts. Much of microsoft documentation states to use domain accounts.

Steve

This new whitepaper may also help you all with regards to how to change service account passwords and accouts for the central admin app pool account

http://support.microsoft.com/kb/934838/en-us

Steve

Arrghh...
I have finally figured out my problem after 2 days:

I NEEDED TO RUN SETUP.EXE /FORESTPREP
from an exchange CD to prepare my AD schema. I don't plan on using exchange if I can get away with it. Not sure if other mail servers work - will try to use IIS SMTP server.
Hope this helps someone else too :)

Thank you Steve: You're right, I was modifying the account in IIS App Pool instead of using the admin tool.
Basically, while I was unable to have a MOSS connection anymore (Access denied), the same account works now perfectly fine.
But I think I'll have to disagree with you when you say "No , the central admin App Pool is used to create the contacts for ALL Moss Site collections. When you mail enable the doc library it is the responsibility of the directory service management to create the contact on behalf of the site. no matter which site collection it is"
In my config, it has worked in the central admin first, and then in the public sites once I've modified the account too.
Anyway... now the contacts are created in my AD OU, I've still work to do before being able to send emails but I'm on the right direction!
Thanks again !
Eric

The directory management service DIRMAN uses the central admin app pool service account as the authentication to AD. This is also confirmed on the official Microsoft technet paper on incoming e-mail.

Steve

"The directory management service DIRMAN uses the central admin app pool service account as the authentication to AD"

Steve, then how do you explain the following:
- I have the Central Administration app pool and the site's web application running under different accounts
- if I put both these account in the local administrators group on the MOSS server, the creation of AD contacts works;
- if I remove the account under wich the web sites application pool runs, the creation of AD contacts fails
- if I remove the AD rights for this same accounts, the creation of AD contacts fails

I agree Valupe that some people still have to add additional rights. I have no idea why but then I don't know everyones infastructure setup. However if you read this MS document it clearly states only the central admin app pool.
http://technet2.microsoft.com/Office/en-us/library/88317397-e0cb-47c7-9093-7872bc6852131033.mspx?mfr=true

Steve Smith

Well, I have a new one for you guys:
After some hours, I finally have emails in my drop folder.
Now... After a few seconds, the message is deleted so I guess that the Sharepoint Timer has done the job. Unfortunaltely, the message never appears in my discussion list !!!
I know what you're thinking... but yes, I'm looking at the right list :o))
Any idea where I can find a trace of how my message is being processed by the timer??
Thanks in advance for your answer! I know I'm almost done with all this...
Eric

I have a little bit more detail to provide...
I have the following event in my application log:

A critical error occurred while processing the incoming e-mail file c:\inetpub\mailroot\drop\P3_20070427150021073100000005.eml. The error was: Bad senders or recipients..

Obviously the sender is correct as my list accepts all senders. And so is the recipient.
It may be important to say that this email has not been dropped to this folder directly but has been copied from another location through a batch. I know this sounds a little bit complicated but I had no other choice, given that my sharepoint and my exchange servers were on the same box, thus forbidding the installation of another SMTP server. Anyway...
If anyone has an idea about how Sharepoint find out who is the recipient of the emails stored in the drop folder, I'm interested !
Thanks
Eric

Finally... it works !
This bad senders or recipient error seems to bue to to a processing from a pop3 service. I know that the doc specified to install the SMTP services only, but I had to use an existing smtp server and I thought it could be ok.
Obviously not... but anyway, I'm glad it works now, thanks everyone for your help and support.
Eric

I'm running a single-server WSS3.0 implementation with Exchange and AD installed.  I've noticed numerous references that I cannot start mail-enabling lists with this implementation (specifically with Eric's last post!).  What can I do to get things working?

Obviously, the SMTP service is already installed for Exchange.

Thanks very much to everyone, espeically Steve, for the whitepaper!

Sorry, one more question:

Regarding switching over from the Network Service to a new domain account, what is the exact process flow I need to follow, here?  Do I create a new account with regular "Domain User" access, then simply type in the account's username and password in Central Administration where it says "Select and Account -> Configurable"?  Do any other permissions need to be applied, and do I also need to change access in IIS's App Pool?

Of course, after all of that, I'd provide delegation access to the AD OU and the Drop folder...

Sorry if my questions sound a little basic, but I feel like everyone else here has been referencing some sort of higher knowledge that I don't have access to.  Thanks very much!!!

John

Hi John,
You're right, it's not possible to make it work directly if WSS and Exchange are on the same box (well, it may be, but I haven't found a way !)
What you can do is set up another SMTP server, exactly as Steve described it in the whitepaper. Don't make the mistake that I did... do NOT install pop3 service or it won't work.
Once this is done, create a dynamic distribution list in exchange (based on your OU)and a send connector to fwd the emails sent to your list to the new SMTP server.
Finally... create a batch that will cut/paste the incoming messages from the drop folder of the SMTP server to the drop folder of your WSS/Exchange server.
Concerning your second question, the account I've created to run the App pool is member of the following:
Domain Admins
IIS_WPG
WSS_ADMIN_WPG
I'm not sure if it needs all that but as my box is also my PDC... I don't think I have much choice. And yes, you only need to change it into the central admin.
Good luck !
Eric

Thanks very much for your assistance, Eric!  I imagine the alternate SMTP server could possibly be on a Windows XP system, for instance?  I *do* have another 2003 server at my disposal, but it's running our accounting software, and I try to touch that box as little as possible.  If I cannot run SMTP on a cheap and easy XP box, I suppose I'll have to resort to that accounting server.

One question, however: I'm not sure if I know how to create a dynamic distribution list in Exchange.  I understand how to create Dist List groups in AD...is this something different?  And when you refer to creating a send connector, do you mean the access relay that Scott points out in section 2B?

Thanks again!
John

Well, I guess that as long as your XP is a Professional Edition, it should do the job...

For Exchange: I don't know which version you're running but I'm using Exchange 2007 and it's pretty straight forward: In the recipient Configuration > Distribution Group, just click on the right menu "New Dynamic Distribution..." It will ask you to select your OU and this is it.
The send connector is something else: That's basically what Exchange is using to send emails out. It could point to a smarthost, or use a MX record that you should have created in your DNS. In this guess, I guess that you'd use the MX record...
The send connector can be created under the Hub Transport of the Organization Configuration.
However, if you're not running this version of Exchange, I'll be of no help as 2007 is the only version I've used.
BTW, the creation of the connector does not allow you to skip the open relay settings ;o)
Eric

Thanks again for your help, Eric.  However, all this appears to be a gigantic hassle that doesn't really address the particular functionality I'm expected to build on this project.  Basically, my sales folks want to be able to save emails to Sharepoint that tie directly to contacts.  It appears that while the Incoming Mail feature allows part A of that, it fails on part B.  I assume I'd have to build a custom Outlook form that does a lookup on the WSS database in order to do satisfy part B...and it occurs to me that if I'm already building a custom Outlook '03 form, all I really need to do is save the email as a .txt file and drop it in the Doc Library (appending contact metadata) rather than go through all this Incoming Email rigamarole...

Regardless, thanks once again for your help!!  I'll give it a go before I start investigating the feasibility of my ad-hoc "solution".  But *boy* does it seem marginally easier (then again, I haven't cracked a book on creating custom Outlook forms quite yet!!)

John

One option here then would be to create a document library for each contact which then gives them an e-mail address for use on incoming mail and also allows you to create custom fields / content types for other documentation that is need for that contacts doc library. You could also research using workflow for information that is put into the library.
Finally you have nice new features in Exchange 2007 that allow you to map an Outlook managed folder directly to a document library in SharePoint , so if a person recieves a mail in their inbox that is also relevant for that contact they just drop the mail into the managed Outlook ( Exchange ) folder and of goes the e-mail to live in a sharepoint doc library but also living in what seems like Outlook to the users perspective.
SharePoint gives you so many options for stuff like this and I would certainly ask your question on how to approach developing custom doc libarries for this sort of thing in the development forum on the suguk forums site. I am sure lots of devs out there will help who probably will not read this thread.

Steve Smith

Thanks, Steve!  Unfortunately, however, we don't quite have the cash to upgrade to Exchange '07 right now.  In a perfect world, I'd have multiple servers running the newest, hottest versions of everything, but my company is pinching some pennies right now.  It's a horrible drag on my psyche, because I've gotta figure out all these work-arounds!!

Thanks again for your suggestions, though.  I'll hit up the Dev forums to see if someone's already invented this wheel before I go about fashioning one of my own!

John

First of all, thanks again to Steve for making this white paper. I am a student currently doing my Industrial attachment program and this is exactly what my employers wanted.

I tried to follow all the steps in the white paper but i've ran into problems. It seems that I have similar problems regarding the "error in application" with the rest of the readers. I have tried almost all of the solutions suggested here but to no avail.

I tried to create a new regular domain user and giving it rights via the Change Service Accounts at the Central Administration. But when i do that, it only adds my new regular user to the WSS_WPG group. Which, the descriptions is, "Members of this group have <b>read</b> access to system resources used by Windows Sharepoint Services."

What should I do to add it into the WSS_ADMIN_WPG group? From what i gather, its not a good idea to add the user directly via AD?

I'm sorry if i'm not making myself clear but please do help as i have no clues at all how to continue troubleshooting this.

I'm using Windows Server 2003, with AD, SMTP, IIS
and WSS 3.0 installed.

What's important is to associate the user to the App pool using the central administration. Once this is done, I don't think this is a problem to grant additional rights in AD directly. Try to add your user to the WSS_ADMIN_WPG from there. The user should also be a local admin.

Thanks for reply Eric! :)

Erm, i tried your suggestion again and still it is giving me the same error. "error in application".

Just in case, I'm doing this wrong, maybe I'll just list down the actual steps for all to see?

First. I created a new user named newUser
Start-> Administrative Tools -> Active Directory Users and Computers -> Users *right click* New -> User

Then. I gave it local admin rights.
Highlighted newUser, *right click* Properties -> Members of -> Add "Administrators".

Then. I open up the Central Administration via the Administrative Tools loggin in as Administrator.
Operations -> Service accounts -> Web application pool -> WSS web application -> Sharepoint 80 -> Configurable -> Username & Password

It tells me to do a "IISRESET /NOFORCE", so i did it.

Now opening up the AD again, I see that newUser has been added to just the WSS_WPG group so I added newUser to the WSS_ADMIN_WPG group as Eric suggested.

So right now, newUser is a member of
Administrators; Domain Users; IIS_WPG; WSS_ADMIN_WPG; WSS_WPG

I do a IISRESET again, just to be sure.

I open up the Central Administration, and created a new Document Library. I allowed the list to accept incoming mail and click ok but I apparently sharepoint doesn't want to allow it.
" The list was created successfully, but could not be assigned an e-mail alias because of the following error: Error in the application. "

So what did I do wrong?? Did I do any of the steps wrongly? Should I format the my entire computer and start fresh? :(  

Well, there is only a few things I can think of...
1 - Ensure that your Incoming E-Mail Settings have been set up correctly in the central administration (page 5, 6, 7 of the whitepaper)
2 - Ensure that you have delegated our OU to your newuser. To do this, go to your AD, right click on your OU and click on "Delegate control" then select your newuser and grant him access rights (read/write)
3 - I don't think this last step is necessary... but just to be sure, try to add your newUser to the Domain Admins group.
If this still doesn't work after that... Either someone has a better idea, either you could just move on and create the user manually. This does not prevent the rest from working.
Hope this helps
Eric

Hi Steve,
In your last post, you were talking about mapping an outlook managed folder with a MOSS2007 document library. I haven't succeeded in putting all this together so far... Would you have any direction for me?
Thanks!
Eric

Hi Eric , I do't have an Exchange 07 server to hand right now but if memory serves me right when you create the managed folder you then add the URL to the doc library to the properties of the managed folder.
I know a few people have blogged on how to do this with records archives but it should be the same process.
One thing I have not tested is if this works on all types of templates or if it is a Publishing thing for it to work properly.
I think it is time I did a series of whitepapers on Exchange 07 and SharePoint for this type of question. Just need the spare day or two now :)

Steve

Thank you Steve for your quick answer. Actually, I haven't seen any place to enter an url address in my Managed Folder properties under Exchange. There is an interesting blog here:
http://www.sharepointblogs.com/helloitsliam/archive/2006/09/28/13029.aspx
but it essentially suggests to forward incoming emails to the MOSS page's email address.
I guess I'll have to be patient and wait for your whitepapers :o)
Thanks,
Eric

Hey fellas,

I ended up going a different route after all (instead of setting up Incoming Email since I'm only running one server).  I set up an Outlook 2003 Macro button that just saves the Outlook message to Sharepiont directly using the http link.  Since the user's already logged into the system, it shows up as a new doc from him/her with all the info inside (including any attachments).  When you click on it, it opens the message within Outlook, meaning a user could go back in and forward/reply if they wanted to.

I also put in a couple of modifications so that the user can type his/her own title and append a Sharepoint contact (got to that by copying down the contacts list to Outlook, then querying it from the macro) rather than using the built-in subject (so we don't have to worry about "RE:" or "FWD:" prepended text).

Good times!

John

Hi,

I just went through the whitepaper and it helped out tremendously.  The only thing though that I didn't see in there was that if your server that hosts SMTP for WSS 3.0 actually has an internal domain name, you'll have to update the SMTP Domain to match that of the MX record you set up in DNS.  For example:

I set my MX record to be: servername.domain.com

The actual server's FQDN is: servername.domain.corp

The default SMTP domain is: servername.domain.corp

I had to change it to servername.domain.com to match the MX record in order for it to actually get the mail sent to it.

After that, works like a charm!!

One more question, do you know if e-mailing posts to a list supports e-mailing HTML?

P.S.  I have a complex Exchange environment here and didn't have to set up any sort of SMTP connector for this.  I didn't have to touch Exchange at all, just in case anyone was wondering.  The key is matching up that domain name you want to send mail to, with the domain name on the SMTP server.

I've got a very similar problem to a post by Eric I've quoted below.  However, I'm not getting any events in my Application log indicating any problems.  Is there a log  I can look at to see what's happening to the message after the SMTP server receives it?  

Eric Said:
Well, I have a new one for you guys:
After some hours, I finally have emails in my drop folder.
Now... After a few seconds, the message is deleted so I guess that the Sharepoint Timer has done the job. Unfortunaltely, the message never appears in my discussion list !!!
I know what you're thinking... but yes, I'm looking at the right list :o))
Any idea where I can find a trace of how my message is being processed by the timer??
Thanks in advance for your answer! I know I'm almost done with all this...

I had the same problem with the generic "Error in the application" when trying to add an email address to a list and after following the Microsoft KB and changing it in the Sharepoint Central Administration, I was able to get sharepoint to hook into AD and create the new email addresses, and they work.

The problem I have now is that I can only access the sharepoint site from the WSS server.  For every other computer, i get the request for login 3 times and then it errors out to the HTTP error 401.1.  Does anyone have any thoughts on what might be going on?  

I have two questions regarding the configuration of email. The first, since I installed the incomming email server on one of my MOSS servers, I get email to the lists and libraries without problem. However, because the server is xxx.mydomain.com, everyone has to remember the xxx part, which is something I'd like to avoid. You mention two methods to solve this problem in your white paper, however, since I don't have permissions to Exchange, I am not able to add/modify the email addresses via an AD taskpad, so the simple solution (although potentially time consuming) is out unless there is a way to give specific permissions on Exchange to only those addresses in the MOSS OU. The second option, which seems like the more reasonable and least ongoing effort, to set up a global recipient policy, is something I can't figure out and all the information on the web that I've been able to find says that you can't create a GRP on an OU. If there is a specific way to do it, maybe someone can provide that info.  

The second issue is that I've noticed that when I create a distribution group email for the members of a sub-site group (e.g. IT Site Members), no entry is found in AD for that group. Additionally, an email sent to the distribution group address (itmembers@xxx.mydomain.com) doesn't get distributed. I see the message pop into the mail drop on my server, then I see it disappear. I am unsure where to look for what is happening to the message, or how to fix this problem.

Any suggestions?

Well, I've racked my brain here using the documents, reading the forum notes, etc. and I am having a difficult time getting the "Directory Management Service" side of things running.  I can successully receive email into my document libraries but no matter what I do the directory management side continually causes an "Access is denied" message on the screen.

OUR SETUP:
First, I decided to run MOSS 2007 using a 4 server setup.  We have 2 Network Load Balanced servers configured to act as Web Front-Ends and the incoming SMTP servers.  The remaining two servers consist of 1 MOSS App Server for handling Excel Calculation Services, Indexing, and Cental Admin Site hosting and a single database server running Sql Server 2005.

Running 'Active Directory Users and Computers' under the SharePoint Central Administration Application Pool account I was able to successfully create users, groups and contacts in the SharePoint OU I created to house MOSS generated Distribution Lists.

It feels as if I am running into a permissions problem somewhere "other" than in Active Directory.  Does the fact I've seperated Central Admin Site functionality and Web Front-End services onto seperate machines confuse the issue?

As I mentioned, I'm successfully getting emails through to the Document Libraries, it is just when I turn on Directory Management Services that I continue to receive "access is denied" messages.

Any help would be appreciated.  I imagine I've overlooked a minute detail somewhere so some outside perspective / help would be appreciated.

you are right this sounds like a permissions / account issue accessing the list. Couple of things to try. not saying that you have to do this but just to see if it helps as others have said this helped them in the past due to way they had built their servers.

1. Try making the  Central Administration Application pool account and the SharePoint Timer Service account use the same service account.

2. try making the app pool account for the web application you are trying to mail enable run as the MOSS Administrator account you are running Central Administration under

Steve Smith

The easiest way to synch the accounts\passwords to get round the permissions issue is:

Ø  Go to the server central admin box:



           1. run the command stsadm –o updatefarmcredentials –userlogin <domain\name> -password <newpassword>

2.     User must run IISReset /noforce to complete the action.

3. Delete the updatefarmcredentials timer job on central admin page->operations->job definitions page



Ø  Go to each other server in the farm:



            1.  run the command stsadm –o updatefarmcredentials –userlogin <domain\name> -password <newpassword> -local.  

o    If –local isn’t supplied, it will fail because step (4) created a timer job that locks creating OTHER timer jobs.

   

   Ø On any machine after this completes (wait for the "Administration Application Pool Credential Deployment" job definition to go away on the Timer Job Definitions central admin page)

       a.     stsadm -o updateaccountpassword -userlogin "domain user" -password "newpassword" -noadmin

It worked for me!

Got it from here: http://blogs.msdn.com/joelo/archive/2006/08/22/712945.aspx

Steve,

Sorry for the late reply.  In response to #1 I examined the accounts assigned to the Central Administration Application Pool and the SharePoint Timer service.  Both are running off of the same account (SPConfigAcct).

As for #2, I'm not sure what you mean by "the MOSS Administrator account you are running Central Administration under".  If you are referring to the credentials used to run the Central Administration Application Pool then I understand.  Otherwise I'm not sure which account you may be referring too.  

Also, to change the app pool account for a web application do I need to use the stsadm tool or can I just log onto each webserver in my farm, change the Identity information for the application pool, and restart it?

Ron

Hi ron , yes I was refering to the account running the central admin App pool. make sure this account is a domain user as well.
As for the method to change the app pool accounts you can do this through STSADM as mentioned above or you can use the Gui method through central admin - operations - service account

Steve Smith

Hi Steve.  First, thanks for all the help and recommendations.  I really appreciate it.  

Now, I've changed the service account on my test site (mosstest) so that it is running off the same service account as my Central Admin Account.  After the IISRESET /NOFORCE of each server I still get an access denied message when I try to add incoming email functionality to a list.

Any other ideas?

Ro

I have just added some more troubleshooting tips on the whitepaper so see if any of those new ones help at all.

Steve Smith

Try this, check IIS on the frontend wssv3 or moss server. Look in the application account settings for the application pool for your site.

Make sure the account login is fomated as domain\poolaccount and not domain.local\poolaccount.

I setup 2 accounts 4 months ago and just today fix why one site worked great (domain\poolaccount) but the 2nd site gave me the error in application error (domain.local\poolaccount)

If this work please tell people so this gets fixed I spend so much time working on this one.!!!!

Has it ever been resolved that web applications running under non domain admin accounts do not properly create the objects in the AD when you try to mail enable a document library?

I just followed these instructions and am having similar problems as everyone else.  I have a domain admin account running my central admin app pool; creating a mail enabled doc library works fine under this web application.  However, my user portal is running under a regular domain user account for its app pool.  Trying to create a mail enabled document library gives me the standard "Error in application" as everyone else.  I have delegated control to the app pool account inside of the OU to no avail.   So despite Microsoft's claims, more rights are needed here to make this work.

I'm suspecting that nothing short of making the current app pool for the portal web application a domain admin is going to work -- that seems to be how others solved this issue.  Obviously this isn't a good solution, but what else can be done at this point?  It's clearly an issue that the regular domain user account does not have rights to update the Active Directory _despite_ having proper delegation assigned to the OU.  

If I opt to go the brute force method and make the account a domain admin, what are the hazards to using this account to run the app pool for the web application for the general public?  

I'm not sure if anyone has run into this problem, but at first Sharepoint could create an AD account, but emails would get returned to sender because the email address could not be found.  I tried for about 3 hours of changing rights and doing everything under the sun to the Active Directory rights.

Here is what happened.  Our email server was @something.us yet our smtp on the Sharepoint server was @something07-something.net (FQDN).  You have to make sure that the Incoming E-Mail Server Display Address in the Sharepoint Incoming Email settings are set the the FQDN and not your email server name.

Also another random tidbit is that the account created in AD is not visible, didn't have an email address, and could be found through the find.  At first I thought it wasn't adding the email address correctly and thats why there wasn't one, but it turns out that it doesn't need an email address...its just a pointer to the SMTP.

Anyways, this was my first time doing any of this and I hope it can help someone else out so they don't have to struggle with these things.

Hello Steve,

We have following issue in our SharePoint environment.

We have three servers in our SharePoint server farm. Two Frontend servers (one is Query and the other is Index Server) and one DB Server. We have installed SMTP virtual server on only one Frontend server (Query Server).

Second thing, we have separate IIS AppPool accounts (Domain accounts) for Central Administration site and SharePoint Web Application.

We have followed Combined-Knowledge white paper to configure email enabled lists/libraries in SharePoint however we were unable to create contacts in OU after delegating control to Central Administration site's app pool account with "Full Control" and even after adding Central Administration site's app pool account to Domain Administrators group with full access to entire domain :-)

We resolved this issue by,

1. Removing Central Administration site's app pool account privileges as "Domain Administrator".
2. Delegating control to Central Administration site's app pool account with "Write" privileges as suggested in Combined-Knowledge white paper and removed "Full Control" permissions.
3. Adding SharePoint Web Application's app pool account to Local Administrators group, where we have installed SMTP Virtual Server. This way Web Application's app pool account will have Full Control to C:\Inetpub\mailroot\Drop folder.

We may try by removing SharePoint Web Application's app pool account from Local Administrators group and giving "Modify" permissions to C:\Inetpub\mailroot\Drop folder (as suggested by Microsoft Technet article - http://technet.microsoft.com/en-us/library/cc262947.aspx) and it seems that it should work but the question is what is the correct way of configuring incoming email feature in SharePoint (MOSS 2007) to avoid any email issues (e.g. email receiving issues/duplicate email issues/routing issues/issues with Timer Service to pickup emails from Drop folder) in future?

Please help!

I have not tried this but I think it should work,

- Delegate control to  Web Application's app pool account with write access instead of Central Administration site's app pool account, provided you are not going to create email enabled lists and libraries in SharePoint Central Administration site.

- This should allow us to create contacts in OU and email enabled lists and libraries in web application (Sharepoint Site Collections and their sub sites).

Steve,

Thanks for the whitepaper. It has been very helpful. I have it all working but the very last part. i sent an email to the list and then watched the SharePoint server mailroot\drop folder. Nothing appeared. so I checked the other folders and found that the emails were ending up in the mailroot\queue folder. So I used the advanced options in the incoming email settings to point to that folder as the location to get the messages from. Now I see the messages appear and then disappear but I don't see anything show up in the document library. I looked in my application logs and I see:

A critical error occurred while processing the incoming e-mail file C:\Inetpub\mailroot\Queue\NTFS_6821183301c894fe00000003.EML. The error was: The process cannot access the file 'C:\Inetpub\mailroot\Queue\NTFS_6821183301c894fe00000003.EML' because it is being used by another process..

And then after several of those messages I see:

A critical error occurred while processing the incoming e-mail file C:\Inetpub\mailroot\Queue\NTFS_cf100eed01c894e800000002.EML. The error was: Bad senders or recipients..

But unlike the eariler similar error that was reported i am not using a POP at all. Any help would be appriciated.

Ben

I just found another error. In the System event log I see the following message:

Message delivery to the remote domain 'sharepointdl.domain.com' failed for the following reason: Unable to bind to the destination server in DNS.

This seems strange to me since the message is arriving on the server. Let me know if you have any ideas.

Some folks have mentioned that once you change the Central Admin application pool to a domain account instead of the Network Service account remote users can no longer login. This occurs when using Integrated Windows Authenication with Kerberos instead of NTLM, and IE as the browser. Either change to NTLM as the authentication method or register the app pool service account SPN to the domain account you are using. There are a number of MS KB articles about this:

http://support.microsoft.com/kb/871179 is one

I finally got it working correctly. It ended up that I had to add an alias in the SMTP server domain section in IIS.

Hello All,

Anyone know if it is possible to have the value, to the right of the @ in the "E-mail server display address" filed configured differently based on the sub site name.

For example
If my root site is called moss2007, i might create a value in the  "E-mail server display address"  field like @Moss2007.com which is great for lists at the root.

However for my subsites i might like to have a value in the  "E-mail server display address"  some thing like @subsite1.Moss2007.com

So in the end i would like to be able per subsite to either keep the @Moss2007.com or optionally create a new value like @subsite1.Moss2007.com

This would go along way to help with Unique email names per list as well as better structured naming convetion for these e-mail enable list.

Although this post is somewhat old, I think that people are finding it as a good guide, and using the white paper.  Here are some things that I learned:

1.  If you are getting a "Error in the application" error, you can enable some advanced information display by turning off custom errors.  Here is the link that helped me do this:  http://blogs.msdn.com/joelo/archive/2007/10/23/email-enabled-lists-and-inbound-email.aspx

Note:  web.config for me was located in %Inetpub%\wwwroot\wss\virtualdirectories\mysiteurl

2.  Maybe it's our particular AD setup, but rather than simply giving my app pool accounts "write" delegation as noted in the white paper, I also had to give it "create child object" and "read".  I found information that led me to this conclusion here:  http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1670215&SiteID=1

Hope that this helps resolve some of the permissions issues...

Sorry, the link to disable custom errors is here:  http://blogs.msdn.com/ecm/archive/2006/10/30/building-tylerbutler-com-part-1-planning-and-basic-branding.aspx

Please ignore the above link.  Duh!

I seem to be having two similar problems to those listed above.  The first is the same as beckyn's.  Every minute of every day on the minute I am getting an error log:
Event Type: Failure Audit
Event Source: MSSQLSERVER
Event Category: (4)
Event ID: 18456
Date: 22/07/2008
Time: 13:41:00
User: HUTCHINS\apolloSQL
Computer: APOLLO
Description:
Login failed for user 'HUTCHINS\apolloSQL'. [CLIENT: <local machine>]

ApolloSQL is both the account that the database service runs with as well as the account that the sharepoint central admin and now the website that I want email to work with.  

I have gone throught he whole procedure listed above to change all the passwords.  This made no difference.

This error has been there ever since I installed MOSS and it does not seem to cause any problems, but I could be mistaken.  Given he frequency of the error, I suspect it has something to do with the timer service.


The second problem is the same as Eric's.  That is, the mail is sent.  It arrives in the drop folder and then a little late disappears.  It does not turn up in the document library.  There are no error logs relating to this that I can tell.  I have not got POP3 installed

It is possible that these two issues are related.

Thanks