Introducing a new secure external sharing experience
Published Oct 02 2017 11:00 AM 315K Views
Microsoft

At Ignite we announced a major improvement to the way secure external sharing of files and folders works in both OneDrive and SharePoint in Office 365 and we wanted to share what this means for users and IT administrators alike. Based on your feedback, we have focused our updates on two key areas: ensuring intended recipients get access 100% of the time, and continual reverification of identity. 

 

These updates will begin rolling out to First Release tenants on October 9, 2017.  

 

Ensuring intended recipients get access 100% of the time: Identity verification 

Office 365 makes it easy to share files and folders by creating a shareable link. Recipients can click the link and immediately access the file without having to go through any additional process. You can already create links that can be used by anyone, and links that are internally shareable within people in your organization.  

Sometimes you need to share with additional security and require that people with the link prove that they are intended recipients. Office 365 also makes it easy to do this by allowing you to send links that work only for specific people 

 

 ExternalSharing2.gif

 

Now, when sending secure links to recipients outside of your organization, those recipients will be sent an email message with a time-limited, single-use verification code when they open the link. By entering the verification code, the user proves ownership of the email account to which the secure link was sent.

 

2.png

 

Secure links allow external recipients to access files and folders securely without requiring them to create or maintain a Microsoft account. Email-based verification codes are a simple and effective way to provide secure access, familiar to users who access secure internet sites that verify identity by sending a code by email or text message.

 

Continual reverification of identity

Now, IT administrators can specify how often external recipients must get a new code and re-verify their email address. This governance control protects your organization’s files and folders from situations where an external recipient’s employment status changes, or any other situation which can cause them to lose access to their email account.

 

3.png

 

To enable this setting, go to the sharing section in the SharePoint admin center.

IT professionals will recognize secure links provide access to external recipients using the same standard adopted by many financial institutions: email-based verification codes and reverification periods. This familiar approach is easier to manage and more secure than competing solutions that require an external recipient to create user accounts that may persist even after the user leaves their current employer and no longer owns that email, creating a very dangerous security hole.

 

Getting started

These features start rolling out on October 9, 2017, to First Release customers and will roll out to all customers by the end of January 2018.

 

For additional information on the new external sharing experience in OneDrive for Business and SharePoint Online, read the New Sharing Features in First Release help article. 

219 Comments
Iron Contributor

One of my customers is running as FR and now we are using the new Sharing Model. In my testing I was not using my real account but today I wanted to user my company AAD account to access a word document we are working on. In the browser I could access the word online version. The normal "Edit in Word" is missing:

ApplicationFrameHost_2017-12-01_10-25-44.png

 

In the Office Online version I can select "Edit in Word":

ApplicationFrameHost_2017-12-01_10-29-24.png

 

But in Word Desktop I'm not able to "sign in":

2017-12-01_10-31-19.png

This is not working. I would expect that I will be prompted for a PIN in Office. If this is by design... this is BAD :)

 

Microsoft

Hi @Marco Scheel,

 

This is by design. The new external sharing flow is only available for the web at this time. We're currently investigating how this feature will work with the clients as well so stay tuned for more information. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Iron Contributor

Hi @Stephen Rice,

 

