Welcome back to our MAS 9 installation series! In Part 1, we explored the architectural shift from WebSphere to OpenShift. In Part 2, we assembled the ingredients: entitlement keys, DNS records, certificates, and hardware. In Part 3, we installed Red Hat OpenShift. In Part 4, we installed Maximo Application Suite and watched a Tekton pipeline chew through 90 minutes of our lives.

In Part 5, we turn that working installation into something you would actually let users touch.

Here’s the thing nobody tells you: getting MAS installed is not the same as getting MAS ready. Right now you have a Suite Admin console protected by a self-signed certificate that makes every browser act like you’re asking it to walk into a windowless van, a Maximo Manage application that may not be talking to a database yet, exactly one user account (yours), and no plan for what happens when a certificate expires on a Saturday. This article fixes all of that.

If your experience is anything like ours, this is also the phase where MAS stops being a project and starts being a system. Projects get installed. Systems get maintained. The difference is everything in this article.

We’ll cover four major areas:

• Certificates – replacing self-signed certificates with trusted ones so your users stop seeing browser warnings
• Database integration – connecting Maximo Manage to your database and activating the application
• User setup – SMTP, identity providers, entitlements, and getting actual humans into the system
• Day-2 operations – the monitoring, backup, and upgrade routines that keep it all running

Prerequisites Check (Before You Start)

Before diving in, confirm you have the following. Most of these are outputs from Part 4, plus a few new items you’ll want to chase down from your security and database teams now rather than mid-task.

• MAS installed and healthy – The Suite Admin console at https://admin.mas.yourdomain.edu loads and you can log in with the admin user created during installation.
• oc CLI access from the bastion host – oc get pods -n mas-sno-core shows everything Running or Completed.
• CA-signed certificates – The certificate, private key, and full CA chain covering the domains listed in Part 2. If you are staying self-signed for a dev environment, that is fine, you can skip ahead.
• Database server ready – SQL Server (or Db2/Oracle) reachable from the cluster, with the maximo database created and the maximo user set as db_owner.
• SMTP server details – Hostname, port, and credentials for a mail relay. Without this, user invitation emails go nowhere and password resets become your new part-time job.
• Identity provider details (optional but recommended) – LDAP connection info or SAML metadata from whoever runs identity at your organization.

Step 1: Certificates – Trading Browser Warnings for Trust

Self-signed certificates got you through installation, but they have two problems in the real world. First, every user sees a scary browser warning and half of them will email you about it. Second, and more seriously, API integrations, mobile clients, and anything else that talks to MAS programmatically will refuse to connect to an untrusted endpoint unless you disable verification, which is a habit you do not want to teach your integration developers.

MAS supports manual certificate management, meaning you provide your own public TLS certificates rather than letting the installer generate self-signed ones. You can apply them either through the Suite Admin UI or by updating the certificate secret directly in OpenShift. We’ll cover both.

What Your Certificate Must Cover

Quick recap from Part 2: your certificate needs Subject Alternative Names (SANs) covering every MAS endpoint. A wildcard certificate for *.mas.yourdomain.edu is the simple option, but note that a single-level wildcard does not cover *.manage.mas.yourdomain.edu or *.home.mas.yourdomain.edu, so multi-level entries need to be listed explicitly or covered by additional wildcards:

• admin.mas.yourdomain.edu
• auth.mas.yourdomain.edu
• api.mas.yourdomain.edu
• home.mas.yourdomain.edu and *.home.mas.yourdomain.edu
• [workspace].manage.mas.yourdomain.edu and *.manage.mas.yourdomain.edu

SAN Gotcha

The number one certificate mistake we see: a wildcard cert for *.mas.domain that does not cover the second-level subdomains Manage uses. Your admin console works fine, then Manage throws certificate errors and you spend an afternoon confused. Check the SAN list against the full route list before you submit the CSR.

Option A: Upload via the Suite Admin UI

The point-and-click path (yes, they still let us have one):

