Querying msExchDelegateListLink in Exchange Online with PowerShell

There are a number of articles that describe the relationship between the FullAccess permission of an Exchange mailbox and the msExchDelegateListLink attribute. Here are two good ones:

In short, this attribute lists all the other mailboxes your mailbox has FullAccess to, unless AutoMapping was set to $false when assigning the permission. It can be a handy attribute to query when trying to learn what mailboxes might appear in an end-user’s Outlook profile.

This attribute is synced to Office 365 via Azure AD Connect, however, for whatever reason, it is not synced back on-premises for new or migrated mailboxes. It is also not exposed in Get-User, Get-Mailbox, Get-MailboxStatistics, Microsoft Graph or Azure AD Graph.

The information is however included in the user’s AutoDiscover XML response. This is how Outlook knows what mailboxes to mount. If you want to look at this data manually, use the ctrl+right-click tool from the Outlook icon on the system tray. This article describes how to do that, if somehow you’re reading this but don’t already know about this tool:

You can also look at the AutoDiscover XML file via the venerable TestConnectivity.Microsoft.com web site. Look at the bottom of of the file, and you’ll see “AlternativeMailbox” entries.

<AlternativeMailbox>

        <Type>Delegate</Type>

        <DisplayName>crowley test 1</DisplayName>

        <SmtpAddress>crowleytest1@mikecrowley.us</SmtpAddress>

        <OwnerSmtpAddress>crowleytest1@mikecrowley.us</OwnerSmtpAddress>

      </AlternativeMailbox>

      <AlternativeMailbox>

        <Type>Delegate</Type>

        <DisplayName>crowley test 2</DisplayName>

        <SmtpAddress>crowleytest2@mikecrowley.us</SmtpAddress>

        <OwnerSmtpAddress>crowleytest2@mikecrowley.us</OwnerSmtpAddress>

</AlternativeMailbox>

While not exactly the msExchDelegateListLink attribute, its the same difference.

This is neat, but to be useful at scale, we need to query this in PowerShell. Fortunately, there are two methods to fetch the AutoDiscover XML.

You can query these endpoints directly or through the the Exchange Web Services (EWS) API. If you don’t have a preference, Microsoft’s documentation recommends SOAP, which is the approach I’ll discuss here.

Using Invoke-WebRequest and SOAP, we can request specific attributes, such as AlternateMailboxes. Other useful attributes are listed in this article:

While I’m not a developer (developers, please keep your laughter to yourself!), I did manage to cobble together the following SOAP request, which will be the string we “post” to the AutoDiscover service. You’ll notice I’ve marked the user we’re querying and any attributes I might want in bold (modify this list to suit your needs):

<soap:Envelope xmlns:a=”http://schemas.microsoft.com/exchange/2010/Autodiscover&#8221;
xmlns:wsa=”http://www.w3.org/2005/08/addressing&#8221;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221;
xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope/”&gt;
<soap:Header>
<a:RequestedServerVersion>Exchange2013</a:RequestedServerVersion>
<wsa:Action>http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetUserSettings</wsa:Action&gt;
<wsa:To>https://autodiscover.exchange.microsoft.com/autodiscover/autodiscover.svc</wsa:To&gt;
</soap:Header>
<soap:Body>
<a:GetUserSettingsRequestMessage xmlns:a=”http://schemas.microsoft.com/exchange/2010/Autodiscover”&gt;
<a:Request>
<a:Users>
<a:User>
<a:Mailbox>bob@contoso.com</a:Mailbox>
</a:User>
</a:Users>
<a:RequestedSettings>
<a:Setting>UserDisplayName</a:Setting>
<a:Setting>UserDN</a:Setting>
<a:Setting>UserDeploymentId</a:Setting>
<a:Setting>MailboxDN</a:Setting>
<a:Setting>AlternateMailboxes</a:Setting>
</a:RequestedSettings>
</a:Request>
</a:GetUserSettingsRequestMessage>
</soap:Body>
</soap:Envelope>

(For this post, I only care about AlternateMailboxes.)

AutoDiscover requires authentication, so we’ll also need to use the Get-Credential cmdlet. Interestingly, any mailbox can query the AutoDiscover response for any other user in the Office 365 tenant. This means, through PowerShell, I can look up the msExchDelegateListLink / AlternativeMailbox values for other users (even without administrative privileges).

I’ve written a function to return the results in a PowerShell array like this:

Get-AlternateMailboxes-Example

 

I should also point out:

  • It has the Exchange Online URL hard-coded within, though you could adapt this for other URLs if you’d like.
  • Both SMTPAddress and Credential parameters require valid Exchange Online mailboxes (though, as previously mentioned they do not need to be the same mailbox).

Usage Example:

Get-AlternateMailboxes -SMTPAddress bob@contoso.com -Credential (Get-Credential)

Finally, here is the script itself:

 

Skype for Business Online Cloud PBX: Picking Good Numbers

Not your granddaddy’s SfBO

Late last year, Microsoft released a dial-in conferencing and PSTN add-on to the popular Office 365 suite. With these new features, I expect Skype for Business Online to attract serious interest. As a technical implementer, if you’re Office 365 focus has been limited to Exchange and SharePoint Online, you’ll want to be sure you’re positioned to support these new features before your competition beats you to it!

For an excellent, no-fluff introduction to the topic, I recommend you read fellow MVP Paul Robichaux’s article over on WindowsITPro: “Skype for Business: PSTN Calling

Selecting Pleasant Telephone Numbers

One of the first things you’ll want to do after you’ve got the necessary licensing situated is to assign phone numbers to your users. If you’re using the Admin Center, you’ll find this approach is documented here.

When using this screen to assign numbers to my business, I found that the numbers that were being presented weren’t very palatable.AdminCenterNumbers

Obviously this is a subjective assessment, though as an example, you’ll likely agree that numbers that end in ‘0000’ are generally more desirable and memorable than those that involve digits from all over your dial pad. Maybe there is some secret TelCo handshake which allows you to pick from great phone numbers, but alas, I don’t know it. 😦

Perhaps more frustratingly, is the fact the portal limits you by showing only a few numbers at a time (per 10 minutes). Based on my business’ location in in Maryland, I wanted a 301 number, but am I supposed to look at 10 numbers every 10 minutes? I’ve not done this with a large tenant yet, so it is possible this UI scales with more licenses/users, but in my testing I couldn’t find a way around this issue.

The good news however, is that PowerShell once again comes to the rescue! Using the Skype for Business Online cmdlets, we are able to bypass the selection limits of the Admin Center and view up to 200 numbers, in a given city, at a time.

