System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

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:

141 votes
Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: Facebook Google
Signed in as (Sign out)
An error occurred while saving the comment
  • David Stein commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    we are running into the same issue. definitely need a workaround if it cannot be permanently fixed.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Same issue. Support case opened with Microsoft and the reason is by design. Please, it's really required to fix

  • Chris commented  ·   ·  Flag as inappropriate

    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.

  • Jeffrey Dennis commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base