Fix Active Directory Discovery Attribute <Not Set> Bug
When an optional AD attribute has been selected for inclusion in AD discovery, if that attribute has a value at time of discovery, it is included in the discovery and reflected as part of the information for the user/computer/group object in CM. If that AD attribute is later cleared (changed to <not set> / NULL value in AD), discovery identifies that the attribute is a NULL value and purposely skips it from the discovery. As such, the user/computer/group object in AD falls out of sync with the AD attributes and continues to report the value even though it has been cleared in AD.
This behavior is clearly documented in all the "ad???dis.log" files, with lines that read:
WARN: ConvertADstoSQLType: pADsValues is NULL
WARN: Type not supported for the follwoing [sic] optional attributes, <attrib1>,<attrib2>,...,
For example. An AD employee has the employeeId attribute populated with their employee number. It is synced into CM. The employee quits and HR clears that information from the employeeId field. It is subsequently not cleared in CM. A similar action can occur with msRTCSIP-PrimaryUserAddress, whereby a once mail-enabled object is no longer mail-enabled, but the CM object still shows the information.
This matches the 2014 Microsoft Connect posting: https://connect.microsoft.com/ConfigurationManagervnext/feedback/details/1000189/pfe-additional-ad-discovery-attributes-when-changed-from-a-value-to-not-set-in-ad-retain-a-value-in-the-configmgr-database
I am also going through this issue. The user discovery stopped working and all previously discovered user disappeared.
Finally to fix it quickly, we did remove all attributes and rerun discovery. This helped to bring all AD user into SCCM. Now I have to add few custom attributes and need to re-discover.
David Stein commented
I could see scenarios where this could be potentially detrimental to an environment that builds automation on top of custom attributes within ConfigMgr.
Sai Kurapati commented
we are running into the same issue. definitely need a workaround if it cannot be permanently fixed.
Same issue. Support case opened with Microsoft and the reason is by design. Please, it's really required to fix
I am seeing this as well. Please fix this. We would like this to work and update any time the field is updated/changed in AD and then discovery happens.
I'm seeing the same issue. There has to be a fix for it.
Jeffrey Dennis commented
We have encountered this issue by extending custom attribute extensions across managed domains. If we set a value in the computer AD custom attribute, synchronize Configuration Manager's "Active Directory System Discovery", and query site it will return the expected value the first time. If we then go and change the same AD custom attribute to another value, perform a sync, and then query the site it will not return the new value, but it will return the old value instead. It appears that the value can never be changed in SCCM once it is synchronized the first time from AD.
Levi Stevens commented
Ran into this issue today. We have a collection based on the AD Computer Description field. The field was cleared in AD, and the computer didn't drop out of the collection because the discovery field in the system class was not cleared. I had to delete the SCCM record and let the client report in again to clear this.
Its really required to fix the issue