The approach is as follows:

  1. Download and install the SfBO PowerShell module.
  2. Establish a PowerShell remoting session.
  3. Figure out what region you want numbers for, and take note of the geocodes.
  4. Search the inventory, reserving 200 numbers for 10 minutes.
  5. If necessary, manually release the numbers and look at another region.
  6. If all else fails, wait 10+ minutes and re-try the above.

Search and Filter with PowerShell

Connect to SfBO

$credential = Get-Credential mike@contoso.com
$lyncSession = New-CsOnlineSession -Credential $credential
Import-PSSession $lyncSession

Search the inventory

$x = Search-CsOnlineTelephoneNumberInventory -InventoryType Subscriber -Region NOAM -Country US -Area MD -City SS -Quantity 200
Get-CsOnlineTelephoneNumberReservationsInformation

$x.Reservations.numbers.DisplayNumber

Use PowerShell filtering to find desirable number patterns

#Numbers with 00
$x.Reservations.numbers.DisplayNumber | ? {$_ -like '*00*'}

#Numbers ending in 0
$x.Reservations.numbers.DisplayNumber | ? {$_ -like '*0'}

#Numbers not containing 304
$x.Reservations.numbers.DisplayNumber | ? {$_ -notlike '*304*'}

#Numbers with 0 in the last group
$x.Reservations.numbers.DisplayNumber | ? {(($_ -split ' ' )[-1]) -like '*0*'}

PowerShell PSTN FilteringRelease the numbers and look at a different region (avoiding the 10 minute wait)

Clear-CsOnlineTelephoneNumberReservation -ReservationId $x.ReservationId -InventoryType subscriber
$x = Search-CsOnlineTelephoneNumberInventory -InventoryType Subscriber -Region NOAM -Country US -Area MD -City BE -Quantity 200

$x.Reservations.numbers.DisplayNumber

Select the numbers you like (Don’t forget to include the country code)

Select-CsOnlineTelephoneNumberInventory -ReservationId $x.ReservationId -TelephoneNumbers 13010000000, 13010000003, 13010000002 -Region NOAM -Country US -Area MD -City SS

NOTE: I haven’t worked out the code myself, but you may want to find phone numbers in consecutive blocks, so here is a topic that discusses how to do that.

Once you’ve got the numbers reserved, you can continue to use PowerShell to assign them to your licensed users, or you can go back to the Admin Center and assign them there.

——————– EDIT: December 2016 ——————–

The GeoCode documentation is being depricated. To determine your GeoCode utilize these cmdlets

e.g.

Get-CsOnlineTelephoneNumberInventoryRegions -InventoryType Subscriber
Get-CsOnlineTelephoneNumberInventoryCountries -InventoryType Subscriber -RegionalGroup NOAM
Get-CsOnlineTelephoneNumberInventoryAreas -InventoryType Subscriber -RegionalGroup NOAM -CountryOrRegion US
Get-CsOnlineTelephoneNumberInventoryCities -InventoryType Subscriber -RegionalGroup NOAM -CountryOrRegion US -Area MD

Enabling/Disabling AAD Connect’s Automatic Upgrade Feature

Last week, Microsoft announced this quarter’s Azure Active Directory Connect (AADConnect) update. Version 1.1 (download) includes some big changes, including one that made me worry. AAD Connect now has an Automatic Upgrade feature! Given that this is the first version to include this concept, we won’t see how it works until next quarter, but I sure do hope they are careful.

Cautiously Optimistic

Over the past few years we’ve seen several DirSync/AADSync/AADConnect versions be revoked due to bugs, which means you could wake up one morning to some terrible sync catastrophe resulting from bad sync rules or who knows what. Case in point: THIS VERSION!!! You’ll see in the comments of the announcement I linked above, several people had problems with the upgrade to the 1.1 build and Microsoft quickly released a new version 4 days ago (1.1.110.0). Nevertheless, I believe such a sync-related catastrophe is unlikely. The greater risk is letting your sync software get too out of date, which is something I see more often than I don’t. In fact, Microsoft’s sync tools have been so reliable that many organizations are probably still running the same version deployed when they first migrated to Office 365 (Though they are possibly in an unsupported scenario).AADConnect Auto Upgrade

New installations of AAD Connect which use the default “Express” option will enable Automatic Upgrade for you.

I did an in-place upgrade from a prior version to 1.1.110.0 and it left Auto Upgrade in a “Suspended” state, which is not to be confused with “Disabled”. I’m not sure why we need two “not-enabled” states, but it is described in the documentation as a system-only value. It will be easier to test this when there is actually a version beyond 1.1.110.0 to upgrade to.

I think it is interesting that this product doesn’t hook into the operating system’s Automatic Update feature, as most Microsoft products do. My theory is that the Azure AD team is currently moving faster than the requisite internal coordination allows.AADConnect Auto Upgrade 2

Disabling Automatic Upgrade

I would discourage anyone from turning off Automatic Upgrade without good cause (FUD does not count), though there may be some good causes.

For example, while Microsoft discourages us from modifying the default synchronization rules (The product has pop-ups warning you about this too), it is supported. The caveat is that upgrades sometimes redefine the default rules, overwriting your changes. In this case, the guidance states:

If you need to change the scope or the join setting in an “out-of-box” synchronization rule, document this and reapply the change after upgrading to a newer version of Azure AD Connect

As you have probably guessed, this scenario presents a problem with the idea of an automatic upgrade. Luckily for this, and perhaps other reasons, you can disable Automatic Upgrade. There are two new cmdlets for controlling the behavior:

  • Get-ADSyncAutoUpgrade
  • Set-ADSyncAutoUpgrade

Get-ADSyncAutoUpgrade will show you the current state, which will be Enabled, Disabled or Suspended. You can also see this by looking the AAD Connect summary page (second image above).

To disable AAD Connect’s Automatic Upgrade feature, type:

Set-ADSyncAutoUpgrade -AutoUpgradeState Disabled

Enabling Automatic Upgrade

If you need to enable the feature, type:

Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled

Presenting at the Rockville, MD Office 365 User Group

If you’ve been here once or twice, you’ll know I like talking about Office 365 and Azure AD Directory Synchronization! If you like this topic too, or are preparing for an upcoming migration, and are in the Washington DC Metro Area next Thursday (Nov. 12), please come to the Rockville-based Office 365 user group meeting.

Rockville Office 365 User Group

During this event, I’ll be covering sync across the following agenda:

  1. Introduction to concepts
  2. Environment Readiness
  3. Tools
  4. Operations and Troubleshooting
  5. Q&A

Attendance is free but please RSVP here:

Azure AD Connect PowerShell Cmdlets

documentation

Click the image!

Microsoft TechNet used to be one of the best documentation libraries in the industry. Sadly, it still is; so what’s that tell you about the industry today?

Office 365 and Azure are truly great cloud services, but the frequency of updates and new releases are a challenge for Microsoft’s own sales team to keep up with, let alone us in the field, trying to work with the stuff. As made abundantly clear by their actions (e.g. killing tech conferences, technical writer layoffs, shuttering TechNet subscriptions, and abandoning the MCM program), Microsoft doesn’t really see “the problem”.

When Microsoft shipped DirSync and then later Azure AD Sync, documentation of the associated PowerShell modules became increasingly sparse, though some cmdlets did have a help synopsis, as I discussed last year. Azure AD Connect, the current version of Office 365 and Azure Active Directory synchronization technology, has 69 cmdlets in the “ADSync” module.

Wanna take a guess at how many of these have an associated help topic? Don’t forget, this product was launched earlier this summer and is now on it’s second public release.

Zero

(Pause for effect)

So, I have listed all 69 cmdlets here, with a brief note about what I’ve found so far. Right now, most are empty, but I will fill them in as I discover their purpose and/or have more time. If you’ve got a question about one I don’t have detailed, leave a comment and I’ll try to prioritize some research for you. I haven’t checked with the Azure AD team on this, so please take my findings with a grain of salt, and hope for real support documentation to arrive soon!

NOTE: This refers to the “ADSync” module that ships with Azure AD Connect 1.0.8667.0.

Cmdlet

Add-ADSyncAADServiceAccount

My
Comments

Sample
Usage

 

Cmdlet

Add-ADSyncAttributeFlowMapping

My
Comments

Maps a source to target
attribute.

Export one of the rules
from the editor to see this and other samples.

Sample
Usage

Add-ADSyncAttributeFlowMapping  `

-SynchronizationRule $syncRule[0] `

-Source @(‘mailNickname’,‘sAMAccountName’)
`

-Destination ‘cloudFiltered’
`

-FlowType ‘Expression’
`

-ValueMergeType ‘Update’ `

-Expression ‘IIF(IsPresent([isCriticalSystemObject])
|| IsPresent([sAMAccountName]) = False || [sAMAccountName] =
“SUPPORT_388945a0” || Left([mailNickname], 14) =
“SystemMailbox{” || Left([sAMAccountName], 4) = “AAD_” ||
(Left([mailNickname], 4) = “CAS_” && (InStr([mailNickname],
“}”) > 0)) || (Left([sAMAccountName], 4) = “CAS_”
&& (InStr([sAMAccountName], “}”) > 0)) ||
Left([sAMAccountName], 5) = “MSOL_” ||
CBool(IIF(IsPresent([msExchRecipientTypeDetails]),BitAnd([msExchRecipientTypeDetails],&H21C07000)
> 0,NULL)) ||
CBool(InStr(DNComponent(CRef([dn]),1),”\\0ACNF:”)>0), True,
NULL)’
`

-OutVariable syncRule

Cmdlet

Add-ADSyncConnector

My
Comments

Sample
Usage

 

Cmdlet

Add-ADSyncConnectorAnchorConstructionSettings

My
Comments

Sample
Usage

 

 

Cmdlet

Add-ADSyncConnectorAttributeInclusion

My
Comments

Sample
Usage

 

 

Cmdlet

Add-ADSyncConnectorHierarchyProvisioningMapping

My
Comments

Sample
Usage

 

 

Cmdlet

Add-ADSyncConnectorObjectInclusion

My
Comments

Sample
Usage

 

Cmdlet

Add-ADSyncGlobalSettingsParameter

My
Comments

Sample
Usage

 

Cmdlet

Add-ADSyncJoinConditionGroup

My
Comments

Used in the construction of
sync rules.

Export one of the rules
from the editor to see this and other samples.

Sample
Usage

Add-ADSyncJoinConditionGroup  `

-SynchronizationRule $syncRule[0] `

-JoinConditions @($condition0[0]) `

-OutVariable syncRule

Cmdlet

Add-ADSyncRule

My
Comments

Export one of the rules
from the editor to see this and other

samples.

Sample
Usage

Add-ADSyncRule  `

-SynchronizationRule $syncRule[0]

Cmdlet

Add-ADSyncRunProfile

My
Comments

Sample
Usage

 

Cmdlet

Add-ADSyncRunStep

My
Comments

Sample
Usage

 

Cmdlet

Add-ADSyncScopeConditionGroup

My
Comments

Used in the construction of
sync rules.

Export one of the rules
from the editor to see this and other samples.

Sample
Usage

Add-ADSyncScopeConditionGroup  `

-SynchronizationRule $syncRule[0] `

-ScopeConditions @($condition0[0],$condition1[0],$condition2[0]) `

-OutVariable syncRule

Cmdlet

Disable-ADSyncConnectorPartition

My
Comments

Sample
Usage

 

Cmdlet

Disable-ADSyncConnectorPartitionHierarchy

My
Comments

Sample
Usage

 

Cmdlet

Disable-ADSyncExportDeletionThreshold

My
Comments

 Disables the accidental deletion safety feature.

More info here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-feature-prevent-accidental-deletes/

Sample
Usage

 Disable-ADSyncExportDeletionThreshold

Cmdlet

Enable-ADSyncConnectorPartition

My
Comments

Sample
Usage

 

Cmdlet

Enable-ADSyncConnectorPartitionHierarchy

My
Comments

Sample
Usage

 

Cmdlet

Enable-ADSyncExportDeletionThreshold

My
Comments

 Enables the accidental deletion safety feature. To verify, run Get-MsolDirSyncConfiguration.More info here: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-feature-prevent-accidental-deletes/

Sample
Usage

Enable-ADSyncExportDeletionThreshold

Cmdlet

Get-ADSyncAADPasswordResetConfiguration

My
Comments

I believe this is used to
report on password write-back.

Sample
Usage

Get-ADSyncAADPasswordResetConfiguration -Connector ‘demo1923.onmicrosoft.com – AAD’

 

Cmdlet

Get-ADSyncAADPasswordSyncConfiguration

My
Comments

Indicates whether or not
password hash sync is enabled (SYNC)

Sample
Usage

Get-ADSyncAADPasswordSyncConfiguration -SourceConnector ‘laptop.lab’

