Lithnet AutoSync Trigger Scripting

After many years automating my MIM solutions with Event Broker/UnifyNow, I’m implementing a solution with Lithnet AutoSync. The result is the same event-driven sync as I’m used to, but I’ve had to get used to the different way AutoSync works.

I always liked how Event Broker allowed me to integrate PowerShell scripts with run profiles, and often used a “post-export script” to perform extra tasks that weren’t really worth a full PowerShell MA integration. With AutoSync the script trigger is provided to check the target system to see if an import should be run, perhaps also staging the import data first. However there’s no reason why I can’t also make some other changes, I just have to switch my thinking from a “post-export script” to a “pre-import script”.

NOTE: Ryan has now pointed out the Execution Controller Script functionality which I’m keen to have a play with next!

The trigger script goes in much the same way I’ve always written post-export scripts:

• Do an LDAP search to find users that need something doing,
• Do the thing,
• (If necessary) Update the user so it no longer satisfies the query.

Now with AutoSync I add an extra step:

• If any changes were made, run a Delta Import.

Here’s my basic trigger script for AD:

Import-Module ActiveDirectory
. D:\Scripts\lib\Set-LocalVariables.ps1
. D:\Scripts\lib\TargetFunctions.ps1

function Get-RunProfileToExecute 
{
    $changes = 0

    $changes = AD-CreateHomeFolder -changes $changes 
    $changes = AD-CreateMailbox -changes $changes -TargetDomainName $DomainName -SearchBase $StdUserOU
    $changes = AD-HideFromGAL -changes $changes -TargetDomainName $DomainName -ActiveOU $StdUserOU -TerminatedOU $TermUserOU
    $changes = AD-MailEnableDL -changes $changes -TargetDomainName $DomainName -SearchBase $GroupOU

    if ($changes -gt 0)
    {
        $p = New-Object Lithnet.Miiserver.Autosync.ExecutionParameters
        $p.RunProfileType = "DeltaImport"
        write-output $p
    }
}

I won’t post the code for all those functions, they’re just standard Exchange and home folder scripts, so just for an example, the AD-CreateMailbox function which mailbox-enables users looking like they need it:

<#
    AD-CreateMailbox

    Triggers mailbox creation for managed users where homeMDB is not populated. 
#>
function AD-CreateMailbox([int]$changes,[string]$TargetDomainName,[string]$SearchBase)
{
    $DC = (Get-ADDomainController -DomainName $TargetDomainName -Discover).HostName[0]

    $Filter = "(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2)(employeeNumber=*)(!(homeMDB=*)))"
    $Users = @(Get-ADUser -Server $DC -SearchBase $SearchBase -LDAPFilter $Filter)
    if ($Users.count -gt 0)
    {
        $PSSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ExchangeURI -Authentication Kerberos
        Import-PSSession $PSSession | out-null
        foreach ($user in $users)
        {
            Enable-Mailbox -Identity $user.SamAccountName -DomainController $DC | out-null
            $changes += 1
        }
        Remove-PSSession $PSSession | out-null
    }
    $changes
}

The final step is to create the trigger in AutoSync and schedule it to run at a high frequency. I’ve got mine running every 60 seconds and it doesn’t seem to cause any performance issues as the script does its LDAP searches and then goes straight back to sleep when there’s nothing to do. However if a new user is detected (or a new Distribution Group, or a terminated user needing to be hidden from the GAL) it does it’s thing quickly and the information about it flows straight back to the Portal where the Service Desk can see it.

All in all a good result, and thanks to Ryan for making such a great utility freely available!