thanks for the info. I was getting more comfortable with this new way, but this fact is one again putting me down. I see the benefits of the new sharing model replacing the AAD guest based model, but this means that this way of sharing reduces the user experience dramatically :( I will also get used to tis fact an in most client scenarios we can work aground using B2B options. But I have a few high profile clients that are internally not ready to allow external guests in AAD groups and are now limited for the time being. I'm looking forward for an announcement for the removed features (Client apps).

 

Ciao Marco

Bronze Contributor

Hi @Stephen Rose,

I love the verification codes for shareable links (with documents/folders), but is there any chance that this will come to sharing full sites with guests as well? 

I'm looking for a way to enable guest access to a site with very specific permissions that will be handled through SharePoint Groups, without the guest having to create an Microsoft ID.

Copper Contributor

Do you happen to if/when the PnP javascript library will be updated to support sharing secure links?  Or, is there an example somewhere of how to use the PnP javascript to send a secure link?

 

UPDATE: I just tested the PnP 'shareObject' javascript method and it will create and email a secure link now.

Brass Contributor

On the continual re-verification of identity. The blog states that IT administrators can now specify how often external recipients need to re-verify their email address. This has been set to 30 days in our organisation, however it appears every time external recipients attempt to use the shared link, a new verification code is sent...?  

 

"Continual reverification of identity

Now, IT administrators can specify how often external recipients must get a new code and re-verify their email address. This governance control protects your organization’s files and folders from situations where an external recipient’s employment status changes, or any other situation which can cause them to lose access to their email account."

Ownership-verify.jpg

Brass Contributor

@Stephen Rose if a first time external share recipient has an Office365 subscription in their organisation. Are they able to access the shared link by signing in with their office365 account, instead of verification code method?

Brass Contributor
As I understand it, if the user you attempt to share to doesn't already exist in your AAD as a guest user they will get a link + OTP if you share a file or folder. If you share a site you will have the old (imo better more secure :p ) experience using B2B and work accounts to authenticate.
Copper Contributor

I must be missing something because when I share with "Specific people" outside of the organization, they receive the same Open [Link] and then have to register if they don't have a Microsoft account. They are never receive or required to enter the verification code. Could this be because something isn't correct in the admin center?

@Ivan Unger Right now this is only for files and folders.

 

@John Tsalamandris External recipients need to check the "keep me signed in" box otherwise they will need to re-enter a code next time they click the link, even if that admin option is set to 30 days. For your second question, right now users only get asked to sign in if they have a Guest account which exists in that organization. If they don't already have a Guest account then they will be taken through the passcode flow.

 

@Shery Kirby It sounds like the feature isn't rolled out to your organization yet. It's currently rolled out to 50% of organizations. If you'd like to accelerate your access to it then you can enroll your organization into the First Release program for all users.

Copper Contributor

@Rafael Lopez-Uricoechea So, the actions are all available for use in the New Experience but ultimately when the external user receives the link it appears the same as the earlier email message and the user is redirected to the Microsoft sign in page, using Microsoft, Organizational, or Create a new account until the new sharing experience gets rolled out. Am I understanding you correctly?

 

@Shery Kirby That's the correct description for what would happen to organizations which do not yet have this feature rolled out to them.

Copper Contributor

I am testing this Ad-hoc external sharing method. It seemed if I use a hotmail account, I am able to get the one-time code. However, if I use other email accounts such as gmail or yahoo mail account, this doesn't work. here is the message I got from an GMAIL account when I try to open the secured link. Does it support gmail or yahoo mail or other non-MSA email account? Thanks.

 

ad-hoc sharing.PNG

 

 

Microsoft

Dean

 

Secure sharing works with all providers (gmail, yahoo, etc...) no MSA required. You will need to use that users email for the share and code. Also the code is a one time use code.

Copper Contributor

@Stephen Rose. thanks Stephen for quick response! Then what does "The link is not available to you" mean? I tried a few times already. thanks.

@Dean Chen That error message shows up when you are signed in with an account that doesn't match email address that the link is secured to. It looks like something is particularly odd there since the error message is supposed to include which email address you're currently signed into.

 

Can you try going to www.office.com and/or the root fo your sharepoint (http://tenant.sharepoint.com) to see what account you're currently signed into?

 

If you go back to gmail and open the link in a different browser or a private browsing session with no sign-in cookies then you should no longer see that message.

Copper Contributor

@Rafael Lopez-Uricoechea Thanks for the suggestion! After I cleared up the cached history in the browser or logged onto a different browser, my Gmail or Yahoo account worked with the secured link and with the one-time code as designed!

 

I do have a couple questions to understand this new secured sharing method.

1. At the tenant level in SPO, by default, we have 30 days setting under "Require recipients to continually prove access ownership when they access shared items". Does this 30-days mean, after 30 days, the secured link is no longer valid, correct? If the guest wants to continue to access the shared contents after 30 days, they would have to ask the sender to share the contents with a new email again, right?

 

2. As I understand the "One-time code" concept, it has to be sent over to the guest every single time when the guest clicks the link, is that correct?

 

Thanks,

 

@Dean Chen For #1 actually if you have this set to 30 days then it means that recipients who enter a code will have to re-verify their email address by entering a new code 30 days after they enter the first one, even if they checked the "keep me signed in" box. So for example if you send me a secure link on December 1st and I enter in the code and click "keep me signed in", when I come back on December 30th I'll be asked for a new code. The link itself still will continue to work and I don't have to ask you for re-share the content with me.

 

This feature is primarily meant to protect against employment changes for recipients. For example if on December 1st I work for Contoso and have rafael@contoso.com but then by December 30th I left Contoso, then I won't be able to re-verify my rafael@contoso.com email address and so will lose access to the content that you shared with my Contoso identity.

 

For #2 it depends on whether the recipient clicked on "keep me signed in". If they do not check that box then the code is only valid for that browsing session. If they close their browser then they'll need to click on the link again and enter in a new code.

Copper Contributor

@Rafael Lopez-Uricoechea Understand. I will continue to test. If I have any new questions, I will post them there. :)  Thank you!

Deleted
Not applicable

I have mixed feelings about this change.  

 

Firstly although we received the message in September that it was slowly rolling out, we didn't get any further messages and so last Wednesday we started getting tickets from users that their partners (outside the organisation) were complaining they couldn't get to content.  Turned out we had been rolled to the new experience without any further communications or warning - that needs to improve.

 

I saw elements of this at Ignite back in September so I knew when customers explained what they were seeing that we had been 'upgraded'.

 

To the feature itself.  

1) Yes it makes adhoc sharing a little easier, previously some customers didn't get the 'Do you have a Microsoft account / O365 Account' screen.  I struggle what was difficult about it but whatever.  So on that point yep the verification code is a different approach and for some folk easier.

 

