Migration from on premises to Azure AD and Office 365 – Part 2

This post continues on from the last post (Migration from on premises to Azure AD and Office 365 – Part 1) where I discussed the issues arising from using the Azure AD Sync tool to sync the on site Active Directory objects to the Azure AD for use with Office 365, Sharepoint Online and other Microsoft Online Services.

The next issue we discovered was that a few objects would not sync to the cloud, looking closer we noticed this was a range of basic objects that create the default building blocks of the domain such as the ‘Domain Users’ group and the now renamed original ‘Administrator’ account.

Now these made very little difference to the operation of the Online Platform as these users and groups are not actually used on a regular basis. However, if something is not syncing as expected we have to assume that other objects that we do need may also be having issues. But something about the significance of them all being system objects made me suspicious that this would be expected behaviour.

That’s when I came across Microsoft KB2643629 and discovered that the Azure Ad Sync tool has a default scope that defines what objects are and are not synced.

The items that were not syncing had the active directory attribute ‘IsCriticalSystemObject’ set to true. I checked this out with a quick couple of powershell command

get-aduser -filter * -properties iscriticalsystemobject | where {$_.iscriticalsystemobject -eq $true}  | select name, iscriticalsystemobject | ft
get-adgroup -filter * -properties iscriticalsystemobject | where {$_.iscriticalsystemobject -eq $true}  | select name, iscriticalsystemobject | ft

We didn’t mind these objects not syncing (in fact for security, its better not to),  but if you find you need to check out this site that details how to change the relevant scoping of the sync client -> Exit Code Zero – DirSync Hints and Tips.

Now how to licence every user, We wanted to assign the ‘Microsoft Office 365 Plan E2′ but only the Sharepoint Online Part for the time being.
This can be achieved through the web interface
by signing into the Admin Section selecting users > Active Users > Change the view to the unlicensed users > Now select the users you wish to licence > in the bottom right an option appears to ‘Activate synced users‘, Selecting this allows you to set the exact requirements.

Or if you have more complex requirements, PowerShell wins again, this script is adapted from a script on TechNet by Trey Carlee

    # Disabled Plans
$disabledPlans= @()
$disabledPlans +=”MCOSTANDARD” # Lync Online (Plan 2)
$disabledPlans +=”EXCHANGE_S_STANDARD” # Exchange
$disabledPlans +=”SHAREPOINTWAC” # Office Online

# Setup License Options Object
$SPOnly = New-MsolLicenseOptions -AccountSkuId orgname:STANDARDWOFFPACK -DisabledPlans $disabledPlans

# Go through all unlicensed users
$unlicensedUsers = Get-MsolUser -All -UnlicensedUsersOnly
$i = 0
foreach ($msolUser in $unlicensedUsers) {
# Distinguish between users. Common variations include UPN (!$msol.User.Department)
foreach ($msolUser in $unlicensedUsers) {
if ($msolUser.UserPrincipalName.Contains(“domain.com”)) {
Write-host $i” – Setting “$msolUser.UserPrincipalName
# Set usage location. – Required for licensing
Set-MsolUser -UserPrincipalName $msolUser.UserPrincipalName -UsageLocation “GB”
# Apply SP-only license to each user
Set-MsolUserLicense -UserPrincipalName $msolUser.UserPrincipalName -AddLicenses orgname:STANDARDWOFFPACK -LicenseOptions $SPOnly


The last modification we made was to look into why updates took so long to reach the Azure online platform. Evidence pointed to a sync once every 3 hours, which is significant for most businesses. We found a config file in C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.config that could be opened with any text editor and the schedule changed. Restarting the service to ensure it reloads the config file was the last step.

We released this to the client and let them login and play with the new Sharepoint  Online.