I've been involved in a number of discussions recently about where network discovery falls in implementing a CMDB, and I've never fully agreed with the idea that automated discovery of your existing assets is the right way to get a CMDB up and running.

Quoting the venerable IT Skeptic blog because he hits the nail on the head here:
"How will you populate the CMDB initially? The vendors’ silver bullet solution is auto-discovery. It can find out something about many things, but not everything about all things. It won’t help with disconnected devices, or financial information, or physical location. Ask how they go with finding UPS, PABX, factory machinery, or building security and cooling systems."
As a vendor I did some good hard looking at auto-discovery and despite the fact that most IT equipment has standardized SNMP, WMI, or SSH for remote access there's still a huge number of issues with even the best designed auto-discovery tools:

Trust: because the CMDB's single source of added value is it's correctness. Think for a second, if your CMDB is usually right you'll still end up logging into your servers to double check before making a change request wouldn't you?. What added value did you get in that situation? If anything it was a new cost in your time, and a new liability in another database that might just be wrong you have to check anyways. If you can't place a nearly absolute level of trust in your CMDB it becomes a liability instead of an asset.

Taking this focus on correctness to the extreme, which would you prefer, a CMDB with just hostnames and the responsible team, or one auto-discovered and never fully verified? I know I'd take the former because at the very least it lets your helpdesk wake up the right team at 3AM.

Secondly there's completeness; even if you gather every single technical detail about computers (which really won't happen. What about your legacy app that doesn't show in add/remove programs?) you still end up missing the financial information, the warranty information, even who's responsible for the system's health and well being.

Lastly there's the issue of cost, the IT skeptic post I linked is about how doing CMDB according to ITIL is realistically impossible, and it's true - you could have a 3 person team doing nothing but populating, updating, and verifying the CMDB for years at a medium sized company and still never track all your assets properly; is that level of completeness worth a quarter million dollar or higher yearly investment?

The bottom line is that every asset you put in your CMDB, and every attribute you track has a cost associated with it to keep up it's correctness. It requires careful planning on what's worth tracking and what isn't in order to preserve that correctness but also give you a tool that's complete enough to be useful, and above all it has to add value. Auto-discovery might be a useful tool for figuring out what's on your network, and for that it makes a good starting point for populating a CMDB, but directly importing data at the push of a button really fails on all these tests.