Overview:

You have Excel files in .XML format (XML Spreadsheet 2003) and you get error

“This action couldn’t be performed because Office doesn’t recognize the command it was given.”

When you try to open the file from a SharePoint document library.

There will likely not be a product change to address this issue, it is recommended that the issue is worked around.

Workaround:

Deploy a registry key based fix, depending on the version and bitness of Office Installed the registry changes will vary.

**Warning, editing the registry can have harmful side effects if not done property, use this workaround at your own risk.

Registry file content will be in-between the —- markers

—-Office 2013 MSI 32 bit —

—End Office 2013 MSI 32 bit —

—-End Office 2016 MSI 32 bit —

—-Office 2016 MSI 64 bit —

—-End Office 2016 MSI 64 bit —

Overview:

Currently there is no way to remove an App for Office add-in reference from Office 2016 (see below).

These add-in references are stored in the registry under a combination value that includes the add-in’s ID GUID.  This ID can be seen in both the add-in manifest and in the SharePoint Online application catalog (see below).

Workaround:

***Computer systems can be broken if registry edits are not performed properly, use this workaround at your own risk.  There are no guarantees or warrantees of any kind **

There are a list of Item(1,2,3,etc) values  under a key like this one:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Excel\Web Extension User MRU\ADAL_z139970C84C528DEE9B3F50D634024065AABC863258DFEC9DB277DB4808974A9\File MRU

The entry looks like this value name = “Item1”

value = “[F00000000][T01D2B8497B0ABB70][O00000000]*51c8c010-87f6-4b2a-b105-e6128bc8b66z SPCatalog https://hempele3.sharepoint.com/sites/apps   1.0.0.0”

Since the add-in reference you want to remove could be anywhere in this list, it could be complicated to find and removed.

I have created a sample program that will remove these add-in references:

usage: RemoveAddinRef <app excel word powerpoint> <GUID of addin>
example: RemoveAddinRef excel 51c8c010-87f6-4b2a-b105-e6128bc8b66f

The GUID can be obtained from the “Apps for Office” catalog that can be found in the SharePoint admin tools for Office 365.

The .exe and Visual Studio source code is attached to this blog post.  Project Download zip

Overview:

Some users opt to not have the Office Client installed at all and just to use the Office web applications.  In this scenario there is no OneDrive sync client installed and no shortcuts appear in the File Explorer navigation.   This blog post will provide a tool and instructions for a custom OneDrive like link to be made in the File Explorer Side Bar area (see picture below):

Workaround:

This blog has a Visual Studio sample project and an sample .exe that will create a Side Bar item from passed in parameters.

First you will need to know the location of the OneDrive or SharePoint URL, a good way to do this is to open your OneDrive location and pick “Return to classic OneDrive”, this will get a more direct URL, something like:

https://somecompany-my.sharepoint.com/personal/warren_somecompany_com/Documents/Forms/All.aspx

Turn the above into a WebDAV URL like below:

\\somecompany-my.sharepoint.com@SSL\DavWWWRoot\personal\warren_somecompany_com\Documents

Once you have the title you want to use (can be anything) and the WebDAV URL you can call the sample program:

CreateSidebarItem.exe “My Title” “\\somecompany-my.sharepoint.com@SSL\DavWWWRoot\personal\warren_somecompany_com\Documents”

Use this sample code at your own risk, there are no warranties or guarantees of any kind.

The solution and exe can be found here solution

Overview:

From the SharePoint 2013/2016 document library UI, Office documents open in the web application instead of the rich client application (when it should not) or there are other issues opening documents from the SharePoint UI to the Office rich client application.  An indicator of this issue would be when an out of the box un-customized document library works fine, but a customized document library does not work.

Issue:

The SharePoint JavaScript code requires IE document mode 10 for the pages to work correctly in IE 11.  You can see what doc mode the browser is in by opening the F12 Developer tools in IE and looking at the value in the upper right hand corner, see picture below:

Workaround:

If IE is being put into document mode 11 or Edge you will need to change your custom code (master pages, etc) to not modify the IE document mode or to specify document mode 10.

For example:

<meta http-equiv=”X-UA-Compatible” content=”IE=10″ />

Scenario:

We have recently recognized an influx of issues regarding Office 2013/Office 2016 and saving/checking out Office files to SharePoint Online. This issue can be ambiguous and have many causes but we want to raise awareness that WAN accelerators, such as RiverBed, have been involved in multiple of our recent cases.

