It asks one question, over and over.

An application on the core that communicates with equipment and reports general information on equipment alarms. Motorola files it under Fault Management. That is the org chart. This is the tool.

What it tells you is narrower than the interface suggests. UEM knows essentially two things. First: can I reach this device? Second, and only if the device speaks SNMPv3, a general description of an alarm the device reports — a router's degraded statistics, for instance.

That is the whole model. It does not correlate, rank, or diagnose. A device that cannot do SNMPv3 gives you the first thing and nothing else.

A ticket lands. You log in and start where you always start: the default view of the whole system. One question — is the alarm clear?

If the alarm is active, the reported fault is real, right now. If it is clear, the report did not survive contact with the system, and what you are holding is no longer the ticket you were sent.

It is tempting to look for a taxonomy — combinations of alarms that decode to a named cause. Asked which alarms travel together, the answer was flat: that's it. Can it talk to the equipment or not.

A VPM in comm fail tells you the VPM lost power before you leave the office. Not because comm fail means power, but because the VPM stopped answering, and power is what usually stops it. The alarm is the same alarm it always is.

When the board is lit, there is no shortcut. You drill down.

An alarm's presence is not proof of a live fault, and its absence is not proof of health. You watch for fifteen to twenty minutes. If it stays clear, the ticket closes and nobody touches the equipment.

The alarms that mislead are the ones that bounce — a flaky network link that drops, recovers, drops again. Each recovery looks like a resolution. It cleared, you closed it, and it came back.

Whether this one is worth chasing or worth waiting out is a judgment call. It is made on experience, not on a rule.

UEM is not only an instrument. The GTR 8000 manual documents base-radio diagnostics inside it — reset, service mode. Field engineers reset radios and site controllers from UEM without hesitating.

The reasoning is direct: if the equipment isn't working, a remote reset can't make it worse. It is a reboot. Minutes at most.

And a site controller reset does not take the site down. Sites run two or three controllers for redundancy. That structural fact is why the action is safe, and it is not visible anywhere on the alarm screen.

The NOC watches UEM and raises tickets from it. When one reaches you, you open UEM and confirm — and that is a real check, not a circular one, because the alarm is a live question, not a stored claim. You are not re-reading the ticket. You are asking the equipment again, now.

Which is why NOC tickets are frequently already answered. The alarm cleared. Or you are standing at the equipment, working on it, and the NOC ticketed the outage you created.

Telling which kind of ticket you are holding is sometimes hard. You drill down. And the one thing UEM cannot see is the customer's backhaul microwave — for that you look somewhere else entirely.

UEM is a virtual machine on the core's VMS server. Everything it knows, it learns by reaching across the network to the equipment. Its blind spot is therefore structural, not a defect: when a site goes silent, UEM reports that the site went silent. See where it sits in the core →

A site that lost commercial power comm-fails. A site whose backhaul dropped comm-fails. From the core these are the same event — the whole site, gone quiet.