Azure AD Connect Synch Errors

Azure AD Connect Synch Errors

We were experiencing increasing long synch times between our on-premise active directory and the Azure cloud databases, which became apparent during the use of our user account creation tools.

Since we are in hybrid mode, we have a mixed user population, some cloud, some on prem home mailboxes and depending on whether or not a team has been onboarded yet will determine where their mailbox is homed.

The script that creates the user account and mail enables it has to wait for AAD to synch before it can write the Exchange GUID of the cloud mailbox back to the remote mailbox on prem. This pause while synching started out being thirty minutes and ended up being more than three hours in some cases.

Some investigation time later and we identified this error on the Azure AD synch log:

The Azure hosted AD domain controllers had been reduced in size to A1 and stripped of the Windows GUI to offset this performance throttling, but it seems that at peak times of operation, the DCs couldn't cope with replication duties and synch pull requests from the Azure AD synch engine.

The issue was resolved by increasing the size of the VM back to A2 (from 1 core, 1.75GB RAM -> 2 core, 4GB RAM). Now we are not seeing any Azure AD Connect synch errors and the object synch intervals to Azure are within reasonable timeframes.

OnPrem DL Membership

OnPrem DL Membership Management

The hybrid configuration of an Office 365 environment poses many challenges.
This is especially true when the organisation spans many domains and partner entities.
With 6000 user and 7000 functional mailboxes to onboard to EXO, the business process for the migration to the cloud is complex and greatly exacerbated by a shared services model that entangles the dependancies of multi-departmental shared mailboxes.

To partially mitigate the online user losing the ability to manage onprem distribution groups, we are now asking our users to manage their own DL's via the DSQuery method:

C:\windows\system32\rundll32.exe dsquery,OpenQueryWindow

This is a less than ideal solution but at least we can continue to provide a means for end users to manage DL members across the online \ onprem boundary.

Ideally we would have batched the users to avoid this problem but in any large organisation this is impractical, especially if the configuration was not designed with this in mind.

Office 365 - Licensed Shared Mailboxes

We run a hybrid mode AD \ Exchange 2010 instance and are keen to keep licenses applied to only those resources that absolutely need them. As part of general housekeeping we need to ensure that shared mailboxes are not consuming a license and so I created this script to check for mailboxes that are of the type shared and are also assigned an Office 365 license.

#Get Your Office 365 credentials
$creds= get-credential -Message "Enter your Office 365 username and password"

#Connect to Azure and EXO
Connect-AzureAD -credential $creds
Connect-ExchangeOnline

#Grab the data that we require

$all_ncc_exo_users_exp = Get-AzureADUser -All $true|select UserPrincipalName -ExpandProperty AssignedPlans|Where-Object {$_.CapabilityStatus -eq "Enabled" -and $_.Service -eq "exchange"} |select -ExpandProperty UserPrincipalName -Unique 

$licensed_sharedmbs = $all_ncc_exo_users_exp |%{get-aduser -filter {userprincipalname -eq $_} -Properties distinguishedname }|where {($_ -match "generic") -and ($_ -notmatch "kitchen")}

write-host $licensed_sharedmbs|fl name, userprincipalname

As always, use at your own risk and post i the comments if you need a hand.