SharePoint 2010

SharePoint 2010 & OneNote 2010 – synchronization issues

Bix

OneNote is a tool from Microsoft Office to quickly write things down, such as meeting or course notes.  When put on a SharePoint collaboration space, it allows easy multi editing; we tend to use it quite a lot at work as it’s handy and quite powerful.

In order to avoid having peoplemixing up content, I usually advise people not to write in the same paragraph together, or better, not in the same text box.  If you are on the same page and want to edit things together with someone, use a different text box – sometimes it requires you to click way off or below the current text in order to create a new box.

That being said, and even if you’re the only one editing a OneNote file, at some point you might have synchronization errors.

You probably know that you cannot create a OneNote file on a document library requiring checkout:

But thing is, nothing prevents you from putting it in a library with versioning enabled, and that is a very bad idea, as we will see here.

At some point, when trying to add a page or to modify anything to a page in a section, you will have the dreaded synchronization error message:
An error occurred while attempting to sync this section or notebook. (Error code:0xE4020005)

And then it’s getting like really annoying. Whatever you do to that OneNote file, be it with the web or the thick client, the targeted section(s) are impossible to modify in any way. Well you can modify them of course but nothing get saved.

An interesting thing to check is to see if the section is checked out to someone (in case the versioning is enabled on the library which, I remind you, is a bad idea for OneNote).

In order to do that:

  • Surf to the document library containing the OneNote file.
  • Modify the current view to include a Checked Out To column
  • Surf to the OneNote folder contents.  The default behavior when clicking on a OneNote document (represented as a folder in SharePoint) is to open the OneNote web tool. In order to work around this, do the following:
    • Well do that and open the OneNote in the browser and copy the part of the URL after “id=”, i.e. http://yoursite.ext/path/sitecoll/_layouts/OneNote.aspx?id=/pathandfilename&Source=parentpath&DefaultItemOpen=1
    • Go to the parent library containing the OneNote (URL with AllItems.aspx at the end) and manually add ?Rootfolder= followed by pasting the part of the URL you just copied at the previous step.   Final URL should be something like http://yoursite.ext/path/sitecoll/library/Forms/AllItems.aspx?Rootfolder=/pathandfilename&Source=parentpath&DefaultItemOpen=1
  • Browsing the OneNote content in that folder view might make you notice some pages and sections which are actually checked out:
  • You can then easily either discard checkout of the corrupted section(s).
  • If the corrupted sections unable to be sync’d, are not checked out, you can also try a checkout yourself, and then immediately re-checkin under a Major version.

When everything is clean, think about disabling the versioning on the document library containing the OneNote, and such problem would normally not happen anymore.

Last resort if the section still doesn’t want to sync, is create a new one and move all the pages from the old to the new… crappy work-around but it ended up working for a few desperate OneNote files here…

 

SharePoint: move a document library with Export-SPWeb

Bix

For some laziness reasons, and mainly because I had so many issues (or fear of issues, you know how that is) with the PowerShell commands to manage site collections, I got used to stsadm command line, which is something from SharePoint 2007 a.k.a. MOSS.

It still works with SharePoint 2010, and also in SharePoint 2013 with some workaround. But clearly, the SharePoint Management Shell is the way to go now, and I have been advocating Powershell for long enough, to go and try to make the effort to use it here.

I got a request from a user, to move a document library with versioning enabled, from a site collection root to a subsite, while keeping the whole version history of all documents within.

Opening the document libraries (source & target) with Explorer and copy-pasting works and even keeps version history, but only within the same site collection. Moving documents this way to a subsite, removes the whole shebang.   So yeah, it seems like we’ll have to use the dreaded Export-SPWeb command.

“Dreaded”, because the official documentation about it is poor, lowly documented and examples are just not complete, and you WILL get errors hardly understandable.
Blogger Blksthl provides a more documented version, but it still lacks to explain about this thing we use at work: managed paths. Even if in the URL nothing makes the difference, Managed Paths are not the same as site collections; they are a “sub-division of a web application”, and clearly they behave differently.

Logging on the App server with Farm Account (not sure such an elevation is needed, but I want to avoid permissions issues).  The aim is to migrate the document library MyDocLib from the site collection http://webapp.mysite.be/managedpath1/MySiteColl, to the sub-site http://webapp.mysite.be/managedpath1/MySiteColl/MySubSite/, keeping all versions of all documents – and user security, of course.

Now let’s try various versions of the syntax, since it’s never indicated where to put the managed path:

Oh yeah, even the value for parameter -Includeversions is not even well documented in the official doc. They mention 4 possible values but not exactly what to enter for each of them. I had to get more info on this on another TechNet article…

The error message changes a bit, and it’s funny that it mentions the usage of stsadm.exe in the PowerShell command itself…

After some research, it might appear that the -itemurl parameter might require a full path, let’s try:

For some reason I didn’t include MydocLib in that command, and I don’t know if the result would be the same if I had. Anyway, you’ll find a lot of literature about this <nativehr>0x80070057</nativehr> error, but nothing I could get much from.

Ok enough playing, here is the way to success.

The problem is to know exactly what to put in –identity and -itemurl. For the first one, it looks like the full site collection path where the doc lib is located, is correct. For the second one, it’s another story, and thanks to TechNet user HAZET in yet another post on the problem, here is the SharePoint shell command to know about your site collection elements’ itemURLs:

The result will be something like:

Okayyyyy so the Managed Path has to be indicated in the -itemURL. So here’s the final -and working- command:

-identity: full site collection path
-itemurl: document library path with managed path and a starting slash.

Now you have your .cmp file ready to be imported in the target sub-site. The Import-SpWeb command doesn’t need an -itemurl parameter so you might think your problems are over .. but not quite yet:

The prompt is the correct directory, the file with this precise name exists.  OK this is PowerShell so maybe  .\MyDocLib.cmp ?  Nah, same error message.

In fact… Export-SPWeb can work in the current directoty, but Import-SPWeb cannot (if anyone finds any logic in this, let me know). You need to specify the full path:

It works!