WAN accelerators are intended to optimize traffic but if misconfiguration or errors are occurring, this can cause delays and/or the inability to save and check out Office files to SharePoint. Due to the design of acceleration and modification of TCP packets, if not done properly it cause expected errors for Office.

Errors:

Error messages we have seen connect directly to this issue have been:

• The  file “http://domain….” is checked out for editing by user ‘ ‘
• The file “filename.xlsx” has been locked for editing by ‘ ‘
• ” Upload failed” – You may notice you are locked out of the file for extended durations (minutes to hours while you know no other user is in the file)

What to do:

Testing the removal/bypassing of WAN accelerators (such as modifying the hosts file) is critical to early troubleshooting. If a change in behavior is found after removing these acceleration services, engage your WAN acceleration team to investigate further.

If the issue is still present after removal of WAN acceleration services, continue with normal troubleshooting which typically involves simplification of environment (both local machine and network), review of networking logs (Fiddler/Netmon), and review of ULS logs on the SharePoint side (ULS would be available to SharePoint On-Premise users but not available to the public for SharePoint Online).

As noted, there can be many causes for this issue but wanted to let you know of a topic hitting our radar a bit more frequently and then ideas for further troubleshooting in chance WAN acceleration is not the cause.

Dustin

Issue:

In SharePoint 2016 for document libraries that are set to "Open in the client application" Visio documents will do nothing when clicked on or show the Windows Store popup window, if the Visio rich client is not installed.

Details:

The Visio Viewer is installed with Microsoft Office, ideally the Visio Viewer would show the file or the web Visio Viewer would show the file.  If the web viewer were to be used, it would require a change to the SharePoint code.  SharePoint JavaScript code has no way of telling if Visio is installed or not due to web browser security, so their only option would be to open all Visio files in the web viewer, not honoring the document library setting for users that do have the Visio rich client installed who want Visio to start when the files are clicked on in the SharePoint UI.

This use to work, what happened? 

Office, SharePoint and Internet Explorer have been evolving, they are moving away from using the Office IE add-ins to using a protocol handler technology.  Modern browsers do not support old style add-ins, but protocol handlers will work in all modern browsers and IE.  The SharePoint code now uses protocol handlers instead of browser add-ins to open files, see links below for more information:

https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers

https://msdn.microsoft.com/en-us/library/office/Dn906146.aspx?f=255&MSPPError=-2147217396

Workaround:

**Warning, this is sample code, use at your own risk, there are no guarantees or warranties of any kind**

This blog post contains a sample program that will create a protocol handler for the Visio Viewer that ships with Microsoft Office.

The Visual Studio solution can be found here: VisioHandlerSolution.

You can find the VisioHandler.exe program under the VisioHandler\VisioHandler\bin\Debug folder.

VisioHandler.exe needs to be deployed to this exact folder: C:\Program Files\VisioViewerHandler

One time setup is needed to configure the registry to hookup the protocol handler, this command needs to be ran with administrator privileges:

VisioHandler.exe install

The above command will check to see if the protocol handler already exists, if it does exist the command will do nothing.  This insures that if the Visio rich client is installed, none of its settings will be overwritten.

After the file has been deployed and the "install" command ran, all should be working.  Go to a SharePoint 2016 document library and try to open a Visio document, IE will download the file and open it using the Visio viewer.

The code could be modified to use the Visio web viewer, simply change the call to ShellExecute to call VisioWebAccess.aspx instead, see sample below:

http://sp2016ocsi/_layouts/15/VisioWebAccess/VisioWebAccess.aspx?id=/Shared%20Documents/warrenr/Drawing1.vsdx

You may receive the following error when trying to open a Microsoft Office file in the browser stored in SharePoint on-premise using Office Web Apps or Office Online Server, or in SharePoint Online using Office Online:

Sorry, you can't edit this document with other people.

This error can occur if another user has the file open in a Microsoft Office 2016 client application, such as Word, when they have one of the following registry keys set to 1:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Internet\FSSHTTPOffWord

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Internet\FSSHTTPOffExcel

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Internet\FSSHTTPOffPowerPoint

For a user with Microsoft Office 2013, the following registry key may be set to 1:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Common\Internet\FSSHTTPOff

When the value is set to 1, it disables the Cell Storage Service. When this is disabled, it in turn disables the co-authoring feature of Office. So when a user opens the file, instead of allowing multiple users to edit the file, it puts the lock on the file and prevents others from editing the file in the browser or client.

To resolve the issue, make sure the registry key value is set to 0 on user machines.