2) However if I invite say 6 external people to share a folder so we can collaborate then they all get that code and under permissions I see one entry, the link with a little 'x' to the right of it (more on that later) and underneath it small grey circles for each of the 6 people I shared it with.  Say I no longer want to share with 1 of those folk, I can't remove just that one.  I have to kill the link completely and reinvite the other 5 people - they then get a new link.

 

3) That link.  That link needs to be kept and if it changes as per item 2 then it needs to be updated - that's a pain.  Our users can't just send them a link to the folder and have them go through the login screen as they did previously.  They have to remember when they send emails to the whole team that these 6 people have a different link to everyone else.  And if they invite some more external people that will be another weird link.   In just a few days for one of our external collaborations we have 3 of these odd verification code links and of course the 10 or so internal people.  That means for every update email they have to send 4 links out and inform folk which link to click on to keep up to date on progress on the project. - that's absolutely horrible.

 

4) If I do have a long term external partner that we are working with then the best way is actually to onboard them into AD.  This now becomes an IT ticket that the colleague has to submit and our managed service has to execute.  Its also something the colleague has to think about up front.  In the previous solution (last Tuesday) they just emailed them and they got added to AD.  So an IT burden and a colleague burden has been added.

 

Overall I think the idea is good but the implementation is weak and not well thought out.  Longer beta testing of this feature with companies that do large amounts of external collaboration would have been good.  I also feel there needs to be a colleague option that lets them choose between 1-time adhoc collaboration and long term collaboration ie. verification code or onboard.  The verification codes sent need to be broken into distinct permission entries, ie. an invite to 6 people should result in 6 distinct permission entries, not 1 link with 6 people listed under it.

 

This change really hurts us and to be honest its pushing us away from O365 towards Box and other solutions.

 

Brass Contributor

Is the token authentication a forced change?  My understanding was yes but in looking at this it appears it is a check box that is optional.

 

Screen Shot 2018-01-02 at 1.35.33 PM.png

 

Second, if this is enabled then there is no way to share a site with an external party?  

Hi @Brett Cox. The checkbox you’re seeing does not control whether this feature is enabled or not. Instead, it is an optional feature (off by default) which lets you specificity how often recipients need to re-verify their email. For example if you share with amy@contoso.com and this checkbox is set to 30 days, then when Amy enters in the code to access the file/folder, she will have to do the same thing again 30 days later (even if she selected to be kept signed in). This way, if she loses access to her email account (for example if her employment status changes) then she also loses access to that shared item (because she can’t enter the new code).

 

Does that make sense?

 

For site sharing, you can still share externally but for now it will use the previous system that requires that recipients create accounts.

Brass Contributor

@Rafael Lopez-Uricoechea Thanks, makes sense.  What is still not clear to me then is how this new token sharing is managed in the SP admin portal.  I do not see anything new in the portal.  I thought we were going to set the validity period for the token.  Is the only way to set a validity period for the token sharing via the method in my message above?  Is the token roll-out complete?

@BRETT COX Based on your screenshot this feature has already rolled out to your tenant.

 

