Version and support position
Where the installed version sits against current and against support, and what the upgrade path realistically costs. On this platform that answer is frequently the single most important finding.
Search hans.study
Indexed across articles, news, KB updates, knowledge base, books, learning, and tools. Press Esc to close.
// LENEL ONGUARD HEALTH CHECK · HANS STUDY · ONTARIO, CANADA
OnGuard estates tend to be old, large, and load-bearing. They were installed when the organisation was smaller, they have absorbed every acquisition and expansion since, and upgrading them is difficult enough that many run several versions behind while everyone hopes nothing changes.
The defining characteristic of OnGuard environments is accumulation. Modules bought for one project, integrations added by successive integrators, cardholder data that has never been cleaned, and a database carrying fifteen years of history. The review follows that shape.
Where the installed version sits against current and against support, and what the upgrade path realistically costs. On this platform that answer is frequently the single most important finding.
OnGuard licenses by module and by count. Which modules are licensed, which are actually used, and where the estate has grown past what was bought.
Database sizing, maintenance plans, index and event history growth, archiving strategy, and backup and restore that has been tested. Long-lived OnGuard databases are rarely maintained proportionally to their age.
Firmware consistency across the field, memory and cardholder capacity against the population loaded, downstream device health, and offline behaviour when the server is unreachable.
Data hygiene at scale, stale records, access level sprawl, and whether the permission model can still be explained by anybody currently employed.
Video, intrusion, elevator, visitor management, HR and directory synchronisation. Each one is a dependency, and on older estates several were built by people who have moved on.
What actually survives a server failure, whether failover has been tested rather than assumed, and what the field does while the head end is unavailable.
Operator privilege model, service accounts, encryption and certificate posture, audit trail retention against policy, and patch discipline on a system that is often treated as untouchable.
Large organisations where OnGuard controls access to something that matters and where the institutional knowledge about it has thinned out. Healthcare, education, government, critical infrastructure, and enterprise campuses.
Most useful before an upgrade decision, ahead of a budget cycle, after the person who knew the system has left, or when a merger has brought two estates together.
The deliverable is a prioritized remediation plan, not a pile of observations you have to triage yourself.
Recommendations do not change based on who is selling. There is no product being steered toward at the end of this.
Remote delivery via the DHD, a remote access device, where the system cannot be reached over the network.
Screen share, supplied configuration exports, logs and documentation. Most of what a health check examines is visible without anyone travelling, and this is how the majority of engagements run.
The DHD, a pre-configured remote access device, ships to the site. Somebody on site plugs it into power and network, which takes minutes and needs no technical skill. It provides the access needed to examine the system properly, then ships back. Covers configuration, shipping both directions, and retrieval.
Cheaper and faster than travel for a single site, and it is what makes distance stop mattering. A site in another province costs the same to review as one an hour away.
For work that needs someone in the room: physical inspection, cabling and rack conditions, commissioning witness, or an environment that cannot be reached remotely. Travel and on-site time are added to the written quote before work starts.
Listed because an unstated exclusion is what turns an agreed scope into an argument at invoice time, and that is the exact failure this practice exists to review other people for.
Same structure and the same fixed pricing across every platform. The layers reviewed differ, because the ways these systems fail differ.
Architecture, roles and sizing under real load.
CrossFire, iSTAR estate, SQL dependency and integrations.
Edition, Device Pack currency and support entitlement.
Which product family you are in, and what that decides.
Edge analytics, and the device estate that limits them.
Edition ceiling, gateway topology, and controller firmware.
A system nobody wants to touch is not stable. It is unexamined, and the difference only becomes visible on the day it matters.
Independent of Lenel, Honeywell, and every integrator involved. See the independence policy.
Two tools run by default to help me understand how the site is used. You can turn either off at any time. Cloudflare's server-side analytics is always on and never sees your identity.