• Log in to the Suite Admin console and go to Administration.
• Under Manual certificates, choose to add or replace the certificate.
• Paste or upload the certificate, the private key, and the CA chain.
• Save. The operator rolls the change out to the affected routes automatically over the next several minutes.

Option B: Update the Certificate Secret Directly

If you prefer the command line, or you’re scripting this for repeatability (good instinct), the public certificate lives in a secret named [instance]-cert-public in the MAS core namespace. First, assemble your full chain. Order matters: leaf certificate first, then intermediates, then root.

# Build the full chain file (order: leaf -> intermediate -> root) cat server.crt intermediate.crt root.crt > tls-chain.crt   # Update the public certificate secret in the core namespace oc create secret tls sno-cert-public \   --cert=tls-chain.crt \   --key=server.key \   -n mas-sno-core \   --dry-run=client -o yaml | oc apply -f -

Give the operators a few minutes to reconcile, then verify from the bastion host:

# Confirm the endpoint presents the new certificate and full chain openssl s_client -connect admin.mas.yourdomain.edu:443 \   -servername admin.mas.yourdomain.edu -showcerts </dev/null \   | openssl x509 -noout -subject -dates -ext subjectAltName

You should see your certificate’s subject, a validity window that isn’t about to expire, and the complete SAN list. If your browser still shows warnings after this, clear the browser cache first before assuming the worst, browsers cache certificate state aggressively.

Write It Down

Record the certificate expiration date somewhere that is not your memory. Set a calendar reminder 30 days out. Certificate expiry is the most preventable outage in all of IT, and it still happens everywhere, constantly. We will come back to this in day-2 operations.

Step 2: Database Integration – Where Maximo Actually Lives

MAS Core is happy with its internal MongoDB for configuration data, but Maximo Manage needs a real database: IBM Db2, IBM Db2 Warehouse, Microsoft SQL Server, or Oracle Database. Continuing this series’ theme, we’ll use SQL Server, but the process is nearly identical for the others.

In WebSphere days, you configured the database connection in maximo.properties and hoped. In MAS, the database connection is a JDBC configuration object managed through the Suite Admin console, and the Manage activation process builds the entire schema for you. It is genuinely better, provided you set it up correctly the first time.

Prepare the Database

Maximo is picky about database settings, and fixing them after the schema is built ranges from annoying to impossible. For SQL Server, before you connect anything:

• Case-sensitive collation – Create the database with SQL_Latin1_General_CP1_CS_AS. Maximo requires case sensitivity, and no, you cannot change this later without rebuilding.
• Snapshot isolation – Enable ALLOW_SNAPSHOT_ISOLATION and READ_COMMITTED_SNAPSHOT on the maximo database.
• Dedicated maximo login – The maximo user must be db_owner of the maximo database. Test the login from SQL Server Management Studio before blaming MAS.
• Network path from the cluster – The SQL Server must be reachable from the OpenShift node itself, not just the bastion. Verify with: nc -zv [sqlserver-host] 1433 from a debug pod or the node.

-- Run on SQL Server before activation ALTER DATABASE maximo SET ALLOW_SNAPSHOT_ISOLATION ON; ALTER DATABASE maximo SET READ_COMMITTED_SNAPSHOT ON;

Create the JDBC Configuration

In the Suite Admin console, go to Configurations and create a new Database (JDBC) configuration. You’ll choose a scope: System-wide, or specific to an application or workspace. For a single-instance SNO deployment with just Manage, scoping it to the Manage application in your workspace is the cleanest choice.

The connection string follows the same format we previewed in Part 4:

-- Run on SQL Server before activation ALTER DATABASE maximo SET ALLOW_SNAPSHOT_ISOLATION ON; ALTER DATABASE maximo SET READ_COMMITTED_SNAPSHOT ON;

Enter the maximo user credentials, and if your SQL Server uses SSL with a certificate that isn’t publicly trusted (most internal ones), upload the server certificate you exported to a .pem file back in Part 4. The console validates the connection when you save, which catches most typos immediately rather than 40 minutes into activation.

