Jaa

SharePoint 2007 - Incoming Email

  • Artikkeli

There are many little "gotchas" with setting up incoming email for MOSS.  Just nit picky little things, normally they are all about email infrastructure, SMTP, etc. My advice below is to help you avoid taking your heart medication, it can be easy to set this up, but it can also be a hair pulling, eye rolling, staying up all night and getting no results kind of affair as well.

I promise, this technology does actually work, but if you deviate from the standard build (see list item 3 below for "standard build" as defined by me) you will fall off a cliff unless really understand what you are doing.

I'm not an exchange guru, just a humble BizTalk/Moss guy.

Don't just do this trial and error and play with settings until it works. It won't work. Be deliberate and intentional, setup the standard way and then slowly change things, each time checking to see if the forwarding still works.

This is where I recommend you start, read all this stuff first, before you race off back to your Virtual Machines.

  1. Plan incoming e-mail (Office SharePoint Server) <link updated - August 2009>
  2. Configure incoming e-mail settings (Office SharePoint Server) <link updated - August 2009>
  3. In addition to the technet site, a very good place to start is
    1. How to configure email enabled lists in Moss2007 using Exchange 2003
    2. How to configure email enabled lists in Moss2007 using Exchange 2007
  4. Read these documents and set it up in a lab exactly as described until it works
  5. Now introduce incremental changes to the infrastructure and after each one, verify that email is still getting through, or not.

Gotchas and Advice

  1. Trust me, for the first run, just make the FQDN of the moss server (SMTP server) the same as the @domain that you are trying to send to

    Clarification
    AD domain = example.com,
    moss server name = MOSS2K7
    moss FQDN = MOSS2K7.example.com
    email domain = MOSS2K7.example.com
    example address = myemail@moss2k7.example.com

  2. Trust me, for the first run, start off by actually allowing MOSS to own an OU and manage it's own contacts, don't be a cowboy and hope to configure them manually on the first try.

  3. Just do everything the default way the first time, use a lab environment if you have to

  4. Use the OWA website on your lab email server (or a local instance of Outlook conntected to that server)  to send emails around, don't try to hook-up external MX-Records and send from external emails.

  5. Keep and eye out for .eml files showing up in the Queue folder on the MOSS box. This is a sign that the SMTP server is forwarding them elsewhere and that is a sign that there is a fundamental problem with the email coming in.  Most likely the SMTP sever does not recognize that it is the utlimate destination for emails with that @domainname address.

 

If you try to read from the SMTP queue on the MOSS server, you will get

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

The solution to this is "DON'T READ FROM THE QUEUE". If the emails are in the SMTP queue on your Moss server then your email/smtp settings are probably messed up. (Perhaps you did not take my advice on keeping the FQDN of the MOSS server the same as the @domain name that you are sending mail to?)

______________________

If you try to "drag and drop" from queue to the drop folder manually, you will get

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

Don't tell me, let me guess. You copied the .eml files from the Queue folder to the Drop folder and then saw sharepoint delete them. Same point as above, If the emails are in the SMTP queue on your Moss server then your email/smtp settings are probably messed up. (Perhaps you did not take my advice on keeping the FQDN of the MOSS server the same as the @domain name that you are sending mail to?)

_______________________

Comments

  • Anonymous
    October 26, 2007
    PingBack from http://www.soundpages.net/computers/?p=5177

  • Anonymous
    November 26, 2007
    An user at the customer where I&#39;m working at the moment asked the functional application manager

  • Anonymous
    February 20, 2008
    Thanks for the very helpful suggestion that email delivered to the queue folder is an indication of something wrong. Now at least I can stop looking at OSS and concentrate my efforts on SBS.

  • Anonymous
    April 02, 2008
    The comment has been removed

  • Anonymous
    June 04, 2008
    Ramesh: Sorry to be a little slow in the response, but I too just came across this issue. You to Central Administration > Operations > Incoming Email Settings. Modify your configuration from Automatic to Advanced. Then change your 'email' drop folder to the SMTP email drop folder.  Even though I'm using the default SMTP configuration 'C:inetpubmailrootdrop'.  I needed to set this value to fix the error. Best of Luck: Dylan Phillips

  • Anonymous
    March 24, 2009
    Are these instructions the same for SBS? For some reason I believe I've read somewhere that WSS uses the network service account...how do I check to see which service account WSS is using?

  • Anonymous
    March 24, 2009
    Why would Automatic be greyed out in the incoming mail settings?

  • Anonymous
    May 29, 2009
    bryan not sure exactly why it would be greyed out, or what the implications of using this under SBS are. does the local server have the SMTP service configured in IIS? are your credentials highly priviledged? (both log on account and service credentials?)

  • Anonymous
    November 04, 2009
    I'm getting the same error message as malathyr plus an associated error like this: A critical error occurred while processing the incoming e-mail drop folder . The error was: Value cannot be null. Parameter name: path. This is only happening on the other Web Front Ends in the farm - NOT the one with the SMTP server installed.

  • Anonymous
    November 04, 2009
    The comment has been removed

  • Anonymous
    November 04, 2009
    I've checked that the Drop folder exists in the same place on all Sharepoint servers, and the permissions on the folder are the same everywhere. But I'm still getting those error messages.

  • Anonymous
    August 03, 2010
    I've just went through this task myself.   Our installation involves 2 WFE servers running Windows Server 2008 R2.  Both WFEs need SMTP installed and configured, add the feature, then CONFIG WITH IE 6.  The key on these two is to make sure that the default domain is the email domain you want users to send email to and the FQDN is the same. This is how the system determines that it is the final mail stop for all email to that domain. If they are not the same, then the SMTP service dumps it back out to the Smart Host. The email domain defaults to the servername.domain.com, which doesn't work for us.  Also, make sure you give your SP service account proper rights to the drop folder.  Once this is in place, we enabled incoming email from SP Central Admin, then enabled it on a doc library.  When doing this, the domain will take on the name of the FQDN you set on the SMTP server, you don't get to select or change it.  Just type an email address.  For inside to inside email, our Exchange admin intercepts our new.domain.com emails and forwards them to our load balancer address.  Works great.  For outside to inside email to doc libs, you'll have to have an MX record and or an alias to get it to Exchange, then it can be forwarded to your SP farm as before.

  • Anonymous
    October 27, 2010
    Hey...Relax.. the Alias entry for your SMPT service resolves the issue... :)