Azure AD Connect: How to run custom Sync scheduler with multiple on-premise AD connectors

Hello All,
I was recently involved on a project where I did some PowerShell scripts to remotely connect to an Azure AD (AAD) Connect server and run custom manual synchronization cycles (Delta Import & Delta Sync) using AAD Connect’s Custom Scheduler component.
The primary reason we had to do this was due to AD migration of users from one AD forest to another AD forest. Both these AD forest users were being synchronized (using a single AADConnect in target AD forest) to a common Azure AD tenant. Post AD migration via ADMT tool, the migrated AD user(s) merges with its corresponding pre-existing synced identity on Azure AD (due to ms-DS-SourceAnchor being the ImmutableID). Hence this avoids a new user being created on Azure AD post AD migration.
This post details the instructions for the following tasks:

  1. How to run Azure AD Connect Sync Scheduler remotely for a specific on-premise AD connector?
  2. How to run Delta Import/Delta Sync schedule actions remotely?

The AAD Connect server is having multiple On-Premises AD connectors configured for 2 Active Directory forests ( &; synchronizing user accounts from both these AD forests to a common Office 365 tenant ( as shown below.
So here are the instructions to run AAD Connect Custom Run Scheduler manually for a Delta Import & Delta Sync operation for the “ABC.NET” ON-PREM AD connector remotely.
1.  Stop the AutoSyncScheduler on the AADConnect01 server. (By default, Delta Sync runs on all configured connectors every 30 minutes on an Azure AD Connect Server)

Import-Module -Name ActiveDirectory
$Session = New-PSSession -ComputerName $AADComputer
Invoke-Command -Session $Session -ScriptBlock {Import-Module -Name ‘ADSync’}
Invoke-Command -Session $Session -ScriptBlock {Set-ADSyncScheduler -SyncCycleEnabled $false}
Invoke-Command -Session $Session -ScriptBlock {Get-ADSyncScheduler}

Confirm that the default AutoSyncCycle is set to “FALSE” as shown below. This confirms that the AutoSyncScheduler will not run every 30 minutes.
2.  Run the following PowerShell command to perform a Delta Import for the “ABC.NET” (On-Premises) AD connector remotely from a management server.

Invoke-Command -Session $Session -ScriptBlock {Invoke-ADSyncRunProfile -ConnectorName “” -RunProfileName “Delta Import”}

3.  Run the following PowerShell command to perform a Delta Sync for the “ABC.NET” (On-Premises) AD connector.

Invoke-Command -Session $Session -ScriptBlock {Invoke-ADSyncRunProfile -ConnectorName “” -RunProfileName “Delta Synchronization”}

4.  Run the following PowerShell command to monitor the Sync engine to see if its busy due to Delta Import command issued in the previous step.

Invoke-Command -Session $Session -ScriptBlock {Get-ADSyncConnectorRunStatus}

3“RunState” status of “Busy” means that the Delta Synchronization is currently running as shown above.
The cmdlet returns an empty result if the sync engine is idle and is not running a Connector as shown below.
4.  Run the following PowerShell command to “Export” (commit) all the changes to Azure AD connector “SKYNET.COM – AAD”.

Invoke-Command -Session $Session -ScriptBlock {Invoke-ADSyncRunProfile -ConnectorName “ – AAD” -RunProfileName “Export”}

5.  Finally, do not forget to turn back the “SyncCycle” back to its previous defaults by running the PowerShell command below.

Invoke-Command -Session $Session -ScriptBlock {Set-ADSyncScheduler -SyncCycleEnabled $true}


Microsoft 365 ATP: Anti-Phishing Policy/Sender Domain Hygiene (Lessons from the Field)

I was recently working on a project implementing Microsoft Advanced Threat Protection (ATP) on Office 365 services for one of our clients and have come across a few lessons learnt that hopefully might become useful for others out there & also looking into this great new feature from Microsoft!
LESSON 1: ATP Anti-Phishing Policy Not Working due to existing Spam policies
We created a new ATP Anti-Phishing policy where we added a bunch of Executive team users to protect them from being impersonated by attackers under “Add Users to Protect” setting. Unfortunately, the policy did not work as expected and we were still able to spoof users defined in this policy in spite of adding them explicitly under the policy settings.
What we found was that the Exchange Online SMTP verified domain was in the “Allowed Domain” in their “Spam Filter Policy” which overrides the settings in Anti-Phishing policy and hence any spoofed messages would skip filtering and will get delivered.
Removing the SMTP domain as an “Allowed Domain” under “Spam Filter Policy” fixed the issue and the ATP Ant-Phishing policy blocked any spoofed messages from that point on.
This highlights the importance of reviewing your existing EOP policies that may have been created to help ‘alleviate’ user noise around false positives.  While this original configuration certainly reduce false positives, it also significantly reduced the effectiveness of their spam detection!
Lesson 2: Post ATP Implementation, False Positives has increased
On the other side of the coin, after enabling ATP, it was noticed that a lot of emails were being marked as Spam/Spoof.  As it turns out, this is expected behaviour where sender email systems will be scrutinised by ATP for SPF, DMARC & DKIM standards.
After some investigations into the increase ‘false positives’, many of the emails which were being marked as Junk were coming from domains missing SPF records and hence ATP marks such messages as Junk. One common way to verify this is analysing message header using Test Connectivity tool from Microsoft for the affected messages and looking at the X-Forefront-AntiSpam-Report header which indicates missing SPF records.
Microsoft acknowledges this can happen in the specific article:
This highlights the double-edge sword that Office ATP provides.   It increases your sensitivity to spam email to protect your organisation, but it also relies on many technologies that fall in the realm of organizations to implement themselves to increase their own security and trust profile!  SPF and DKIM are pretty much the standard in ‘increasing’ the reputation of your email domain and to protect your own email services, but it requires IT Admins to proactively configure it for their own domains, and many  unfortunately still not reached that level of maturity!
Office ATP will certainly start showing you which of your partner organisations are still being ‘slack’ with their email security and should hopefully help you start the conversation to encourage them to do so!

Follow ...+

Kloud Blog - Follow