Thursday, 18 July 2013

SharePoint 2013 New file cannot be saved to a destination library

When SharePoint site is added to the trusted sites in IE and Trusted Sites' custom level includes 'Automatic logon with current user name and password' (see one of my previous posts), we might have messed up something in SharePoint - Office client association. Or maybe it is a Microsoft's bug on certain clients?
The situation is that when you click on a file already in the library to edit/open it- it opens up nicely in the client application without asking for credentials. Depending on the Library Settings, if you want to edit it, you might Check Out the file. We are fine here.
Similarly, when you Upload a file from your local machine into the Document Library, it is done without any problems (however it will not let you save the file under the name that already exist in the library unless you check to add another version of it). In that case users must ensure they upload files with names already changed!
Our real problem is when we click 'New Document', we are being re-directed to the client application based on the Library template, we create/edit the file, want to save it back to the Library and then - BOOM! Cannot do it! Client application offers to save the file locally and when you click 'Save & Send' to save it to a selected SharePoint Library- you will see a fancy error message 'Cannot save to: http://intranet.company.com' or something like that.

In order to fix that, you have to enable a WebClient service in Windows Services as per this blog post. On my machine (happens to be a Windows Server 2012 Datacenter) it is well hidden and it s called a Desktop Experience, see picture below:


It resolved the problem of not saving a file into the library the request of a new file originated from. Well. partially. Now SharePoint wants to authenticate you before it saves your file!
You remember we added our intranet to the trusted sites (you can leave in your intranet zone, whatever- it is after all a browser, not SharePoint configuration. The best way is to have a play and see which configuration- Intranet Zone or Trusted Sites works best). But why MS Office applications installed locally want credentials to upload files back to SharePoint? Microsoft says- "it is our fault" on Vista and 7 and they provide a hotfix.

In short, you have to add a registry value to your local registry (on a machine with Office Applications installed through which you are accessing SharePoint sites). Perform:

#################################################################################
  1. Click Start, type regedit in the Start Search box, and then press ENTER.
  2. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
  3. On the Edit menu, point to New, and then click Multi-String Value.
  4. Type AuthForwardServerList, and then press ENTER.
  5. On the Edit menu, click Modify.
  6. In the Value data box, type the URL of the server that hosts the Web share, and then click OK.

    Note You can also type a list of URLs in the Value data box. For more information, see the "Sample URL list" section in this article.
  7. Exit Registry Editor.
After this registry entry is created, the WebClient service will read the entry value. If the client computer tries to access a URL that matches any of the expressions in the list, the user credential will be sent successfully to authenticate the user, even if no proxy is configured.

Note You have to restart the WebClient service after you modify the registry.

Sample URL list

The following is a sample URL list:
https://*.Contoso.com
http://*.dns.live.com
*.microsoft.com
https://172.169.4.6
This URL list enables the WebClient service to send credentials through the following channels.

Copyright Microsoft Corporation

#################################################################################

You can use your Group Policy to apply the fix and add your intranet website to trusted sites in IE.

Stay tuned for new updates in SharePoint 2013 in production!  

 

No comments:

Post a Comment