Friday, September 13, 2013

How to Configure an Office 365 Hybrid Premise Service Account

Updating Contacts in Office 365 from an On Premise Server

By Vern Weitzman

In case you are not familiar with the Microsoft Hybrid Exchange Server, an overly simplified explanation is that it's just an Exchange Server with a connector to the cloud. The hybrid connector makes the cloud an extension of your on-premise Exchange servers. I think this is an incredible enterprise solution and I plan to blog about it in the future.

As the CTO of a company that develops contact management software, I did not find it easy to adapt to this hybrid environment. Normally, when a customer has our application installed, it makes temporary MAPI RPC connections to thousands of local Exchange Server mailboxes. Since some of our customers have already moved gobs of mailboxes to the cloud, we had to be very creative to re-architect our platform and quickly implement support for Exchange Web Services (EWS).  The solution written below seems really simple. However, if we had this information before we started, we could have saved many of hours of frustration.
In the MAPI world, it was pretty straightforward to setup a service account so it could open many end-user mailboxes.  See my prior blog posting on how to set up a service account for an on-premise mailbox.
To summarize, we have found that Impersonation is the best option for itrezzo Unified Contact Management and I suspect the same would be true for other applications as well. There are two reasons for this. The first is that Microsoft is hinting that they may not be supporting delegation in the not-to-distant future. The second reason is because of hard coded throttling. Exchange 2013 throttling policies can't be changed. Impersonation bills activity against the target mailbox so the service account doesn't immediately use up it's processing quota. In either case, you might want to look at the article on Impersonation vs Delegation in the Exchange Dev Blog to help you determine what is best for your specific situation. 

Another requirement is to have the service account mailbox licensed on Office 365.  We did not know this when we started testing with our EWS implementation.  If the mailbox was not licensed, the ODME Impersonation attempts yielded “401 Unauthorized” errors when trying to log in.  
There are three ways we suggest creating a service account to open remote mailboxes.  For itrezzo Unified Contact Management, we usually use the second choice.
  • An on-premise service account that is created in your local windows domain.  In this instance, you must have a direct mailbox associated with this domain account. You move the mailbox to the cloud and license it on Office 365.  You can also use the PowerShell to do this. The specific PowerShell command is Set-MSoluserLicense.
  • Use an on premise service account that was created in your local windows domain.  In this instance, you must have a direct mailbox associated with this account. The mailbox will stay on-premise and Office 365 considers this object licensed.
  • Create a mailbox in the cloud.  You will be required to license the mailbox as part of the creation process. This mailbox will not be visible to on-premise applications that depend on the GAL to open mailboxes.
Note: For service accounts, it is also a good idea to set the service password so it never expires.
The last step for all three of these methods is to grant the service account ODME Impersonation rights. After these steps are complete, it can take up to 15 minutes for them to take effect.  I always recommend that you test the effectiveness of the service account.  Some suggestions on how to do this are at the bottom of this post. Read on for details on setting up the service account.

Steps to configure a service account to update mailboxes in the cloud



  1. Create a local mailbox and service account in the domain according to your standard procedures. Note that If you create the mailbox in the cloud, it will not sync back to the on-premise domain. For example, the local application would not see this mailbox in the on-premise GAL.
  2. Wait a few minutes for the account to sync to Office 365.
  3. Move the mailbox to Office 365 using the Exchange Management Console. This would normally be done from the Hybrid Server.
  4. After the on-premise service account is synced with your Office 365 (via Directory Synchronization), it will need to be granted a license on Office 365. The simplest way to license the on-premise service account in the cloud is to log in to your Office 365 web admin account and select “Admin” and then “Office 365” in the drop down (see screenshot below)



  1. Select “users and groups” from the navigation bar on the left.
  2. Once you find the user you want to license, click on their name and you should be presented with the following screen:
  3. Choose the licenses you wish to assign as shown above. The minimum requirements for this service account require that you at least check “Windows Azure Active Directory Rights” and “Exchange Online”.
  4. Once you select “Save” there will be a few more screens to step through. Please note that this account needs no special administrative permissions in the domain.
  5. It may take up to 4 hours for the service account to sync and have the licensing take effect. However, we have seen this happen in as little as a few minutes.

Assigning the ODME Impersonation Role

I am suggesting that you use the PowerShell to set the ODME Impersonation role. Because the tools are more likely to be installed on the Exchange Hybrid Server, you could use that server. However, if you need to start adding extra software components, it may be a good idea to this from a workstation.
  1. You need the Windows Azure Active Directory Powershell Module to manage Office 365. If you already have this installed, proceed to step #12. The next step will explain how to get this component installed.
  2. The Microsoft TechNet article explaining how to Manage Windows Azure Active Directory using Windows Powershell is where you can find the download. Please follow the instructions to install either the 32 bit, or 64 bit version as your system requires.
  3. Bring up the PowerShell and enter the following commands to connect to your Office 365 infrastructure (you will need log in credentials for Office 365 that has full administrative rights).
$cred=Get-Credential(this will pop-up a login dialog for O365)
$Session = New-PSSession -ConfigurationName Microsoft.Exchange `
    -ConnectionUri https://ps.outlook.com/powershell/ `
    -Credential $Cred -Authentication Basic -AllowRedirection


(this will usually return a message that looks something like this:)
WARNING: Your connection has been redirected to the following URI:"https://pod51034psh.outlook.com/powershell-liveid?PSVersion=3.0 "
Import-PSSession $Session(this will load all of the Exchange Online PS command sets, etc. - it make take a few seconds to complete)
  1. Now we will create the impersonation role and assign the service account to that role. From the online PowerShell session that you just started:
New-ManagementRoleAssignment –Name "Impersonation-itrezzo" `
     –Role "ApplicationImpersonation" `
     –User svc_itrezzo@yourdomain.net


Now your itrezzo server should be able to add, modify or delete contacts on cloud mailboxes.


It makes a huge amount of sense to perform a quick test to make sure the new service account can open up user mailboxes.  Here are some tools that we use:
  • Try creating a profile using Outlook 2010, 2013 and be certain that the credentials used are for the service account. After opening the service account mailbox, you should be able to add a secondary mailbox to the profile.  If that mailbox opens and you can create items (an Outlook Contact for example), your service account is most likely ready for production.
If you want to test from the application server, it is sometimes recommended that you don’t have Outlook on that same server. Here are two other tools that we have found helpful:
  • The Microsoft Remote Connectivity Analyzer https://testconnectivity.microsoft.com
  • EWS Editor  -- This application was built so that developers could have source code demonstrating how to use Exchange Web Services. There is a little extra learning curve to get use to EWG Editor, but it is well worth the effort and it just takes a few seconds to copy it onto a server.

I will create a future blog post on how to test your service account in greater detail.