Azure AD Sync Requirements / Prerequisites (Part 1)

Azure AD Sync Requirements / Prerequisites (Part 1)

In this articles series, I will walk you thru step by step to install and configure Azure AD Sync tool to synchronize on prem identities with office 365. You can download the most recent version of Azure AD Sync from Microsoft Website. Let’s get started with part 1 of this series.


Azure Active Directory Sync is the new synchronization service that allow customers to do the following:

  • Synchronize multi-forest Active Directory environments without needing the complete feature set of Forefront Identity Manager 2010 R2.
  • Advanced provisioning, mapping and filtering rules for objects and attributes, including support for syncing a very minimal set of user attributes (only 7!)
  • Configuring multiple on-premises Exchange organizations to map to a single Azure Active Directory tenant

More details on Azure AD Sync tool can be found on Technet

In this article series, we’ll setup environment for synchronizing on premise users with Office 365 using Azure ADSync Tool and apply different filtering options to synchronize only the required users. Once it’s all done we will upgrade the Azure ADSync tool to the new Azure AD Connect Preview 2 tool.

Prerequisites for Azure AD Sync:

  • Windows Server 2008, 2008R2, 2012, 2012R2
  • .Net framework 4.5 installed
  • PowerShell (preferably PS3 or better)
  • An account with local administrator privileges on your computer to install Azure AD Sync.

Azure AD Sync requires a SQL Server database to store identity data. By default a SQL Express LocalDB (a light version of SQL Server) is installed and the service account for the service is created on the local machine. SQL Server Express has a 10GB size limit that enables you to manage approximately 100.000 objects.



Service Accounts for Azure AD Sync Tool

We need 2 service accounts for Azure AD Sync installation as mentioned below.

  1. Local Active Directory user account
  2. Office 365 user account (Global Admin Rights)

On Premises Service Account to connect to AD DS:

On Prem service account is required to read the user information from local active directory. Additional permissions are required for Password Right Back and other optional features of Azure AD Sync tool. To create a service account on local active directory  –> logon to any writable Domain controller and follow the steps as mentioned below.

  • With an admin account, create a user account in AD for the AAD Sync service account.





  • Once the active directory account is created, login to Azure AD Sync server and add the newly created AD account to local admin groups on the AAD Sync server.


111 112


  • Log off the AAD Sync server and login to the Domain Controller to assign appropriate permissions to the AAD Sync Service Account.
    • On Prem service account required “Replicating Directory Changes” and “Replicating Directory Changes All” permissions in local active directory. To assign these permissions make sure that “Advanced Features” are enabled for the domain


121 122

  • Configure “Reset Password” and “Change Password” extended rights for the AAD Sync service account in Windows 2012 R2. To assign appropriate permissions Right Click on Domain name –> Properties –> Security.






  •  Additional rights that are required for the service account to use the write back feature.
Object Type Data source Attribute Permission / Access Right Inheritance
Contact proxyAddresses Write The child objects only
Group proxyAddresses Write The child objects only
User/InetOrgPerson msExchArchiveStatus Write The child objects only
msExchBlockedSendersHash Write The child objects only
msExchSafeRecipientsHash Write The child objects only
msExchSafeSendersHash Write The child objects only
msExchUCVoiceMailSettings Write The child objects only
msExchUserHoldPolicies Write The child objects only
proxyAddresses Write The child objects only

Office 365 Service Account:

Office 365 Service accounts is used to read & write the user information to office 365 Active directory (Azure Active Directory). Office 365 account needs to be a global admin and password expiry should be set to “NeverExpire” as best practice.

  • Create a user account on Office 365 and assign global admin rights to the account

1 2

  • Set Password to never expire using the PS Cmdlet Set-MsOlUser -UserPrincipalName -PasswordNeverExpires $True



This concludes part 1 of this multi-part article in which I’ve explained the pre-requisities for Azure AD Sync tool and permissions required on both side (local Active Directory and Office 365).

If you want to read the other Parts in this series, then please go to:

Exchange Online Advanced Threat Protection

Exchange Online Advanced Threat Protection

Exchange Online Advanced Threat Protection

