New OneDrive & SharePoint Feature: Fixing Unhealthy Sharing Links


Hi all,


I wanted to drop by and let interested folks know about a new feature we are rolling out to help users deal with "unhealthy" links! We've seen a few cases recently where a user makes some permission changes (such as breaking inheritance manually via permissions API's) that can cause sharing links to become unhealthy, which means the links exist but they no longer grant actual access to the item. In these cases, the sharing dialog still returns the link but the recipient will be unable to use it. 


To help with these cases, we've made a change to Manage Access to now show these unhealthy links along with a new string to help guide users. In order to use that type of sharing link again, users can delete the existing link and then create a new one. Please note that in some cases, re-sharing the item with the same settings can often allow the service to automatically fix the link with no end user impact.   


Unhealthy Link.png

We'll begin rolling this feature out to all customers soon. If you have any questions, please let me know!


Stephen Rice

Senior Program Manager, OneDrive

16 Replies

@Stephen Rice

Good day. Do you know of any blog or documentation that covers a few common ways links can become broken? I'm currently working on a ticket with Microsoft for just that. A user shared a link with non-company users, it works for a long while, she changes the name, and sometime after that the company and my user finds that the document is broken; however, other links to the document work.  I could give more information, but I'm not asking you to look into my problem, just if your expertise may reveal documents not easily found. 


Thank you for your time.


Daniel Smith

Hi @dsmith_icona,


This post is the only "documentation" that we have at the moment. The particular case we are covering here occurs when advanced users play with the advanced permissions API's around a file/folder/document library. The short but technical explanation is that a sharing link consists of a link object that is tied to an ACL on the item and when the ACL gets removed (but the link is not), it can cause some pretty broken scenarios. This only occurs if you use lower level permissions API's though as all of our UI for sharing/unsharing files will always clean up both pieces. 


Renaming a file wouldn't cause this to occur though so working through this with support is likely your best bet. Thanks!


Stephen Rice

Senior Program Manager, OneDrive

@Stephen Rice, Will this go to all customers simultaneously? Will GCC clients get it at the same time as other customers?


Thank you,

Hi @Justin-GOV,


We will roll this out to our Prod customers first (already started) and it should hit GCC soon after. Thanks!

Stephen Rice

Senior Program Manager, OneDrive

@Stephen Rice 

Hi Stephen,

this sounds like a good feature! I would be even more happy if a report, or csv, could be generated with these broken links. Preferably per site or tenant wide.

Hi @Andre_B_Backs,


That's great feedback! Definitely something we'll keep in mind as we improve in this space! Thanks!


Stephen Rice

Senior Program Manager, OneDrive

@Stephen Rice great change! 


The notification that we receive for the change says "If you would like to enable this policy for your tenant, review these instructions."

I've not seen any instructions or links to technical documentation, is this a admin centre toggle or a client side setting?   

Hi @mikeparkie,


Sorry for the confusion! There is no admin configuration or toggle in this space. This is just new UI to help with an edge case that some users were running into. Sorry for the confusion! Thanks!

Stephen Rice

Senior Program Manager, OneDrive

@Stephen Rice Thanks for the confirmation. 

@Stephen Rice 


Hi Stephen,


I am working with the SP REST api to programmatically remove individual users from a secure link.


I have noticed some odd behaviour when multiple API calls are made in parallel, each trying to remove access for a different user against the same SecureLink.


Sometimes this results in a SecureLink turning "unhealthy", showing the red "broken link" warning text in the UI.


I am also intermittently (but regularly) seeing scenarios where I am trying to remove user A and B, and even though each request results in a HTTP 200 response (with no error in the response body), it appears as if the removal of user B reinstates user A against the link. Note that this only happens if the API calls are made in parallel. If the same API calls are made in sequence then everything works as expected. To me this suggests there is some sort of concurrency issue on the server side.


I am only using the /ListItemAllFields/SecureLink endpoint, using the inviteesToRemove bit in the JSON payload to indicate which user to remove. I am not using any API endpoints that directly manipulate the underlying ACLs.


I also think this issue could arise if multiple end users are modifying the same secure link through the browser and they happen to submit their changes at the same time, given that this operation uses the same API endpoints.


Let me know if you need me to provide more info or some code to reproduce this issue.












Hi @jvossers,


We don't currently support making sharing API calls to the same object in parallel. We recommend sequential calls when you need to perform multiple operations on the same link. Thanks!


Stephen Rice

Senior Program Manager, OneDrive

@Stephen Rice I have found that the following scenario will **always** cause a link that is broken.


I am trying to share a video with everyone in the company, but I do not want people to be able to download the video.  As the picture below shows, I am creating the link and I must Copy the link once I hit apply.

Then, when I go back and look at the status of the link, it is always broken.


Hi Marcel,

I am not able to reproduce this. Does it occur in all cases (e.g. your OneDrive, a team site, etc) or with other files? Thanks!

Stephen Rice
Senior Product Manager, OneDrive

@MarcelMeth we ran across a similar problem with one site (only) in our tenant. In our case, the problem was with sharing links to (Word) documents and libraries.

After doing some probing we found the link was broken only if we specified "Read only" and did not block download. This led us to the permission levels on the SharePoint site. It turned out that one of the site owners had edited the "Read" permission level.

We were able to revert the permission level by editing it using another site as a template and this fixed the links.

Hope this helps.



This sounds like exactly what I too am looking for. However I cannot find anywhere that the inviteesToRemove syntax is explained. What call are you using for that?