IBM Maximo Real Estate and Facilities · Administration · A guide for Maximo people

Every MREF system has a small, old-looking console at /html/en/default/admin that tells you what the platform is doing: which agents run where, what is queued, what failed, how much memory is left. This guide walks through every page on a real MREF 9.2.2 system on OpenShift, explains each line, and spends extra time on the agents, the background workers that do most of the real work.

The green In Maximo terms boxes translate each page for someone who knows Maximo Manage.

GETTING IN

Opening the console

Sign in to MREF as an administrator, then open https://<your MREF host>/html/en/default/admin/index.jsp in the same browser. The left menu lists the pages you are allowed to see; the right side shows the selected page.

The menu. The red text at the top is System Status: warnings the platform wants you to see first.

Access is per page, per user: see Admin Users below. A user with "Read Only" on a page can look but not press its buttons.

THE BIG PICTURE

How MREF runs on OpenShift

On Maximo Application Suite, MREF is not one server. The Facilities operator builds it from a custom resource (the FacilitiesWorkspace) into several pods in its own namespace. On this system, mas-instdb2-facilities:

OpenShift console → Workloads → Pods in the MREF namespace.

So when the Admin Console says an agent is "Running On instdb2-wsp-multiagents-3000", it means the multiagents pod. Its log (/home/wiotp/log/server.log inside that pod, or the pod's Logs tab in OpenShift) is where that agent's errors go, not the Error Logs page of the UI server.

PAGE 1

Admin Summary and the red warnings

Admin Summary of the UI server.

The red System Status text

The two messages above the menu on this system:

• "Maximo Application Suite session timeout setting could not be retrieved." MREF asks MAS for the session timeout so both log users out at the same time. The server log shows the call is refused (HTTP 401). Users can still work; MREF falls back to its own timeout (System Info → User Session Timeout, 30 minutes here). Worth fixing so sessions behave consistently.
• "Invalid AES Encryption Keystore Password detected. Refer to the vaultSecret setting…" MREF encrypts some stored values with an AES key kept in a keystore. Its password comes from the vault secret named in the FacilitiesWorkspace (vaultSecret). The warning means that password does not open the keystore. Fix it in OpenShift, by correcting the secret, never by editing anything in the console. Until then, features that rely on encrypted values may fail.

THE HEART OF IT

Agents, the background workers

An agent is a background process inside a Liberty server that wakes up regularly, looks for queued work in the database, and does it. Almost everything that is not a user clicking a button is done by an agent: asynchronous workflows, scheduled events, imports, publishing, cleanup.

Agents page: status, the Stop/Start link, and the server each agent runs on.

Reading the statuses

• Running with a server name: normal.
• Not Running: not started. Fine for agents you do not use (SNMP here).
• Start Failed: something tried to start it and it could not. Here the Reserve SMTP agent is switched on for the multiagents pod but Reserve mail is not configured (its domain is still the sample reserve.tririga.qa.tririga.com). Harmless if you do not use Reserve; otherwise fix the configuration.

Where an agent runs, and why

On OpenShift the multiagents pod is started with agent switches such as WF_AGENT=enabled, SCHEDULER_AGENT=enabled, MAINTENANCE_AGENT=enabled and RESERVE_SMTP_AGENT=enabled; the operator sets them from the FacilitiesWorkspace (agentsSpecs, empty here, means "use the defaults"). Each Liberty server has an instance ID (0 for the appserver, 3000 for multiagents), which is the number you see after the pod name.

TUNING THE AGENTS

Pages that configure agents

Thread Settings

Maximum worker threads per agent: WFAgent 80, DataImportAgent 6, SchedulerAgent 3, ReportQueueAgent 2.

How many things each agent may do at once. More WFAgent threads means more workflows in parallel, but also more database connections and memory. These values come from FACILITIES.properties (WFAgentMaxThreads=80 and so on); on MAS, change them there, not here.

Workflow Agent Info

Workflow agent settings.

• User and Group List: you can dedicate a workflow agent to certain users (for example, a heavy integration user). Not used here.
• Run Workflows Triggered By Scheduled Events As: the user that scheduled workflows run as (system).
• Workflow Instance Recording: Errors Only: instances are kept only for failed workflows. Switch to "All" briefly when you debug a new workflow, then back: recording everything fills the database.
• Workflow Max Threads 80, Max Active Threads Per User 70: the per-user limit stops one user (or one integration) from taking every thread.

Scheduler Info

How many occurrences a schedule with no end date generates ahead.

A recurring schedule with no end date would create endless events, so the scheduler only creates the next 100 daily or weekly, 50 monthly or 10 yearly occurrences, and tops them up later.

Maintenance Agent

Database maintenance commands and when to run them.

A small scheduler for database housekeeping: here Db2 table and index reorganisation (TRI_DO_REORG_TABLE_AND_INDEX) every Sunday. The cleanup itself (old workflow instances, stale records) runs daily at CLEAN_HOUR from FACILITIES.properties (0 here, midnight UTC). Agree this with your DBA: on MAS the database is often managed separately.

Reserve SMTP Agent

Inbound mail settings for room booking. Still the sample domain here, which is why the agent shows Start Failed.

WATCHING THE WORK

Workflow Events, Workflows Executing, Performance Monitor

These are the pages to open when "a workflow did not run" or "the system is slow".

Workflow Events: what is waiting in the queue (current events) and what is scheduled (future actions).

• Workflow Events in the Queue: pending events per user. Empty is good. A number that only grows means the WFAgent is stopped, overloaded or failing.
• Oldest Event in Queue: how far behind the agent is.
• Future Actions: actions waiting for a date (WFFutureAgent).

Workflows Executing: running and suspended workflow instances, with Stop, Suspend and Resume.

A workflow that never finishes (a loop, a lock) shows here with its current step and run time. Stop it here rather than restarting the server.

Performance Monitor: key metrics, refreshed every minute.

The quickest health check: CPU, heap, open database connections, workflow queue count and throughput, workflows started, completed and failed (since the server started), extended formula queue and logged-in users. "Record to Log" writes the numbers to the log, handy before and after a load test.

DATA

Database Info, Database Query Tool, Data Connect, Caches

Database Info

Database clock, code set and one-click maintenance tasks.

The top checks that the database and server clocks agree, and that the database is UTF-8 (CODEUNITS32 on Db2). The Database Admin Tasks run the cleanup jobs now instead of at night: clean up workflow instances, stale records, scheduled events, re-analyse statistics, check the organisation and geography hierarchies, deep cleanup, check and restore associations. They change data and can run for a long time: use them on purpose, outside business hours, with a recent backup.

Database Query Tool

SELECT-only SQL against the MREF database, with IBM's library of audit queries on the left.

Runs SELECT statements only. The list on the left is a library of ready-made audit queries (agent settings, record counts, workflow queue counts, logins). It is the fastest way to answer "did the workflow run?" (WF_EVENT_HISTORY) or "what is in this record?" (the T_<BO> table).

Data Connect

DataConnect jobs: one row per integration batch, with Ready, Fail, Retry, Delete.

When an external system writes rows into staging tables, DataConnect turns them into records in batches ("jobs"). This page shows each job's state and lets you retry or fail it. Empty here: no DataConnect integration is running.

Caches

Every cache, and what to flush after which change.

MREF keeps metadata in memory for speed. When a change does not show up, flush the matching cache rather than restarting: Workflows For Agent after publishing a workflow the agent does not pick up, Security Scope after organisation or group changes, Query Cache after query changes, Object MetaData Cache after Data Modeler work. All Caches (Global) flushes everything on every server; it is safe but makes the next minutes slower for everyone.

DIAGNOSTICS

Error Logs, Platform Logging, Metadata Analysis, Java Info, Must Gather

Error Logs

The log files of this server and the last 20 major exceptions.

Click a log to read it, "Roll" to start a fresh file. server.log is the main one. Remember it is the log of the UI server; agent errors are in the multiagents pod's log.

Platform Logging

Debug switches per area: agents, BIRT, publish, cache, DataConnect and more.

Tick a category to add DEBUG output for it to the log: for example Workflow Agent → Event check/pickup when workflows do not start. Untick it when you are done: debug logging is large and slows the server.

Metadata Analysis

System-wide self-tests; results go to the log.

Renders every form, runs every query, loads every workflow, generates publish DDL. Useful after an upgrade or a big migration to find broken metadata. Each one is heavy: run it on a test system or at night.

Java Info

JVM version, CPU, heap and the Java system properties.

Note the warning on Force Garbage Collection: it can pause the server. Leave it alone.

Must Gather Tool

Collects logs and settings into a package for IBM Support, linked to your case number.

Use it when IBM Support asks for it. On MAS, also collect the OpenShift side (the MAS must-gather) so support sees the pods too.

SYSTEM

System Info, Build Number, Licenses, Admin Users, Users Logged In

System Info

Property files, Lock System, value encryption, query and session settings, feature flags.

• Property Files: view the TRIRIGA properties and Liberty server.xml of this pod. On MAS, edit them through the FacilitiesWorkspace secrets, not here.
• Lock System: blocks new logins, for example during an Object Migration. Sign in to the application first, or you lock yourself out.
• Username and Password Encryption: encrypts a value for use in a properties file.
• User Session Timeout: 30 minutes here (the fallback while MAS's value cannot be read).
• Feature Flags: switches for newer behaviour, such as the Carbon-style record pages.

Build Number

Application 9.2.2 on platform 9.2.6, and the upgrade history (from 9.1.2 on 15 September 2026).

The first page IBM Support asks about. Code build, database build and language pack should all match.

Licenses

Licence types and what each one allows. User licences are managed in MAS.

On MAS, who gets which licence (and AppPoints) is decided in Suite Administration; this page only shows what each licence type unlocks.

Admin Users

Who may open which console page, one tick per page.

Two pages, Platform Properties and AES Encryption, are not ticked even for system: they are hidden from the menu until someone grants them. Keep it that way unless you need them.

Users Logged In

Lists active sessions (user, IP address, login time, last action) with a "Log Out User" action. Use it before locking the system or deploying a migration package. (No screenshot: it shows session identifiers.)

BEFORE YOU CLICK

Safe, careful and dangerous buttons

GLOSSARY

Words you will hear

Screens: IBM Maximo Real Estate and Facilities 9.2.2 (platform 9.2.6) on Maximo Application Suite and Red Hat OpenShift, test system, viewed read-only. Agent descriptions summarise IBM's documentation and what this system shows; check IBM's documentation for your version before changing anything.