Cmdlet

Get-ADSyncConnector

My
Comments

Gets the management agents
(connectors) used by the sync service.

Sample
Usage

Get-ADSyncConnector

Cmdlet

Get-ADSyncConnectorHierarchyProvisioningDNComponent

My
Comments

Couldn’t get it to work

Sample
Usage

x =
Get-ADSyncConnector -Name
‘laptop.lab’

Get-ADSyncConnectorHierarchyProvisioningDNComponent -ShowHidden -Connector $x

Cmdlet

Get-ADSyncConnectorHierarchyProvisioningMapping

My
Comments

Couldn’t get it to work

Sample
Usage

$x =
Get-ADSyncConnector -Name
‘laptop.lab’

Get-ADSyncConnectorHierarchyProvisioningMapping -Connector $x

Cmdlet

Get-ADSyncConnectorHierarchyProvisioningObjectClass

My
Comments

Didn’t test: I presume it
lists the objects to be synced (e.g. people, contacts, etc)

Sample
Usage

 

 

Cmdlet

Get-ADSyncConnectorParameter

My
Comments

Sample
Usage

 

Cmdlet

Get-ADSyncConnectorPartition

My
Comments

Sample
Usage

 

Cmdlet

Get-ADSyncConnectorPartitionHierarchy

My
Comments

Sample
Usage

 

Cmdlet

Get-ADSyncConnectorTypes

My
Comments

Sample
Usage

 

Cmdlet

Get-ADSyncGlobalSettings

My
Comments

Displays Global
Configuration Settings.

Sample
Usage

  (Get-ADSyncGlobalSettings).Parameters
| Where name -eq Microsoft.SynchronizationOption.AnchorAttribute

Cmdlet

Get-ADSyncGlobalSettingsParameter

My
Comments

Sample
Usage

 

Cmdlet

Get-ADSyncRule

My
Comments

 Lists the sync rules

Sample
Usage

 

Cmdlet

Get-ADSyncRunProfile

My
Comments

Sample
Usage

 

Cmdlet

Get-ADSyncSchema

My
Comments

Sample
Usage

 

 

Cmdlet

Get-ADSyncServerConfiguration

My
Comments

Sample
Usage

 

Cmdlet

New-ADSyncConnector

My
Comments

Sample
Usage

 

Cmdlet

New-ADSyncJoinCondition

My
Comments

Sample
Usage

 

Cmdlet

New-ADSyncRule

My
Comments

Export one of the rules
from the editor to see this and other samples.

Sample
Usage

New-ADSyncRule  `

-Name ‘In from
AD – User Join’
`

-Identifier ‘c2db05cb-39bd-4e17-a19a-26718c692e48’
`

-Description
`

-Direction ‘Inbound’
`

-Precedence 100
`

-PrecedenceAfter ‘00000000-0000-0000-0000-000000000000’ `

-PrecedenceBefore ‘00000000-0000-0000-0000-000000000000’ `

-SourceObjectType ‘user’ `

-TargetObjectType ‘person’ `

-Connector ‘43617e64-d544-4426-9354-e7d7508915b1’
`

-LinkType ‘Provision’
`

-SoftDeleteExpiryInterval 0 `

-ImmutableTag ‘Microsoft.InfromADUserJoin.003’ `

-OutVariable syncRule

Cmdlet

New-ADSyncRunProfile

My
Comments

Sample
Usage

 

Cmdlet

New-ADSyncScopeCondition

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncAADPasswordResetConfiguration

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncAADPasswordSyncConfiguration

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncAADServiceAccount

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncAttributeFlowMapping

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncConnector

My
Comments

 Removes one of your Management Agents (Connectors)

Sample
Usage

 

Cmdlet

Remove-ADSyncConnectorAnchorConstructionSettings

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncConnectorAttributeInclusion

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncConnectorHierarchyProvisioningMapping

My
Comments

Sample
Usage

 

 

Cmdlet

Remove-ADSyncConnectorObjectInclusion

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncGlobalSettingsParameter

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncJoinConditionGroup

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncRule

My
Comments

 Removes a sync rule.

Sample
Usage

 

Cmdlet

Remove-ADSyncRunProfile

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncRunStep

My
Comments

Sample
Usage

 

Cmdlet

Remove-ADSyncScopeConditionGroup

My
Comments

Sample
Usage

 

Cmdlet

Search-ADSyncDirectoryObjects

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncAADCompanyFeature

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncAADPasswordResetConfiguration

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncAADPasswordSyncConfiguration

My
Comments

 See details here:  http://blogs.technet.com/b/undocumentedfeatures/archive/2015/11/18/reset-aadsync-or-aadconnect-password-hash-sync-configuration.aspx

Sample
Usage

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -TargetConnector $aadConnector -Enable $false

Cmdlet

Set-ADSyncAADPasswordSyncState

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncConnectorParameter

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncGlobalSettings

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncSchema

My
Comments

Sample
Usage

 

Cmdlet

Set-ADSyncServerConfiguration

My
Comments

Sample
Usage

 

Cmdlet

Set-MIISADMAConfiguration

My
Comments

Sample
Usage

 

Cmdlet

Test-AdSyncUserHasPermissions

My
Comments

Sample
Usage

 

Cmdlet

Update-ADSyncConnectorPartition

My
Comments

Sample
Usage

 

Cmdlet

Update-ADSyncConnectorSchema

My
Comments

Sample
Usage

 

Cmdlet

Update-ADSyncDRSCertificates

My
Comments

Sample
Usage

 

I’m Speaking @ IT/Dev Connections – UPDATED!

ImSpeakingAtDevConnections

I am 34,000 feet in the air at the moment, headed to the IT / Dev Connections conference in Las Vegas, Nevada! Judging by the list of sessions and speakers, I expect this to be a great event. I am also very interested to see how many of you all are in attendance, especially since Microsoft has killed so many of their conferences (MEC, MMS, etc).

I have once again been given an opportunity to present at this seminar, so I invite you to attend both of my sessions:

 Tuesday @ 1:45 in Pinyon 2 – Exchange Online Protection In-Depth

 Wednesday @ 1:15 in Pinyon 2 – Mastering PowerShell for Exchange Online

This blog post will also serve as the means to download my PowerPoint presentations as well as the PowerShell samples, so check back after my sessions are over for those.

UPDATE:

Thanks for everyone who attended my sessions! Here are the resources as promised:

What are the Azure DirSync Cmdlets [Updated]?

