How to Build a Custom Genetec Security Center Plugin Using the Genetec SDK

Two different things people mean by "Genetec SDK"

Genetec ships two distinct SDK surfaces under the Security Center umbrella, and confusing them is the most common early misstep:

• The Security Center SDK (Genetec.Sdk) is a client library for building standalone applications that connect to Security Center over the network — logging in as an SDK user, querying entities, subscribing to events, pulling live and archived video. This is what you'd use to build an external service or bridge that talks to Security Center.
• The Plugin Framework is what most people mean by "a Genetec plugin" — an in-process extension that installs as a Role on the Genetec Server and, optionally, ships a matching extension that Security Desk and Config Tool load directly. This is the closer analogue to a Milestone MIP SDK plugin, and it's what this guide covers.

Plugin architecture: role, agent, and client extension

A Genetec plugin is typically organized as three coordinated pieces, all sharing a common plugin GUID so Security Center can associate them at runtime:

• The Plugin Role — a background service entity that runs on the Genetec Server, configured and monitored from Config Tool exactly like Genetec's own built-in roles (Archiver, Access Manager, and so on). This is where persistent logic lives: talking to a third-party system, running scheduled jobs, reacting to Security Center events.
• Agents — units of work the Plugin Role owns and supervises. A plugin can register one or more agents that each handle a specific responsibility (an event listener, a polling worker, a device bridge), and Genetec Server manages their lifecycle alongside the role itself.
• Client extensions — separate assemblies that Config Tool and Security Desk load to give operators and administrators UI for the plugin: property pages for configuring the role, custom entity browser nodes, and task or workspace panels inside Security Desk.

This split matters for how you design a plugin: server-side logic in the role/agents keeps running whether or not any operator has Security Desk open, while the client extension is purely presentational and only matters when a user is actively looking at it.

Custom entity types

Security Center's entire object model is built from entities — cameras, doors, cardholders, areas, alarms, and roles are all entities with a type, a GUID, and a position in the system tree. A plugin can introduce its own custom entity types that live alongside Genetec's built-in ones: a custom device type representing a third-party sensor, a configuration entity holding plugin-specific settings, or a logical grouping entity that shows up in Config Tool's entity browser and can be referenced from macros, schedules, and reports just like any native entity.

This is what makes Genetec plugins feel native rather than bolted-on: once a custom entity type is registered, it participates in Security Center's existing permission model, audit trail, and entity browser search — you don't rebuild any of that plumbing yourself.

Illustrative plugin structure

The exact base classes vary by SDK version, but the shape of a plugin solution is consistent across releases — a role project, an agent, and a Security Desk extension coordinating through the shared plugin GUID:

using Genetec.Sdk.Plugin;

namespace Xplug.GenetecPlugin
{
    // Registered in Config Tool as a Plugin role; supervises one
    // or more agents and exposes configuration to Config Tool.
    public class XplugPluginRole : Plugin
    {
        public override void OnLoad()
        {
            base.OnLoad();
            RegisterAgent(new XplugEventAgent(this));
        }

        public override void OnUnload()
        {
            // Release connections, stop timers, flush queued work.
            base.OnUnload();
        }
    }
}

namespace Xplug.GenetecPlugin
{
    // Owned and supervised by the role; handles one responsibility,
    // e.g. listening for a specific Security Center event class.
    public class XplugEventAgent
    {
        private readonly XplugPluginRole _role;

        public XplugEventAgent(XplugPluginRole role)
        {
            _role = role;
        }

        public void OnEntityEvent(Guid entityId, string eventType)
        {
            // Dispatch to a third-party system, raise a custom
            // alarm, write an audit entry — the plugin's actual work.
        }
    }
}

namespace Xplug.GenetecPlugin.SecurityDesk
{
    // Loaded by Security Desk; contributes a task or workspace
    // panel bound back to the plugin role's configuration/state.
    public class XplugSecurityDeskExtension
    {
        public void Initialize()
        {
            // Register a custom task, entity browser node, or
            // property page scoped to the plugin's entity types.
        }
    }
}

The role and agent classes are the source of truth for behavior; the Security Desk extension is a thin, UI-only layer reading and writing state through the role rather than duplicating logic client-side.

Deploying a Genetec plugin

1. Build and package the role, agent, and client extension assemblies together — Genetec's plugin tooling packages these into an installer the Genetec Server and Security Desk workstations can consume.
2. Install on the Genetec Server first, then add the plugin as a Role from Config Tool (System → Roles → Add an entity → Plugin), pointing it at the appropriate database and assigning it to a server.
3. Deploy the client extension to every Security Desk and Config Tool workstation that needs the plugin's UI — typically via the same installer used for the server component, run on each client machine or pushed through existing software distribution tooling.
4. Verify entity registration — confirm the plugin's custom entity types appear in Config Tool's entity browser and that the role reports a healthy state before rolling out to operators.
5. Test failover behavior if the Genetec Server environment is configured for role failover — a plugin role should recover its agents cleanly when Genetec Server relocates the role to a standby server.

Licensing considerations

Genetec plugins built for commercial distribution typically go through the Genetec Technology Assurance Partner Program (GTAP), which governs SDK access, certification, and how the plugin's licensing is issued. In practice this means the plugin role usually validates a license entitlement issued through Genetec's licensing system alongside the customer's Security Center license — so a plugin ships not just as software, but as a licensable, certifiable product on the Genetec platform. Building this correctly from the start avoids a re-architecture later when a customer wants a properly licensed, GTAP-certified version instead of an internal proof of concept.

Where projects usually need a specialist

The mechanics above describe the shape of a Genetec plugin; the hard parts of a real deployment are elsewhere — role failover behavior, keeping agent state consistent across thousands of entities, designing custom entity types that hold up under Security Center's permission and audit model, and GTAP certification. This is the work behind every custom Milestone XProtect plugin development and Genetec Security Center engagement we run at Xplug.in — architecture, certification, and the long-term version tracking that keeps a plugin running through years of Security Center upgrades.