Syncing OneNote to Sharepoint - Access Denied and Automatically Detect Settings

If you have a OneNote notebook on SharePoint you may have seen something like the following errors at some time:

• An 'infobar' appears at the top of the page in OneNote saying you don't have permission to sync to that section file
• You may have failed to create a new notebook on that SharePoint location
• You may have failed to open the notebook

One obvious reason you might get this is that you don't in fact have permissions to write to the SharePoint location. You should check that first, for example, by trying to write a simple text file there. But there could be other causes for this, most of which should be quite rare*. But if you're running on Vista there is one very simple reason that is likely to be quite common.

Automatically Detect Settings needs to be on

• You need to ensure that "Automatically Detect Settings" is checked on in the "Internet Options" settings in Internet Explorer, as shown below.
• You can get to this from Internet Explorer -> Tools -> Internet Options -> Connections -> LAN Settings

• If this option doesn't work for you because it messes with your browsing in Internet Explorer then go back to your original settings and read the rest of the nitty gritty in this post for other ways to possibly fix this.

* there's actually another possibly common cause, depending on your network conditions you may get time outs when connecting to your server that get falsely reported to OneNote as permissions denial. We have made some changes to address this issue that you'll see in a future service pack soonish. This should be intermittent though (unlike the auto detect settings issue) and likely fixed just by restarting OneNote once the network condition has improved.

Why do you need Automatically Detect Settings on?

There's a lot of details behind this that may be hard to follow if you don't know much about HTTP etc. I'll try and explain it briefly.

Background

