SCCM is not synchronizing disabled accounts, so it is not synchronizing the change in the UserAccountControl-attribute, so from SCCM perspective every machine/user is active. This creates problems e.g. in Software Asset Management since collections can’t select AD active accounts only. SCCM should synchronize changed attributes or at least UserAccountControl of AD disabled accounts if the account exists in SCCM

Please add a check box which would enable me to have the DNS check skipped during computer system discovery. There are situations when a system may not resolve in DNS from the CM server, however I would still like to have the attribute data (LastLogon, pwdLastSet, etc) from Active Directory updated by the discovery process regardless of the DNS check. Currently these values are not updated if the system is not found.

We have had a number of cases where old firmware versions of SSD drives caused computer failures - so being able to report on these is important.
OOTB the Win32_DiskDrive class is available but doesn't include the firmware property.
This means you need to add a custom class to enable discovery of this data.
Can we extend the existing class to have the firmware able to be enabled without any customization?
More info on an unsupported way to achieve the same result: https://timmyit.com/2017/03/13/hardware-inventory-disk-name-and-firmware/

AD Group discovery automatically discovers all computers and users that are members of the group (and nested groups). Sometimes it is not desired, as we choose what computers/users we want to discover via AD System/User Discovery. AD Group discovery should update group membership information for existing resources in the site. Or, ideally, provide an option to choose if we want to also discover group members, or not.

When creating custom discovery data using the smsresgen class there is no way to remove this from the discovery related tables in ConfigMgr. Since there is a supported way to add this data, there should be a supported way to remove it. This is necessary as a rollback option, to return ConfigMgr to its default state, before the custom discovery data was added.

Have the ability to include/exclude certain OU's from both Active Directory User and System Discovery.

E.G. I might have an "All Users and Groups" OU at the root domain level, which may contain sub OU's containing service accounts or mailbox accounts etc. that I don't want being picked up by discovery. The ability to pick which sub OU's to discover/not discover would be really handy in this scenario. The same applies for system/computer discovery also.

When System Discovery finds an object that seems invalid, currently it won`t be imported (which is good).
ERROR: System <systemname> is a unsupported operating system, unsupported version, or malformed AD entry. Reported system type is: ().
However if the same object has an AD Group Membership and AD Group Discovery finds it, it won't check if it is valid, but write the DDR and create the object record in SCCM DB.

Please change AD Group Discovery so it validates new objects too.

Please extend AD discovery to work with Multivalue Attributes.
For the moment, only the first value from the multivalued attribute is discovered.

Software Inventory scan cycle (file scanning) of just Program Files can be ridiculously slow where it can run for over 12 hours or more which impacts all other inventory scan cycles. Worse still, if user powers down or restarts client the scan restarts from scratch. Disabling throttling is still too slow ( due to its use of WMI according to Tier 3) and not supported.
We would like a usable Software (file) Inventory scan cycle.

Create ddr even if system discovery cannot ping/nslookup device. Primary server is behind firewall due to network decision, therefore system discovery fails. Checkbox that will create DDR without successful nslookup or ping would allow us to discover devices.

Currently, you can exclude discovery of machines by OU. While great, some systems can not be organized easily into one or a few OUs.

Requesting a feature be added to allow the same functionality but exclude systems from system discovery that are in a specific Active Directory group.

It would be ideal to be able to defer feature upgrades for Windows 10 via Client settings to avoid having to use a GPO. This would avoid the current dual scan issue with GPOs and WUfB Policy Settings.

Active Directory Group Discovery
As the title states it's a discovery method meaning it simply creates new resources (and/or updates values of attributes).
It never deletes groups that no longer exist in AD.
Wouldn't it be good to have a mechanism that keeps the SCCM in sync with AD (especially for groups and users)?
Thanks for taking this into consideration.

AD forest discovery fails and does not continue parse through the other forests after and "Discovery is being aborted due to an unexpected exception".

We would like to see where the discovery sees that it cannot contact or reach any given forest but is able to continue with the other forests to collect the data.

Add the option to filter out objects based on attributes.
examples:
where "Operating System Name" -notlike "%2003" and"Operating System Name" -notlike "%5.1" and -notlike "%OSX%"
where "Description" -notlike "%Physical%"
Where "OrganizationalUnit" -ne "OU=Disabled Objects,DC=contoso,DC=com"

it might delay the scan for each object and cause the discovery to take more time, but on the other hand make it more useful and stop discovering unwanted objects to the DB

Could you implement a reboot pending check in the console ?

this is not an easy way to implement reporting on it :
http://blogs.technet.com/b/smartinez/archive/2014/06/27/reboot-pending-report-how-to-create-the-report.aspx

The 'description' field very regularly used to note important contextual information about AD objects and their purpose. The description information should be discovered from Active Directory by default so it is available to both help understand objects in ConfigMgr and for use with building collection membership queries.