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

Today it's only possible to orchestrate software updating based on a membership in collections.
This is however rarely enough for more complex setups where you might have back-, middle-, and front tiers in your setup.

Therefore I recommend adding a dependency system between computer objects, so that you can orchestrate at least the following:
1) Which tier of servers are patched first, second and third etc.
2) Reboot order between the different tiers which includes an accept of one tier being fully patched and rebooted before the next tier is begun updating.
3) Ability to choose between warning or rollback if a single server fails updating - however this should be possible to decide based on each tier. (you often care more that a database server is identical than a webfrontend).

Currently, when users request an application through the Software Center, it will generate an email (if setup) allowing helpdesk to approve or deny the request. That feature works great and I think it is a good step forward. However, when the request is approved, no notification is sent back to the user. They would have to manually check the software center to see if the approval went through or if the system is still online outside of their defined business hours, it will automatically install. This is a poor experience from our standpoint as users tend to not notice these changes.

It would be nice to have SCCM automatically generate a notification to the user or generate an email alerting them that their application request was either approved or denied. Rather than manually checking the software center or waiting until an icon appeared on the desktop.