Monitoring ITVDesk Security Events with Windows Event Log

A recorder reconnects repeatedly after an account change. An administrator updates a security setting. A camera client is denied access. When these situations need investigation, a useful starting point is a record of what happened, when, and with which account or client.

ITVDesk Security Audit records supported security and administrative events inside the application. On Windows, administrators can also send new audit events to the Windows Application Event Log, making them available to existing event collection and monitoring tools.

This guide covers the local checks first, then explains what must be configured separately for central monitoring.

Start with Security Audit in ITVDesk

Open Settings > Security > Security Audit. Review the time, event type, camera, username, client information, result, and available details for the activity you are investigating.

Not every field is relevant to every event. A local configuration change, for example, need not have a remote client IP address. Read the event and result together rather than interpreting an empty field as an error.

Security Audit and the application's diagnostic log have different purposes. The audit helps review supported access and administrative activity; it is not a packet trace, a complete Windows activity history, or a replacement for recorder diagnostics.

Enable the Windows Event Log Copy

  1. On the Windows installation running ITVDesk, open Settings > Security > Security Audit.
  2. Select Send Security Audit events to Windows Event Log.
  3. Click the Save button for that setting.
  4. Check that ITVDesk confirms forwarding is enabled for new audit events.

Existing audit records are not copied retrospectively. The setting applies to new events after forwarding has been enabled. Turning it off stops the additional Windows copy; the local ITVDesk Security Audit remains active.

This operating-system forwarding option is supported on Windows. Do not assume that the same setting forwards events to Linux or macOS system logs.

Find the Events in Windows

  1. Open Event Viewer on the ITVDesk computer.
  2. Select Windows Logs > Application.
  3. Choose Filter Current Log... and filter the event source to ITVDesk Security.
  4. Open a recent event and inspect its message and details.

These records belong to the Application log, not the Windows Security log. The source name is important: an event ID without its source and log can refer to an unrelated event elsewhere in Windows.

Messages include an audit timestamp identified as TimestampUtc. Event Viewer may display its time column using local time, so account for the time zone when comparing records with VMS footage or another system.

Understand the Event IDs

Use the following IDs together with the ITVDesk Security source. Then read the event type, result, and details to understand the individual record.

  • 1100: successful login events.
  • 1101: unsuccessful login events.
  • 1110: account lockout and rate-limit events.
  • 1120: authorization events, including access-denial records.
  • 1130: supported client connection events.
  • 1199: other supported security, administrative, and lifecycle events. Inspect the event type and result rather than treating every 1199 record as an error.

Supported audit activity includes authentication, access decisions, application and Broker startup/shutdown, and supported configuration changes. It does not mean every action in Windows or every VMS operation is recorded by ITVDesk.

An audit-storage failure can also appear under ID 1199, with Event=AuditStorage, Result=Error, and Error severity. Such a record deserves investigation of local audit storage; it does not by itself establish that central collection is working.

Verify a New Event Before Adding a Collector

Start with a pilot computer. Saving the enabled forwarding policy records that administrative change and provides a useful first event to look for. You can also use an authorized sign-in or another supported, controlled action to confirm a fresh record appears.

Match the time, event type, and result between ITVDesk and Event Viewer. Do not deliberately lock out a production recorder account to test the feature. If failed-login testing is required, use a designated test account and a planned test window.

For administrators who prefer PowerShell, this read-only query shows up to 50 matching events from the previous day:

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    ProviderName = 'ITVDesk Security'
    StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

An empty result needs context: the setting may be disabled, there may be no matching new events in the selected period, or Windows logging may need investigation. Compare with the local audit before drawing a conclusion.

Connect the Windows Log to Central Monitoring

Once local delivery is confirmed, the Windows administrator can configure Windows Event Forwarding (WEF) to collect the relevant Application log records on a Windows Event Collector. Microsoft describes WEF as forwarding selected events from devices to a collector; subscriptions and collector configuration determine what is collected. See Microsoft's Windows Event Collector documentation.

Scope the collection to the intended computers and the ITVDesk Security source. Configure permissions, connectivity, collection policy, and retention according to the environment. If a monitoring or SIEM agent already collects Windows events, confirm that its policy includes these records.

Enabling the option in ITVDesk does not configure WEF, a collector, or SIEM alert rules. Generate another controlled event after collection is configured and verify it arrives at the central destination with its source computer and event details intact.

The local Windows copy is an additional destination, not a guarantee of end-to-end delivery. Monitor the collector and forwarding health separately. No entries on a central dashboard do not necessarily mean that no security activity occurred.

Choose Alerts That Someone Can Act On

A sensible starting point is repeated failed access, unexpected administrative changes, and audit-storage errors. Consider the workstation's role and normal client behavior before turning those patterns into alerts.

For example, failed logins immediately after a planned password change may indicate that a recorder still holds the previous password. Investigate that context before assuming hostile activity. Likewise, a startup event can be expected during maintenance but unexpected at another time.

Decide who reviews alerts, how records are retained, and who may export them. Audit records can contain usernames and network addresses, so restrict access and redact identifying information before sharing samples outside the organization.

When an Expected Record Is Missing

Check the simplest causes first: the correct Windows computer, the Application log, the ITVDesk Security source, the selected time period, and whether the action occurred after forwarding was enabled and saved.

If the event exists locally in Windows but not centrally, investigate the collection path and subscription filters. If it appears in ITVDesk but not in the Windows log, check the forwarding setting, installation, Windows logging availability, and relevant policy restrictions.

Keep evidence of the test action and its time. A missing secondary copy should be investigated without assuming that authentication failed or that the video stream stopped.

Keep the Audit in Context

Security records are most useful alongside the deployment configuration and relevant VMS/NVR records. They support investigation and operational review; collecting them alone does not establish compliance with a security framework.

For the broader configuration checklist, see ITVDesk Security Hardening Checklist. Recent changes are listed in the Security Changelog.