What’s new in SharePoint 2016 – Part 1

Bill Baer, Senior Technical Product Manager and MCM for SharePoint in SharePoint Product Group in Redmond, has shared the details on What’s New for IT Professionals in SharePoint Server 2016 in Microsoft Ignite on Wednesday, 06 May, 2015.

SharePoint 2016 build version 16.0.4021.1201 has been shown in Ignite. In Ignite Bill Baer has discussed what will be included in next version of SharePoint family, few of the things are complete and few are still in progress as there is almost a year in the final launch.

With addition of new features, SharePoint 2016 will be covering some of the known issues in earlier versions of SharePoint:

  • Operating SharePoint wasn’t easy
  • Patching and updating SharePoint wasn’t easy
  • Scale and management

I have planned to write a series of blog posts to share details on what’s coming in SharePoint 2016. In this blog post (Part 1), I will share details on new updates in SharePoint 2016 Management.

Hardware Requirements

  • It will remain 64 bit application, recommended RAM for single Server installation is 16 to 24 GB, and for a Farm server it will be 12 to 16 GB. You can see below table for recommended hardware requirements.
Single Server 16-24 X64
80 GB
Farm Server 12-16 X64
80 GB


  • It will support Windows Server 2012 R2 and Windows Server 10
  • Windows Management Framework 3.0 which provide support for PowerShell 3.0
  • Microsoft .Net Framework 4.5.2 (in windows Server 10 you will need 5.6)
  • Continuous to support Windows Server AppFabric which provide in-memory distributed caching for no. of different features (i.e. Caching for Social Feeds, login Token cache, last modified time cache, etc.)
  • AppFabric will be component of SharePoint 2016 (AppFabric support will be available for SharePoint 2013 and SharePoint 2016)
  • Provide support for Information Protection and Control Client
  • Microsoft WCF Data services to enable the creation & consumption of oData Services.

SharePoint 2016 Prerequisites

Database Requirements

  • It require Microsoft SQL Server 2014 (64-bit) with SP1
  • Or next versions of SQL Server 201x (64-bit)


  • Not much changes in Deployment scenarios from SharePoint 2013, still support SharePoint development installations on domain controller.
  • The only change is that stand alone installations are no longer available in SharePoint 2016 with built-in database engine of SQL express edition, but still you can install SQL Server separately on the same machine for single server installation.
  SharePoint 2013 SharePoint 2016
Workgroup Unsupported Unsupported
Domain Controller Developer Developer
Client OS Unsupported Unsupported
Dynamic Memory Unsupported Unsupported
Windows Web Server Unsupported Unsupported

Upgrade & Migration

  • SharePoint Server 2013 is the foundation of next versions of SharePoint.
  • Services Application Architecture of SharePoint 2016 will be same as of SharePoint 2013, PerformancePoint Service Application will be part of SharePoint 2016.
  • SharePoint 2013 can be directly upgraded to SharePoint 2016, SharePoint 2013 will support for incremental upgrade to next versions of SharePoint.
  • For upgrading SharePoint 2013 to 2016, any site collection with 14.5 mode need to be upgraded to 15 mode, this is required if there is any backward compatible site collection (from SharePoint 2010) then it need to be upgraded to SharePoint 2013 to ensure that they can be upgraded in SharePoint 2016.
  • Detaching databases from SharePoint 2013 and re-attaching to same databases to 2016, this is similar as we do in previous versions of SharePoint.
  • Content migration is also available with no. of different ways, APIs are available and there are many 3rd party tools available for this job like Metalogix, AvaPointe, & ShareGate.
  • No direct upgrade form SharePoint 2010, you need to update SharePoint 2010 site collections to SharePoint 2013 then it will easy to upgrade to SharePoint 2016 as SharePoint 2013 is the foundation to upgrade next releases of SharePoint.


  • SAML authentication becomes a first class citizen in SharePoint 2016.
  • There were multiple authentication providers in SharePoint 2013 like windows Claims, form based authentication, SAML Claims, WSFED and others to provide backward compatibility.
  • In SAML Claims is the default and recommended model but SharePoint 2016 will continue to support Windows Identity.

SharePoint 2016 Auth

SMTP connection Encryption

  • In SharePoint 2013 & SharePoint 2010, we always leverage port 25 for any communication, now SharePoint 2016 supports STARTTLS connection encryption.
  • In older versions of SharePoint all the communication through emails, alerts was unencrypted. In SharePoint 2016, we can run on non-default ports which encrypted communication between SharePoint and the messaging service. This can be configurable through Central Administration and PowerShell.