You can limit the type of external sharing allowed in your tenant or in specific groups/sites. This flow is enabled when your external sharing is set to allow new external users. If you turn external sharing off, or you limit it to only existing users in the directory then no users will go through this flow. But when you allow sharing to new external users then this flow will be used during secure sharing and there’s no way for admins to revert to the old experience.

 

The code itself can only be used once and must be used within 15 minutes of it being generated (it gets generated when the recipient clicks on the link). Once the code is entered, by default it will only allow access to the shared resource for the length of the browser session. If the browser session ends and the user clicks on the link again in a future session then a new code will be generated and sent to the email address the link is secured to.

 

If end users/recipients do not want to have to re-enter codes on every new session, they can choose the “keep me signed in” checkbox on the code verification page. When they do this, the access to the file will persist beyond the browser session. They can close their browser and open it again. When they click the link they will not be asked for a new code.

 

By default they can do this indefinitely (as long as they manually checked “keep me signed in”) but the setting in your screenshot allows admins to set a time limit  for when recipients have to get a new code, even if they had checked to be kept signed in.

Copper Contributor

I am very much with @Deleted - this is going to require a lot of inconvenience for what was previously a smooth on-boarding to share with new external users. We already had to ask them to go through the process of creating Microsoft Accounts to access when we first shared to them, and now if additional members from the same client agency need access to the share, their experience will be different. And we have to maintain it with much more granular focus than we did before. When will the process change again? That link is horrible. Please give us the option to move back to account authentication if we choose. 

 

Our organization is incredibly frustrated with this change. It's given us a black eye we didn't need when asking people to buy in on using Sharepoint Online and we also will be considering other options as a direct result of it.

Copper Contributor

@Stephen Rose@Rafael Lopez-Uricoechea, or @Stephen Rice is this feature available via the graph api yet?

Deleted
Not applicable

@Stephen Rose@Rafael Lopez-Uricoechea, or @Stephen Rice: is there a way for OneDrive to send an automated reminder (say, weekly) providing each individual OneDrive user a listing of the files they have shared externally and with whom? If they're not required to use an expiration date with files, it can be handy to remind them of all the files/data they've "released" to the outside world so they can clean up (i.e., un-share) from time to time. Is something like this available today?

Microsoft

@Deleted, you can get at this data via auditing today but there isn't a straightforward path to build that type of report. It's definitely a use case we want to fulfill but we don't have anything to show off just yet. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Brass Contributor

@Stephen Rose@Stephen Rice, following on really from the points @Deleted has made, and some I'm re-iterating here.

 

I'm currently working for a client that has very recently deployed SharePoint Online to the business. They work heavily with external users and the way SharePoint/Onedrive now handles External Sharing is causing a few problems.

  1. When a person shares a document to a collection of people, one link gets created for all of those people. There is currently no way to stop access to one person without deleting the link and then adding the other people back again. There should be a way of removing access for one person that using a link instead of deleting all. Perhaps clicking on their profile picture that always shows the default grey profile picture and their email address (on hover), gives an option just to remove that one person. 
  2. If you have already shared with one person and it creates a link for them, and another person/or yourself, (without really looking if it has already been shared with that person), try sharing with the same person again, a new link is made on that document. Why can the code realize the document has already been shared with that person? Sure sent the email out again, but don't make another link. 
  3. If it is a different person who the document is shared with, but the document is being shared, being shared with the same permission as an existing link, why can't the person be added to that link and then give them that link, instead of creating two separate links?
  4. The new external "Sharing Links" obviously isn't being picked up in search properly. If you got to Site Content -> Site Usage, then click the "Shared externally" tab, I no longer see the documents that are shared with an external Sharing link showing in this list. Only if I share a document with an external user that is within our AD Directory, does the document show on this tab. This needs to be fixed, as it was the only indication for a site owner to quickly see what documents/folders were externally shared.
  5. Following on from my last point, we had a Content Search webpart that used to display External documents, simple query 
    path:"https://myexamplesite.sharepoint.com/sites/testingexternalshare"  (IsDocument:"True" OR contentclass:"STS_ListItem") ViewableByExternalUsers=TRUE
    This content search webpart no longer return results of the new Sharing links.
  6. The new sharing links can only Share as a Contributor or Read only. There doesn't seem to be an option to Share externally to someone and allow them editable rights on the document, but prevent them from deleting the document. The old way of sharing, you could at least go into the advance permissions section and change the person permission to use a custom permission, in our case "Contribute (No Delete)" 
  7. When will these links be getting expiry options? 
  8. As a developer, I know PNP have used the APIs to create new sharing links to external users. However, I haven't found any documentation, or way of being able to say, Is this document being externally shared? Who are the email address that this is shared with. I should be able to bring back the same list of people email address, that I currently see under the Sharing link.
  9. Lastly, and this is Sharing in general, not just the new Sharing links. There seems to be a blanket share for a site. Either the site & items are sharable or they are not. It would be good if there was a seperation on a site of those that can share the entire site and those who can share at folder/item level. An owner for example should be able to share an entire site, but maybe the members of the site, can only share at folder/item level.

 

