We are deploying uCMDB/DDMA to discover & map our infrastructure (backbone). We bought a 2000 nodes bundle to support our 1400 servers (we have room from growth). About 90% of our 1400 servers are Windows based (2K3, and 2K8), the other servers are RedHat/Linux.
Discovery limits: how the number of licenses is managed/control in the uCMDB. What CI is counted to know if we reach the limit of our license?
When we met the security team, they asked us to ensure we are not running SNMP discovery on a server not member of our Windows domain. This is to ensure we are not giving our SNMP strings to any non-authorized server. On the other end, they would like to know if a non-authorized machine is present on our network. Is someone ever face the same kind of challenge with their own security team?
We first planned to run IP ping sweeps on IP subnets where our servers should be, then run SNMP, WMI and Cmd discoveries. The request from our security team is now forcing us to change our strategy. We looked at the Windows/Domain discovery to built our list of IP addresses (candidates for SNMP/WMI), but we aren't able to run a full discovery of our network for a reason we don't know.
We must have (at least) 25000 computers in AD, but we can't discover more than 12000 computers after 2 days of domain & Domain Topology discovery. What can be the problem here?
How is your probe ranges setup? Instead of allowing all sub-nets to be discovered are you limiting your discovery scope to certain ones? Another possibility is to integrate with other tools that you might already be discovering with like SCCM that could integrate with uCMDB.
How do you know what an authorized machine is? Is there a DB of authorized machines? Is there a spreadsheet? You would need someway to compare what you can ping, to what is deemed an authorized machine. DDM will just tell you if there is an IP address and if security lets you, what shell it can access.
Just a couple of ideas, but hopefully give you a place to start.
Licensing: Examine your liense. Every ucmdb.xml file I have recieved from HP has not restricted my discovery. I've never come had an issue where I've hit a limit and the appliation stopped discovering. For example, in NNMi if you go over on the nodes you are licensed for than the application stops monitoring nodes until it gets back to the limit. I have not seen that type of behavior.
Now for your discovery strategy question. First, go get the HP CMS Best Practices Library, and study all of the documentation in that. Go to the HPLN to find the documentation, https://hpln.hp.com/group/discovery-and-dependency-mapping. One thing I hear in your message is your strategy is to turn on all of the discoveries and see what comes back. Doesn't sound like much of a plan. Decide on what types of data you need, then authorize what jobs should be gathering that information, or what current data repositories should be integrated to satisfy them. Having SNMP, WMI, and xCMD out hitting the same machines will mean you will have attributes flopping values as different jobs report variations to the same attribute field. Do you and your team a huge favor, and study up on the CMS BP Library under the 'Planning and Design' section.
For the security concern, this will get answered once you lay out your data-to-job strategy. Discover what you know to begin with, and then design a strategy to discover what you don't know. For example, once you have all of the servers you expect discovered, you can design discovery jobs that look at the deltas. Get your experience with this tool in place with what you expect so you don't have to weed your way later through a torrent of CIs.
I won't comment on your security folks. I could run holes through that statement about the community strings, but if that is their policy I understand what it means to them. The biggest thing you can counter with is that the most common snmp security threat is when the default string is not changed. So scan away with SNMP if you agree to do the delta scans with 'public'.
Get the CMS BP Library. It will answer a lot of your questions.