| |

Apache, Tomcat, and IIS in Your CMDB

ByTeam Virima

Apache, Tomcat, and IIS instances are the invisible middle tier in most enterprise CMDBs. This guide explains why application server discovery matters and how to get every web and application server into your CMDB.

Table of Contents

#TLDR

Physical and virtual servers make it into the CMDB. Apache, Tomcat, and IIS — the application servers running on those hosts — typically do not. This guide covers what application server CIs are, why they matter for incident routing and change management, and how automated discovery captures Apache, Tomcat, IIS, and SSL certificates as first-class CMDB CIs.

The Missing Application Tier

Open your CMDB and look at any web application server. You will find a CI for the Windows Server or Linux Server it runs on. What you almost certainly will not find is a CI for the Apache web server, Tomcat container, or IIS instance deployed on that host.

This is the application tier blindspot. Your CMDB knows the physical and virtual infrastructure layer reasonably well. It does not know the software layer running on top of it — the actual web servers and application containers that your business depends on.

The physical server is a CI. What runs on it is not.

This gap has direct operational consequences. When an Apache instance fails, the CMDB points to a server, not a service owner. When an IIS upgrade is planned, change managers cannot see which applications sit in the affected IIS instance. When a certificate expires, no one knew it was expiring because it was never in the CMDB.

Application server discovery closes this gap. According to NIST’s National Vulnerability Database, Apache HTTP Server, Apache Tomcat, and Microsoft IIS collectively accounted for hundreds of active CVEs in 2024 — many requiring precise version identification to determine exposure, which is exactly the data that application server CIs in your CMDB provide.

Why Application Server CIs Matter

Incident Routing

Who owns the Apache instance on prod-web-04? If the CMDB only has a record of the server, the answer is “whoever owns the server.” If the CMDB has an Apache CI with its own ownership, configuration data, and version, the answer is precise: the web platform team owns this specific Apache installation.

Faster routing means shorter MTTR. In a P1 incident, every minute of “who owns this?” is a minute of revenue impact. For a deeper look at how CIs and their dependencies work together in incident context, see our guide to configuration item relationships.

Change Management

A planned OS upgrade on a Windows Server affects every IIS website and virtual directory running on that host. Without IIS CIs in the CMDB, change managers cannot enumerate that impact. The change advisory board approves the server upgrade without knowing that it will take down twelve web applications.

With IIS Server, IIS Website, and IIS Virtual Directory CIs linked by “Hosted On” and “Runs On” relationships, change impact analysis works correctly. The CAB sees the full downstream blast radius before approving the change.

Capacity Planning

Application server CIs enable capacity planning conversations that server-level data cannot support. If a single Apache instance serves 40% of your web traffic and it runs on a server already at 85% CPU, the capacity conversation needs to reference the Apache CI — not just the server.

Compliance and Certificate Tracking

SSL/TLS certificates expire. When they do on an uncatalogued IIS website, the first notification is usually a user-facing error or a compliance audit finding. With certificate CIs in the CMDB linked to the IIS websites they protect, expiry dates become queryable CMDB attributes. Teams can report on certificates expiring within 90 days without a manual spreadsheet audit. See our guide to digital certificate management for full context on certificate lifecycle tracking.

Apache Webserver Discovery

Apache HTTP Server discovery uses a PowerShell probe on Windows hosts and SSH-based discovery agent scans on Linux hosts to interrogate running Apache processes directly.

What Gets Captured

  • Apache version — major and minor version of the running httpd process
  • Configuration file paths — location of httpd.conf and included configuration files
  • Virtual host definitions — site names and document roots configured in the Apache instance
  • Service status — whether the Apache service is active, stopped, or in a failed state

The Resulting CI

Each discovered Apache installation becomes an Apache Webserver CI in the CMDB. A “Runs On” relationship links this CI to the parent server CI (Windows Server or Linux Server). This means:

  • Change impact analysis on the parent server automatically surfaces the Apache CI
  • Incident records can be linked directly to the Apache CI rather than to a generic server
  • Service maps built in Virima ViVID include the Apache tier as a distinct node

Apache Tomcat Discovery

Apache Tomcat is the runtime environment for Java web applications across enterprise environments. Tomcat instances host deployed WAR files, serve Java Servlet and JSP applications, and frequently sit behind Apache HTTP Server as a reverse proxy target.

What Gets Captured

  • Tomcat version — critical for patch management and CVE tracking
  • HTTP connector port — the port Tomcat listens on (default 8080, but often customized)
  • Deployed applications — WAR files and context paths of deployed Java applications
  • Base directory — CATALINA_HOME and CATALINA_BASE paths

The Resulting CI Structure

A Tomcat discovery creates an Apache Tomcat CI linked via “Runs On” to the host server. Deployed applications can be tracked as child CIs, giving the CMDB visibility into which applications run on which Tomcat instance on which server.

