Configuring Office 365 Preferred Language Settings


Office 365 empower organizations to use cloud based services for their business to ensure anytime anywhere access to corporate information. When you setup Office 365 tenant for an organization with offices in different regions then you’re also required to empower your end users to setup up their own preferred language settings in Office 365. For example, if you have a user in Japan then his preference will be to use Japanese language for his Office 365 portal instead of using English. In Office 365 you can set up language settings for users based on how you setup identities in Office 365. You can easily update language settings for users using PowerShell. Preferred language settings depends on how user identity is provisioned. If you have cloud based identities then you need to use Azure AD to modify the user account properties in Office 365. If you are using Azure AD Connect to sync on-premises active directory accounts with Office 365, then you have to update the settings in local active directory.

Configuring Office 365 Preferred Language Settings for Cloud Identities

Configuring Office 365 language settings for cloud based identities requires you to connect with Azure AD powershell. Perform the following steps to configure these settings.

  • Connect with Azure AD powershell using global admin credentials

C:\> Connect-MsolService

Configuring Office 365 Preferred Language Settings

  • Run the following cmdlet to configure the preferred language settings for user to Urdu

PS C:\> Set-MsolUser -UserPrincipalName -PreferredLanguage “ur-PK”

  • To verify the language settings for the user account, run the following PS cmdlet

PS C:\> Get-MsolUser -UserPrincipalName | fl PreferredLanguage

Configuring Office 365 Preferred Language Settings

Configuring Office 365 Preferred Language Settings for Synced Identities

When you are using synced identities with Office 365, you need to modify the on-premises user attribute in Active Directory to setup preferred language in Office 365. To modify the preferred language in Office 365 to Urdu for a user Phil, you need to set the “PreferredLanguage” attribute in user account properties in Active Directory. By default, this attribute does not contain any value and set to use English as default language.

  • To modify the individual user account properties, you can run the following PowerShell cmdlet.

Set-ADUser -Replace @{‘PreferredLanguage’=”ur-PK”}

  • To update the preferred language attribute in a specific OU, run the following cmdlet.

Get-ADUser SearchBase “OU=Test,OU=IT, DC=msexperttalk,DC=com” Filter * Properties PreferredLanguage | ForEach-Object {Set-ADUser $_.SAMAccountName –replace @{PreferredLanguage=“ur-PK”}}

  • To update the preferred language attribute of users in a specific domain, run the following cmdlet. Following cmdlet will set the attribute for those users who do not have any this attribute setup.

Set-AdServerSettings -RecipientViewRoot “”
#Change language to ur-PK for all users with a setting of NULL in the domain
Get-ADUser -SearchBase “DC=msexperttalk,DC=com” -Filter * -Properties PreferredLanguage | where {$_.PreferredLanguage -eq $null} | Select SAMAccountName | ForEach-Object {Set-ADUser $_.SAMAccountName –replace @{PreferredLanguage=”ur-PK”}}

Preferred Language attribute settings will update the language for the following in Office 365.

  • Office 365 Default Landing page
  • General settings and menu
  • Office 365 Management portal
  • Video
  • Groups
  • OneDrive for Business
  • Delve
  • Office Online
  • Planner

To review a complete list of available language codes, please visit the Microsoft TechNet site.

Incorrect Email Address Applied after Mailbox migrated to Office 365


By default, whenever you create a mailbox in your Exchange infrastructure, the primary email address for the mailbox is being assigned based on the email address policy applied to the user. Recently, I have been working with a customer for Exchange 2010 hybrid implementation with Office 365 and we ran into an issue of email address being changed after the mailbox is migrated to Office 365. Primary email address of mailboxes being migrated to Office 365 from on-premises Exchange 2010 had been changed. You will notice this issue in your hybrid implementation if you have more than one email address policy applied in your exchange organization.

Understanding Email Address Policy

From the behavior of email address, it was obvious it’s being done by email address policy but the question is which email address policy and why? As we are running infrastructure in a hybrid mode and our on-premises infrastructure is the source of authority so we need to look into Exchange 2010 email address policies to fix the issue.

If you have more than 1 email address policy in your Exchange organization than It’s recommended to review your email address policies before moving any mailbox to Office 365.

In my scenario, i had 2 email address policies configured on Exchange 2010 as shown below.

Incorrect Email Address Applied after Mailbox migrated to Office 365As you can see, We had two email address policies configured and the policy with the name of “Set Email Address” has highest priority.

For those of you who don’t know why we need to create another email address policy, In Exchange 2010,  you cannot modify the criteria and conditions of default email address policy that’s why organizations tend to create a new custom policy as per their requirements. Default email address policy assign an email address of with a scope of “All Recipient Types“.