Ldifde.exe Failed to Import Schema File Error Code 8224

bannerExchange 2013 — Ldifde.exe Failed to Import Schema file error code 8224

Exchange Server install and upgrade usually involve an update to the Active Directory schema. During my Exchange 2013 Lab Installation I’ve encountered the following error during schema preparation.

There was an error while running ‘ldifde.exe’ to import the schema file ‘C:WindowsTempExchangeSetupSetupDataPostExchange2003_schema0.ldf’. The error code is: 8224.

Above error message indicates that the import of schema changes have been failed and when you check your Schema Master FSMO role domain controller in your forest you’ll notice the following event log in Directory Services logs.

Ldifde.exe Failed to Import Schema file error code 8224

From this warning message we can notice that the root cause is a replication issue in your Directory services infrastructure. In my experience this is due to either a domain controller in the environment is offline or decommissioned incorrectly causing replication issues. To check the status of replication in your Active Directory infrastructure you can either use RepAdmin or Active Directory Replication Services Tool. Once you resolved replication issues in your Active Directory infrsatructure you will be able to extend AD Schema and Exchange setup will not have any issues during the schema extension.

In my lab, one of the child domain controller went offline and i forgot to check that. Once the child domain controller was up and running and I’ve a success message of replication in my lab i was able to extend the Schema during Exchange 2013 SP1 installation.


Security Vulnerability in AD FS 3.0

Security Vulnerability in AD FS 3.0

Security Vulnerability in AD FS 3.0

April 2015, Microsoft has released an important security update for ADFS 3.0 in Security Bulletin which prevent you from security breach reported in ADFS 3.0. Security Vulnerability in AD FS 3.0 was found which helped hackers / intruders to gain access of your application using the existing token.

According to the Microsoft Security Bulletin MS15-040 the vulnerability allows an attacker to gain access to your application using ADFS 3.0 SSO like Office 365. The flaw is with the logoff process of ADFS 3.0 which didn’t could allow intruder to reuse the existing token to access the application. The log off failed allowing an intruder to reuse the existing token to access the application as the user.

This security update resolves a vulnerability in Active Directory Federation Services (AD FS). The vulnerability could allow information disclosure if a user leaves their browser open after logging off from an application and an attacker reopens the application in the browser immediately after the user has logged off.

The Security bulletin claims that Microsoft has no knowledge of any cases where this vulnerability was exploited and i hope no one is impacted or could be impacted and everyone can patch their ADFS servers as i did my servers before writing up this article :)

Detail information on security bulletin can be found on Technet.  Be safe :)

Azure AD Sync “Permissions-Issue” Error Code-8344

Azure AD Sync “Permissions-Issue”

Today i have been working on troubleshooting Azure AD Sync tool for one of my customer where they were having issues with the tool. MIIS client was reporting export errors for all the users in the organization and the error was “Permissions-Issue”. It was one of the interesting errors to work on and it took me a day to resolve the issue and i thought to share the remedy with all of you so that you should be able to resolve this issue within an hour.

Azure AD Sync Export Error

Whenever AAD Sync perform synchronization with office 365, evertime we were getting the error message on “Export”. If we look at the error message it says “Permissions-issue” and we verified that our on prem service account and Office 365 service account has all the required permission for AAD Sync tool. At one stage we thought it’s a false error but No it’s not a false error and it does have a solution. Below is the screenshot of error message that we were getting.

Azure AD Sync error When you click on permission-issue you’ll see the following screenshot which is giving us the details of error message along with error code.

AAD Sync permission error details

Let’s get started to resolve this error and below are the steps that we need to perform to resolve this issue.

Resolve AAD Sync Export Error

If you click on Permission-Issue to see the detail you’ll see that Connected date source error code is 8344. To resolve this issue, perform the following steps

1. Run Active Directory Inheritance script to get a list of users on which inheritance is blocked. Once you’ve the list pls make sure that you allow inheritance on those users/groups.

To allow inheritance, Make sure Advance Features are enabled in View then go to user properties –> Security –> Advanced –> Select the check box “to include inheritable permissions from this object’s parent”

2. Make sure you’ve the required on prem permissions assigned to Azure AD Sync tool service account. You can assign the appropriate permissions to Azure AD Sync tool by following this article.

3. Once you’ve check the inheritance and required permissions. Make sure that the service account is a part of AAD Sync security group in active directory. The name of security group is MSOL_AD_Sync_RichCoexistence. After you add the service account to the group, re-run the full synchronization and you will see that all permission-issue errors are gone.