Activate Maximo Manage

Now for the main event. In Suite Admin, open your workspace, select Maximo Manage, confirm the components you want (base Manage plus the JMS bundle we recommended in Part 4, and any add-ons like Health), point it at your JDBC configuration, and click Activate.

Then settle in, because activation is the long pole of this entire article. The maxinst process builds the complete Maximo database schema: every table, index, and view, from scratch. Expect 1 to 3 hours depending on your hardware and database latency. You can watch it work:

# Watch the Manage activation pods oc get pods -n mas-sno-manage -w   # Follow the maxinst logs (the schema build) oc logs -f -n mas-sno-manage -l mas.ibm.com/appType=maxinstPod

Demo Data Decision

During activation you will be asked whether to load demo data (the classic MAXDEMO content). For a sandbox, load it, it is handy for training and testing. For anything that will ever touch production data, skip it. Removing demo data after the fact is somewhere between tedious and archaeological.

When activation completes, the workspace shows Manage as Active, and your users’ future home is live at https://[workspace].manage.mas.yourdomain.edu. Log in once to bask in it. Then close the tab, because you still have no users.

Step 3: User Setup – Letting Other People In

So far, everything has been you and the admin account. Time to fix that. User setup in MAS involves three layers that WebSphere veterans will half-recognize: how users authenticate (identity provider), what suite-level entitlement they hold (this is new, and it costs AppPoints), and what they can do inside Manage (the security groups you already know).

First: Configure SMTP

Do this before creating any users. MAS sends account invitations and password resets by email, and without an SMTP configuration those messages silently go nowhere while you wonder why nobody can log in.

In Suite Admin, go to Configurations, select SMTP, and enter your mail relay’s hostname, port, sender address, and credentials. Send the test email. Actually confirm it arrives, spam filters love eating automated mail from new senders, and your first twenty users will all report ‘I never got the email’ in unison.

Identity: Local Users, LDAP, or SAML

MAS ships with a local user registry, which is perfectly fine for dev and small deployments: accounts live in MAS, passwords are managed there, done. For production, you almost certainly want to connect your enterprise identity provider instead, and MAS supports both LDAP (Active Directory and friends) and SAML single sign-on. Both are set up under Configurations in Suite Admin.

• LDAP – Provide the connection URL, bind credentials, base DN, and user/group filters. MAS synchronizes users from the directory, and your Active Directory team gets to keep owning passwords, which they enjoy.
• SAML – Exchange metadata with your IdP (Entra ID, Okta, ADFS, etc.). Users get true single sign-on into MAS and Manage. Slightly more setup, dramatically fewer password tickets.

Break Glass

Whatever you choose, keep at least one local administrative account that does not depend on the external IdP, and store its credentials in your password vault. When LDAP is down or the SAML certificate expires (see: certificates, above), that local account is how you get back in the door.

Entitlements and AppPoints

Here’s the part with no WebSphere equivalent: every user you create holds an entitlement type, and entitlements consume AppPoints from the license pool you installed in Part 4. Premium users get access to everything and cost the most points; Base users cover typical day-to-day Maximo work; Self-Service users are the cheap seats for people who only submit and view their own requests. Exact point values depend on your license agreement, so check your entitlement documents or the IBM licensing documentation before you promise 500 colleagues Premium access.

Remember the note from Part 2: AppPoints are shared across all your MAS environments. Dev, stage, and production all drink from the same pool. The License usage page in Suite Admin shows current consumption, and it belongs in your weekly routine (more on that shortly).

Creating Users and Granting Access

From Suite Admin, open Users and create your first real user: name, email, entitlement type, and which applications in which workspaces they can access. Grant Manage access, and the user is synchronized into Maximo Manage automatically.

Inside Manage, the security model is the one you already know from 7.6: security groups control application access, site access, and permissions. New MAS users land in the default group (MAXDEFLTREG, same as ever), and you assign them to real security groups from there. Your MAXADMIN muscle memory transfers over completely, it is honestly a little comforting.

