This is an approximate build reference for Office cumulative updates and service packs.

Issue:

When opening an InfoPath form from SharePoint 2007 or 2010 with Office 365 (2013) click to run installed the form opens in IE as XML not in the InfoPath client as it should.

When opening Office documents from SharePoint 2007 or 2010 with Office 365 (2013) click to run installed the open click in IE results in error:

"The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document"

The cause is that all the files and settings for the Office IE add-ons are not present.

Workaround:

If you install the "Microsoft SharePoint Foundation Support" feature then the issues go away.

Detailed Workaround steps:

First, download SharePoint Designer 2013 from here:

http://www.microsoft.com/en-us/download/details.aspx?id=35491

 Extract the SharePointdesigner_32bit.EXE to access the source files:

Access the Office Customization Tool (OCT) by running the /admin switch:

Once inside the OCT, navigate to the “Set Feature Installation states” on the left, and set all features to 1) Not available, 2) Hidden, 3) Locked as such:

File > Save the MSP file that gets created by the OCT and place it into the “Updates” folder that is included with your previously extracted source.

 Now you can simply double click Setup.exe, push out a batch file that calls setup from a network location, or use a software distribution tool like SCCM to push out the fix.

Current Status:

The product group is actively working on this issue right now, check back to this blog post for further information.

Issue:

Word and other Office apps appear to hang or freeze, just a blank nonfunctional grey screen is shown when opening files from SharePoint Online (SPO) in the rich client apps.

Cause:

The registry key:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\SignIn

DWORD value signinoptions 

was set to a too restrictive option for your environment.

The value of 0 is the least restrictive and can be used if you are having this problem.

0 - Don't block any sign in UI.

1 - Allow Live ID sign in UI only.

2 - Allow Org ID sign in UI. 

3 - Block all sign in UI. only.

4- Allow both Org and Live

Workaround:

Set the "signinoptions" registry value to 0.

Issue:

Large (50MB+) Publisher 2013 files only open as read only from SharePoint online or SharePoint 2013, user must save locally, then upload the file by hand.

Cause:

Publisher relies on the "Web Client" local service, this service has a default limit of 50MB.

Workaround:

Set the registry key value FileSizeLimitInBytes to a larger value, so for 200MB put a decimal value of 200000000:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\FileSizeLimitInBytes

Issue:

Office 365 Click to Run and App-V 5 SP2 are installed on same computer.

Users try to pick document menu item "Edit in Microsoft XXX" where XXX is an Office application name.

Users get error "Edit Document requires a Microsoft SharePoint Foundation compatible application and web browser"

Repair install of Office does not resolve the problem.

Cause:

The Office IE add-ons and App-V 5 SP2 are do not work together at the moment.

Workaround:

If iexplore.exe is removed from the registry key value ProcessesUsingVirtualComponents  under key:

HKLM\Software\Microsoft\AppV\Client\Virtualization

The issue goes away, the side effects of this action are listed below:

The registry value that toggles this on or off is EnableDynamicVirtualization. In addition, those processes that are specified for this feature are listed in the ProcessesUsingVirtualComponents registry value located in the same key. By default, Explorer.exe and Internet Explorer are listed there.

Dynamic Virtualization has a limited scope of interaction designed for features introduced in App-V Service Pack 2.

This leads to an important statement: Just because the application is hooked, doesn’t always mean it is running virtualized if it appears as a process under the ProcessesUsingVirtualComponents registry value. This will be done at the thread level. When an ActiveX OCX or a DLL that implements a shell extension is loaded from a native process or a process from another virtual application, App-V generates an additional virtual environment on demand linking the package containing the OCX or DLL with the process. Then dynamic virtualization is turned on for that particular thread. Once the thread exits, dynamic virtualization is turned off. If the said thread with dynamic virtualization spawns another thread, that thread too will be virtualized.

****When you turn off the Dynamic Virtualization and remove the Executable paths from the above configuration you will lose the functionality described above.****

Most of the above details came from the below blogs and App-V documentation:

1. http://blogs.technet.com/b/gladiatormsft/archive/2014/02/05/app-v-5-on-run-virtual-rds-run-virtual-virtualizable-extensions-and-dynamic-virtualization.aspx
2. http://blogs.technet.com/b/gladiatormsft/archive/2014/02/11/app-v-5-the-case-of-the-runvirtual-collision.aspx
3. About App-V 5.0 SP2: http://technet.microsoft.com/en-us/library/dn508408.aspx
4. About Client Configuration Settings: http://technet.microsoft.com/en-us/library/jj687745.aspx