Incorrect Email Address Applied after Mailbox migrated to Office 365The custom email address policy was configured to be applied on “Users with Exchange Mailboxes” and the primary email address was configured as first initial and last name (e.g.

Incorrect Email Address Applied after Mailbox migrated to Office 365

Why Email Address was changed?

We understand the email address policy configuration, now whenever a mailbox is migrated to Exchange Online the Default Policy will be applied to the mailbox instead of the custom policy because the custom policy scope is set to only “User Mailbox” and when you move a mailbox to Office 365, it converts the mailbox to MEU and our custom policy was not applied to MEU. As a result, the default reply address is set to instead of what might have been originally intended.

How to Fix It?

Now, we understand the problem and it’s time to fix the issue. We have 2 options to fix this issue.

  • Modify the Custom Policy to apply to all Recipient Type
  • Modify your default email address policy to add additional SMTP address matching the custom policy and set the email address as primary address

Once you apply the fix, you need to wait for Azure AD connect sync to happen to replicate the changes to Office 365. Hope this article help you fix your issue with incorrect email address applied to user mailbox after the mailbox is migrated to Office 365.

Filtering in Azure AD Sync (Part 3)

In this article we will work on setting up different type of filtering in Azure AD Sync to synchronize only the required users with office 365. Part 1 and Part 2 of this article series revolves around the prerequisites, installation and configure of Azure AD Sync tool. We’re already done with Azure AD Sync tool prerequisites and installation and now it’s time to setup filtering in Azure AD Sync tool.

Let’s get started with Part 3 of this series.

Azure AD Sync Filtering Types

Azure AD Sync tool support three types of filtering and you can choose the type of filtering based on your requirements.

  • OU Based Filtering
  • Domain Based Filtering
  • Attribute Based Filtering

You can enable filtering in Azure AD Sync at any time. If you have already run the default configurations of directory synchronization and then configured the filtering, the objects that are filtered out are no longer synchronized to Azure AD. As a result, any objects in Azure AD that were previously synchronized but were then filtered are deleted in Azure AD. If objects were inadvertently deleted because of a filtering error, you can re-create the objects in Azure AD by removing your filtering configurations, and then synchronize your directories again.

OU Based Filtering

With organizational based filtering, you can explicitly specify which OU’s can synchronize with office 365. In our case I’ve only synchronized 2 OUs with office 365 “Users” & “Admin Users”. To setup OU filtering follow the steps .

  • Log in to the Sync server using the local active directory service account for Azure AD Sync. In our case we’re using as service account and I’ve logged in to the server using
  • Browse to “C:Program FilesMicrosoft Azure AD SyncUIShell” and run “MIISClient”


  • After running the client, Click on “Connectors” to modify the connectors for filtering


  • Select on prem AD Connector and go to the properties  –> Configure Directory Partition –> Containers. On prem connector type will always be “Active Directory Domain Services”



  • Unchecked the OU’s which you don’t want to synchronize. By default all OU’s will be selected.


  • Click Ok and close the MIISClient. OU filtering has been set.

Domain Based Filtering

At times, you need to work on multiple domains for large organization or with multiple business units. Scanerio’s comes when one of your business units move to office 365 and rest of the business units remains on their existing systems. Requirments like synchronizing users with only specific UPN/Domain can be achieved using Domain Based filtering. Using domain based filtering, you can specify which users can synchronize with office 365 based on their domain name. Steps to setup domain based filtering are as below.

  • Run MIISClient –> Connectors –> On Prem Connector –> Properties


  • Go to Configure Directory Partitions –> Select Directory Partition and select the domains which you want to synchronize with office 365. In our case, We’ve 2 domains installed in our lab ( and and we’re only synchronizing users with office 365. All other partitions and domains are unchecked.




We can apply all 3 type of filtering to synchronize the required users. Sometimes domain filtering does not clear up your Run Profile for other domains and you need to manually remove your run profile to complete the domain filtering.

Attribute Based Filtering

Attribute based filtering is used to synchronize on prem users with office 365 based on attribute field values.

There are several ways to configure filtering based on attributes. Configuration on inbound from AD is recommended since these configuration settings will be kept even after an upgrade to a newer version. Configuration on outbound to AAD is supported, but these settings will not be kept after an upgrade to a newer version and should only be used when it is required to look at the combined object in the metaverse to determine filtering.

Inbound Filtering

  • To setup inbound filtering, go to “Synchronization Rules Editor” on sync server. You can find the “Synchronization Rules Editor” in start menu on Windows Server 2012 R2.


  • Make sure that Inbound Rule type is selected on the left side and click on Add New Rule


  • Select Connected Systems (Source Forest), CS Object Type as user because we’re doing filtering based on users.



Name field represents the name of the rule, Connected System is the source such as the Active Directory forest. The Connected System Object Type is the type of AD object like  user, groups, contacts etc. Link Type is the action which you want your rule to perform. It has 3 values or actions like Join, StickyJoin or Provisioned. Join action will merge or update the object. Provisioned action will create the object. Link Type option will be superseded by Join rule configured in a later step.

  • Click Next. As we’re synchronizing those users with office 365 who has company field value of either Ms Tech Talk or NullWe do not need to configure anything in Scoping Filter and Join Rules. (This needs to be configured in more details based on your filtering).
  • On the transformation screen, Add the value as  “IIF(IsNullOrEmpty([company]),NULL,IIF([company]<>”MS Tech Talk”,”DoNotSync”,NULL))” and click on ADD button.


It is recommended to use Inbound Filtering. Outbound filtering is not recommended. More information on attribute based filtering can be found on Technet.

Outbound Filtering

  • To perform outboud filtering, run “Synchronization Rules Editor
  • Make Sure Rule type “Outbound” is selected.
  • Click on Add Rule on the right hand side and provide the parameters for Connected Systems, CS Object Type and define the rules based on your rule.

Outbound filtering is recommended and used in Resource Forest / Account Forest topology. It is recommended to perform Full Sync after configuring filtering

Couple of examples on attribute based filtering can be found on David’s blog here and here.

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

Step by Step Azure AD Sync Installation Guide (Part 2)

In this article we will install and configure the Azure AD Sync tool to synchronize on prem identities with office 365. Part 1 of this article series revolves around the prerequisites required to install and configure Azure AD Sync tool. We’re already done with Azure AD Sync tool prerequisites and has created the required service account on Office 365 and on prem active directory.

Let’s get started with Part 2 of this series.

Azure AD Sync Installation

  • To install Azure AD Sync tool, login to Sync server using the on prem local active directory service account. In our case, local active directory service account name is
  • You can download the most recent version of Azure AD Sync using the following link of Microsoft Website.
  • If there are 100,000 or less objects in AD to sync to Office 365 you can use SQL express, If more objects are needed then a full version of SQL is required.
  • The minimum recommended hardware requirements for the synchronization server in relation to how many objects you have in your on-premises Active Directory can be found on Technet.

It’s recommended that you should use a separate machine for Azure AD Sync tool installation. Azure AD Sync tool should not be installed and configured on Domain Controller and ADFS server as it’s not recommended.

  • Let’s get started with the installation of Azure AD Sync tool. To start the installation process, launch the executable called MicrosoftAzureADConnectionTool.exe


  • Once you run the executable, Click YES on User Account Control pop up to start the process.

a (2)

  • Windows Azure AD Sync setup will being, specify the path to install the tool. In our case, we’re using the default installation path.

Step by Step Azure AD Sync Installation Guide

  • Once you click on install, Azure AD Sync will start installing components like SQL Express, Connectors etc.

Step by Step Azure AD Sync Installation Guide

  • After the installation of required components is completed, you’ll be prompted for below screen to provide your Azure AD Credentials. This needs to be your office 365 Global Admin credentials. We’re using as a service account created in part 1 of this series.

a (5)

  • After connecting with Office 365 using Global Admin Credentials, the next screen will be presented to enter your on prem active directory account credentials. In our case, We’ve already setup a service account in our local active directory and we will use the same account  here as shown below.

a (7)

  • After providing the credentials, click on Add Forest and Active Directory forest will be added as shown below. Repeat the same steps to add multiple forests.

a (8)


  • Next Screen will be presented for User Matching, You can uniquely identify your users based on criteria defined here. We’re using the default settings.

a (9)


  • Next screen will be presented to choose the Optional Features and the new features that comes with Azure AD Sync tool.

a (10)


  • Once you’re done with all the information and tool is able to connect with both on prem AD and Office 365 using the credentials provided during the configuration click on Configure to start the configuration

a (11)

a (12)

  • Once the configuration is completed, Click on Finish and the Wizard begins the process of synchronizing on prem identities with Office 365.

a (13)

  • To verify that the users have been synchronized with Office 365, login to Office 365 –> Users –> Active Users and verify the last sync time and Status.


By Default, Azure AD Sync tool Synchronized with office 365 after every 3 Hours. We can change this time at any time.

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

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: