Just a few weeks ago, Microsoft announced a new feature in its line-up of hybrid Exchange capabilities: the Minimal Hybrid Configuration option. With the introduction of this new capability, Microsoft seems to have responded to a long-standing question from customers who can now move mailboxes to Office 365 without the need to deploy a ‘full’ Hybrid configuration.
Nothing but excellent news in the hybrid Exchange realm these days! Microsoft recently updated the support statement for cross-premises permissions in a hybrid deployment. As of now, Full Access delegate permissions are supported cross-premises. I know many customers will be delighted to hear this as this has been a big ask for quite some time now.
It’s important to understand that the support only applies to Full Access permissions, as stated here. Other permissions like Send-As, Receive-As or Send-on-Behalf are still not supported. Note that Microsoft is in the process of updating its documentation; you should see a more consistent message across TechNet over the next few days!
Although full access permissions have been reported to work intermittently, no cross-premises permissions were supported previously. As such, you could not rely on them working either. From what I understand, the plumbing was already in place for a while but the intermittent results were partially due to the Outlook client not honoring them quite as one would expect. Provided you have the November 2015 update to Outlook 2013, you should no longer run into any problems.
As you move mailboxes to Office 365, permissions are migrated along. If you already had permissions assigned before the move, there is nothing you need to do. Although the permissions were also migrated previously, you had to move connected mailboxes at the same time so they would be hosted in the same organization in order for them to work. Not too long ago, I was talking to a customer who started out with a handful of mailboxes to move to Office 365 but ended up with a huge migration batch because of the interweaved permissions… As of now, this is no longer needed, making planning for migration batches a lot easier!
You should now also be able to add the Full Access permissions after mailboxes have been moved. This means you can give an on-premises mailbox access to a mailbox in Office 365 and the other way around without having to set the permissions prior to moving the target mailbox to Office 365.
In order to explain things more clearly, I have put together a Q&A. I hope this helps!
What cross-premises permissions are supported in a hybrid deployment today?
Full Access only. Other delegate permissions like Send-As, Receive-As or Send-on-Behalf are not. There are no changes to cross-premises calendar delegation either. That continues to work the same way it did before.
Will the permissions work both ways?
Yes. On-premises mailboxes can access Office 365 mailboxes and vice versa.
What do I need to do to make this work?
Nothing, really. Just make sure you are using an up-to-date Outlook client. For Outlook 2013, this means you need at least the November 2015 Cumulative Updates. Needless to say, the more up-to-date you are, the better!
In order to add permissions for a recipient in the other organization, you can either use PowerShell or the Exchange Admin Center. Unlike the EAC in Office 365, you cannot use the on-premises EAC to grant an Office 365 mailbox access to an on-premises mailbox. For that you must revert to using PowerShell.
How do I add permissions to an Office 365 mailbox for an on-premises recipient?
Follow these steps to add Full Access permissions to an Office 365 mailbox for an on-premises recipient:
- Login to the EAC in Office 365 (Exchange Online)
- Navigate to recipients > mailboxes and then select properties of the mailbox you want to add Full Access permissions for.
- In the properties window, navigate to mailbox delegation
- Scroll down to you get to the Full Access From there, use the recipient picker (plus-sign) to add the on-premises mailbox you wish to grant permissions to:
- Click save.
How do I add permissions to an on-premises mailbox for an Office 365 recipient?
As mentioned earlier, you cannot use the EAC to add permissions for an Office 365 recipient. Instead, you must use the on-premises Exchange Management Shell. Don’t worry it’s quite simple!
|Add-MailboxPermission –Identity <On-Prem_mailbox_to_give_permissions_for> -User <O365_mailbox_to_give_permissions_to> -AccessRights FullAccess –AutoMapping $false|
|Add-MailboxPermission –Identity email@example.com –User firstname.lastname@example.org –AccessRights FullAccess –AutoMapping $false|
Unlike for permissions in the same environment, the AutoMapping feature is not supported. Hence why I specified the –AutoMapping $false parameter. I suspect the permissions to work without adding the parameter too!
What will my users see?
There is no difference in how Outlook displays an Office 365 mailbox over an on-premises mailbox you have access to. However, an on-premises user might get prompted for credentials when trying to access a mailbox in Office 365. This is because, in the back, the Outlook client must establish a connection with the Office 365 service first.
How that looks, depends on a number of things like the version of the Outlook client, whether you use Modern Authentication and whether or not they already have another Office 365 mailboxes in their Outlook profile.
Consider the following scenario: you are about to implement directory synchronization for Office 365. You have multiple Active Directory sites across several, geographically dispersed, locations all over the world. Unsurprisingly, some of these locations have better connectivity than others and you might not want AAD Connect to connect to Domain Controllers in locations with a slow or high latency connection at the risk of slowing down the entire process.
When Azure AD Connect connects to a new forest, it uses DNS to locate domain controllers it needs to connect to. Without additional configuration, it is very difficult to control or know exactly which Domain Controllers AAD Connect will connect to. I believe that within the domain it is installed in, AAD Connect will try and connect to Domain Controllers within the same site first –but I’m still waiting on getting that confirmed. Even if that is true, that would not necessarily be the case for remote forests as there is no way for AAD Connect to know which site in the remote forest is closest.
Once AAD Connect is installed, you will find that it is relatively easy to define a (static) list of Domain Controllers that AAD Connect should connect to.
- First, open up the Synchronization Service Manager on your AAD Connect server. This executable (miisclient.exe) is typically located in “C:\Program Files\Microsoft Azure AD Sync\UIShell”
- Navigate to Connectors and locate the connector, specific for your domain (forest). Note that the screenshot below only shows a single domain. If you are in a multi-forest environment and you might see multiple:
- Right-click the connector and choose Properties.
- In the properties window, go to Configure Directory Partitions and make sure to check the box next to Only use preferred domain controllers:
- In the Configure Preferred DCs window, add the domain controllers you want AAD Connect to interface with. You can order the domain controllers preference by moving them up/down the list.
- Click OK to confirm the changes.
That’s all there is to it. Now, Azure AD Connect will only talk to the Domain Controllers you have specified.
Yesterday, Microsoft announced they released Azure AD Connect and Azure AD Connect Health to the public.
Azure AD Connect can be seen as the successor to DirSync/AADSync, with an added edge. It does not only allow you to configure directory synchronization, but the wizard also allows you to automatically setup and configure Active Directory Federation Services instead of having to go through the motions manually.
The GA of the tool has been long awaited and it’s great to finally see it become available for everyone. Make sure to check back in the weeks to come as I will more than likely be posting some articles on what’s new and how to deal with the tool.
Office 365 provides various authentication options, such as cloud-IDs, Password Hash Synchronization or federated identities. Leaving out the specifics on how each of these options work, all of them are configured per domain. Whenever trying to access services in Office 365, the user is required to authenticate using its User Principal Name. For sake of simplicity, the general advise it to configure the UPN to match the email address which makes it less confusing for them.
The April 2015 Security Bulletin, Microsoft released an update for Active Directory Federation Service 3.0 which comes with Windows Server 2012 R2.
According to the documentation, the vulnerability would allow an attacker to gain access to an application – such as Office 365. Apparently the flaw is in the logoff process. As I understand it from the limited information available, although the user appears to have logged off, the logoff actually failed allowing an attacker to re-use the existing token to access the application as the user.
Although the bulletin mentions that Microsoft has no knowledge of any cases where this vulnerability was exploited, I personally wouldn’t wait for it to happen to me… 🙂
More information can be found here: https://technet.microsoft.com/library/security/MS15-040
It’s been a while since I have last posted an article on my blog, and there’s a good reason for that. For the past few months, Paul Cunningham, Tony Redmond and I have been working fiercely on a new ebook, called “Office 365 for Exchange Professionals“. Together with Exchange MVP Jeff Guillet who is leading the efforts as our technical editor, we are confident that this book will deliver high quality, up-to-date and relevant information!
As the name might already give away, this book is targeted to Exchange administrators, enthusiasts and experts to help them transition their skills to the cloud. One of the biggest challenges writing about Office 365 is the fast rate at which things change. That is also the reason why we have chosen to publish the book as an ebook rather than a traditional, printed, book. We plan to have the book available in early May with contents being up-to-date as close as possible to the release date! We’re continuously editing the text to ensure that even the latest changes in Office 365 are included.
We are also looking at keeping the book up-to-date in the future to stay relevant as Office 365 (and Exchange Online) evolve. Right now, we are still figuring out what the best way would be to do that. Once we’ve come up with something suitable, we will definitely share that with you.
In the meantime, if you have any questions or there are topics which you would like to see covered in the book, feel free to leave a comment. The book already contains a lot (really, a LOT) of information, but getting your feedback has proven to be invaluable!
Looking forward to hearing from you!