You may receive the following error when opening a Word document from SharePoint:

We couldn't register this document. You won't be able to create links from other documents to this one.

Or you may receive the following error when opening an Excel workbook from SharePoint:

The file could not be accessed.

These two errors can happen if the file has a long file path. Per the following document, SharePoint on-premise has a 260 character limitation in the full file path, which includes the path and the file name:

https://technet.microsoft.com/en-sg/library/ff919564(v=office.14).aspx

The limitation in SharePoint Online for the file path is 400 characters:

https://support.office.com/en-us/article/SharePoint-Online-limits-8f34ff47-b749-408b-abc0-b605e1f6d498

To fix the error, reduce length of the file name so that the full file path is below the character limit.

Issue:

You have a custom multifactor authentication login pages that leverage DUI API, and all works fine from web browsers but the Office client (Word, Excel, etc) fails to render all of the HTML property, you may see a flicker of the login page but in the end Office shows this error:

"Your organization's policies are preventing us from completing this action for you.  For more info, please contact your help desk."

Cause:

When the DUO iframe is loaded from the ‘duo.form.login.template.html’ file, the code is <iframe id="duo_iframe" width="100%" height="350px" frameborder="0">
Note that the SRC attribute of the Iframe element is missing, causing the iFrame to load the URL about:blank (The Iframe SRC attribute is set at a later point in the Duo-Web-v2.js file).  For security reasons Office does not allow navigation to any non-https end point within the webview which is shown to capture user credentials. The lack of a SRC attribute causes the embedded browser to load "about:blank" in the IFRAME which is not based on HTTPS and Office cannot allow such navigation to take place.

Workaround:

Specifying a SRC attribute for the Iframe element resolves the issue : <iframe id="duo_iframe" src="images/TempImage.gif” width="100%" height="350px" frameborder="0"> (Since we have a SRC, about:blank no longer loads, and hence the issue does not occur)

Issue:

You have a SharePoint Online document library that requires checkout and you have it synced locally via OneDrive for business.  Files opened from either online or from the local synced folder open documents read only with no way to check in or check out files from the Office client.

Cause: 

This is a current design limitation with OneDrive,

"Libraries with Checkout, Required columns or metadata, or when Draft Item Security is set to either Only users who can edit or Only users who can approve items in Version Settings of the library."

https://support.microsoft.com/en-us/help/3125202/restrictions-and-limitations-when-you-sync-files-and-folders

Workarounds:

1. Do not sync SharePoint document libraries that require checkout
2. Uncheck the OneDrive setting: Office[tab] \ "Use Office 2016 to sync Office files that I open";  If you uncheck this global setting, co-authoring will not work for any file opened from a local synced folder.  But co-authoring will work for any files opened from online.  GPO for controlling this setting is EnableAllOcsiClients defined at:   https://support.office.com/en-us/article/Use-Group-Policy-to-control-OneDrive-sync-client-settings-0ecb2cf5-8882-42b3-a6e9-be6bda30899c#enableallocsiclients

Status:

Supporting libraries that require checkout is on the product groups backlog and maybe fully supported at some point in the future.

Issue:

You have Office 365 client application (Word, Excel, PowerPoint) trying to open a document from SharePoint or OneDrive via the Office recently used document list and receive error:

"Sorry, something went wrong"

Cause:

Office 365 no longer support the registry key:

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Common\Roaming] "RoamingSettingsDisabled"

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Roaming] "RoamingSettingsDisabled"

Workaround:

The workaround is to delete the above registry keys or set it to 0.

If you need to reduce the traffic that Office is sending to the internet you can use these registry keys:

• HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Internet
  Name: UseOnlineContent
  Type: DWORD
  Value: 0 -Do not allow Office to connect to the Internet. Office applications do not connect to the Internet to access online services or to download the latest online content from Office.com. Connected features of Office are disabled.
• HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Common\Internet
  Name: UseOnlineContent
  Type: DWORD
  Value: 0 - Do not allow Office to connect to the Internet. Office applications do not connect to the Internet to access online services or to download the latest online content from Office.com. Connected features of Office are disabled.

Issue:
You have Office 365 / 2016 and open a document from SharePoint that has SharePoint metadata properties of type [lookup - multi select] and they do not show and can not be set on the Office backstage area (File / Info screen)

Cause:
This is a current design limitation with Office, there are no current plans to change this behavior.

Workarounds:
If using Word, you can use the SharePoint properties screen (View tab \ Properties see screen shot below) or to use the properties page from the SharePoint web UI.