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.