Last week I gave a presentation at Microsoft Ignite – The Tour in Sydney. Here are the slides from that presentation.
Last week I gave a presentation at Microsoft Ignite – The Tour in Sydney. Here are the slides from that presentation.
One of the most important things when you implement adoption is to have a positive initial experience. This typically means ‘easing’ a user’s transition during the adoption process. If too many things are different, then there is much more likely to be a negative impression of the new processes. This slows adoption and at worst, can actually halt it in its tracks.
When moving to Microsoft 365, one of the most common things that a user needs to accomplish to be able to save and add attachments to emails. They have been performing this seamlessly using on premises file servers for years. They simply select to attach and then navigate to the file, attach it, then send. Easy.
Unfortunately, as I have documented before:
it isn’t easily done with SharePoint Online. This is really strange, given that SharePoint Online is the place where users should save and access common files in the Microsoft Cloud. Let’s take a look at the issues I’m taking about.
So an email arrives in my inbox on Outlook on the desktop, as shown above.
I want to upload this directly into an existing SharePoint stand alone Team Site, but as you can see the only option I have is my own personal OneDrive for Business or a range of Office 365 Groups and Teams that already exist.
Just to make sure I haven’t missed anything, I’ll select the More option at the bottom of the list.
Now I only have the option to save to a Group (which includes Microsoft Teams). So, let’s say I select the Sales Group (which is actually a Microsoft Team).
I’m now returned to Outlook. Where did that attachment actually go?
So, if I call up my Sales Team and rifle through all the file locations in Teams interface, I can’t find the file as you see above!
Turns out that the attachment I saved is placed into the root of the default Document Library in the Microsoft Team as you see above. But guess what? There is no way to actually see that unless I navigate to that location via SharePoint. I actually can’t see that attachment I just saved if I’m using the Microsoft Teams app! They all end up in the root of the Documents location, which isn’t accessible in the Teams app!
This means, that the only REAL solution for users to save the document to other locations in various SharePoint Document Libraries, is to firstly sync those destination locations to their desktop and then save the attachments the old fashioned way to the sync location so they will end up in SharePoint.
That means, to save or add attachments I firstly have to sync EVERY location I might want to save a file too!
Outlook Web Access is actually worse than the desktop client as the only options you have are to download or save to OneDrive for Business as seen above.
Interestingly, if I want to attach a file from a SharePoint site I can navigate to Browse Web Locations, select the Team Site I want
and I see a Windows Explorer pane where I can navigate to locate the file I wish to attach, just like on premises days. However, the look and feel here is pretty dated and requires Windows Explorer to be working and may pop up warning dialogs which will freak most users out.
When I use Outlook Web Access I can Browse cloud locations for an attachment
I effectively only see my OneDrive for Business as shown above.
These experiences leave a bad taste in the mouth for users, especially first time users grasping with the ‘modern’ way of working. They need to have an experience which is pretty much identical to the one they had on premises. Why can’t we simply save and add attachments directly from SharePoint Online Team Sites like we have always been able to do from on premises network file shares?
I’m seeing this end user frustration more and more in the field and was prompted to write the article to hopefully rally the masses to get a change enacted. So the best thing you can do is visit this UserVoice request:
and vote it up.
Next, tweet about getting this enabled to the following accounts:
I will be!
Perhaps I’m missing something obvious here and if I am please let me know but I don’t think I am. Help me raise awareness and improve Outlook so it is easier for users to adopt Microsoft 365!
If you are unfortunate enough to somehow get malware in your Office 365 tenant you may not appreciate that by default you can still download this, even though it gets detected as shown above.
Best practice would be to use the PowerShell command:
Set-SPOTenant –DisallowInfectedFileDownload $true
to prevent users from having the option to download the infected file. Basically, it removes the Download button as shown above. Doing this will apply the setting across all SharePoint Sites, including OneDrive for Business, Teams and stand alone site collections.
From the Microsoft documentation:
If the Set-SPOTenant cmdlet has the DisallowInfectedFileDownload parameter set to:
true (recommended), this happens:
All actions, except Delete, are blocked for detected files.
People cannot open, move, copy, or share detected files.
People see a visual cue that indicates that a file has been identified as malicious. No one can download the file.
false, this happens:
All actions, except Delete and Download, are blocked for detected files.
People cannot open, move, copy, or share detected files.
People see a visual cue that indicates a file has been identified as malicious, but they can choose to accept the risk and download the file anyway.
Allow up to 30 minutes for your changes to spread to all Office 365 datacenters.
The recommended best practice is then to turn this on for all tenants as it is not on by default.
I’ve been developing scripts to work with OneDrive for Business when I fell into a bit of a rabbit hole that lead me to an interesting revelation.
Part of the challenge with working with OneDrive for Business in Office 365 is that not all users have one, even though they are licenses for it. The reason for this is simply that a user’s OneDrive for Business isn’t generally provisioned for them until they start using it. Thus, in my demo tenant there are probably users who haven’t as yet been through the process of having a OneDrive provisioned. No issues.
Secondly, when you share information with external users in SharePoint and Teams you may also find an AD account but that user hasn’t as yet access SharePoint resources for some reason. Maybe, they haven’t accepted the sharing request and so on. Again, no big deal.
So I created a script that goes through each active Azure AD user in the Office 365 tenant and check to see whether there is a corresponding SharePoint Online user. To do this I used the following commands:
So I trained these commands on the OneDrive for Business URL which is typically:
As you can see from the above report, the green lines indicates matches to accounts in my Azure AD and in my OneDrive for Business. The green tenant users, with a custom domain typically have their own OneDrive for Business. The green External users, distinguished by an account that includes #EXT# are typically accounts outside the tenant that have been shared information with and accepted that sharing request.
Now the red tenant users, typically haven’t had their OneDrive for Business provisioned yet and the red external users typically haven’t accepted the sharing request that has been sent them as yet. All understood.
Here’s where the rabbit hole opened up. Ok, I thought, now what happens if I do the reverse? That is, check my SharePoint users against my Azure AD users? So off I went to create a script.
The script came back with the results you see above. All the the yellow accounts are SharePoint users that don’t have a match Azure AD account. Quite a few eh? When I first saw this I panicked a bit, because many of the accounts I didn’t recognize. What was going on here I wondered? Had I been compromised?
In a perfect world, there would be a one to one mapping between Azure AD accounts and SharePoint account. However, things aren’t that perfect, so in my demo tenant, I had created lots and lots of accounts over the years and many had become ‘orphaned’ leaving behind information in SharePoint. Many were just so old I forgotten that I created them and then later deleted the Azure AD account.
Is this a problem? Not really I don’t think, because without an Azure AD account to login to, these ‘orphaned’ resources aren’t much use. Still, if they aren’t needed then they really should be deleted to my mind.
Interestingly, some of these ‘orphaned’ SharePoint users actually still had their own OneDrive for Business that clearly wasn’t being displayed anywhere else. Once I took control of these ‘orphaned’ sites by making myself a Site Collection Administrator I could see what they actually contained. When I was happy it wasn’t needed or in use I deleted these, again using PowerShell.
So what did my trip down the rabbit hole teach me? Firstly, I learned that Azure AD and SharePoint user accounts don’t always line up. Next, I learned that you can end up with ‘orphaned’ SharePoint users and resources that you may want to clean up using PowerShell. I don’t believe these represent any security issues but if they aren’t necessary then they probably should be deleted. However, be careful of system accounts which shouldn’t be removed. Just get rid of those you recognise as no longer being required.
The biggest thing that my exploration taught me is the value of PowerShell to get behind the standard interface of Office 365 and see what is really going on. It gives you much better control and for me it helps me understand much better how everything works.
If you want the scripts that I used to do these comparisons then I suggest you sign up to my Patron community – www.ciaopspatron.com where you’ll find these and whole lot more Office 365, Microsoft 365 and Azure resources.
One of the common beliefs with Office 365 is that OneDrive for Business storage for most plans (typically Business plans) is limited to 1TB per user. Well, I’m here to tell you that the limit for most tenants is in fact 5TB per user. Don’t believe me? Well, read on and be AMAZED!
You can see from the above that the user has the standard 1TB storage for the OneDrive for Business.
The ‘normal’ way that you set the amount of storage each user gets for their OneDrive for Business is via the Storage option in the OneDrive Admin console as you can see above.
Now, if you visit the link just below that setting you will see the following:
Here’s the full link:
Thus, if you have more than 5 users (and perhaps less) you can get 5TB per user OneDrive for Business.
These days, I prefer to do most of my administration using PowerShell. The above script will set the new limit for all users provisioned with OneDrive for Business from this point on to have 5TB of space in their OneDrive for Business.
To increase any existing users OneDrive for Business up to the 5TB limit you’ll need to run the above script for each user. You’ll need to replace the URL with each users individual OneDrive for Business URL.
After doing this, if you now look at the users OneDrive for Business storage quota, you’ll see it is now 5TB!
Magic eh? And you thought I couldn’t give you free GB’s out of thin air! Shame on you.
I recently wrote an article about
that ran through the process of what happens when users go offline when working on shared files.
After doing some more poking around in the latest OneDrive for Business sync client I found this under the Office tab in Settings:
You can find more information on the first option here:
If you turn off this setting, Office will no longer be able to automatically merge changes from different versions of documents. You’ll also be prompted to upload a new copy of a file before you can share it directly from an Office desktop app.
You can also elect how to handle Sync conflicts, which by default is set to Let me choose to merge changes or keep both copies.
The defaults options are going to suit most people but you can go in a customise these if you wish to improve how conflicts are handled in your environment.
It has been over three years since I wrote an article about file conflicts in Office 365 –
and as you can appreciate a lot has changed since then. Probably the biggest change is that we now have File on Demand and the ability to sync SharePoint Document Libraries. However, there will always remain challenges around shared files going offline when multiple people continue to work on them.
I will preface all this by saying that it is best practice to ‘Check Out’ any files you wish to use prior to you going offline. Doing so will ensure you have exclusive write access to that file while you are offline and until you check that file back in.
Of course, not everyone is going to follow best practice and we are going to end up with the following scenario.
Let’s say that Lewis Collins (user 1) creates a new Excel spreadsheet called conflicts.xlsx in a SharePoint Document Library as shown above.
If Lewis opens that file using Excel Online and makes a change by adding the entry ‘Online 2’, as shown above, it is automatically saved back to the SharePoint Online Document Library.
A second user (Robert Crane – user 2) used OneDrive Files on Demand to sync a copy of that same file to their desktop as shown above.
This second user (user 2) now opens the file using Excel on desktop and makes changes to the file by adding the entry ‘Offline 3’ as shown.
You can see that because the user is still connected to the Internet any changes are automatically synced back to the SharePoint Online Document Library.
So, while everyone is online all changes are updated into the one location.
We can also look at the version history of the file and see all previous versions thanks to automatic version history in SharePoint Document Libraries. We can roll back or view any of these if we wish.
At this point, user 2 (Robert Crane), goes offline and is no longer connected to the Internet.
Now because user 2 didn’t check the file out prior to going offline, user 1 can continue to edit the file. They do so adding the entry ‘Online 4’ to the file, which is then immediately saved back to the SharePoint Document Library.
While offline, user 2 adds a new entry to their offline version of the same file. Here they create an entry ‘Offline 4’ as shown above.
Thus, we now have a situation where the file in SharePoint Online is different from the file on the users desktop. This will clearly create a conflict when user 2 return online.
User 2 comes back online and at the next sync is informed of a conflict as noted in their file manager as shown above.
When user 2 attempts to open the file in conflict they are presented with the warning banner at the top as shown. They are given the option to either Save a Copy or Discard Changes.
If they select Discard Changes, any updates they have made to the file while they have been offline will be overwritten with what is currently in SharePoint Online. Once they select this, any updates they have made to the file while they are offline will be lost and the copy they have on their desktop will be the same as what is currently in SharePoint Online. In short, their local copy is overwritten with that from SharePoint Online. They can’t recover their original file after this happen because the file they changed was only saved to their desktop.
If they select Save a Copy, the file they have changed will be uploaded to SharePoint Online replacing the current version in SharePoint Online.
The OneDrive sync client will then kick in and copy the file from user 2’s desktop to SharePoint Online Document Library replacing the version that others have been working on and potentially removing changes they have made.
When the sync is complete, user 2 should see the same situation on their desktop, as shown above, prior to going offline.
Now, the file that was changed by user 2 while they were offline has become the primary file in SharePoint Online and on desktops. However, any changes that user 1 made while user 2 was offline are no longer in the most current version of the file.
Before we tackle that situation let’s look another experience for user 2 as they come back online with a different version of the file.
When user 2 comes back online with a different version of a file they will also see the system tray icon for their sync client display a warning as shown above.
If they select this the sync client will open and display a conflict message as shown above.
Clicking that message will show them greater detail on the conflict as shown above.
If they click to resolve the issue they will be presented with the above dialog providing two options.
The option Open in Office to merge changes will simply open Excel and take the user through the experience detailed above, i.e. save a copy or discard changes.
The second option Keep both files will rename the changed version on the desktop to conflicts-.xlsx. Thus, the original file they were working on offline will be renamed and the newer version that is in SharePoint Online will be downloaded to the original name on their desktop. The idea is basically to create a second copy of the file, rather than overwriting the original. Users would then need to open both files and manually merge any changes back to a single file. The end result here is two files with different names, each holding the unique changes made by each user.
Let’s return to the situation where user 2, who was offline, comes back online, opens the file in conflict and selects to save their copy back into SharePoint Online by using the Save a Copy button.
This means that any changes user 1 made to the file while user was offline are ‘lost’ because user 2 has overwritten the file with their version.
However, don’t forget that SharePoint Online Document Libraries include automatic versioning. This means that when user 2 uploaded their file, the file user 1 had been working on isn’t deleted, it is simply saved as a previous version. So, both files are still in SharePoint Online in full fidelity. One is current and one is the previous version.
You have the ability to compare previous versions or restore previous versions if you wish.
My experience is that Excel is a fairly complex program and in most cases you’ll have to manually merge any changes between the two documents. However, as you can see above, with Word the application can generally merge changes automatically for you using the revisions ability built into the program.
As I said at the beginning of this article, best practice is to check document out prior to going offline to avoid conflicts. If that doesn’t transpire, then you probably need to manually merge changes using versions in SharePoint Online. However, as you can hopefully see SharePoint Online will retain both versions of the file if you do go offline. I would suggest however, you have a play with exactly how this works in your environment prior to requiring it. SharePoint is magic but it doesn’t read minds, yet!
This quick lesson will show you how to access and use the OneDrive for Business admin console in your Office 365 tenant. You’ll also see the control you have as an administrator to manage individual users OneDrive for Business.