In the modern era, we have seen a steady increase in data security specially the email security against spammer. Spammers are constantly changing the way they send and mask spam/viruses. Microsoft is continuously working to protect their customers against modern era techniques so that customer can enjoy the best in class services. With that being said, On 8-April Microsoft has announced the new advanced robust optional feature to protect against Spam, viruses and malware with Exchange Online Protection. Yes ! I’m talking about new Exchange Online Advanced Threat Protection and I’m excited to deep dive into ATP. Currently ATP is available in private preview only and is expected to be available to commercial customers as optional service by this summer.

ATP will have the following advanced features as optional service.

  1. Protection against unknown malware & Viruses
  2. Real time protection against malicious URLs
  3. URL trace & Rich Reporting

ATP will be available at $2 per user per month for commercial customers and $1.75 for government pricing customers as optional feature.

More details on ATP can be found on Office Blog.

Mystery of Office 365 UsageLocation

Office 365 Features Limitations/Restrictions by Location

Many of the people might get confused or probably never focused on why we need to specify usage location while assigning a license to end user in Office 365? What’s the purpose of UsageLocation? Is it same as of Country field populated in Active Directory?

If you look at a cloud user via PowerShell, you’ll also notice that there is a separate “UsageLocation” attribute. This attribute is the one used while assigning a license to a user in office 365. Some features in Office 365 are not allowed in certain countries and “Microsoft” determines this with the help of UsageLocation attribute. When you assign a license to a user and specify the usage location of Office 365 services, Microsoft apply usage restriction to those particular users based on their usage location. e.g. Hosted Voice Mail and Lync audio/video is not allowed in Brunei and if you try to enable Hosted voice Mail for a user with “UsageLocation” of Brunei, you’ll get an error message  stating that “This feature is not available in the location indicated in this user’s UsageLocation“.  Now we understand the reason behind this attribute, there are a couple of ways to set usage location for users in Office 365.

  • Office 365 Portal
  • Local Active Directory

When you assign a license to a user in Office 365 portal using PS or GUI you specify a UsageLocation. We can specify UsageLocation in local active directory and Dir Sync or AAD Sync can sync the usage location to office 365 and override the information. If you look at the connectors in DirSync and AADSync, you’ll see that “UsageLocation” in the Azure Active Directory is mapped to “msExchUsageLocation” on-premises. You can populate the attribute either in the cloud or on-premises. Mostly attributes are only writable on one side or the other. Based on the flow rules, the on-premises value will take precedence and overwrite existing data in the cloud.

Valid values for “msExchUsageLocation” appear to be the same as those for the “Country” field (attribute name = “c”); basically it’s the 2-letter ISO code for the country.

Usage Restriction details can be found here.

Office 365 Usage Restrictions

Office 365 Usage Restrictions

The availability of services and features in Office 365 varies by country or region. A service, such as Voice over Internet Protocol (VoIP), may be available in one country or region, and not available in another. Features within a service can be restricted for legal reasons in certain countries or regions. Below is the details of services available in each country or region.


Office 365 Usage Restrictions

Office 365 Usage Restrictions











Connect Exchange Online using PowerShell

Connect Exchange Online using PowerShell

Managing Exchange online with PowerShell requires you to connect with Exchange Online. Few months ago i was working on automating the process of connecting with Exchange online rather then writing the cmdlets every time i connect with Exchange online and you know what i come up with ? Powershell Function which makes it so easy for me to connect to Exchange Online anytime i want to and i don’t have to write cmdlets every time. The function is as below.

# PowerShell Function to connect with Exchange Online

Function Connect-ExchOnline {
$ExchOnlineCred = Get-Credential

Write-Output “You are Connecting to Exchange Online. After successful authentication PowerShell will load Exchange Online Cmdlets”

#Create remote Powershell session with Exchange Online
$ExchOnlineSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri -Credential $ExchOnlineCred -Authentication Basic -AllowRedirection

#Import the remote PowerShell session

Import-PSSession $ExchOnlineSession -AllowClobber | Out-Null



You can download this PowerShell function script from Technet Gallery. This script is basically a function and I didn’t “call” the function in the script self. Try dot-sourcing the script first and then running it using Connect-ExchOnline and enter your Office 365 admin credentials to connect.

1 17 18 19