ARTICLE UPDATED August 2014 to address the PowerShellConfig module.

NOTE: If you are using Azure AD Connect, see this new article.

As you may have seen, DirSync’s PowerShell functionality can now be called from the “Import-Module” cmdlet instead of running a custom DirSyncConfigShell.psc1 file. If we look at this new module, we can see 92 DirSync-related cmdlets:

DirSync PowerShell Module

Notice the screenshot is actually listing the commands of the “Microsoft.Online.Coexistence.PS.Config module” and “PowerShellConfig” (very descriptive!), not “DirSync”. That is because the DirSync module is a wrapper of sorts, calling “%programfiles% \Windows Azure Active Directory Sync\dirsync\DirSync.psd1” on your behalf. The DirSync module itself contains no cmdlets.

So, what do these cmdlets do anyway? Not all of them are well documented online, so you should start with the help file. Unfortunatley, even the help file omits a synopsis for the 67 “PowerShellConfig” cmdlets.  For the 25 within Microsoft.Online.Coexistence.PS.Config module, run the below command to generate an output similar to the following table:

ipmo DirSync
gcm -m Microsoft.Online.Coexistence.PS.Config | get-help | select name, synopsis | epcsv $env:userprofile\desktop\DirSyncCmdlets.csv -notype


Name

Synopsis

Disable-DirSyncLog

This commandlet is used to disable logging for the Azure Active Directory Sync tool.

Disable-MSOnlineObjectManagement Disable-MSOnlineObjectManagement -Credential <pscredential> [-ObjectTypes <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]
Disable-MSOnlinePasswordSync Disable-MSOnlinePasswordSync -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Disable-MSOnlineRichCoexistence Disable-MSOnlineRichCoexistence -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Disable-OnlinePasswordWriteBack

This commandlet is used to disable writing back user password resets from cloud to onpremise Active Directory.

Disable-PasswordSyncLog

This commandlet is used to disable logging for the Password Sync feature of the Azure Active Directory Sync tool.

Enable-DirSyncLog

This commandlet is used to configure the logging level for the Azure Active Directory Sync tool.

Enable-MSOnlineObjectManagement Enable-MSOnlineObjectManagement -ObjectTypes <string[]> -TargetCredentials <pscredential> -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Enable-MSOnlinePasswordSync Enable-MSOnlinePasswordSync -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Enable-MSOnlineRichCoexistence Enable-MSOnlineRichCoexistence -Credential <pscredential> [-WhatIf] [-Confirm] [<CommonParameters>]
Enable-OnlinePasswordWriteBack

This commandlet is used to enable writing back user password resets from cloud to onpremise Active Directory.

Enable-PasswordSyncLog

This commandlet is used to configure the logging level for the Password Sync feature of the Azure Active Directory Sync tool.

Get-CoexistenceConfiguration

Gets a configuration information from the Microsoft Online Coexistence Web Server

Get-DirSyncConfiguration Get-DirSyncConfiguration -TargetCredentials <pscredential> [<CommonParameters>]
Get-DirSyncLogStatus

This commandlet is used to retrieve the current logging level for the Azure Active Directory Sync tool.

Get-OnlinePasswordWriteBackStatus

This commandlet is used to obtain the current status of writing back user password resets from cloud to onpremise Active Directory.

Get-PasswordSyncLogStatus

This commandlet is used to retrieve the current logging level for the Password Sync feature of the Azure Active Directory Sync tool.

Get-PreventAccidentalDeletes

This commandlet is used to retrieve the current status of the object deletion threshold for DirSync.

Set-CoexistenceConfiguration

Configures Microsoft Online Directory Synchronization Tool.

Set-CompanyDirSyncFeatures Set-CompanyDirSyncFeatures -TargetCredentials <pscredential> -FeaturesFlag <int> [<CommonParameters>]
Set-DirSyncConfiguration Set-DirSyncConfiguration -TargetCredentials <pscredential> -DirSyncConfiguration <CloudDirSyncConfiguration> [<CommonParameters>]
Set-FullPasswordSync

Resets the password sync state information forcing a full sync the next time the service is restarted.

Set-PreventAccidentalDeletes

This commandlet is used to enable or disable the object deletion threshold for DirSync.

Start-OnlineCoexistenceSync

Starts synchronization with Microsoft Online

Update-MSOLDirSyncNetworkProxySetting

Updates the directory sync service to use the current user’s http proxy settings.

The de-“magicification” of DirSync is definitely a good thing for all Azure customers.  Having said this, I’d still keep the Codeplex FIM modules around, since they do offer a lot more control of and visibility into the underlying FIM Sync Service.

Here are the cmdlets without help documentation:

 Add-AttributeFlowMapping
 Add-ConfigurationParameter
 Add-ConnectorAnchorConstructionSettings
 Add-ConnectorAttributeInclusion
 Add-ConnectorFilter
 Add-ConnectorHierarchyProvisioningMapping
 Add-ConnectorObjectInclusion
 Add-RelationshipConditionGrouping
 Add-RunStep
 Add-SynchronizationConditionGrouping
 Disable-ConnectorPartition
 Disable-ConnectorPartitionHierarchy
 Enable-ConnectorPartition
 Enable-ConnectorPartitionHierarchy
 Export-ServerConfiguration
 Get-AADConnectorPasswordResetConfiguration
 Get-ConfigurationParameter
 Get-Connector
 Get-ConnectorHierarchyProvisioningDNComponent
 Get-ConnectorHierarchyProvisioningMapping
 Get-ConnectorHierarchyProvisioningObjectClass
 Get-ConnectorPartition
 Get-ConnectorPartitionHierarchy
 Get-ConnectorTypes
 Get-GlobalSettings
 Get-PasswordHashSyncConfiguration
 Get-RunProfile
 Get-Schema
 Get-SynchronizationRule
 Import-MIISServerConfig
 Import-ServerConfiguration
 Initialize-Connector
 Initialize-RunProfile
 Initialize-SynchronizationRule
 New-Connector
 New-RunProfile
 New-SynchronizationRule
 Remove-AADConnectorPasswordResetConfiguration
 Remove-AttributeFlowMapping
 Remove-ConfigurationParameter
 Remove-Connector
 Remove-ConnectorAnchorConstructionSettings
 Remove-ConnectorAttributeInclusion
 Remove-ConnectorFilter
 Remove-ConnectorHierarchyProvisioningMapping
 Remove-ConnectorObjectInclusion
 Remove-PasswordHashSyncConfiguration
 Remove-RelationshipConditionGrouping
 Remove-RunProfile
 Remove-RunStep
 Remove-SynchronizationConditionGrouping
 Remove-SynchronizationRule
 Set-AADConnectorPasswordResetConfiguration
 Set-ConfigurationParameter
 Set-Connector
 Set-GlobalSettings
 Set-MIISADMAConfiguration
 Set-MIISECMA2Configuration
 Set-MIISExtMAConfiguration
 Set-MIISFIMMAConfiguration
 Set-PasswordHashSyncConfiguration
 Set-ProvisioningRulesExtension
 Set-RunProfile
 Set-Schema
 Set-SynchronizationRule
 Update-ConnectorPartition
 Update-ConnectorSchema

