Before I get into the details: my problem is clearly different than the one described in this question. I'm running a single Azure Connect instance, so the problem clearly isn't due to multiple sync. In fact, our system is using Azure Connect from the start, so there's no upgrade to speak of.

That said, pretty much every member of our organization had both a local AD account as well as a separate Office365 account. As such, in our case, the Azure Connect has to sync up to existing Azure AD accounts.

The process worked for most of our users; however, 9 accounts remain problematic, and I cannot figure out why.

The error message is pretty "standard":

Nie można zaktualizować tego obiektu, ponieważ następujące atrybuty skojarzone z tym obiektem mają wartości, które mogą już być skojarzone z innym obiektem w lokalnych usługach katalogowych: [Mail user@domain.com;]. Popraw lub usuń zduplikowane wartości w katalogu lokalnym. Więcej informacji na temat identyfikowania obiektów ze zduplikowanymi wartościami atrybutów, można znaleźć w artykule http://support.microsoft.com/kb/2647098.

Tracking Id: GUID ExtraErrorDetails: [{"Key":"ObjectIdInConflict","Value":["GUID"]},{"Key":"AttributeConflictName","Value":["Mail"]},{"Key":"AttributeConflictValues","Value":["user@domain.com"]}]

The "friendly" part of the error message is in Polish, but it's the standard "InvalidSoftMatch" error.

Now, I know I'm using soft matching by SMTP address... but the user in question has a clearly defined email (via the email attribute in AD; we don't have a local Exchange to make use of the proxyAddresses attribute). That same user has the exact same SMTP address in Office365 Exchange (as well as a SIP address which is also the same). Needless to say, I can't find any other mentions of this email being used in Exchange online.

As such, I can't figure out why this account isn't being synchronized and keeps throwing the "soft match" error.


Ah... Softmatch, my old friend. Worked so many of these back in the day i was practically married to it, had to automate the process.

Since there is no exchange you need to set the ImmutableID on the users. What you are looking for are 4 lines

$upn user@userdomain.com
$GUID = (Get-ADUser -Filter {UserPrincipalName -eq $upn}).ObjectGUID
$ImmutableID = [System.Convert]::ToBase64String($GUID.tobytearray())
Set-MSOLuser -UserPrincipalName $upn -ImmutableID $immutableID

Here is my 'old' blog post on this issue http://hazelnest.com/blog/blog/2016/01/28/o365-dirsync-issues/

Also the video on the process i created https://youtu.be/G1CyTbbv6pg

Hope this helps.

  • So... in essence the solution is to "manually" hook up AD records to AAD records via the ImmutableID, rather than rely on the matching mechanisms in use by Azure Connect?
    – Shaamaan
    Nov 16 '18 at 6:51
  • I'm going to mark this as an answer, as this does solve the problem. I am, however, a bit weary of using it for all the accounts that are having sync issues - mainly because the issues do happen for SOME reason, and this feels like ignoring that reason (whatever it might be)...
    – Shaamaan
    Nov 16 '18 at 13:06
  • I issue stems from the AAD installation. If you really don't want to see this issue you will need to configure the Source Anchor during installation of the AAD Connect but i have seen that come with its own issues. docs.microsoft.com/en-us/azure/active-directory/hybrid/…
    – Hannel
    Nov 16 '18 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.