ManageEngine OpManager is a network management platform for real-time monitoring of network devices, servers, routers, switches and firewalls. Its value is catching bottlenecks and performance problems before they turn into outages. These notes cover how I build it with high availability, from design to the final failover test.
What it does
- Health and performance monitoring: SNMP and WMI collect metrics such as CPU, RAM and traffic.
- Fault management: receives SNMP traps and syslog and sends smart alerts.
- High availability: a standby server keeps the monitoring service running if the primary fails.
- Reporting: SLA reports and trend analysis.
Architecture
The design is an enterprise failover: one primary server, one standby server and one shared external MSSQL database. If the primary fails, the standby takes over immediately.
- Primary server: does the polling and data collection.
- Standby server: stays ready and watches the primary through a heartbeat.
- Database server (MSSQL): stores configuration and logs, and both OpManager servers connect to it.
- Managed devices: everything being monitored.
How I size it
For large environments I use Windows Server for both the application and the database.
| Component | Minimum | Recommended | Why |
|---|---|---|---|
| App server CPU | 4 cores | 8 cores | OpManager processes are heavy |
| App server RAM | 16 GB | 32 GB | Caches data and reduces disk load |
| App server disk | 100 GB | 500 GB SSD | Disk speed matters for log writes |
| App server OS | Windows Server 2019 / 2022 | ||
| SQL Server | MSSQL 2019 / 2022, Standard or Enterprise | ||
| SQL RAM | - | 32 GB+ | Better database performance |
| SQL disk | - | 1 TB (RAID 10) | Monitoring data grows quickly over time |
Network and ports
| Service | Port | Direction |
|---|---|---|
| Web console (HTTPS) | TCP 8060 | Admin to OpManager |
| Database | TCP 1433 | OpManager to SQL Server |
| Failover heartbeat | TCP 9999 | Primary to / from Standby |
| SNMP polling | UDP 161 | OpManager to devices |
| SNMP traps | UDP 162 | Devices to OpManager |
| WMI (Windows servers) | TCP 135, 445 | OpManager to Windows hosts |
| SSH (CLI monitoring and NCM) | TCP 22 | OpManager to Linux / network devices |
| Ping (up / down) | ICMP | OpManager to devices |
| NetFlow (optional) | UDP 9996 | Devices to OpManager |
The order I install in
1. Prepare the database. In SQL Server Management Studio create a new database named OpManagerDB with the collation SQL_Latin1_General_CP1_CI_AS. Create a SQL-authenticated user with db_owner on it, and enable the SQL Browser service.
2. Install the primary. Run the installer as Administrator and choose the Failover Service (Primary) option in the Professional or Enterprise edition. When asked for the database choose MSSQL and enter the server address, database name and the user you just created. Start the OpManager service, sign in, and change the initial credentials right away. On first login the product asks for an XML licence file: register it from the profile icon, in the Register tab.
3. Install the standby. On the second server run the installer again and choose Failover Service (Standby). Enter the same database details (both servers must use one database), and the IP address and port of the primary. Finish the installation, start the service and register the licence on this server too.
How I configure failover
Open the web console on the primary and go to Settings → General Settings → Failover Details. The primary should show as Active and the standby as Listening. If both servers are in the same subnet, define a virtual IP so users always reach the console at one address, whichever server is active.
What I configure first
- Discovery: under Settings → Discovery enter the IP ranges of your servers and switches.
- Credentials: define SNMP (v2c / v3) and WMI profiles, with a domain account for WMI, so OpManager can read device data.
- Notifications: set up the SMTP mail server so alert emails can be sent.
How I test before handover
| Test | Expected result |
|---|---|
| Database connection | Both servers connect to MSSQL without errors. |
| Service status | The OpManager service is running on the primary and the standby. |
| Discovery | Key devices, such as the core router and the domain controller, are discovered. |
| Metrics | CPU and traffic graphs appear for the devices. |
| Failover | Unplug the primary's network cable: the standby becomes active within about two minutes and an alert email is sent. |