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.


  • "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 (15)
  1. One bug report we’ve been trying to track down has to do with sections from Notebooks on Sharepoint servers

  2. Here at Microsoft we use a lot of OneNote shared notebooks a lot of those notebooks are stored on SharePoint. 

  3. Here at Microsoft we use a lot of OneNote shared notebooks a lot of those notebooks are stored on SharePoint

  4. mharr says:


    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.

  5. DavidRas says:

    Good point re: 945713. Although to be precise it lists that as one of the possible work arounds among others. And this vulnerability doesn’t seem to affect the vast majority of users for the below reasons stated in the report. I’m not an expert on this particular vulnerability issues so I won’t give advice on it. I presume there will be a Windows update addressing it soon, so if you’re in one of the risk categories (domain joined, with primary DNS suffix configured, with a below second level domain, without a trusted WPAD server on your network that someone else has put a ‘bad’ server on), then perhaps leave Auto Detect Settings off until the update comes out…


    • Customers who do not have a primary DNS suffix configured on their system are not affected by this vulnerability. In most cases, home users that are not members of a domain have no primary DNS suffix configured. Connection-specific DNS suffixes may be provided by some Internet Service Providers (ISPs), and these configurations are not affected by this vulnerability.

    • Customers whose DNS domain name is registered as a second-level domain (SLD) below a top-level domain (TLD) are not affected by this vulnerability. Customers whose DNS suffixes reflect this registration would not be affected by this vulnerability. An example of a customer who is not affected is or, where “contoso” and “fabrikam” are customer registered SLDs under their respective “.com” and “.gov” TLDs.

    • Customers who have specified a proxy server via DHCP server settings or DNS are not affected by this vulnerability.

    • Customers who have a trusted WPAD server in their organization are not affected by this vulnerability. (See the Workaround section for specific steps in creating a WPAD.DAT file on a WPAD server.)

  6. Sam says:

    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)

  7. Bradley says:

    Hi, I’m having an issue where I have OneNote 2007 SP1 and SharePoint 3.0 (latest version) installed on a server and all of a sudden a few weeks ago OneNote wont sync with any of us.  We just get "waiting on update" and the sync swirly icon stops and there is no error message.  We are all now getting: This notebook has not been connected in xx days. If the location no longer exists or has been moved, you can sync this notebook to another location. If you expect this location to become available again, you do not need to do anything.

    Any ideas? It started a few weeks ago for everyone.



  8. aatreya says:

    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.

  9. Bradley says:

    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?

  10. DavidRas says:

    Sorry for the delay in catching up on some of this.


    Yes, OneNote notebooks don’t play well when you set Check-In/Check-Out required on a doc lib. It’s sort of a mismatch in model. OneNote philosophy is to remove all barriers and decisions like having to save etc. so you can just take notes. But sometimes that runs into a fundamental mismatch like this when required CheckIn/CheckOut is all about forcing you through hurdles to save. Most scenarios we’ve seen for required check in / check out are about tightly controlled document types (think insurance forms that go through a certain process, or contracts, or where there are approval processes), and the users just have separate doc libs for those type of docs, and other more free form team sharing information.

    I’m curious about your scenario. Can you explain why you set Check-In/Check-Out required on the document library, and why you wanted your OneNote notebook in that same document library and not another.

    By the way, this is something we’re actively looking at for improved models here.


    If there’s anyway you can get me contact details (try the submit email form on the post) then I’d like to follow up with you and we can work out what your issue is on this Sharepoint site and why your notebook is not syncing. Based on your update, I’m guessing there’s just one or more embedded files being blocked somehow and even if OneNote sync 90% of the files it won’t tell you that sync has completed if there’s something not going through. We have seen issues with some embedded files that SharePoint won’t accept (e.g. if it had a virus in it, or policy on your SharePoint server was blocking it for some other reason). Then OneNote fails to successfully save that file up to the SharePoint site and will give you this kind of situation. If you can get me contact details via the email form, we’ll follow up. If there’s anything you can tell us about the files (file type, anything else unique) that would help too.


    If you could get me contact details as well (try the submit email form on the post) then I’d also like to follow up on this.

    Thanks all for the feedback.

  11. bradhs says:

    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.



  12. Ravinder Jamgotre says:

    I have a SharePoint farm configured over HTTPS using port 434 not 443 as we at the time had another server service using https on 443. I am trying to share OneNote workbooks externally and cannot do this as OneNote comes back with error stating the url or path is invalid… when I try sharing the workbook using http://localservername/documentlibrary/ it works fine but obviously this will not work externally due to the localserver name not public facing… how can I overcome this issue?

  13. Stefan says:

    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.

Comments are closed.

Skip to main content