Is it possible to add a customized feature in Discovery in future versions of SCCM? i.e. In the mentioned discovery methods can there be an option to run a full discovery on particular Active Directory Containers

•Active Directory Group Discovery
•Active Directory System Discovery
•Active Directory User Discovery

For e.g. I take example for Active Directory Group Discovery, in that i have mentioned the below OUs,if i use "Full discovery polling schedule" then it becomes effective on all below mentioned OUs, so i just need to run this option for an particular OU mentioned in my Active Directory Group Discovery i.e. LDAP://OU=ABC,DC=Contoso,DC=com to retrieve a information immediately for that particular OU in SCCM operational Purpose.

LDAP://OU=ABC,DC=Contoso,DC=com
LDAP://OU=XYZ,DC=Contoso,DC=com
LDAP://OU=123,DC=Contoso,DC=com

Scenario is there are total 21,000 machines are reporting to an SCCM server, i add new OU for discovery which consists of 500 machines, since discovery for AD is set to run for every 7 days, but i want SCCM to make a quick note of OU changes for these 500 workstations via discovery, but i need wait for 7 days for full discovery.Though i use trigger manually "Run Discovery as soon as possible" but it will again unnecessary run discovery on mentioned OU's, so i need to run full discovery on specific OU mentioned in discoveries.

Delta Discovery consider only below changes,

1.New computers or users added to Active Directory
2.Changes to basic computer and user information
3.New computers or users that are added to a group
4.Computers or users that are removed from a group
5.Changes to System group objects

so if i am not wrong, delta discovery doesn't consider OU changes? thats why i raised this question in forum, Is it possible include an option to run a full discovery on particular Active Directory Containers in future versions of SCCM? to avoid unnecessary running of full discovery for all OU's in mentioned in Discovery

Thanks,

Muthukumaran

The IP address information that is accessible for queries and reporting is often out-of-date especially with remote and VPN clients. It's more useful to know what an online client's IP address is now rather than what it was at various points in the past.

It would be useful if the current IP address and current subnet (based on subnet mask) was included in SMSCollectionMemberClientBaselineStatus and vCollectionMemberClientBaselineStatus as part of Client Online Status.

This data appears to be available in BGBResStatus, and since that table is already being used in vCollectionMemberClientBaselineStatus, both the IP address and subnet fields could be added to the view.

I would like to see some changes in the way containers are processed during discovery.

1) I would like the ability to change the order and/or prioritize which containers are searched first. We have multiple forests, and it would be good to be able to set some to run before others.

2) I would like to be able to establish multiple schedules for AD Discovery so that some containers can be run more frequently than others.

3) I would like to be able to right click on a container and manually run discovery on that container only.
4) Allow the option to specify which DC SCCM will use for the discovery.

There is issue when SCCM client only considers Direct Access network adapter activeness but it doesn't calculate whether DA connection is successful or not. In case of DA "connecting" scenario where laptop is not at all connected to Corporate Network, SCCM client keep trying to access on-prem SCCM MP and DP servers and failing every time until its get connected or user disconnects from DA so that SCCM client tries to DMZ hosted IBCM MP and DP server for successful communication.

If SCCM client get additional logic to consider Direct Access Successful criteria then there will not be any SCCM client to server communication issue.

We find ourselves trying to go from MAC address to device in the console fairly regularly, especially when troubleshooting things like PXE from the logs (which only shows MAC address) and needing to kill off failed OSD records (which may be named "Unknown" or have a random computer name in ConfigMgr, but you're now in WinPE ready to kick off the TS again).

If the MAC Address information was pulled with Heartbeat discovery, it could easily be used to filter the device list and find the resource .As the information rarely changes, it seems like it would be very low impact to add this information to Heartbeat discovery as it would never come up in delta reports.

Thank you for making ConfigMgr easier to use and troubleshoot!