Skip to main content

Windows Tracking Policy (App Blocking Tracking)

Updated today

The Windows Tracking Policy in Swif.ai enables organizations to collect important security, compliance, and operational event data from Windows devices. In addition to USB, lock/unlock, and location tracking, this policy can also be used together with Windows Application Block controls (via AppLocker) to track when users attempt to open blocked applications.

This policy supports both BYOD and company‑owned Windows devices running Windows 10 or later (note: some capabilities may be restricted on BYOD devices).

For the base tracking behavior (USB, lock/unlock, and location), see:

What This Policy Does for App Blocking

When used together with Windows AppLocker‑based blocking, the Windows Tracking Policy allows Swif.ai to collect additional data related to application blocking:

Blocked app open attempts (agent callback via AppLocker events)

When a user tries to launch an application that has been blocked by your Windows application control configuration (e.g., AppLocker):

  • Windows logs an AppLocker event stating the app was prevented from running (for example, MICROSOFT.WINDOWSSTORE was prevented from running. with event ID 8022 in Microsoft-Windows-AppLocker/Packaged app-Execution).

  • The Swif Windows agent:

    • Monitors these AppLocker logs.

    • Detects new “blocked app” events.

    • De‑duplicates events using a local cache of seen IDs.

    • Sends an “applicationBlock” tracking event back to Swif with:

      • Policy ID

      • Tracking type: APPLICATION_BLOCK_TRACKING

      • Tracked time

      • Application name (e.g., MICROSOFT.WINDOWSSTORE)

      • Time the app was blocked (killed/prevented from running).

This provides near real‑time visibility into attempted policy violations and user behavior on Windows.

Example internal behavior (for reference)

  • The agent maintains an appblock_seen_ids cache (XML or structured store) with values like 2026-01-17T05:59:55|8022.

  • For any new AppLocker event ID/time pair that hasn’t been seen, it sends a gRPC callback ApplicationBlockTrackingServiceResponse to the Swif server.

  • The server then publishes an MDM_API_EVENT_TRACKING event of type applicationBlock into Swif’s event pipeline.

How App Blocking & Tracking Works on Windows

On Windows, Swif leverages the existing Windows AppLocker mechanism combined with the Swif agent and tracking pipeline:

App blocking enforcement (via AppLocker)

  • You configure application block rules on Windows (e.g., to block Microsoft Store or specific EXEs/packages).

  • When a user attempts to run a blocked app, Windows itself prevents the execution and writes an AppLocker error event (such as Event ID 8022, “<APPNAME> was prevented from running”).

Swif agent tracking callback

  • The Swif agent continuously watches the AppLocker event logs, e.g.:

    • Microsoft-Windows-AppLocker/Packaged app-Execution

  • For each new event that indicates a blocked app:

    • The agent parses the log (time, event ID, application name, message).

    • It checks a local “seen IDs” cache to avoid duplicate reporting.

    • It sends a structured tracking callback with:

      • typeTrackingType = APPLICATION_BLOCK_TRACKING

      • eventType = applicationBlock

      • data.appName = <blocked app name>

      • data.killedAt = <time Windows prevented the app>

Server‑side processing & reporting

  • The Swif Windows server receives the callback over gRPC and routes it into the Swif tracking pipeline.

  • An MDM_API_EVENT_TRACKING message is produced, tagged with:

    • Team ID

    • Device ID

    • Policy ID

    • Metadata (tracking type, trackedAt, appName, killedAt)

    • Event type: applicationBlock

    • Source: hardwareAgent

  • These become visible in Event Logs and related reports in Swif.ai.

Note
Unlike Linux, the Windows implementation is focused on capturing attempted runs of blocked apps via the AppLocker log callback. The documentation here is limited to the tracking/visibility aspect, not the detailed configuration of Windows AppLocker rules themselves.

Requirements

  • OS: Windows 10+

  • Swif agent: Latest Windows agent installed and running on the device.

  • Policies required:

    • A Windows Tracking Policy applied to the device or device group.

    • Windows application control rules (e.g., AppLocker) configured to block the desired applications.

Base Windows Tracking Policy reference:

Policy Settings (App Blocking–Related)

In addition to USB Tracking, Device Lock Tracking, and Location Tracking, the Windows Tracking Policy / tracking system supports application block tracking events when combined with Windows AppLocker.

Field Name

Description

Value Options

Events Report

Minimum OS Requirement

Application Block Tracking (Windows)

Controls whether Swif logs tracking events related to blocked applications on Windows devices by reading AppLocker logs and sending structured callbacks to Swif. This includes when a blocked app is prevented from running by AppLocker.

True – Enables tracking of “blocked app attempt” events reported via the Swif agent and server pipeline.

False – No app blocking tracking events are collected by Swif (even though AppLocker may still block the app locally).

View reports at Device Management → Event Logs and relevant security/endpoint reports

Windows 10+

Behavior when enabled (true)

  • Agent‑side event:

    • Whenever Windows AppLocker prevents a blocked app from running and writes a log entry, the Swif agent:

      • Detects the event.

      • Records its unique ID and timestamp in the local appblock_seen_ids cache.

      • Sends an applicationBlock tracking event to Swif with the app name and time blocked.

  • Server‑side processing:

    • Swif’s Windows server consumes the callback and pushes an MDM_API_EVENT_TRACKING record into the event pipeline.

    • Events are then visible in:

      • Device Management → Event Logs

      • Browser & Device Event Logs

      • Security Center (if enabled)

      • Automations and alerts (if configured).

Behavior when disabled (false)

  • Windows AppLocker may still block the application according to your local Windows policies.

  • However:

    • The Swif agent does not send application block tracking callbacks.

    • No applicationBlock events are surfaced in Swif’s Event Logs.

  • You effectively get enforcement only (from Windows), without centralized visibility in Swif.

Where to View App Blocking Tracking Events

Once Windows Tracking and AppLocker‑based blocking are in place (and app block tracking is enabled):

  • Navigate to Device Management → Event Logs → Device Events in Swif.ai.

  • You will see events such as:

  • Blocked application attempted / applicationBlock

    • Indicates that a user tried to run an application that is blocked by your Windows policy, and Windows prevented it from running.

    • The Swif event will include:

      • Device

      • Application name (e.g., MICROSOFT.WINDOWSSTORE)

      • Time blocked

      • Associated policy/device identifiers.

You can filter these events by:

  • Device

  • Application name

  • Event type (applicationBlock)

  • Time range

This gives Security and IT teams a centralized view of attempted use of blocked software on Windows devices.

Example Use Cases

✔ Enforce high‑risk software bans
Block tools like remote access utilities, unapproved communication apps, or the Microsoft Store and record every time users try to open them.

✔ Investigate suspicious behavior
Combine application block attempt data with USB and lock/unlock events to understand patterns like:

  • A user repeatedly trying to run a blocked remote access tool.

  • Attempts coinciding with unusual USB usage.

✔ Compliance & audit evidence
Demonstrate that high‑risk Windows applications are both blocked and monitored, supporting:

  • SOC 2

  • ISO 27001

  • HIPAA

  • Internal security controls

✔ Policy tuning & visibility
See which blocked apps generate the most attempts and where enforcement friction is highest, then adjust your application control policies accordingly.

How to Configure App Blocking Tracking on Windows

1. Configure Windows AppLocker (or equivalent)

On your Windows devices (via Group Policy, Intune, etc.):

  1. Define AppLocker rules to block specific apps or package families (for example, block Microsoft Store).

  2. Ensure auditing/logging is enabled so that blocked attempts generate events in:

    • Microsoft-Windows-AppLocker/Packaged app-Execution

    • Or other relevant AppLocker logs depending on the rule type.

