323
Total Pages
242
Linux-Friendly Pages
81
Pages with Bias
25.1%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues (110)

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page shows a Windows bias primarily by referencing Windows agents and tools first (or exclusively) in several connector descriptions, especially for Microsoft Exchange and Security Events. Windows-specific terminology (e.g., 'Windows agent', 'Windows machines') is used without equivalent Linux context in multiple places. In contrast, Linux (Syslog) is mentioned only once, and there are no Linux-specific setup or troubleshooting examples for connectors that could apply to both platforms. There is also a lack of parity in prerequisites and instructions for Linux environments.
Recommendations:
  • For connectors that mention 'Windows agent' or 'Windows machines', add equivalent references and instructions for Linux agents/machines where applicable.
  • Provide Linux-specific setup, configuration, and troubleshooting examples alongside Windows examples for all relevant connectors.
  • Where prerequisites or permissions are listed for Windows (e.g., PowerShell, Windows agent), include corresponding Linux commands, tools, or agent instructions.
  • Avoid using Windows-centric language (e.g., 'Windows agent') as the default; instead, use cross-platform terms or explicitly mention both Windows and Linux.
  • Ensure that all connectors which can be used on Linux have clear documentation for Linux environments, including links to Linux agent installation and configuration guides.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by referencing PowerShell deployment scripts as the mechanism for custom deployment options, without mentioning or providing alternatives for Linux environments (such as Bash or cross-platform scripting). There are no Linux-specific examples or guidance, and the only scripting tool referenced is PowerShell, which is traditionally associated with Windows. No mention is made of running these workflows or scripts in a Linux environment, nor are any Linux-native tools or shell examples provided.
Recommendations:
  • Explicitly state whether the PowerShell deployment script is cross-platform (e.g., works with PowerShell Core on Linux/macOS) or provide equivalent Bash scripts/examples for Linux users.
  • Include Linux-specific instructions or examples for customizing deployments, such as using Bash or other common Linux automation tools.
  • Clarify any platform requirements or limitations for running deployment scripts, and provide guidance for Linux users where necessary.
  • Where possible, use neutral, cross-platform terminology (e.g., 'script' instead of 'PowerShell script') and provide both Windows and Linux command-line examples.
  • Add a section or note addressing Linux/macOS users, outlining any differences or additional steps required.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation references the use of a PowerShell cmdlet (Unlock-SPOSensitivityLabelEncryptedFile) as the only example of a command-line tool for managing sensitivity labels, with no mention of Linux or cross-platform alternatives. No Linux-specific tools, commands, or usage patterns are provided, and the documentation implicitly assumes a Windows/PowerShell environment for administrative tasks.
Recommendations:
  • Include equivalent command-line examples for Linux environments, such as using Microsoft Graph API via curl or other cross-platform tools.
  • Explicitly state whether the administrative tasks (e.g., unlocking sensitivity label encrypted files) can be performed on Linux, and provide guidance or alternatives if available.
  • Where PowerShell cmdlets are mentioned, add notes or links to REST API documentation or CLI tools that can be used on non-Windows platforms.
  • Review all examples and references to ensure Linux and macOS users are not excluded from administrative guidance.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation is heavily focused on Microsoft cloud services and tools (Dataverse, Power Platform, Dynamics 365, Microsoft Entra, SharePoint, Office 365, Microsoft Defender, Microsoft Teams, Outlook, etc.), with all examples and playbooks referencing only Microsoft-centric and Windows ecosystem technologies. There are no mentions of Linux tools, cross-platform command-line examples, or integration with non-Microsoft environments. The documentation assumes the use of Microsoft Sentinel and related services, which are primarily managed via web portals or PowerShell, but does not provide any Linux-specific guidance or parity.
Recommendations:
  • Add examples or guidance for integrating Microsoft Sentinel with Linux-based log sources, such as syslog, auditd, or Linux agents.
  • Include sample queries or playbooks that demonstrate detection or response for Linux endpoints (e.g., Linux file access, process creation, SSH logins).
  • Document how to automate responses or notifications using cross-platform tools (such as Python scripts, curl, or Linux mail utilities) in addition to Microsoft Teams and Outlook.
  • Clarify whether the solution supports Linux-based environments and, if so, provide explicit instructions or references for Linux users.
  • If PowerShell or Windows-specific tools are required, note this explicitly and suggest alternatives or workarounds for Linux-only environments.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy
Summary:
The documentation demonstrates a mild Windows bias. In the 'InstallAgent' section, Windows-related link types ('InstallAgentOnWindowsVirtualMachine', 'InstallAgentOnWindowsNonAzure') are listed before their Linux equivalents, and the only detailed example link provided is to a Windows DNS connector. There is also a lack of Linux-specific examples or references, and the only connector example referenced is for Windows. No PowerShell or Windows command-line examples are present, but the overall pattern and example selection favor Windows environments.
Recommendations:
  • Add Linux-focused examples and references, such as linking to a Linux data connector template (e.g., Syslog or Linux agent).
  • When listing options (such as link types), alternate or randomize the order, or list Linux and Windows together to avoid 'Windows first' ordering.
  • Provide at least one detailed example or screenshot for a Linux-based connector alongside the Windows DNS connector.
  • Explicitly mention parity and support for both Windows and Linux environments in the introduction and relevant sections.
  • If referencing external documentation or templates, ensure Linux connectors are equally represented.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a bias toward Windows and Microsoft-centric tools and workflows. All playbook examples and templates focus on Microsoft products (e.g., Microsoft Teams, Outlook, Defender for Endpoint, Entra ID, Azure Firewall) with no mention of Linux-native tools, open-source alternatives, or Linux-specific workflows. There are no examples of integrating with Linux firewalls (like iptables or nftables), Linux user management, or Linux-based notification/email systems. The documentation assumes a Microsoft ecosystem and does not provide parity for Linux environments.
Recommendations:
  • Include examples of playbooks that interact with Linux-based firewalls (e.g., iptables, nftables) for blocking IP addresses.
  • Provide templates or guidance for disabling Linux user accounts (e.g., using usermod or passwd commands) as part of incident response.
  • Add notification examples using Linux-native tools (e.g., sendmail, mailx, or integration with open-source chat platforms like Mattermost or Rocket.Chat).
  • Mention and demonstrate integration with open-source ticketing systems (e.g., OTRS, RT) alongside ServiceNow.
  • Balance the order of examples so that Linux/open-source options are presented alongside or before Microsoft/Windows-specific tools where applicable.
  • Explicitly state that playbooks can be extended to Linux environments and provide links or references to relevant connectors or scripts.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates a Windows bias by focusing migration steps and examples on Windows systems, such as referencing the 'Windows Security Events' solution, 'Windows Security Event connector', and 'Windows agent-based connections' without providing equivalent Linux examples or guidance. Linux-specific features are only briefly mentioned (e.g., Linux multi-homing) and not elaborated upon. There are no step-by-step instructions or connectors highlighted for Linux systems, and the documentation does not mention Linux tools or patterns for migration.
Recommendations:
  • Add parallel Linux-focused migration steps, including references to Linux-specific connectors and solutions (e.g., 'Linux Security Events via AMA').
  • Provide examples and screenshots for Linux agent installation, configuration, and validation, similar to the Windows examples.
  • Include guidance on uninstalling the legacy agent from Linux systems, referencing relevant commands and documentation.
  • Mention Linux tools and patterns (such as syslog, auditd, or Linux-specific data connectors) alongside Windows tools.
  • Ensure that Linux and Windows instructions are presented with equal prominence, or provide a clear structure separating guidance for each platform.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation exclusively describes authentication and configuration steps using the Azure portal and Logic Apps designer, both of which are web-based or GUI tools commonly accessed via Windows environments. There are no command-line examples (such as Azure CLI, Bash, or PowerShell) for Linux users, nor are there references to Linux-native tools or workflows. All instructions assume use of the Azure portal UI, which may be more familiar or accessible to Windows users.
Recommendations:
  • Add equivalent command-line instructions using Azure CLI (az) for all authentication and role assignment steps, which can be run on Linux, macOS, or Windows.
  • Include examples of how to perform authentication and role assignments using Bash scripts or via REST API calls.
  • Explicitly mention that all steps can be performed from any OS using the Azure portal, and provide parity in CLI examples.
  • Where screenshots are provided, consider including CLI output or terminal screenshots to illustrate cross-platform usage.
  • Clarify that Logic Apps and Microsoft Sentinel are cloud-based and accessible from any OS, but provide Linux-friendly automation examples.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
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 collecting security events from Linux systems, nor are Linux-specific connectors or data collection rules mentioned. The focus on Windows tools and lack of Linux parity may leave Linux administrators without clear guidance for cost optimization.
Recommendations:
  • Add a section or examples for collecting and optimizing security event ingestion from Linux servers, including relevant connectors (e.g., Syslog, CEF) and data collection rules.
  • Mention Linux data sources and how to use data collection rules or agents (such as the Azure Monitor Agent on Linux) to filter and optimize log ingestion.
  • Ensure that references to connectors and data collection are platform-neutral where possible, or provide parallel guidance for both Windows and Linux environments.
  • Review the documentation for other areas where only Windows-centric tools or workflows are described, and add Linux equivalents or cross-platform instructions.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not display overt Windows bias in terms of command-line examples, tools, or patterns, but it lacks any mention of Linux or cross-platform considerations. There are no examples or instructions that reference Windows-specific tools (like PowerShell) or workflows, but equally, there is no information about Linux compatibility, deployment, or usage, which may leave Linux users uncertain about support or required steps.
Recommendations:
  • Explicitly state whether the Microsoft Sentinel solution for MS Business Apps is supported on both Windows and Linux environments.
  • If relevant, provide examples or notes for both Windows and Linux administrators (e.g., how to configure connectors or access logs from Linux-based systems).
  • Mention any platform-specific requirements, limitations, or best practices for Linux environments.
  • Include references or links to cross-platform documentation or troubleshooting guides.
  • Clarify if any features (such as Playbooks or Parsers) have different behaviors or setup steps on Linux versus Windows.

Page-Level Analysis

Powershell Heavy Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by prioritizing PowerShell and Windows-centric deployment methods. The manual deployment section provides detailed PowerShell instructions before Python, and the PowerShell example assumes use of the Azure portal and PowerShell Core, both of which are more familiar to Windows users. There is no mention of Linux shell (e.g., Bash) or CLI-based deployment options, and no explicit Linux or cross-platform examples are provided. The Python deployment requires Visual Studio Code, which, while cross-platform, is not the default editor on Linux systems. There are no examples using Azure CLI, Bash, or Linux-native tools.
Recommendations:
  • Add explicit Linux/Bash shell deployment instructions, including examples using Azure CLI and Bash scripts.
  • Present deployment options in a neutral order (e.g., ARM template, Python, PowerShell) or clarify that all are equally supported.
  • Include notes or examples for Linux users, such as using the Azure CLI in Bash to deploy and configure Function Apps.
  • Highlight cross-platform tooling (e.g., Azure CLI, VS Code) and provide alternatives for users who may not use PowerShell or Windows.
  • Ensure that references to workspace keys and configuration steps are not Windows-specific (e.g., avoid linking only to Windows agent documentation).

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates a Windows-first bias by referencing Windows VM creation before Linux, and by providing a direct link to Windows agent installation instructions while only offering a troubleshooting link for Linux. There are no explicit Linux onboarding or installation steps, nor are Linux-specific examples or guidance provided for the extension installation process.
Recommendations:
  • Provide parallel Linux onboarding instructions, including a direct link to the Linux agent installation documentation (not just troubleshooting).
  • Ensure that both Windows and Linux VM creation links are presented together or in a neutral order.
  • Include Linux-specific notes or screenshots where relevant, especially if the extension installation process differs.
  • Add a section or callout for Linux users explaining any unique steps or considerations.
  • Review all references to ensure Linux and Windows are treated with equal prominence and detail.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not display overt Windows bias in terms of command-line examples or tool recommendations. However, it lacks parity by not providing any Linux-specific examples or instructions, especially in the section where cURL is mentioned. The only command-line tool referenced (cURL) is cross-platform, but no explicit Linux or macOS usage is shown, nor are there any screenshots or steps that acknowledge Linux environments. The documentation is focused on the Microsoft Sentinel web interface, which is platform-agnostic, but it misses opportunities to address Linux users directly.
Recommendations:
  • When mentioning cURL, provide explicit examples for both Windows (e.g., PowerShell or Command Prompt) and Linux/macOS (e.g., bash shell).
  • Include notes or sections that clarify that all steps can be performed from any OS with a supported browser, and highlight any OS-specific considerations if they exist.
  • If screenshots or instructions reference file paths or command-line usage, ensure both Windows and Linux formats are shown.
  • Consider adding a brief section or FAQ addressing common Linux/macOS user questions, such as authentication or network troubleshooting.

Page-Level Analysis

Windows First Windows Terms Windows Examples
Summary:
The documentation shows a mild Windows bias. Windows-specific terms (such as 'NTDomain', 'DeviceNtDomain', 'DestinationNTDomain', 'SourceNTDomain') are present as field names and descriptions. In several field descriptions, Windows is mentioned explicitly (e.g., 'The Windows domain of the device address'). File path examples consistently list the Windows path first (e.g., 'C:\ProgramFiles\WindowsNT\Accessories\wordpad.exe' before '/usr/bin/zip'). There are no PowerShell-specific examples or exclusive use of Windows tools, but Windows terminology and examples are more prominent or appear before Linux equivalents.
Recommendations:
  • Alternate the order of Windows and Linux/Unix examples in file paths, or list Linux examples first in some cases.
  • Where possible, generalize field descriptions to avoid Windows-centric language (e.g., say 'domain name' instead of 'Windows domain name'), or provide both Windows and Linux/Unix context.
  • Add clarifying notes for fields that are Windows-specific, and provide equivalent Linux/Unix fields or note when not applicable.
  • Ensure that examples and terminology are balanced between Windows and Linux/Unix systems throughout the documentation.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a mild Windows bias: file path examples consistently show Windows paths (e.g., c:\temp) before Linux equivalents (e.g., /tmp), and in some cases, only the Windows path is shown in code snippets. In configuration examples, the sample_file_path is set to a Windows path by default. There are no PowerShell-specific commands or Windows-only tools, but the ordering and emphasis of examples favor Windows. Linux-specific troubleshooting is only briefly mentioned in the Docker/Ubuntu section, and Linux file path conventions are not given equal prominence throughout.
