Azure AD Sync Office365 conflicts

[Blue_Cookeh]

Hi All,

 

Just setting up our Office365 sync again on our DC and getting some conflict reports into my inbox.

 

Basically because of some local problems I had to delete and recreate users within our on premise AD and in doing so I used the same proxyAddresses as the users' old accounts. Now, the old accounts no longer exist (nor in the AD Recycle Bin), but Office365 is still giving me sync errors for the accounts I had to recreate. Any ideas how I can fix this?

 

Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:[email protected],smtp:[email protected];Mail [email protected];]. Correct or remove the duplicate values in your local directory. Please refer to http://support.microsoft.com/kb/2647098 for more information on identifying objects with duplicate attribute values.

[Zenden]

Just thinking out loud here but..... remove the smtp addresses from the accounts then sync to Office 365 (and make sure the old accounts have been deleted to match your AD) then re add and sync again.

[Blue_Cookeh]

Any other ideas anyone?

[rpwillis]

It will be because the Azure AD account (O365) have their immutableId values from the deleted accounts. So DirSync thinks that they are linked to different account - in fact they are. To resolve you've got 2 options:

1. Delete the Azure accounts and re-create. Not feasible if they are being used.

2. Set the immutableId value to null, then DirSync can link them up.

 

You can do this using PowerShell:

set-msoluser -userprincipalname x -immutableID "$null"

for an individual user.

 

You can find For a script that can do all of them at once at https://www.rm.com/Support/GeneralDownload.asp?cref=DWN3444137&nav=0. Don't run the first part of it which unfederates your domain though.

[Blue_Cookeh]

It will be because the Azure AD account (O365) have their immutableId values from the deleted accounts. So DirSync thinks that they are linked to different account - in fact they are. To resolve you've got 2 options:

1. Delete the Azure accounts and re-create. Not feasible if they are being used.

2. Set the immutableId value to null, then DirSync can link them up.

 

You can do this using PowerShell:

set-msoluser -userprincipalname x -immutableID "$null"

for an individual user.

 

You can find For a script that can do all of them at once at https://www.rm.com/Support/GeneralDownload.asp?cref=DWN3444137&nav=0. Don't run the first part of it which unfederates your domain though.

 

It's only around 5 users at the moment so will do it by hand... will let you guys know how I get on.

 

Thanks for that, I'm not hugely clued up on how Azure AD works in comparison to on-premise AD so learn something new every day!

[Blue_Cookeh]

Trying to set the ImmutableID to $null doesn't seem to actually empty the attribute, and when I try to set it to the same as the on-prem ID I just get an exception as below... any ideas anyone?

 

