Remote Mailboxes in Exchange Hybrid configuration

I’ve been asked a few questions recently about Remote Mailboxes in Office 365 hybrid configurations. The Remote Mailbox exists on the On Premise Exchange server and is the link between the Office 365 mailbox and the On Prem Exchange Organisation. Without one of these for each Office 365 mailbox, you can’t effectively manage certain Office 365 mailbox properties, you can’t offboard it back to the On Prem Exchange Server, and most importantly, not having a Remote Mailbox breaks mail flow between users On Prem and users in Office 365.

Quite often, when administrators first start using Office 365 in Hybrid mode, they will create a new user simply by creating the AD account, synchronising it using DirSync/AADSync, and then licensing the user. This will give you a mailbox in Office 365, but will also cause the problems listed above. The correct way to provision new users in Office 365 is to create new Remote Mailboxes. If a Remote Mailbox isn’t present or has been accidentally deleted, you can create one and link it up to the Office 365 mailbox.

To do this:

From Exchange Management Shell (On Premise):

Enable-RemoteMailbox username –RemoteRoutingAddress

The RemoteRoutingAddress is always in the format of, for example:

Enable-RemoteMailbox joeb –RemoteRoutingAddress

You then need to get the Mailbox GUID of the Office 365 mailbox. To do this, go into Office 365 PowerShell and run:

Get-Mailbox –Identity emailaddress | fl Identity,ExchangeGUID

Copy the Mailbox GUID into your clipboard and go back to the Exchange Management Shell (On Premise):

Set-RemoteMailbox username –ExchangeGUID 8e992097-24c1-432c-8a89-98e3c7a7d283

Anything in italics needs to be changed to a parameter relevant to your requirements. Once you’ve completed this, perform a delta/incremental sync and the two shall become one (so to speak!)

There is a KB article from Microsoft on a similar issue (trying to Offboard a mailbox where the Remote Mailbox GUID is not the same as the 365 GUID) here:

Thanks for reading 🙂

Office 365 – MFA support for the Windows Office 2013 suite on it’s way!

Great news for users of Office 365 Multi Factor Authentication! Office 365 MFA is soon to be fully supported in the Office 2013 Windows client applications.

At the moment, MFA only supports web based applications like OWA. If you have MFA enabled and want to use rich client applications such as Outlook 2013, you have to use an App Password. This is a randomly generated 16 digit persistent passcode which is assigned to an individual application, such as Word 2013.This provides a higher level of security than a user specified password however is not as secure as true MFA.

This new functionality will pave the way for customers making use of the integrated Office 365 MFA authentication. Especially considering that it is totally free to enable!

Currently the update is only available to those people taking part in a Private Preview, however interested parties can keep their eyes on the Office 365 roadmap at to find out about release dates for this update.

Office 365 – Outlook Profiles in a Cutover Migration

One of the drawbacks of performing a cutover migration from an On Premise Exchange environment to Office 365 is that Outlook profiles must be recreated to connect to the Office 365 servers. If done manually on every single workstation in your company, this could be a very time consuming process as you would have to create a new profile, set it as the default and configure it for the user.

One way of automating some of this process is to use Group Policy to run a script to create a new, blank Outlook profile and set it as the default profile. The user will then be presented with the first time profile setup screen when opening Outlook and should be able to use Autodiscover to automagically find their new Office 365 profile settings:

Outlook New Profile SetupOutlook Configure Profile

Outlook Profile Complete

To create the batch file required to do this, copy and paste the following text into a file and save it as a .bat file:

For Office 2010:

reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\O365"
reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles" /v DefaultProfile /t REG_SZ /d "O365" /F
reg add "HKCU\Software\Microsoft\Exchange\Client\Options" /v PickLogonProfile /t REG_DWORD /d "0" /f

For Office 2013:

reg add HKCU\Software\Microsoft\Office\15.0\Outlook\Profiles\O365
reg add "HKCU\Software\Microsoft\Office\15.0\Outlook" /v DefaultProfile /t REG_SZ /d "O365" /F

The script will create a new profile called O365 and set it as the default profile. Create a new Group Policy object to run the .bat file in Group Policy Preferences. You can safely leave the GPO in place for a few days to allow for people who may not be in the office for your go live day as it will not overwrite or remove existing profiles.

When this process in used in conjunction with the Group Policy for controlling Autodiscover ( you can have a 80% automated cutover migration which should be smooth sailing for yourself and your users!

Thanks to my colleague Kevin for sharing his experiences and allowing me to blog about this.

Cloud Security 101

With Microsoft, Amazon and Google currently enticing businesses and consumers into cloud services with promises of resiliency, scalability and simplified administration, many companies are quite rightly moving services and data into the cloud in some way or other.

Before making such a leap however, questions must be asked about data security and compliance. Cloud services must be scrutinised in order to ensure that data geo location and security practices meet compliance requirements for the customer and their clients. After all, you are trusting these providers with your essential business data, and in some cases your intellectual property.

Edward Snowdens leaks regarding NSA/GHCQ snooping, along with the leakage of personally identifiable information from services at Sony, eBay and the like has left many people suspicious and wary of who exactly can get to your information. This blog post is here to show you a sample of the security features used to protect your data in Office 365 and Azure, and some of the ways your data is protected in transit.

Office 365 Security

The Office 365 service provides many layers of security. Microsoft want to be seen as a safe pair of hands to help drive adoption and for this reason they have the interests of security and privacy at the very top of their lists of priorities.

The data in all Office 365 services is encrypted at rest using BitLocker and in addition to this, as of November 2014, all Office 365 data is encrypted again on a per file basis. This means that each individual file is encrypted using different keys, which are stored in an alternate location to the master key.

All Administrative actions taken on Office 365, either by the tenant administrators or the service administrators, are audited and fully transparent. As an Office 365 customer, you can view and export a list of Powershell commands run by Microsoft Support or your own administrators. Microsoft support technicians are given administrative access when required based on the least privilege model, and this access is time limited by default.

Data theft from inside or outside of the service is a serious concern to Microsoft and the Office 365 team work on the assumption that a compromise has already been made. A Red team exists whose sole job is to attempt to compromise the systems protecting customer data. They do this by attempting to gain access to test data, and a Blue team works in parallel to identify the Red team and counteract this threat. This is the equivalent of having your IT systems constantly penetration tested, which is more than most companies can say for their own IT systems!

Compliance in Office 365 is a hot topic and is critical to getting governmental departments, and health and financial companies on board. Office 365 are compliant with many of the standards required in these sectors, such as ISO 27001, FISMA, and HIPAA.

All of these security features help to make Office 365 a platform which is likely to be far more secure and compliant than your own On Premise environment. Microsofts transparency on security and privacy are also far superior to any of their rivals, giving you the peace of mind needed to begin your move to the cloud.

Much more information can be found at the Office 365 Trust Center –

Azure & Microsoft Datacentre Security

The Microsoft Azure IaaS environment should be considered by customers as an extension of their Datacentre. Microsoft are staunch supporters of the concept that the data you place in cloud services is your data, not theirs. Encryption is in place across all servers, and nobody with physical access in the Datacentre has knowledge of which customer’s data is in which rack or server.

Direct access to the Azure Hypervisors is unavailable to customers and network isolation is used to separate traffic between tenants. There are also various methods customers can use to increase the privacy of their Azure traffic, such as using Azure Private Virtual Networks and Azure ExpressRoute, which creates a direct connection to Azure, keeping your inter-site traffic off the Internet.

The physical environment is highly secured and access is extremely limited by using separation of duties and roles to make sure that no one person has too much knowledge of the systems. Failure to abide by the Microsoft Datacentre security policies means instant dismissal for the employee. In addition to this, personally identifiable information is stored separately to non-personally identifiable information.

All access to customer data is blocked by default, using a zero privileges policy. If this is allowed, it is time limited and fully audited. In addition to this, staff members who receive this access to customer data will not have physical datacentre access. These same physical and data based access controls are also in place for the Office 365 and all other Microsoft Online services.

From a compliance point of view, you can rest assured that Azure complies with the majority of major standards across the world. These compliance standards are not easy to achieve by any standards, but Microsoft remain committed to keeping their compliance up to date and as broad as possible. Some of the specific compliance standards which are verified for the Azure Service are:

  • ISO/IEC 27001
  • SOC 1 and SOC 2 SSAE 16/ISAE 3402
  • UK G-Cloud
  • EU Model Clauses
  • Singapore MCTS
  • FedRAMP
  • Australia IRAP

Much more information can be found at the Azure Trust Center –

Convincing your boss, management boards and other business trustees that a move to the cloud is a secure one is a tough job, but Microsofts commitment to privacy, security and transparency makes it much easier to put together a viable business case which can help you reap the rewards of scalability, resiliency and compliance.

Exchange Online – Lock down mail flow

By default, Office 365/Exchange Online allows mail to be received from any external source. This is done using a ‘hidden’ default inbound connector. The properties of this connector cannot be viewed or modified, even in Exchange Online Powershell.

This is all well and good and allows you to be able to send/receive mail out of the box in Office 365, however is does cause a problem if you are using a 3rd party mail solution such as Mimecast or Websense. If you do happen to be using a 3rd party mail filter and you leave the default inbound connector alone, somebody could bypass your filter by sending you mail directly to your Office 365 hostname. From a best practices and security point of view, this is most definitely a bad thing.

To combat this and limit Office 365 from receiving mail only from your mail filter, go into your Exchange Admin centre and create a new Inbound Connector under Mail Flow>Connectors.

New Inbound Connector

The settings of your Inbound Connector should be as follows:

Type: Partner
Connection Security: Force TLS (only if your mail filter supports forced TLS. This will add an extra layer of security. Otherwise, use Opportunistic TLS)
Sender Domains: *
Sender IP Addresses: (enter your mail filters IP addresses here)

This example states that Office 365 will only receive mail from the IP address and nothing else. The * wildcard under Sender Domains applies the connector to all mail. If I were to use Exchange Online Powershell to perform the same task, my command would look like this:

New-InboundConnector -Name Lockdown -ConnectorType Partner -RequireTls $true -SenderIPAddresses -SenderDomains *

This simple configuration change will ensure that nobody can bypass your mail filter and spam you with invitations to enlarge something or other 🙂

Office 365 First Release Program

First of all, Happy New Year and welcome to 2015!

It’s been a long time coming, but I finally signed up for my very own Office 365 account today for my own production and testing environment. 2015 will hopefully see me develop my SharePoint Online skill set, and I’m also keen to have a test bed for problems which clients come to me with, and also just to satisfy my own curiosity when I need to!

The Office 365 teams are making a lot of UI changes at the moment, the majority of which I like a lot, but I need to be able to keep on top of the changes to avoid getting egg on my face in front of customers 🙂

For this reason, one of the important things for me to enable straightaway was the First Release program. This program is designed for the people who want to be on the bleeding edge, and gives the tenant updates as soon as they become available, sometimes as soon as one week after the announcement. This will allow me to test new functionality and become fully versed with it before my customers even receive it!

If you are one of those that live on the bleeding edge, log into your Office 365 Admin portal, and go to Service Settings>Updates and enable!

Office 365 First Release