Genetec Security Center Alarms End to End: Camera Setup, Alarm Configuration, Video Pop-Up and Recording Until Acknowledgement

The chain we are building

Almost every alarm requirement we are sent for Security Center is a variation of the same sentence: when something happens, show the operator the right camera, and don't lose the video until they've dealt with it. It sounds like one feature. In Security Center it is five separate pieces of configuration, owned by different roles and tasks, and the gaps between them are where real deployments go wrong:

We'll take them in order. Menu paths below match recent Security Center 5.x releases; labels move slightly between versions, so treat them as directions rather than a script.

1. Configuring the camera

Enrolling the unit on an Archiver

In Security Center a camera never exists on its own. It belongs to a video unit (the encoder or IP camera as a device), and the unit belongs to an Archiver role, which connects to it, pulls its streams and writes them to disk. So the first decision is which Archiver owns the camera, because that decides where its video is stored and which server's failover protects it.

1. In Config Tool, open the Video task and select the Archiver that should own the camera.
2. Add an entity → Video unit, then pick the manufacturer and product type, the IP address and port, and the credentials the camera expects. For many manufacturers, unit discovery will find the device on the network and fill most of this in for you.
3. Once the unit is enrolled, its cameras (one per video channel) appear under it in the entity tree. Rename them now — the camera's name is what operators will see in the alarm list at 3 a.m., and Camera 1 on unit 192.168.10.44 helps nobody.

Streams and recording settings

On the camera's Video tab, each stream usage (live, recording, remote, low and high resolution) can point at a different encoder stream. The common pattern is a high-resolution stream for recording and a lighter stream for live viewing over constrained links. For alarm work, check that the stream you record is the one an investigator will actually want to export — a 640×360 sub-stream recorded to save disk is a problem you only discover on the day it matters.

The Recording tab either inherits the Archiver's defaults or overrides them per camera. The settings that matter for alarms:

If the site records continuously, most of the "recording until acknowledgement" problem becomes a retention problem: the video exists, you just have to stop it ageing out. If the site records on motion or on schedule, it's a recording problem first. Know which one you're solving before you configure the alarm.

2. Configuring the alarm

Alarms are entities too, created in Config Tool's Alarms task (Add an entity → Alarm). An alarm entity is a template: it describes how an alarm of this kind should behave, and each time it fires Security Center creates a separate alarm instance with its own ID, trigger time and source. That distinction matters later — you acknowledge an instance, not the alarm.

The properties worth setting deliberately:

• Priority — 1 is highest. It orders the alarm list and decides which alarm takes the operator's tiles when several arrive together.
• Recipients — the users, user groups or monitors that receive the alarm, and whether they get it all at once or in sequence. An alarm with no reachable recipient fires into silence.
• Attached entities — the cameras (and doors, areas, maps) shown when the alarm arrives. This is the single setting that makes a camera "pop up" natively; we come back to it below.
• Video display options — whether attached cameras show live video, playback from the trigger time, or both, and whether still frames are captured.
• Automatic video recording and protect recorded video — start recording on attached cameras when the alarm triggers, and protect what's recorded against retention clean-up for a set period.
• Reactivation threshold — how soon the same alarm from the same source can fire again. Too short and a chattering input buries the operator; too long and a genuine second event is swallowed.
• Automatic acknowledgement — acknowledges the instance after a timeout. Useful as a ceiling, dangerous as a default: an auto-acknowledged alarm looks handled in reports when nobody saw it.
• Procedure — a URL the operator opens from the alarm, typically the site's response instructions.

How the alarm is triggered

An alarm entity does nothing until something triggers it. The common sources:

• Event-to-actions — on the camera, unit, door, input or zone, map an event (motion on, input state changed, analytics event, door forced open) to the Trigger alarm action and pick the alarm entity. This is how most installations wire it.
• Zones and analytics — I/O zones, intrusion detection units and video analytics raise events that feed the same event-to-action mechanism.
• Operators — an alarm can be raised manually from Security Desk.
• The SDK — a plugin role or SDK application triggers the alarm in code when a third-party system says so: a fence controller, a PSIM, an LPR watchlist hit, a building management system. This is where most custom integrations start.

Gotcha — When a plugin triggers an alarm, pass the real source entity — the camera or custom entity that saw the event — rather than the plugin role itself. The source is what operators filter on, what reports group by, and what the reactivation threshold is counted against. Alarms whose source is always "the integration" are impossible to triage and throttle each other.

