locked
Task 'SharePoint' reported error (0x80070005) : 'You do not have permission to view this SharePoint List HTTP 302

    Question

  • 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 2007
    Inside 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
    Tuesday, September 11, 2007 4:32 PM

Answers

  • 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
    • Proposed as answer by IT Happens Monday, July 11, 2011 2:17 PM
    • Marked as answer by Mike Walsh FIN Monday, July 11, 2011 4:33 PM
    Monday, June 27, 2011 7:35 PM

All replies

  • You get this error when Outlook is connected to Exchange using Outlook anywhere?

    Is the external SharePoint URL the same as internal?

    Wednesday, September 12, 2007 1:18 PM
  •  

    >> 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

     

     

    Wednesday, September 12, 2007 4:52 PM
  • 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 to resolve your problem. Good luck!

     

    Best,

    Sigi

     

    Thursday, September 13, 2007 11:07 AM
  •  

    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?

    Thursday, September 13, 2007 8:54 PM
  • 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 Server

    thanks

    Shawn
    Wednesday, January 14, 2009 10:47 PM
  •  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
    Wednesday, February 04, 2009 3:30 PM
  • 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.

    We hope this helps!

    Thursday, March 05, 2009 10:48 PM
  • Hi, I running into the same problem. I have the same configuration.  ISA 2006, Sharepoint 2007,  Outlook 2007

    My AAM has
    Default https://SITE1.com
    Intranet http://SITE1.com for search

    my ISA converts all http://SITE1.com to https://SITE1.com

    I add my calendar from https://site1.com/ and I get the error.

    I bypass ISA by going directly to sharepoint and I get the error. 

    I have downloaded and installed office-kb959642 which didn't help.

    Anyone got any ideas.  I can't get rid of http://site1.com/ from AAM because it will break search.

    Thanks

    Kevin

    • Proposed as answer by Kevin M Parks Wednesday, March 25, 2009 8:33 PM
    • Unproposed as answer by Mike Walsh FIN Thursday, March 26, 2009 5:11 AM
    Wednesday, March 25, 2009 7:59 PM
  • I got mine working,

    In AAM I had to change it so it looks like this:

    Default https://SITE1.com
    Intranet http://servername for search

    If I put http://SITE1.com it fails. 

    I suspect Outlook doesn't handle the redirection right.

    Kevin

    • Proposed as answer by Kevin M Parks Wednesday, March 25, 2009 8:36 PM
    • Unproposed as answer by Mike Walsh FIN Thursday, March 26, 2009 5:11 AM
    Wednesday, March 25, 2009 8:35 PM
  • 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
    Thursday, March 26, 2009 5:12 AM
  • 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 error


    d3v
    Friday, April 24, 2009 5:46 AM
  • Hi,

    Did you every resolve this issue?  I am having the same problem.

    Thank u
    Rafik - Consultant Sharepoint
    Wednesday, February 24, 2010 7:11 PM
  • 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
    Wednesday, February 24, 2010 11:16 PM
  • 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.

    Friday, February 26, 2010 3:23 PM
  • 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
    • Proposed as answer by John Guilbert Thursday, March 04, 2010 8:54 AM
    • Unproposed as answer by Mike Walsh FIN Thursday, March 04, 2010 9:15 AM
    Thursday, March 04, 2010 8:54 AM
  • 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

     

    Wednesday, April 14, 2010 6:42 AM
  • 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

    Hi. I'm relatively new to IIS/Sharepoint 

    Can you plase explain what these "verbs"  are and give an example maybe?


    d3v
    Thursday, April 15, 2010 10:56 PM
  • Has anybody solved this issue? One of my remote users is experiencing the same problem.
    Tuesday, May 25, 2010 6:56 PM
  • 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

    Wednesday, December 01, 2010 6:51 PM
  • 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.

    Tuesday, January 04, 2011 2:15 PM
  • This still sounds like a bad idea for a production server, unless there is some scheduled downtime.
    Tuesday, January 04, 2011 8:50 PM
  • 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

    Wednesday, January 05, 2011 8:56 PM
  • 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.

     

    Thursday, January 06, 2011 9:20 PM
  • 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

    Thursday, January 06, 2011 9:47 PM
  • No problem Dustin. Keep pulling your hair out like the rest of us.
    Thursday, January 13, 2011 9:28 AM
  • 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.
    Friday, January 14, 2011 9:09 PM
  • Has anyone managed to resolve this problem?
    Wednesday, February 23, 2011 4:13 PM
  • 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

    Friday, March 25, 2011 12:25 PM
  • 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
    • Proposed as answer by IT Happens Monday, July 11, 2011 2:17 PM
    • Marked as answer by Mike Walsh FIN Monday, July 11, 2011 4:33 PM
    Monday, June 27, 2011 7:35 PM
  • 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.
    Friday, July 08, 2011 9:47 PM
  • 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.

    Monday, July 11, 2011 2:17 PM