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 as it's a one way sync from AD to Office 365. For example, the local application would not see this mailbox in the on-premise GAL.
2. Wait about 30 minutes for the user account to sync to Office 365 by automatic delta sync. You can also run a manual delta sync in Azure AD Connect by running the following PowerShell cmdlet - Start-ADSyncSyncCycle -PolicyType Delta
3. Move the mailbox to Office 365 using the Exchange Management Console or Exchange Admin Center. 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 Admin Center and select “Users” and then “Active Users”. (see screenshot below).

5. Select the required Service account from Active Users and click on Edit next to Product Licenses.
   

   
6. Choose the licenses you wish to assign and click on Save as shown below. The minimum requirements for this service account require that you at least check “Windows Azure Active Directory Rights” and “Exchange Online”.
   

   
7. 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.
8. It may take up to 60 minutes 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.
9. Once the Service account's mailbox is created in Office 365, then follow the next steps.

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.

10. You need to connect to Exchange Online PowerShell remotely bu opening Windows PowerShell as Administrator on your machine.Below step with direct you to the Microsoft article on how to connect to Exchange Online PowerShell remotely.
11. The Microsoft article explaining how to Connect to Exchange Online PowerShell is where you can find the steps.
12. Open Windows PowerShell as Administrator and run the following commands to connect to Exchange Online PowerShell. You will need to enter Global Administrator credentials to sign-in when prompted.

Set-ExecutionPolicy RemoteSigned Press 'Y' for Yes or 'A' for 'Yes to All' $UserCredential = Get-Credential When prompted to enter the credentials, provide the Global Administrator credentials for office 365. $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection Import-PSSession $Session -DisableNameChecking -AllowClobber

13. 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.