3. When the alarm is raised

Once an instance fires it moves through a small set of states, and every downstream behaviour — pop-up, recording, export, escalation — should key off these transitions rather than off timers of its own:

In Security Desk, recipients receive the instance in the Alarm monitoring task — an alarm list beside a canvas of tiles. Selecting an alarm (or letting it arrive automatically, depending on the operator's settings) loads its attached entities into the tiles: live video, playback from the trigger time, a map, a door. From there the operator can acknowledge, put it under investigation, snooze it or forward it to someone else. Each of those actions is itself an event, which is what makes the rest of this article possible.

4. Getting the camera onto the operator's screen

The native pop-up

For most sites, attaching the camera to the alarm and getting recipients right is the whole answer. The Alarm monitoring task loads attached cameras automatically, and the video display options decide whether the operator sees live, playback or both. Two native extensions cover a lot of the rest:

• The Display an entity in the Security Desk action, mapped from an event, pushes a camera to a chosen user or monitor — useful for a video wall or a supervisor who isn't an alarm recipient.
• Camera sequences attached to an alarm show several cameras in rotation when one tile isn't enough.

When a plugin needs to drive the pop-up

Native behaviour runs out when the decision about which video to show depends on information Security Center doesn't hold: the PTZ preset nearest a fence segment, the camera covering the lane an LPR read came from, a layout that combines video with a custom panel showing the third-party system's data. That is a Workspace SDK module — a client extension Security Desk loads — usually paired with a plugin role or SDK service that holds the business logic.

The shape is consistent across projects: the client module subscribes to alarm events, resolves the cameras for the instance, and places them in a dedicated task or a chosen monitor. The class names below are illustrative; the exact Workspace SDK types for tasks, tiles and monitors vary between Security Center releases:

public sealed class AlarmVideoModule : WorkspaceModule
{
    private AlarmVideoSettings _settings;   // read from the plugin role's config

    public override void Load()
    {
        _settings = AlarmVideoSettings.Load(Workspace.Sdk);

        // Fires for alarm instances this operator is a recipient of.
        Workspace.Sdk.AlarmTriggered += OnAlarmTriggered;
    }

    private void OnAlarmTriggered(object sender, AlarmTriggeredEventArgs e)
    {
        if (!_settings.HandlesAlarm(e.AlarmGuid)) return;

        // Our own rules: attached cameras plus any resolved from the
        // source (nearest PTZ preset, lane camera, zone map, ...).
        var cameras = CameraResolver.For(e.AlarmGuid, e.SourceGuid);

        // Marshal to the UI thread before touching tiles.
        Dispatcher.BeginInvoke(() =>
        {
            var task = AlarmVideoTask.OpenOrFocus(Workspace, _settings.TargetMonitor);
            task.ShowCameras(cameras, playbackFrom: e.TriggerTime.AddSeconds(-_settings.PreAlarmSeconds));
        });
    }

    public override void Unload()
    {
        Workspace.Sdk.AlarmTriggered -= OnAlarmTriggered;
    }
}

Three things separate a pop-up operators tolerate from one they ask to have removed: it must not steal focus from an operator mid-investigation on a higher-priority alarm, it must respect the operator's camera permissions (the SDK will happily show what the operator isn't allowed to see if you load it with a privileged connection), and it must cope with ten alarms arriving in two seconds without opening ten windows.

5. Keeping the recording until the alarm is acknowledged

This is the requirement behind most of the alarm work we're sent: from the moment the alarm fires until a person acknowledges it, the camera must be recording, and that footage must survive. It has to answer three questions — when recording starts, when it stops, and where the footage ends up. We build it with a storage target the customer chooses: if the plugin's configuration names a local storage path, the alarm clip is written there; if not, it stays on the Archiver as the default; and where the cameras support it, edge storage covers the case where the Archiver can't be reached at all.

Option A — the Archiver (the default)

This is native Security Center and needs no plugin for the core behaviour:

1. On the alarm, turn on automatic video recording so attached cameras start recording when the instance triggers, and protect recorded video so the footage is exempt from retention clean-up.
2. To tie recording to acknowledgement rather than to a fixed duration, add event-to-actions on the alarm entity itself: Alarm triggered → Start recording on the attached cameras with an unlimited (or long) duration, and Alarm acknowledged → Stop recording.
3. Add Alarm triggered → Add bookmark so investigators can find the moment without scrubbing.

What this doesn't give you is a ceiling (an alarm nobody acknowledges records forever), correct handling of overlapping instances on the same camera (the first acknowledgement stops recording that a second, still-active alarm needs), or a clip anyone can hand to a third party without a Security Center export. Those three gaps are why it's usually extended by a plugin role.

Option B — a local storage path set in the plugin

Here the plugin role owns the recording lifecycle and writes a self-contained clip to a folder the administrator sets in the plugin's configuration — a local disk on the server, or a UNC share on a NAS or evidence store. If the path is left empty, the plugin falls back to Option A and leaves the footage protected on the Archiver.

The design we use, in outline:

1. On trigger: record the instance ID, cameras and trigger time in the role's database (not in memory — the role can fail over mid-alarm), and make sure each camera is recording, reference-counted per camera so overlapping alarms don't stop each other's recording.
2. While active: nothing to stream. The Archiver is already recording; the plugin only watches for acknowledgement and for the maximum duration.
3. On acknowledgement (or on hitting the ceiling): release the camera's recording reference, protect the archive range, then export trigger time minus pre-alarm buffer to acknowledgement time plus post-alarm buffer from the Archiver to the configured path.
4. After export: compute a SHA-256 hash of the file, write a small sidecar (alarm, instance, source, cameras, operator, acknowledgement reason and time, hash), and record the result back on the instance so the trail is visible inside Security Center.

public sealed class AlarmRecordingAgent
{
    private readonly AlarmRecordingStore _store;     // role database, survives failover
    private readonly CameraRecordingLeases _leases;  // ref-counted per camera
    private readonly AlarmRecordingSettings _cfg;    // LocalStoragePath, buffers, max duration

    public void OnAlarmTriggered(AlarmInstance alarm)
    {
        var cameras = alarm.AttachedCameras();
        _store.Open(alarm.InstanceId, cameras, alarm.TriggerTime);

        foreach (var camera in cameras)
            _leases.Acquire(camera, alarm.InstanceId);        // starts recording if first lease

        BookmarkService.Add(cameras, alarm.TriggerTime, $"Alarm {alarm.Name} #{alarm.InstanceId}");
    }

    public void OnAlarmAcknowledged(AlarmInstance alarm, AckInfo ack)
        => Close(alarm.InstanceId, ack.Time, reason: ack.Reason);

    public void OnMaxDurationReached(int instanceId)
        => Close(instanceId, DateTime.UtcNow, reason: "Max duration reached — escalated");

    private void Close(int instanceId, DateTime end, string reason)
    {
        var rec = _store.Get(instanceId);
        if (rec == null || rec.Closed) return;               // idempotent: ack and timeout can race

        foreach (var camera in rec.Cameras)
            _leases.Release(camera, instanceId);             // stops only when no alarm still needs it

        var from = rec.TriggerTime - _cfg.PreAlarm;
        var to   = end + _cfg.PostAlarm;
        ArchiveProtection.Protect(rec.Cameras, from, to, _cfg.ProtectFor);

        if (!string.IsNullOrWhiteSpace(_cfg.LocalStoragePath))
            ExportQueue.Enqueue(new ExportJob(rec, from, to, _cfg.LocalStoragePath)); // retried, hashed
        // else: footage stays protected on the Archiver (the default)

        _store.MarkClosed(instanceId, end, reason);
    }
}

The export runs from a queue with retries rather than inline in the event handler, because the Archiver may still be flushing the last seconds of video at the moment of acknowledgement, and because a network share that's unavailable for ten minutes should delay the clip, not lose it.

Gotcha — "Local" path means local to whichever server the plugin role is running on. After a failover, D:\AlarmClips is a different disk on a different machine. In any deployment with role failover, configure a UNC path the role's service account can write to from every server in the failover list, and check its free space and permissions on startup — not on the first alarm.

Option C — on the camera's edge storage

Many cameras can record to an SD card or onboard storage. Security Center can retrieve that edge footage into the Archiver afterwards (often called trickling, or archive transfer in recent releases), which closes the gap when the network or the Archiver was down during the alarm — exactly when you'd least want to lose it. Edge storage is configured per camera and depends heavily on the manufacturer and on the camera's support in Security Center; it's a resilience layer, not a replacement for Options A or B.

The plugin's role here is bookkeeping: if the camera was offline during the instance, mark the clip as pending, request the edge range be retrieved once the camera reconnects, and run the export only after the gap is filled.

Choosing between them

6. The edge cases that decide whether it works in production