Current Status:

The product group is actively investigating this issue, check back to this blog post for updates.

ISSUE:

When opening an Office 2010 file from a SharePoint 2013 site, users are prompted for credentials even though client integration is disabled in SharePoint Central Administration.

CAUSE:

There is an additional HEAD request which returns a 403 Forbidden response. 

For example, if you take a network trace, you may see something like this:

HEAD https://int-www.sharepointportal.test.com/Documents/test.docx HTTP/1.1

Connection: Keep-Alive

Cookie: BIGipServer~seccp~int-www.sharepointportal.test.com-ssl=rd2861o00000dfdsfddsfdd0ffff0ab33040o5000; ASP.NET_SessionId=whcr4m0unufc483493jf4f0hn; s_vi=[CS]v1|2A0851ED051D1A84-4000013540001FFC[CE]; s_fid=241D25D30F5546C1-15779EB616A64E07; s_nr=1411663880736-Repeat; s_vnum=1411704000263%26vn%3D4; s_invisit=true; gpv_pageName=Login%20to%20SharePoint%20Portal; s_cc=true; SC_LINKS=%5B%5BB%5D%5D; s_sq=%5B%5BB%5D%5D

User-Agent: Microsoft Office Word 2013 (15.0.4615) Windows NT 6.1

X-IDCRL_ACCEPTED: t

Host: int-www.sharepointportal.test.com

HTTP/1.1 403 FORBIDDEN

Content-Length: 13

Content-Type: text/plain; charset=utf-8

Server: Microsoft-IIS/7.5

X-SharePointHealthScore: 0

SPRequestGuid: 64febb9c-f42f-90b8-4c8d-a753439264e3

request-id: 64febb9c-f42f-90b8-4c8d- a753439264e3

X-Forms_Based_Auth_Required: https://int-www.sharepointportal.test.com/_login/default.aspx?ReturnUrl=/_layouts/15/error.aspx&Source=%2fDocuments%2ftest.docx

X-Forms_Based_Auth_Return_Url: https://int-www.sharepointlportal.test.com/_layouts/15/error.aspx

X-MSDAVEXT_Error: 917656; Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.

RESOLUTION:

-  For IE 8 and 9 block the verbs OPTIONS, PROPFIND and if necessary HEAD in the Request Filtering section in IIS.

If you are using Windows Server 2008 or Windows Server 2008 R2:

            On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager

    If you are using Windows Vista or Windows 7:

          On the taskbar, click Start, and then click Control Panel Double-click Administrative Tools, and then double-click Internet Information Services (IIS) Manager.

    In the Connections pane,

         Go to the connection, site, application, or directory for which you want to modify your request filtering settings.

         Home pane, double-click Request Filtering.In the Request Filtering pane, click the HTTP verbs tab, and then click Deny Verb... in the Actions pane.  

NOTE:  Office 2010 may issue a HEAD request in addition to the OPTIONS request. It is not recommended to suppress the HEAD request because it may be used by other applications for other purposes.

 --

-  For IE 10+ remove the X-MS-InvokeApp header from each web application.

Overview:

By default Microsoft Word opens hyperlinks to documents as read only when the hyperlink is part of an emails contents.

Many issues can arise when the document is opened read only.  This post shows a way to have Word open the document as read-write when the hyperlink to the document is in an email.

I am going to take this issue a step further by explaining how to edit a SharePoint workflow email task to send an email where the hyperlink to the document will open as read-write in Word without any security warnings.

Solution:

You have a working SharePoint workflow that sends emails that contain hyperlinks to Word documents.  When users click on the link in Outlook the document opens as read only with Word, this behavior is causing you problems.

1. Open the "Define E-mail Message" task with SharePoint designer (see screen shot below)

2. Select the hyperlink to the document and click the hyperlink edit button

3. Add ms-word:ofe|u| to the front of the hyperlink definition address line.   For example:  ms-word:ofe|u|[%Task Process:Web URL%]/[%Task Process:Item URL%]

4. Save and publish your workflow

5. Use the workflow to generate a new email and click on the link, the user will get an Outlook security warning (see below)

6.  You can make this warning go away by adding one of the two following registry keys, 14 is for Office 2010 and 15 is for Office 2013

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\common\Security\Trusted Protocols\All Applications\ms-word:

HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\common\Security\Trusted Protocols\All Applications\ms-word:

This only prevents the security warning for Microsoft Word documents.

Of course you can use the technique for plain hyperlinks,  for example:

Instead of using: http://sp2010ocsi/WRWFLib/2My test document.docx

You could use:   ms-word:ofe|u|http://sp2010ocsi/WRWFLib/2My test document.docx

Issue:

You have Office 2013 Click To Run installed on a client computer, you have SharePoint 2007 lists that contain links to InfoPath forms.  When users click on the link to the InfoPath form, instead of InfoPath being started IE shows the document as XML in an IE window (see screen shot below).

Cause:

The Office IE add-on that ships with the Click to Run version of Office are different and currently do not fully work with SharePoint 2007. 

**But InfoPath forms opened from a document library work fine.

Workaround:

You can change IE's behavior on how it opens XML documents to point to InfoPath instead.

Open Regedit.exe and navigate to key:

HKEY_CLASSES_ROOT\MIME\Database\Content Type\text/xml

Change the value for the CLSID member to be {807583E6-5146-11D5-A672-00B0D022E945}

The above class ID is for InfoPath.

SYMPTION:

When opening Office files from the version history in SharePoint, users receive a message “Couldn't open https://<path>/_vti_history/Shared Documents/filename.

CAUSE:

The "Do not save encrypted pages to disk" was enabled in IE under the Tools, Internet Options, Advanced tab or via Group Policy.

RESOLUTION:

Uncheck the "Do not save encrypted pages to disk" setting.

NOTE:

By default, the "Do not save encrypted pages to disk" option is unchecked (except for Windows Server systems).

The purpose of "Do not save encrypted pages to disk":

In IE9, this option does exactly what it says it does—resources received from HTTPS URLs are not placed in the Temporary Internet Files Cache and temporary files are not created for these resources. This option is universal for HTTPS responses.

In IE10or above, the option behaves differently. Instead of trying to prevent HTTPS resources from being saved to disk, the option will delete cached-from-HTTPS resources from the cache when the browser is closed. This helps ensure that the browser works correctly even when this setting is enabled.

SYMPTON:

Receive error message "An unexpected error has occurred" when trying to view/editing PowerPoint in the browser using Office Web Apps 2010.

*  Word and Excel files are displayed without an error.

CAUSE:

* The installation procedure for Office Web Apps did not complete successfully or an update was applied to the web app.  (The Configuration Wizard had not been executed on all servers in the farm).

Or

*  There are missing lines in web.config file for the Web Application under the <appSettings> section.

If you take a ULS trace, you may see something like this:

Office Web Apps PowerPoint Front End f9zy Assert Unexpected exception on PptWebControl.OnInit: System.TypeInitializationException: The type initializer for 'Microsoft.Office.Server.Powerpoint.Pipe.Interface.PipeManager' threw an exception. ---> System.NotSupportedException: Specified method is not supported.

RESOLUTION:

Run PSConfig on all servers in the farm.

Or

Update any missing lines in the web.config file. 

Example <appSettings> section:

<appSettings>

    <add key="PptServer_Pipe" value="Microsoft.Office.Server.Powerpoint.Pipe.Web.WacPipe, Microsoft.Office.Server.Powerpoint.Pipe.Web, Version=14.0.0.0,

Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

    <add key="PptServer_BroadcastManager" value="Microsoft.Office.Server.Powerpoint.Web.MossHost.MossBroadcastManager,

Microsoft.Office.Server.Powerpoint.Web.MossHost, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

    <add key="FeedCacheTime" value="300" />

    <add key="FeedPageUrl" value="/_layouts/feed.aspx?" />

    <add key="FeedXsl1" value="/Style Library/Xsl Style Sheets/Rss.xsl" />

    <add key="ReportViewerMessages" value="Microsoft.SharePoint.Portal.Analytics.UI.ReportViewerMessages, Microsoft.SharePoint.Portal, Version=14.0.0.0,

Culture=neutral, PublicKeyToken=71e9bce111e9429c" />

    <add key="aspnet:AllowAnonymousImpersonation" value="true" />

    <add key="aspnet:UseStrictParserRegex" value="true" />

    <add key="ChartImageHandler" value="storage=session;timeout=20;" />

</appSettings>

Scenario

You experience a small amount of latency (usually 3-5 seconds) when saving to a local OneDrive for Business directory, but not other local directories.

Cause

In Office 2013, when saving to the local directory tied to your OneDrive for Business 2013 application (typically located at C:\users\%username%\<Example Folder Name>) Office will actually make two simultaneous saves.  One save to the local directory, and another to the server location tied to your OneDrive for Business 2013 application.  An example of a server location would be your Office 365 OneDrive site which you are syncing with OneDrive for Business 2013.

The reasoning behind this behavior is to give you a "server copy" of the file right away so you have server copy functionality immediately.  Server copy functionality includes, but is not limited to, co-authoring, sharing, versioning, etc.

To provide context, here is how you would have to get "server copy" functionality in Office 2010.

-Save the file to local OneDrive for Business directory.
-Close the document in Office to release the lock on the document.
-Wait for OneDrive for Business to sync the document up to OneDrive. Syncs usually happen every 10 minutes.
-Reopen the document in Office from your OneDrive site, now it’s a server copy.
-Server copy functionality available in Office (co-authoring, sharing, versioning, etc.).

Resolution

Since this functionality is very engrained into the design of Office 2013, there are no means to disable the simultaneous save.

As far as workarounds are concerned, the following situations would be viable, however server copy functionality would be sacrificed.

-Do not save directly to the OneDrive for Business folder, but rather save to another local directory.  Then manually move documents to the OneDrive for Business directory.

ISSUE:

Receive a message“A problem occurred when accessing Office Document Cache.  Do you want to repair the problem?” when trying to open any Office file from SharePoint or OneDrive.

Clicking Yes, shows message"The Microsoft Office Upload Center found a problem while accessing the Microsoft Office Document Cache."

CAUSE:

Office 2013 and a Click-2-Run version of OneDrive for Business was installed on same system.

* To verify if you have installed the Click-2-Run version of OneDrive for Business, go to Control Panel, Programs and Features, and "en-us" will be next to the name.

RESOLUTION:

Remove the Click-2-Run version of OneDrive for Business.

* .msi and Click-2-Run versions of Office are not recommended on the same system  -  http://support.microsoft.com/kb/2753630.

You may experience a long delay where an Office 2013 application seems to hang for a number of seconds when you click on the File menu item, for example when trying to access the Save options for a Word or Excel file:

Clicking on File should bring up the Backstage view, where you can manage your files and related data by creating or saving files or setting options:

In cases where it takes a long time for the Backstage to appear, the application may be trying to contact a network location such as OneDrive, and network latency could cause the application to hang for a number of seconds. If you are consistently experiencing this symptom, and you are not using OneDrive, you can resolve the issue be enabling the following option: File > Options > Save > Don't show the Backstage when opening or saving files

With this setting enabled, the File menu should show up immediately. Instead of getting a Backstage view when clicking Save or Open, you will be presented with a classic Open or Save dialog box instead:

In order to implement this setting on all computers in your organization, you can use a registry key to enable this option. Configure the registry key below with a value of 1. Create the SkipOpenAndSaveAsPlace key as a DWORD value if it does not already exist.

 
   HKEY_CURRENT_USER\Software\ Microsoft\Office\15.0\Common\General\SkipOpenAndSaveAsPlace

ISSUE:

Document preview for SharePoint 2013 search results randomly give an error "To start seeing previews, please log on by opening the document".

CAUSE:

The behavior occurs because the page that we use to show the preview (_layouts/15/wopiframe.aspx) is set up for anonymous access.  Since the user did not browse the site collections from where the documents to be displayed reside, there is no access token which can be presented in order to retrieve the file. If the browser does not supply the authentication token with the request for the page, the user will be authenticated anonymously, which will not have access to the document that is supposed to be shown in the preview.  Now in the case where the user is authenticated, the browser sometimes drops the authentication token so that even though the user is authenticated on the outer page, the wopiframe request does not contain the auth token and we end up with the “to start seeing previews…” message.

RESOLUTION:

For Windows NTLM authentication only, a fix to target this scenario is included May 2014 CU or later.

For other authentication providers including Kerberos, use one of the following workarounds:

1.  Use the Wopiframe2.aspx logic in place of Wopiframe.aspx:

     1.        Open the file location C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS
     2.        Locate wopiframe.aspx.  Rename it to wopiframe.aspx.bak.  – This will be our backup copy.
     3.        Locate Wopiframe2.aspx.  Make a copy of it and paste it in the same directory.  Rename it to Wopiframe.aspx.
     4.        Open the file location: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\TEMPLATE\LAYOUTS
     5.        Repeat steps 2 and 3 within the 15\Template\Layouts folder.
     6.        Reset IIS on the box.

               - Possible issues with the above workaround:

                     -Anonymous users may get prompted when looking at document previews.

                     -Wopiframe.aspx could be overwritten and set back to default by a CU.

                     -Previews of Excel files may return message "We can't show a preview of this item". 

2.  Switch to NTLM

3.  Disable the preview functionality

4.  Refresh the browser

SYMPTOM:

Consider a scenario where a user browses to a SharePoint 2013 site using Internet Explorer (IE), searches for an Office document and hits the 'Send' option (in order to send the URL via Email).

One of the following occurs:

• IE hangs and nothing ever occurs.
• IE opens a blank tab, hangs and does nothing further.

During this same scenario, the following is also true:

• Other non-IE browsers seem to work fine with the same document URL.
• The URL is at least 512 characters in length.

CAUSE:

This is a known limitation involving current versions of Internet Explorer, the mailto: protocol, and URLs that exceed 512 characters.

SOLUTION:

Some suggestions to avoid this include (choose one of the following).

• Enable Protected Mode for the IE zone that the site URLs are set to.  Note that this workaround may cause other limitations.

• Ensure the size of the URL does not exceed 512 characters in length.

• Use a registry setting to configure the mailto protocol for the IE zone that Sharepoint sites are set to.  If, for example, the site URL is in the Trusted Sites zone, set the mailto protocol to 2, and so on.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults

or 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults     

Name: mailto
Type: REG_DWORD
Data: 0

The value for the zones are:

   Value    Setting
   ------------------------------
   0        Local Machine Zone
   1        Local Intranet Zone
   2        Trusted sites Zone
   3        Internet Zone
   4        Restricted Sites Zone

Symptom:

Consider the following scenarios:

Scenario 1.

A user browses to a SharePoint or other web site using a non-IE browser, enters their forms-based authentication (FBA) credentials and checks the box to remember their account info, which creates a persistent cookie.   They proceed to click on a link to open an Office document, which produces a prompt again for their credentials.

If the user switches to an IE browser, they do not receive the additional prompt.

Scenario 2.

A user browses to a SharePoint or other web site using IE to browse.   This user enters their credentials in the form and proceeds to click on a link to open an Office document.   They receive another FBA challenge for credentials.

If they then place the URL of the site into either the Local Intranet zone or the Trusted Site zone, they do not receive the additional challenge for credentials.

Cause:

For Scenario 1, the reason for the challenge in the non-IE browser is that when Office requests the persistent, it is retrieved from IE's cookie jar.   Other browsers do not write their cookies the same way or to the same location; therefore Office cannot retrieve those cookies.

For Scenario 2, the reason for the challenge is due to IE's Protected Mode.   If the URL is resolved to an IE zone that has Protected Mode set, IE will not share the cookie with other applications, like Office.  

Solutions:

For Scenario 1, the workaround is either to use IE to take advantage that Office can retrieve the persistent cookie, or (for non-IE browsers) the user will need to log in again when opening Office documents. 

For Scenario 2, the workaround is to ether remove the checkbox for Protected Mode or move the URL of the site to a zone that does not have it set.

Issue:

You have Lync running and open a SharePoint web page with IE (internet explorer) and the user presence information does not show.

Workaround:

Find the IE security zone the SharePoint site is in, and turn off "protected mode" for the IE security zone.

Or run IE as administrator

Issue Details:

The Office IE add-on loops though all the processes on the computer looking for Lync, so it can use a handle to the process to communicate with it.  When IE is enforcing protected mode Windows security restricts the process list that is sent back to the Office IE add-on and the Lync handle is inaccessible.

Overview:

Microsoft Office 2013 applications give error when opening a file from a SSL website.  Error:  "Certificate error:  The Application Experienced an Internal Error Loading the SSL Libraries"

Issue:

There are actually two different aspects to this issue, out of the box Office 2013 only supports the default settings for whatever OS Office is running on.  So for Windows 7 Office 2013 requires TLS 1.0 or SSL3 to be supported on the server.  Windows 8.1 and Office 2013 SSL3, TLS 1.0, TLS 1.1 and TLS 1.2 are supported but the RC4 cipher suite is not supported.

So some users will see this error because they are on Windows 8.1 and their servers hosting the SSL site do not support the newer protocols and some users will get this error because the servers only support newer protocols and the client is Windows 7 which only supports SSL3 and TLS 1.0 by default.

Windows 8 and Office 2013 have stricter SSL security requirements, they no longer accept the RC4 cipher suite.

http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx

Workaround:

For issue where Windows 8.1 does not support RC4cipher suite:

The server hosting the SSL site needs to support newer ciphers

https://support.microsoft.com/en-us/kb/245030

 You want to enable the TLS 1.2 support. Snippet from the blog

<Snippet> 

SCHANNEL Key 

Start Registry Editor (Regedt32.exe), and locate the following key in the registry. 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL 

SCHANNEL\Protocols SubKey 

To enable the use of the protocols that will not be negotiated by default (such as TLS 1.1 or TLS 1.2), change the DWORD value data of the DisabledByDefault value to 0x0 in each of the following registry keys under the Protocols key:

•SCHANNEL\Protocols\TLS 1.1\Client 

•SCHANNEL\Protocols\TLS 1.1\Server 

•SCHANNEL\Protocols\TLS 1.2\Client 

•SCHANNEL\Protocols\TLS 1.2\Server 

<Snippet>

For users that have Windows 7 and do not want to support the older SSL 3 and TLS 1.0 protocols on their servers:

There is no workaround to this issue, a code change was needed for Office to override the default settings of the Windows 7 operating system.  A possible workaround would be to use Windows 8.1 or later operating system.

Or, there will be a hotfix released for Office 2013 that will allow it to support TLS 1.1 and TLS 1.2 on Windows 7, the estimated delivery date for that hotfix is August 2015.  This blog will be updated after the fix has shipped. 

Some may have noticed that recently Google has removed the NPAPI Plug-in support from Chrome.  This change is discussed here http://blog.chromium.org/2014/05/update-on-npapi-deprecation.html. What this means is that when opening a file from SharePoint on premise or SharePoint online the browser will default to either downloading a local copy or attempting to open the file in browser (regardless of your library settings). 

Many other SharePoint integration features will not work when the NPAPI support is disabled, they include:

• Documents will not open in rich client app when doc lib link is clicked
• Lync Presence information will not show
• Export to Excel from doc lib and SharePoint list will not work
• "Edit Library" button will not work
• "New Quick Step" will not work
• "Workflow Settings" \ "Create a workflow in SharePoint designer" will not work
• "Open with Access" and "Open with Project
• "Edit Lists"

As this can have an impact on how Office integrates with SharePoint and Sharepoint Online we have found a temporary work around that allows you to enable the NPAPI plug-ins while things are being figured out.

1. Open Chrome

2. Put "chrome://flags/#enable-npapi" into the address bar

3. Find the "Enable NPAPI" plug-in and enable it

4. Select "relaunch now" at the bottom of the page

5. Test, you should now have your old functionality back.

The above workaround will not work after September 2015, per Googles blog post:

"In September 2015 we will remove the override and NPAPI support will be permanently removed from Chrome. Installed extensions that require NPAPI plugins will no longer be able to load those plugins."

http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html

Another workaround would be to open the file in the browser with Office Web Apps, then click the button from the web editor to open in rich client application, like "Edit in Word" button

We unfortunately don’t have timelines to share on this yet. (the presence replacement feature)

This will just be a general overview of how the office backstage works.

There have recently been a number of requests asking how the office backstage works with office 2013 or office 365. First I want to explain the office backstage is different from the "connect to office" feature. The backstage is the portion of office under file that resembles the below image, where connect to office resembles explorer view/mapped drive.

There are two types of locations in the backstage. There are the account/service locations(also called Native Services) and the locations you've manually added(sometimes referred to as Mounted Services).

Manually added locations are very straight forward as they just require you to put in the orgid/Microsoft account and password tied to them and they get added. These services get added to the registry and are saved. It's the native service locations that can cause confusion.

Native Service locations are created by the Service Manager Cache through Exchange's Autodiscover. Office uses that AutoDiscover to find the On-Premises SharePoint settings (SPMySiteHostURL) as long as you have Autodiscover setup (again usually via exchange) then the service should find any sharepoint/onedrive accounts tied to the user account currently accessing office.

In environments with both On-premise and SharePoint Online. If the account is federated then both SharePoint Online and On-Premise should show in the backstage by default. If not federated then only On-Premise will show by default, but SharePoint Online can be added manually as a Mounted service.

I hope this clears up any confusion with regards to the Office Backstage.