As time allows, I will return with more detail on each of the above DirSync cmdlets; so long for now!

Backup and Restore Instructions for the DirSync Database

Today, Microsoft released a 9 page guide on backing up and restoring the Microsoft Azure Active Directory Sync tool. You can get it here.

Some things to keep in mind:

  • This guide applies to DirSync when used with the full version of SQL only.  This means it does not apply to most installations.
  • You don’t need to backup or restore DirSync.  If you simply install a new instance and configure it appropriately, the objects will re-sync.  Doing a backup/restore can save time however, if you have a very large number of users (I wouldn’t bother with less than 100k).
  • Ironically, this guide doesn’t actually tell you how to backup or restore the database.  You need some SQL-aware backup product to do that.  Instead, this guide helps you make use of a restored database in a DirSync environment (working with miisclient.exe, handling keys, etc).

DirSync 1.0.6593.0012

Late Monday, Microsoft released another update to the DirSync software, this time with a build number of 6593.0012. You can download it in from the usual link.

DirSync 1.0.6593.0012

As with previous DirSync updates, there has been no official announcement of the release, however the “use at your own risk” Wiki does mention one of the new features:

Version 6593.0012
Date Released 2/3/2014
Notable Changes

New features:

  • Additional Attributes are synchronized on User and Contact objects

Attributes documented here

The new attributes referenced in the link are userCertificate and userSMIMECertificate. Interestingly pwdLastSet was also added, however there is no mention of that one in the article. These additions serve an unknown purpose for now, however one might speculate that they are in support of new capabilities soon to be available in the service?!

Before you upgrade, you may wish to get a “before and after” review of the attribute inclusion list. The best way to review this is in the “Configure Attribute Flow” area of each management agent. At the end of this post, I have also shared an experimental PowerShell method of getting this information.

It is noteworthy that the author of this update, a Microsoft Program Manager for DirSync, is linking to yet another community wiki page instead of the seemingly defunct Knowledge Base article KB-2256198. Sadly, it would appear that the crumbling integrity of the TechNet/Support documentation may be latest casualty in a growing list of IT Pro-related cuts Microsoft has made along their quest to the cloud…

<#
Description:
This script counts and dumps the attribute inclusion lists from each MA.
It does not evaluate attribute flow or applicable object types.

February 3 2014
Mike Crowley
http://mikecrowley.us
#>

#Import Modules
Import-Module SQLps -WarningAction SilentlyContinue

#Get SQL Info
$SQLServer = (gp 'HKLM:SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters').Server
if ($SQLServer.Length -eq '0') {$SQLServer = $env:computername}
$SQLInstance = (gp 'HKLM:SYSTEM\CurrentControlSet\services\FIMSynchronizationService\Parameters').SQLInstance
$MSOLInstance = ($SQLServer + "\" + $SQLInstance)

#Get Management Agent Attribute Info
[xml]$OnPremAttributes = (Invoke-Sqlcmd -MaxCharLength 10000 -ServerInstance $MSOLInstance -Query "SELECT attribute_inclusion_xml FROM [FIMSynchronizationService].[dbo].[mms_management_agent] WHERE [ma_name] = 'Active Directory Connector'").attribute_inclusion_xml
[xml]$CloudAttributes = (Invoke-Sqlcmd -MaxCharLength 10000 -ServerInstance $MSOLInstance -Query "SELECT attribute_inclusion_xml FROM [FIMSynchronizationService].[dbo].[mms_management_agent] WHERE [ma_name] = 'Windows Azure Active Directory Connector'").attribute_inclusion_xml
$ADAttributes = $OnPremAttributes.'attribute-inclusion'.attribute
$AzureAttributes = $CloudAttributes.'attribute-inclusion'.attribute

#Output to Screen
Write-Host $ADAttributes.count "Attributes synced from AD to the Metaverse" -F Cyan
Write-Host $AzureAttributes.count "Attributes synced from the Metaverse to Azure" -F Cyan
Write-Host "See" $env:TEMP\DirSyncAttributeList.txt "for detail" -F Cyan

#Output to File
"******AD Attributes******" | Out-File $env:TEMP\DirSyncAttributeList.txt
$ADAttributes | Out-File $env:TEMP\DirSyncAttributeList.txt -Append
" "| Out-File $env:TEMP\DirSyncAttributeList.txt -Append
"******Azure Attributes******" | Out-File $env:TEMP\DirSyncAttributeList.txt -Append
$AzureAttributes | Out-File $env:TEMP\DirSyncAttributeList.txt -Append

##END

DirSync 1.0.6567.0018 Has Been Released

As some of us noticed, last week, Microsoft quietly removed the latest version of DirSync without so much as a tweet explaining why. Word on the street is that there were issues in the “Export” stage in the synchronization process (see KB 2906832). Today it would appear those issues have been resolved, as v1.0.6567.0018 just hit the web. You can download it here, though I’d advise caution, given Microsoft’s approach to communicating (lack-thereof) bugs.

As stated in the updated Wiki, the following improvements exist in this version:

New features:

  • DirSync can be installed on a Domain Controller (must log-off/log-on AFTER installation and BEFORE configuration wizard)
    • Documentation on how to deploy can be found here

Contains fixes for:

  • Sync Engine memory leak issue
  • Sync Engine export issue (FIM 2010 R2 hotfix 4.1.3493.0)
  • “Staging-Error” during large Confirming Imports from Windows Azure Active Directory
  • password sync behavior when sync’ing from Read-Only Domain Controllers (RODC)
  • DirSync setup behavior for domains with ‘@’ symbol in NetBois names
  • Fix for Hybrid Deployment Configuration-time error:
    • EventID=0
    • Description like “Enable-MsOnlineRichCoexistence failed. Error: Log entry string is too long.  A string written to the event log cannot exceed 32766 characters.”

Upgrading DirSync to the Latest Version

EDIT (Nov. 22 2013): DirSync 1.0.6567.0018 Has Been Released

EDIT (Nov. 11 2013): DirSync 1.0.6553.2 has been removed from Microsoft’s download site and version history comment removed from the Wiki.  Not sure why.

Early this morning, Microsoft released an updated version of Windows Azure Active Directory Sync tool (DirSync to you and me). Version 1.0.6553.2 (or later) can be downloaded from the usual link. It comes with 4 known improvements:

  1. Fix to address Sync Engine memory leak
  2. Fix to address “staging-error” during full import from Azure Active Directory
  3. Fix to handle Read-Only Domain Controllers in Password Sync
  4. DirSync can be installed on a Domain Controller. Documentation on how to deploy can be found here.

I am most excited about #4, as this enables me to build more interesting labs from my laptop, now that I don’t need a dedicated “DirSync Server”. You should note however, this is recommended only for “development” environments. After some further testing, I’d consider recommending this configuration for shops with multiple domain controllers and 50 or fewer users.

If you’re already running DirSync, and want to upgrade, you’re likely in one of two camps:

  1. You want to move DirSync from a dedicated server to a DC.
  2. You don’t want to move the DirSync server to a DC (or elsewhere), you just want the latest version.

If you’re in the first scenario, I’m going to assume you’re working in a lab or very small environment. This means you don’t need to worry about a lengthy synchronization process, and can easily take advantage of the built-in soft-match capability of the product. Your upgrade process is easy:

  1. Throw away your existing DirSync server.
  2. Install Dirsync on a DC.
  3. Run the Directory Sync Configuration Wizard

As soon as you finish the 3rd step, the initial synchronization will rebuild the database (and re-sync passwords), returning to where you left off!

NOTE: If you’re a big shop, you should consider that a full sync takes roughly 1 hour per 5,000 objects synced, according to a recent webcast by Lucas Costa. Soft-matches would likely go faster, but you’ve been warned…

Now, if you’re just looking to upgrade your version of DirSync to the latest version, you need to first ensure you are running versoin 6385.0012 or later. In-place upgrades aren’t supported on earlier versions. If this is you, refer to the soft-match advice I gave above. This is your upgrade path.

For those that are running 6385.0012 or later, upgrading is as simple as a few clicks of the mouse. For the nervous, here are some screenshots:

NOTE: The installer detects an existing installation.
This is the default path, but it should reflect your installation directory.
Hmm, that’s not good! Fortunately a reboot cleared this up for me, but if you’re not so lucky, you can examine the following logs:
  • coexistenceSetup
  • dirsyncSetup
  • miissetup
  • MSOIDCRLSetup

…which are located in the earlier discussed installation directory.

msiexec returned 1618
Much better!
For an upgrade, you’ll want to run this right away, since not doing so leaves you without a functioning DirSync server.
Global Office 365 Administrator credentials go here. This is stored on your DirSync server, so make sure PasswordNeverExpires attribute is set to $true on the Office 365 account (or your on-premises account, if you’re using a federated user)
On-Premises Enterprise Admin credentials go here:
Checking this box allows some attributes to be written back to your Active Directory, which is necessary for a Hybrid Exchange Server scenario.
Enable Password Sync… or Don’t.
NOTE: Upgrades and new installs require a Full Sync.
This post wouldn’t be complete without a plug for my free DirSync Report script! DirSync Report

DirSync and Disabled Users: The BlockCredential Attribute [Part 2]

In this two-part article, I have laid out a scenario in which DirSync sets the Azure “BlockCredential” attribute of disabled Active Directory users. In Part 1, I explained how the Windows Azure Active Directory Sync tool (DirSync) causes this to happen. Part 2 (below) discusses how to change this behavior.


Last time, we saw that magic a rules extension prevents a user from logging into Office 365 if their on-premises Active Directory account was disabled. Below, I’ll show you how to override this attribute flow, but first a note on Microsoft Support:

NOTE: Changing the behavior of DirSync means that you may wander into “unsupported” terrain, but in my experience, unless an unsupported change is likely the cause for a given problem, Microsoft’s support staff have been understanding and have yet to terminate a support case without cause. Having said this, you should not expect Microsoft to incorporate your changes into their upgrade path, so be sure to document, backup, and plan upgrades accordingly.

As you’ll recall, the existing attribute flow is:

userAccountControl à Rules Extension à accountEnabled à Metaverse
Metaverse à accountEnabled à BlockCredential

We will adjust it to the following:

userAccountControl à Rules Extension à accountEnabled à Metaverse à <Nowhere>

In essence, we are allowing the rules extension to update the Metaverse, but not allowing the Azure MA to flow to the BlockedCredential attribute.  This ensures changes in the on-premises Active Directory (such as disabling accounts) will not prevent login to Office 365 (be sure this is actually what you want before you proceed).  Fortunately it also does not necessarily prevent an administrator from setting BlockedCredential manually on Office 365 users.

With our game plan, let’s begin by firing up the trusty miisclient.exe; usually located here:

C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe 

1) Click Management Agents.
2) Open the “Windows Azure Active Directory Connector” MA.
3) Click “Configure Attribute Flow” and expand “Object Type: User”.
4) Select the accountEnabled attribute.
5) Click “Delete”.

6) Click “OK” until you are back on the main screen.

 

We’re almost done!  Two tasks remain:

  1. Test our change by:
    • Creating a new AD user, ensure they sync to Office 365 and that they can log in
    • Disable the user’s AD account, run another sync and ensure they can still log in.
  2. Determine how to update users that were disabled before our change.  If you simply want to re/enable all currently disabled accounts, the below PowerShell sample might work well:
Connect-MsolService
$BlockedUsers = Get-MsolUser -EnabledFilter DisabledOnly -All
$i= 1
$BlockedUsers | ForEach-Object {
 Write-Host ($_.UserPrincipalName + " (" + $i + " of " + $BlockedUsers.count + ")" )
 Set-MsolUser -UserPrincipalName $_.UserPrincipalName -BlockCredential $false
 $i = $i + 1
 }

Thanks to William Yang for his advice on this post.

DirSync and Disabled Users: The BlockCredential Attribute [Part 1]

In this two-part article, I will describe a scenario in which DirSync sets the Azure “BlockCredential” attribute of disabled Active Directory users. In Part 1 (below) I explain how the Windows Azure Active Directory Sync tool (DirSync) causes this to happen. Part 2 discusses how to change this behavior.

As I’ve been discussing, DirSync can be more complicated than it appears. Even if you are familiar with the miisclient.exe console, some of FIM’s logic is hidden in “Rules Extension” DLL files such as “MSONLINE.RulesExt.dll“. These files can be reverse-engineered to some degree, however it can be very difficult.

That’s why it’s good to know you can avoid them all together if necessary! For example, imagine that I don’t want DirSync to prevent my disabled users from logging into Office 365. Perhaps you need to limit access to on-premises resources for a group of people, while still allowing everyone access to Office 365.

If this restricted group is only a handful of users, and you don’t need password synchronization, you might be best off creating them manually within the Office 365 portal. However if automation and password sync are important, this scenario presents a few credentialing challenges:

  • Because ADFS authenticates against local domain controllers, the accounts Must be enabled.
  • DirSync will sync passwords for disabled users, but as mentioned above, it also disables them in Office 365 (by setting their BlockCredential attribute).

The first bullet point is simply how ADFS works, therefore ADFS is out. This 2nd option, however, can actually be explored. WHY does DirSync do this? As far as I can tell, Microsoft hasn’t documented this part of the attribute flow, so let’s take a look ourselves.

Launch miisclient.exe and select the Management Agents tab. Double-click the “Active Directory Connector” MA and select “Configure Attribute Flow”, then expand to this section:

What we can see here is that FIM is reading the Active Directory attribute “userAccountControl” (where the disabled state is recorded) and updating the “Metaverse” attribute “accountEnabled” based on logic within the rules extension. For the sake of argument, why don’t we call this rules extension “magic”, because I have no idea what’s inside it – but let’s keep going.

Now let’s look at the “Windows Azure Active Directory Connector” MA in the same spot:

Well, that’s pretty simple. It’s taking the accountEnabled attribute OUT of the Metaverse and sending it to Azure. The type “Direct” means no magic. After some testing, I have determined that this attribute directly toggles the BlockCredential attribute I mentioned earlier.

userAccountControl à Magic à accountEnabled à Metaverse

Metaverse à accountEnabled  à BlockCredential

(AD / Azure)

Clear as mud, right? J

Here’s an example to be sure:

1) A user has just been disabled.
2) Later, DirSync runs, updating the “userAccountControl” value in the AD MA.

3) The magic within the rule extension reads this and decides the “accountEnabled” Metaverse attribute needs to be updated to “false” which is then exported to Azure.

4) More magic within Azure, decides the user’s BlockCredential attribute needs to be updated. You can view this in the Office 365 Admin Portal or within PowerShell.
5) The user can no longer log into Office 365.Note: This behavior is described in KB 2742372  It looks like your account has been blocked

As you can see, this won’t work in our scenario. Fortunately, FIM is very flexible and we can change this behavior!

Continue on to Part 2 if you’d like to see how.

Dirsync: Determine if Password Sync is Enabled

For those not interested in the complete DirSync Report I published last week, now you can run just the Password Hash Sync portion, in a script I published here: Dirsync: Determine if Password Sync is Enabled.

For deployments with remote SQL installations: As with the previous report, note that we make use of the SQL PowerShell Module, which must be present on the computer.

Sample Output(s)

DirSync “Busted Users” Report

If you administer DirSync for your organization, you likely have seen emails like this, indicating some of your users didn’t sync.

DirSync Error Email

It can be a frustrating email, since the “error description” is for some reason blank and the “On-premises object ID” column is not something that’s easy to correlate to a user account within your Active Directory. There are also application event log entries (FIMSynchronizationService #6111 and Directory Synchronization #0), but again these aren’t exactly rich with detail.

Many of you know that DirSync is actually a customized installation FIM 2010 R2’s Synchronization Service. Within the miisclient.exe console, you can look at your most recent “Export” job and examine the errors one at a time.

Miisclient.exe Console


(By the way, this is actually the place to go if you wanted to configure filtering for directory synchronization.)

Using this console certainly works, but it’s not an efficient way to resolve errors. Microsoft seems to acknowledge this, but falls short of a fix with that email, in my opinion. Instead of wearing out your mouse, I propose you use the PowerShell script I have written below. Within, I leverage the free FimSyncPowerShellModule which you’ll need to download and copy to:

…\System32\WindowsPowerShell\v1.0\Modules\FimSyncPowerShellModule\FimSyncPowerShellModule.psm1

Once you’ve copied the module, you’re ready to run the report, which can be downloaded here.

Here is a sample output, followed by the code itself.

Sample Output

<#
Description:
This script generates a list of users who are failing to export to Azure AD.

This script makes use of the FimSyncPowerShellModule
https://fimpowershellmodule.codeplex.com/
(Download and copy to C:\Windows\System32\WindowsPowerShell\v1.0\Modules\FimSyncPowerShellModule\FimSyncPowerShellModule.psm1)

October 18 2013
Mike Crowley
http://mikecrowley.us
#>

#Import the FimSyncPowerShellModule Module
ipmo FimSyncPowerShellModule

#Get the last export run
$LastExportRun = (Get-MIIS_RunHistory -MaName 'Windows Azure Active Directory Connector' -RunProfile 'Export')[0]

#Get error objects from last export run (user errors only)
$UserErrorObjects = $LastExportRun | Get-RunHistoryDetailErrors | ? {$_.dn -ne $null}

$ErrorFile = @()

#Build the custom Output Object
$UserErrorObjects | % {
 $TmpCSObject = Get-MIIS_CSObject -ManagementAgent 'Windows Azure Active Directory Connector' -DN $_.DN
 [xml]$UserXML = $TmpCSObject.UnappliedExportHologram
 $MyObject = New-Object PSObject -Property @{
 EmailAddress = (Select-Xml -Xml $UserXML -XPath "/entry/attr" | select -expand node | ? {$_.name -eq 'mail'}).value
 UPN = (Select-Xml -Xml $UserXML -XPath "/entry/attr" | select -expand node | ? {$_.name -eq 'userPrincipalName'}).value
 ErrorType = $_.ErrorType
 DN = $_.DN
 }
 $ErrorFile += $MyObject
 }

$FileName = "$env:TMP\ErrorList-{0:yyyyMMdd-HHmm}" -f (Get-Date) + ".CSV"
$ErrorFile | select UPN, EmailAddress, ErrorType, DN | epcsv $FileName -NoType

#Output to the screen
$ErrorFile | select UPN, EmailAddress, ErrorType, DN

Write-Host
Write-Host $ErrorFile.count "users with errors. See here for a list:" -F Yellow
Write-Host $FileName -F Yellow
Write-Host