Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, October 27, 2016 11:22 AM | 1 vote
From what i can tell, the "ProxyAddresses" attribute within the user AD Objects is present in the schema and is populated. i have recently made some changes to a couple of users (added/removed some additional SMTP addresses). These changes are not synchronizing into Exchange Online?
No Errors are shown in the "Service Manager" or event log, the changes are listed within the "Statistics". i have check the rules and the property is selected to be synchronized.
the property never gets updated within Exchange Online. i do not want to uninstall the current version of the sync tool for the older DirSync.
i am using "Azure AD Connect" 1.1.189.0
All replies (12)
Thursday, October 27, 2016 1:04 PM
This behaviour is quite common:
https://support.microsoft.com/en-us/kb/2643629
You could also remove the user from the OU that is being synced.
Then sync the ou again.
move user back into ou + change smtp.
sync ou again.
most likely this will reflect the change by then.
Thursday, October 27, 2016 1:19 PM
Nope, this does not change things. Tried it on a test "Shared Mailbox" account, moved to another OU which deleted the user from O365. Then moved back into the sync'd OU, added back into O365.
the "proxyaddress" attribute has not changed from the original settings, no update and no errors. This was sync'd previously and fulfills all the Pre-Reqs on the web link.
Thursday, October 27, 2016 1:30 PM
The AD Object attributes are perfectly correct, other attributes sync to O365, like (Title, Job Description etc) but not "Proxyaddresses", not tried any others like (Mail, targetaddress, mailnickname etc).
?????
Thursday, October 27, 2016 1:33 PM
so far, just the "Proxyaddress" attribute is missing the sync. testing the others appears fine.
Saturday, October 29, 2016 2:33 AM
Hi,
Does it works now?
By default, delta synchronizations from your on-premises Active Directory forest to Office 365 are scheduled to run every 3 hours. Therefore, we need manually sync those change by PowerShell.
Delta Sync: Start-ADSyncSyncCycle -PolicyType Delta
Full Sync: Start-ADSyncSyncCycle -PolicyType Initial
For your reference:
https://blogs.technet.microsoft.com/rmilne/2014/10/01/how-to-run-manual-dirsync-azure-active-directory-sync-updates/
Allen Wang
TechNet Community Support
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
Monday, October 31, 2016 7:13 AM
Thank-you
i am aware of this, and normally run it manually when debugging an issue. this has all been checked along with the sync rules. This property alone does not sync, and yet i cannot see an error. are there more detailed logs on how i can investigate what is happening?
Thursday, November 10, 2016 7:30 AM
OK, no activity, which means noone knows !!!
Can anyone tell me if there are logs attached to the sync process i can review. i may be able to see why the property is not updating in Azure AD.
Thursday, March 9, 2017 10:08 AM
We had this problem too but upgrading to Azure AD Connect v1.1.443 fixes the issue.
Alan Farley
Friday, April 21, 2017 10:14 AM
thank-you
i will try this.
Friday, August 4, 2017 2:28 PM
We have the same issue. Using Azure AD Connect 1.1.553.0 and having issues syncing Resource Mailbox proxyaddresses attribute. EUM is the attribute we are trying to sync for Skype for business.
Tuesday, June 25, 2019 9:00 AM
Hi wizz1969,
any update on this?
Many thanks.
Wednesday, May 27, 2020 10:08 PM
Just want to throw in my experience, in case anyone else stumbles across this thread. In my case the SMTP attribute would not sync because the azure ad sync client had confused the user account experiencing sync-failure with a security group that had the identical name. The sync object matched to o365 user was the security group, even though it was a security group and not a user account.
I was able to discover this by using the metaverse search function of the Azure AD Connect Synchronization Service Manager miisclient. Searching the account name of the problem account revealed a security group instead.
After changing the name of the security group in local AD and running a sync of -policytype initial, the account gained the correct sync relationship and the attributes that would not sync, including proxyaddresses, began to work.
As a bonus I now have a cloud-only o365 group with that email address + a random number that O365 created to mitigate the smtp collision it had created itself