ITOM Vis/Discovery Lessons Learned
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
7 hours ago
When Discovery is done well, it becomes the foundation for Service Mapping, impact analysis, and operational intelligence.
For those who’ve implemented it — what was the hardest lesson you learned?
We're about to implement ITOM vis in a zbooted (greenfield) environment, and we've identified that effective discovery depends on:
• Thoughtful MID Server placement
• Credential strategy and testing
• Clean identification rules
• CMDB governance alignment
• Controlled scope and scheduling
But mature Discovery implementations look very different, so open to hearing about any other lessons learned from the hive mind.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
Hi @alexbt1639 ,
Below are the lessons that I have learnt from my discovery implementation experience
MID Server alignment matters more than you think
It’s not just “have enough MID Servers.” It’s about placing them close to the targets they need to reach, balancing load, and making sure only one schedule runs per MID at a time. Otherwise you end up with stuck jobs or missed discoveries.
Scheduling by priority is essential
Not all CIs are equal. Many teams eventually tier their schedules (like you did with data center vs. end‑user computing). Critical infrastructure gets discovered more frequently, while lower‑priority endpoints can be scheduled less often or during off‑hours.
Credential strategy is a constant battle
Getting credentials right is harder than building patterns. You need a clear process for testing, rotating, and maintaining them. Without that, discovery fails silently or floods you with “no access” errors.
Identification rules must be clean and consistent
Duplicate CIs or bad merges are one of the biggest headaches. Spend time upfront defining identification rules so that the same server doesn’t appear three times under different names.
Governance keeps the CMDB usable
Discovery can fill your CMDB with noise if you don’t have governance. Define what classes you care about, what attributes are mandatory, and who owns data quality.
Communication with infra/cloud teams is key
Discovery only works if the network, firewall, and IAM permissions are in place. Building a checklist and validating access before onboarding new classes saves huge amounts of time.