In my case, customer was using AAD Sync along with password sync and they had Exchange 2010 SP3 hybrid configured.

Hope this article will help you resolve your issue with Azure AD Sync tool. Please feel free to ask us in case you have other issues. Thanks.

Change Default Sync time of Azure AD Sync (Part 5)

Change Default Sync time of Azure AD Sync

In Part 4 of this article series, we learned about how we can manually synchronize on prem identities and password hash with office 365. In this article we will learn how we can change the default synchronization time of Azure AD Sync tool to meet our requirements.

Let’s get started with Part 5 of this series and learn how to change the default sync time of Azure AD Sync.

Default Synchronization

By default Azure AD Sync tool synchronize with office 365 after every 3 hours just like Dir Sync tool. Dir Sync determines the time to synchronize with office 365 using Microsoft.Online.DirSync.Scheduler.exe.config file located in “C:Program FilesMicrosoft Online Directory Sync” but this has been changed with the new Azure AD Sync tool and now we have Windows Tasks Scheduler to determine / modify the time to sync with Office 365.

By Default, Azure AD Sync schedule runs after every 3 hours executed by a schedule tasks. This scheduled task actually runs DirectorySyncClientCmd.exe in the backend and perform delta sync.

To modify the default synchronization time, we need to perform following steps.

  • Log on to Sync server using on prem Sync service account. In our case, we’re using AAD@mstechtalk.com as service account.
  • Go to start menu and search for Windows Tasks Scheduler


  • In windows tasks scheduler Library, you can notice that a task with the name of Azure AD Sync Scheduler is defined to triggered after every 3 Hours.


  • We can’t modify the task if it’s enabled. To modify the scheduler Right Click on Task –> Click Disable to disable the task as shown below


  • After disabling the schedule, double click on task and go to Triggers as shown below



  • Select the Trigger and click on Edit to edit the schedule trigger. Currently you can see the trigger is defined to run after every 3 hours and it’s set to run for Indefinitely.


  • From the drop down menu of “Repeat task every” Select the time after which you want to trigger Azure AD sync with office 365. In our case I’ve modified the time to 10 minutes.



  • Click Ok to close the Trigger editor. Click on Ok to Azure AD Sync Scheduler Properties as well to complete the process.


  • When you click on Azure AD Sync Scheduler Properties, It will prompt you to enter the Password of Microsoft account created during the installation and configuration but we can replace that account with our Azure AD Sync on prem service account. Enter your on prem Azure AD Sync service account credentials and hit Ok.


  • After modifying the trigger settings, you can see that you have successfully modified the default sync time of Azure AD Sync tool to 10 minutes.


  • Last action that we need to perform after changing the default sync time is to enable the scheduler by Right Clicking on the scheduler and Click Enable.

This brings us to the end of this article in which we learned how to modify the default sync time of Azure AD Sync tool. If you want to read other articles of this series please go through the following URLs.

Enable / Disable Skype for Business Client

Enable / Disable Skype for Business client

In my previous post, I shed some light on new Skype for Business Client (formally known as Lync client ) look and options available to end user. This post will focus on the steps require to enable or disable Skype for Business Client for end user. Being an administrator you can control whether a user can use Skype for Business or not. With that being said, let’s get started with this post.

Before we start, i assume that you currently have Lync 2013 deployed in your infrastructure and the steps mentioned below are tested on Lync 2013 server edition. Here are the steps to Enable or Disable Skype for Business client in Lync 2013 server.

Mostly Microsoft product updates are pushed to end users from Windows Updates and Microsoft prefer to push new product updates from Windows Updates too. You can either manage Windows Updates centrally using WSUS and allow which updates can be pushed to end users machine and if you don’t have any centralized Patching system then you probably come up with this scenario where few users update their Lync client to Skype for Business and few using Lync. Once lync client is updated to Skype for Business client users will get the following pop up.


Most of the companies wants to standardize their software deployment and if you want to manage standardization of Lync client without using any central management system then here are the steps which will help you to control lync client version on your end user machines.

Enable Skype User Interface

By default Skype for Business client UI value is Null in Lync Client policy. We can check client policy setting using this cmdlet,

Get-CsClientPolicy -Identity Global <PolicyName>


We can allow Skype for Business client interface using following cmdlet in Lync Management Shell,

Set-CsClientPolicy -Identity Global -EnableSkypeUI $True

To enable for particular set of users,

New-CsClientPolicy -Identity AllowSkypeUI -EnableSkypeUI $True

Grant-CsClientPolicy -Identity <sip address> -PolicyName AllowSkypeUI