Recommendations:
  • Present Linux and Windows file path examples side-by-side or alternate their order to avoid always listing Windows first.
  • In code snippets, use placeholder paths (e.g., <path-to-temp-dir>) and provide both Windows and Linux examples in comments.
  • Ensure that all instructions and examples are equally applicable to both Linux and Windows environments.
  • Add explicit Linux shell command examples where relevant (e.g., for file creation, permissions, or service management).
  • Highlight any OS-specific considerations (such as file permissions or service management) in dedicated callout sections.
  • Review all code and configuration blocks to ensure Linux parity and avoid defaulting to Windows-centric paths or conventions.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows environments, specifically Windows DNS servers, and does not mention or provide guidance for Linux-based DNS servers or cross-platform scenarios. All examples, prerequisites, and instructions are tailored exclusively for Windows Server, with no Linux equivalents or alternatives discussed. The tools and terminology (e.g., Windows DNS Events, Windows Server DNS, Windows event logs) are Windows-specific, and there is no indication of parity or support for Linux DNS logging or ingestion.
Recommendations:
  • Add a section clarifying whether Linux-based DNS servers (such as BIND or dnsmasq) are supported, and if not, explicitly state this limitation.
  • If Linux DNS log ingestion is possible, provide equivalent instructions, prerequisites, and examples for popular Linux DNS servers.
  • Include Linux-specific tools, log file paths, and configuration steps where relevant.
  • Use more inclusive language in titles and throughout the documentation (e.g., 'Stream and filter DNS logs with the AMA connector' instead of 'Windows DNS logs').
  • If the connector is Windows-only, suggest alternative solutions or connectors for Linux DNS log ingestion, or link to relevant documentation.
  • Ensure that any API examples or schemas are annotated to indicate whether they are Windows-specific or cross-platform.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation page focuses exclusively on Microsoft Sentinel and Microsoft security solutions, with all examples and instructions centered around the Azure portal UI and Microsoft-specific tools. There are no references to Linux tools, command-line interfaces, or cross-platform automation methods. The documentation implicitly assumes a Windows-centric environment by only mentioning Microsoft products and workflows, without addressing how users on Linux or other platforms might interact with Sentinel or automate incident creation.
Recommendations:
  • Include examples of how to interact with Microsoft Sentinel using cross-platform tools such as the Azure CLI or REST API, which are available on Linux, macOS, and Windows.
  • Provide sample scripts for automating incident creation using Bash or Python, in addition to (or instead of) PowerShell.
  • Explicitly mention that the UI and automation options are accessible from any OS with a web browser, and clarify any platform-specific limitations.
  • Reference relevant documentation for Linux users, such as installing and using the Azure CLI on Linux, or integrating Sentinel with non-Microsoft security solutions.
  • If automation is discussed, show both PowerShell and Bash (or Python) equivalents for parity.

Page-Level Analysis

Windows First Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page exhibits a Windows bias primarily by referencing Windows-centric tools and automation methods (notably PowerShell), mentioning them before or instead of cross-platform or Linux-native alternatives. The only automation scripting example given is PowerShell, and there is no mention of Linux command-line tools or scripting options. The documentation also references the Azure and Defender portals, which are web-based and cross-platform, but when it comes to automation and exporting, only Windows/PowerShell options are highlighted, with no Linux or CLI parity.
Recommendations:
  • Include examples of automating rule management using Azure CLI (az) or Bash scripts, not just PowerShell.
  • Explicitly mention that API and PowerShell automation can be performed from Linux/macOS as well, and provide cross-platform instructions.
  • Reference and provide examples for using REST API via curl or other Linux-native tools for rule management.
  • Where PowerShell is mentioned, also provide equivalent commands or scripts using Azure CLI or generic REST API calls.
  • Clarify that exporting/importing ARM templates can be done from any OS, and provide sample commands for Linux environments.
  • If possible, add a section or callout for Linux users, summarizing the parity and any differences in workflow.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First
Summary:
The documentation page demonstrates a Windows bias by referencing Windows-specific tools and technologies (such as PowerShell, Windows events, and Windows malware families) without providing equivalent Linux examples or mentioning Linux-specific attack patterns. PowerShell is highlighted in multiple detection scenarios, and Windows alerts are used as illustrative examples. There is no mention of Linux-based threats, tools, or detection patterns, nor are Linux command-line or log sources referenced.
Recommendations:
  • Include detection scenarios and examples that reference Linux-based attacks, such as suspicious Bash or shell activity, Linux-specific malware, or Linux log sources (e.g., syslog, auditd).
  • Provide examples of multistage attacks that involve Linux endpoints or mixed-OS environments.
  • Balance the use of Windows-specific tools (like PowerShell and Windows Event Logs) with Linux equivalents (such as Bash, systemd, or Linux audit logs).
  • Add references to Linux security solutions (e.g., Microsoft Defender for Endpoint on Linux, or integration with Linux EDR tools) where appropriate.
  • Ensure that tables and illustrative examples include both Windows and Linux alerts/incidents to demonstrate parity.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation refers to opening a 'command prompt' without specifying platform, which is a Windows-centric term. No explicit mention is made of Linux or macOS terminals, nor are there any platform-specific instructions or clarifications. All command-line examples use curl, which is cross-platform, but the language and context assume a Windows environment by default and do not address Linux users directly.
Recommendations:
  • Replace or supplement the phrase 'open a command prompt' with 'open a terminal or command prompt,' and clarify that the instructions apply to Windows, Linux, and macOS.
  • Add a note confirming that curl commands work on all major platforms, and provide installation guidance or references for curl on Windows, Linux, and macOS if necessary.
  • Where file paths are referenced (e.g., <enter_path_to_file>.json), provide examples for both Windows (C:\path\to\file.json) and Linux/macOS (/path/to/file.json) to avoid ambiguity.
  • Explicitly state that the instructions are platform-agnostic, or provide any necessary platform-specific caveats (such as quoting or escaping differences).

Page-Level Analysis

Missing Linux Example
Summary:
The documentation page does not display overt Windows bias in terms of mentioning Windows tools, PowerShell, or Windows-specific patterns. However, it lacks any mention of Linux-specific tools, workflows, or examples, and does not address cross-platform considerations. All examples and instructions are platform-neutral but implicitly assume the use of Azure Logic Apps and Microsoft Sentinel interfaces, which are web-based and not OS-specific. The absence of Linux-specific guidance or parity checks constitutes a 'missing_linux_example' bias.
Recommendations:
  • Explicitly mention that Microsoft Sentinel and Logic Apps are accessible and manageable from Linux, macOS, and Windows environments.
  • Provide example workflows or command-line interactions (e.g., using Azure CLI) from a Linux shell, especially for tasks like exporting/importing ARM templates or managing playbooks.
  • Include references to cross-platform tools (such as Azure CLI, REST API usage) and clarify that PowerShell is not required.
  • Add a section or note on how to perform common migration or operational tasks from Linux systems, ensuring parity with any Windows-based instructions.
  • If any automation or scripting is discussed, provide both Bash and PowerShell examples where relevant.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by prioritizing Windows-based data connectors and tooling. Windows-specific agents and event types (e.g., Windows agent, SecurityEvent, W3CIISLog) are mentioned explicitly, while Linux equivalents are only referenced in a single entry (Syslog via Legacy Agent) and not in parity with the Windows coverage. The documentation for Microsoft Exchange and Security Events focuses solely on Windows machines and agents, with no comparable Linux event collection examples or guidance. Additionally, links and instructions for agent installation reference Windows-centric tabs and tools, and Linux agent scenarios are not equally detailed.
Recommendations:
  • Provide Linux-based examples and instructions alongside Windows ones for all relevant connectors, especially for event and log collection.
  • Ensure that agent installation documentation references both Windows and Linux agents equally, with clear parity in detail and guidance.
  • Include Linux event types (such as auditd, auth.log, etc.) and their mapping to Log Analytics tables where applicable.
  • Where Windows-specific tools or logs are mentioned (e.g., W3CIISLog, SecurityEvent), add Linux equivalents (e.g., Apache/Nginx logs, Syslog, audit logs) and describe their ingestion.
  • Review all prerequisite and setup sections to ensure Linux users are not omitted and have clear, actionable steps.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing the PowerShell New-GUID cmdlet as an example for generating GUIDs, without mentioning Linux or cross-platform alternatives. No Linux or macOS command-line tools are suggested for this task, and the only explicit tooling example is Windows-specific. This may hinder Linux or cross-platform users from following the guidance seamlessly.
Recommendations:
  • When suggesting how to generate a GUID, include cross-platform and Linux-native options, such as 'uuidgen' (available on most Linux/macOS systems) or Python's uuid module.
  • Rephrase the sentence to mention multiple platforms, e.g., 'Generate it by using any development tool, an online generator, the PowerShell New-GUID cmdlet (Windows), or the uuidgen command (Linux/macOS)'.
  • Wherever command-line examples are given, provide both Windows (PowerShell/CMD) and Linux/macOS (bash/sh) equivalents.
  • Audit the documentation for other places where Windows tools or patterns are referenced first or exclusively, and ensure Linux parity in examples and tool recommendations.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation provides a PowerShell script for automating the rotation of BTP client secrets, relying on Azure PowerShell modules and cmdlets. No equivalent Bash, Azure CLI, or cross-platform scripting example is provided. The automation guidance is thus Windows-centric, and Linux users are not given parity in automation instructions.
Recommendations:
  • Provide equivalent automation examples using Azure CLI and Bash scripts for Linux/macOS environments.
  • Explicitly mention that the PowerShell script is intended for Windows users, and link to or include Linux-compatible alternatives.
  • Where possible, use cross-platform tools (e.g., Azure CLI) in examples, or offer both PowerShell and Bash/CLI versions side by side.
  • Review other automation or scripting sections for similar bias and ensure Linux users have clear, actionable guidance.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates Windows bias by recommending and documenting tools (such as LightIngest) that are Windows-only, without providing Linux alternatives or guidance for non-Windows environments. There are no Linux-specific examples or instructions, and the documentation does not clarify cross-platform compatibility for other tools (such as AzCopy or the Custom Log Ingestion script). The order of presentation and lack of parity in tooling further reinforce a Windows-centric approach.
Recommendations:
  • Provide explicit instructions and examples for Linux environments, including installation and usage of ingestion tools on Linux.
  • If a tool is Windows-only (e.g., LightIngest), recommend and document alternative ingestion methods for Linux (such as using Azure Data Explorer's ingestion REST API, Python SDK, or other cross-platform tools).
  • Clarify the cross-platform compatibility of tools like AzCopy and the Custom Log Ingestion script, and include Linux/macOS installation and usage steps where applicable.
  • Present platform-agnostic or Linux-first options alongside Windows instructions to ensure parity and inclusivity.
  • Add a table or section summarizing supported platforms for each tool, with links to relevant documentation for each OS.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias in several areas: file paths and process examples use Windows conventions (e.g., C:\Windows\explorer.exe, C:\Windows\System32\notepad.exe), registry fields reference Windows Registry exclusively, and user identity examples use Windows formats (e.g., Contoso\JSmith, SID). There are no Linux or cross-platform examples for file paths, process names, or user identities, and no mention of Linux equivalents for registry or process fields. No Linux-specific tools or patterns are referenced.
Recommendations:
  • Provide Linux/Unix examples alongside Windows examples for file paths (e.g., /usr/bin/bash), process names, and command lines.
  • Include Linux user identity formats (e.g., UID, user@domain) in user field examples.
  • Clarify that registry fields are Windows-specific and, if applicable, describe how similar data might be represented on Linux (e.g., configuration files, /etc).
  • Add examples of alerts and schema usage from Linux-based systems to ensure parity.
  • Where possible, use neutral or cross-platform examples (e.g., generic process names, file paths) to avoid platform-specific bias.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a clear Windows bias in the sections describing how to generate and sanitize ARM templates for playbooks. The only automation script provided is a PowerShell script, and instructions reference running it in Visual Studio Code, Windows PowerShell, or PowerShell Core. There are no examples or guidance for performing these tasks on Linux or macOS, nor are alternative tools or shell commands mentioned. The documentation assumes the user is on a Windows environment, both in tool recommendations and in the order of presentation.
Recommendations:
  • Provide equivalent instructions for Linux and macOS users, including how to run the PowerShell script using PowerShell Core on those platforms.
  • Explicitly state that PowerShell Core is cross-platform and provide installation links for Linux/macOS.
  • Offer alternative methods for extracting and sanitizing ARM templates using Azure CLI, Bash, or other cross-platform tools.
  • Include example commands and screenshots from Linux/macOS terminals where appropriate.
  • Avoid assuming Visual Studio Code or Windows PowerShell as the default environment; mention cross-platform editors and shells.
  • Add a section or note clarifying platform compatibility for all scripts and tools referenced.

Page-Level Analysis

Windows Tools Powershell Heavy Missing Linux Example Windows First
Summary:
The documentation page demonstrates a Windows bias by focusing heavily on Windows-specific tools, commands, and attack techniques (such as rundll32.exe, PowerShell, Certutil, Exchange PowerShell Snapin, and Windows System Shutdown/Reboot). Many hunting queries and analytic rules reference Windows-centric binaries and behaviors, with little to no mention of Linux or cross-platform equivalents. There are no explicit Linux examples or references to Linux-specific threats, tools, or command-line patterns. This may leave Linux users without clear guidance or parity in threat detection and hunting.
Recommendations:
  • Add Linux-specific examples and hunting queries, such as detections for common Linux persistence or privilege escalation techniques (e.g., cron jobs, systemd service abuse, SSH key misuse).
  • Include analytic rules and hunting queries that reference Linux-native tools and binaries (e.g., bash, systemctl, sudo, /etc/passwd modifications).
  • Balance the documentation by providing both Windows and Linux perspectives for each content area (process, file, registry, network, etc.), or explicitly state if a given rule is Windows-only.
  • Highlight cross-platform detection strategies where possible, and clarify which rules are applicable to Linux, macOS, or other operating systems.
  • Consider adding a section or table summarizing OS coverage for each analytic rule and hunting query.

Page-Level Analysis

Windows First Windows Tools Windows Heavy Examples
Summary:
The documentation exhibits a moderate Windows bias. Windows-specific identifiers (e.g., SID, Windows domain\username format) are consistently listed before Linux equivalents (e.g., UID, simple username). Examples and field priorities often use Windows-centric formats, and Windows terminology (such as SIDs, domain\username, and C:\Windows\System32\svchost.exe) is more prominent and detailed than Linux references. Linux is mentioned, but usually after Windows, and with less detail or fewer examples.
Recommendations:
  • Alternate the order of Windows and Linux examples throughout the documentation, or present them side-by-side to ensure parity.
  • Provide Linux-specific examples (e.g., UID, /usr/bin/processname) wherever Windows examples are given (such as for ActorUserId, GroupId, ActingAppName).
  • Expand on Linux username and group formats (e.g., user@host, /etc/passwd entries) in the same detail as Windows formats.
  • Include Linux-specific terminology and normalization recommendations (e.g., mention GID for groups, typical Linux username conventions, and process paths).
  • Ensure that field type recommendations and normalization guidelines are equally detailed for both Windows and Linux systems.

Page-Level Analysis

Windows First Windows Tools Windows Examples Missing Linux Example
Summary:
The documentation demonstrates a Windows bias through the exclusive use of Windows-style file paths (e.g., C:\Windows\explorer.exe), Windows-specific concepts (such as integrity levels and UAC), and examples referencing Windows tools and formats. While some fields mention Linux, there are no Linux-specific examples, terminology, or parity in explanations. Windows terminology and references are consistently presented first or exclusively, with little to no Linux context.
Recommendations:
  • Provide Linux-specific examples alongside Windows examples, such as using /usr/bin/bash or /usr/bin/sshd in process name/path fields.
  • When describing fields like integrity levels or session IDs, include Linux equivalents or clarify how these concepts map (or do not map) to Linux systems.
  • Balance the use of Windows and Linux terminology in field descriptions and examples, ensuring both platforms are represented.
  • Add explicit notes or tables indicating differences in field population or semantics between Windows and Linux sources.
  • Where Windows tools or concepts are referenced (e.g., UAC, Win32 integrity levels), provide Linux analogs or state when no direct equivalent exists.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows/Azure portal-centric bias by exclusively describing integration steps using the Azure portal GUI, with no mention of command-line alternatives (such as Azure CLI, PowerShell, or Bash scripts) that would be relevant for Linux users. There are no examples or instructions for performing these tasks from Linux environments, nor is there any reference to cross-platform tooling or automation approaches.
Recommendations:
  • Add equivalent instructions for configuring diagnostic settings and data connectors using Azure CLI, which is cross-platform and commonly used on Linux.
  • Provide sample scripts or commands for running Microsoft Purview scans and managing Sentinel analytics rules via CLI or REST API.
  • Explicitly mention that all portal-based steps can be performed from any OS with a web browser, but highlight automation options for Linux users.
  • Include references or links to documentation on using Azure CLI and REST APIs for relevant tasks.
  • Where screenshots are shown, clarify that the UI is accessible from any platform, and supplement with text-based alternatives.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy Missing Linux Example
Summary:
The documentation provides both Windows and Linux instructions for setting environment variables, but Windows instructions are presented first, and Windows-specific tools (such as the System Properties dialog) are described in more detail. The Linux section is less detailed and assumes more user familiarity with the command line. There are also references to Windows environment variable syntax (e.g., %userprofile%) before Linux equivalents (~), and the Windows workflow is described in a more step-by-step, GUI-oriented manner, while Linux instructions are more condensed and terminal-focused. There are no PowerShell-specific commands, but the overall pattern prioritizes Windows tools and workflows.
Recommendations:
  • Present Linux and Windows instructions in parallel or in the same level of detail, rather than always listing Windows first.
  • Provide equally detailed, step-by-step instructions for Linux users, including screenshots or explicit command examples for common tasks (e.g., editing .bashrc with nano or vim).
  • When referencing environment variable paths, list both Windows (%userprofile%) and Linux (~) syntaxes together, or default to platform-agnostic language.
  • Ensure that all examples and workflows are provided for both platforms, with clear parity in explanation and troubleshooting steps.
  • Consider including PowerShell and Bash equivalents for any command-line instructions, and avoid assuming GUI access for Windows users only.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy
Summary:
The documentation demonstrates a Windows bias by referencing Windows-specific event sources (e.g., 'Microsoft-Windows-Sysmon'), using Windows-centric terminology and examples (such as EventID, ProcessName, and the Event table), and prioritizing Windows/PowerShell tools for deployment and management (e.g., recommending PowerShell scripts for deleting functions, and referencing Azure portal and PowerShell for ARM template deployment). There is a lack of explicit Linux or cross-platform deployment/testing instructions, and examples focus on Windows event sources or generic KQL, without showing Linux-specific log sources or command-line tools.
Recommendations:
  • Include Linux-specific examples, such as parsing logs from common Linux sources (e.g., auth.log, messages, or Linux audit logs) and show how to map these to ASIM schemas.
  • Provide deployment and management instructions using cross-platform tools such as Azure CLI and/or REST API, not just PowerShell and Azure Portal.
  • When referencing event sources or tables, include both Windows and Linux examples (e.g., show Syslog and Windows Event Log side by side).
  • Explicitly mention and provide examples for Linux-based environments in sections discussing log collection, parser development, and testing.
  • If recommending scripts or tools, ensure that Linux-compatible alternatives (e.g., Bash scripts, Azure CLI) are documented alongside PowerShell.
  • Review terminology to ensure it is inclusive of both Windows and Linux environments, avoiding Windows-centric language where possible.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation page focuses exclusively on Splunk-to-Microsoft Sentinel migration and provides step-by-step instructions for exporting data from Splunk using Splunk Web, but does not mention or provide examples for Linux command-line tools, shell scripts, or non-GUI workflows. There are no references to Windows-specific tools or PowerShell, but the lack of Linux/CLI parity in the export/upload process and absence of cross-platform considerations indicate a subtle bias toward GUI-based (often Windows-centric) workflows.
Recommendations:
  • Add instructions for exporting Splunk detections using the Splunk CLI or REST API, with example commands for Linux environments.
  • Include sample shell scripts or curl commands for users who prefer or require command-line workflows, especially on Linux systems.
  • Clarify that the export and upload process can be performed from any OS, and provide OS-agnostic guidance.
  • Where screenshots are shown, consider including both GUI and CLI alternatives, or at least mention that CLI options exist.
  • Explicitly state platform requirements or lack thereof, to reassure Linux users that the process is not Windows-specific.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation repeatedly references CSV formatting differences between files created in Microsoft Excel and those created in a 'text editor', but does not mention Linux-specific tools or editors (such as LibreOffice, nano, vim, or Linux command-line CSV creation). Microsoft Excel is mentioned by name, while the alternative is generically described, implicitly centering the Windows/Office experience. No Linux or cross-platform tools are named, and no Linux-specific examples are provided.
Recommendations:
  • Explicitly mention cross-platform and Linux-friendly tools for creating CSV files, such as LibreOffice Calc, Google Sheets, or command-line utilities (e.g., csvkit, awk, sed).
  • Provide examples of CSV formatting/output from Linux tools or editors (e.g., show how to create a compatible CSV using nano, vim, or command-line tools).
  • When describing CSV differences, avoid centering Microsoft Excel; instead, use neutral language or list multiple tools (e.g., 'for CSV files created in Microsoft Excel, LibreOffice Calc, or other spreadsheet editors...').
  • Consider adding a section or note on ensuring CSV compatibility across different operating systems and editors, including common pitfalls on Linux.
  • If relevant, provide sample commands for generating or validating CSVs on Linux (e.g., using cat, echo, or csvkit).

Page-Level Analysis

Windows First Windows Tools Powershell Heavy Missing Linux Example
Summary:
The documentation generally provides both Windows and Linux examples for most applications, but there are several instances of Windows bias. In many cases, Windows file paths are listed before Linux equivalents ('windows_first'). Some applications (e.g., Apache Tomcat, NGINX, SecurityBridge) only provide Linux examples, omitting Windows instructions ('missing_linux_example'). There is a tendency to mention Windows tools and file paths, and the documentation refers to Windows-specific configuration files and patterns ('windows_tools'). While PowerShell commands are not explicitly shown, the overall structure and ordering favor Windows environments.
Recommendations:
  • For all application sections, ensure both Windows and Linux examples are provided, or explicitly state if a platform is not supported.
  • When listing file paths or configuration steps, alternate the order (sometimes Linux first), or present both together to avoid 'windows_first' bias.
  • Where only Linux examples are given (e.g., Apache Tomcat, NGINX, SecurityBridge), clarify if Windows is unsupported or provide equivalent Windows instructions if possible.
  • If referencing Windows tools or configuration files, provide Linux equivalents or note platform-specific differences.
  • Review general instructions and introductory sections to ensure parity in mentioning both platforms and avoid implicit prioritization of Windows.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation provides only HTTP REST API examples and does not include any platform-specific command-line examples (such as PowerShell, curl, or CLI). However, it also does not provide any Linux-specific guidance or examples (e.g., using curl or bash), which may disadvantage Linux users who are accustomed to such tools. There is no explicit Windows bias in the form of PowerShell or Windows tool references, but the lack of Linux-oriented examples is a subtle bias.
Recommendations:
  • Add example commands using curl for Linux/macOS users to demonstrate how to make the REST API calls from a Linux shell.
  • If providing command-line examples, ensure parity by including both PowerShell (for Windows) and bash/curl (for Linux/macOS) examples.
  • Explicitly mention that the REST API can be accessed from any platform and provide guidance or links for common tools on both Windows and Linux.
  • Consider including sample scripts or one-liners for both Windows and Linux environments to illustrate cross-platform usage.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates Windows bias by providing only a Windows-style file path (c:/data.csv) in the CLI example, omitting equivalent Linux/macOS examples. There is no mention of Linux/Unix file paths or shell environments, and the examples assume a Windows context for file output. No PowerShell-specific commands are present, but the lack of Linux parity and the use of Windows file path conventions indicate a bias.
Recommendations:
  • Provide equivalent Linux/macOS CLI examples using Unix-style file paths (e.g., /tmp/data.csv).
  • Mention that the CLI commands work across platforms and clarify any OS-specific differences.
  • Add notes or examples for running the commands in Linux/Unix shells (bash, zsh) as well as Windows Command Prompt or PowerShell.
  • Use platform-neutral file paths in examples, or provide both Windows and Linux/macOS variants side by side.

Page-Level Analysis

Windows First Powershell Heavy
Summary:
The documentation demonstrates a mild Windows bias, particularly in the 'Testing APIs' section, where Windows-centric tools (Visual Studio Code, PowerShell Invoke-RestMethod, Microsoft Edge Network Console) are listed before cross-platform or Linux-native tools (Bruno, curl). PowerShell is specifically highlighted, and no Linux shell or CLI examples (such as bash with curl or httpie) are provided. There are no explicit Linux examples or references to Linux-native tools or workflows elsewhere in the document.
Recommendations:
  • List cross-platform and Linux-native tools (such as curl, httpie, Postman, or Bruno) before or alongside Windows-specific tools in the 'Testing APIs' section.
  • Provide example API calls using both PowerShell and bash/curl to ensure parity for Linux users.
  • Mention that Visual Studio Code and Edge are available cross-platform, or suggest alternative Linux editors (like Vim or nano) for editing JSON/ARM templates.
  • Include explicit instructions or notes for Linux/macOS users where file paths, shell commands, or environment differences may be relevant.
  • Where PowerShell is referenced, add equivalent bash or shell command examples to ensure inclusivity.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows-first bias by focusing migration steps and examples almost exclusively on Windows systems and tools. It references Windows-specific connectors and solutions (e.g., 'Windows Security Events'), and does not provide equivalent Linux migration examples or mention Linux-specific connectors or tools. Linux is only briefly mentioned as a feature (multi-homing), with no concrete guidance or parity in migration steps.
Recommendations:
  • Include explicit migration steps and examples for Linux systems, such as connecting Linux machines to Microsoft Sentinel using AMA.
  • Reference and link to Linux-specific connectors or solutions (e.g., 'Linux Security Events via AMA'), if available.
  • Provide sample configurations or screenshots for Linux environments, similar to those given for Windows.
  • Ensure that prerequisites and troubleshooting sections address both Windows and Linux environments equally.
  • Mention Linux tools and commands for agent management and uninstallation, not just Windows tools.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation exclusively describes authentication steps using the Azure Portal UI and Azure Logic Apps designer, both of which are web-based and platform-agnostic, but does not provide any command-line examples. There are no references to Windows-specific tools or PowerShell, but there is also a complete absence of Linux (or cross-platform) CLI examples (such as Azure CLI or REST API), which are commonly used in Linux environments. This omission may disadvantage Linux users or those who prefer automation via CLI or scripting.
Recommendations:
  • Add equivalent Azure CLI commands for all authentication and role assignment steps, showing how to enable managed identity, assign roles, and create connections programmatically.
  • Include REST API examples for advanced users or automation scenarios, which are platform-neutral.
  • Explicitly mention that all steps can be performed on any OS via the Azure Portal, but provide links or examples for CLI-based workflows to ensure Linux parity.
  • If screenshots or UI steps are shown, consider adding CLI/script snippets alongside them for each major action.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation provides examples for creating Data Collection Rules (DCRs) and their associations, with a focus on API requests and JSON payloads. While the Syslog/CEF example explicitly sets 'kind': 'Linux', the custom log example uses a Windows file path ('C:\Server\bin\log\Apache24\logs\*.log') in the response, and does not provide a Linux file path equivalent. There are no PowerShell or Windows tool-specific commands, but the only concrete file path example is Windows-style, and Linux patterns are not shown. This may confuse or exclude Linux users, especially since custom log collection is a common Linux scenario.
Recommendations:
  • For every example using a Windows file path, provide a Linux equivalent (e.g., '/var/log/apache2/*.log').
  • Explicitly mention both Windows and Linux file path conventions in the documentation.
  • If the DCRs support both OS types, clarify any OS-specific requirements or differences.
  • Add a note or table summarizing path syntax differences between platforms.
  • Ensure that sample payloads and responses are balanced between Windows and Linux scenarios.

Page-Level Analysis

Windows Tools Windows First Missing Linux Example
Summary:
The documentation page demonstrates a bias toward Windows and Microsoft-centric tools and workflows. All example playbooks, templates, and integrations focus on Microsoft products (Teams, Outlook, Entra, Defender for Endpoint, Azure Firewall) and ServiceNow, with no mention of Linux-native tools, open-source alternatives, or cross-platform command-line examples. There are no references to Linux firewalls (e.g., iptables, nftables), Linux user management, or Linux-based notification/email systems. The examples and screenshots are all oriented around Microsoft and Windows-centric environments, with no Linux parity.
Recommendations:
  • Include examples of playbooks that interact with Linux-based systems, such as blocking an IP using iptables/nftables or disabling a Linux user account.
  • Provide notification playbook templates that use Linux-friendly tools (e.g., sendmail, postfix, or integration with open-source chat platforms like Mattermost or Rocket.Chat).
  • Add cross-platform examples or note how to adapt playbooks for non-Microsoft environments.
  • Mention and provide sample connectors or actions for popular Linux-based security and infrastructure tools (e.g., syslog, fail2ban, Linux firewalls, LDAP).
  • Ensure that Linux and open-source options are presented alongside Microsoft/Windows tools, not just as an afterthought.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows environments, specifically referencing Windows Security Events, Windows event IDs, and Windows-centric connectors. There are no examples or mentions of equivalent Linux audit logs, connectors, or event IDs for RDP or remote login detection. The instructions and prerequisites are exclusively tailored to Windows, with no guidance for Linux systems.
Recommendations:
  • Include information on how to collect and analyze remote login events from Linux systems (e.g., using syslog, auditd, or SSH logs).
  • Provide equivalent event IDs or log types for Linux (such as SSH login events) and describe how to configure connectors for these sources.
  • Add Linux-specific examples and configuration steps alongside Windows instructions.
  • Clarify whether the anomalous login detection feature supports non-Windows platforms, and if not, note this limitation explicitly.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias in several ways. Windows log collection is discussed before Linux, with more detailed and varied solutions (e.g., Windows Event Forwarding, PowerShell, ARM templates) and specific references to Windows tools and patterns. Some solutions (like PowerShell and Windows Event Forwarding) are mentioned without Linux equivalents or are presented as default approaches. Linux solutions are grouped together and sometimes lack the same level of detail or practical examples. In some cases, Windows-specific tools (e.g., PowerShell) are suggested without mentioning Linux alternatives, and the documentation often lists Windows methods before Linux ones, even in cross-platform sections.
Recommendations:
  • Ensure Linux and Windows sections are given equal prominence and detail, possibly by interleaving examples or providing parallel solution tables.
  • When mentioning Windows-specific tools (e.g., PowerShell, Windows Event Forwarding), also mention Linux equivalents (e.g., Bash scripts, Syslog forwarding) in the same context.
  • Provide Linux command-line examples (e.g., Bash, systemd, rsyslog configuration) wherever PowerShell or Windows commands are given.
  • Avoid presenting Windows solutions first by default; alternate the order or present both platforms together where possible.
  • Expand Linux solution details to match the depth provided for Windows, including practical configuration steps and considerations.
  • Review endpoint and cloud platform sections to ensure Linux-native tools and patterns are included and described with parity.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates a Windows bias in the section 'Use data collection rules for your Windows Security Events', where only Windows-specific data collection (Windows Security Events connector) is discussed in detail. There are no equivalent examples or guidance for Linux data collection, connectors, or cost optimization strategies, despite Linux being a common platform in cloud environments. The focus on Windows tools and the absence of Linux parity in examples and recommendations may leave Linux users underserved.
Recommendations:
  • Add a parallel section describing data collection rules and connectors for Linux security events, such as using the Linux Syslog connector or the Azure Monitor Agent on Linux.
  • Provide examples and cost optimization tips for Linux data sources, including how to filter or reduce ingestion from Linux logs.
  • Mention Linux alongside Windows in relevant sections to ensure parity and inclusivity.
  • Link to documentation on configuring data collection for Linux systems in Microsoft Sentinel.
  • Review other sections for implicit Windows-first assumptions and ensure cross-platform guidance is provided where applicable.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by focusing on Windows-specific data sources (e.g., Windows file share access logs), referencing Windows Security Events, and omitting equivalent Linux log sources or examples. The only log example provided is for Windows (Event ID 5140), and there are no instructions or templates for Linux audit logs or other non-Windows environments. Additionally, the documentation does not mention or provide examples for exporting or processing Linux-based logs, nor does it discuss Linux-specific tools or patterns.
Recommendations:
  • Add examples and templates for Linux log sources, such as auditd or syslog, alongside the existing Windows examples.
  • Include instructions for exporting Linux logs to Azure Blob Storage or Event Hub, possibly using common Linux tools (e.g., rsyslog, logrotate, or custom scripts).
  • Provide sample data formats and notebooks for Linux-based security events, ensuring parity with the Windows-focused Anomalous Resource Access example.
  • Mention both Windows and Linux log types in introductory and walkthrough sections to make it clear that the platform supports both.
  • Where possible, generalize language to refer to 'operating system logs' or 'security events' rather than only Windows-specific terms.

Page-Level Analysis

Missing Linux Example Windows First
Summary:
The documentation does not provide explicit examples or instructions for either Windows or Linux, but it also does not mention Linux at all, nor does it clarify whether the connectors or eStreamer client can be run on Linux systems. The absence of Linux-specific guidance or parity in examples may lead to confusion for Linux users, especially since syslog and CEF are commonly associated with Linux environments.
Recommendations:
  • Explicitly state the supported operating systems (Windows, Linux) for each connector and the eStreamer client.
  • Provide installation and configuration examples for both Windows and Linux environments, especially for the CEF via AMA connector and the eStreamer client.
  • If the connectors or tools are cross-platform, clarify any OS-specific steps or requirements.
  • Include links to Linux-specific documentation or troubleshooting guides where relevant.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a bias toward Windows environments by referencing PowerShell deployment scripts as the mechanism for custom deployment options, without mentioning or providing alternatives for Linux or cross-platform scripting. There are no examples or guidance for using Bash, shell scripts, or other Linux-native tools. The documentation assumes the use of PowerShell in automation pipelines, which may not be suitable for Linux-first or cross-platform teams.
Recommendations:
  • Provide equivalent Bash or shell script examples for deployment customization, alongside PowerShell.
  • Explicitly mention that deployment scripts can be implemented in other languages or shells, and provide guidance or references for Linux users.
  • Clarify whether the provided PowerShell scripts are compatible with PowerShell Core (pwsh) on Linux/macOS, and if not, offer alternatives.
  • Include notes or sections on running repository deployment workflows in Linux-based CI/CD environments (e.g., GitHub Actions runners on Ubuntu, Azure Pipelines with Linux agents).
  • Avoid assuming PowerShell as the default automation tool; instead, present it as one option among several cross-platform choices.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing Windows event logs, Windows endpoints, and Windows-specific tools (such as the Azure Monitor Agent for Windows). There are no examples or instructions for Linux-based Azure Virtual Desktop environments, nor are Linux equivalents or cross-platform considerations mentioned.
Recommendations:
  • Include guidance for monitoring Linux-based virtual desktops if supported, or explicitly state if only Windows is supported.
  • Provide examples or references for collecting logs and security data from Linux environments, using Linux-compatible agents or tools.
  • Mention cross-platform capabilities and limitations where applicable, to clarify the scope for users on non-Windows platforms.
  • If Linux is not supported for Azure Virtual Desktop, add a clear note to inform users and avoid ambiguity.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation is heavily focused on Microsoft cloud services and tools (e.g., Dataverse, Power Platform, SharePoint, Microsoft Entra, Office 365, Microsoft Sentinel, Microsoft Teams, Outlook), with all examples, playbooks, and integrations referencing Microsoft-centric or Windows ecosystem products. There are no references to Linux, Linux-based tools, or cross-platform command-line examples. No PowerShell or CMD examples are present, but the entire workflow assumes use of Microsoft cloud and endpoint infrastructure, which is typically Windows-centric. There is a lack of parity for organizations or analysts operating in Linux environments.
Recommendations:
  • Add explicit notes on cross-platform compatibility for Microsoft Sentinel and Power Platform analytics, including any Linux support or limitations.
  • Provide examples or guidance for integrating non-Windows endpoints (e.g., Linux servers, macOS devices) with Microsoft Sentinel, especially for USB exfiltration or device monitoring scenarios.
  • Include references or links to Linux-based tools or agents that can send relevant logs (e.g., syslog, auditd) to Microsoft Sentinel, and describe how to configure these.
  • Clarify if any playbooks or automations can be triggered or executed from non-Windows environments, and provide examples if possible.
  • Where possible, mention open standards or APIs that can be used from any OS, not just Microsoft tools.
  • If certain features are Windows-only, explicitly state this to set expectations for Linux users.

Page-Level Analysis

Windows First Windows Terms Windows Examples
Summary:
The documentation exhibits mild Windows bias, primarily through the use of Windows-centric terminology (e.g., 'NTDomain', 'Windows domain'), and by listing Windows-style file paths (e.g., 'C:\ProgramFiles\WindowsNT\Accessories\wordpad.exe') before Linux equivalents in examples. Several field descriptions reference Windows-specific concepts before or instead of Linux/UNIX equivalents, though some UNIX references are present. There are no PowerShell-specific examples or exclusive Windows tool mentions, but the ordering and terminology favor Windows environments.
Recommendations:
  • When providing examples (such as file paths), alternate the order or give Linux/UNIX examples first in some cases to balance representation.
  • For fields like 'deviceNtDomain' and 'dntdom', clarify that these are Windows-specific and, where possible, mention the Linux/UNIX equivalent or note when not applicable.
  • In field descriptions, ensure that both Windows and Linux/UNIX terminology are used equally (e.g., for process names, domains, and file paths).
  • Consider adding a brief section or note explaining how the mapping applies to both Windows and Linux/UNIX sources, and highlight any differences.
  • Review all examples and field descriptions to ensure Linux/UNIX environments are equally represented and not treated as secondary.

Page-Level Analysis

Powershell Heavy Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by prioritizing PowerShell-based deployment instructions, referencing Windows-centric tools and patterns (such as PowerShell and ARM templates), and omitting explicit Linux or cross-platform CLI examples. The Python deployment instructions require Visual Studio Code, which, while cross-platform, is not the default or most common development environment on Linux. There are no examples using Azure CLI, Bash, or other Linux-native tools, and the PowerShell manual deployment is described before the Python method.
Recommendations:
  • Add explicit Linux/Bash/Azure CLI examples for deploying and managing Azure Functions-based connectors.
  • Include instructions for deploying Python-based connectors using the Azure CLI or other Linux-native tools, not just Visual Studio Code.
  • Present deployment options in a neutral order or explicitly state that all methods are cross-platform where applicable.
  • Reference cross-platform tools (e.g., Azure CLI, REST API) alongside or before Windows/PowerShell-specific tools.
  • Clarify that PowerShell Core is cross-platform, but provide equivalent Bash or shell script examples for Linux users.
  • Add a section or callout for Linux/macOS users to ensure parity and inclusivity.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by prioritizing Windows and Microsoft-centric services and tools in examples and references. It specifically highlights connecting to Azure, Windows, Microsoft, and Amazon services, but does not mention Linux or non-Windows data sources or provide Linux-specific configuration examples. There are no references to Linux tools, syslog, or Linux-based data connector scenarios, and all screenshots and navigation paths are focused on Microsoft portals.
Recommendations:
  • Include explicit examples and instructions for connecting Linux-based data sources (e.g., syslog, Linux servers, or open-source security tools) to Microsoft Sentinel.
  • Add references and links to documentation for Linux data connectors, such as those for Syslog, CEF, or custom log ingestion from Linux systems.
  • Balance the mention of Windows and Linux by providing parallel configuration steps or navigation paths for both environments.
  • In the 'Connect Microsoft Sentinel to...' section, mention Linux and open-source services alongside Windows and Microsoft services.
  • Add screenshots or command-line examples relevant to Linux environments, such as using Bash or SSH, where appropriate.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation references PowerShell as the only CLI automation method for pushing rules to Microsoft Sentinel, with no mention of Linux-compatible alternatives (such as Azure CLI, Bash, or cross-platform scripting). There are no examples or instructions for Linux users, and the only automation tool explicitly mentioned is PowerShell, which is traditionally associated with Windows environments.
Recommendations:
  • Include examples using Azure CLI or REST API with curl to demonstrate cross-platform automation.
  • Explicitly mention that PowerShell Core is available on Linux and provide Linux-specific usage notes if PowerShell is required.
  • Add Bash or shell script examples for exporting/enabling rules, or clarify if such workflows are not supported.
  • Ensure that all automation and scripting guidance is platform-neutral or provides parity for both Windows and Linux users.

Page-Level Analysis

Powershell Heavy Windows First Missing Linux Example Windows Tools
Summary:
The documentation exhibits a Windows bias by recommending and providing only PowerShell-based automation for setup, requiring PowerShell installation even for cross-platform tasks, and not mentioning or providing equivalent instructions or scripts for Linux or macOS users. All command-line examples and automation are centered on PowerShell, with no Bash, shell, or Linux-native alternatives. The prerequisite section lists PowerShell before AWS CLI, and the automation script is described as being run from a PowerShell command line, with no mention of Linux shells or terminals.
Recommendations:
  • Provide Bash or shell script equivalents for the PowerShell automation, or clarify if the provided PowerShell scripts are cross-platform (PowerShell Core) and can be run on Linux/macOS.
  • Explicitly mention Linux and macOS support in the prerequisites and setup instructions, including installation links for PowerShell Core on those platforms if required.
  • Include command-line examples for Linux/macOS users, or at least clarify the steps for running the automation scripts in those environments.
  • If the automation script is Windows-only, provide a manual or alternative automated setup path for Linux/macOS users.
  • Reorder prerequisites and instructions to avoid always listing Windows/PowerShell first; consider a platform-neutral or parallel structure.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
While the documentation claims support for both Windows and Linux, there is a subtle Windows bias. Windows terminology (e.g., PowerShell) is often mentioned first, and explicit step-by-step examples or scripts for Windows (such as PowerShell installation) are referenced, while equivalent Linux command-line examples are less prominent or missing. The Linux-specific setup is mostly relegated to the log forwarder scenario, and there are no detailed Linux installation or configuration walkthroughs for the agent itself. In several places, Windows tools or patterns are mentioned before Linux equivalents.
Recommendations:
  • Provide explicit Linux command-line examples (e.g., shell commands for installing the Azure Monitor Agent on Linux, not just PowerShell for Windows).
  • Ensure that for every Windows example or tool mentioned (such as PowerShell), an equivalent Linux example (such as Bash or shell commands) is provided and given equal prominence.
  • In lists or instructions, alternate the order or present both Windows and Linux options side by side, rather than defaulting to Windows-first.
  • Add screenshots or walkthroughs of the Linux experience where applicable (e.g., installing the agent, configuring data collection rules via CLI on Linux).
  • Clarify in each section whether the instructions apply to both Windows and Linux, and avoid assuming Windows as the default environment.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation exclusively references Microsoft portals (Azure portal, Defender portal) and GUI-based workflows, which are inherently Windows-centric. There are no command-line examples (such as PowerShell or CLI), but also no mention of Linux tools, command-line interfaces, or cross-platform automation. The documentation assumes users interact with Microsoft Sentinel through web portals, which are most commonly accessed from Windows environments. There are no Linux-specific instructions or parity examples.
Recommendations:
  • Add instructions or examples for enabling the data connector using cross-platform tools such as Azure CLI or REST API, which can be run on Linux, macOS, and Windows.
  • Explicitly mention that the portals can be accessed from any OS with a supported browser, to clarify cross-platform compatibility.
  • If automation is possible, provide sample scripts in both PowerShell and Bash (or Python), showing how to enable the connector programmatically.
  • Include troubleshooting or verification steps that can be performed from Linux environments, such as querying logs using Azure CLI.
  • Where screenshots or UI steps are shown, consider providing CLI equivalents or links to relevant API documentation.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates a Windows-first bias by referencing Windows-specific guidance before Linux equivalents and omitting detailed Linux onboarding instructions. The only explicit installation reference is for Windows, while Linux is only mentioned in the context of troubleshooting, not onboarding. This may make it harder for Linux users to follow the onboarding process.
Recommendations:
  • Provide explicit, step-by-step onboarding instructions for Linux virtual machines, paralleling the Windows guidance.
  • Include direct links to both Windows and Linux agent installation/configuration documentation in the onboarding steps, not just in troubleshooting.
  • Ensure that examples and references to VM creation, extension installation, and agent configuration are presented for both Windows and Linux, ideally side-by-side or in parallel sections.
  • Avoid placing Windows instructions or links before Linux equivalents unless there is a clear technical reason.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a bias toward Windows environments by exclusively referencing Microsoft-centric tools (Azure portal, Microsoft Sentinel, Office Management API, Kusto Query Language) and workflows. There are no examples or instructions for Linux users, nor is there any mention of cross-platform command-line alternatives or compatibility considerations for non-Windows environments.
Recommendations:
  • Include explicit statements about platform compatibility (e.g., whether the Azure portal and Microsoft Sentinel can be accessed and configured from Linux systems or via cross-platform CLI tools).
  • Provide examples using the Azure CLI or PowerShell Core (which is cross-platform), and clarify if these steps can be performed from Linux or macOS.
  • Mention any Linux-specific considerations, such as required dependencies or differences in accessing the Azure portal or Microsoft 365 services.
  • If all steps are web-based and platform-agnostic, explicitly state this to reassure non-Windows users.
  • Add troubleshooting or FAQ sections for users on Linux or macOS, especially if there are known limitations or workarounds.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows environments, specifically Windows DNS servers. All examples, prerequisites, and configuration steps are tailored exclusively to Windows Server, with no mention of Linux-based DNS servers or how to achieve similar functionality on Linux. Windows tools, logs, and event types are referenced throughout, and there are no Linux equivalents or cross-platform guidance provided.
Recommendations:
  • Add equivalent instructions and examples for collecting and filtering DNS logs from Linux-based DNS servers (e.g., BIND, Unbound, dnsmasq).
  • Include prerequisites and setup steps for Linux environments, such as supported distributions, required packages, and log file locations.
  • Provide API and portal configuration examples that reference Linux data sources and illustrate how to normalize and ingest Linux DNS logs.
  • Reference Linux tools and logging patterns (e.g., systemd-journald, syslog, logrotate) alongside Windows event logs.
  • 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.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation is heavily oriented toward Microsoft and Windows-centric environments, referencing tools and concepts such as Active Directory, Windows Defender, and registry events, with no mention of Linux equivalents or guidance for non-Windows environments. There are no examples or instructions for Linux-based systems, nor is there any discussion of cross-platform considerations.
Recommendations:
  • Include explicit guidance or notes for organizations running Linux endpoints, such as how to ingest Linux security events into Sentinel.
  • Provide examples or references for integrating non-Windows data sources (e.g., syslog, auditd, Linux authentication logs) into Microsoft Sentinel.
  • Clarify which features or connectors are Windows-specific and which are cross-platform, and provide parity where possible.
  • Add documentation or links for onboarding Linux servers to Microsoft Defender for Endpoint and how their data appears in Sentinel.
  • Balance event table descriptions by mentioning Linux event types or noting when a table is Windows-only.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a mild Windows bias by referencing the Azure and Defender portals (which are primarily accessed via web browsers on Windows environments) and by not providing any Linux-specific instructions or examples. The only command-line tool mentioned is cURL, which is cross-platform, but there are no PowerShell or Windows-specific tools referenced. However, there are also no Linux-specific examples or guidance, such as using Linux-based TAXII clients or command-line integration patterns. The documentation assumes use of the Microsoft Sentinel web interface and omits parity for Linux CLI or automation scenarios.
Recommendations:
  • Add examples or references for connecting to TAXII feeds using Linux command-line tools (e.g., using curl, httpie, or open-source TAXII clients like cabby or medallion).
  • Include automation examples for both Windows (PowerShell) and Linux (bash) environments, especially for tasks like querying the discovery endpoint or testing connectivity.
  • Explicitly mention that the steps are platform-agnostic where applicable, or provide notes for Linux users if there are any differences.
  • Reference open-source TAXII clients and libraries that are commonly used on Linux, and provide links or example commands.
  • If screenshots or UI instructions are platform-specific, clarify their applicability or provide Linux desktop equivalents if relevant.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates a Windows bias by providing examples and descriptions that are specific to Windows environments (e.g., referencing Windows event IDs, Active Directory, and NTDomain identifiers) without offering equivalent Linux or cross-platform examples. The entity identifiers and sample queries are tailored to Windows-centric data sources, and there is no mention of Linux audit logs, syslog, or Linux user/group management events. The documentation assumes a Windows/Active Directory environment as the default context for customization, omitting guidance for organizations using Linux-based infrastructure.
Recommendations:
  • Include Linux-specific examples, such as detecting user group changes via Linux audit logs (e.g., /var/log/audit/audit.log) or syslog.
  • Provide sample KQL queries for common Linux security events (e.g., sudo usage, user creation, group membership changes) alongside Windows examples.
  • Expand the list of entity identifiers to include Linux-relevant fields, such as UID, GID, or Linux hostnames.
  • Mention Linux data sources (e.g., Syslog, Linux auditd) in the activity template and configuration sections.
  • Balance the documentation by presenting both Windows and Linux scenarios, or explicitly state if the feature is currently Windows-only.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page is largely platform-neutral in its core instructions, focusing on the Microsoft Sentinel UI in the Azure and Defender portals. However, in the 'Next steps' section, automation and scripting are only referenced via PowerShell and API, with no mention of Linux-native tools or CLI alternatives. There are no Linux shell (bash/CLI/az CLI) examples or references, and PowerShell is the only scripting tool explicitly linked. This creates a subtle Windows bias, especially for users seeking automation or scripting guidance from Linux environments.
Recommendations:
  • Provide equivalent automation instructions and examples using Azure CLI (az) and/or bash scripts, not just PowerShell.
  • When referencing scripting or automation, mention both PowerShell and cross-platform tools (e.g., az CLI, REST API with curl, Python SDK).
  • Include explicit notes or examples for Linux/macOS users, especially in sections about exporting/importing rules, automation, and scripting.
  • Where possible, link to documentation or guides for using Microsoft Sentinel with Linux-native tools.
  • Avoid implying PowerShell is the only or primary automation method; present it alongside other cross-platform options.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy
Summary:
The documentation demonstrates a mild Windows bias. File path examples consistently mention Windows paths (e.g., 'c:\temp') before Linux equivalents ('/tmp'), and the sample output file names use Windows-style paths as the primary example. Configuration examples and instructions often default to Windows conventions. There is also a reference to retrieving tenant IDs via the Microsoft Entra ID portal, which is a GUI-centric (and often Windows-used) approach, with no mention of CLI alternatives. However, Linux is not entirely neglected: Linux paths and commands (such as logger) are included, and there is a troubleshooting note for Ubuntu Docker images. There are no PowerShell-specific commands, but the overall pattern is to mention Windows first and more prominently.
Recommendations:
  • Present Linux and Windows examples side by side, or alternate which OS is presented first in examples.
  • When giving file path examples, use both Windows and Linux formats together (e.g., 'c:\temp' (Windows) and '/tmp' (Linux)), or use OS-agnostic placeholders.
  • For instructions that reference the Azure portal for information retrieval, also provide CLI-based alternatives (e.g., using Azure CLI or Bash commands) to support headless and Linux-first workflows.
  • Ensure that all code snippets and configuration examples are equally applicable to both Windows and Linux environments, and explicitly state any OS-specific differences.
  • Add a section or callout summarizing cross-platform compatibility and any known OS-specific caveats.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation page demonstrates a mild Windows bias by listing Windows-based data sources and connectors (such as 'Windows Security Events via AMA' and 'Windows Forwarded Events') before Linux equivalents in the data connector table. Additionally, the only explicit OS-specific links in the connector table point to Windows-based documentation (e.g., 'connect-services-windows-based.md'), while Linux or cross-platform connectors (such as Syslog or CEF) are not given equal prominence or dedicated links. There are no explicit Linux command-line or tool examples, and no mention of Linux-specific ingestion scenarios or tools.
Recommendations:
  • Provide equal prominence to Linux-based data sources and connectors (e.g., Syslog, Linux audit logs) in tables and lists, including dedicated documentation links where available.
  • Include explicit examples or references for Linux ingestion scenarios, such as configuring data collection from Linux servers using the Azure Monitor Agent.
  • Avoid listing Windows connectors or tools before Linux equivalents; instead, group by function or provide parallel examples for both platforms.
  • Where possible, add cross-platform or Linux-specific sample scenarios and walkthroughs, ensuring Linux users can follow along without ambiguity.
  • Review connector documentation links to ensure both Windows and Linux ingestion paths are equally discoverable.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is exclusively focused on Windows DNS servers and the Windows DNS Events via AMA connector. All examples, field mappings, and descriptions refer only to Windows environments and tools, with no mention of Linux-based DNS servers, Linux logging mechanisms, or cross-platform applicability. The documentation assumes a Windows context throughout, omitting Linux equivalents or guidance.
Recommendations:
  • Add sections or notes describing support (or lack thereof) for Linux DNS servers and clarify if the AMA connector can be used with Linux-based DNS logs.
  • Provide equivalent field mapping tables and filtering examples for common Linux DNS servers (e.g., BIND, Unbound, dnsmasq) if supported.
  • If Linux is not supported, explicitly state this early in the documentation to set user expectations.
  • Include references or links to documentation covering DNS log ingestion from Linux servers, if available.
  • Ensure future updates consider parity between Windows and Linux environments, especially for cross-platform products like Microsoft Sentinel.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not display overt Windows bias in terms of mentioning Windows-specific tools, PowerShell, or Windows-first ordering. However, it is implicitly biased toward web-based and Microsoft portal workflows, with no mention of Linux or cross-platform command-line alternatives. There are no examples or instructions for Linux users, such as using Azure CLI, REST APIs, or other non-GUI methods, which may be preferred or required in Linux environments.
Recommendations:
  • Add equivalent instructions for deploying and configuring the solution using Azure CLI and/or REST API, which are cross-platform and commonly used in Linux environments.
  • Where possible, provide command-line examples (e.g., for app registration, secret creation, or data connector configuration) alongside portal-based instructions.
  • Explicitly state that all steps can be performed from any OS with a supported browser, or clarify any OS-specific requirements.
  • Include troubleshooting or verification steps that use cross-platform tools (e.g., Azure CLI, Kusto Query Language via CLI) rather than only GUI screenshots.
  • If any step requires a Windows-only tool or interface, note this clearly and suggest alternatives for Linux users.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by focusing on Windows-specific tools and technologies such as PowerShell and WMI, referencing them in detection scenarios without mentioning Linux or cross-platform equivalents. Examples and threat detections are described in terms of Windows-centric activities (e.g., PowerShell command execution, WMI, Microsoft Defender for Endpoint), and there are no Linux-specific examples or references to Linux-native tools or attack patterns. The documentation assumes a Windows environment for endpoint detection and response, with no guidance for Linux-based systems.
Recommendations:
  • Include examples and detection scenarios that reference Linux-based attack techniques and tools (e.g., bash scripts, cron jobs, SSH abuse, Linux credential dumping tools like 'gsecdump' or 'LaZagne').
  • When describing suspicious command execution, provide Linux equivalents alongside PowerShell and WMI (e.g., bash, python, perl, systemd misuse).
  • Reference cross-platform endpoint detection tools and data sources, such as Microsoft Defender for Endpoint for Linux, and clarify how these scenarios apply to Linux systems.
  • Add detection scenarios for Linux-specific threats (e.g., rootkit installation, unauthorized use of sudo, suspicious use of system binaries).
  • Balance the order of presentation so that Windows and Linux examples are given equal prominence, or explicitly state when a scenario is Windows-only.
  • Where possible, generalize descriptions of suspicious activity (e.g., 'suspicious script execution') and then provide both Windows and Linux examples.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First
Summary:
The documentation demonstrates a moderate Windows bias. Several detection scenarios and examples reference Windows-specific tools and technologies, such as PowerShell and Windows event logs, without providing Linux or cross-platform equivalents. The ransomware detection example lists only Windows malware and Windows event sources. Scenario descriptions highlight PowerShell and WMI (both Windows-centric) as suspicious activity vectors, and 'Windows Error and Warning Events' are used as an example alert source. There are no explicit Linux or Unix examples, nor are Linux-specific tools or attack patterns discussed. While the documentation is focused on Microsoft Sentinel (which is itself a Microsoft/Azure product), the lack of Linux parity in examples and scenario coverage may limit its usefulness for organizations with heterogeneous environments.
Recommendations:
  • Include Linux-specific detection scenarios, such as suspicious Bash or shell script execution, anomalous sudo activity, or Linux-specific malware/ransomware alerts.
  • Provide examples of alerts generated from Linux event sources (e.g., syslog, auditd, or Linux security logs) alongside Windows event examples.
  • When referencing suspicious command-line activity, include both PowerShell (Windows) and Bash (Linux) examples.
  • Highlight support for cross-platform data connectors and analytics rules, and clarify how Fusion handles signals from Linux-based systems.
  • In scenario tables and examples, balance Windows and Linux sources/tools to reflect real-world, mixed-environment deployments.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by prioritizing Windows agents and tools in several connector descriptions, particularly for Microsoft Exchange and Security Events connectors, where only Windows machines and agents are mentioned explicitly. Linux equivalents are either omitted or only briefly referenced (e.g., Syslog via Legacy Agent is listed, but not cross-referenced in Windows-centric sections). There is a lack of Linux-specific examples or parity in prerequisites and instructions, especially for connectors that could apply to both platforms.
Recommendations:
  • For connectors that mention Windows agents or tools (e.g., Microsoft Exchange Logs and Events, Security Events via Legacy Agent), explicitly state if Linux equivalents exist and provide parallel instructions/examples for Linux where applicable.
  • Where agent installation is discussed, include both Windows and Linux agent installation procedures and links, not just Windows or PowerShell-focused tabs.
  • Cross-reference the Syslog (Linux) connector in sections that discuss Windows event collection to highlight Linux support.
  • Ensure that all prerequisites and setup steps are platform-neutral or provide both Windows and Linux variants where possible.
  • Review all connector documentation for implicit Windows-first language and update to reflect equal support for Linux where available.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation exhibits a Windows bias in several areas. Many connectors and examples, especially those related to Microsoft Exchange, Active Directory, IIS, and DNS, are described exclusively in the context of Windows servers and Windows agents. Instructions and prerequisites often reference 'Windows machines', 'Windows agent', or 'Windows Event logs' without mentioning Linux equivalents or providing parallel Linux instructions. In some cases, only Windows-specific tools or logging mechanisms (e.g., Windows Firewall, Windows Event Forwarding) are discussed, and Linux alternatives (such as Syslog or Linux firewalls) are either omitted or only briefly mentioned. This creates an impression that Windows is the primary or default platform for these integrations, with Linux support being secondary or absent.
Recommendations:
  • For every connector or example that references Windows-specific tools (e.g., Windows Event logs, Windows Firewall, IIS), provide equivalent Linux examples (e.g., Syslog, iptables/ufw, Apache/Nginx logs) where applicable.
  • Where instructions mention 'Windows machines' or 'Windows agent', clarify if and how Linux machines are supported, and provide explicit Linux setup steps if available.
  • For connectors that support both Windows and Linux (such as 'Custom logs via AMA' or 'Syslog via AMA'), ensure that Linux is mentioned equally and that Linux-specific guidance is as detailed as the Windows guidance.
  • If certain features are Windows-only, explicitly state this and, if possible, suggest alternative approaches for Linux users.
  • Review the ordering of examples and documentation sections to avoid always listing Windows first; alternate or group by platform where appropriate.
  • Encourage contributors to include Linux prerequisites, commands, and troubleshooting steps alongside Windows content.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation provides only a PowerShell script example for running the prerequisite checker, which is specific to Windows environments. There are no equivalent examples or instructions for Linux or cross-platform command-line tools (such as Bash, curl, or Python). The exclusive use of PowerShell and Windows-centric tooling may hinder users on Linux or macOS from following the instructions directly.
Recommendations:
  • Provide equivalent Bash or shell script examples using curl or wget for Linux/macOS users.
  • Explicitly mention that the PowerShell script is for Windows and offer alternative instructions for other platforms.
  • Where possible, use cross-platform tools or languages (e.g., Python, curl) in examples.
  • Add a section or note clarifying platform compatibility and linking to platform-specific guidance if available.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation references a PowerShell cmdlet (Unlock-SPOSensitivityLabelEncryptedFile) as the only command-line tool for interacting with sensitivity labels, without providing equivalent Linux or cross-platform alternatives. There are no Linux shell or CLI examples, and the documentation implicitly assumes a Windows/PowerShell environment for administrative tasks.
Recommendations:
  • Provide equivalent CLI examples using cross-platform tools such as Azure CLI, Microsoft Graph API, or REST API calls that can be executed from Linux/macOS environments.
  • Explicitly mention whether the referenced PowerShell cmdlet is available via PowerShell Core (pwsh) on Linux/macOS, or provide guidance for Linux users.
  • Add a section or note addressing how Linux or non-Windows users can perform the same operations, or clarify if certain actions are Windows-only.
  • Where possible, use platform-agnostic language and tools in examples to ensure parity for all users.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a Windows bias by recommending tools (LightIngest) that are Windows-only, not providing Linux alternatives or examples, and generally assuming a Windows environment for ingestion tasks. While AzCopy is cross-platform, the documentation does not clarify or provide Linux-specific usage instructions. There are no Linux command-line examples or explicit mentions of Linux-compatible ingestion workflows.
Recommendations:
  • For LightIngest, explicitly state that it is Windows-only and suggest alternative ingestion methods for Linux environments, such as using Azure Data Explorer's ingestion REST API, Azure CLI, or Python SDK.
  • For AzCopy, include explicit Linux installation and usage instructions, with example commands for Linux shells.
  • Wherever scripts or tools are referenced, clarify their OS compatibility and provide parallel instructions or links for both Windows and Linux users.
  • Add a section or callout addressing Linux users, summarizing supported ingestion tools and methods for non-Windows environments.
  • Ensure that all code snippets and instructions are provided for both PowerShell/Windows CMD and Bash/Linux shells where applicable.

Page-Level Analysis

Powershell Heavy Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows bias in several areas: PowerShell scripts are the primary or only example given for Azure Monitor ingestion, and the SIEM data migration accelerator deploys a Windows VM by default. While some tools (like AzCopy and Logstash) are cross-platform, the documentation emphasizes Windows-centric tools and patterns, often mentioning Windows or PowerShell before Linux alternatives. There is a lack of explicit Linux/bash examples or guidance, especially for key migration scenarios.
Recommendations:
  • Provide equivalent bash or shell script examples for ingestion tasks, especially for Azure Monitor custom log ingestion.
  • Explicitly mention and demonstrate how to use cross-platform tools (like AzCopy, Logstash) on Linux, including installation and usage examples.
  • For the SIEM data migration accelerator, offer an option to deploy a Linux VM or container, or clarify how to run the migration tools on Linux.
  • Avoid defaulting to PowerShell in examples; where PowerShell is shown, also provide a Linux-compatible alternative (e.g., Python, bash, or REST API via curl).
  • In tool tables and descriptions, indicate OS compatibility and avoid listing Windows tools first unless there is a technical reason.
  • Highlight any limitations or differences in tool behavior between Windows and Linux, and provide workarounds if necessary.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation refers to 'open a command prompt' and 'download the results or returned data from the JSON file to a folder on the current system' without specifying the operating system, but the phrase 'command prompt' is commonly associated with Windows. No explicit Linux or macOS terminal instructions or examples are provided, and there is no mention of shell differences, file path conventions, or environment-specific considerations. All command-line examples use curl, which is cross-platform, but the lack of Linux/macOS context or terminology suggests a subtle Windows-first bias.
Recommendations:
  • Replace or supplement 'open a command prompt' with 'open a terminal or command prompt', and clarify that the instructions apply to Windows, Linux, and macOS.
  • Provide explicit examples or notes for running the curl commands on Linux/macOS terminals, including any differences in authentication or file path syntax.
  • Mention that curl is available by default on most Linux/macOS systems, but may need to be installed separately on Windows.
  • Add screenshots or references to both Windows and Linux/macOS environments to reinforce cross-platform applicability.
  • Where file paths are referenced (e.g., <enter_path_to_file>.json), clarify the syntax for both Windows (C:\path\to\file.json) and Linux/macOS (/path/to/file.json).

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by exclusively using Windows-centric data sources (e.g., SecurityEvent table, which is populated by Windows Security Events), focusing on Windows event IDs, and not providing equivalent Linux or cross-platform examples. All KQL examples reference Windows-specific logs and fields, and there is no mention of Linux data sources, event types, or how to migrate Linux-based ArcSight rules. The documentation assumes the use of the Azure Monitoring Agent (AMA) for Windows Security Events and does not address Linux log collection or rule migration scenarios.
Recommendations:
  • Include examples using Linux data sources, such as Syslog, CommonSecurityLog, or custom tables populated from Linux servers.
  • Provide KQL queries that demonstrate how to migrate ArcSight rules for Linux event types (e.g., authentication, sudo, SSH, process creation).
  • Mention and link to documentation on connecting Linux data sources to Microsoft Sentinel, including configuration steps for the AMA or Log Analytics agent on Linux.
  • Balance the presentation order by alternating or pairing Windows and Linux examples, or by providing a cross-platform example where possible.
  • Clarify in the introduction that the guidance applies to both Windows and Linux environments, and explicitly call out any differences or additional steps required for Linux.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a mild Windows bias by referencing Windows-specific data sources (such as the SecurityEvent table from Windows) as the primary example in sample queries, and by mentioning Windows-centric tools and terminology before their cross-platform or Linux equivalents. There are no Linux-specific examples or explicit mention of Linux data sources, and the documentation does not provide parity in illustrating how Linux-based logs or events can be visualized in workbooks.
Recommendations:
  • Include sample queries that use Linux data sources (e.g., Syslog, LinuxAuditLog) alongside or instead of Windows SecurityEvent.
  • When providing examples, alternate between Windows and Linux sources, or provide both to ensure parity.
  • Explicitly mention that workbooks can visualize data from both Windows and Linux sources, and provide guidance or links for Linux log integration.
  • Add screenshots or walkthroughs that show Linux data sources being selected and visualized in workbooks.
  • Review terminology to ensure that Windows-specific terms are not presented as the default or only option.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by providing detailed normalization examples and mappings exclusively for Windows event 4624, referencing Windows-specific concepts (such as SIDs and Windows usernames) before or instead of Linux equivalents. While Linux user IDs (UID) are mentioned in field type tables, there are no concrete Linux event examples or mappings, and Windows-centric terminology and tools (e.g., Windows event fields, SIDs, Windows domain\username format) are prioritized throughout. Linux tools, event types, or normalization scenarios are not given parity in examples or guidance.
Recommendations:
  • Add parallel Linux event normalization examples (e.g., mapping a Linux authentication log event to ASIM fields) alongside the Windows event 4624 example.
  • Include Linux-specific field mapping tables and sample values (e.g., mapping /var/log/auth.log fields, Linux UIDs, and usernames).
  • Reference Linux event types and tools (such as auditd, syslog, or journald) in schema mapping and normalization guidance.
  • Ensure that field type tables and entity descriptions provide Linux examples with equal prominence to Windows examples.
  • Where possible, provide cross-platform comparison tables or diagrams to illustrate normalization from both Windows and Linux sources.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First
Summary:
The documentation page demonstrates a Windows bias in several ways: many of the analytic rules and hunting queries focus on Windows-specific tools, processes, and attack techniques (e.g., rundll32.exe, PowerShell, Certutil, Exchange PowerShell Snapin, Windows System Shutdown/Reboot). There is a notable emphasis on PowerShell-based attacks and Windows-native binaries (LOLBins), with little to no mention of Linux-specific equivalents or examples. The process activity and hunting queries sections are particularly Windows-centric, and Linux tools, commands, or attack patterns are not represented. This creates an impression that the content is primarily relevant to Windows environments.
Recommendations:
  • Add Linux-specific analytic rules and hunting queries, such as detection for common Linux persistence techniques, suspicious use of bash, cron jobs, or systemd services.
  • Include examples of Linux-native attack tools (e.g., bash scripts, python reverse shells, netcat, SSH abuse) alongside Windows tools.
  • Balance the coverage of Windows and Linux by providing parity in detection rules for both platforms (e.g., detect suspicious sudo usage, unauthorized changes to /etc/passwd, or Linux-specific malware).
  • Explicitly mention cross-platform applicability where possible, and clarify if a rule is Windows-only.
  • Add hunting queries and analytic rules for Linux process activity, file activity, and network events, not just Windows-centric ones.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by providing examples and references that prioritize Windows concepts and tools. For instance, the only concrete event table example is 'WindowsEvent', and original event type/subtype examples are Windows-specific (e.g., Windows event ID 4624, Windows logon type 2). The FQDN example uses the Windows domain\hostname format, and the device hostname example is 'ContosoDc', a typical Windows naming convention. While Linux is mentioned in the vendor/product list, there are no Linux-specific field examples or event references, and Windows-related fields and formats are described first or exclusively.
Recommendations:
  • Add Linux-specific examples alongside Windows ones, such as Linux event IDs, syslog formats, or Linux hostnames.
  • When describing fields like EventOriginalType or EventOriginalSubType, include Linux-originated event examples (e.g., auditd event types, sudo event IDs).
  • In FQDN and hostname examples, provide both Windows and Linux naming conventions (e.g., 'host.example.com' for Linux/Unix).
  • For device fields, use a mix of Windows and Linux hostnames (e.g., 'ContosoDc' and 'webserver01').
  • Ensure that Linux tools and event sources are referenced with equal prominence to Windows equivalents throughout the documentation.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by consistently listing Windows sources, tools, and event types first or in greater detail compared to Linux equivalents. Windows-specific connectors, event IDs, and collection methods are described in depth, while Linux sources are mentioned less frequently and often lack equivalent detail or examples. Windows event collection patterns (e.g., Security Events, Sysmon, WEF) and Microsoft-centric tooling are emphasized, with Linux and cross-platform alternatives sometimes only briefly referenced or omitted.
Recommendations:
  • Ensure Linux and cross-platform sources are given equal prominence in tables and lists, not always after Windows sources.
  • Provide detailed examples and collection patterns for Linux (e.g., Syslog, auditd, Linux Sysmon) equivalent to those given for Windows (event IDs, connectors, etc.).
  • Include Linux-specific event IDs, log types, and connectors in all relevant sections, not just as afterthoughts.
  • Where Windows tools (e.g., WEF, Event Viewer, Security Events) are mentioned, also mention and explain Linux tools (e.g., journalctl, auditd, syslog-ng) and how they integrate with Sentinel.
  • Add explicit Linux usage and deployment examples, including sample log lines, configuration steps, and troubleshooting tips.
  • Review all parser lists to ensure Linux and other non-Windows platforms are represented wherever possible, and not just under generic or Microsoft-centric headings.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation page demonstrates subtle Windows bias primarily through the use of Windows-centric terminology, examples, and field values. Hostname and domain examples (e.g., 'DESKTOP-1282V4D', 'Contoso\DESKTOP-1282V4D') are in Windows format, and fields such as 'ActorUsernameType' use 'Windows' as an example value. Application paths (e.g., 'C:\Windows\System32\svchost.exe') are Windows-specific. There are no equivalent Linux or cross-platform examples, and the documentation does not mention or illustrate Linux/Unix tools, naming conventions, or user/domain formats.
Recommendations:
  • Provide Linux/Unix examples alongside Windows ones, such as using hostnames like 'ubuntu-server', domain formats like 'example.com', and file paths like '/usr/bin/sshd'.
  • When illustrating field values (e.g., ActorUsernameType, TargetFQDN), include both Windows and Linux/Unix representations.
  • Clarify that the schema is platform-agnostic and explicitly mention support for Linux/Unix systems where applicable.
  • Avoid using only Windows-specific application names or paths; include cross-platform or Linux-native applications and services in examples.
  • Where domain or username formats are discussed, show both Windows (DOMAIN\user) and Linux (user@example.com or user@hostname) formats.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias in several ways: field examples and descriptions frequently use Windows-centric paths, tools, and concepts (e.g., C:\Windows\explorer.exe, Registry keys, PsExec), and there are no Linux or cross-platform examples provided. Windows terminology and artifacts are referenced exclusively, and Linux equivalents are not mentioned or illustrated.
Recommendations:
  • Add Linux-based examples alongside Windows ones for fields such as FilePath (e.g., /usr/bin/sshd), ProcessName, and Registry (or note the absence of a Linux equivalent).
  • Include cross-platform or Linux-specific tools (e.g., SSH, systemd, auditd) in rule and threat examples, not just Windows tools like PsExec.
  • Clarify in field descriptions when a concept is Windows-specific (e.g., Registry fields), and suggest how to handle or map similar data from Linux or macOS systems.
  • Provide at least one end-to-end example for a Linux-originating alert event, showing how fields would be populated.
  • Review enumerated values and examples for user and process fields to ensure they are not solely Windows-centric (e.g., include Linux username formats, UIDs, and process paths).

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page exhibits a mild Windows bias. Windows is the only OS mentioned explicitly in introductory and example contexts (e.g., 'Windows sends several authentication events', 'C:\Windows\System32\svchost.exe', 'Windows 10'). Device and field examples use Windows-centric naming conventions (e.g., 'DESKTOP-1282V4D', 'Contoso\DESKTOP-1282V4D'), and protocols like NTLM are referenced without Linux/Unix equivalents. There are no Linux or Unix-specific examples, tools, or field values, and no mention of Linux authentication protocols (e.g., PAM, Kerberos as used in Linux, SSH logins, etc.).
Recommendations:
  • Include Linux/Unix-specific examples alongside Windows ones, such as sample hostnames (e.g., 'ubuntu-server', 'centos7'), file paths (e.g., '/usr/bin/sshd'), and OS names (e.g., 'Ubuntu 22.04').
  • Mention Linux/Unix authentication protocols (e.g., PAM, SSH, Kerberos as used in Linux) in the relevant fields (LogonProtocol, LogonMethod) and provide example values.
  • Balance field value examples to include both Windows and Linux/Unix conventions (e.g., show both 'DOMAIN\user' and 'user@domain' or just 'user').
  • Explicitly state that the schema is intended to normalize authentication events from both Windows and Linux/Unix systems, and provide guidance or links for Linux data sources.
  • Where device types or OS fields are discussed, include Linux/Unix as example values (e.g., 'Windows 10', 'Ubuntu 22.04', 'Red Hat Enterprise Linux 8').

Page-Level Analysis

Windows First Windows Tools Windows Heavy Examples
Summary:
The documentation demonstrates a Windows bias by prioritizing Windows terminology, formats, and examples throughout the schema reference. Windows-specific formats (such as domain\hostname, SID, and Windows DHCP server log quirks) are mentioned before or more prominently than their Linux or open-source equivalents. Several fields and examples focus on Windows environments, and guidance is often tailored to Windows server behavior, with Linux or non-Windows systems only briefly referenced or omitted.
Recommendations:
  • Provide Linux/Unix-specific examples alongside Windows examples for fields like SrcHostname, SrcUserId, and SrcUsername.
  • Discuss Linux DHCP server logging formats and any normalization considerations, not just Windows-specific quirks (e.g., MAC address formatting).
  • When listing possible values or formats (e.g., for SrcDomainType, SrcUsernameType), present Linux/Unix and open-source conventions first or equally, rather than always leading with Windows.
  • Include guidance for parsing and normalizing data from common Linux DHCP servers (such as ISC DHCP, Kea) in addition to Windows DHCP.
  • Balance the documentation by referencing both Windows and Linux tools, patterns, and environments, ensuring parity in detail and prominence.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation is heavily Windows-centric, focusing exclusively on Windows Registry events, terminology, and examples. All field descriptions, examples, and references are specific to Windows (e.g., HKEY_LOCAL_MACHINE, C:\Windows paths, Windows SIDs), with no mention of Linux or cross-platform registry/event equivalents. There are no Linux examples, nor is there discussion of how (or if) similar concepts might apply on Linux or other platforms.
Recommendations:
  • Explicitly state that the schema is Windows-specific, and clarify if there is or is not a Linux equivalent for registry event normalization.
  • If cross-platform support is planned or possible, provide guidance or mapping for Linux (or macOS) equivalents, or explain why such mapping is not applicable.
  • Where possible, include examples or notes about how similar monitoring or normalization would work on Linux systems (e.g., monitoring configuration file changes, dconf/gsettings, or other OS-specific registries).
  • If the schema is intended to be extensible, provide a section on how to handle non-Windows systems or how to extend the schema for other platforms.
  • Avoid assuming Windows-only context in field descriptions (e.g., process paths, SIDs) and clarify when a field is only relevant to Windows.

Page-Level Analysis

Windows Tools Windows Examples Windows First
Summary:
The documentation demonstrates a subtle Windows bias, primarily through the use of Windows-centric terminology, examples, and field values. Several example values and field names reference Windows-specific constructs (such as SIDs, 'C:\' file paths, 'WORKGROUP', 'DESKTOP', and 'Microsoft Hyper-V Network Adapter'), and HTTP user agent strings reference Windows OS versions. There is little to no mention of Linux or Unix equivalents, and Windows patterns are presented as the default or only example.
Recommendations:
  • Include Linux/Unix-specific examples alongside Windows ones, such as file paths ('/var/log/syslog'), device names ('eth0'), and user/group identifiers (UID/GID).
  • When referencing fields like User SID or domain names, clarify applicability to non-Windows environments (e.g., mention UIDs for Linux).
  • Provide sample values for fields like device names, file paths, and domains that reflect both Windows and Linux conventions.
  • Avoid using only Windows-specific terms (e.g., 'WORKGROUP', 'DESKTOP', 'C:\') as examples; alternate or supplement with Linux/Unix equivalents.
  • In the 'Data types and formats' and 'Network sessions table schema' sections, explicitly note cross-platform considerations and differences.
  • For fields such as 'DvcOutboundInterface', which uses 'Ethernet adapter Ethernet 4' as an example, add a Linux-style example like 'eth1' or 'enp0s3'.

Page-Level Analysis

Windows First Windows Tools Windows Heavy Examples
Summary:
The documentation demonstrates a Windows-first bias in several areas. In field descriptions and examples, Windows formats (such as SID, domain\username, and Windows session IDs) are consistently listed before Linux or other equivalents. Windows-specific terminology and examples (e.g., C:\Windows\System32\svchost.exe, Contoso\johndow) are prevalent, while Linux examples are present but less prominent and rarely first. Some field descriptions provide detailed guidance for Windows (such as session ID conversion) without equivalent Linux-specific notes. There are no PowerShell command examples or explicit omission of Linux tools, but the overall pattern prioritizes Windows concepts and formats.
Recommendations:
  • Alternate the order of Windows and Linux examples and formats in field descriptions and tables, or list them alphabetically to avoid implicit prioritization.
  • Provide Linux-specific guidance and notes where Windows-specific advice is given (e.g., for session IDs or process paths).
  • Include more Linux-centric examples (e.g., /usr/bin/sshd for ActingAppName, Linux UIDs and group names) alongside Windows examples.
  • Where normalization is discussed, explicitly mention both Windows and Linux normalization patterns and field names.
  • Ensure that all field types and enumerations include Linux and cross-platform values with equal prominence.
  • Consider adding a section or examples that show how the schema applies to Linux-only environments.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a subtle Windows bias by referencing Windows-specific tools and data sources (e.g., Windows Events, Sysmon, Microsoft Defender for Endpoint) as primary examples when discussing normalized data and analytics. There are no explicit Linux or cross-platform examples, nor are Linux-native tools or event sources mentioned, which may give the impression that ASIM is primarily for Windows environments.
Recommendations:
  • Include explicit examples of Linux event sources (e.g., auditd, syslog, journald) alongside Windows examples when discussing supported data sources and schemas.
  • Mention Linux-native tools and logs (such as Linux audit logs, syslog, or cloud-native sources) in lists and examples to demonstrate cross-platform applicability.
  • Provide sample queries or use cases that involve Linux data sources to illustrate parity.
  • Ensure that when listing supported sources or schemas, both Windows and Linux examples are presented, ideally alternating or grouping by platform rather than defaulting to Windows-first.
  • Add a section or note clarifying ASIM's support for Linux and other non-Windows platforms, including any limitations or special considerations.

Page-Level Analysis

Windows First Windows Tools Powershell Heavy Missing Linux Example
Summary:
The documentation generally maintains parity between Windows and Linux, especially in the section on setting environment variables, where both platforms are given dedicated tabs and step-by-step instructions. However, there are subtle signs of Windows bias: Windows instructions are presented first, and Windows-specific tools (like the System Properties dialog) are described in more detail and with more UI guidance than their Linux equivalents. The Linux instructions assume more technical familiarity (e.g., editing .bashrc with vim/nano), and there is less explanation of the rationale or context for Linux users. In other sections, Windows-style paths (%userprofile%) are mentioned alongside Linux (~), but Windows terminology and patterns (such as referencing the System Properties dialog) are more prominent. There are no PowerShell-specific code examples, but the overall tone and ordering suggest a slight preference for Windows environments.
Recommendations:
  • Alternate the order of Windows and Linux instructions in tabbed sections, or present Linux first in some cases to balance exposure.
  • Provide equal detail and context for Linux instructions, including screenshots or step-by-step UI guidance where appropriate (e.g., using graphical editors or file managers).
  • When mentioning file paths, always provide both Windows and Linux equivalents together, and clarify which is which.
  • Include PowerShell and Bash equivalents for any command-line instructions, or clarify when a command is platform-specific.
  • Add a brief rationale or context for both Windows and Linux users about why certain steps are necessary, not just for Windows.
  • Where possible, use cross-platform language and avoid assuming the user is more familiar with Windows tools or UI.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation assumes the use of Power BI Desktop, which is only available for Windows, and does not mention or provide alternatives for Linux or macOS users. All instructions and screenshots are based on the Windows version of Power BI Desktop, and there is no discussion of cross-platform options or workarounds. The prerequisite to install Power BI Desktop from the Microsoft Store further reinforces a Windows-only workflow.
Recommendations:
  • Acknowledge that Power BI Desktop is only available for Windows and explicitly state this in the prerequisites.
  • Provide guidance or links for Linux/macOS users, such as using Power BI service (web) for report creation where possible, or running Power BI Desktop in a Windows VM or via Wine.
  • If feasible, include steps for exporting data from Microsoft Sentinel and importing it into Power BI using cross-platform tools (e.g., CSV export and import).
  • Mention any limitations or alternative workflows for non-Windows users, and direct them to relevant Microsoft documentation or community solutions.
  • Consider including a table comparing platform support for each step, so users on Linux/macOS can quickly see what is and isn't possible.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by focusing primarily on Microsoft Sentinel usage within Azure and Microsoft Defender portals, both of which are Windows-centric environments. There is a lack of explicit Linux or cross-platform setup instructions or examples, and references to tools and workflows are oriented toward the Microsoft ecosystem. While Linux is mentioned in passing (e.g., 'Linux or Windows hosts'), there are no concrete Linux-specific instructions, examples, or troubleshooting tips. The documentation assumes usage of Azure Machine Learning and does not address local or non-Windows Jupyter environments in detail.
Recommendations:
  • Add explicit instructions and examples for running the notebook in local Jupyter environments on Linux, including installation steps and troubleshooting tips.
  • Provide Linux-specific examples or screenshots where relevant, such as setting up Python environments or configuring MSTICPy on Linux systems.
  • Include parity in tool recommendations (e.g., mention Linux package managers like apt or yum for Python installation alongside Anaconda).
  • Ensure that references to portals or environments clarify cross-platform compatibility and, where possible, provide alternatives for Linux users.
  • Highlight any differences or additional steps required for Linux users, such as file path conventions or permissions.

Page-Level Analysis

Missing Linux Example Windows First
Summary:
The documentation page exclusively describes GUI-based removal of Microsoft Sentinel via the Azure and Defender portals, with no mention of command-line or scripting options. There are no examples or instructions for Linux users (e.g., using Azure CLI, Bash, or cross-platform tools), and the workflow assumes a portal-based (often Windows-centric) approach. The absence of Linux or cross-platform command-line instructions may disadvantage users who prefer or require non-Windows environments.
Recommendations:
  • Add instructions for removing Microsoft Sentinel using Azure CLI, which is cross-platform and works on Linux, macOS, and Windows.
  • Include Bash and PowerShell script examples for automating the removal process.
  • Explicitly mention that the portal-based instructions apply equally to users on any OS, or clarify any OS-specific requirements.
  • Provide links to relevant Azure CLI documentation for resource and workspace management.
  • Ensure that any screenshots or UI references are supplemented with equivalent command-line steps for parity.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by referencing Windows-specific event sources (e.g., 'Microsoft-Windows-Sysmon'), using Windows-centric terminology and examples (such as EventID and the Event table), and recommending PowerShell and Azure Portal for deployment and management tasks. There are no explicit Linux or cross-platform deployment/test examples, and Linux-specific tools or workflows are not mentioned, even though Microsoft Sentinel supports ingesting logs from Linux sources (e.g., Syslog).
Recommendations:
  • Provide equivalent Linux-based examples alongside Windows examples, such as using Linux Syslog event types and fields in KQL queries.
  • Include instructions for deploying and managing parsers using Linux-native tools (e.g., Azure CLI, Bash scripts) in addition to PowerShell.
  • Mention and demonstrate cross-platform or Linux-specific log sources and how to map their fields to ASIM schemas.
  • Clarify that the guidance applies to both Windows and Linux data sources, and highlight any differences or additional steps required for Linux environments.
  • Add sample parser development and deployment workflows for Linux users, including exporting logs, running tests, and submitting contributions from Linux systems.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation repeatedly references 'Windows Security Events' and 'Windows Events' as primary examples of log sources, with no mention of Linux equivalents (such as Linux audit logs or syslog from Linux VMs) in the context of VM log collection. The only mention of syslog is as a network device/on-premises source, not as a core VM workload. The log collection agent (Azure Monitoring Agent, AMA) is discussed only in the context of Windows VMs, with no explicit mention of Linux VM support or examples. This creates a subtle Windows bias, as Linux scenarios are not equally represented.
Recommendations:
  • Explicitly mention Linux VMs as supported sources for log collection, alongside Windows VMs, in all relevant sections.
  • Provide examples of collecting Linux audit logs and syslog from Linux VMs, not just from network devices.
  • When describing the Azure Monitoring Agent (AMA), clarify that it supports both Windows and Linux, and provide example configurations for both platforms.
  • In lists of data sources, include Linux-specific logs (e.g., /var/log/auth.log, /var/log/secure, auditd) where appropriate.
  • Balance the mention/order of Windows and Linux examples to avoid the impression that Windows is the default or only supported platform.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation provides a PowerShell script for automating the rotation of the BTP client secret, but does not offer equivalent examples for Linux environments (e.g., Bash, Azure CLI, or Python). The script relies on PowerShell and Az modules, which are native to Windows and require extra setup on Linux. No alternative Linux-native automation or command-line instructions are provided, and there is no mention of cross-platform compatibility or guidance for Linux users.
Recommendations:
  • Provide equivalent automation examples using Bash and Azure CLI, which are commonly used in Linux environments.
  • Mention cross-platform options for running the automation, such as using Azure CLI or Python scripts, and provide links or references.
  • Clarify whether the PowerShell script can be run on PowerShell Core (pwsh) on Linux, and provide installation/setup instructions if so.
  • Wherever scripts or command-line instructions are given, include both Windows (PowerShell) and Linux (Bash/Azure CLI) variants.
  • Explicitly state the platform requirements for any provided scripts or tools.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates some Windows bias, notably by referencing Windows-specific documentation (such as 'Install Log Analytics agent on Windows computers') and omitting equivalent Linux instructions or links in certain sections. While the main deployment method is Linux-centric (Docker containers on Linux), there are places where Windows is mentioned first or exclusively, and Linux alternatives are not always provided. Additionally, some tool references and navigation instructions assume a Windows environment.
Recommendations:
  • Where Windows-specific links or instructions are given (e.g., 'Install Log Analytics agent on Windows computers'), provide equivalent Linux links or instructions, or clarify if not applicable.
  • Ensure that all navigation paths and examples are platform-neutral or include both Windows and Linux variants.
  • If referencing tools or utilities, mention cross-platform or Linux-native alternatives where appropriate.
  • Review all sections for implicit Windows-first ordering and adjust to either present Linux first (when more relevant, as in this case) or present both equally.
  • Explicitly state when a step or tool is only relevant to Windows, and offer guidance for Linux users.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation exhibits a subtle Windows bias by referencing the PowerShell New-GUID cmdlet as the primary example for generating GUIDs, without mentioning Linux or cross-platform alternatives. No Linux or cross-platform command-line tools (such as uuidgen) are suggested, and the only explicit tool reference is Windows-specific. There are no examples or instructions tailored for Linux users.
Recommendations:
  • When suggesting how to generate a GUID, include cross-platform and Linux-native tools (e.g., 'uuidgen' for Linux/macOS, or online generators) alongside PowerShell.
  • Rephrase the sentence to mention non-Windows options first or equally (e.g., 'Generate it using uuidgen (Linux/macOS), PowerShell New-GUID (Windows), or any online generator').
  • Audit the documentation for other tool or command references to ensure Linux parity and provide equivalent instructions/examples for both platforms.
  • Consider adding a short section or note on cross-platform compatibility for any command-line or scripting steps.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation page for Microsoft Sentinel scheduled analytics rules demonstrates a Windows bias primarily by referencing PowerShell as the only scripting/automation interface for enabling rules via command line, and by mentioning PowerShell before API in the 'Next steps' section. There are no Linux or cross-platform CLI examples (such as Azure CLI or Bash), and no mention of Linux-native tools or workflows. This may give the impression that only Windows or PowerShell users can automate or script rule management, omitting equivalent Linux-friendly approaches.
Recommendations:
  • Include Azure CLI examples for exporting, importing, and enabling analytics rules, alongside or before PowerShell examples.
  • Explicitly mention that APIs and automation can be accessed from any platform, not just Windows.
  • Provide Bash or shell script snippets for common tasks, or reference cross-platform tools.
  • Add a note clarifying that PowerShell Core is available cross-platform, or provide links to relevant Linux installation guides.
  • Ensure that any automation or scripting guidance is platform-neutral or includes both Windows and Linux options.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a Windows bias by exclusively providing instructions and tooling based on PowerShell scripts, referencing Windows PowerShell and Visual Studio Code as editors, and instructing users to run commands such as Set-ExecutionPolicy that are specific to Windows environments. There is no mention of Linux or cross-platform alternatives for script execution, nor are there examples or guidance for users on Linux or macOS. All automation and scripting guidance assumes a Windows-centric workflow.
Recommendations:
  • Provide explicit instructions for running the PowerShell script on Linux and macOS, including prerequisites (such as installing PowerShell Core and setting execution policy equivalents).
  • Mention and demonstrate the use of cross-platform editors (e.g., VS Code on Linux/macOS, nano, vim) for editing scripts.
  • Include alternative shell commands or instructions for users who prefer Bash or other shells, or clarify that the script is compatible with PowerShell Core on all platforms.
  • Add notes or examples for Linux/macOS users, such as how to download and run the script, and how to handle permissions.
  • Avoid referencing only Windows-specific tools (e.g., 'Windows PowerShell') and instead use neutral or cross-platform terminology (e.g., 'PowerShell Core').

Page-Level Analysis

Missing Linux Example
Summary:
The documentation page focuses exclusively on migrating from Splunk to Microsoft Sentinel, with all examples and instructions referencing Splunk Web and Microsoft Sentinel in the Azure/Defender portal. There is no mention of operating system-specific tools, but the only example for exporting Splunk detections uses the Splunk Web UI and SPL queries, without any CLI or OS-specific alternatives. No PowerShell, Windows tools, or Windows-first patterns are present, but there is also no mention of Linux command-line options or parity for Linux-based Splunk deployments.
Recommendations:
  • Provide alternative instructions for exporting Splunk detections using the Splunk CLI, which is commonly used on Linux servers.
  • Explicitly state that the migration process is OS-agnostic if that is the case, or clarify any OS-specific requirements.
  • Include examples or notes for users managing Splunk on Linux systems, such as using shell scripts or Linux file paths for exports.
  • If any step requires access to files or directories, provide both Windows and Linux path examples.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page exhibits a Windows-first bias, with several workbooks and descriptions focused specifically on Windows technologies (e.g., Windows Event Log analysis, Windows Security Events, Microsoft products). There is a lack of explicit mention or examples for Linux or non-Windows environments, and no Linux-specific workbooks or equivalent monitoring scenarios are highlighted. The language and examples assume a Microsoft/Windows-centric environment, and Linux or cross-platform considerations are missing.
Recommendations:
  • Add examples or descriptions of workbooks that specifically address Linux log sources (e.g., syslog, auditd, Linux authentication logs) and their monitoring in Microsoft Sentinel.
  • Include Linux-focused or cross-platform workbooks in the table, or clarify which existing workbooks are applicable to Linux data sources.
  • Where Windows-specific tools or logs are mentioned (such as Windows Event Log), provide equivalent Linux log types and describe how they can be monitored using Sentinel workbooks.
  • Explicitly mention support for non-Windows environments and provide guidance or links for users managing Linux or hybrid infrastructures.
  • Balance the documentation by ensuring that both Windows and Linux (and other platforms, where relevant) are represented in examples, terminology, and recommended practices.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation displays a Windows bias by focusing on Windows Security events as the only explicit OS event source, referencing Windows-specific event IDs, and listing 'Windows' as the only device family and OS in enrichment examples. There are no examples or mentions of Linux or macOS event sources, device types, or OSes, and no guidance for integrating non-Windows data. This may lead readers to believe that UEBA is primarily or exclusively for Windows environments.
Recommendations:
  • Add explicit mention of Linux and macOS as potential data sources for UEBA, if supported.
  • Provide examples of Linux (e.g., syslog, auditd) and macOS event sources and how to onboard them to Microsoft Sentinel.
  • Include Linux/macOS device types and operating systems in enrichment sample values and tables.
  • Clarify whether non-Windows events are supported or not, and provide guidance for customers with heterogeneous environments.
  • If Linux/macOS are not supported, state this explicitly to set expectations.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation provides a detailed PowerShell function as the only example for programmatically calling the upload API, relying on the MSAL.PS PowerShell module and Windows certificate store paths. There are no equivalent examples for Linux or cross-platform scripting environments such as Bash/cURL or Python. This focus on PowerShell and Windows-specific tooling may hinder Linux users or those working in non-Windows environments.
Recommendations:
  • Add equivalent example(s) for Linux environments, such as using Bash with cURL or Python scripts leveraging the MSAL or requests libraries.
  • Demonstrate how to handle authentication and certificate management in a cross-platform way (e.g., using PEM files instead of Windows certificate store).
  • Explicitly mention that the API can be accessed from any platform and provide at least one non-Windows example before or alongside the PowerShell example.
  • Reference cross-platform tools (e.g., OpenSSL, cURL, Python) where appropriate, not just Windows/PowerShell modules.
  • Clarify any platform-specific requirements or differences in the authentication/token acquisition process.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation repeatedly references Microsoft Excel as the tool for creating CSV files, and provides separate syntax examples for CSVs created in Excel versus those created in a 'text editor'. There is no mention of Linux-native tools (such as LibreOffice Calc, csvkit, or command-line utilities) or explicit Linux examples. The documentation implicitly assumes a Windows-centric workflow for CSV creation and editing.
Recommendations:
  • Include explicit examples using Linux-native tools for CSV creation and editing, such as LibreOffice Calc, csvkit, or command-line editors (vim, nano).
  • Clarify that 'text editor' can refer to editors on any platform, and provide examples using Linux command-line tools (e.g., echo, cat, awk) to generate CSVs.
  • Mention cross-platform CSV editors and note any differences in CSV formatting or quoting conventions between Windows (Excel), macOS, and Linux tools.
  • Add a section or note on verifying CSV compatibility across different operating systems and tools.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by listing Windows-specific solutions (e.g., Windows DNS, Windows Firewall) before or more prominently than their Linux equivalents, and by referencing Windows tools and patterns (such as Windows DNS logs and Windows Firewall) without providing equivalent Linux examples or guidance. While Syslog and CEF are mentioned (which are cross-platform), there is a lack of parity in examples or detailed steps for Linux environments, and no Linux-specific tools (such as iptables, nftables, or Linux DNS logs) are referenced.
Recommendations:
  • Add explicit Linux-focused examples, such as how to ingest and match Linux DNS logs (e.g., from BIND or systemd-resolved) and Linux firewall logs (e.g., iptables, nftables) into Sentinel.
  • Provide parity in the solution and connector tables by including Linux-specific sources and connectors alongside Windows ones.
  • When listing data sources or connectors, avoid always listing Windows sources first; alternate or group by platform.
  • Include screenshots or walkthroughs that show Linux log ingestion and matching analytics, not just Windows-centric examples.
  • Reference Linux-native tools and patterns where appropriate, and provide guidance for both Windows and Linux environments.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation generally provides both Windows and Linux examples for log file locations where applicable, but there is a consistent pattern of listing Windows file paths before Linux equivalents (windows_first). In some cases, such as NGINX HTTP Server and SecurityBridge Threat Detection for SAP, only Linux examples are provided, but there are no cases where only Windows examples are given. There is no evidence of PowerShell-heavy or Windows-only tooling; the syslog configuration and command-line instructions are Linux-centric. However, the documentation sometimes refers to Windows tools or patterns first, and in a few cases, Linux-only applications are not mirrored with Windows examples (missing_linux_example).
Recommendations:
  • Alternate the order of Windows and Linux examples throughout the documentation to avoid always listing Windows first.
  • Where possible, provide both Windows and Linux examples for all applications, or explicitly state when an application is only available on one platform.
  • Ensure parity in detail and clarity between Windows and Linux instructions, including configuration file names and example paths.
  • Consider adding PowerShell or Windows command-line equivalents for syslog configuration steps if relevant for Windows-based syslog servers.
  • Add a summary table at the top of the document indicating platform support for each application, clarifying which are Linux-only or Windows-only.