Sentinel

391
Total Pages
285
Linux-Friendly Pages
106
Pages with Bias
27.1%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues

488 issues found
Showing 126-150 of 488 flagged pages
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/sample-workspace-designs.md ...lob/main/articles/sentinel/sample-workspace-designs.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by consistently listing 'Windows Security Events' and 'Windows Events' as primary log sources, referencing Windows-specific tools like the Azure Monitoring Agent (AMA) for Windows VM log collection, and omitting explicit Linux log collection examples or Linux agent instructions. Syslog and CEF are mentioned, but only generically and without parity in example detail or tooling. There are no Linux-specific collection patterns, nor are Linux VMs or their security events discussed with the same specificity as Windows.
Recommendations
  • Include explicit examples and instructions for collecting security and performance events from Linux VMs, such as using AMA or legacy agents for Linux.
  • Provide parity in log source lists by mentioning Linux equivalents (e.g., Linux audit logs, /var/log/syslog, /var/log/auth.log) alongside Windows events.
  • Add details on configuring diagnostic settings and workspace routing for Linux VMs and containers.
  • Reference Linux-specific documentation and tools (e.g., OMS Agent for Linux, AMA for Linux, syslog configuration) where Windows tools are mentioned.
  • Ensure that diagrams and solution summaries show both Windows and Linux VM log flows, and clarify any differences in agent deployment or data collection.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/best-practices-data.md ...ocs/blob/main/articles/sentinel/best-practices-data.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several ways: Windows-specific tools (Windows Event Forwarding, PowerShell) are mentioned more frequently and sometimes before Linux equivalents; examples and solutions for Windows are more detailed and numerous; some sections (e.g., endpoint solutions, cloud platform data) list Windows methods without Linux alternatives; PowerShell is suggested for custom log collection, but no Linux shell or scripting example is given; and Windows terminology and tools are referenced more often than Linux ones.
Recommendations
  • Ensure that for every Windows-specific tool or method (e.g., Windows Event Forwarding, PowerShell), an equivalent Linux solution (e.g., Syslog forwarding, Bash scripting) is provided and described.
  • Present Linux and Windows solutions in parallel, rather than listing Windows options first or exclusively.
  • Add Linux-specific examples for custom log collection, such as using Bash, Python, or other common Linux scripting tools.
  • Include Linux endpoint solutions (e.g., auditd, sysmon for Linux, EDR connectors for Linux) where only Windows endpoint solutions are mentioned.
  • Review all tables and solution lists to ensure Linux parity in detail and coverage.
  • Avoid using Windows terminology as the default; clarify when a solution is platform-specific.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/billing-reduce-costs.md ...cs/blob/main/articles/sentinel/billing-reduce-costs.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias primarily in the 'Use data collection rules for your Windows Security Events' section, which exclusively discusses Windows Server and the Windows Security Events connector. There are no equivalent examples or guidance for Linux systems, nor mention of Linux data connectors or event collection. The focus on Windows tools and connectors, without Linux parity, may lead Linux users to feel unsupported or unclear about cost optimization strategies for their environments.
Recommendations
  • Add a section detailing cost optimization for Linux-based event collection, including connectors such as the Syslog connector or the Linux agent.
  • Provide examples and guidance for configuring data collection rules for Linux systems, similar to the Windows Security Events connector coverage.
  • Mention Linux-specific considerations for data ingestion, retention, and workspace separation, ensuring parity with Windows-focused advice.
  • Ensure that any references to data collection or agent configuration include both Windows and Linux platforms, or clarify platform-specific limitations.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-aws.md .../azure-docs/blob/main/articles/sentinel/connect-aws.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation demonstrates a Windows bias by recommending PowerShell as the primary automation tool for connector setup, requiring PowerShell installation for the automatic setup, and providing instructions that assume the use of PowerShell and Windows environments. There are no equivalent instructions or examples for Linux shell environments (e.g., Bash), nor is there mention of Linux-native tools or setup scripts. The documentation also lists PowerShell before the AWS CLI in prerequisites and does not provide parity for Linux users.
Recommendations
  • Provide Bash shell examples and instructions for Linux and macOS users alongside PowerShell instructions.
  • Offer a cross-platform setup script (e.g., Python or shell script) that works natively on Linux, macOS, and Windows.
  • Explicitly mention Linux and macOS as supported platforms for the connector setup, and clarify any platform-specific requirements.
  • List installation instructions for both PowerShell and Bash (or other relevant shells) in the prerequisites.
  • If the automation script is PowerShell-only, consider developing and linking to a Bash or Python equivalent for Linux users.
  • Add troubleshooting notes for common Linux-specific issues (e.g., permissions, environment variables, CLI differences).
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-custom-logs-ama.md ...blob/main/articles/sentinel/connect-custom-logs-ama.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page generally aims for cross-platform coverage, but there are several signs of Windows bias. Windows tools and patterns (e.g., PowerShell) are mentioned first or exclusively in some installation instructions. The portal-based setup instructions use screenshots and UI flows that are more familiar to Windows users, and PowerShell is referenced before Azure CLI (which is more common on Linux). There is a lack of explicit Linux command-line examples for installing the Azure Monitor Agent, and the ARM template instructions do not provide Linux-specific file path examples. While Linux log forwarder setup is covered, the overall flow and examples tend to prioritize Windows approaches or omit Linux parity in some areas.
Recommendations
  • Provide explicit Linux command-line examples for installing the Azure Monitor Agent, such as using apt, yum, or direct shell commands.
  • When listing installation methods, mention Azure CLI before or alongside PowerShell, and clarify which is preferred for Linux users.
  • Include Linux-specific file path examples (e.g., /var/log/app.log) in ARM template documentation.
  • Add screenshots or instructions for Linux environments (e.g., SSH terminal setup, Linux VM resource selection).
  • Ensure that all steps and prerequisites have parallel instructions for both Windows and Linux, with equal detail and prominence.
  • Highlight differences in agent installation and configuration between Windows and Linux, including troubleshooting tips for each platform.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/cef-name-mapping.md ...e-docs/blob/main/articles/sentinel/cef-name-mapping.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Windows Terms Windows Examples
Summary
The documentation page exhibits mild Windows bias. Several field descriptions and examples reference Windows-specific concepts (e.g., 'Windows domain', 'C:\ProgramFiles\WindowsNT\Accessories\wordpad.exe'), and Windows terminology (such as 'NTDomain') is used for certain fields. In file path examples, Windows paths are listed before Linux equivalents. There is no exclusive use of Windows tools or PowerShell, but Windows is often mentioned first or more prominently than Linux/UNIX.
Recommendations
  • Ensure parity in examples by alternating or balancing Windows and Linux/UNIX references (e.g., list '/usr/bin/zip' before or alongside 'C:\ProgramFiles\WindowsNT\Accessories\wordpad.exe').
  • For fields like 'NTDomain', clarify applicability to non-Windows environments or provide equivalent Linux/UNIX concepts if relevant.
  • Where Windows-specific terms are used, add notes or examples for Linux/UNIX systems to avoid implying exclusivity.
  • Review field descriptions to ensure that references to Windows domains, processes, and file paths do not overshadow Linux/UNIX equivalents.
  • Consider including a general statement at the beginning noting that examples and terminology cover both Windows and Linux/UNIX environments.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-azure-functions-template.md .../articles/sentinel/connect-azure-functions-template.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by prioritizing PowerShell-based deployment instructions, referencing Windows-specific tools and patterns (such as PowerShell and workspace keys linked to Windows agent documentation), and omitting explicit Linux shell or cross-platform CLI examples. The Python deployment section requires Visual Studio Code, which is cross-platform but is presented after PowerShell and ARM template options. There are no Bash, Azure CLI, or Linux-native instructions, and the manual deployment with PowerShell is given before Python, reinforcing a Windows-first approach.
Recommendations
  • Add explicit Linux shell (Bash) or Azure CLI instructions for manual deployment, especially for users who do not use PowerShell.
  • Clarify that both PowerShell and Python options are cross-platform, and provide guidance for Linux/macOS environments (e.g., using Azure CLI, Bash, or VS Code on Linux).
  • Reference Linux agent documentation alongside Windows agent documentation when discussing workspace keys and permissions.
  • Present deployment options in a neutral order (e.g., ARM template, Python, PowerShell) or clarify that all options are available regardless of platform.
  • Include troubleshooting and validation steps for Linux environments, not just Windows.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-cef-syslog-ama.md .../blob/main/articles/sentinel/connect-cef-syslog-ama.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Powershell Heavy
Summary
The documentation page is generally Linux-focused, as it describes ingesting syslog and CEF messages from Linux machines and network devices into Microsoft Sentinel. However, there is evidence of Windows bias in several areas: PowerShell is mentioned as a method for installing the Azure Monitor Agent before Azure CLI, and Windows tools (PowerShell) are referenced in the installation instructions, even though the context is Linux. Additionally, the documentation sometimes references Azure portal workflows and tools that are more familiar to Windows administrators, and the order of presenting PowerShell before CLI may reinforce a Windows-first perspective.
Recommendations
  • When listing installation methods for the Azure Monitor Agent, present Azure CLI before PowerShell, or explicitly state that PowerShell is for Windows and CLI is for Linux.
  • Remove or clarify references to PowerShell in Linux-focused instructions, ensuring Linux-native tools (bash, CLI) are prioritized.
  • Add explicit Linux command-line examples where only generic or Windows-centric instructions are given.
  • Ensure that any screenshots or UI references do not assume a Windows environment or familiarity with Windows tools.
  • Where both Windows and Linux options exist, always present Linux options first in Linux-focused documentation.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-dns-ama.md ...re-docs/blob/main/articles/sentinel/connect-dns-ama.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation is heavily focused on Windows DNS servers, with all examples, prerequisites, and instructions tailored exclusively to Windows environments. There are no references to Linux DNS servers (such as BIND or Unbound), nor are there examples or guidance for configuring the AMA connector with Linux-based DNS logs. Windows tools and patterns (such as enabling Windows DNS analytical logs and using Windows-specific event fields) are mentioned exclusively and before any cross-platform considerations.
Recommendations
  • Add explicit support and examples for ingesting and filtering DNS logs from Linux-based DNS servers (e.g., BIND, Unbound) using the AMA connector or equivalent.
  • Include Linux prerequisites and setup steps, such as enabling DNS logging on popular Linux DNS servers and configuring the AMA agent on Linux hosts.
  • Provide API and portal configuration examples for Linux DNS sources, including sample data collection rules and filtering patterns relevant to Linux DNS logs.
  • Reference Linux tools and log formats (e.g., /var/log/named/query.log for BIND) alongside Windows equivalents.
  • Clarify in the introduction and prerequisites whether Linux DNS servers are supported, and if not, provide guidance or links to alternative solutions for Linux environments.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/create-analytics-rule-from-template.md ...ticles/sentinel/create-analytics-rule-from-template.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a bias toward Windows environments by exclusively mentioning PowerShell as the automation tool for pushing rules, without referencing Linux-native alternatives (such as Bash, CLI, or SDK usage on Linux). There are no examples or instructions for Linux users, nor is there mention of cross-platform command-line approaches. The focus on PowerShell and lack of Linux-specific guidance may hinder parity for users operating outside Windows.
Recommendations
  • Include examples for pushing rules using Azure CLI or REST API from Linux/macOS environments.
  • Explicitly mention that the REST API can be used from any platform, and provide sample curl or Python requests.
  • Add guidance or links for Linux users on installing and using cross-platform tools to manage Sentinel rules.
  • Clarify that PowerShell is available on Linux, but also provide alternative approaches for users who prefer native Linux tools.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/connect-microsoft-purview.md ...ob/main/articles/sentinel/connect-microsoft-purview.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Missing Linux Example Windows First
Summary
The documentation page demonstrates a bias toward Windows environments by exclusively referencing Microsoft-centric tools and workflows (Azure portal, Office Management API, Microsoft Sentinel, Kusto Query Language) without mentioning Linux equivalents or cross-platform alternatives. All setup and operational instructions assume use of Microsoft portals and services, which are primarily accessed from Windows environments. There are no examples or guidance for Linux users, such as using CLI tools, REST APIs, or automation scripts that could be run on Linux systems.
Recommendations
  • Provide instructions for accessing and configuring the connector using cross-platform tools such as Azure CLI or PowerShell Core (which runs on Linux and macOS).
  • Include examples of how to interact with the Office Management API using curl or other Linux-native tools.
  • Mention and demonstrate how Kusto queries can be executed from Linux environments, e.g., using the Kusto CLI or SDKs available for Linux.
  • Clarify which steps (such as portal access) can be performed from any OS via a web browser, and which are Windows-specific.
  • Add troubleshooting or operational notes for Linux users, such as log locations, environment variables, or authentication methods relevant to non-Windows platforms.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/create-analytics-rules.md .../blob/main/articles/sentinel/create-analytics-rules.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Powershell Heavy 🔧 Windows Tools
Summary
The documentation demonstrates a moderate Windows bias. While the main focus is on the Microsoft Sentinel UI (in both Azure and Defender portals), the only command-line automation examples referenced are via PowerShell, and the only automation tooling mentioned by name is PowerShell. There is no mention of Linux-native tools or CLI equivalents (such as Azure CLI or Bash scripting). Additionally, when discussing automation, PowerShell is listed before API, and there are no Linux-specific instructions or examples.
Recommendations
  • Include automation examples using Azure CLI (az sentinel ...) alongside or before PowerShell, to provide parity for Linux and cross-platform users.
  • Mention and provide examples for using REST API with curl or other cross-platform tools, not just PowerShell.
  • Avoid listing PowerShell before API or CLI in automation sections; consider a neutral or Linux-first order.
  • Explicitly state that all automation steps can be performed from Linux/macOS as well as Windows, and provide any necessary prerequisites or differences.
  • If possible, add a section or callout for Linux users, highlighting any differences or confirming full support.
  • Where scripts or code are referenced, provide both PowerShell and Bash/Azure CLI equivalents.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/data-source-schema-reference.md ...main/articles/sentinel/data-source-schema-reference.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page predominantly lists Azure and Microsoft-centric data sources and schemas, with a strong emphasis on Windows-native tools (e.g., IIS Logs, OfficeActivity, Azure Key Vault). While Linux Syslog is mentioned, it appears as a single entry among many Windows/Office/Azure sources, and there are no Linux-specific schema references beyond Syslog. Windows tools and schemas are listed first and in greater detail, with no parity for Linux equivalents (e.g., no mention of Linux audit logs, journald, or other host logs). Examples and references for Linux are minimal, and there is no guidance or links for Linux-specific log integration beyond Syslog.
Recommendations
  • Add more Linux-specific data source schema references, such as auditd, journald, or other common Linux host logs.
  • Provide parity in documentation for Linux tools and patterns, including example integrations and schema references.
  • Ensure Linux examples are given equal prominence and detail as Windows/Azure/Office sources.
  • Include links to Linux log documentation and integration guides, not just Syslog.
  • Consider adding a section or table dedicated to Linux host and network log schemas to balance the Windows/Azure focus.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/datalake/notebook-examples.md ...b/main/articles/sentinel/datalake/notebook-examples.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a bias toward Windows environments by specifying Visual Studio Code (VS Code) and the Microsoft Sentinel extension as prerequisites, without mentioning Linux alternatives or cross-platform compatibility. There are no references to running the notebooks on Linux or macOS, nor any mention of Linux-specific tools, patterns, or installation instructions. The examples and screenshots implicitly assume a Windows-centric workflow, and there is no guidance for users who may prefer or require Linux-based setups.
Recommendations
  • Explicitly state that Jupyter notebooks and the Microsoft Sentinel extension are cross-platform, and provide installation instructions for Linux and macOS.
  • Include examples or screenshots showing notebook usage on Linux (e.g., Ubuntu) and/or macOS.
  • Mention alternative editors (such as JupyterLab or classic Jupyter Notebook) and clarify whether the Sentinel extension is available or required on non-Windows platforms.
  • Add troubleshooting or environment setup notes for Linux users, including package dependencies and Spark installation guidance.
  • Avoid language that implies Windows is the default or only supported platform; use neutral phrasing such as 'on your preferred OS' or 'in VS Code on Windows, Linux, or macOS'.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/data-connector-ui-definitions-reference.md ...es/sentinel/data-connector-ui-definitions-reference.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Powershell Heavy
Summary
The documentation demonstrates a subtle Windows bias, primarily in the ordering and emphasis of examples and references. Windows-specific connectors (e.g., Windows DNS) are highlighted as detailed examples, and the InstallAgent component lists Windows installation options before Linux equivalents. The reference to the Windows DNS connector as a 'detailed example' and the ordering of InstallAgent link types (Windows before Linux) suggest a prioritization of Windows scenarios. There is also a lack of parity in example depth for Linux connectors, and no Linux-specific connector is referenced as a detailed example.
Recommendations
  • Provide equally detailed examples for Linux-based connectors, such as referencing a Linux Syslog or Linux DNS connector in the same way as the Windows DNS connector.
  • Alternate or randomize the order of Windows and Linux options in lists (e.g., InstallAgent link types) to avoid implicit prioritization.
  • Include explicit Linux/Powershell parity in examples, such as showing both Windows and Linux installation steps or configuration samples where relevant.
  • Reference Linux-specific tools and patterns (e.g., systemd, journald, syslog) alongside Windows tools in relevant sections.
  • Ensure screenshots and sample JSONs do not exclusively reflect Windows-centric scenarios.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/datalake/auditing-lake-activities.md ...articles/sentinel/datalake/auditing-lake-activities.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates a Windows bias by exclusively providing PowerShell examples for audit log searches, referencing Windows-centric tools and roles (Exchange Online, Office 365), and omitting any Linux or cross-platform CLI alternatives. The instructions and code snippets assume a Windows environment, with no mention of Linux-compatible methods or tools for accessing or querying audit logs.
Recommendations
  • Include equivalent examples using cross-platform tools such as Bash, curl, or Python scripts for querying the audit log via REST APIs.
  • Mention and document how to access audit logs from Linux or macOS environments, including authentication and API usage.
  • Provide guidance on using platform-agnostic tools (e.g., Microsoft Graph API, Office 365 Management Activity API) from non-Windows systems.
  • Clarify any platform requirements or limitations, and offer alternatives for users who do not have access to PowerShell or Windows environments.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/datalake/sentinel-lake-onboarding.md ...articles/sentinel/datalake/sentinel-lake-onboarding.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First Missing Linux Example 🔧 Windows Tools
Summary
The documentation page demonstrates a Windows bias by exclusively referencing Microsoft Defender, Microsoft Sentinel, and Azure portals—all of which are primarily accessed via web interfaces or Windows-centric tools. There are no examples or instructions for onboarding or managing the data lake using Linux tools, CLI, or cross-platform automation (e.g., Azure CLI, Bash scripts). All references to configuration, management, and exploration are tied to the Defender portal or Microsoft Sentinel, with no mention of PowerShell, but also no parity for Linux or cross-platform command-line approaches.
Recommendations
  • Add onboarding instructions using Azure CLI and Bash scripts to support Linux and cross-platform administrators.
  • Include examples for managing data lake resources via REST API or SDKs, which can be used on any platform.
  • Explicitly mention cross-platform compatibility for all portals and tools, clarifying which steps can be performed from Linux, macOS, or Windows.
  • Provide troubleshooting and offboarding steps that do not require submitting a support request via a Windows-centric portal.
  • Add a section comparing available tooling (portal, PowerShell, Azure CLI, REST API) and their platform compatibility.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/entities-reference.md ...docs/blob/main/articles/sentinel/entities-reference.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page demonstrates a Windows bias by referencing Windows-specific concepts and tools (e.g., NTDomain, NetBiosName, SID, RegistryKey/Hive, WindowsSecurityZoneType, AlternateDataStreamName) throughout the entity schemas. Windows terminology is consistently used first or exclusively, while Linux equivalents (such as UID/GID, /etc/passwd, Linux file attributes, or Linux registry alternatives) are not mentioned or described. There are no examples or schema attributes for Linux-specific entities, and fields like OSFamily and OSVersion only list Linux as an option without further detail or parity in examples.
Recommendations
  • Add Linux-specific identifiers and examples for entities such as Account (e.g., UID, GID, /etc/passwd), Host (e.g., hostname, /etc/hostname, domain concepts in Linux), and File (e.g., inode, file permissions, SELinux context).
  • Include Linux registry alternatives or clarify that RegistryKey/RegistryValue are Windows-only concepts.
  • Provide parity in documentation by listing Linux attributes and patterns alongside Windows ones, especially in tables and schema definitions.
  • Add examples of Linux-specific entity mapping and investigation, such as mapping Linux process attributes (e.g., /proc, systemd unit names) and Linux log sources.
  • Clarify which fields are applicable to Windows, Linux, or both, and provide guidance for cross-platform environments.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/fusion.md ...tDocs/azure-docs/blob/main/articles/sentinel/fusion.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First
Summary
The documentation page demonstrates a Windows bias primarily through the frequent mention of Windows-specific tools and patterns (such as PowerShell, Windows Error and Warning Events, and Windows malware), and by providing examples and scenarios that are centered around Windows environments and Microsoft Defender products. There is a lack of Linux-specific examples, tools, or equivalent scenarios, and Linux detection patterns are not mentioned or prioritized.
Recommendations
  • Add examples and scenarios that specifically reference Linux-based threats, logs, and detection patterns (e.g., Linux malware, SSH brute force, suspicious Bash commands).
  • Include Linux equivalents for Windows-specific tools and events, such as referencing syslog, auditd, or Linux security events alongside Windows Error and Warning Events.
  • Provide detection scenarios that involve Linux endpoints and common Linux attack vectors (e.g., rootkits, privilege escalation via sudo, cron job abuse).
  • Mention integration with Linux-native security solutions (such as Microsoft Defender for Endpoint on Linux, or third-party Linux security tools) where applicable.
  • Ensure that documentation examples and tables alternate or balance between Windows and Linux environments, rather than focusing primarily on Windows.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/includes/deprecated-connectors.md ...in/articles/sentinel/includes/deprecated-connectors.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several ways. Many deprecated connector sections (e.g., Microsoft Exchange Logs and Events, Security Events via Legacy Agent) focus exclusively on Windows machines, Windows agents, and Windows-specific data sources, with little or no mention of Linux equivalents or cross-platform alternatives. Windows tools and patterns (such as the Windows agent, Windows event logs, and PowerShell tabs in links) are referenced before or instead of Linux options. Linux is only explicitly mentioned in the Syslog connector section, which is brief and lacks parity with the detailed Windows sections. There are missing Linux-specific examples and guidance for several connectors.
Recommendations
  • Provide Linux-specific examples and instructions for all connectors where applicable, not just for Syslog.
  • Ensure that documentation for data collection agents and connectors includes both Windows and Linux scenarios, including prerequisites, installation steps, and troubleshooting.
  • Where Windows tools (e.g., Windows agent, PowerShell) are mentioned, also mention and link to equivalent Linux tools (e.g., Linux agent, shell commands) in the same context.
  • Add parity in detail and guidance for Linux connectors, including supported log types, configuration steps, and migration paths.
  • Review and update documentation links to include Linux tabs and examples, not just Windows/PowerShell.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/fusion-scenario-reference.md ...ob/main/articles/sentinel/fusion-scenario-reference.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Windows First Missing Linux Example
Summary
The documentation page demonstrates a Windows bias through frequent references to Windows-specific technologies (PowerShell, WMI), tools (Microsoft Defender for Endpoint, formerly MDATP), and patterns (remote WMI execution, PowerShell command line). Examples and scenarios focus on Windows endpoints and do not mention or provide parity for Linux equivalents (e.g., Bash, SSH, Linux endpoint telemetry). Linux-specific attack patterns, tools, or detection methods are absent, and Windows-centric terminology is used throughout, with no corresponding Linux guidance or examples.
Recommendations
  • Add scenarios and detection patterns for Linux endpoints, including common Linux attack techniques (e.g., SSH brute force, Bash script execution, Linux credential dumping tools like 'LaZagne' or 'John the Ripper').
  • Provide examples of malicious activity using Linux-native tools (e.g., suspicious Bash commands, cron job abuse, systemd manipulation) alongside PowerShell and WMI examples.
  • Reference Linux-compatible security solutions (e.g., Microsoft Defender for Endpoint for Linux, auditd, syslog, Linux firewall logs) in data connector sources and scenario descriptions.
  • Ensure parity in threat detection coverage by describing how Fusion correlates signals from Linux systems and cloud-native Linux resources, not just Windows VMs and services.
  • Explicitly mention Linux attack frameworks (e.g., Metasploit, Cobalt Strike on Linux, custom Python scripts) and how their activity would be detected.
  • Balance the use of Windows-specific terminology with Linux equivalents, and avoid presenting Windows tools/patterns first or exclusively.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-schema-alert.md ...b/main/articles/sentinel/normalization-schema-alert.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page exhibits a subtle Windows bias. Examples and field descriptions frequently reference Windows-specific concepts (e.g., C:\Windows paths, explorer.exe, registry keys, SID, Windows username format, and tools like PSEXEC and Rubeus). There are no Linux-specific examples (such as Linux file paths, processes, or user formats), and Windows terminology is used as the default or only illustration. Linux equivalents are not mentioned or are missing entirely.