After configuring client policy, Lync client will prompt for restart,


Disable Skype User Interface

To disable Skype for Business client user interface run the following command in Lync management shell,

Set-CsClientPolicy -Identity Global -EnableSkypeUI $False

Registry Settings

Administrators can control the client interface using registry settings too. Here is the registry location:


To change registry settings using powershell,

Enable Skype for Business: Set-ItemProperty HKCU:\Software\Microsoft\Office\Lync -Name EnableSkypeUI -Value 00,00,00,01

Disable Skype for Business: Set-ItemProperty HKCU:\Software\Microsoft\Office\Lync -Name EnableSkypeUI -Value 00,00,00,00


Azure AD Synchronization using PowerShell (Part 4)

Azure AD Synchronization using PowerShell

In Part 3 of this article series, we learned about different filtering options available to us and how we can use them to fulfill the requirements. In this article we will learn on how we can manually force a synchronization using PowerShell and how we can change the default synchronization time of Azure AD Sync.

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

Azure AD Full Synchronization

We’ve a utility called DirectorySyncClientCmd.exe which executes the sequence of actions to synchronize on prem identities with office 365.

To run a full synchronization browse to “C:Program FilesMicrosoft Azure AD SyncBin” from windows powershell and run the cmdlet .DirectorySyncClientCmd.exe Initial as shown below. “Initial”will perform a full synchronization.


It’s recommended that you perform a full synchronization after making a major change in your Azure AD Sync configuration like enabling password synchronization for user.

Azure AD Delta Synchronization

To perform the delta synchronization with Office 365, we need the same executable to perform delta synchronization of users from on prem to office 365. By default Azure AD Sync tool performs delta sync after every 3 hours. Later in this article we’ll learn on how we can change the default sync time of the tool. To perform the delta synchronization we use the .DirectorySyncClientCmd.exe executable with Delta keyword as shown below.


Azure AD Password Synchronization

Password Sync was one of those features which helped a lot of enterprises to manage their users password policies and change management from local active directory. Password Synchronization enables users to log into their Office 365 and other Microsoft online services like Intune, CRM etc using the same password as they use to log into their on-premises infrastructure. It is important to note that this feature does not provide a Single Sign-On solution because there is no token sharing in the Password Sync process. This feature is also referred as Same Sign-On.

Active Directory Domain Services that are configured for FIPS are not compatible with the Password Sync feature.  During Password Synchronization Plain text version of a user’s password is neither exposed to the password sync tool nor to Azure AD or any of the associated services. Azure AD Sync tool synchronize the user’s password in the form of hash.

When you’ve password synchronization enabled then password complexity policy and password expiry policy on office 365 will no longer be valid and on prem policies will be applicable.

To perform a Password Synchronization, We need to run the Password Synchronization with Office 365 using Azure AD Sync. You can download this script from Technet.


More details on password synchronization can be found on Technet.

Verifying Manual Synchronization

To verify the Full and Delta Synchronization, Log in to Office 365 Portal and Browse to users –> Active Users and check the last sync time. You can also check the MIISClient for last sync time and status of sync.


To verify the password synchronization is completed successfully, Go to Event Viewer –> Application Logs and look for Event ID 656 and 657 as shown below.



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

Skype for Business Client Announced

What’s New in Skype for Business Client

Finally ! Microsoft has announced the availability of Skype for Business. Skype for Business client was available for end users in Preview but yesterday Microsoft released the new update for Lync 2013 client KB2889923.

Microsoft rebranded Lync client to Skype for Business client. New Lync client is named as Skype for Business. Skype for Business client has new look then the Lync client but a look similar to Skype for consumer for user adoption and ease of usage. Here I’m going to walk you through some of the new look and feel of Skype for Business Client.

You can download Skype for Business client update from Microsoft download center.

Here are the new look of Skype for Business client


New One click Call controls in Skype4B client

Call Control

Meeting Experience


New Emotions in Skype for business meeting and chat window,


New call control bar, when Skype4b client is in background,

Call BG

New Phone tab look in Skype for Business client,


New Skype for business client icons in outlook for meeting schedule, join Skype meeting and meeting invitation.

join      MSchedule


Here are the new settings in Skype4B client Options






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 AAD@mstechtalk.com as service account and I’ve logged in to the server using AAD@mstechtalk.com.
  • 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 (mstechtalk.com and contoso.mstechtalk.com) and we’re only synchronizing mstechtalk.com 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 AAD@mstechtalk.com
  • 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 AzureAD@UCTechTalk.onmicrosoft.com 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: