Restrict access to OneDrive for Business

Edit: A new admin centre for OneDrive has been launched as of December 2016, and allows for much more granular control over what can be synchronised, and where from. Check it out at

A question which I get asked quite frequently is whether OneDrive for Business can be blocked, locked down, or restricted. Whatever your reasons for doing this, there are some things you can do to restrict access.

As a little bit of background information, OneDrive for Business is not the same as your personal OneDrive, and is essentially your own private SharePoint library. If you have no plans to use SharePoint Online, then the easiest way to block access to OneDrive for Business is to simply remove the SharePoint Online license from the users in question. This is done in the sub menu of the licensing options for a user and can be applied on a per user basis.

SharePoint License

Another thing you can do is to hide the OneDrive button from the portal. This is done under the SharePoint Admin section of the Office 365 portal, under the Settings Tab. This setting applies to all users.

Hide OneDrive for Business

With this option selected, OneDrive will not show up in the Portal menu, along with the Office Web Apps.

Hide OneDrive for Business

We can also stop users from being able to create a personal site at all, by going into the User Profiles area of the SharePoint admin center. Go into Manage User Permissions and remove ‘Everyone except external users’. This will stop any users from being able to create their own OneDrive for Business sites. If you like, you can then add users or groups into this list who you would like to be able to create a OneDrive for Business site.

Personal Site Lockdown

This doesn’t stop any users who have already created their OneDrive for Business sites from accessing it if they know the direct URL or have added it as a favourite into their Internet Browser. I won’t be covering that scenario here, however if this is something you would like more information on, let me know in the comments and I will put a post together!

Microsoft inTune – Mobile Device Management Authority set to Office 365

Well that is a mouthful of a title! Microsoft have now fully rolled out their Mobile Device Management features in Office 365, and I decided to kick the tires and find out more about what it could do. This involves enabling the MDM service from within Office 365.

A couple of weeks after this, I needed to do some testing with Microsoft inTune, the big brother of Office 365 MDM. I signed up for the 30 day trial, and went through the process of ticking off the pre-requisites of the intial deployment. One of these steps is to set the Mobile Device Management Authority. This settings defines whether you will integrate your inTune subscription with System Center Configuration Manager or not. This is a decision which is very difficult to reverse once done, but for my purposes I wanted to configure inTune itself as the Mobile Device Management Authority, and not integrate with SCCM.

However I was not able to do this as when I visited Admin>Mobile Device Management, I was told that my MDM Authority was set to Office 365. There was also no option to change this. I ended up having to log a call with inTune support, who responded very quickly and reset the MDM Authority so that I could set it. It took around 5 days for the reset to be processed. Once it is complete you can set the MDM Authority to inTune or SCCM!

MDM Authority

I can see this catching out a lot of customers who are using the built-in Office 365 MDM and decide to upgrade to use inTune. Just keep in mind that you will need to reset your MDM Authority by logging a call with inTune support, and this will take 5 working days. It’s also worth noting that before resetting your MDM Authority, you need to retire all current mobile devices from Office 365 MDM. This is best done by performing a selective wipe from the Mobile Devices tab of the Office 365 admin center.

I hope this helps some of you out there who are looking to move from the built-in Office 365 MDM to Microsoft inTune.

Exchange Server 2016 Announced at Ignite!

Exchange Server 2016

Great news for all you Exchange consultants and architects out there. A whole new version of Exchange is on it’s way for us to learn about and deploy!

The Ignite 2015 conference played host this year to the announcement of Exchange 2016 as the on premise successor to Exchange 2013. This new version will be released in the latter half of 2015 and has a few notable changes / features added:

  • The Client Access role has been removed completely. In Exchange 2013 the Client Access role was simply an intelligent proxy service and had no real involvement in traffic other than proxying it to the correct location. Now clients will connect to client access services (running within the Mailbox role) and those requests are routed to the Mailbox server holding the active database for that mailbox.
  •  Search has received various improvements, primarily to performance, which was a bugbear in Exchange 2013 due to the slowness of search in Online mode and OWA in particular.
  • Document Collaboration is Microsofts headline feature. This will leverage Office Web Apps and SharePoint servers, and potentially Microsoft Online Services to allow for document versioning and collaboration within the attachment mechanism in Outlook/OWA. In essence, a user can attach an item to an email and not have the issue of dealing with manually merging multiple versions of the same document. This versioning will be handled automatically.
  • Outlook Connectivity will now be handled by MAPI/HTTP by default. This connectivity protocol reduces bandwidth and latency requirements and provides a more stable Outlook experience.
  • Coexistence with Exchange 2013 is going to be a hoot. When deploying Exchange 2016 in your environment, you will not need to move the namespace in order to migrate mailboxes as there is backwards compatibility with the Exchange 2013 namespace model built into Exchange 2016. This means that it will be simple to introduce Exchange 2016 into your environment and start using it in anger. You will still need to migrate this namespace eventually but when you do this is up to you!
  • Hybrid functionality will, of course, be improved, allowing for customers to more easily decide which parts of the component stack they want to remain On Premise and/or move to the Cloud.

Armed with the information we have so far been furnished with, I think that we can all look forward to a more simplified and powerful Exchange On Premise experience. Microsoft must have learned a lot from running the largest Exchange Organisation in the world in Office 365, and I hope that all the On Premise environments around the world will benefit from their lessons learnt.

ExpressRoute for Office 365

It’s Ignite week this week, and although I’m disappointed that I’m not able to attend, I will be doing my best to keep abreast of all the Office 365, Exchange and Azure news!

The best piece of news so far, particularly for larger Office 365 customers, is the announcement of the ExpressRoute Service Providers for Office 365. This technology provides a private, managed connection to Office 365, giving you the equivalent of a direct MPLS connection into Office 365 datacentres. Multiple links can be used to provide redundancy, however each ExpressRoute circuit provides 2 active physical connections for built in redundancy.

This service will be available starting this Summer, and initially in the UK BT will be the only provider able to offer ExpressRoute for Office 365, however this will be expanded in the months following General Availability.

The full provider list for the UK at the time of writing consists of:

BT / Colt / Level3 / Orange / Tata / Verizon

More information is available on the Office Blog:

The perils of deleting a Shared Mailbox user account

The world of IT is a perilous and dangerous place to be. Particularly when your mouse is hovering over that ‘Delete’ button.

I came across an incident recently where a user had left a company, and as per standard practice for leavers in Office 365, their mailbox had been converted to a Shared Mailbox to free up the license whilst preserving mailbox access for their manager. As this mailbox was now Shared and the user was no longer present, the administrator deleted the user account in question out of Active Directory. The effect of this was that the user and mailbox in Office 365 was also deleted. This behaviour is something worth remembering if you are the administrator of an Office 365 environment.

I could see that the mailbox was listed in the Office 365 ECP under Recipients>Mailboxes>…>Deleted Mailboxes therefore it was recoverable. I went for the Recover option and was faced with the error:

'User not found'

Uh oh. Usually this process would recreate the MSOL User account along with restoring the mailbox. I checked in the Office 365 Admin Centre and the user had not been recreated, however if I went to the ECP and Recipients>Shared I could see the restored mailbox. Unfortunately though, the mailbox was only half there and the details pane showed no email address, just ‘the items you’re trying to open couldn’t be found’:


My mailbox was stuck in limbo! I went into Powershell for Exchange Online and ran Get-Mailbox, but the Shared mailbox wasn’t listed. I then ran Get-Mailbox -SoftDeletedUsers and the Shared mailbox wasn’t here either. This wasn’t looking good.

I was concerned that if I deleted the limbo mailbox then I would lose it forever, but I had no choice but to try. I got another error message ‘User not found’ when trying to delete the mailbox but after a minute or two it showed up in Deleted Mailboxes and when running Get-Mailbox -SoftDeletedUsers it also appeared. Hurrah!

My mantra whenever I work with Exchange, online or on premise is that if something doesn’t work in the GUI, try it in Powershell. So I ran the command shown below to try and recover the mailbox, and by the Power of the Shell, it worked!

Undo-SoftDeletedMailbox -WindowsLiveID -Password (ConvertTo-SecureString -String ‘Passw0rd’ -AsPlainText -Force)

In my opinion, this looks like a GUI based bug when recovering a Shared Mailbox. User mailboxes restore without a hitch, but Shared Mailboxes are not so friendly via the GUI. The answer, as usual, is the mighty Powershell.

Sharepoint Online Sharing Emails – Rejected / Bounced / NDR

If you have a 3rd party mail security system, or you have locked down Office 365 inbound mail flow, you may notice that when you attempt to share something with an internal colleague in SharePoint Online, the sharing invitation NDRs and gets bounced back. If your mail goes direct to Office 365 and you have configured an Inbound Connector in order to lock down inbound mail (eg to only allow Mimecast to send mail to Office 365), you may see the following error:

Your message wasn't delivered because the recipient's email provider rejected it.

Alternatively, your 3rd party mail hygeine product (in my case, Mimecast) blocked the message before it could get to Office 365 with a slightly different error:

Remote Server returned '< #5.5.0 smtp;550 Administrative Lockout - Inbound not allowed >'

The reason for this error is because the SharePoint Online service is spoofing your email address to send the sharing invitation. If we look more closely at the source server name, we can see that, in my example, the email came from DB4.MAIL.YLO001.MSOPRD.MSFT.NET, which is one of Microsofts own SMTP servers (probably running MDaemon ;-D). The email is coming from a Microsoft SMTP server and is using one of your own email addresses. Not many email services will like this, particularly mail security services such as Mimecast or MessageLabs if this is where your MX records point. To get around this, you will need to allow the SharePoint Online IP address ranges to send using your domain name.

If your MX records point to Office 365 and you have an Inbound Connector configured for locking down inbound mail flow, then you can connect to Exchange Online Powershell and add the SharePoint Online IP addresses to your connector:

First, run Get-InboundConnector | fl and note down the existing SenderIPAddresses. In this example, I will use for demonstration purposes.

Then run the below command to change the IP addresses assigned to the connector. Make sure you include the IP addresses of the mail system which your MX records point to, or you will end up not receiving any mail at all!

Set-InboundConnector -Identity "Connector Name" -SenderIPAddresses,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

The list of IP addresses above is all of the SharePoint Online IPs at the time of writing, however this is subject to change and should be checked by yourself prior to running this command. You can check the list of IP addresses here:

In my case the problem was actually with my Mimecast configuration, not Office 365. In Mimecast there is an Inbound Lockout Policy section under Gateway>Policies. The policies configured here say that any Inbound messages from our domain name should be dropped by the firewall. This stops spoofing and is a default policy. To stop Mimecast blocking messages from SharePoint Online, I created a new Inbound Lockout Policy which did not block emails to my domain name when the Sender IP address was one of SharePoint Online’s IPs. This rectified the problem.

Locking down mail flow does have many benefits, but simplified administration is not one of them unfortunately!