Happy to discuss further in a private message.

Microsoft

Hi @Paul Matthews,

 

Thanks for all of your feedback! Some of these I have answers for today (see below) and others are things that we'll discuss internally as we gather feedback. So without further adieu, let's dive in :) I'm also changing to bullets as the numbering is getting screwed up as I add responses in.

 

  • When a person shares a document to a collection of people, one link gets created for all of those people. There is currently no way to stop access to one person without deleting the link and then adding the other people back again. There should be a way of removing access for one person that using a link instead of deleting all. Perhaps clicking on their profile picture that always shows the default grey profile picture and their email address (on hover), gives an option just to remove that one person.
  • This is probably one of the most common complaints we've seen and it's something we're absolutely committed to fixing. I don't have a timeframe for you just yet but stay tuned :)
  • If you have already shared with one person and it creates a link for them, and another person/or yourself, (without really looking if it has already been shared with that person), try sharing with the same person again, a new link is made on that document. Why can the code realize the document has already been shared with that person? Sure sent the email out again, but don't make another link. 
  • Good feedback, I will pass this along. More on why we do this below.
  • If it is a different person who the document is shared with, but the document is being shared, being shared with the same permission as an existing link, why can't the person be added to that link and then give them that link, instead of creating two separate links?
  • The goal behind multiple links is that we want to give users easier ways of managing who has access. So for example, you may take a marketing doc and share it once with Users A, B, C of Partner 1 and then again with Users D, E, F of Partner 2. If you need to unshare with one of your partners, we wanted to make it easy to undo each "share" operation (as opposed to having to either unshare to everyone and re-share or to go into a single link and remove individual users).
  • The new external "Sharing Links" obviously isn't being picked up in search properly. If you got to Site Content -> Site Usage, then click the "Shared externally" tab, I no longer see the documents that are shared with an external Sharing link showing in this list. Only if I share a document with an external user that is within our AD Directory, does the document show on this tab. This needs to be fixed, as it was the only indication for a site owner to quickly see what documents/folders were externally shared.
  • Thanks for bringing this to our attention. Can you repro this reliably?
  • Following on from my last point, we had a Content Search webpart that used to display External documents, simple query 
    path:"https://myexamplesite.sharepoint.com/sites/testingexternalshare"  (IsDocument:"True" OR contentclass:"STS_ListItem") ViewableByExternalUsers=TRUE
    This content search webpart no longer return results of the new Sharing links.
  • The new sharing links can only Share as a Contributor or Read only. There doesn't seem to be an option to Share externally to someone and allow them editable rights on the document, but prevent them from deleting the document. The old way of sharing, you could at least go into the advance permissions section and change the person permission to use a custom permission, in our case "Contribute (No Delete)" 
  • Good feedback, I will pass this along
  • When will these links be getting expiry options? 
  • This is definitely an ask we hear often. Nothing to announce yet but we certainly hear the desire.
  • As a developer, I know PNP have used the APIs to create new sharing links to external users. However, I haven't found any documentation, or way of being able to say, Is this document being externally shared? Who are the email address that this is shared with. I should be able to bring back the same list of people email address, that I currently see under the Sharing link.
  • I don't believe we have anything available here just yet. Stay tuned.
  • Lastly, and this is Sharing in general, not just the new Sharing links. There seems to be a blanket share for a site. Either the site & items are sharable or they are not. It would be good if there was a seperation on a site of those that can share the entire site and those who can share at folder/item level. An owner for example should be able to share an entire site, but maybe the members of the site, can only share at folder/item level.
  • I'll pass this along as well.

 

Thanks again for your feedback!


Stephen Rice

OneDrive Program Manager II

Microsoft

@Paul Matthews,

 

On the tagging issue, are you seeing the item show up correctly before the external user has accessed it or after they've accessed it? The former is expected (matches the behavior we have today, for better or worse :) ) but the latter should work. If it's not, let me know so we can investigate. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Brass Contributor

Hi @Stephen Rice

 Thank you for your reply. Hopefully some of my suggestions will implemented.

 

In regards to the tagging, which I assume you mean search, I did go through ms-support on my tenant (not premium support) to help me work out if there was an issue. I only got the sharing links once to show up in the external sharing stats page. I had to click stop sharing so only the owners had access to the document/folder, then I shared with an external user who was not part of my AD, so that it created a sharing link.

 

(I believe I did test that the external user had access to the document, but cannot guarantee I did this for every test. However, I would argue this isn't very good, as you could have a document externally shared for months, because the person has never accessed it, and you wouldn't know in the externally shared stats.)

 

It was only after I reindex the document library, and after about 20mins or so, the item came up saying it was shared. However, if I removed the share, and reindexed the document library, it still showed that it was externally shared, even when I checked it the next day. I have yet to see it properly working since and without a need to reindex the document library, or clear all permissions first. 

 

We do have custom permissions on our sites. There are a couple of additional groups apart from Owners, Members and Visitors. Our library inherit permissions from the site initially. However, surely this shouldn't prevent it from working. I can set up a test now and check tomorrow, on a standard OTB team site.

 

Thanks

 

Paul

Copper Contributor

@Rafael Lopez-Uricoechea, @Stephen Rice, a quick question to confirm. This new external sharing method is still limited by the anonymous access link expiration days, right? For example, in SPO, if I set 15 days in "Anonymous access links expired in this many days", the shared link will expire after 15 days, even if I send this link out through "Only the people you specify will have the access to edit". Is that true? or the link won't expire at all?

 

Thanks,

Dean

Copper Contributor

I think I got it. the link never expires, unless someone says differently. Thanks.

@Dean Chen the expiration policy you are referring to is only for “anyone” links and doesn’t yet apply to “specific people” links.

Copper Contributor

This change is extremely frustrating as outlined by many comments on this blog.  The fault it is causing for our users is this.

  • Share a word file with an external user not yet registered in AAD
  • They can view and edit in Word Online with the new method (emailed link + verification pin)
  • They cannot edit in Word 2016 on the desktop
  • They never get registered (as intended by the new design)

So for new external users we must perform something similar to this (assuming they already failed as outlined above).

  • Have them clear the cookies from the browser
  • Share a SITE with the person  (using an empty site specifically for this purpose)
  • Let them login the old way using an associated Microsoft account and thus being registered into AAD
  • Re-share the file that we actually intend them to edit
  • Now it allows editing in full word as it did in the past

This causes the external person to contact the sharer who will contact IT for support.  The process is very confusing and results in more failure and more contact required than before.

I hope this new method can become an option that we can opt out of - and quickly!

 

 

 

 

Copper Contributor

@Julian Orange, my experience is to delete the cookies if the shared folder was shared before. Re-sharing is another way to do it

Microsoft

Hi @Julian Orange,

 

We've certainly heard this feedback and it is something we're looking to address. Stay tuned for more details. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Copper Contributor

This new secure sharing method eases the onboarding of external participants but now thoroughly inhibits collaboration with them, which is the entire point of the feature.  Forcing external users to use the limited "Edit in Word Online" obstructs our employees from using our most necessary functionality, Change Tracking, alongside our external partners. 

 

When will the full, "Edit in Word" functionality be re-enabled?  O365 support doesn't understand what the problem is, which makes it even more frustrating.

Microsoft

Hi @Patrick Sudderth,

 

This is probably the most common feedback we've heard on the new external sharing method and it's something we're absolutely looking at. Stay tuned.


Stephen Rice

OneDrive Program Manager II

Copper Contributor

Hi @Stephen Rice

Thanks for the reply.  Is there an ETA on bringing back the full functionality to offer "New External Users the ability to Edit shared Word Documents in Full/Desktop Word without requiring assistance" ?
Would it help the process if I open a premiere support request? 

The trouble is not the ones we have to assist with a workaround but the ones who do not report it, lose faith in the system and find other means for collaboration.

Thanks

Julian

Microsoft

Hi @Julian Orange,

 

We don't have anything specific to share just yet. You can open the premiere request but I expect you'll end up hearing the same thing as a result. We certainly understand the frustration and hope to have more to share soon. Thanks!

 

