Problem involving EventConfig_{oldsvrname} and AAD Connect.

(I posted this at Reddit, but am still searching for an answer so I wanted to post here too. Hoping one of you might know what I'm facing and be able to help me get past the hurdle I'm encountering. Thanks. )

I've implemented AAD Connect in preparation for an O365 Hybrid migration project.

MSOL is sending me Identity Synchronization Error Reports every 30-minute cycle, complaining about an object with the Identity "EventConfig_xxx" (where xxx = an old server name).

The Error Description states "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:EventConfig_xxx@{organization};]. Correct or remove the duplicate values in your local directory. Please refer to for more information on identifying objects with duplicate attribute values."

How could I possibly have a duplicate address in local AD that uses ? There is nothing in the local domain with that domain name.

ADUC doesn't find an object with that name. I managed to find it myself, in Exchange System Objects, under the Events Root folder. There were 3 entries there with the same name. In ADSIEdit I found the objects, one with the name EventConfig_xxx. one with EventConfig_xxx-1, and one as EventConfig_xxx-2. The objects are of Object Type 'Public Folder'

The environment presently has Exchange 2010 servers, running SP3 UR26. Also one Exchange 2016 svr.

Nobody within the organization recognizes the server name at all or has any memory of it. Ping resolves it to an IP address. It doesn't respond to ping. I cannot find that IP address anywhere in DNS, whether looking in Forward or Reverse lookup zones.

I could not find the object in the O365 Admin Center, or the O365 EAC, or using O365 Remote Powershell (neither with Get-MSOLUser or Get-Mailbox).

I can find the object in a Metaverse Search using the AAD Connect Sync Mgr tool and the Source Anchor (provided in the Error Report). If I look at the Proxy Addresses on the object, none are the address AAD Connect is complaining about.

I cannot find the object in the Azure AD admin center.

IdFix doesn't detect the object.

I haven't found much online about this. I found a few pages that lead me to believe this is an orphaned remnant from either Exchange 5.5, 2000, or 2003. One article from 2007 ( suggested using a utility called 'events.exe' with a switch to clean up the infrastructure, but I'm not confident that will still apply, and I don't see any way to roll that back if it causes unanticipated problems.

The company does use Public Folders, so I can't break those.

Do any of you know what the Events Root\EventConfig_xxx objects do, how they are used, etc..., and how I can either clean them up or correct whatever is causing the AAD Connect complaint?

I've been trying to gather info on this and resolve it for a while now, so if I've left out any important and relevant information here, call me out on it - I probably just forgot to mention it.

Online ComputersAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bruno PACIIT ConsultantCommented:

As you found suspicious objects with ADSIEdit you can try to mark these objects as to be ignored by AAD Connect.

To do that, in ADSIEdit, locate the suspicious object, modifiy its attribute "AdminDescription" and give it the value "User_DoNotSync".

Normally, AAD Connect wil just ignore any object that has a value startinf with "User_" or "Group_" in AdminDescription attribute.

This should make the synchronization error to disappear. This does not answer to the question of what these objects are from and if you can delete them or not but may be you can just ignore them..

Have a nive day
Online ComputersAuthor Commented:
Hi Bruno,

Thanks for the idea, I didn't know about that feature of AAD Connect.

I did try that, but AADC did still try to sync the object (and showed the changed attribute so I know this was after the change had replicated across the AD environment) and still threw the error.
Bruno PACIIT ConsultantCommented:
Hi again,

Well, looks like Microsoft AAD connect make a specific treatment on these objects.
By the way, did you searched if these objects exists on o365 as mail contacts ? Public folders are not mailboxes nor groups so I presume the synchronization creates a contact object in your exchange online.

Also, I suppose you don't synchronize your whole domain so you probably have some organizational units that are not synchronized ? In this case, can you just try moving the object in a container that is not synchronized and check if error disappears. But note where the object is currently so you may be able to put it back if something gets wrong with your onpremise exchange.

If you dont have on premise public folders and your exchange on premise is 2013 or above it's pretty sure these objects are just old ones that were not cleaned in your previous migration.
Online ComputersAuthor Commented:
Thanks Bruno, there is no visible contact record for that object either.

I really don't think it exists in O365. I think AAD Connect is not syncing it to Azure, and the Sync Error notification is telling me that.

I just don't understand why it is complaining that there is an '@...' proxyaddress, and I don't understand why it is complaining about the EventConfig_{oldsvr}..., but not complaining about EventConfig_{oldsvr}-1..., or EventConfig_{oldsvr}-2..., , or EventConfig_{differentoldsvr}..., . I see all of those in ADSIEdit in the same place, but only the one is flagged by AADConnect. (And no, none of them are visible in O365, and there's no reason any of them should be in O365.)

My client is annoyed at the emails, and I'm concerned that this may indicate some other problem that I'll uncover as I go further with the migration project. I don't want to simply redirect the emails because if the client doesn't see them then I'll own those errors forever and anytime new recipients are improperly added to AD in the future the client won't see the problem.

Ultimately I need to find the cause and solution.

I appreciate your help.

I really do think this is a tough one. I think it is going to require somebody that was both an Exch2k expert and remembers it, and also knows (is certain, not just guessing like me) whether or how the Events Root\EventConfig_{svr} entries are used in Exch 2010 + Exch 2016 hybrid configs.

I wish I could just delete the entry in ADSIEdit, but as I wrote above I don't know if that might break anything, and I wouldn't know how to properly re-create it if deleting it did cause harm.
Online ComputersAuthor Commented:
Opened an MS Support ticket for this. I'm not comfortable with the solution, but it seems to have worked.

In the Synchronization Manager, in both the AAD and on-prem AD connector properties there is a clickable link to Select the object types that are sync'ed. At the client I was working one of the object types selected in the list was 'PublicFolder' (may have been PublicFolders, don't recall for sure).

The MS tech had me de-select that on both connectors, then run a Full ('Initial') sync. That seems to have cured the problem.

MS said that by default those checkboxes are NOT checked, and also said (and I know) that DirSync has nothing to do with Public Folders and I know the Public Folder migration process doesn't use DirSync to sync up the PFs.

BUT, I also know that I installed AAD Connect to the client only about a week or two ago, I didn't make any customizations to that settings area, and I've never needed to deselect those boxes before, and I've been working with BPOS/O365 since 2009, and implemented DirSync scores of times probably.

So I'm still uncomfortable with this, and worried that when we progress and are working to implement the hybrid environment and eventually migrate the PFs I worry this will come back to bite me.

I'd be more comfortable if I actually knew where and for what the EventConfig_ entries are used, and how to resolve the error rather than evading it.

But, short answer is the problem was resolved by unchecking the PublicFolder object type in the Sync Manager connector properties.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.