Using MOSS2007 Recently, I have started receiving a "401 unauthorized" error when trying to email enable a document library (the error has only been brought to my attention today - it is difficult to say when it started, as it is possible that no-one has tried to email enable a document library in several days/weeks) There does not appear to be any additional information in the ULS logs We have recently upgraded our Exchange server from 2003 to 2007, but again, I cannot confirm the exact date that this started occurring, so can't link it to this definitively. The problem appears to be in the creation of the contact in the OU - in the Incoming E-mail settings in Central Admin of MOSS, if I choose "No" for "Use the sharepoint directory Management Service to create distribution groups and contact", then the document library is able to be email enabled (although obviously, no contact is created) In confirming that this is setup correctly, I have followed this guide http://www.combined-knowledge.com/Downloads/2007/How%20to%20configure%20Email%20Enabled%20Lists%20in%20Moss2007%20RTM%20using%20Exchange%202007.pdf I have checked the following: The central admin app ppol and sharepoint timer service are using the same domain level service account This acount has access rights to all files (I have made it a server admin to ensure no problems here) This account is the MOSS administrator for Central admin The account has rights on the OU (full control) Mail is still being delivered to document libraries which were set up successfully in the past. I have been working with our AD admin on this, and so far, we haven't been able to find any logs that have been useful to us. I would have expected to find a failed login attempt on either one of the domain controllers, or the mail server, but haven't been able to find anything. Putting ULS logs to verbose has revealed the following error message (this was actually when I tried to update an existing email address): 02/23/2010 11:25:09.76 w3wp.exe (0x165C) 0x24E4 Windows SharePoint Services General 8nca Verbose Application error when access /_layouts/EmailSettings.aspx, Error=The request failed with HTTP status 401: Unauthorized. at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall) at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.DeleteContact(String Alias) at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String newAlias) at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration) at Microsoft.SharePoint.SPList.Update() at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender, EventArgs args) at System.Web.UI.WebControls.Button.OnClick(EventArgs e) at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) My original post on this was in the managed newsgroups (since deleted, but can see the archive here http://relatedterms.com/thread/2226676/401%20Unauthorized%20when%20trying%20to%20email%20enable%20a%20document%20library)I am still at the same stage on this. The only difference is that now we are running only Exchange 2007, rather than a mix of 2003/2007. Any ideas on how to get this working again, or how I can get more information would be appreciated. Thanks in advance for any assistance!

Hi, I think this must be permission issue. I would like you to check the web application pool account of the site not admin application pool account. Please make sure the web application pool account have “Modify” permission to that OU. For more information ,please refer to http://lambertqin.spaces.live.com/blog/cns!E93C48B467E6B3E1!1453.entry Hope this helps Thanks! Stanfford

Hi Stanfford, Thanks for getting back to me. The web application pool account has full control of the OU. Also, this WAS working, but just stopped suddenly. Any other ideas? Thanks in advance!!

HI, If you create new list,and enable the incoming setting, does same error occur?

yes - if I create a new list, and email enable it, the same problem occurs. If I say no to "Use the SharePoint Directory Management Service to create distribution groups and contacts" in the "Configure incoming email settings" section in central admin, and then email enable a list, it works (but clearly, there is no contact created in this case)

this sounds a bit hairy to diagnose, definitly should work. Have you tried to fiddler the call to the web service to see a. where the 401 error occurs (and check the windows logs of this server for, say, kerberos issues) b. if there's info in the response's http header itself

Hi Emmanuel, thanks for getting back to me!! I have tried Fiddler, and it didn't seem to provide me with any useful information. Further researching this, I started going through the security logs on all of the servers involved, and it appears that I am getting a logon failure on the Sharepoint front end web server. The failure is for the service account under which the application pool runs, not for the account which is actually trying to call the webservice. There are a couple of things about this that seem (to me) to be a bit unusual, but I'm not sure of how important they are: 1. the "Authentication Package" is showing as NTLM (we have kerberos enabled) - I suspect this is a large part of the problem, but not sure why it is occurring... 2. The IP address that is showing (replaced with SERVER_IPADDRESS below) is the IP address of the server, not of the load balancer Error details are below (details of server names, user names and ip addresses removed) - any ideas on this would be very much appreciated Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 9/08/2010 2:14:57 PM Event ID: 4625 Task Category: Logon Level: Information Keywords: Audit Failure User: N/A Computer: OURSERVERNAME.OURDOMAIN.com.au Description: An account failed to log on. Subject: Security ID: NULL SID Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: NULL SID Account Name: serviceAccountName Account Domain: OURDOMAIN Failure Information: Failure Reason: An Error occured during Logon. Status: 0xc000006d Sub Status: 0x0 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: OURSERVERNAME Source Network Address: SERVER_IPADDRESS Source Port: 51504 Detailed Authentication Information: Logon Process: Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe. The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network). The Process Information fields indicate which account and process on the system requested the logon. The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases. The authentication information fields provide detailed information about this specific logon request. - Transited services indicate which intermediate services have participated in this logon request. - Package name indicates which sub-protocol was used among the NTLM protocols. - Key length indicates the length of the generated session key. This will be 0 if no session key was requested. Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> <EventID>4625</EventID> <Version>0</Version> <Level>0</Level> <Task>12544</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2010-08-09T04:14:57.000Z" /> <EventRecordID>358627058</EventRecordID> <Correlation /> <Execution ProcessID="624" ThreadID="748" /> <Channel>Security</Channel> <Computer>OURSERVERNAME.OURDOMAIN.com.au</Computer> <Security /> </System> <EventData> <Data Name="SubjectUserSid">S-1-0-0</Data> <Data Name="SubjectUserName">-</Data> <Data Name="SubjectDomainName">-</Data> <Data Name="SubjectLogonId">0x0</Data> <Data Name="TargetUserSid">S-1-0-0</Data> <Data Name="TargetUserName">serviceAccountName</Data> <Data Name="TargetDomainName">OURDOMAIN</Data> <Data Name="Status">0xc000006d</Data> <Data Name="FailureReason">%%2304</Data> <Data Name="SubStatus">0x0</Data> <Data Name="LogonType">3</Data> <Data Name="LogonProcessName"> </Data> <Data Name="AuthenticationPackageName">NTLM</Data> <Data Name="WorkstationName">OURSERVERNAME</Data> <Data Name="TransmittedServices">-</Data> <Data Name="LmPackageName">-</Data> <Data Name="KeyLength">0</Data> <Data Name="ProcessId">0x0</Data> <Data Name="ProcessName">-</Data> <Data Name="IpAddress">SERVER_IPADDRESS</Data> <Data Name="IpPort">51504</Data> </EventData> </Event>

I appear to be getting somewhere on this - thanks largely to this post: http://blogs.msdn.com/b/jiruss/archive/2008/10/21/loopback-security-check-feature-iis-7.aspx I had already been through the KB article that this mentions, and had it set up using method 1, however I had not added the FQDN to the list of BackConnectionHostNames, only the netbios name - adding the FQDN seems to have got me moving forward. I can now see that the contact is being created in the AD OU, but currently the email address is still blank - not sure what is going on here, but at least I am past the first hurdle....

Arduk, You've been making leaps ahead, that's for sure. This would be a good time for screenshots, in fact, so that people can regroup and see where you are in the progress, and the behaviour that you're seeing once the contact is made. Can you supply any details? Also, are we getting any kind of new error message in ULS when that contact is made? Is there any message on the DC? Also, can you tell me if the account running your Central Administration application pool (and, thus, OWSTimer) is the same as the account running your web application? The group will be created by the account running the Central Administration service, but the task for approval for that group will be created by the account running the application pool for the site where the group is created. Because of this division of labour, I'm wondering if permissions issues still exist. To be sure, in Central Administration, under /Lists/Distribution Groups/Allitems.aspx, make sure that the application pool accounts are added. Do other lists work, by the way? Is this limited to groups with large memberships, for instance? Thanks, Tracy

When the contact is created by Sharepoint, the contact object is created in Active Directory, as well as in Exchange 2007. When I look at the contact, while I do see the proper SMTP address (the one MOSS assigned), I notice that the check box for "automatically update e-mail address based on email address policy" is not checked. The screenshot below is the image of the contact properties from the Exchange management tools. At this point, the contact does not show up in the global address book, and it does not seem to have an email address if you open it from AD users and Computers. After ticking the "Automatically update e-mail addresses based on e-mail policy" tick box (see screenshot below), the contact becomes visible in the global address book, and you are able to use it to send emails to the document library. Can anyone explain why this is not being created correctly, or give me some ideas on how to troubleshoot it? How does sharepoint create the contact? There is nothing showing up in the sharepoint logs. There don't seem to be any errors on the domain controller, or the exchange servers..... in answer to the questions from Tracy: the central admin application pool account is the same as the web application pool account. I am not talking about distribution groups here, just creating a contact when a document library is email enabled, but in any case, the application pool account has full control of the distribution groups list. The contact is not created successfully for any list that I email enable - I am not trying to create distribution groups, so it shouldn't relate to large membership size... Thanks in advance for any ideas on this!

There is no E-Mail addresses associated with AD Contacts created by DMS in Exchange 2007, this is known issue. untill now i couldn't find any good solution for this, the below link have given a briefly description for this: http://lambertqin.spaces.live.com/blog/cns!E93C48B467E6B3E1!1375.entry Hope this helps.

wow - what an enormous step backwards....... So now, instead of Sharepoint being able to create a contact, which would automatically appear in the global address book, we need to monitor whether a new contact is created, and when it is we need to manually update this setting?!?! I assume this is a bug that will be fixed at some stage, or is this behaviour "By design" (ie won't be fixed)??

I have no idea for this. i am afraid you need some experts in Exchange 2007 point out this.

no problems - thanks very much for pointing your assistance on this - I have been trying to get this to work for quite a while now, so at least I can now stop beating my head against the wall, and hand it over to the exchange admin ;) very frustrating when existing functionality is broken, especially when it is an "upgrade" that does it.... Thanks again to everyone for their assistance on this!