See all of the top support solutions for our most common issues here
I saw this in a post on the Configuration Manager Team blog concerning some documentation updates for March and thought it would be something every ConfigMgr admin would want to see.
Below is their Top Ten Clarifications for Discovery but you can read their entire post here.
If you've had questions or problems with discovery, we encourage you to read the updated documentation. However, if you're interested in a quick summary of some of the key pieces of information that customers needed, we put together our "Top Ten Clarifications for Discovery" list.
Top Ten Clarifications for Discovery
1. Discovery can generate significant traffic on the network, especially if the same resources are discovered at multiple sites within the hierarchy. Best practices:
2. Active Directory System Group Discovery doesn't discover new resources but discovers additional information about previously discovered computers from the specified locations in Active Directory Domain Services. This information includes the OU and group membership of the computer:
3. Active Directory System Discovery must be able to discover the computer account in Active Directory Domain Services and then successfully resolve the computer name to an IP address.
4. Active Directory discovery methods require that the site server computer account has Read access to the specified Active Directory containers.
5. Heartbeat Discovery forces the rediscovery of active clients that have been deleted from the Configuration Manager database by the administrator, or by a database maintenance task.
6. Heartbeat Discovery is the discovery process that submits a client's installation status to its assigned site.
7. Run Network Discovery only when the other discovery methods cannot find the resources that you need to discover. For example, Network Discovery is the right discovery method for workgroup computers, but Active Directory System Discovery is the better discovery method for Active Directory computers.
8. Network Discovery must be able to identify the subnet mask in addition to the IP address of a resource. Please refer to the following KB article for more information on this requirement and on other Network Discovery details:
237557 - SMS: Systems Management Server Network Discovery Internals
9. Just because you can discover a resource, it doesn't mean that you can manage it with Configuration Manager. Network Discovery often identifies objects that cannot be managed by Configuration Manager (such as printers), because they have both an IP address and an identifiable subnet mask.
10. The approximate size of an individual DDR is 1 KB. It's impossible for us to estimate how much network traffic Discovery creates, because it depends on the number of resources found and how they are discovered. Remember that although each DDR is small in size, these can mount up and discovering a large number of resources can have a significant effect on the network.
Note: We didn't get this clarification into the discovery documentation, because it's not related directly to discovery, but collections. However, new customers especially, are running into this when they configure discovery and the expected resources do not show up in the Configuration Manager console. The missing piece of information here is after discovery has run, you won't see the resources in the Configuration Manager console until the collection membership has updated and the console has refreshed. To do this manually, right-click the collection, click Update Collection Membership, click OK, and then press F5 to refresh the display.
J.C. Hornbeck | System Center Knowledge Engineer
App-V Team blog: http://blogs.technet.com/appv/AVIcode Team blog: http://blogs.technet.com/b/avicodeConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/DPM Team blog: http://blogs.technet.com/dpm/MED-V Team blog: http://blogs.technet.com/medv/OOB Support Team blog: http://blogs.technet.com/oob/Opalis Team blog: http://blogs.technet.com/opalisOrchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/SCMDM Support Team blog: http://blogs.technet.com/mdm/SCVMM Team blog: http://blogs.technet.com/scvmmServer App-V Team blog: http://blogs.technet.com/b/serverappvService Manager Team blog: http://blogs.technet.com/b/servicemanagerSystem Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentialsWSUS Support Team blog: http://blogs.technet.com/sus/