• Create the user in Suite Admin with the right entitlement.
• Grant access to the Manage application in the workspace.
• Wait for the sync (usually a few minutes), then assign security groups in Manage under Security > Users.

Sync Patience

User synchronization between MAS Core and Manage runs on an interval. If a freshly created user is not visible in Manage yet, give it five minutes before you start troubleshooting. We have both debugged sync issues that resolved themselves faster than we did.

Step 4: Day-2 Operations – Keeping the Lights On

Everything up to now was still installation, just with extra steps. This section is about what you do every day, week, and month after. In WebSphere-land, your day-2 toolkit was log files, heap dumps, and intuition. OpenShift gives you dramatically better tools, but only if you actually set up the routine to use them.

The Daily Health Check

Three commands from the bastion host tell you most of what you need to know. Run them with your morning coffee:

# Cluster operators: healthy output is no output oc get co | grep -v "True.*False.*False"   # Any pods misbehaving anywhere? oc get pods -A | grep -Ev "Running|Completed"   # Storage filling up? oc get pvc -A

Pair that with a glance at the Suite Admin dashboard, which surfaces the health of MAS Core and each application. If both are quiet, go about your day. If not, OpenShift’s events and pod logs will usually tell you exactly what is unhappy, in its own cryptic dialect that you are, by now, learning to speak.

Monitoring and Alerts

Remember the comparison table from Part 1: monitoring went from ‘WebSphere logs and Tivoli tools’ to built-in Prometheus and Grafana. OpenShift ships with a full monitoring stack that is already scraping your cluster. Your job is just to make it talk to you: configure Alertmanager with an email or Slack receiver so that node pressure, degraded operators, and certificate expiry warnings reach a human before users do.

The alerts worth caring about first: node memory and disk pressure (SNO has no spare node to lean on), persistent volume usage over 80 percent, pod restart loops in the mas-* namespaces, and anything mentioning etcd. On a single node, storage pressure is the one that sneaks up on people, Manage attachments and logs grow quietly until they don’t.

Backups: The Uncomfortable Conversation

Here is an uncomfortable truth about our SNO setup: it is a single node. If that machine dies, high availability is not coming to save you, your backups are. A restorable MAS environment needs four things backed up on a schedule:

• The Maximo database – This is your crown jewels. Use native database tooling (SQL Server backup jobs, Db2 backup) on at least a daily schedule, stored somewhere that is not the same machine.
• MAS configuration (MongoDB) – MAS Core stores users, configurations, and suite settings in its internal MongoDB. Back it up with mongodump from the mongoce namespace, or at minimum export your Suite CRs: oc get suite,manageapp,manageworkspace -A -o yaml.
• Secrets and certificates – Export the cert secrets and your masconfig directory (entitlement key, license.dat, pull secret) to your password vault or a secured repo.
• Persistent volumes – Attachments, doclinks, and logs live on PVs. Snapshot or file-level backup per your storage platform.

Test the Restore

A backup you have never restored is a rumor, not a backup. Once a quarter, restore the database backup to a scratch environment and confirm Maximo actually starts against it. The first time you test this should not be during an outage.

Updates and Upgrades

MAS updates arrive through operator channels, which means the days of downloading fix packs and scheduling weekend outages are mostly behind you. The MAS CLI gives you two commands with importantly different jobs:

• mas update – Applies maintenance updates within your current channel (9.0.x to 9.0.y). Dependencies and operators are updated in the right order automatically.
• mas upgrade – Moves you to a new subscription channel (9.0 to 9.1). Bigger deal, more planning, read the release notes first.

OpenShift itself also needs regular updates, and MAS versions support specific OCP version ranges. Before touching either, check IBM’s compatibility matrix, upgrade OpenShift and MAS in a supported sequence, and always run updates in a dev environment before production. The operators make updates far less dramatic than the WebSphere fix pack ritual, but ‘less dramatic’ is not ‘zero risk’, take a backup first (see previous section, which conveniently exists).

When You Need IBM Support

