E-mail enabled list alias information is not synchronized between configuration database and content database

E-mail enabled list alias information is not synchronized between configuration database and content database

  • Comments 8
  • Likes

BEHAVIOR/SYMPTOMS: 
====================
A WSS 3.0 or MOSS 2007 site has one or more incoming e-mail enabled document libraries or lists.  New emails sent to the library's e-mail address stop being
added to the library:  The e-mails are received by the server, the .eml file is placed into the e-mail drop box, and then the .eml disappears from the dropbox as
SharePoint picks up the e-mail.  However, the incoming email is lost and is never added to the document library.


ERROR MESSAGE: 
====================
In the Application log of the Event Viewer, the following Warning is found:
Event Type:        Warning
Event Source:      Windows SharePoint Services 3
Event Category:   E-Mail
Event ID:             6873
Date:                    <date>
Time:                   <time>
User:                    N/A
Computer:            <Computer Name>
Description:
An error occurred while processing the incoming e-mail file
C:\Inetpub\mailroot\Drop\<ID number>.eml. The error was: Unknown alias.
In the ULS log, this Warning may appear:
12/18/2008 12:33:27.03   OWSTIMER.EXE (0x0C54)    0x06A0     Windows SharePoint
Services      E-Mail    6873       Warning      An error occurred while processing
the incoming e-mail file C:\Inetpub\mailroot\Drop\<ID number>.eml. The error was:
Unknown alias.

CAUSE: 
====================
The configuration database stores the email alias information in the Alias column
of the dbo.EmailEnabledLists table.  The content databases stores the email alias
in the  tp_EmailAlias column in the dbo.Alllists table.  Comparing the information
between those two locations, the alias information will not match or will not be
present in the configuration database.
Because the configuration database is unaware of the alias which has been set in
the content database, the email will be discarded rather than sent to the document
library.  Also, the "Unknown alias" error will be recorded in Event Viewer and ULS
trace logs.
In at least one case, we observed this behavior when a customer joined an incoming
e-mail server to the farm with a version mismatch. This server was at an earlier
version than the rest of the farm.

RESOLUTION/WORKAROUND:
============================================================
Running the command stsadm.exe -o refreshdms -url <URL name> will pull the e-mail
alias information from the content database and write it to the configuration
database.
Note:
In some cases, this problem has been observed to recur.  Running the stsadm -o
refreshdms command will temporarily resolve the problem.  In cases where it is
recurring, it is prudent to script the stsadm -o refreshdms command to run at
regular intervals in order to minimize the chances of data loss as e-mails are
discarded.

Comments
  • I am not using DMS. Will this command work? If not is there any other command.

    Thanks

  • yes we can still use it

  • I am running the stsadm command but getting error in the application.

    Any suggestions?

    Thanks

  • I am creating an Document Library Instance using custom Document Library Definition. In this case, the Incomining Email Settings link under Communications is not visible. Though I am able to attach the emailAlias programatically, the properties are getting set, Also I am able to see the Alias in AD. The email is been received in Mailbox\Drop folder and is also been picked up by Timer service, but doesn't appear in Document Library. In The Event Logs it gives the same error as you mentioned in the blog. I even tried executing the ststadm -o refreshdms -url <> command, but no luck. Any pointers what might be the problem. Is that the Incoming email functionality doesn't work with custom templates?

  • This really helped us, thanks!  Excellent post.

  • When I run the stsadm command, I get "Cannot complete this action. Please try again." There's nothing in the log. Any ideas?

  • this article saved my day :) in my case this issue was affecting only one document library where the values in config DB and content DB were not matching (actually it was missing in the config DB)

    For other document libraries incoming email was working

    I just had to disabled and re-enable incoming email for the problematic doc lib

  • Thank you for posting this. We migrated our 2010 environment to 2013 and no emails were going out. That command line helped get things moving along.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment