Issue:

Sometimes when opening Word documents from SharePoint you see message:  my.docx is locked for editing by 'another user'.

Or with PowerPoint or Excel you see similar message, but instead of the users name, like "John Smith", you see their network ID, like "I:0#w|mydom\smithj"

You would like to accurately see the users name in the message so they can more easily be contacted to release the lock on the document.

This issue will only happen when IE tries to open a real hyperlink to the document, most SharePoint document opens happen via JavaScript code or a protocol handler.  But SharePoint search preview "Edit" link will open document like a direct URL, which can cause this issue.  For example, if you paste a document URL into IE address bar and hit enter you may encounter this issue:  Like:

http://sp2013ocsi/WRBI/ForceCheckoutLib/Test2-Ben.docx

Workarounds:

If you have Office Web Apps configured, you can first open in the web app, then pick to edit in the rich client from there.  This will by pass the issue.

Or you can modify these registry keys, they will change how the Office application is started and bypass this issue.  The screen below will be showed instead:

**You assume all risks for modifying the registry, invalid changes to the registry could cause your computer to stop working

These registry changes can work around the issue:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Word.Document.12\shell\OpenAsReadOnly\command
Remove the /h from the default value, you would end up with something like this:
"C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE" /n "%1"

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Excel.Sheet.12\shell\OpenAsReadOnly\command
Remove the /h from the default value, you would end up with something like this:
"C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE" /dde

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PowerPoint.Slide.12\shell\OpenAsReadOnly\command
Remove the /h from the default value, you would end up with something like this:
C:\PROGRA~2\MICROS~4\Office14\POWERPNT.EXE "%1"

Summary:

You have customized the ADFS sign-in page with your own jscript code per

https://technet.microsoft.com/en-us/library/dn636121.aspx

All works fine when the page is viewed in IE, but does not work right when viewed as a popup from Office.

Current Status:

Right now this is a design limitation, the code simply does not run.

The product group has been informed of this limitation and it may or may not be addressed in the future.

ISSUE:
Users are receiving an error message [Sorry, but to open this workbook, your computer must be running a supported version of Microsoft <application> and a browser that supports opening files directly from Office Online.] when opening documents from SharePoint 2013 sites into Office Pro Plus 2013.

CAUSE:
Webroot AV seems to be blocking Internet Explorer's access to Interceptor.dll, which is an Office component that allows Internet Explorer to open documents in the local Office applications.

FIX:
As Webroot AV seems to be blocking access, Microsoft has no direct fixes for this issue. There are several workarounds available below.

WORKAROUNDS:
1. Add an exception for Interceptor.dll in Webroot AV. This dll is typically found at [C:\Program Files\Microsoft Office 15\root\office15].
2. Change what dll is called when Internet Explorer tries to engage the local applications. In the Registry Editor, change the Default value from [C:\Program Files\Microsoft Office 15\root\Office15\Interceptor.dll] to [C:\Program Files\Microsoft Office 15\root\Office15\OWSSUPP.dll] in the following hive location HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{9203C2CB-1DC1-482D-967E-597AFF270F0D}\InprocServer32
3. Remove Webroot AV from the system.

NOTE:
-Although it's not limited to Windows 7, the vast majority of support cases we've encountered, users have been running Windows 7.
-This issue should only effect Internet Explorer due to the unique way it reaches out to the local machine to engage the Office apps. In our troubleshooting, the latest versions of Firefox and Chrome should not reproduce this issue.
-If any/all of the workarounds stop the issue from reproducing, we highly recommend you reach out to Webroot support to report the issue.

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. 

One issue that we have noticed in testing is that anytime files are opened in Read only the Document Information Panel will not automatically open even if the SharePoint site is set to open it automatically.

Environment:

SharePoint Online

Office 2013

Here are the steps we used in our testing to reproduce the behavior:

Repro Steps:

1. While in a SPO library, in Site Settings > Site Content Types > Document > Document Information Panel Settings
   •  Select "Always show Document Information Panel on document open and initial save for this content type".
2. Create an OOB approval workflow on the SPO library.  To do this:
   •  From the library Ribbon > Workflow Settings > Add a Workflow
   •  Be sure that “*Approval – SharePoint 2010” is selected
   •  Enter anything you’d like for the Name
   •  Uncheck “Allow this workflow to be manually started by an authenticated user with Edit Item permissions” and check “Creating a new item will start this workflow”
   • Click “Next”
   • Choose an approver to receive the workflow notification emails
   • Click “Save” – This should create the workflow
3. Create a new Word document in the SPO library where you created the workflow.  Once you save the document this should kick off the workflow and generate an email to the approvers titled something like “Tasks – Please approve…”
4. Within the email, you will see “To complete this task:” along with a link to the Word document.
5. Click on that link and the document opens in your local Word client, but does not display the document information panel.  However, when you open the document directly from the SPO library and it opens in my local Word client, the Document Information Panel does display properly.

Currently there are no workarounds for modifying this behavior when using out of the box SharePoint Workflows.   If you are using customized workflows you may be able to use the workaround noted in the following blog:

http://blogs.technet.com/b/office_integration__sharepoint/archive/2014/12/04/force-microsoft-word-to-open-in-edit-mode-from-hyperlink-in-an-email.aspx

Issue:

User opens a .ppsx file from SharePoint or other network location and the file opens in PowerPoint full application.  Users want the file to open in Slide show mode.

Workaround:

This behavior can be modified by making a registry change.

**Registry changes can be dangerous if not done correctly, you assume all risks for editing the registry.

Open Regedit.exe

Navigate to Key "HKEY_CLASSES_ROOT\PowerPoint.Show.12"

edit value BrowserFlags

Set the value to be 8

The possible values are

a = open in edit mode

8 = open in show mode in new window

0 = open in show mode   - this opens in the browser, I would not recommend this, the power point process could possibly get stuck and stay running even after the slide show ended.

Symptoms

Imagine a scenario where users on a corporate network are editing their Office (Word, PowerPoint, etc) documents and click to save them.  They wait and noticed it takes an unusually long wait (thirty seconds or longer) that it takes to save the data.  If they take their laptop off of their corporate network, the save time to SPO is decreased dramatically.

Taking a network trace of the clients attempting to save their data shows unusually high TCP and/or UDP traffic across ports such as 139.

Workaround

In scenarios like this, it was noted that removing the local bindings of NetBIOS over TCP/IP seems to allow the saving of Office documents to complete at a quicker rate.

One can troubleshoot what device or network issues is causing this behavior, or simply disable (as indicated below).

NOTE: Ensure network printers do not require these settings in order for users to utilize them.


Steps to disable TCP/IP over NetBIOS

1)      Go to the client machine's Control Panel
2)      If the control panel view is setup by Category, there should be a section entitled “Network and Internet”.
3)      Under that section, we need to select “View network status and tasks”.
4)      In the next window (which should be “View your basic network information and set up connections”) there should be a setting toe “Change adapter settings” on the left window pane. We need to select that option.
5)      This will open the “Network Connections” window.
6)      We need to right mouse click on the network connection we are using (for example “Ethernet” or “Wi-Fi”) and select “Properties”.
7)      In the Network connection properties windows, we should be on the “Networking” tab and a box in the middle of the window “This connection uses the following items:”
8)      We want to scroll down in that box until can see and highlight “Internet Protocol Version 4 (TCP/IPv4)”.
9)      With that option highlighted, we should be able to select the Properties button just underneath that window.
10)   In the “Internet Protocol Version 4 (TCP/IPv4)” window, there should be an “Advanced” button near the bottom right of the window. Select that button.
11)   In the “Advanced TCP/IP Settings” window we need to select the “WINS” tab.
12)   At the bottom of this tab, we need to select the option to “Disable NetBIOS over TCP/IP” and select the “OK” button

Symptom:

Consider the following scenario....

A user browses to a WebDav or other website site, clicks into a document library and chooses to open (let's say) a Word document.  A challenge for credentials occurs.  Since the user was already prompted for credentials when browsing to the site, he/she was not expected to be prompted again every time they open a new document in the rich client.

Causes:

Some general info first:  When switching from a browser's session (IE, etc) to an Office application, the two cannot (directly) share authentication.  All access to a web server, like SharePoint, requires some form of authentication.  A user will always be challenged, even if said user never sees the challenge for credentials (it may be occurring automatically behind the scenes).   

Here are some common causes....

1. Some authentication types like Basic Authentication will always prompt.  Get used to it, it's by-design.

2. If a cookie-based authentication is using session cookies, there will always be a challenge.  

3. Non-IE browsers will not pass the persistent cookie to Office.

4. Zone settings in IE may not be set optimally for passing credentials such as NTLM or persistent cookies.

5. In older versions of Office, the WebClient Service was used for WebDav calls.  Since this service uses WinHTTP - instead of WinInet like IE - the IE zones are not checked/adhered to.  If the URL is not a local address and no proxy is configured, WinHTTP will not pass the credentials.

6. NTLM authentication is used, but users log into their client machines with one account, while browsing with another.  Since NTLM, by it's nature, automatically grabs the logged-in user account; it initially sends the wrong credentials in this scenario.





Workarounds:

1. For older authentication types that are designed to always challenge a user, the only workaround is to use another authentication type.

2. If an organization allows it, consider using a persistent cookie authentication.

3.  Office ends up getting the cookie from IE's cookie jar.  Either use IE or ensure, at some point, IE was also browsed to the same site and stored the cookie first..

4. If the zone isn't set to automatically pass credentials, Windows authentication will not be passed.  Also, Protected mode - if set on the zone -  will segregate a persistent cookie from other applications, like Office.

**See the following blog for more info around #s 3 & 4:

http://blogs.technet.com/b/office_integration__sharepoint/archive/2015/04/14/additional-credential-prompts-opening-office-documents-from-a-web-server-using-persistent-cookies.aspx

5. Since the WebClient Service does not use IE's security zones to determine if it should pass credentials automatically, the following registry key will need to be set.

NOTE:  Always back up your registry before making changes!

  Open regedit and find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

  Create a new multi-string value called:  AuthForwardServerList

  Add site URLs to this key that are considered safe to forward creds to.

See the following KB for more details:
https://support.microsoft.com/en-us/kb/943280

6.  For Windows authentication, try setting 'remember my password' check-box after the first time credentials are entered.  This should cache the account to the Windows Credential Manager for later use.  Not all organizations allow using stored credentials from this location, so this may or may not work.

NOTE: It's considered a security risk for multiple users to share a machine that logs in as one (shared) account, browse as their corpnet account and cache those credentials on the shared machine.

Symptom:

Consider the following scenario...

In a custom,  cookie authentication environment using a multiple cookie (persistent & session) scheme - whereas the first cookie (a persistent one) is set to allow the creation of the session cookie(s) to be used for continued authentication -  Office 2013 client users are unexpectedly prompted for credentials after already authenticating.

Office 2010 clients were found to not exhibit this behavior.

Cause:

Investigations showed Office 2013 was not accepting the second authenticating session cookies after initial persistent cookie expires. Office 2010 clients were able to retain the other cookie(s) for use.  This was determined to be a code defect in the Office 2013 product.  

Resolution:

Solution 1:

See the following knowledge base (KB) article for the fix:


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

Note:  Although the above article mentions several fixes in it, the one in this blog is not mentioned at the time of writing - thus the need for the blog.

Solution 2:

(workaround)

Set the initial (persistent) cookie to a longer life (expiration) so users can complete their work before being prompted again.

When opening a workbook in SharePoint using Excel 2016, it opens as read-only with the following message:
 

We opened this workbook read-only from the server.

To edit the workbook, click on the button Edit Workbook

This is a design change from Excel 2013, which opened workbooks directly into edit mode by default. The reason for the change in Excel 2016 is to prevent locking out users from editing the file.

When you open a file in edit mode, you get exclusive editing capability in the file, and no other person can then open the file to edit. They can only view the spreadsheet in read-only mode. Even if you are the only person that uses the workbook, this can happen when you open a file in edit mode and leave it open on your work machine, for example, which means you are locked out of the file for editing on another computer at home or elsewhere.

Changing the behavior to open workbooks by default in read-only mode helps prevent these scenarios. Many users read information but never make edits to the spreadsheet. For these users, opening the file as read-only works just fine for them, and it leaves the file unlocked for editing for someone else. So this change in behavior helps keep the workbook available for those people who need to edit.

Issue:

With PowerPoint 2013 when opening a document for edit from SharePoint 2010 or SharePoint 2013 you may see an error similar to this:

"Sorry, we couldn't find C:\users\<userid>\Desktop\%u. Is it possible it was moved, renamed, or deleted?"

This only happens when the SharePoint server is in an IE security zone that is set to use IE protected mode.

Workaround:

You can turn off protected mode for the IE security zone.

Current Status:

The product group is actively looking into this issue, a hotfix for PowerPoint maybe provided.  Check back to this blog for more info.

When using Microsoft Office 2010 to open an Office document, such as a Word document or Excel workbook, from SharePoint or OneDrive, you may receive unexpected credential prompts followed by the Office application closing with an error.

This is a known issue caused by the following updates for Office 2010:

October 2015 update for Office 2010 (KB3055034)

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

November 2015 update for Office 2010 (KB3101521)

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

You may also experience an issue with Office 2010 opening SharePoint or OneDrive documents as read-only.

This is also a known issue caused by the following update for Office 2010:

October 2015 update for Office 2010 (KB3054886)

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

These issues have been fixed in the following December update for Office 2010:

December 2015 update for Office 2010 (KB3114399)

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

You can also use the following workaround: Download the document from SharePoint/OneDrive to your local computer. Open the file to make changes and save it back to the local computer. Then upload the file back to SharePoint/OneDrive.

Issue:

You have Mac Office 2016 installed and want to open documents from SharePoint (2010, 2013 or SharePoint Online) , instead of opening the document in the Office application (like Word or Excel) the web editor is started.

Or if you have SharePoint 2010 or 2013 without Office Web Apps installed then you get an error:

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

Workaround:

If the document opens in Office Web Apps you can pick to "Open in Word" or "Open in Excel" which will start the rich client application and allow the document to be edited.

If Office Web Apps is unavailable, you can open the document directly from the rich client application by using the File \ Open menu and then navigating to the document library and selecting the document to open, or you can use the most recently used documents list in the rich client application.

Current Status:

 The product group is actively working on this issue right now, check back to this blog post for new information.  A server side fix will likely be available for SharePoint 2013 and SharePoint Online at some point.

Summary:

You have a custom HTML login page (like ADFS) that shows in the Office client applications when Office wants to authenticate a user for online resources.

This custom HTML login page fails to render correctly, either the UI does not fit right or you get JScript errors.

Cause:

Currently Office 2016 uses IE document mode 7 (aka IE7 mode) by default when rendering the HTML login page in the Office client, much HTML and JScript does not work or works differently when viewed with IE7.

Workaround:

You can force Office to use a different document mode for you page, you can work around this issue by putting this directive in your custom login HTML page.

<meta http-equiv="x-ua-compatible" content="IE=9" >

Summary:

You have Office 2016 Click to Run installed version 16.0.6528.1017 (March 16, 2016 first release channel) or greater and IE11 and your SharePoint side is in an IE security zone that has Protected Mode turned on.

When the above is true and you navigate to some SharePoint web pages (like a list), IE will crash.

Cause:

This is a bug.

Workaround:

Disable protected mode in the IE security zone.

Current Status:

The product group is actively looking into this issue, we have no fix date available at this time.  Check back to this blog for more information.

Symptoms

Imagine a scenario where users on a corporate network are editing their Office (Word, PowerPoint, etc) documents and click to save them.  They wait and noticed it takes an unusually long wait (thirty seconds or longer) that it takes to save the data.  If they take their laptop off of their corporate network, the save time to SPO is decreased dramatically.

Taking a network trace of the clients attempting to save their data shows unusually high TCP and/or UDP traffic across ports such as 139.

Workaround

In scenarios like this, it was noted that removing the local bindings of NetBIOS over TCP/IP seems to allow the saving of Office documents to complete at a quicker rate.

One can troubleshoot what device or network issues is causing this behavior, or simply disable (as indicated below).

NOTE: Ensure network printers do not require these settings in order for users to utilize them.

Steps to disable TCP/IP over NetBIOS

1)      Go to the client machine's Control Panel
2)      If the control panel view is setup by Category, there should be a section entitled “Network and Internet”.
3)      Under that section, we need to select “View network status and tasks”.
4)      In the next window (which should be “View your basic network information and set up connections”) there should be a setting toe “Change adapter settings” on the left window pane. We need to select that option.
5)      This will open the “Network Connections” window.
6)      We need to right mouse click on the network connection we are using (for example “Ethernet” or “Wi-Fi”) and select “Properties”.
7)      In the Network connection properties windows, we should be on the “Networking” tab and a box in the middle of the window “This connection uses the following items:”
8)      We want to scroll down in that box until can see and highlight “Internet Protocol Version 4 (TCP/IPv4)”.
9)      With that option highlighted, we should be able to select the Properties button just underneath that window.
10)   In the “Internet Protocol Version 4 (TCP/IPv4)” window, there should be an “Advanced” button near the bottom right of the window. Select that button.
11)   In the “Advanced TCP/IP Settings” window we need to select the “WINS” tab.
12)   At the bottom of this tab, we need to select the option to “Disable NetBIOS over TCP/IP” and select the “OK” button

