I ran into this issue when migrating users to Exchange Online, while running Outlook 2016 MSI 32 bit.
Once a user is on Exchange Online, Outlook starts leveraging the power of FAST search. This search occurs on the Exchange Online end, rather than the device end, and is designed to give quicker results while being more reliable than Windows Desktop Search. There’s a great write-up on this on Microsoft’s TechCommunity that goes into much more detail.
It does depend what sort of search you do as to whether it’ll use FAST or Windows Desktop Search too, but the most basic of searches will use FAST. There’s also timeouts and speed checks that can force it to fail back to Windows Desktop Search.
However, there are some catches with this search from my testing. If you do an email search and decide to delete one of the emails in the results, it appears that nothing has happened. You can delete and delete, right click, press the delete key, click the X to delete and it all appears to do the same – nothing. In the background though, it has actually deleted your email, it just doesn’t display this in any way. It’s like the search results are a static result and won’t update on an action like this.
This behavior can be confusing for a user, especially when they’re used to seeing emails disappear and react when something’s done to them.
There’s another catch that depending on your environment, might be more of a deal breaker. If you use the category field, flag, or extra fields, for example when filing a document into a DMS system, those aren’t displayed or updated in a FAST search. If your users need this to effectively manage their emails, then it’s worth looking at just disabling FAST search via Outlook altogether.
As mentioned in the above post and this Technet article, there’s a single registry setting that can disable FAST search:
A restart of Outlook is needed after this change, and users won’t be alerted of anything different. Search will just start using Windows Desktop Search (which was always running anyway) and not know any better.
Worth reading the entire thread, but it turns out unknowing cleaners seem to have cause a lot of outages!
I’ll let the responses speak for themselves:
I had a WinNT cluster that held elections every Thursday night. We stayed late two weeks in a row: no elections. Skipped a week: elections. One Thursday we came back after a drink… and watched the cleaner carefully unplug the server and dust the power bar.
Early in my career I was sent to solve the mystery of a small remote site going down every weeknight about the same time. Dutifully I sat in a small office watching a comms cabinet till 6:30pm when a cleaner walked in and attempted to unplug the cabinet to power his vacuum!
The Network goes down every saturday at almost the same time and after 15 minutes it worked again. After months of troubleshooting… it turned out that the Cleaning Service used the socket of the network cabinet to plug in the vacuum cleaner…
Worked for for a communication company and offices in a region kept losing network connectivity then a couple minutes later would come back up. Found an engineer “cleaning fiber connections” in the MDF unplugging them one at a time.
I’d be hoping these incidents happened a while ago, but in reality it’s a good demonstration of how things can happen that you really didn’t plan for. It’s also a good argument for having your important gear in a secure room!
If you’re managing OneDrive for Business in your organisation, there’s a lot to consider – more than what you’d think until you start looking into it. I’ve just gone through this, so thought it was a good time to document and share what I found with my recommendations.
There’s two major areas to review settings in:
admin.onedrive.com
You may not know this even exists as it’s still in preview, as OneDrive for Business fully functions without ever having to go here. The OneDrive admin center at https://admin.onedrive.com/ has some nice settings worth checking out. Some of the settings were already available in other areas, but this gives a central point to manage them.
Sharing: Under the Sharing section, there’s a few settings I’d recommend changing. The defaults are much more open – allowing users to create shareable links that don’t require a sign-in (which is really a bad idea when you’re sharing work information!), as well as the default link type being ‘Shareable: Anyone with the link’.
I’d recommend having the default ‘Direct: Specific people’ when sharing a link, and restricting the ability to have anonymous shareable links at all. This way ensures that data only gets shared to the people the end user chooses, and nobody else.
Sync: ‘Allow syncing only on PCs joined to specific domains’ is off by default, and you’ll need to look up your domain’s GUID to enter it in. This is good for data leakage, do you really want someone’s home PC automatically downloading all work data? This won’t block them from accessing OneDrive information at all as it’s available via web and Android/iOS apps, but none of those solutions automatically sync content. You can also block Mac OS if you don’t manage any in your company.
There’s also the option of blocking syncing of specific file types – I can’t think of a particular reason for this though. OneDrive already has AV built into it, as does your PC with Windows Defender, AND you should have Applocker in place to block running unwanted executables… but it’s still worth noting the option.
Storage: The default ‘Days to retain files in OneDrive once a user account has marked for deletion’ might be missing a word, but it’s default value is 30. You can go all the way up to 3650, which is 10 years minus a few days for leap years. I don’t have to worry about this data or pay extra for it, so I’d rather have it retained just in case.
There’s also another option where on departure, the manager based on the AD/AAD field of the departing user will be granted access to their OneDrive, which is a nice automated way of having someone check the contents in case anything needs to be saved out. That setting lives in the SharePoint Admin center, fully described in the above link.
Device Access: Worth noting that you can restrict access from certain IP addresses, but in the real world I don’t see many companies doing this unless you really want to keep your OneDrive data internal.
There are other options in the OneDrive for Business Admin Center, but nothing I personally considered changing.
Group Policy
This is probably where you’ve already started. Make sure you’ve deployed the latest ADMX files, and review all the settings. Here’s the key ones I’d recommend looking at, some are computer based and some user:
Enable OneDrive Files On-Demand: This makes just the stubs of files download to the OneDrive client, then download the full file when requested. There might be some pushback on not having instant access to a file when wanted, but when you tie this into Known Folder Redirection (below) and have users that move around a lot, this should save bandwidth and disk space across your fleet. I have this one enabled.
Prevent users from using the remote file fetch feature to access files on the computer: I’d definitely have this one off as it lets users access the entire contents of any PC they’re signed into (where their account also has access to the local files of course), remotely. It could easily lead to data leakage when you’re opening up such a big door.
Delay updating OneDrive.exe until the second release wave: If OneDrive becomes important to your users (which it should, yet again with Known Folder Redirection), then you probably want to avoid getting a new release that has a bug. Sit back and wait for the second release wave to make sure you’re getting a more stable update each time. Enabled with maybe a few users having this Disabled for piloting/testing.
Prevent users from synchronizing personal OneDrive accounts: I enabled this one, as with the above settings I’ve already allowed a method that users can get and work on the files they want from anywhere. I can also monitor this and produce logs if required. Someone’s personal OneDrive I have no visiblity or control over, and there’s really no need to allow this.
Silently move Windows known folders to OneDrive: Once you’re ready and fully deployed with OneDrive, this is the next great feature to check out. It deserves it’s own blog post later, but you can silently configure the user’s Desktop, Documents and Pictures folders to live in OneDrive, rather than the local PC. This lets users access the same data wherever they log into, with the extra benefit of doing it in the background after the user logs in – no login delays. It’s like having an important part of roaming profiles, without the headaches. More info here: https://docs.microsoft.com/en-us/onedrive/redirect-known-folders
If you’d originally disabled OneDrive via GPO through the policy Prevent the usage of OneDrive for file storage then just disabling that policy should be enough, as long as you still have OneDriveSetup.exe running at login via the Run registry hive against the user. If you removed that, you may have to add it back in.
I found this method to be useful – to create the value HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Run – Reg_SZ value type OneDriveSetup with value data C:\Windows\SysWOW64\OneDriveSetup.exe /thfirstsetup – but only applying this if the OneDrive registry value didn’t exist. OneDriveSetup should remove itself if successfully run, and will also create OneDrive meaning the setup key won’t get put back again.
If you see what a new user gets the first time they log in assuming no OneDrive cleanup has happened, is the exact same OneDriveSetup key as above. In my testing, having other switches against OneDriveSetup caused issues.
This is just a quick one. Most Office 365 admins will hopefully have a separate admin account to perform higher level tasks, compared to their normal user account.
Because of this, the admin accounts shouldn’t need any licensing, because they’re not being used like a normal user. One person shouldn’t need to have two sets of licenses – but there are some problems that can come up because of this.
For example, if you want to use your admin account to access someone’s mailbox, that can be difficult when you don’t have a mailbox yourself to log onto, to then open another user’s mailbox. Outlook can be used to work around this, where you set up a profile for the email address of the user you want to access, but enter your admin credentials when prompted:
Your Name is just a display name field, email address needs to be the user’s email. Don’t enter a password here and click ‘Next’
This login page will start by showing the user’s email address, use the option ‘Sign in with another account’ and use your admin account.
The above works OK, but is a little time consuming if you’re accessing a mailbox for a quick check.
If you try to go to Outlook Online, you’ll get a message saying your admin account doesn’t have a license or a mailbox. To get around this, you’ll need to use a URL like:
This had been on my to-do list for a little while since I heard about it (mostly from Daniel Streefkerk who quite rightly has been drawing attention to this via Twitter, thanks!)– and it should be on yours too.
By default, Basic Authentication is allowed as an authentication method in Exchange Online. This is because that’s the ‘standard’ way things have worked for a very long time – you want to get your emails, you provide a username and password and you’re done.
In our modern world, that doesn’t work too well anymore. It’s too risky in that many ways, and things like 2FA and Conditional Access add an extra layer of security when logging in. That’s great, but many systems weren’t built or haven’t been updated to support this – they’ll just fail when logging in.
What this leaves us with, is an internet exposed authentication system that accepts username and password logins without any other layers of authentication, even if you have 2FA and conditional access turned on.
As per Microsoft’s documentation around disabling basic authentication covers, this lets attackers use brute force or spray attacks to try different credentials to get into your tenant. With the amount of leaks we see these days (register on Troy Hunt’s https://haveibeenpwned.com/ if you haven’t already), it’s likely attackers are hitting Microsoft servers with correct accounts of your staff members. If they manage to get the right password – which is very possible if people end up using an old password they used years ago, or password changes were disabled because you thought you were covered with 2FA – they now have valid credentials to get in and pretend to be that staff member, often to then send emails to all their contacts with a malicious link or some other scam.
If you want to see what’s going on for your tenant, go to the Azure portal and into Azure Active Directory > Monitoring – Sign-ins. Set the Status to ‘failure’ and apply, and see what’s there.
Here’s an example, where you can see the client app is ‘Other clients, IMAP’. This account is disabled, and if you look in the device info there’s no data.
Once you have a look here, you might start to get worried – so it’s time to see if you can disable basic auth!
Only certain email clients will work without basic auth, so your first step is to work out what people are using, and get approval to force the usage of only these:
That can be a tough ask, and you’ll need to weigh up the risk of leaving basic authentication in place (to me this is an easy choice, but can still be difficult to get approved and implement).
Again, the Microsoft documentation explains how to do this quite easily – create a new Authentication Profile which has Basic Auth disabled by default, and apply it to test users:
That’s all you need to do to test. The third command forces an immediate refresh on the test user.
I would recommend leaving this in place for a while, and get as many test users on as possible as you might find certain systems using basic authentication that you weren’t aware of.
If you need to drop the policy off of a user, use this command:
And with that, you’ll have all existing and future accounts protected from the risks of leaving Basic Auth enabled. Of course if you have a special requirement where a few accounts do need Basic Auth, create another policy, enable basic auth on it, and apply it to those accounts. Your attack surface will still be greatly decreased, and hopefully you’ll eventually be able to disable basic auth on those too.
There’s also now a Conditional Access option that supports ‘other clients’ – “This includes older office clients, other mail protocols(POP, IMAP, SMTP, etc), and ACS”. This might help you if you either want to block those older clients, or allow them through in certain circumstances:
