Task 'SharePoint' reported error (0x80070005) : 'You do not have permission to view this SharePoint List HTTP 302
Hi folks, I have an error I haven't been finding any information to resolve about: Configuration: Exchange 2007 MOSS 2007 ISA 2006 Windows XP Professional SP2, Office 2007Inside the network, everything works fine. Also when connected via a VPN (through ISA). Exchange and MOSS are published via ISA to the Internet. Outlook Anywhere with Outlook 2007 works fine- also accessing OWA and Sharepoint via the web browser. Sharepoint web publishing rule is set to NTLM authentication. OWA and sharepoint web publishing share a single web listener (to enable SSO) that uses HTML Form Authentication with persistent cookies. The original host header is forwarded and requests appear to come from the ISA server. Requests are bridged from https to http. Problem: When synchronising Outlook from remote, the following error messages are displayed: Task 'SharePoint' reported error (0x80070005) : 'You do not have permission to view this SharePoint List (Intern - Aufgaben). Contact the SharePoint site administrator. HTTP 302.' Also, when editing a list in dataview the changes cannot be synchronized back.Any ideas?-Marcel
September 11th, 2007 4:32pm
You get this error when Outlook is connected to Exchange using Outlook anywhere? Is the external SharePoint URL the same as internal?
September 12th, 2007 1:18pm
>> You get this error when Outlook is connected to Exchange using Outlook anywhere? Yes, connected and synchronised. >> Is the external SharePoint URL the same as internal? Yes, the external and internal URL are the same - except that the ISA server does a translation from http://sharepoint.domain.com to https://sharepoint.domain.com
September 12th, 2007 4:52pm
Hi! What kind of list are you talking about? Is this a custom list? If yes, then Outlook does not support synchronizing custom lists in SharePoint. If not, the error indicates that you do not have sufficient permission on the SharePoint. Either to one or to all fields that you're trying to write. Might permissions be the problem? What kind of list is it? Try to create a new contacts list, and synchronize this list with Outlook. Does it work then? It also might be that there is a custom column created that causes problem. Thus creating a new list and verify the issue on the newly created list might be the easiest way to solve this problem. I have written an article series about Outlook & Sharepoint interconnectivity that you might find interesting to read.You can access the latest one here: http://www.windowsitpro.com/articles/index.cfm?articleid=96955&feed=ArticleLink&promocode=rtartpage Hope this might help toresolve your problem. Good luck! Best, Sigi
September 13th, 2007 11:07am
It is a standard contact list and synchronisation works fine when the Outlook 2007 client is within the LAN or connected via VPN. Only when working from remote without VPN (connected through the internet), the error message appears. On the ISA Server, I get the following log entry: Original Client IP Client Agent Authenticated Client Service Destination Host Name Transport HTTP Method Filter Information GMT Log Time Processing Time Bytes Sent Bytes Received Cache Information Error Information Log Time Client IP Destination IP Destination Port Protocol Action HTTP Status Code Client Username URL Server Name Log Record Type 0.0.0.0 Microsoft Office/12.0 (Windows NT 5.1; Microsoft Office Outlook 12.0.6017; Pro) No Reverse Proxy sharepoint.company.com TCP POST Req ID: 07e4d5c9; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=no, logged off=no, client type=unknown, user activity=yes 13.09.2007 21:08 62 178 5584 0x0 0x200 13.09.2007 23:08 84.XX.XXX.XXX YY.Y.Y.YY 80 http Allowed Connection 302 anonymous http://sharepoint.company.com/kunden/_vti_bin/lists.asmx SERVER Web Proxy Filter Which corresponds to the 302 error in Outlook. Does Outlook 2007 not understand http 302 redirections?
September 13th, 2007 8:54pm
Marcelw,Did you every resolve this issue? I am having the same problem with a Sharepoint Tasklist being synchronized from Outlook (outlook anywhere ) using ISA ServerthanksShawn
January 14th, 2009 10:47pm
Has anyone figured out this issue?I'm having the same problem and can't find any concreate information on how to fix it.Thanks
February 4th, 2009 3:30pm
We had this problem after setting up its new DNS name (internally and externally), as well as adding an SSL key. We weren't really sure which one caused it, but to fix it, we did the following: Go into SharePoint Central Administration Go to Operations Under Global Configuration, select Alternate access mappings Choose your Alternate Access Mapping Collection from the dropdown (e.g. SharePoint - 80) Make the Default zone your new DNS name, including if it's SSL'ed or not (e.g. http://portal.company.com or https://portal.company.com) In doing this, it removed our URL settings for Intranet and Internet, since they were the same. We can now create/modify/delete our IT calendar linked to Outlook 2007 from SharePoint 2007.Wehope this helps!
March 5th, 2009 10:48pm
Hi, I running into the same problem. I have the same configuration. ISA 2006, Sharepoint 2007,Outlook 2007 My AAM has Default https://SITE1.comIntranet http://SITE1.com for searchmy ISA converts all http://SITE1.com to https://SITE1.com I add my calendar fromhttps://site1.com/and I get the error.I bypass ISA by going directly to sharepoint and I get the error. I have downloaded and installedoffice-kb959642 which didn't help.Anyone got any ideas. I can't get rid ofhttp://site1.com/from AAM because it will break search.ThanksKevin
March 25th, 2009 7:59pm
I got mine working,In AAM I had to change it so it looks like this:Default https://SITE1.comIntranet http://servername for searchIf I put http://SITE1.com it fails. I suspect Outlook doesn't handle the redirection right.Kevin
March 25th, 2009 8:35pm
Do NOT propose your own answers.Propose other people's answers and wait for other people to propose your answer(s).The first "answer" you proposed here was in any case a message saying that you are "running into the same problem" . How can that possibly be an answer ?WSS FAQ sites: WSS 2.0: http://wssv2faq.mindsharp.com WSS 3.0 and MOSS 2007: http://wssv3faq.mindsharp.com Total list of WSS 3.0 and MOSS 2007 Books (including foreign language titles) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx
March 26th, 2009 5:12am
does this apply to wss 3.0 im running wss 3.0 and outlook 2007. are those 2 even supposed to synchronize by design? im getting the same 0x80070005 errord3v
April 24th, 2009 5:46am
Hi,Did you every resolve this issue? I am having the same problem.Thank uRafik - Consultant Sharepoint
February 24th, 2010 7:11pm
i found that wss 3.0 and outlook 2007 are designed to synchronize properly. However I was never been able to resolve this issue on our network. IT would been a killer feature. d3v
February 24th, 2010 11:16pm
I have the same problem and I need to resolve - I've tried in Outlook 2003 and Outlook 2007 - can create folder , but events sync fails. Nothing anywhere I have seen resolves this issue.
February 26th, 2010 3:23pm
Resolved this issue, by removing certain "verbs" in the Web.Config for the site. These were added from a conversion from .NET 2.0 to .NET 3.5. Just do a bit of testing by removing certain "verbs". If that doesn't work look at your permissions for the list and permissions in Web.Config.Hope this helps. - Apologies - just proposed my own answer - can't undo
March 4th, 2010 8:54am
Hi I just had the same problem with one of our customers servers. Their AAM looked like this: default: https://intranet.domain.com intranet: http://intranet.domain.com With the above configuration and the ISA redirection from port 80 to port 443 (http to https) they were unable to sync a calendar with sharepoint. Even though all URLs in the Outlook 2007 file named "userlogin.sharing.xml.obi started with https:// when using fiddler I saw that http:// was used to start the sync and therefore generating a http 302 (temporary redirect because of the ISA). When I saw that I removed http://intranet.domain.com from the AAM and the sync started working. Funny thing is I re-added the entry to the AAM in the custom zone and it is still working even for new Outlook connections. I don't know why outlook prefers the intranet zone since the default zone should be the first to use especially when it was used to connect the calendar but maybe someone at microsoft can shed some light on the priority of URLs when using webservices. I hope this can help anyone
April 14th, 2010 6:42am
Resolved this issue, by removing certain "verbs" in the Web.Config for the site. These were added from a conversion from .NET 2.0 to .NET 3.5. Just do a bit of testing by removing certain "verbs". If that doesn't work look at your permissions for the list and permissions in Web.Config.Hope this helps. - Apologies - just proposed my own answer - can't undoHi. I'm relatively new to IIS/Sharepoint Can you plase explain what these "verbs" are and give an example maybe?d3v
April 15th, 2010 10:56pm
Has anybody solved this issue? One of my remote users is experiencing the same problem.
May 25th, 2010 6:56pm
Oh, you don't need specific samples. Just remove certain ones, and it'll work! Sheeeeeesh. Erm... yeah, if anyone can help provide some detail, this would really help: we're running into the same issue and I don't really want to go "remove 'certain' verbs" on a production server without knowing what I'm removing! --Dave
December 1st, 2010 10:51am
Dave, I have to admit I didn't want to give specifics due to it being possibly a lucky fix. Like I said - try testing by removing certain verbs or adding verbs in Web Config - this will not ____ it up as long as you change back and you may be required to restart IIS. This MAY solve the issue. Thanks. John.
January 4th, 2011 6:16am
This still sounds like a bad idea for a production server, unless there is some scheduled downtime.
January 4th, 2011 12:51pm
You would think with 10k views and 21 responses someone would have a better answer than "try testing by removing certain verbs or adding verbs in Web Config"... -Dustin
January 5th, 2011 12:57pm
Who said anything about doing this in production Dustin. All testing should be done in a development environment which should be a mirror of production. If you haven't got this setup then you are asking for trouble. Just a reminder - noone proposed "try testing by removing certain verbs or adding verbs in Web Config"... as the answer anyway.
January 6th, 2011 1:21pm
I agree a dev environment would be ideal, but I am not in control of that. And, as the solution "try testing by removing certain verbs or adding verbs in Web Config" solved your problem, it is a possible answer for the situation (and may be the only answer, as this thread has been ongoing for 4 years). I was simply surprised by the amount of input this thread has received without an actual accepted answer. Sorry for any misunderstandings I may have caused. If I find a better solution I will make sure to post it, if I resort to your advice, I will make sure to propose your solution as an answer. Thanks, Dustin
January 6th, 2011 1:49pm
No problem Dustin. Keep pulling your hair out like the rest of us.
January 13th, 2011 1:29am
Thanks John, there has been lots of hair pulling... Still no luck on this though, forwarded on to our outlook admin to see if it might be outlook related.
January 14th, 2011 1:10pm
I just wanted to post feedback to this question. I finally resolved my issue by configuring incomming email. Even though outgoing email had been set up on the server, when the server was set up the incomming email was either configured wrong, or the administrator simply forgot to configure it. I would definitely recommend checking incomming email settings before spending a lot of thinking this is probably a deeper issue, especially if you were not the one to set up your sharepoint environment.
January 21st, 2011 11:32am
Has anyone managed to resolve this problem?
February 23rd, 2011 8:16am
Has anyone managed to resolve this problem?
February 23rd, 2011 8:16am
Simon, I solved this problem by adjusting the web application properties. The way our web application was configured, it was hosted on port 1000, with the server redirecting port 80 to 1000. By stopping the default web application and putting the SharePoint web application on port 80, it solved this issue for me. Note: This did not require and IIS restart and had no noticable down time if you change the sharepoint web application port first then stop the default web app. Dustin
March 25th, 2011 12:25pm
Below is the order in which the AAMs are added to the property by SharePoint. SPUrlZone.Intranet SPUrlZone.Default SPUrlZone.Extranet SPUrlZone.Internet SPUrlZone.Custom Hence the Intranet zone would be the first zone leveraged by the Outlook sync. For Eg Outlook Calendar Sync fails with error when AAM has Default Zone: https://SharePoint Intranet Zone: http://SharePoint Error: Task 'SharePoint' reported error (0x80070005) : 'You do not have permission to view this SharePoint List .Contact the SharePoint site administrator. HTTP 302.' If we change the Intranet Zone to Internet Zone like below Default Zone: https://SharePoint Internet Zone: http://SharePoint The outlook calendar sync issue should hopefully get fixed. Manjeet Singh
June 27th, 2011 7:35pm
Manjeet gave some good information. Our Intranet zone (HTTP) was being redirected to our Default Zone (HTTPS) for some functionality we were trying to enforce. The way in which we carried out this configuration involved AAM's and IIS port settings. Although it gave us what we wanted, it inadvertantly broke the Outlook synchronization across all Outlook-connected lists/libraries in our SharePoint site. Reverting back to our previous configuration, Outlook syncing worked perfectly. Now I just need to figure out how to configure the redirection so it works without impacting Outlook syncing. But the AAM property ordering listed above prompted me to go this direction. So thank you, Manjeet. It's almost an answer for me, but I'll be playing around with the configuration some more to validate the settings.
July 8th, 2011 2:48pm
Adjusting the HTTP address to the Internet Zone as suggested by Manjeet worked for me. It never would have occurred to me that the DEFAULT zone WOULDN'T be the first zone SP would use =) I suspect that the MarcelW would resolve the issue by placing the HTTPS url in the DEFAULT zone, leaving the INTRANET zone blank, and by placing the HTTP url in the INTERNET zone. Thanks Manjeet.
July 11th, 2011 7:18am