Recommendations
  • Add Linux-specific examples alongside Windows ones, such as Linux file paths (/usr/bin/sshd), processes (sshd, bash), and user formats (e.g., user@hostname, UID).
  • Include registry-like configuration examples for Linux (e.g., /etc/passwd, /etc/ssh/sshd_config) in relevant sections.
  • Mention Linux tools or detection patterns (e.g., SSH brute force, sudo misuse, cron jobs) in rule and threat examples.
  • Clarify that fields and schema are OS-agnostic, and provide guidance for mapping Linux alerts and entities.
  • Balance references to Windows-specific concepts (SID, registry, PSEXEC) with Linux equivalents (UID/GID, configuration files, SSH, systemd, etc.).
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/microsoft-purview-record-types-activities.md .../sentinel/microsoft-purview-record-types-activities.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
Powershell Heavy 🔧 Windows Tools Missing Linux Example
Summary
The documentation references a PowerShell cmdlet (Unlock-SPOSensitivityLabelEncryptedFile) as a method for removing sensitivity labels from files, without mentioning any Linux or cross-platform alternatives. No Linux-specific tools, commands, or examples are provided, and the documentation implicitly assumes a Windows/PowerShell environment for administrative actions.
Recommendations
  • Include equivalent Linux or cross-platform methods for managing sensitivity labels, such as REST API calls or CLI tools available on Linux.
  • Explicitly state platform requirements and provide guidance for non-Windows users.
  • Add examples using bash, curl, or other Linux-native tools where possible.
  • Reference any available SDKs or automation options that work on Linux (e.g., Python scripts, Azure CLI).
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/migration-ingestion-tool.md ...lob/main/articles/sentinel/migration-ingestion-tool.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
Powershell Heavy Windows First 🔧 Windows Tools Missing Linux Example
Summary
The documentation page demonstrates a Windows bias in several areas: PowerShell is the primary scripting example for Azure Monitor ingestion, and the SIEM data migration accelerator deploys a Windows VM and downloads only Windows-compatible tools. Windows tools and patterns (PowerShell, Windows VM) are mentioned before or instead of Linux equivalents. There is a lack of explicit Linux or cross-platform examples for key migration steps, especially for custom log ingestion and accelerator usage.
Recommendations
  • Provide Linux/bash examples alongside PowerShell for custom log ingestion and REST API usage.
  • Clarify cross-platform compatibility for all tools, especially the custom log ingestion tool and SIEM data migration accelerator.
  • Offer instructions for deploying the SIEM data migration accelerator on Linux VMs or containers.
  • List Linux and macOS usage patterns and prerequisites wherever Windows-specific steps are given.
  • Explicitly mention and demonstrate how to use tools (e.g., AzCopy, Logstash) on Linux/macOS, not just note their compatibility.
  • Avoid assuming Windows as the default environment for migration tasks; present platform-neutral guidance.
GitHub Create Pull Request
Sentinel https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/sentinel/normalization-develop-parsers.md ...ain/articles/sentinel/normalization-develop-parsers.md
High Priority View Details →
Scanned: 2026-01-09 00:34
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
🔧 Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary
The documentation page exhibits Windows bias in several areas: deployment and management instructions frequently reference Windows-centric tools (Azure portal, PowerShell, ARM templates), and the only explicit script/tool for function deletion is a PowerShell script. There are no Linux-specific deployment or management examples, nor are CLI alternatives (such as Azure CLI or bash scripts) mentioned. The documentation assumes familiarity with Windows tools and patterns, and does not provide parity for Linux users in key operational steps.
Recommendations
  • Add Linux/Unix-specific deployment instructions, such as using Azure CLI or bash scripts for parser management.
  • Provide examples for deleting and managing functions using cross-platform tools (e.g., Azure CLI, REST API), not just PowerShell.
  • When referencing tools (e.g., ARM templates, portals), clarify platform-neutral options and explicitly mention Linux compatibility.
  • Include sample commands and workflows for parser deployment and testing that can be run from Linux environments.
  • Ensure that any referenced scripts or automation (such as the function delete tool) are available in cross-platform formats, or provide equivalent alternatives.
GitHub Create Pull Request
← Previous Page 6 of 20 Next →