Minor tweak. I would like to see Client OS Bit-Depth returned with Discovery Data. We have a custom deployment portal that allows the support tech to only see the software that matches the OS and bit-depth of the machine name they've entered to deploy to, but to get bit depth now, we have to wait for HINV and then use "Processor Width", we'd much rather this be Discovery Data so it's available immediately. We were able to implement a computer naming standard which segregates 32-bit and 64-bit OS'es by name but without that, it would have been more difficult to implement. I can see other benefits of having this information available via Discovery...

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

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.

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.

This request ( https://configurationmanager.uservoice.com/forums/300492-ideas/suggestions/8414520-exclude-virtual-cluster-and-ou-from-discovery ) was not fully completed, but it was marked as complete. People have been commenting that it is NOT done.

We appreciate the addition of OU exclusion, but Virtual Cluster exclusion is also a big part of what we need!

I believe most of us don't want to have to pile up our cluster objects into a junk OU just to exclude them. My AD is organized such that it makes far more sense to see these objects sitting with the real computer objects.

Please review the request for Virtual Cluster exclusion as a separate request from the OU exclusion.

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!