ADSync Cmdlets

I really enjoyed the later versions of DirSync which included a native PowerShell Module to execute sync engine tasks and show some global configuration settings. Now that we are looking at moving over to the new tool AADSync there is a new module installed but with very little reference to it available on the web at time of writing this blog. I’ve outlined the name of the cmdlets below but the ‘Get-Help’ doesn’t offer any description or examples as yet so I’ve included some in this post.

Cmdlets

From browsing over these cmdlets we can see that there is much more functionality available to use then there was in the DirSync module equivalent. If we take nothing else away from this list it’s that we can now not just run the engine but configure the tool itself.

Examples

Here are some nice examples of what we can achieve now that ADSync Module is available

Example 1

Scenario: Create a custom rule to not sync users with X121Address=NoSync

[code language=”PowerShell”]
#Get the AD Connector
$ADConnector = (Get-ADSyncConnector | ? {$_.Type -eq "AD"})
#Create the Scope Filter Object
$scopefilter = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeCondition
$scopefilter.Attribute = "x121Address"
$scopefilter.ComparisonValue = "NoSync"
$scopefilter.ComparisonOperator = "EQUAL"
#Create the Attribute Flow
$AttributeFlowMappings = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.AttributeFlowMapping
$AttributeFlowMappings.Source = "True"
$AttributeFlowMappings.Destination = "cloudFiltered"
$AttributeFlowMappings.FlowType = "constant"
$AttributeFlowMappings.ExecuteOnce = $False
$AttributeFlowMappings.ValueMergeType = "Update"
#Add the Scope Filter to a Scope Group
$scopefiltergroup = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeConditionGroup
$scopefiltergroup.ScopeConditionList.Add($scopefilter)
#Create the Rule
$GUID = $ADConnector.Identifier.Guid
Add-ADSyncRule -Connector $GUID -Name "In from AD – User DoNotSyncFilter" -SourceObjectType user -TargetObjectType person -Direction inbound -AttributeFlowMappings $AttributeFlowMappings -LinkType Join -Precedence "1" -ScopeFilter $scopefiltergroup
[/code]

Example 2

Scenario: Add Additional Attributes to be imported from Active Directory

[code language=”PowerShell”]$ADConnector = (Get-ADSyncConnector | ? {$_.Type -eq "AD"}) | Add-ADSyncConnectorAttributeInclusion -AttributeTypes employeeID[/code]

Example 3

Scenario: Adjust the attribute flow of UPN so that AD Mail Attribute flows to UPN in Office 365

[code language=”PowerShell”]
#Define the Flow Mapping
$Mapping = New-object Microsoft.IdentityManagement.PowerShell.ObjectModel.AttributeFlowMapping
$Mapping.Source = "mail"
$Mapping.Destination = "userPrincipalName"
$Mapping.FlowType = "Direct"
$Mapping.ExecuteOnce = $false
$Mapping.Expression = $null
$Mapping.ValueMergeType = "update"
#Get the AD Connector
$ADConnector = (Get-ADSyncConnector | ? {$_.Type -eq "AD"})
$GUID = $ADConnector.Identifier.Guid
#Create the Rule with higher precedence
Add-ADSyncRule -Connector $GUID -Direction Inbound -Name "In From AD – User UPN Flow" -SourceObjectType user -TargetObjectType person -AttributeFlowMappings $Mapping -Description "Map Mail to UPN in the Metaverse" -LinkType Join -Precedence 99
[/code]

Here is the user sync’d to the Metaverse without Attribute Flow Transformation. (Note the UPN value)

We run the PowerShell and preview the results

Commit the change and check with a Metavere search

Let’s check Azure Active Directory. It has the prefix.

Happy days!

Some of these cmdlets seem to still need a little TLC. I found that they didn’t give the desired results although committing in the shell. We all love agile, so give it time and they should get fixed up, and there is always the GUI if you really have too.