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: WarningEvent Source: Windows SharePoint Services 3Event Category: E-MailEvent ID: 6873Date: <date>Time: <time>User: N/AComputer: <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.
I am not using DMS. Will this command work? If not is there any other command.
yes we can still use it
I am running the stsadm command but getting error in the application.
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