Upgrading to Genetec Security Center 5.14: The Runbook, the Order of Operations, and What Breaks

The migration paths page answers the question of which route your system can take to 5.14, and whether it needs a stop at 5.11 on the way. This is the next question: it is Friday evening, the change window is open, and the route is decided. What happens, in what order, and what do you check before deciding whether to go home or roll back.

I have run this upgrade on systems from thirty cameras to several thousand. The mechanics of the installer are the easy part and the vendor documents them well. The parts that go wrong are the ones the installer does not know about: the SDK plugin nobody remembered, the federated site three time zones away, and the fact that the Web Client the security manager uses every morning does not exist in 5.14.

What is different about 5.14 specifically

Three things in 5.14 change the upgrade in ways earlier releases did not.

The Web Client is retired. The browser-based Web App replaces it, and it is a different product with a different feature set and a different URL. Anyone who used the Web Client to monitor, to acknowledge alarms, or to run reports needs to be told before the upgrade, shown the Web App before the upgrade, and have their bookmarks changed after. This is a change management item, not a technical one, and it is the one that generates the most calls on Monday.

The media component is 64-bit. Security Desk and the media pipeline underneath it are 64-bit in 5.14. Client workstations that were marginal on 5.13 with 32-bit decoding may behave differently, generally better, but any third-party video plugin or decoder that was 32-bit only stops loading. Check the plugin list on the workstations, not just the servers.

5.14.0.1 followed the initial release within weeks. Upgrade to the current 5.14.x build, not to 5.14.0.0, and read the known issues for that build before the window. The release notes are specific about what was fixed between the two, and some of it matters.

Pre-flight, the week before

• Inventory, per component, with build numbers. The Directory, every Archiver, every Access Manager, the Media Router, every workstation, every SDK integration, and both ends of every federation. The migration page explains why the oldest component sets the route. The inventory is also your rollback map.
• Platform underneath. Windows Server build and SQL Server version checked against the 5.14 supported matrix. If either needs to move, that is a separate change, done first, with its own soak period. The Server 2025 delta is relevant if the OS move is to 2025.
• Database health. Size, free space, recovery model, and a backup that has been restored somewhere. The SQL article covers the checks. An upgrade runs schema changes against the Directory database, and a database on an Express install near its 10 GB limit will fail the upgrade rather than the upgrade failing gracefully.
• Licence. The licence must be valid for 5.14 and the SMA current. Genetec’s licence check happens at upgrade time, and discovering the maintenance agreement lapsed is not a Friday-night discovery you want.
• SDK and plugins. Every integration listed with its vendor and its 5.14 compatibility confirmed in writing. Intercom, intrusion, visitor management, elevator, LPR analytics, custom dashboards. The ones that are not 5.14-compatible either get updated before the window or get a decision: go without them, or postpone.
• Federation. Federated Security Center systems have their own version rules. Confirm the remote sites are within the supported range for a 5.14 host, and agree the upgrade order with whoever owns them.
• Client workstations. Count them, confirm each meets the 5.14 requirements, and check for 32-bit plugins. A plan for who upgrades each one and when.
• Backups, all of them. Directory database, every role database, the Genetec configuration through Server Admin, and a snapshot or image of each server if the platform allows it. Copied off the hosts. Tested.
• Communication. The Web Client retirement, the window, the expected outage, and the rollback deadline, sent to everyone who uses the system, a week out and again the day before.

Order of operations, the night of

The order matters because 5.14 components will talk to older roles during the transition, but not indefinitely and not in every direction. Directory first, then the roles that depend on it, then the clients.

1. Stop recording gracefully. Put the Archivers into a state where the last file closes cleanly. Note the time. Any gap in recording starts here and you will be asked about it later.
2. Final backups. Directory database and configuration, again, now that nothing is changing. This is the rollback point.
3. Directory server. Run the installer, let it upgrade the Directory database schema, and wait. On a large Directory database the schema migration can take a long time and it will look like nothing is happening. Do not interrupt it. When Server Admin comes back, confirm the Directory role is healthy and the build number is the one you expected before doing anything else.
4. Expansion servers, one at a time. Archivers, Access Managers, the Media Router, in whatever order minimises the recording gap, which usually means the busiest Archiver first. After each one, confirm the role comes up healthy in Config Tool and that it is recording or managing whatever it is meant to. Then the next.
5. Verify recording before moving on. Every Archiver recording, every camera streaming, timeline populating. This is the first go or no-go point: if recording is not healthy here, the rest of the night is troubleshooting rather than upgrading, and the rollback decision starts now.
6. Integrations. Bring up each SDK integration and confirm it connects. The one that fails is the one that was not confirmed in pre-flight.
7. Federation. Confirm each federated site reconnects and that entities and events flow both ways.
8. Clients. Upgrade Config Tool and Security Desk on the workstations, starting with the control room. Confirm login, live video, playback, alarm handling, and any plugin the operators depend on. Confirm the Web App is reachable and that the people who used the Web Client can do what they need in it.
9. Genetec Update Service. Confirm GUS sees the new build and is not about to apply something else on its own schedule.

The rollback decision

Decide the rollback deadline before the window opens, write it down, and hold to it. The usual shape: if recording and alarm handling are not healthy by a fixed time, with enough of the window left to restore, you restore. The decision is made against the checklist, not against how close you feel you are to fixing it.

Rollback for Security Center is a restore, not an uninstall. Restore the Directory database backup taken at step 2, reinstall the previous build on the Directory and the expansion servers, and restore each role’s configuration. The database schema was upgraded in place, which is why the pre-upgrade backup is the only way back. Snapshots of the servers make this faster and are worth the storage.

What rollback does not undo: video recorded during the upgraded period stays in whatever format the 5.14 Archiver wrote, and in practice it remains readable. Events written to the 5.14 schema are gone once the database is restored. Note the interval so the incident record is honest.

The first week

• Monday morning. Someone in the control room before the shift change, watching operators use the new Security Desk and the Web App. The complaints on Monday are almost never bugs; they are workflow changes nobody was shown. Ten minutes of standing next to an operator resolves most of them.
• Retention. Confirm the Archivers are keeping video for the configured period and that the free-space threshold behaviour is what it was. An upgrade is an opportunity for a default to reassert itself.
• Health Monitor. Review the health events for the week. An entity that went unhealthy at 02:14 on upgrade night and stayed there is easy to miss under the noise of the upgrade itself.
• Database. Re-run the maintenance job and check the Directory database size. The schema migration can leave indexes in a poor state and the first maintenance pass after an upgrade is the one that matters.
• Hardening. Apply the 5.14 hardening guide’s recommendations that were not in the previous release. An upgrade that leaves the system at the old release’s security posture is half done.
• Documentation. Build numbers, the date, what was changed, what was skipped, and why. The next person to do this will be reading it, and there is a fair chance it will be you.

Done this way the upgrade is uneventful, which is the only kind of upgrade a security system should have. The interesting part is the pre-flight, and the pre-flight is where the time goes. If a proposal for this work has one line for the upgrade night and nothing for the week before, it is a proposal for a different, more exciting evening than the one you want.