The Content Types were custom and so were the document templates behind them. When I was saving for the first time, it would default to the local Document library and not the document library in SharePoint. Bugger!
(...)
To make it more weird, was the fact that once we were able to get the location right once, each library would then start working correctly, meaning new documents would default to the right location in SharePoint! Very weird and after some tests, another conclusion was that emptying the local Office cache would lead to this problem re-appearing. And...every new user would face it for each "new" library, or when the Office cache was emptied.
Another weird suggestion we got, from googling for this problem, was going to the "Save & Send" section and only after "Save". It worked! At least partially in certain cases. It would still be something unacceptable for users..."You have to click Save & Send and only after Save the document" is not something you want to tell your customer :-)
The solution ended up being quite easy, but getting there...not so much! It seems Word makes a connection to the root site collection of the Web Application (/) and if it doesn't exist...it just misbehaves! In our scenario, we had a new Web App and only had a site collection in a custom managed path and no site collection created in "/".
Creating a dummy site in "/" solves the issue. Seems like someone in the Office team made it a requirement...unfortunate. There was a TechNet post that helped me getting to this conclusion, check it here. There was also a big discussion in StackExchange on this, although the reasons and solutions are different, it may help people facing a similar situation, check it here.
I've also heard from talking to other people that certain APIs may also malfunction, if you don't have a root site collection for the Web App, so beware, in case of doubt always create it!
No comments:
Post a Comment