Example (as used in internal testing)


When Microsoft Store is blocked, AppLocker logs entries like:

  • Event ID: 8022

  • Message: MICROSOFT.WINDOWSSTORE was prevented from running.

Swif’s agent relies on these log events to generate tracking callbacks.

2. Apply a Windows Tracking Policy

  1. In Swif.ai, go to Policies → Windows → Tracking Policy.

  2. Ensure that a tracking policy is created and assigned to your target Windows device or group.

  3. Enable Application Block Tracking for Windows.

  4. Optionally configure:

    • USB Tracking

    • Device Lock Tracking

    • Location Tracking

Policy reference:

3. Verify on a Test Device

On a Windows device that has:

  • The Swif agent installed and running.

  • The Windows Tracking Policy applied.

  • AppLocker rules blocking at least one application.

Perform the following:

  1. Attempt to open a blocked application (e.g., Microsoft Store if blocked).

  2. Confirm on the device:

    • Windows prevents the application from running (AppLocker popup or silent failure depending on your configuration).

  3. Confirm in Swif.ai:

    • Navigate to Reports → Event Logs → Device Events.

    • Filter by the test device and recent time range.

    • Verify an applicationBlock / “blocked application attempted” event showing the app name and time.

Verification & Troubleshooting

If app blocking tracking events are not appearing in Swif:

  1. Confirm policies are assigned

    • Verify that a Windows Tracking Policy is applied to the device.

    • Ensure any “Application Block Tracking” flag/field (if present) is enabled.

  2. Validate Windows app blocking configuration

    • Confirm your AppLocker rules are correctly configured and deployed.

    • On the device, manually check the relevant event log with PowerShell or Event Viewer.

      • Example PowerShell pattern used during development:

        • Get-WinEvent -LogName "Microsoft-Windows-AppLocker/Packaged app-Execution" -MaxEvents 1

      • Confirm events like MICROSOFT.WINDOWSSTORE was prevented from running. (ID 8022) appear when you attempt to open the blocked app.

  3. Check the Swif Windows agent

    • Ensure the latest Swif Windows agent is installed and running.

    • If needed, reinstall or restart the agent.

    • Optionally restart the device.

  4. Check Event Logs filters in Swif

    • In Reports → Event Logs → Device Events:

      • Clear filters for device, event type, and time range.

      • Re‑filter by device and recent time range to ensure events are not hidden.

  5. Avoid duplicates

    • The agent maintains a cache of seen event IDs (appblock_seen_ids).

    • If you expect a new event and do not see it:

      • Confirm that a new log entry was generated (new RecordId/time).

      • Ensure your test is genuinely generating fresh AppLocker events (not just re‑opening the Event Viewer).

Best Practices

  • Pair Windows Tracking with AppLocker
    Use Windows Tracking Policy together with well‑defined Windows AppLocker rules to gain both enforcement (apps are blocked) and centralized observability (attempts are logged in Swif).

  • Start with a pilot
    Pilot blocked applications on a small group of devices first, monitor applicationBlock events, then gradually roll out broadly.

  • Monitor trends
    Use Event Logs to identify:

    • Which blocked apps are most frequently attempted.

    • Which devices or users repeatedly try to run blocked tools.

  • Automate alerts & workflows
    Use Swif automations or external integrations to:

    • Notify Security when a high‑risk blocked app is attempted.

    • Open tickets when repeated attempts occur from the same device or user.

  • Review regularly
    Periodically review:

    • Your Windows app blocking rules (AppLocker).

    • The volume and distribution of applicationBlock events.
      to keep controls aligned with evolving risks and business requirements.

Related Articles
Windows AppLocker Policy (Application Block)
Windows Tracking Policy
Linux Tracking Policy
Linux Tracking Policy (App Blocking Tracking)
Apple Tracking Policy (App Blocking Tracking)
Did this answer your question?