• "Automatically detect settings" talks to a server on your network to get basic configuration information like proxy server
• In XP HTTP traffic goes over a protocol stack called WinInet
• In Vista there is also a new network stack called WinHTTP for HTTP traffic. This is a much improved HTTP specific stack. It was originally created for Windows Server 2003.  WinInet still exists on Vista for backwards compatibility.
• WebDAV (a protocol for accessing files over HTTP) was re-written in Vista to use WinHTTP. This was a significant improvement over the WebDAV stack in XP.
• However, many applications still use WinInet because they haven't been re-written to use WinHTTP on Vista. Internet Explorer for example still uses WinInet. And many parts of Microsoft Office still use WinInet. Parts of OneNote included.
• So on Vista when OneNote is accessing files on SharePoint it makes some calls to check on things like which files have changed and so on, that ultimately end up using the WinInet stack. But when it actually tries to write up changes to the file it uses WebDAV which uses the WinHTTP stack.
• Now there is a subtle difference in behavior between WinInet and WebDAV over WinHTTP. WebDAV on Vista has a rule that it never proactively sends your credentials over the wire unless you have auto detect settings on (because that's how it gets configured to know when to send your creds proactively and when not to). WebDAV defaults to assuming you're on open public internet when this is not set and doesn't send credentials proactively at all.
• Note: that your credentials are always encrypted anyway, so I'm not talking about plain text transmission here. WebDAV still thinks it's a good idea not to send them unless needed on public internet. It's good surface minimization.
• In theory, if WebDAV gets a permission denied response the user will be explicitly prompted for the credentials and WebDAV will then proceed to send them and you'll successfully connect.
• The reason for the difference in behavior is that inside a work environment people generally expect to just be able to connect to all their server resources without having to enter credentials for each server.

The problem

 

• OneNote syncs in the background relatively frequently. It's not just saving when the user hits save. OneNote is also syncing potentially several notebooks on different servers.
• That means OneNote can't just pop up random dialogs asking you for credentials every time it syncs, otherwise you might be working on one notebook, and get bothered by credential prompts randomly popping up from a second notebook syncing in the background. That would be pretty weird.
• So as a result, OneNote makes file access calls in a 'UI-less' mode. The layers under OneNote are told not to show credential prompts if there are permissions failures. The various networking layers below OneNote return "permissions denied" error codes. OneNote should then display an infobar saying you need to enter a password and give you the option to click it to enter the password. This is less intrusive than random cred prompts. And this infobar only shows when you're on the relevant notebook.
• However, in the situation above, the initial WinInet calls all succeed (checking the notebook is there, checking for which files changed etc.) and only writing the file up fails. This messes with this workflow a little and you get a slightly different infobar just telling you that OneNote got an access denied failure. This isn't very helpful...

This affects other apps too

• This problem manifests in different ways for different apps
• It's slightly less of a problem for traditional apps. Because they generally save in response to a specific user command only, and do it synchronously. They make all file access calls and network calls requesting full UI showing. This allows the underlying network stacks to just pop credential prompts whenever needed (it's also the reason they can hang while you're saving to a slowly responding network server...).
• So for many apps this manifests as you getting one to three credential prompts while trying to open a file. Sometimes these may fail and you'll end up with a read only copy of the file open.
• See this post on the SharePoint team blog for more details on this
  • By the way I would NOT "stop and disable the WebClient service" as suggested as one of the possible solutions on this blog post. It turns off WebDAV which will break OneNote syncing, and likely other apps too. And the "install Web Folder and run in XP compatibility mode" option has some unpleasantness too... Look to the bottom of the post for "Problem Description" and "Potential Workarounds" for other options.
• Note, that in theory the result should just be that you get a manual cred prompt and entering credentials should succeed. However, in practice I have noticed that there appear to be occasions and configurations where even after entering the credentials the access fails with other apps too. Still investigating.

What's being done to address this?

We're paying lots of attention to this issue. And here are a couple of things that are being done among others:

• There are hot fixes coming from the Windows team to help deal with this as mentioned on the SharePoint team blog post. The hotfixes are KB941853 and KB941890. These fixes are only available through support right now (e.g. if you're a corporate customer) but should be available in a future service pack after further testing and work.
• OneNote will also be doing work to have a better response to this particular kind of partial failure in the network calls, so the user gets more helpful information in the infobar and OneNote can prompt appropriately where possible.

Comments

• Anonymous
  November 28, 2007
  PingBack from http://www.shahine.com/omar/CredentialPromptsOnVistaWithSharepointAndOffice.aspx

• Anonymous
  November 29, 2007
  One bug report we've been trying to track down has to do with sections from Notebooks on Sharepoint servers

• Anonymous
  December 03, 2007
  Here at Microsoft we use a lot of OneNote shared notebooks a lot of those notebooks are stored on SharePoint. 

• Anonymous
  December 03, 2007
  Here at Microsoft we use a lot of OneNote shared notebooks a lot of those notebooks are stored on SharePoint

• Anonymous
  December 04, 2007
  BUT.... Latest Security update (Microsoft Security Advisory 945713) says that Automatic Detect Settings should be turned off, at least until a fix is available for the Web Proxy AutoDiscovery vulnerability.

• Anonymous
  December 10, 2007
  The comment has been removed

• Anonymous
  January 03, 2008
  Also - if you are syncing with Sharepoint 2007 and enable the option to require items to be checked out before editing on the doc library in which your notebook is stored then you get sync errors from OneNote (unless you manually check out the relevant sections - very messy)

• Anonymous
  February 13, 2008
  The comment has been removed

• Anonymous
  February 20, 2008
  It says above: "OneNote should then display an infobar saying you need to enter a password and give you the option to click it to enter the password." I'm getting the password request bar ("needs a password to sync some of your notebooks"), but when I click on it and click on the item that pops up, nothing happens.

• Anonymous
  February 20, 2008
  Update: It looks like OneNote does update some documents, but it continues to say "Waiting for update." It never completes, even the syncing icon stops spinning.  Could it be attachments that exist in the documents that are causing a timeout somehow?

• Anonymous
  March 16, 2008
  The comment has been removed

• Anonymous
  March 24, 2008
  Hi David, Thanks for following up on my issue.  I checked the C:UsersMyUserAppDataLocalMicrosoftOneNote12.0OneNoteOfflineCache_Files and found a bunch of attachements, all ending in: pdf, rtf, xls, wma.  The file sizes are all less than 141k and smaller. Drop me an email and I can give you more details.  I just installed Vista SP1 and Office 2007 SP1 and still having issues. Thanks, Bradley

• Anonymous
  October 12, 2010
  The comment has been removed

• Anonymous
  February 17, 2011
  I copied a page from a local notebook to another one on sharepoint. It wouldn't synchronize (waiting for update forever) if the objects in the source notebook contain attachments. Even copying single objects containing attachments causes the same problem. Workaround is copying text and attachments seperately.