Windows Events are currently split across numerous packages:

- System: Application, System, Security Events
The rational behind including Windows events in the System integration was to ensure users automatically start ingesting Application, System and Security events as soon as Agent is installed. While this is valuable, it leads to confusion as users don't realise this is the case, and end up looking in the Windows integration for these sources.

- Windows: Forwarded Events, PowerShell and Sysmon
Should we consider splitting these data streams into standalone integrations, inline with other integrations?

- Custom Windows Events - anything outside the supported events in System and Windows integrations.
This integration currently limits users to just one event channel. This results in users having to maintain several integrations for Windows events, assuming they are collecting numerous event channels.

Feedback provided directly by @nicpenning:

1. Each channel has it's own mappings and pipelines so if you need to alter any of them you have to do so in many areas
2. The custom windows event logs is causing two field conflicts for sure (event.creation, winlog.event_id)
3. The fact that there are 3 integrations to do similar things is uneasy as I don't know the parity between the system integration for System, Security, Application logs vs doing that in the Custom Windows Event Logs, or the Windows Integration that only has Powershell, Sysmon, etc..
4. Data stream inconsistencies between each of the integrations which needs to be taken into account and changed per channel (if possible)
5. I shouldn't need 3 unique integrations which is a total of 13 integrations to read the Windows event logs. They all need the same pipeline and mappings, so it should be possible to assign the 1 custom pipeline and 1 custom mapping to all Windows events. Since the custom mappings for the integrations are components I can't add to the mapping other component templates and I don't want to alter and managed mappings and pipelines as those could change over upgrades.

This issue is intended to track discussions as to how we can streamline the discoverability and usability of Windows packages for both Elastic supported events/channels and custom Windows events.