This structure enables precise change questions: this Tomcat upgrade affects which applications? The CRM integration WAR and the reporting API — both owned by the application team. Without the Tomcat CI, that question has no CMDB-based answer.

IIS Discovery: Server, Websites, and Folders

IIS (Internet Information Services) is Microsoft’s Windows web server platform. It hosts ASP.NET applications, WCF services, SharePoint, and web APIs across Windows Server environments. Unlike Apache (a single process serving virtual hosts), IIS has a structured three-tier hierarchy that CMDB discovery must reflect accurately.

The Three-Tier IIS Model

Virima 6.1.1 discovers IIS infrastructure at all three levels using a PowerShell probe that interrogates the IIS configuration through the Microsoft.Web.Administration API:

Level 1 — IIS Server CI: the top-level IIS installation on a Windows host. Attributes include IIS version, Windows Server host, and service account.

Level 2 — IIS Website CIs: individual sites within IIS, each with its own bindings (hostname, port, protocol — HTTP or HTTPS), physical path, and application pool. A single IIS Server typically hosts multiple websites.

Level 3 — IIS Virtual Directory / Folder CIs: virtual directories and physical folders within each website, mapping URL paths to filesystem locations.

Relationship Chain

Windows Server CI
  → [Runs On] IIS Server CI
      → [Hosted On] IIS Website CI (Customer Portal)
          → [Hosted On] IIS Virtual Directory CI (/api)
          → [Hosted On] IIS Virtual Directory CI (/admin)
      → [Hosted On] IIS Website CI (Internal Tools)

This relationship chain makes change impact analysis deterministic: a change to the Windows Server surfaces every IIS site and every virtual directory in the blast radius report, with no manual enumeration required.

Why PowerShell-Based IIS Discovery Matters

Native IIS configuration data is stored in applicationHost.config — an XML file with a complex schema. Parsing it directly is fragile and version-sensitive. A PowerShell probe using the WebAdministration module or Microsoft.Web.Administration API provides a stable, version-agnostic interface to IIS configuration data that works consistently across IIS 7.5 through IIS 10 on Windows Server 2012 through 2022.

MMC Certificate Discovery

SSL/TLS certificates protect HTTPS traffic on IIS websites. When they expire, websites become inaccessible or display browser security warnings. Certificate management is a perennial source of preventable outages.

MMC Certificate discovery interrogates the Windows Certificate Store to capture:

  • Subject (CN, O, OU)
  • Issuer and Certificate Authority
  • Expiry date — the attribute that triggers renewal workflows
  • Thumbprint — a unique fingerprint for the certificate
  • Subject Alternative Names (SANs) — all hostnames covered by the certificate

Each certificate becomes a Certificate CI in the CMDB, linked to the IIS Website CI it protects. This linkage enables direct CMDB queries for expiring certificates, change management workflows triggered by certificate expiry dates, and audit evidence for TLS/SSL compliance requirements.

Without certificate CIs in the CMDB, expiry tracking falls to shared spreadsheets, calendar reminders, or the browser warning that users report when the certificate has already expired.

Best Practices

Run application server discovery as a distinct scan profile. Application servers change more frequently than physical hosts. New WAR deployments, site additions, and certificate renewals happen on development cycles, not hardware refresh cycles. A separate discovery profile with a tighter schedule captures these changes promptly. For guidance on choosing the right discovery approach for your environment, see our agent-based vs. agentless comparison.

Map ownership at the CI level. Every Apache CI, IIS Website CI, and Tomcat CI should have an explicit owner or team assignment. This is the data that makes incident routing fast.

Set certificate expiry alerts at 90 and 30 days. Use certificate CI expiry dates to trigger automated notifications. A 90-day alert gives the team time to renew through the certificate authority’s process. A 30-day alert is the last checkpoint before impact.

Include application server CIs in your service mapping scope. ViVID service maps are only complete when the application tier is represented. Ensure discovery scope and service map configuration both include Apache, Tomcat, and IIS CI types.

Read more about how automated CMDB discovery feeds service map completeness.

Next Steps

The application tier is where most incidents originate and where change impact is most commonly underestimated. Getting Apache, Tomcat, and IIS CIs into your IT asset management inventory — with correct relationships to their host servers and to the services they support — converts application server management from a manual, fragmented activity into a data-driven, auditable process.

Virima 6.1.1 captures Apache Webserver, Apache Tomcat, IIS Server, IIS Website, IIS Virtual Directory, and SSL Certificate CIs automatically, linking each to its host and populating the “Runs On” and “Hosted On” relationships that feed change impact analysis and service maps.

Ready to see the application tier in your CMDB? Schedule a Demo at virima.com and we’ll show you exactly what Virima 6.1.1 discovers in your environment.

Similar Posts