• Reactivation inside an active alarm. If the same alarm fires again while the first instance is unacknowledged, decide whether that extends the existing recording or opens a new instance and clip — and make the reactivation threshold agree with that decision.
• Many alarms, one camera. Reference-count recording per camera. The first acknowledgement must not stop recording another alarm still needs.
• Unacknowledged forever. Always set a ceiling, and escalate when you hit it rather than silently stopping. This is precisely what XPlug.SmartNotifier's escalation handles: an alarm nobody acknowledges moves to the next person, by WhatsApp, Teams or phone, with the video link attached.
• Auto-acknowledgement. Treat it as a separate outcome in the sidecar and reports. Footage from an alarm no human saw is often the footage someone asks for later.
• Role failover mid-alarm. Instance state in the role database, idempotent close, and a startup sweep that reconciles open instances against Security Center's actual alarm state.
• Clock drift. Export ranges are computed from server timestamps; cameras with drifting clocks put the event outside the clip. NTP on every unit, and a generous pre-alarm buffer.
• Permissions and privacy. Exported clips leave Security Center's permission model. The folder needs its own access control and retention policy, and in GDPR jurisdictions that policy should be written down.

Where projects usually need a specialist

Everything up to Option A is configuration a capable integrator can do in an afternoon. The parts that take experience are the ones in section 6: recording that survives overlapping alarms and role failover, pop-ups that respect operator permissions and priority, exports that are provably complete and tamper-evident, and all of it still working after the next Security Center upgrade. That is the alarm work we've been building inside Genetec and Milestone systems since 2014 — as one-off Genetec plugin development projects, and as XPlug.SmartNotifier where the requirement is getting the alarm to a person, not just a screen.

Working with Xplug.in

Email us your alarm requirement — get a straight answer on how to build it

• Tell us the trigger, the screen and where the video must end up. Even three lines is enough: what raises the alarm, who should see which camera, and where footage must be kept until acknowledgement. We reply with what's native configuration, what needs a plugin, and what we'd flag first.
• Configuration we'll just tell you. If Security Center does it out of the box, we'll say so and point at the settings — no project required.
• Plugins built for real alarm load — reference-counted recording, failover-safe state, a configurable local or network storage path with the Archiver as default, hashed exports and audit sidecars, Security Desk pop-ups that respect permissions and priority.
• Source and IP transferred to you at delivery, certified through Genetec's DAP where it will be distributed, and version-tracked as Security Center releases move.

Email your requirement Use the contact form

Xplug.in is a Genetec Technology Partner, working within the Development Acceleration Program, with 140+ plugins shipped since 2014 — alarm integrations, plugin roles, Security Desk extensions and third-party bridges. Write to contact@xplug.in; a straight technical answer costs you one email.

Questions we get asked

Can Security Center keep recording a camera until an alarm is acknowledged without a plugin?

Largely, yes. Turn on automatic video recording on the alarm so attached cameras start recording when it triggers, protect the recorded video, and pair a Start recording action on the alarm's triggered event with a Stop recording action on its acknowledged event. Test the exact behaviour on your Security Center version, including what happens on reactivation and auto-acknowledgement. A plugin becomes necessary when you also need the clip copied to a specific local or network path, hashed, or handed to another system.

How do I make a camera pop up automatically when an alarm fires in Genetec?

Attach the camera to the alarm entity and make sure the operator is a recipient — the Alarm monitoring task in Security Desk then shows the attached cameras in tiles when the alarm arrives. For pop-ups outside that task, the Display an entity in the Security Desk action can push a camera to a user or monitor, and a Workspace SDK module can open video in a dedicated task, a specific monitor or a custom layout driven by your own logic.

Where should alarm video be stored: the Archiver, a local folder or the camera's SD card?

The Archiver is the default and the system of record — it is backed up, permissioned and audited. A local or network folder is for when the clip must leave the VMS, for a case file, an insurer or a third-party system. Edge storage on the camera protects against network or Archiver outages and is pulled back into the Archiver afterwards. Most production designs use the Archiver first and add one of the other two for a specific reason.

What happens to the recording if nobody acknowledges the alarm?

Without a limit, the camera records indefinitely, which is why a recording-until-acknowledgement design always needs a ceiling — a maximum duration after which recording stops and the alarm is escalated. The alarm's own automatic acknowledgement timer is one such ceiling; an escalation layer such as XPlug.SmartNotifier is another, routing the unacknowledged alarm to the next person rather than letting it sit.