Eventually you will open a support case, and IBM will ask for diagnostic data. The MAS CLI has a command that collects everything they need in one shot:

# Collect MAS + cluster diagnostics for an IBM support case mas mustgather -o /tmp/mustgather

Run it before you open the case and attach the output. It routinely saves a full round-trip of ‘please run must-gather and reattach’, which, given support ticket response cadence, can save you actual days.

The Operations Cadence

Pulling it all together, here is the rhythm we recommend:

Frequency	Tasks
Daily	Health check commands, Suite Admin dashboard glance, confirm database backup ran
Weekly	Review License usage (AppPoints), check PV capacity trends, review alert noise, check for MAS maintenance updates
Monthly	Apply MAS maintenance updates (dev first), review OpenShift update channel, verify MongoDB/config backups
Quarterly	Test a database restore, review certificate expiry dates, review user entitlements against actual usage, evaluate OCP/MAS version currency

Post-Configuration Checklist

Before you declare this environment production-ready, verify:

• Trusted certificate installed; no browser warnings on admin, home, or Manage URLs
• Certificate expiry date recorded with a 30-day calendar reminder
• JDBC configuration validated and Maximo Manage shows Active in the workspace
• Database created with case-sensitive collation and snapshot isolation enabled
• SMTP configured and test email confirmed received (not in spam)
• Identity provider connected, or local registry consciously chosen for dev
• Break-glass local admin account stored in your password vault
• First real users created, synced into Manage, and assigned security groups
• License usage reviewed; AppPoints consumption understood
• Database, MongoDB/config, secrets, and PV backups scheduled
• Alertmanager configured to notify a human
• mas mustgather tested once so you know it works before you need it

Conclusion: You Have a System

Look at what just happened. Four articles ago, MAS 9 was an intimidating architecture diagram. Now you have a Maximo environment with trusted certificates, a live database, real users logging in through your identity provider, and, most importantly, the operational scaffolding: backups, monitoring, and an update routine, that separates ‘it works on my cluster’ from production.

This is also the moment the job quietly changes. Installation was a sprint with a finish line. Operations is a habit. The good news, as we have said since Part 1, is that the OpenShift toolkit makes the habit lighter than it ever was on WebSphere: operators handle the tedium, Prometheus watches the gauges, and your daily check fits inside one cup of coffee.

Coming up in Part 6, we tackle the question every Maximo 7.6 shop has been waiting to ask: how do we get our data into this thing? We’ll cover migration planning, what actually moves from 7.6 to Manage, and the gotchas that live between them.

You built it, you secured it, you can restore it. Go ahead and retire the stress ball. (Keep it in the drawer, though. Just in case.)

Resources

– IBM MAS 9 Documentation: https://www.ibm.com/docs/en/mas

– Manual Certificate Management: https://www.ibm.com/docs/en/mas-cd/continuous-delivery?topic=management-manual-certificate

– MAS CLI GitHub: https://github.com/ibm-mas/cli

– IBM License Key Center: https://licensing.flexnetoperations.com

– OpenShift Monitoring Documentation: https://docs.openshift.com/container-platform/4.16/observability/monitoring/monitoring-overview.html

Stay tuned for Part 6: Migrating Your Data from Maximo 7.6!

About

A3J Group is a leading solutions and consulting firm based in Tampa, Florida, specializing in Enterprise Asset Management (EAM) with a focus on fully developed Computerized Maintenance Management System (CMMS) solutions like IBM Maximo.

In addition to our suite of proprietary products—including MxMobile, our powerful mobile solution for Maximo—we provide traditional consulting services that help organizations plan, implement, optimize, and support their EAM strategies. Whether clients need hands-on configuration, strategic guidance, or ongoing system support, our team delivers the expertise to drive long-term success.

With over 50 years of combined experience, our specialized team is dedicated to our core mission: to serve as excellent stewards of our clients’ trust and investments, while driving measurable results through tailored, high-impact solutions and intelligent consulting.

Visit us at www.a3jgroup.com. Or drop us a line at info@a3jgroup.com.