Stephen Rice

OneDrive Program Manager II

Copper Contributor

@Stephen Rice,@Rafael Lopez-Uricoechea, got another problem. We use this new sharing experience for OneDrive and the SharePoint site documents that is a part of an Office 365 Group. They work. However, we just found out that this new sharing experience doesn't apply to the SharePoint site that is created directly within SharePoint Admin Center. Let me call it "the classic SharePoint site" to be differentiated from the SharePoint site of an Office 365 Group. When I was trying to share a folder/file by entering the recipient's email address, I got an error "Your organization's policies doesn't allow you to share with these users. Please contact your IT department for help.". And there isn't such a new experience of "Only the people you specify will have the access to edit" in such a "classic SharePoint site" anyway. Why is that? Did I miss something?

 

Thanks,

Dean

@Dean Chen Currently when you create a site collection directly from the SharePoint admin center it is created with external sharing disabled. To enable external sharing on it you can select the site collection in the list and hit the Sharing button up top

 

sharing button.PNG

Copper Contributor

Hi, is this related? I posted this earlier today before reading this article: https://answers.microsoft.com/en-us/msoffice/forum/msoffice_onenote-mso_win10-mso_2016/onenote-exter...

 

Microsoft

Hi @Flynn Chris,

 

I can't seem to access that page. Can you re-post that content here? Thanks!

 

Stephen Rice

OneDrive Program Manager II

Copper Contributor

Hi @Stephen Rice

 

Sorry not sure why I can see that link and doesn't work for others. Here is the post:

__________

Hi,

I work in a school sector where each school has its own O365 Tenant. At times there is a need to share OneNote Notebooks externally between tenancies. I am sure external sharing is permitted in the sites' settings. Sometimes it works but often it doesn't.

 

Scenario:
User 1 from tenant A: Creates a OneNote Notebook. Shares with User 2 from tenant B (choosing share with specific user).

 

User 2 from tenant B: Receives the invitation. On opening they are redirected to "Request Verification Code" from Microsoft by clicking a button. They get the access code via email from Microsoft and enter the code. They are then able to access the OneNote Online.

 

The problem occurs when they click on "Open in OneNote". It behaves like it's going to open but then pops up wanting O365 credentials. User 2 enters their credentials and then gets an error message and is unable to use the notebook in OneNote 2016 (Professional Plus)

 

Image

 

My understanding is that this verification code is a new security feature of SharePoint. Could this be causing problems with opening OneNotes in the desktop version of OneNote? Seems that if a user isn't asked for a verification code on sharing that it seems to work ok. The inconsistency in experience in sharing OneNotes externally is causing a lot of problems in our sector and is putting people off using it.

 

Any advice would be appreciated.

Thanks,

Chris

_________

Thanks! Right now only external users with Guest accounts will be able to use the desktop applications of Office. We definitely hear the feedback about allowing ad-hoc external users (those coming in with verification codes) to open in the desktop apps but at this time do not have any dates to share for when that support will be added.

 

Until then, what we've done is hid the buttons in Office Online to open in the desktop apps for ad-hoc external users since they aren't able to use the desktop apps. That fix is in the process of rolling out.

Copper Contributor

@Rafael Lopez-Uricoechea Thanks for the advice. Yeah, it works after the external sharing is enabled.

Brass Contributor

I have been testing the functionality today and found some erratic behaviour.

 

As you can see in image 1, the '@gmail.com' and '@hotmail.com' email addresses are displayed with the 'This link works for these people' as expected. However, if I add an '@outlook.com' email address (image 2), this user now gets permissions directly attached to his user account (image 3). 

 

externalsharing.png

 

I can see this user as a guest in Azure AD, so I figured it probably existed as a guest user before sharing. I deleted the user from Azure AD, removed the permissions and shared again some 4 hours later. This did not change anything, same thing as above.

 

So then I created another guest user (**@outlook.com) in Azure AD and went on to share the folder with that user. The account is granted access via the e-mail but is listed with the "This link works for..." just like the others.

 

I'm at a dead end here as to why this one account got permissions assigned to the account directly as opposed to the rest who have the sharing link. Could this be related to the refresh cycle of the SharePoint User Profile Service? I'll try testing this out some more in the coming days but any pointers sure would help.

Version history
Last update:
‎Jun 25 2020 11:11 AM
Updated by: