Had an interesting one recently with a customer that has created cloud accounts for use during COVID-19 with approx 50 users. Each of these accounts were assigned a license and the users used teams, onenote, onedrive etc…. but not exchange online mailbox – as they already have an on-premise mailbox.

After this, we became involved and implemented AADConnect and exchange hybrid.

After removing the exchange license and clearing the mailbox info as per https://techcommunity.microsoft.com/t5/exchange-team-blog/permanently-clear-previous-mailbox-info/ba-p/607619

some users, not all, were not sync’ing correctly in AAD connect.

we can see the objectID that is conflicting

We can then confirm which object it is in O365

and then search for the conflict – which in this case, was a proxy address.

 

i had previously thought that ProxyAddresses was an exchange related attribute….. and given i had already removed all exchange information from the account… it shouldn’t be there….

At this stage the battle became how to get rid of it – since set-MSOLuser does not seem to allow it.

I found this – https://byronwright.blogspot.com/2017/09/remove-proxy-address-from-office-365.html – but in my instance, the conflicting address is the “correct” address, which keeps getting re-added automatically if you remove it.

Renaming the account temporarily doesn’t work – as the proxy address (as a user account attribute for an unknown reason) seems to update to match the UPN when changed.

 

This article had a good suggestion – https://www.petenetlive.com/KB/Article/0001588 but resulted in an error

Failed to apply fix – User with conflicting attribute is soft deleted in Azure Active Directory. Ensure the user is hard deleted before retrying.<a href=”https://go.microsoft.com/fwlink/?linkid=2007018″ target=”_blank”>Read More</a>

and we cant hard delete the user – they have data…

 

So – what are we left with? Hard matching. A process i was aware of, had never had to do (until now) – but thought was going to be overkill for this situation….. but apparently i was wrong.

There is a script here to help – https://gallery.technet.microsoft.com/office/immutableid-hard-match-in-d3518b08 or, if, like me, you prefer to step through it (when there is a small number of affected users)

import-module ActiveDirectory

$user = “SameAccountName” (not UPN)

$guid = [guid]((Get-ADUser -Identity $user).objectGuid)

$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())

Set-MsolUser -UserPrincipalName <UPN> -ImmutableId <Base64String>

 

this should work…. but didnt, instead i got the error

Set-MsolUser : Uniqueness violation. Property: SourceAnchor.
At line:1 char:1
+ Set-MsolUser -UserPrincipalName benjamin.primus@rtwsa.com -ImmutableI …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolUser], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.UniquenessValidationException,Microsoft.Online.Adminis
tration.Automation.SetUser

 

Then it clicked – this guy must have had an account previously…. run

get-msoluser -all -returndeletedusers

and sure enough – there it was….. with the immutableID assigned to that account…. so i then ran

Get-MsolUser -ReturnDeletedUsers -UserPrincipalName <UPN> | Remove-MsolUser -RemoveFromRecycleBin -Force

Followed by setting the immutableID again – which went through this time.

I then waited for AADConnect to sync again – which went through without error…. “yay” – i thought…. but then the user no longer showed up in the O365 GUI, and powershell showed

Errors : {Microsoft.Online.Administration.ValidationError,
Microsoft.Online.Administration.ValidationError,
Microsoft.Online.Administration.ValidationError,
Microsoft.Online.Administration.ValidationError…}

i used https://support.microsoft.com/en-us/help/2741233/you-see-validation-errors-for-users-in-the-office-365-portal-or-in-the

to troubleshoot this, in particular

$errors = (Get-MsolUser -UserPrincipalName “<User_ID>”).Errors

Get-MsolUser -HasErrorsOnly | select DisplayName,UserPrincipalName,@{Name=”Error”;Expression={($_.errors[0].ErrorDetail.objecterrors.errorrecord.ErrorDescription)}} | Export-csv c:\temp\validationerrors.csv

In this users case, there was still something hanging around from an old mailbox

The execution of cmdlet Set-SyncMailUser failed. The value “8dceb397-5af1-4142-8689-24bffeb83f92” of property “ArchiveGuid” is used by another recipient object. Please specify a unique value.

 

This lead me to https://docs.microsoft.com/en-us/archive/blogs/exovoice/how-to-fix-office365-user-provisioning-issues-that-are-generated-by-faulty-exchange-attributes

Run this to get the conflicting GUID

(Get-MsolUser -UserPrincipalName affecteduser@domain.com).errors.errordetail.objecterrors.errorrecord| fl

Then run this – with the inserted GUID from the above step

Get-Recipient -IncludeSoftDeletedRecipients ‘ExchangeGUID value’|ft RecipientType,PrimarySmtpAddress,*WhenSoftDeleted*

in my case – it was a soft deleted mailbox, so i then run

Remove-MailUser ‘ExchangeGUID value’ -PermanentlyDelete

After this – it was finally all good on next AADConnect Sync.

This whole thing was one huge pain in the arse…. but, at the same time, i learnt a lot…. I’ve previously always setup AADConnect first – and therefore not had cloud accounts that need to be merged etc. The whole process is way fucking harder than it needs to be…. which is very Microsoft…. but, i feel like this will come in useful in future!