Migrating the Windows Event Log Ingestion Method from DataSource to LogSource

Windows Event Logs help you monitor system activity, application behavior, and security events across your environment. Many existing configurations use the legacy Windows Events DataSource to ingest logs. As logging requirements grow, managing event channels, filters, and resource-specific configurations through DataSource properties can become increasingly complex.

LogSource-based ingestion is the recommended method for collecting Windows Event Logs in LogicMonitor. LogSources centralize configuration in the LogicMonitor portal, support collector-side filtering and resource mapping, reduce dependency on resource properties, and generally require fewer system resources than legacy DataSource-based ingestion.

This article explains migrating Windows Event Log ingestion from the legacy Windows Events DataSource to a Windows Event Logging LogSource. This workflow helps you modernize log collection while maintaining visibility, minimizing migration risk, and preserving rollback options throughout the migration process.

Migrating the Windows Event Log ingestion method involves the following steps:

1. Use pre-built LM LogSource or create new as needed for parity.
2. Run both collection methods in parallel and validating results
3. Decommission the legacy DataSource
4. Update resource properties
5. Perform an audit

Requirements for Migrating Windows Event Log Ingestion from DataSource to LogSource

To migrate Windows Event Log ingestion from a DataSource to a LogSource, you need the following:

• A supported LogicMonitor Collector version for LogSource ingestion. Using a LogSource with an LM Collector requires EA Collector 31.200 or later.
• Existing Windows resources in the Resources tree that are currently collecting Windows Event Logs.
• An inventory of the Windows Event Log channels currently collected by the legacy DataSource. This inventory provides a baseline for validating the new LogSource configuration.
• Windows Management Instrumentation (WMI) access for the Collector service account or configured wmi.user and wmi.pass credentials.
• Windows Remote Management (WinRM) enabled for environments that use remote Windows event collection.
• Security log permissions, such as SeSecurityPrivilege, to collect Security event logs.
• An inventory of resource properties related to the legacy DataSource properties currently used for Windows Event Log collection, including:
  • lmaccess.id
  • lmaccess.key
  • lmlogs.winevent.channels
  • lmlogs.winevent.eventtypes
  • lmlogs.winevent.eventids.exclude
  • lmlogs.winevent.message_strings.exclude
  • lmlogs.winevent.detailed_message
• An export of the existing Windows Event Logs DataSource configuration and a snapshot of the associated resource properties before making any changes.

Creating the Windows Event Logging LogSource

Creating a LogSource is the first step in migrating log ingestion. This ensures the new collection method to begin ingesting logs while the legacy DataSource remains active for validation purposes.

1. In LogicMonitor, navigate to Settings > LogicModules.
2. Do one of the following:
   • Use ExchangeModule_Logsource_Windows logsource from My Module Toolbox. If not available in My Module Toolbox, install it from Exchange.
   • Create a new LogSource using the Windows Event Logging template.
     For more information, see Windows Event Logging LogSource Configuration.
     
3. Configure the AppliesTo logic to target the appropriate resources.
4. Ensure that the LogSource matches the legacy DataSource behavior by completing the following:
   • Include the same Event Log channels such as System, Application, and Security.
   • Create additional LogSources if required to collect other logs such as DFS Replication or Directory Service.
   • Replicate the legacy DataSource filtering behavior using LogSource Include Filters and Exclude Filters. Configure filters to preserve the original collection scope and ingestion volume.
   • Verify that Collector permissions and access match the previous configuration.

Running the LogSource in Parallel to Validate Collection

Before decommissioning the legacy DataSource, run both collection methods in parallel and validate the new LogSource configuration.

Continue collecting logs through both methods for at least 24 to 48 hours.

The following list describes the validation criteria:

• Logs are arriving from all expected Windows resources.
• Expected Event Log channels are represented.
• Security logs are being collected where applicable.
• Expected Event IDs are present.
• Existing include and exclude filters behave as expected.
• Resource mappings associate logs with the correct resources.
• No unexpected exclusions or collection gaps are observed.
• Overall event volume is comparable to the legacy DataSource.

Use the following query to evaluate LogSource volume:

* | count by _lm.logsource_name | sort by _count desc

During this period, there should not be any discrepancy in volume ingested through DataSource and LogSource.

If you encounter missing logs, resource mapping issues, or unexpected ingestion behavior during validation, review the common troubleshooting steps before proceeding with decommissioning.

For more information, see Troubleshooting Windows Event Logs Ingestion.

Decommissioning the DataSource

After successful validation, decommission the legacy DataSource.

1. Open the legacy Windows Event Logs DataSource in the LogicMonitor portal.
2. In the AppliesTo field, comment out the existing logic.
   For example: /*isWindows() && lmlogs.winevent.channels && lmaccess.id && lmaccess.key*/
   
3. Add a decommissioning comment.
   For example: /* Deprecated in favor of WindowsEventLogs LogSource as of YYYY-MM-DD */
4. Select Save.
   After completing this process, the DataSource remains available for rollback or audit purposes.

Updating Resource Properties

Updating resource properties removes dependencies on legacy log harvesting configurations and ensures a clean transition to the LogSource-based approach.

Note: Before removing any properties, verify that you have documented the existing DataSource configuration and exported the Windows Event Logs DataSource.

After the LogSource has been validated and the legacy DataSource has been decommissioned, remove the following properties from resources or resource groups:

• lmlogs.winevent.channels
• lmlogs.winevent.eventtypes
• lmlogs.winevent.eventids.exclude
• lmlogs.winevent.message_strings.exclude
• lmlogs.winevent.detailed_message

Performing an Audit

Performing an audit verifies that the migration is successful and that log ingestion continues as expected.

1. Enable the LogSource to ingest logs for 24 to 48 hours.
2. In the Logs interface, run the following query to evaluate log volume:

* | count by _lm.logsource_name | sort by _count desc

3. Compare log volume and distribution between the legacy DataSource and the new LogSource across all relevant resources.
4. Monitor Collector performance to confirm there are no unexpected issues.
5. Archive the DataSource configuration (XML or JSON) for reference.
6. Notify stakeholders, such as security or compliance teams, that the migration is complete.

If rollback is required, re-enable the AppliesTo logic on the legacy DataSource and restore any required resource properties.

This ensures a controlled migration with continuous visibility and minimal disruption.