Security Server and Head-End Infrastructure

In practice, ownership is usually split, and problems come from the split being informal. IT typically owns the physical hardware, the operating system, patching, backup infrastructure, the network and the domain. Security owns the application, the cardholder data, retention requirements, alarm behaviour and who may operate the system.

The split works when it is written down. The useful step is a short document naming who patches the operating system and in what window, who holds local administrator credentials, who is notified when a disk fails, whose backup job covers the security database, and who must approve a change to firewall rules or Active Directory groups that the security system depends on.

We are frequently brought in to write that document during a server project, because we are the party talking to both groups. It costs an hour and prevents the common failure where a patch reboot happens at 3am and nobody notices the recording service did not restart.

Usually yes for the access control server, and it is increasingly the default where IT already operates a hypervisor cluster. Video recording is the part that needs care. Recording is a sustained sequential write workload that does not tolerate shared, thin-provisioned, best-effort storage, and a virtual recorder without reserved throughput will drop frames long before anyone sees a resource alarm.

The requirements that matter are reserved CPU and memory rather than overcommitted allocation, storage with guaranteed write performance, network capacity for the camera streams, and a snapshot policy that excludes the recording volumes. Snapshots on a live video volume are a common cause of stalls.

Support statements differ by software vendor and by version, and they change. We confirm the current requirement for the exact version you run before recommending a design, rather than repeating what was true a few releases ago. Where recording cannot safely be virtualized, a common arrangement is a virtual access control and management server with physical or fault-tolerant recorders.

It depends on where the video lives. If recording is on a separate storage array or on separate recorder machines, the management server can often be migrated while the recorders keep writing, and the archive is simply reattached to the new server. That is the least disruptive case and is one reason to separate recording from the management server when a platform is designed.

If video is on internal disks in the server being replaced, there are two options. The archive can be moved with the disks or the array, which preserves everything but requires a planned interruption. Or the new server can be brought up in parallel and the old one kept running read-only as an archive server for the remainder of the retention period, so historical footage stays searchable while new recording lands on the new platform.

What we do not do is start a migration without an answer to this question. Before any cutover, the plan states where existing footage will be, how it will be retrieved, and how long the site will be recording to a temporary or reduced configuration. If there is an active investigation or a legal hold, that footage is exported and verified before anything is touched.

By making the array tell someone. Most degraded arrays we find were reported correctly by the controller, to a log nobody reads and an amber light in an unattended room. The disk failed months ago, the rebuild never happened because no spare was fitted, and the array is one failure from total loss.

The configuration that prevents this is unremarkable. Enable the controller management agent and configure alert delivery by email to a monitored address, not to a console. Fit and verify a hot spare so a rebuild starts automatically instead of waiting for a person. Monitor predictive failure and reallocated sector counts rather than waiting for an outright failure. Check the cache battery state, because a failed battery changes write policy and degrades performance quietly. Keep one spare disk of the correct model on site, since matched drives are the ones that go end of life first.

On top of that, a physical and log-based check on a scheduled cycle catches what alerting misses, including the case where alerting itself stopped working after a mail server change. This is standard content in a preventive maintenance visit.

More than most people expect. Security applications commonly authenticate operators against Active Directory, run services under domain accounts, map operator privileges to AD groups, use the domain for time synchronization, and may tie workstation trust or certificates to the domain. Cardholder import from HR systems often runs on a domain service account as well.

A domain migration done without security in the room typically produces the same set of failures: services will not start because the account no longer authenticates, operators cannot log in, scheduled imports stop silently, event history keeps recording but reports break, and workstations lose their connection to the server.

The right sequence is to inventory every account, group, service and trust the security system depends on before the change, agree a window, take a full backup and a verified restore point, make the change with a technician present who can re-point services and re-map groups the same night, and then test operator login, badge activity, alarm delivery and video review before the window closes. We attend these as a planned engagement rather than reacting the following morning.

Because the failure decides the schedule. An out-of-warranty server that fails on a Friday night in a facility that cannot unlock doors manually is a different event from a planned replacement on a Tuesday morning with a tested backup and the old machine still on the rack.

The practical triggers for replacing rather than waiting are: no vendor parts availability, an operating system version that no longer receives security updates, storage at the point where rebuild times exceed the realistic window before a second failure, an application version that will not run on anything the site can still buy, or a database that has outgrown the drive layout.

If none of those apply, we will say the platform has life left in it and recommend monitoring and maintenance instead. An assessment that concludes no replacement is required is a useful result.