Symptom:

Consider the following scenario….

A user browses to a WebDav or other website site, clicks into a document library and chooses to open (let's say) a Word document.  A challenge for credentials occurs.  Since the user was already prompted for credentials when browsing to the site, he/she was not expected to be prompted again every time they open a new document in the rich client.

Causes:

Some general info first:  When switching from a browser's session (IE, etc) to an Office application, the two cannot (directly) share authentication.  All access to a web server, like SharePoint, requires some form of authentication.  A user will always be challenged, even if said user never sees the challenge for credentials (it may be occurring automatically behind the scenes).   

Here are some common causes….

1. Some authentication types like Basic Authentication will always prompt.  Get used to it, it's by-design.

2. If a cookie-based authentication is using session cookies, there will always be a challenge.  

3. Non-IE browsers will not pass the persistent cookie to Office.

4. Zone settings in IE may not be set optimally for passing credentials such as NTLM or persistent cookies.

5. In older versions of Office, the WebClient Service was used for WebDav calls.  Since this service uses WinHTTP – instead of WinInet like IE – the IE zones are not checked/adhered to.  If the URL is not a local address and no proxy is configured, WinHTTP will not pass the credentials.

6. NTLM authentication is used, but users log into their client machines with one account, while browsing with another.  Since NTLM, by it's nature, automatically grabs the logged-in user account; it initially sends the wrong credentials in this scenario.

Workarounds:

1. For older authentication types that are designed to always challenge a user, the only workaround is to use another authentication type.

2. If an organization allows it, consider using a persistent cookie authentication.

3.  Office ends up getting the cookie from IE's cookie jar.  Either use IE or ensure, at some point, IE was also browsed to the same site and stored the cookie first..

4. If the zone isn't set to automatically pass credentials, Windows authentication will not be passed.  Also, Protected mode – if set on the zone –  will segregate a persistent cookie from other applications, like Office.

**See the following blog for more info around #s 3 & 4:

http://blogs.technet.com/b/office_integration__sharepoint/archive/2015/04/14/additional-credential-prompts-opening-office-documents-from-a-web-server-using-persistent-cookies.aspx

5. Since the WebClient Service does not use IE's security zones to determine if it should pass credentials automatically, the following registry key will need to be set.

NOTE:  Always back up your registry before making changes!

  Open regedit and find the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

  Create a new multi-string value called:  AuthForwardServerList

  Add site URLs to this key that are considered safe to forward creds to.

See the following KB for more details:
https://support.microsoft.com/en-us/kb/943280

6.  For Windows authentication, try setting 'remember my password' check-box after the first time credentials are entered.  This should cache the account to the Windows Credential Manager for later use.  Not all organizations allow using stored credentials from this location, so this may or may not work.

NOTE: It's considered a security risk for multiple users to share a machine that logs in as one (shared) account, browse as their corpnet account and cache those credentials on the shared machine.

Symptom:

Consider the following scenario…

In a custom,  cookie authentication environment using a multiple cookie (persistent & session) scheme – whereas the first cookie (a persistent one) is set to allow the creation of the session cookie(s) to be used for continued authentication –  Office 2013 client users are unexpectedly prompted for credentials after already authenticating.

Office 2010 clients were found to not exhibit this behavior.

Cause:

Investigations showed Office 2013 was not accepting the second authenticating session cookies after initial persistent cookie expires. Office 2010 clients were able to retain the other cookie(s) for use.  This was determined to be a code defect in the Office 2013 product.  

Resolution:

Solution 1:

See the following knowledge base (KB) article for the fix:

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

Note:  Although the above article mentions several fixes in it, the one in this blog is not mentioned at the time of writing – thus the need for the blog.

Solution 2:

(workaround)

Set the initial (persistent) cookie to a longer life (expiration) so users can complete their work before being prompted again.

When opening a workbook in SharePoint using Excel 2016, it opens as read-only with the following message:
 

We opened this workbook read-only from the server.

To edit the workbook, click on the button Edit Workbook

This is a design change from Excel 2013, which opened workbooks directly into edit mode by default. The reason for the change in Excel 2016 is to prevent locking out users from editing the file.

When you open a file in edit mode, you get exclusive editing capability in the file, and no other person can then open the file to edit. They can only view the spreadsheet in read-only mode. Even if you are the only person that uses the workbook, this can happen when you open a file in edit mode and leave it open on your work machine, for example, which means you are locked out of the file for editing on another computer at home or elsewhere.

Changing the behavior to open workbooks by default in read-only mode helps prevent these scenarios. Many users read information but never make edits to the spreadsheet. For these users, opening the file as read-only works just fine for them, and it leaves the file unlocked for editing for someone else. So this change in behavior helps keep the workbook available for those people who need to edit.

Issue:

With PowerPoint 2013 when opening a document for edit from SharePoint 2010 or SharePoint 2013 you may see an error similar to this:

"Sorry, we couldn't find C:\users\<userid>\Desktop\%u. Is it possible it was moved, renamed, or deleted?"

This only happens when the SharePoint server is in an IE security zone that is set to use IE protected mode.

Workaround:

You can turn off protected mode for the IE security zone.

Current Status:

The product group is actively looking into this issue, a hotfix for PowerPoint maybe provided.  Check back to this blog for more info.

When using Microsoft Office 2010 to open an Office document, such as a Word document or Excel workbook, from SharePoint or OneDrive, you may receive unexpected credential prompts followed by the Office application closing with an error.

This is a known issue caused by the following updates for Office 2010:

October 2015 update for Office 2010 (KB3055034)

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

November 2015 update for Office 2010 (KB3101521)

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

You may also experience an issue with Office 2010 opening SharePoint or OneDrive documents as read-only.

This is also a known issue caused by the following update for Office 2010:

October 2015 update for Office 2010 (KB3054886)

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

These issues have been fixed in the following December update for Office 2010:

December 2015 update for Office 2010 (KB3114399)

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

You may also encounter an Office application closing unexpectedly when saving a file as a different name (Save As) to SharePoint.

This is a known issue caused by the December 2015 update for Office 2010 above, and by the following January 2016 update for Office 2010:

January 2016 update for Office 2010 (KB3114553)

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

This issue is was fixed in the February 2016 update for Office 2010:

February 2016 update for Office 2010 (KB3114750)

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

You can also use the following workaround: Download the document from SharePoint/OneDrive to your local computer. Open the file to make changes and save it back to the local computer. Then upload the file back to SharePoint/OneDrive.