set-msoluser : Unable to update parameter. Parameter name: SourceAnchor.
At line:1 char:1
+ set-msoluser -UserPrincipalName "[email protected]" -ImmutableI ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   + CategoryInfo          : OperationStopped: ( [set-MsolUser], MicrosoftOnlineException
   + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online
  .Administration.Automation.SetUser

[FN-GM]

If you want to double check the emails are no assigned to another user do this.

 

1. Run Active Directory Users and Computers.
   
2. Right-click the domain object and choose Find from the context menu. This will bring up the Find Users, Contacts, and Groups window.
   
3. In the Find drop-down list, choose Custom Search.
   
4. Click the Advanced tab and in the Enter LDAP query: field, enter the following text: proxyaddresses=smtp:[email protected]
   
5. Click the Find Now button.
   

[Blue_Cookeh]

They're definitely not, it's just I've recreated some on premise AD accounts and now DirSync is totally confused! Edited March 1, 2015 by Blue_Cookeh

[EduTech]

Hi,

 

This is failing because objects exist in Azure AD with the same values that you have now set on the re-created on-premise user objects, at the moment when the Azure AD Management Agent attempts to run it's Export Run Profile it is unable to create the new user objects because another object (the previous one) still exists. This is expected, if you didn't allow the synchronization engine to do an export of the deleted user accounts first.

 

The reason why your not able to set the ImmutableID to a value of NULL is because this object that you are trying to do this to, is in a Synchronized Object State, we only allow you to set the ImmutableID value for Cloud User Objects.

 

If you do not need to retain the data i.e. SharePoint Online Incl. OneDrive or Lync Online in the Objects that still exist in Azure Active Directory then if you remove the user accounts as per the below it will unblock you: {you can still restore the Exchange Mailbox if you do it this way}.

 

Remove-MsolUser -UserPrincipalName [email protected] -Force

Remove-MsolUser -UserPrincipalName [email protected] -RemoveFromRecycleBin

 

if you do need to retain the exchange data then let me know and I can show you how to do that

 

If you need to keep all of the data then this is somewhat a little more tricky but let me know what your options are..

 

James.

[Blue_Cookeh]

Hi,

 

This is failing because objects exist in Azure AD with the same values that you have now set on the re-created on-premise user objects, at the moment when the Azure AD Management Agent attempts to run it's Export Run Profile it is unable to create the new user objects because another object (the previous one) still exists. This is expected, if you didn't allow the synchronization engine to do an export of the deleted user accounts first.

 

The reason why your not able to set the ImmutableID to a value of NULL is because this object that you are trying to do this to, is in a Synchronized Object State, we only allow you to set the ImmutableID value for Cloud User Objects.

 

If you do not need to retain the data i.e. SharePoint Online Incl. OneDrive or Lync Online in the Objects that still exist in Azure Active Directory then if you remove the user accounts as per the below it will unblock you: {you can still restore the Exchange Mailbox if you do it this way}.

 

 

 

if you do need to retain the exchange data then let me know and I can show you how to do that

 

If you need to keep all of the data then this is somewhat a little more tricky but let me know what your options are..

 

James.

 

If you could show us that would be great, the only bit of Office365 we use right now is Exchange.

[EduTech]

what do you want me to show you? this is my point be a bit more specific and I'll be able to tell you what you need to do :-) I can't guess! do you need to retain all data or/ just exchange mailbox?

 

James.

[Blue_Cookeh]

Sorry! Sunday night isn't the best time to be doing stuff!

 

It's literally just the Exchange mailboxes and calendars for each user we need to keep at the moment, I was thinking I could just reset the Azure AD password for the affected users, export their data as PSTs and then reimport on the new user... but if you know an easier way that would be great

[aceonbass]

Hi,

 

This is failing because objects exist in Azure AD with the same values that you have now set on the re-created on-premise user objects, at the moment when the Azure AD Management Agent attempts to run it's Export Run Profile it is unable to create the new user objects because another object (the previous one) still exists. This is expected, if you didn't allow the synchronization engine to do an export of the deleted user accounts first.

 

The reason why your not able to set the ImmutableID to a value of NULL is because this object that you are trying to do this to, is in a Synchronized Object State, we only allow you to set the ImmutableID value for Cloud User Objects.

 

If you do not need to retain the data i.e. SharePoint Online Incl. OneDrive or Lync Online in the Objects that still exist in Azure Active Directory then if you remove the user accounts as per the below it will unblock you: {you can still restore the Exchange Mailbox if you do it this way}.

 

 

 

if you do need to retain the exchange data then let me know and I can show you how to do that

 

If you need to keep all of the data then this is somewhat a little more tricky but let me know what your options are..

 

James.

 

 

Hi James,

 

If I could jump in on this topic, I have a similar issue and I'll need your help to change this ImmutableID without losing any data!

 

A quick overview:

 

* Setup our students only in 365 last year, using DirSync, with completely default values.

* This year, adding in our staff (separate forest) I changed to AADSync, in which I also changed the "sourceAnchor" value to "extensionAttribute5"

** This was done, rightly or wrongly, just in case the ObjectGuid ever clashed over the two forests. This attribute set to complete unique values and accounts will never be moved between the forests

* Now, AADSync can add/sync our staff without issue, but obviously not students, as their ImmutableID is still the Base64String version of their AD ObjectGUID.

** Tried to set this with a Powershell script (nice and easy) but can't due to "PropertyNotSettableException".

 

If you can help out with this, that would be fantastic - I would guess we'll need to switch to private message/email etc to discuss this. I've got a script "ready to go" to blast our accounts with the new values.

 

 

Thanks in advance.