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
Has anyone found a way to clear or force memcm to update this field after the initial import? My deployment collections are based on department and employee codes and this causing software to be deployed to incorrect users and devices.
Has this issue been addressed in the latest ConfigMGR Current Branch? I agree this is pretty crippling not to be able to query for additional AD Attributes and have it return Live/Current values entered for the purposes of Collections/Query inside SCCM console.
My only thought of a workaround is to create an AD Group and ADD the Computer Objects to that Group then base your Collection on Group Membership.
Rick Gates commented
We have a lot of these entries in the adusrdis.log and would like this fixed as well.
The main issue is the fact it's filling up the log to the point that the log keeps crashing or takes forever now when I try to open it. Please fix!
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