- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
earlier web service CIs discovered and mapped with Old Linux Server VM, now are trying to discover new Linux Server VM, it is able to discovering new Linux VM ,However this new Linux VM is unable to discover associate web service CI and mapping with it.
could you help us in discovering associate web service CI for new linux server VM?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @pavan garige ,
As per my understanding why this happens
1. Old VM vs. New VM context
* The web service (Tomcat, Apache, JBoss, etc.) was discovered earlier because the process pattern sensor detected listening ports / service processes.
* On the new Linux VM, Discovery sees the server, but the application fingerprinting / process detection step is failing.
2. Possible reasons for Web Service not discovered
* Missing or incorrect credentials → Discovery can SSH into the VM but may not have rights to run service detection commands.
* Application not running at the time of discovery.
* Port/protocol blocked (e.g., HTTP/HTTPS 80, 443, or application-specific ports like 8080).
* Pattern issue → The OOTB Web Server pattern may not be triggered if process arguments/env variables differ on new VM.
* Old Service Mapping entry point not updated → If you are using top-down Service Mapping, the new VM must be linked to the service entry point (URL, FQDN, or Load Balancer).
Steps to fix
1. Verify connectivity & credentials
* Re-run Quick Discovery on the new Linux VM.
* Confirm the application process commands (e.g., ps -ef | grep httpd or systemctl status tomcat) are executable by the credential used.
* Ensure required ports (80/443/8080/8443 etc.) are open from MID to the VM.
2. Check Discovery Pattern Trigger
* Go to Discovery Patterns → find Apache Web Server, Tomcat, JBoss, WebSphere, etc.
* Confirm the process classifier matches the running process on the new VM.
* If custom startup script or binary path differs (e.g., /opt/apache/bin/httpd instead of /usr/sbin/httpd), extend the process classifier.
3. Validate Web Service CI creation
* Check Discovery Log → look at the Application Process Tracker section.
* If it sees the process but fails to classify, update the classifier/pattern accordingly.
4. Update Service Mapping
* If this web service is part of a Service Mapping application service, update the entry point and run a rescan to bind the new VM.
* You may need to use Traffic-Based Connection (TBC) or manually adjust the pattern to include the new host.
5. Test & re-run
* After classifier/pattern adjustments, re-run discovery on the new Linux VM.
* Confirm that a Web Service CI (cmdb_ci_appl / cmdb_ci_web_service) is created and linked as a child of the Linux VM CI.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @pavan garige ,
As per my understanding why this happens
1. Old VM vs. New VM context
* The web service (Tomcat, Apache, JBoss, etc.) was discovered earlier because the process pattern sensor detected listening ports / service processes.
* On the new Linux VM, Discovery sees the server, but the application fingerprinting / process detection step is failing.
2. Possible reasons for Web Service not discovered
* Missing or incorrect credentials → Discovery can SSH into the VM but may not have rights to run service detection commands.
* Application not running at the time of discovery.
* Port/protocol blocked (e.g., HTTP/HTTPS 80, 443, or application-specific ports like 8080).
* Pattern issue → The OOTB Web Server pattern may not be triggered if process arguments/env variables differ on new VM.
* Old Service Mapping entry point not updated → If you are using top-down Service Mapping, the new VM must be linked to the service entry point (URL, FQDN, or Load Balancer).
Steps to fix
1. Verify connectivity & credentials
* Re-run Quick Discovery on the new Linux VM.
* Confirm the application process commands (e.g., ps -ef | grep httpd or systemctl status tomcat) are executable by the credential used.
* Ensure required ports (80/443/8080/8443 etc.) are open from MID to the VM.
2. Check Discovery Pattern Trigger
* Go to Discovery Patterns → find Apache Web Server, Tomcat, JBoss, WebSphere, etc.
* Confirm the process classifier matches the running process on the new VM.
* If custom startup script or binary path differs (e.g., /opt/apache/bin/httpd instead of /usr/sbin/httpd), extend the process classifier.
3. Validate Web Service CI creation
* Check Discovery Log → look at the Application Process Tracker section.
* If it sees the process but fails to classify, update the classifier/pattern accordingly.
4. Update Service Mapping
* If this web service is part of a Service Mapping application service, update the entry point and run a rescan to bind the new VM.
* You may need to use Traffic-Based Connection (TBC) or manually adjust the pattern to include the new host.
5. Test & re-run
* After classifier/pattern adjustments, re-run discovery on the new Linux VM.
* Confirm that a Web Service CI (cmdb_ci_appl / cmdb_ci_web_service) is created and linked as a child of the Linux VM CI.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
Hi @pavan garige ,
If this is helpful to resolve your issue, please accept solution so that can be reference in future.
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 weeks ago
HI Ajay,
Thank you for your detailed explanation and we are able to discover once Applications are active on the Production.
