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 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