Windows security was onboarded as the custom sourcetype city_winsec instead of WinEventLog:Security. Security Essentials content keyed on the standard name shows nothing. Why?
Select an answer to reveal the explanation.
Short Explanation
SSE looks for the nametag it was taught—WinEventLog:Security—not whatever nickname the city invented. city_winsec is invisible until someone aliases or CIM-tags it. Rename the mailbox, miss the mail.
Full Explanation
Windows security onboarded as the custom sourcetype city_winsec instead of WinEventLog:Security will not appear in Security Essentials content keyed on the standard name until the sourcetype is mapped or tagged to expected CIM models. Content discovery depends on expected sourcetype names or CIM tags; renaming without mapping makes otherwise good civic telemetry invisible to packaged detections and dashboards.
Claiming Security Essentials cannot list Windows content unless the city buys ITSI invents a product dependency that is not required for Essentials content listing. Claiming custom sourcetype names automatically inherit every standard Security Essentials mapping is false—inheritance requires explicit tags, eventtypes, or aliases. Claiming city_winsec events sit in a hidden index that Enterprise Security cannot search is unsupported when raw search can already see those events.
Exam caveat: renamed sourcetypes need CIM tags or aliases to unlock standard content discovery in Security Essentials and Enterprise Security.
Operational check: apply authentication eventtypes and CIM tags to city_winsec via props and transforms or a technical add-on, verify Security Essentials lists Windows detections, and test a failed-logon correlation against the renamed sourcetype.