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:
- Do not enable discovery at a site in the hierarchy if that site and its child secondary sites do not require the discovery data.
- Modify the properties of the Active Directory discovery methods such that you query specific containers whenever possible.
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:
- This isn't the right discovery method to find computers in Active Directory Domain Services.
- This is the right discovery method if you need to create collections based on OUs or security groups, and you have already configured Active Directory System Discovery.
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.
- To successfully use this discovery method, ensure that your Active Directory computers register their name in DNS.
- To ensure that this discovery method does not create computer records for computers that are no longer on the network, ensure that DNS is configured for scavenging.
4. Active Directory discovery methods require that the site server computer account has Read access to the specified Active Directory containers.
- When you use this account to discover resources in domains other than the site server's domain, the site server computer account must be a member of the Domain Users or local Users group in the other domain.
- When you use this account to discover resources in another forest, this requires a full forest trust.
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.
- If you accidentally delete a computer from the Configuration Manager console, it will automatically "come back" if it is still active on the network. You can either wait for the next Heartbeat Discovery cycle to run, or you can hurry things along by selecting the Discovery Data Collection Cycle on the client Configuration Manager Properties: Actions tab, and click OK.
6. Heartbeat Discovery is the discovery process that submits a client's installation status to its assigned site.
- The client might be installed but the client state in the Configuration Manager console continues to display No for its Client state if the site hasn't received the client's discovery data record (DDR) from Heartbeat Discovery. This will be the case if the client cannot communicate with its management point.
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/avicode
ConfigMgr 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/opalis
Orchestrator 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/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/