Scan Details - Linux-first Docs for Azure

297

Pages Scanned

56

Pages Flagged

297

Changed Pages

18.9%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:00:06 Scan started

Scan Information

Started At: 2025-08-04 00:00:06

Finished At: In Progress

Status: in_progress

Target URL: https://github.com/MicrosoftDocs/azure-docs/tree/main/articles

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell command-line examples for scripting and automation, without mentioning or providing equivalent Azure CLI (cross-platform) or Bash examples. The PowerShell approach is presented as the primary or sole scripting method, and there is no guidance for Linux/macOS users or references to Linux-native tools or shell environments.

Recommendations:

Add equivalent Azure CLI (az) command examples alongside all Azure PowerShell examples, as Azure CLI is cross-platform and widely used on Linux and macOS.
When introducing scripting/automation, mention both PowerShell and Azure CLI as supported options, and avoid presenting PowerShell as the default or only choice.
Include Bash shell script examples or at least reference that the steps can be performed from Linux/macOS terminals using Azure CLI.
Where possible, provide links to both PowerShell and CLI documentation/samples, and clarify that both are supported.
Review and update screenshots or UI references to ensure they are not Windows-specific if not necessary.
Consider a 'Choose your platform' tabbed approach for code samples (PowerShell, CLI, ARM template) to improve parity and inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Visual Studio Code (VS Code) and GitHub Copilot for testing and using the MCP server, without mentioning or providing examples for Linux-native tools or command-line alternatives. The workflow assumes use of the Azure Portal (web-based, but often associated with Windows-centric workflows) and does not provide any Linux shell, curl, or cross-platform CLI examples for interacting with the MCP server. There is no mention of Powershell, but the documentation does not offer parity for Linux users who may prefer terminal-based or non-GUI approaches.

Recommendations:

Add examples using cross-platform command-line tools such as curl or httpie to demonstrate how to test the MCP server from Linux or macOS terminals.
Mention and provide steps for using the Azure CLI (which is cross-platform) to interact with API Management and MCP server endpoints.
Clarify that Visual Studio Code is available on Linux and macOS, and provide any necessary Linux-specific setup instructions if relevant.
Include at least one example of configuring and testing the MCP server using Linux-native tools (e.g., editing configuration files with nano/vim, using jq for JSON manipulation, etc.).
If possible, provide screenshots or terminal output from Linux environments to reinforce cross-platform support.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page references Azure PowerShell in the 'Next steps' section as the only example for creating an autoscaling, zone redundant application gateway, without mentioning or linking to equivalent Azure CLI (cross-platform) or ARM template instructions. This suggests a bias toward Windows/PowerShell tooling, with no Linux or cross-platform alternatives presented.

Recommendations:

Add links or instructions for creating an autoscaling, zone redundant application gateway using Azure CLI, which is cross-platform and widely used on Linux.
Include references to ARM/Bicep templates for infrastructure-as-code scenarios, which are platform-agnostic.
Ensure that examples and tutorials are provided for both PowerShell and CLI in the 'Next steps' section, or provide a general link to all available methods.
Consider reordering or grouping tooling links so that cross-platform options (CLI, ARM) are presented alongside or before PowerShell examples.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing PowerShell for configuration tasks and omitting explicit Linux or cross-platform examples. The only configuration guide linked is for PowerShell, and instructions for using the Azure CLI (which is cross-platform) or Linux-native tools are not provided or are mentioned only in passing. The documentation also refers to the PowerShell, CLI, REST API, or Portal for details, but PowerShell is consistently mentioned first, and no Linux-specific guidance or examples are included.

Recommendations:

Add explicit Azure CLI examples for all configuration steps, ensuring parity with PowerShell instructions.
Include links to both PowerShell and Azure CLI (and, where relevant, REST API) documentation for configuring TLS policies.
Where referencing command-line tools, alternate the order (e.g., 'CLI or PowerShell') or clarify that CLI is cross-platform.
Provide at least one example of configuring TLS policy from a Linux environment using Azure CLI.
Ensure that all 'Next steps' and instructional links include both Windows and Linux/cross-platform options.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation exhibits mild Windows bias, particularly in the Helm installation section, where Windows instructions (including a PowerShell/winget example) are presented before Linux. The use of Windows-specific tools (winget) is highlighted, and the Windows tab appears before the Linux tab. However, the majority of command-line examples use Azure CLI and Bash syntax, which are cross-platform and Linux-friendly.

Recommendations:

Present Linux and Windows installation instructions in parallel or with Linux first, as Linux is the primary OS for most Kubernetes administrators.
Avoid prioritizing Windows-specific tools (such as winget) in examples; instead, provide equal prominence to Linux package managers (apt, yum, snap) and Homebrew for macOS.
Where possible, use cross-platform installation methods or clearly indicate which commands are for which OS, ensuring Linux and macOS are not afterthoughts.
Explicitly mention macOS where relevant, as it is also a common platform for Kubernetes administrators.
Ensure that all examples and instructions are tested and validated on both Linux and Windows environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell (Get-AzApplicationGatewayBackendHttpSetting) as the only CLI example for checking configuration, and exclusively referencing Fiddler (a Windows-centric tool) for network debugging. There are no Linux or cross-platform command-line examples (such as Azure CLI or Bash), nor are Linux-friendly tools (like tcpdump, curl, or Wireshark) mentioned. The instructions for downloading and installing Fiddler also assume a Windows environment (e.g., 'run as administrator').

Recommendations:

Add Azure CLI (az network application-gateway http-settings list) and/or Bash examples alongside or before PowerShell commands.
Mention and provide examples for cross-platform or Linux-native network debugging tools such as tcpdump, Wireshark, or curl.
When referencing Fiddler, clarify that it is Windows-centric and suggest alternatives for Linux/macOS users (e.g., mitmproxy, Wireshark).
Ensure installation instructions and screenshots are not exclusive to Windows; provide parity for Linux/macOS where applicable.
Adopt a tool-agnostic approach in troubleshooting steps, or at least present Windows and Linux options side by side.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell-based examples for configuring Application Gateway with Key Vault certificates, with no equivalent Azure CLI, Bash, or Linux-native instructions. PowerShell is referenced as the primary automation tool, and the 'Next steps' section links exclusively to a PowerShell guide. There are no Linux-specific or cross-platform command examples, and Windows-centric tools and patterns are mentioned before any alternatives.

Recommendations:

Provide equivalent Azure CLI examples alongside PowerShell for all configuration steps, especially for tasks like referencing Key Vault secrets and configuring Application Gateway listeners.
Include Bash shell scripts or command-line instructions that are platform-agnostic to ensure Linux users can follow along without needing PowerShell.
In the 'Next steps' section, add links to guides for Azure CLI and ARM/Bicep templates, not just PowerShell.
When referencing automation or scripting, mention both PowerShell and CLI options, and avoid presenting PowerShell as the default or only method.
Explicitly state that all steps can be performed on both Windows and Linux, and provide any necessary notes for cross-platform compatibility.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell (a Windows-centric tool) examples for migration and preview registration/unregistration, and by referencing PowerShell scripts as the primary automation method. There are no explicit Linux or cross-platform CLI (Azure CLI/bash) examples, and PowerShell is mentioned before or instead of other options. This may hinder Linux users or those preferring cross-platform tooling.

Recommendations:

Add equivalent Azure CLI (bash) command examples alongside PowerShell commands for all operations, including migration, preview registration, and unregistration.
When referencing automation scripts or tooling, mention both PowerShell and Azure CLI options, or clarify cross-platform support.
In 'Next steps', provide links to tutorials or modules that use Azure CLI or bash, not just PowerShell.
Where possible, use neutral language (e.g., 'Azure CLI or PowerShell') instead of listing PowerShell first or exclusively.
If PowerShell scripts are referenced, note their compatibility with PowerShell Core on Linux/macOS, or provide alternative scripts for bash environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation presents configuration steps for Azure Application Gateway Private Link with a clear preference for Windows-centric tools and workflows. The PowerShell section is detailed and appears before the Azure CLI section, and there are no explicit Linux shell or cross-platform scripting examples. The Azure portal and PowerShell are highlighted first, with CLI (the most cross-platform option) coming last. There are no references to Linux-specific tools, nor are there any bash or shell script examples. This may make the documentation less approachable for Linux users or those preferring non-Windows environments.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples to emphasize cross-platform parity.
Include bash/shell script examples for common tasks, especially for subnet and network configuration, to assist Linux users.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide any OS-specific notes if needed.
Where possible, provide links or references to Linux-native tools (e.g., using curl or jq for REST API calls) for advanced scenarios.
Balance the depth and detail of PowerShell and CLI sections to ensure both Windows and Linux users have equally comprehensive guidance.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell scripts for migration tasks, without mentioning or providing examples for cross-platform alternatives such as Azure CLI or REST API. There are no Linux/bash examples or guidance, and the only automation tooling discussed is PowerShell, which is traditionally associated with Windows environments.

Recommendations:

Include Azure CLI examples and guidance for migration steps alongside or in place of PowerShell scripts.
Explicitly state whether the migration scripts and processes are supported on Linux/macOS environments, and provide instructions for those platforms.
If REST API or ARM template options exist for migration, document them to provide platform-agnostic alternatives.
Balance references to PowerShell with equivalent bash or shell script examples where possible.
Clarify prerequisites for running PowerShell scripts on non-Windows systems (e.g., PowerShell Core on Linux/macOS) if PowerShell is the only supported method.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While the main certificate generation workflow uses OpenSSL (cross-platform), Windows and PowerShell are prioritized or exclusively featured in several areas: Windows is mentioned first in prerequisites, IIS (Windows web server) configuration is described before Apache/NGINX, and only Azure PowerShell is shown for uploading certificates to Application Gateway (with no Azure CLI or ARM template example). The PowerShell code uses Windows-style paths, and there is no explicit Linux/Unix shell or CLI example for the Azure upload step.

Recommendations:

Provide Azure CLI examples alongside Azure PowerShell for uploading certificates to Application Gateway, using Linux-style paths where appropriate.
List Linux and Windows equally in prerequisites, or mention Linux first when discussing OpenSSL, as it is more native to Linux.
Include Linux/Unix shell commands or scripts for certificate upload and management, not just PowerShell.
When discussing web server configuration, alternate the order (e.g., present Apache or NGINX before IIS, or group them without preference).
Clarify that all steps are cross-platform unless otherwise noted, and provide any OS-specific instructions as needed.
Where file paths are shown, include both Windows and Linux path examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a moderate Windows bias. It prioritizes .NET/ASP.NET (Windows-centric) examples, uses Windows-specific terminology (such as 'App Service' and 'X-ARR-ClientCert'), and provides detailed C#/.NET code samples before other languages. There is no explicit mention or example of using Linux-native tools (such as OpenSSL or curl) for certificate handling, nor are there shell or Bash command-line examples. The overall structure and sample order suggest a Windows-first approach, with Linux parity present but not foregrounded.

Recommendations:

Add Linux/Bash command-line examples for enabling client certificates (e.g., using Azure CLI from Bash, not just Cloud Shell).
Include OpenSSL-based examples for certificate inspection and validation, especially in the 'Access the client certificate' section.
Provide parity in code sample ordering: alternate or rotate the order of language samples so that Linux-first stacks (Node.js, Python, Java) are not always after .NET.
Explicitly mention Linux-native tools and patterns where relevant (e.g., using curl with client certificates for testing mutual TLS).
Clarify that the Azure CLI and Bicep/ARM templates are cross-platform, and provide example shell environments for both Windows and Linux.
Consider adding a troubleshooting section for common Linux client issues (e.g., curl or wget certificate errors).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by prioritizing PowerShell automation examples and mentioning them before Linux/CLI alternatives. The 'Automate with scripts' section lists Azure CLI and PowerShell, but only provides an inline PowerShell code snippet, with no equivalent Bash or Linux shell example. There is no mention of Linux-specific tools or workflows for certificate management, and the documentation does not provide parity for Linux users in automation or command-line instructions.

Recommendations:

Provide Bash or Linux shell script examples alongside PowerShell in the 'Automate with scripts' section.
Ensure that Azure CLI examples are as prominent and detailed as PowerShell examples, including inline code snippets.
Mention Linux tools or workflows (such as OpenSSL for certificate handling) where relevant, especially in sections discussing uploading or generating certificates.
Review the ordering of automation/script sections to avoid always listing Windows/PowerShell first.
Include links to Linux-specific configuration guides where appropriate, not just in language-specific FAQs.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias in several ways: PowerShell examples are provided alongside Azure CLI, but no explicit Linux shell or Bash alternatives are given for PowerShell commands. The outbound IP address retrieval section lists Azure PowerShell after Azure CLI, but does not clarify that PowerShell is Windows-centric or provide Linux-native alternatives. Outbound IPv6 support is noted as available only for Windows apps, with no parity for Linux. There is also a lack of Linux-specific troubleshooting or command-line guidance, and no mention of Linux tools (e.g., dig instead of nslookup, or Bash scripting).

Recommendations:

For every PowerShell example, provide an equivalent Bash or Linux-native command (e.g., using Azure CLI in Bash, or REST API with curl).
Clarify in the documentation when a feature or command is Windows-only, and provide Linux alternatives or workarounds where possible.
In sections where outbound IPv6 is discussed, explicitly state the lack of Linux support and link to tracking issues or roadmaps for Linux parity.
Include Linux-native tools in examples (e.g., suggest dig as an alternative to nslookup, or show how to use jq with Azure CLI outputs).
Add troubleshooting or verification steps that are platform-agnostic or provide both Windows and Linux instructions.
Review the order of examples to avoid always listing Windows/PowerShell first; alternate or group by platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation subtly prioritizes Windows by mentioning Windows as the first supported OS in the list ('run them on both Windows and Linux'), and by listing Windows-centric tools (Visual Studio, Azure PowerShell) before or alongside cross-platform or Linux-native alternatives. There are no explicit Linux command-line examples or Linux-specific tools mentioned, and the command-line tooling section lists Azure PowerShell before Azure CLI, which is more cross-platform and Linux-friendly.

Recommendations:

Alternate the order of 'Windows and Linux' mentions to 'Linux and Windows' in some places, or use 'Linux or Windows' to avoid implicit prioritization.
When listing command-line tools, mention Azure CLI before Azure PowerShell, as Azure CLI is cross-platform and more commonly used on Linux.
Include explicit references to Linux-native tools or workflows (e.g., Bash, shell scripts) where relevant.
Add examples or links to documentation that demonstrate Linux-based deployment and management workflows.
Highlight Linux-specific features or benefits where applicable, to balance the focus.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. Windows-specific instructions, tools, and examples (especially PowerShell) are often presented first or exclusively, with Linux equivalents sometimes appearing later or in less detail. Many code samples, especially for authentication and runbook management, use PowerShell and Windows-centric paths or commands. Some advanced features, such as Hybrid Worker Credentials and certain credential management, are only described for Windows, with Linux support explicitly marked as unavailable or not covered. In several sections, Linux instructions are present but less detailed or lack parity with Windows examples.

Recommendations:

Provide Linux examples alongside Windows examples in all sections, especially for authentication, credential management, and starting runbooks.
When presenting instructions or code samples, alternate the order (sometimes Linux first) or present both platforms in parallel tabs or sections.
Expand Linux-specific guidance for features currently described only for Windows (e.g., Hybrid Worker Credentials), or clearly state if/why a feature is not available on Linux.
Include Bash or Python script examples for Linux where only PowerShell is shown for Windows.
Ensure that all references to tools, environment variables, and file paths include both Windows and Linux equivalents.
Where a feature is not supported on Linux, provide context and possible workarounds or alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows bias by prioritizing PowerShell (a Windows-centric tool) in both structure and content, providing only PowerShell code samples, and referencing Windows file paths and environment variables. Linux-specific considerations are mentioned only in passing, and there are no Linux shell (e.g., Bash) examples or detailed Linux workflow guidance. Several features and limitations are described only in the context of Windows or PowerShell, with Linux support or differences often omitted or minimized.

Recommendations:

Provide equivalent Linux/Bash examples for common automation scenarios, especially where PowerShell is used.
Explicitly document differences in behavior, limitations, and setup for Linux Hybrid Runbook Workers, including file paths, environment variables, and module/package management.
Avoid using Windows file paths (e.g., C:\modules) in examples without also providing Linux equivalents (e.g., /opt/modules or /home/automation/modules).
Clarify which features are supported or unsupported on Linux Hybrid Runbook Workers, and provide workarounds or alternatives where possible.
Balance the order of presentation so that Python and Linux scenarios are not always secondary to PowerShell/Windows.
Include troubleshooting and known issues sections specific to Linux environments.
Where PowerShell is recommended, clarify that PowerShell Core (7.x) is cross-platform, and provide Linux-specific notes or examples for PowerShell usage on Linux.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing command-line examples exclusively in Azure PowerShell, with no equivalent Azure CLI (cross-platform) or Bash examples. The only non-portal automation method shown is PowerShell, which is primarily associated with Windows environments. There is no mention of Linux-native tools or scripting approaches, and the ordering of examples always places PowerShell before any mention of CLI (which is only referenced in the intro, not in examples).

Recommendations:

Provide Azure CLI (az) command examples alongside PowerShell for all automation and deletion tasks, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash script examples where appropriate, especially for tasks that could be automated outside of Windows environments.
When listing automation options, present Azure CLI and PowerShell together, or alternate their order, to avoid implying PowerShell is the primary or preferred method.
Explicitly mention that all operations can be performed from Linux, macOS, or Windows, and provide links to relevant cross-platform tooling documentation.
Consider including REST API curl examples for advanced users who may prefer direct API calls from any platform.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a strong bias toward Windows and PowerShell environments. PowerShell is consistently presented as the primary or default scripting language, with detailed examples and references to PowerShell modules, cmdlets, and packaging formats. Windows-centric tools and patterns (such as PowerShell Gallery, .zip modules, and Get-Module cmdlet) are emphasized, while Linux/Python equivalents are only briefly mentioned or lack practical examples. REST API examples and screenshots also focus on PowerShell scenarios, and there is little to no guidance for Linux-native workflows or tools.

Recommendations:

Provide parallel, detailed examples for Python runbooks, including REST API payloads, portal workflows, and package management steps.
Include Linux-native packaging and module management guidance (e.g., using .whl, pip, or requirements.txt for Python) with concrete examples.
Highlight the use of Azure CLI and bash scripting in automation scenarios, not just as a note but with step-by-step instructions.
Balance screenshots and walkthroughs to show both PowerShell and Python/Linux scenarios.
Reference Linux documentation and best practices where relevant, such as running Python runbooks on Linux-based runtime environments.
Avoid presenting PowerShell/Windows tools and patterns first or exclusively; ensure equal prominence for Linux/Python approaches.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_registry_focus

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Windows and Linux for most troubleshooting steps, but there are several signs of Windows bias. Windows examples, tools, and troubleshooting steps are often presented first, and some scenarios (such as registry key removal, event log checks, and PowerShell-based troubleshooting) are described only for Windows, with no Linux equivalents or alternatives. There is a heavier focus on Windows-specific tools (PowerShell scripts, registry edits, event logs), and Linux troubleshooting is sometimes less detailed or omitted.

Recommendations:

Alternate the order of Windows and Linux instructions or present them in parallel to avoid always listing Windows first.
Where Windows-specific tools (e.g., PowerShell scripts, registry edits, event log checks) are mentioned, provide equivalent Linux commands or log locations (e.g., journalctl for service logs, Linux equivalents for registry or configuration changes).
For scenarios that only provide Windows steps (such as registry key removal or event log troubleshooting), add Linux-specific troubleshooting steps or clarify if not applicable.
Ensure Linux troubleshooting steps are as detailed as Windows steps, including command-line examples for common issues (e.g., checking service status, log collection, authentication issues).
Where PowerShell scripts are referenced for Windows, provide bash or Python script equivalents for Linux where possible.
Explicitly mention if a scenario or step is Windows-only, and provide rationale or alternatives for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page is generally cross-platform in intent, focusing on Visual Studio Code and Azure Functions, which are available on Windows, macOS, and Linux. However, there are subtle signs of Windows bias: troubleshooting steps specifically mention Windows (e.g., WSL Bash), and there are no explicit Linux/macOS-specific instructions, caveats, or screenshots. Windows-specific issues are called out, but Linux/macOS users are not directly addressed, and there are no examples or troubleshooting steps tailored for them. All instructions assume a generic environment, but Windows is the only OS called out by name.

Recommendations:

Add explicit notes or troubleshooting steps for Linux and macOS users, such as common issues with permissions, shell environments, or dependencies.
Where Windows-specific guidance is given (e.g., about WSL Bash), provide equivalent Linux/macOS advice or clarify if those issues do not apply.
Include at least one example or screenshot showing the workflow on Linux or macOS to demonstrate parity and inclusivity.
In requirements and setup sections, explicitly mention that the instructions apply to all supported platforms, and link to platform-specific installation guides for dependencies like Azure Functions Core Tools.
Review all included files (e.g., functions-install-core-tools-vs-code.md) to ensure they do not contain hidden Windows bias.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific tools and configuration steps are often mentioned before their Linux equivalents, and some CLI examples are Windows-centric. While Linux is supported and mentioned, Linux-specific instructions are sometimes less detailed or appear after Windows instructions. In some cases, Linux examples or notes are missing or less prominent, especially for command-line and deployment scenarios.

Recommendations:

Ensure all CLI and deployment examples are provided for both Windows and Linux, with equal prominence and detail.
When listing tools or configuration steps (e.g., Azure CLI, PowerShell), present Linux and Windows options side by side or in parallel tabs, rather than listing Windows first.
Include explicit Linux shell examples (bash/zsh) for all command-line operations, not just Azure CLI commands.
For sections referencing Visual Studio or Windows-specific tooling, add equivalent instructions for Linux-friendly tools such as VS Code, .NET CLI, and Azure CLI.
Review all references to configuration settings (e.g., environment variables, file paths) to ensure Linux-specific guidance is included and not just assumed.
Where possible, avoid language that implies Windows is the default or primary platform; instead, use neutral or cross-platform phrasing.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform coverage, but there are several instances of Windows bias. Windows-specific tools, patterns, and terminology (such as environment variable delimiters, file paths, and settings) are often mentioned first or exclusively. PowerShell is referenced in detail, while equivalent Linux shell or Bash examples are missing. Some settings are described as 'Windows only' without parallel Linux guidance, and certain examples (like file paths) use Windows conventions. In a few cases, Linux-specific instructions are present but less prominent or detailed.

Recommendations:

For every Windows-specific example or mention (such as environment variable delimiters, file paths, or settings), provide the Linux equivalent side-by-side or in parallel.
When referencing PowerShell or Windows tools, also mention and give examples for Bash or Linux CLI usage.
Avoid using Windows paths (e.g., %HOME%\typescript) without also showing the Linux alternative (e.g., $HOME/typescript).
Where settings or behaviors differ between Windows and Linux (such as environment variable delimiters or time zone values), clearly document both, not just the Windows case.
If a setting is 'Windows only', explicitly state what the Linux equivalent is or clarify if there is none.
Ensure that Linux-specific features (such as linuxFxVersion, Oryx build, etc.) are given equal prominence and detail as Windows-specific features.
Add Bash/Azure CLI examples wherever Azure PowerShell is referenced for managing settings.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a mild Windows bias. Visual Studio (a Windows-centric IDE) is consistently listed first in C# sections, and PowerShell is highlighted as an HTTP test tool before cross-platform alternatives like curl. Microsoft Edge's Network Console is also mentioned, which is Windows-specific. While the page does mention cross-platform tools and support for Linux/macOS, Windows tools and patterns are often prioritized or listed before their Linux equivalents.

Recommendations:

List cross-platform tools (such as Visual Studio Code and command-line/terminal) before Windows-only tools (like Visual Studio) in environment tables and tool recommendations.
When mentioning HTTP test tools, list curl (cross-platform) before PowerShell and Microsoft Edge, or group them by platform.
Explicitly note platform compatibility for each tool, especially when referencing Windows-only options.
Provide Linux/macOS-specific examples or notes where appropriate (e.g., for changing ports, running emulators, or using command-line tools).
Balance PowerShell examples with bash/zsh or other Linux shell equivalents where command-line usage is discussed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Bash and Windows CMD examples for Maven and Azure CLI commands, but consistently lists Windows CMD after Bash, which is a positive sign. However, there are some subtle Windows biases: (1) The term 'command prompt' is used alongside 'terminal', which is a Windows-centric term; (2) There are no explicit Linux-specific instructions or troubleshooting notes, and no mention of Linux tools or shell environments beyond Bash; (3) In the Java version support table, Windows is listed before Linux, and for Functions 2.x, Linux is marked as 'n/a' without further explanation or guidance. There are no PowerShell-specific examples, but the documentation does not provide parity for Linux-specific scenarios or tools, and does not address potential differences in environment setup or troubleshooting for Linux users.

Recommendations:

Use neutral terminology such as 'terminal' instead of 'command prompt' unless specifically referring to Windows.
Provide explicit Linux troubleshooting notes or callouts where behavior may differ (e.g., file permissions, environment variable setup).
Add examples or notes for common Linux shells (e.g., zsh, fish) if relevant, or clarify that Bash examples are applicable to most Linux environments.
In tables and lists, alternate the order of Windows and Linux, or use alphabetical order to avoid implicit prioritization.
For any features not supported on Linux (e.g., Functions 2.x), provide a brief explanation or workaround if possible.
Where environment variables or file paths are referenced, show both Windows and Linux formats, or clarify differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation generally maintains good cross-platform parity, but there are subtle signs of Windows bias. References to 'command prompt' and development 'on Windows' appear before or instead of explicit mentions of Linux or macOS. The guidance for remote build specifically recommends it for Windows users, and the use of 'command prompt' as a generic term may confuse Linux/macOS users. There are no explicit PowerShell-only examples, but the documentation does not always clarify CLI usage across platforms. Visual Studio Code is the only editor mentioned, which is cross-platform, but no Linux-specific editors or shell environments are referenced. There are no missing Linux examples, and the documentation does emphasize that Azure Functions for Python is Linux-hosted.

Recommendations:

Replace or supplement 'command prompt' with 'terminal' or 'shell', and clarify that all CLI commands work on Linux/macOS as well as Windows.
When referencing development environments, explicitly mention Linux and macOS alongside Windows, especially in sections about local development and publishing.
Avoid language such as 'use remote build when you're developing Python apps on Windows' without providing equivalent guidance for Linux/macOS users.
Add examples or notes for Linux/macOS users where file paths, environment variables, or shell commands may differ.
Consider mentioning other popular cross-platform editors (e.g., PyCharm, Vim) or at least clarify that Visual Studio Code is available on all platforms.
Review all CLI command examples to ensure they are not Windows-specific (e.g., avoid backslashes in paths, use forward slashes or note both).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing only Windows/PowerShell examples for key administrative tasks (such as enabling Kerberos encryption), referencing Windows-specific tools and policies (e.g., Group Policy, Windows registry keys, Set-ADUser), and omitting equivalent Linux/Unix commands or workflows. Windows terminology and tools are consistently mentioned first or exclusively, while Linux/Unix administration scenarios are not addressed, despite the relevance for NFS and dual-protocol volumes.

Recommendations:

Provide equivalent Linux/Unix command-line examples (e.g., using 'kadmin', 'ldapmodify', or 'realm' for Kerberos and LDAP configuration) alongside PowerShell commands.
Include guidance for managing Active Directory integration from Linux hosts, especially for NFS and dual-protocol scenarios, such as joining AD from Linux or configuring Kerberos tickets.
Reference Linux tools and configuration files (e.g., /etc/krb5.conf, sssd, realmd) where relevant, and explain how to achieve required settings without Windows tools.
Balance the order of presentation so that Linux/Unix workflows are described alongside or before Windows-specific instructions where applicable.
Clarify which steps are required or different for Linux-based environments, especially for customers managing mixed or non-Windows infrastructures.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-native tools (Active Directory Users and Computers MMC snap-in) for managing LDAP POSIX attributes, providing step-by-step instructions and screenshots only for Windows environments. There are no equivalent instructions or examples for managing POSIX attributes from Linux or cross-platform tools. The documentation also references Windows-specific features and tools (e.g., Windows File Browser, 'net view' command) before or instead of Linux equivalents, and omits Linux-based workflows for common administrative tasks.

Recommendations:

Provide equivalent instructions and screenshots for managing LDAP POSIX attributes using Linux tools (e.g., ldapmodify, ldapadd, or Apache Directory Studio) alongside the Windows MMC snap-in.
Include examples of how to access and modify LDAP attributes from Linux command-line utilities or cross-platform GUI tools.
When referencing Windows-specific tools or commands (e.g., Windows File Browser, 'net view'), also mention Linux/NFS equivalents (e.g., using 'showmount', 'ls', or 'mount' commands) and describe how similar tasks can be performed from Linux clients.
Ensure that all configuration and management steps are documented for both Windows and Linux environments, especially for tasks relevant to dual-protocol (NFS and SMB) scenarios.
Consider reordering sections or examples so that Linux and Windows instructions are presented with equal prominence, or grouped together for parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page primarily provides Azure PowerShell commands for managing the 'Disable showmount' feature, with only a brief mention of Azure CLI as an alternative. There are no explicit Linux shell or Bash examples, and the PowerShell approach is presented first and in detail, which may disadvantage users on Linux or macOS platforms.

Recommendations:

Provide equivalent Azure CLI command examples alongside PowerShell, with full syntax and usage.
Include Bash shell examples for Linux users where applicable (e.g., using az CLI in Bash).
Present both PowerShell and CLI options in parallel, or lead with the more cross-platform Azure CLI.
Clarify that all commands can be run on any platform where Azure CLI is available, not just Windows.
Add a note or section specifically for Linux/macOS users, ensuring parity in instructions and screenshots if interface differences exist.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exhibits Windows bias in the section addressing NFS access from Windows clients. It provides detailed PowerShell commands and mounting instructions for Windows, but does not offer equivalent Linux examples or commands. Additionally, Windows-specific troubleshooting is covered, while Linux client troubleshooting is not. In the persistent mount section, Linux is mentioned first, but the linked documentation is generic and not expanded upon here. Overall, the page assumes Windows users need more explicit guidance, while Linux users are expected to infer or seek information elsewhere.

Recommendations:

For every Windows-specific example (such as PowerShell commands and mount instructions), provide equivalent Linux commands (e.g., mount command with options, NFS client configuration).
Include troubleshooting tips for Linux NFS clients, similar to the Windows CaseSensitiveLookup guidance.
Where Windows tools or patterns are mentioned, ensure Linux tools (such as nfs-utils, mount.nfs, /etc/fstab configuration) are also described.
Balance the depth of explanation between Windows and Linux, ensuring that Linux administrators receive as much actionable detail as Windows administrators.
Consider adding a dedicated FAQ entry for common Linux NFS client issues and their solutions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by presenting Windows/Powershell examples and instructions first, providing detailed steps for setting SACLs via the Windows GUI, and referencing Windows tools (e.g., robocopy) without Linux equivalents. There is a lack of step-by-step Linux command examples for managing Audit ACEs or SACLs on NFS shares, and Linux tooling is only referenced indirectly or via links.

Recommendations:

Provide equivalent step-by-step instructions for setting Audit ACEs on NFSv4.1 shares from a Linux client, including example commands (e.g., using setfacl or nfs4_setfacl).
Include Linux CLI examples for feature registration and management, not just Azure PowerShell and CLI references.
Mention Linux tools (e.g., rsync) alongside Windows tools like robocopy when discussing migration operations.
Ensure that instructions for both Windows and Linux are presented in parallel or with equal prominence, rather than Windows-first.
Add screenshots or terminal output examples for Linux-based workflows where applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation presents Windows (SMB) client instructions and screenshots before Linux (NFS) client instructions, and provides more detailed step-by-step guidance for Windows users (including both GUI and command-line methods). Windows-specific tools (File Explorer, dir command) are highlighted, while Linux instructions are briefer and limited to the df command. REST API usage references PowerShell specifically, but does not mention Linux shell scripting or tools.

Recommendations:

Alternate the order of Windows and Linux sections in different documentation updates, or present them in parallel to avoid always prioritizing Windows.
Provide equally detailed Linux instructions, including both GUI (if applicable, e.g., GNOME Files/Nautilus) and command-line methods.
For REST API usage, include examples for both PowerShell (Windows) and bash/curl/jq (Linux/macOS) to ensure parity.
Mention Linux-native tools (such as lsblk, ncdu, or graphical disk usage analyzers) where relevant, not just df.
Ensure screenshots and examples are balanced between platforms, and avoid implying Windows is the default or primary environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. SMB/Windows terminology and tools are introduced before or with more detail than Linux/NFS equivalents. Official support is highlighted for Windows and macOS SMB clients, while Linux (Samba) is described as unsupported. Windows-specific features (NTFS ACLs, SID translation, NTLM fallback) are explained in detail, but Linux/NFS equivalents (such as POSIX ACLs, idmapd, or Samba configuration) are not equally covered. No practical Linux/NFS configuration or troubleshooting examples are provided, and there is a lack of parity in example commands or references for Linux administrators.

Recommendations:

Provide equal emphasis and detail for Linux/NFS and Windows/SMB throughout the documentation.
Include practical Linux/NFS client configuration and troubleshooting examples (e.g., mounting NFS shares, configuring idmapd, setting POSIX/NFSv4 ACLs).
When describing dual-protocol or identity mapping, include Linux-specific tools and workflows (such as nsswitch.conf, getent, idmapd.conf) alongside Windows/Active Directory concepts.
Clarify the support status for Linux SMB clients and provide guidance or references for best-effort interoperability.
Balance the order of presentation: do not always introduce Windows/SMB first; alternate or present both platforms together.
Add Linux-focused links in the 'Next steps' section (e.g., guides for configuring NFS clients, troubleshooting Linux access issues, using Samba with Azure NetApp Files).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in several areas. In the section 'Ways to create snapshots', PowerShell is explicitly mentioned alongside Azure CLI, REST API, and the Azure portal, but there is no mention of Linux shell scripting or examples using Bash. The ordering of tools often lists PowerShell before or alongside CLI, with no explicit Linux-focused guidance or examples. There are no Linux-specific commands or references to Linux-native tools or workflows, and no examples are provided for Linux users. This may make the documentation less accessible or immediately useful for Linux administrators.

Recommendations:

Add explicit Linux/Bash examples for creating and managing snapshots, such as using Azure CLI from a Bash shell.
When listing tools, alternate or randomize the order of Azure CLI and PowerShell, or list Azure CLI first, as it is cross-platform.
Include sample scripts or command lines for both Windows (PowerShell) and Linux (Bash) environments.
Reference Linux-native automation and scripting patterns where appropriate, such as cron jobs for automation.
Ensure that all instructions and examples are platform-neutral or provide parity between Windows and Linux wherever possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows tools and patterns (such as PowerShell, Chocolatey, and Winget) are described in more detail and appear before or more prominently than Linux equivalents. PowerShell is used for manual installation on Windows, and the Visual Studio (Windows-only) workflow is given equal prominence to the cross-platform Visual Studio Code workflow. In some sections, Windows installation methods are listed last, but the Windows-specific tools and scripting (PowerShell) are more detailed and varied than for Linux/macOS. Linux and macOS instructions are present and technically complete, but Windows-specific tooling and patterns are more deeply integrated.

Recommendations:

Ensure that Linux and macOS installation instructions are as detailed and varied as Windows (e.g., mention package managers like apt, yum, or snap if available, not just manual download).
Where multiple installation methods are listed, present Linux/macOS options before or alongside Windows options, rather than after.
Provide Bash or shell script examples for Linux/macOS with the same level of detail as PowerShell for Windows.
Highlight cross-platform tools (like Visual Studio Code and Azure CLI) before platform-specific tools (like Visual Studio or PowerShell).
Where possible, avoid assuming PowerShell as the default scripting environment for manual installation; provide equivalent Bash scripts for Linux/macOS.
Consider adding a summary table that clearly indicates which methods are cross-platform and which are Windows-only.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates Windows bias by referencing PowerShell-specific instructions and links (e.g., 'import-export-ps.md'), mentioning Azure PowerShell before Azure CLI, and omitting explicit Linux or cross-platform command-line examples. There are no CLI or Bash examples, and PowerShell is implicitly prioritized.

Recommendations:

Provide parallel Azure CLI (cross-platform) instructions and links wherever PowerShell is mentioned.
Update references such as 'import-export-ps.md' to include or point to CLI/Bash/Linux-friendly guides.
Explicitly mention that both Azure CLI and PowerShell can be used for migration tasks, and provide examples for both.
Ensure that all steps referencing command-line tools include both Windows and Linux/macOS compatible commands.
Review sample code and instructions to ensure they are platform-neutral or include notes for both environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias. Several JSON examples for UI controls specify the 'osPlatform' property as 'Windows', and controls such as 'Microsoft.Compute.CredentialsCombo', 'Microsoft.Compute.UserNameTextBox', and 'Microsoft.Compute.SizeSelector' are repeatedly shown with 'osPlatform': 'Windows'. There are no examples or mentions of Linux or cross-platform scenarios, nor are Linux-specific values or considerations discussed. This may give the impression that the toolkit or UI definitions are primarily intended for Windows environments.

Recommendations:

Include examples where 'osPlatform' is set to 'Linux' or both 'Windows' and 'Linux', especially for controls like user name, credentials, and VM size selectors.
Discuss any differences or considerations for Linux-based deployments in the test cases, such as username restrictions or password requirements.
Add at least one example for each relevant test case that demonstrates a Linux scenario, or explicitly state if the toolkit is Windows-only.
Where 'osPlatform' is used, clarify that it can accept 'Linux' and provide guidance for Linux-specific values.
Review the documentation for implicit assumptions about Windows and update language to be more platform-neutral where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a strong Windows bias by exclusively referencing Windows Server Active Directory as the LDAP identity source, requiring Windows-specific infrastructure (domain controllers, AD Certificate Services), and omitting any examples or guidance for integrating with non-Windows LDAP servers (such as OpenLDAP on Linux). All terminology, screenshots, and instructions are centered around Windows environments, with no mention of Linux-based alternatives or parity.

Recommendations:

Include parallel instructions and examples for integrating with common Linux-based LDAP servers (e.g., OpenLDAP), including configuration steps and screenshots where possible.
Generalize terminology where possible (e.g., 'LDAP server' instead of always 'Windows Server Active Directory'), and clarify that non-Windows LDAP sources are supported.
Provide guidance on certificate management for Linux LDAP servers, such as using OpenSSL or other Linux CA tools, not just Windows AD CS.
Add troubleshooting tips and best practices relevant to Linux LDAP deployments.
Ensure that prerequisites and network requirements are described in a platform-agnostic way, or provide both Windows and Linux variants.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows Server Active Directory as the external identity source, with all examples, screenshots, and instructions tailored to Windows environments. It exclusively references Windows tools (MMC, domain controllers, NetBIOS names), Windows-specific patterns (Active Directory, .local domains), and PowerShell/Run command cmdlets. There are no examples or guidance for integrating non-Windows LDAP servers (such as OpenLDAP on Linux), nor any mention of Linux-based tools or workflows.

Recommendations:

Add parallel instructions and examples for integrating Linux-based LDAP servers (e.g., OpenLDAP), including how to export certificates and configure connections.
Include Linux command-line examples (such as using openssl, ldapsearch, or certtool) for certificate management and LDAP queries.
Provide screenshots or CLI output from Linux environments where relevant.
Clarify in the introduction and throughout the document that third-party (non-Windows) LDAP directories are supported, and link to their specific setup guides if available.
When listing prerequisites and configuration steps, mention both Windows and Linux LDAP server options, and avoid assuming the use of Windows-only tools (like MMC or NetBIOS names) unless necessary.
If PowerShell/Run command is required, note any cross-platform alternatives or limitations for Linux administrators.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page does not provide any OS-specific command-line examples, but the only 'Next steps' link points to a PowerShell-based tutorial, which is typically associated with Windows environments. There is no mention of Linux tools, Bash, or cross-platform CLI options, and no Linux-specific guidance is provided.

Recommendations:

Include links to equivalent tutorials using Azure CLI (az), which is cross-platform and commonly used on Linux and macOS.
Add explicit mention of cross-platform configuration options, such as using Azure Portal, Azure CLI, or ARM templates, to ensure Linux users are supported.
If PowerShell is referenced, clarify that Azure PowerShell is available on Linux and macOS, or provide Bash/Azure CLI alternatives alongside PowerShell examples.
Ensure that future documentation and 'Next steps' sections offer parity between Windows/PowerShell and Linux/Azure CLI approaches.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page is generally platform-neutral but contains a subtle Windows bias in the troubleshooting section, where only the Windows-specific command ('ipconfig /flushdns') is provided for clearing the DNS cache. No equivalent instructions or commands are given for Linux or macOS users. There are no PowerShell-heavy sections or exclusive references to Windows tools, but the omission of Linux/macOS examples in this context may hinder parity.

Recommendations:

When mentioning platform-specific commands (such as clearing DNS cache), provide equivalent instructions for Linux (e.g., 'sudo systemd-resolve --flush-caches' or 'sudo resolvectl flush-caches') and macOS (e.g., 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder').
Explicitly state that the instructions apply to all platforms, and include notes or callouts for any platform-specific differences.
Review other troubleshooting or automation sections to ensure Linux/macOS users are not overlooked when platform-specific actions are described.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation assumes a development workflow centered on .NET and Azure App Service, with all examples and instructions tailored to ASP.NET Core and related Microsoft tooling. There are no Linux-specific instructions, nor are there examples for deploying or running the sample app outside of the Azure/Microsoft ecosystem. The use of GitHub Codespaces and Azure CLI is cross-platform, but the lack of explicit Linux (or macOS) terminal commands, package installation steps, or alternative frameworks (such as for Node.js, Python, or Java) suggests a bias toward Windows/Microsoft environments.

Recommendations:

Add explicit notes that the tutorial works on Linux and macOS as well as Windows, especially since .NET Core is cross-platform.
Include Linux/macOS-specific terminal commands where appropriate (e.g., for running the app, installing .NET SDK, or using the Azure CLI).
Mention alternative editors or IDEs (such as VS Code on Linux/macOS) alongside Codespaces.
Provide a brief section or appendix on deploying and running the sample app on a local Linux machine or on a Linux-based cloud VM.
Clarify that Azure App Service supports both Windows and Linux hosting, and provide links or instructions for both.
Where security best practices are discussed, mention Linux-specific considerations (such as file permissions, firewall configuration, etc.) if relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation is generally platform-neutral but contains a subtle Windows bias in the troubleshooting section. Specifically, when instructing users how to clear the DNS cache, only the Windows-specific command (`ipconfig /flushdns`) is provided, with no mention of equivalent commands for Linux or macOS. No PowerShell-specific commands or Windows-only tools are otherwise present, but the lack of Linux/macOS parity in this example can disadvantage non-Windows users.

Recommendations:

Include equivalent DNS cache flush instructions for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo service nscd restart`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
When giving OS-specific troubleshooting steps, present all major platforms together or link to platform-specific instructions.
Review other troubleshooting or command-line sections to ensure parity for Linux and macOS users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes both setx (cmd) and PowerShell examples, which may be seen as Windows-centric. Linux/macOS instructions are present but listed after Windows ones. No Linux-specific tools or patterns are omitted, but the ordering and emphasis favor Windows users.

Recommendations:

Present Linux/macOS instructions before or alongside Windows instructions, rather than after.
Use tabbed or parallel formatting to show all OS instructions at once, reducing perceived priority.
Ensure parity in detail and troubleshooting tips for Linux/macOS environments.
Consider including a note that all major platforms are supported equally, to reinforce cross-platform intent.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes explicit PowerShell examples. While Linux/macOS instructions are present, Windows command-line tools and patterns are consistently mentioned first, which may suggest a subtle Windows-first bias.

Recommendations:

Present Linux/macOS and Windows instructions in parallel tabbed sections, or alternate which platform is shown first.
Avoid always listing Windows (cmd/PowerShell) before Linux/macOS in step-by-step instructions.
Where possible, use cross-platform commands or highlight platform-agnostic approaches.
Ensure that Linux/macOS users are given equal prominence and clarity in all setup and configuration steps.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is focused exclusively on ASP.NET Core applications, which are cross-platform, but all examples and instructions assume a development environment and workflow typical of Windows users. There are no explicit Linux or cross-platform command-line examples, and all configuration steps are described via the Azure Portal UI or C# code, with no mention of CLI or scripting alternatives (such as Azure CLI, Bash, or PowerShell). This can implicitly prioritize Windows-centric workflows and may leave Linux developers without clear guidance.

Recommendations:

Provide equivalent command-line instructions using Azure CLI for adding Key Vault references and managing App Configuration, with examples that work on Linux, macOS, and Windows.
Explicitly mention that the steps apply to all platforms supported by ASP.NET Core, and clarify any platform-specific considerations if they exist.
Include sample scripts or terminal commands for common tasks (e.g., adding a Key Vault reference, rotating certificates) that can be run in Bash or other non-Windows shells.
Add a section or callout for Linux/macOS users, highlighting any differences or confirming parity.
Ensure that any referenced tutorials or prerequisites also contain Linux/macOS instructions where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation generally maintains good cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows command-line instructions (Cmd and PowerShell) are listed before or alongside Linux/macOS equivalents, and PowerShell is given its own language pivot and tab. The use of 'command prompt' as a generic term and the explicit inclusion of PowerShell-specific instructions and pivots may reinforce a Windows-centric perspective, even though Linux/macOS instructions are present. No major Linux examples are missing, and Linux tools (like curl) are included.

Recommendations:

Ensure that Linux/macOS instructions are always presented first or in parallel with Windows instructions, especially in tabbed or pivoted sections.
Avoid using 'command prompt' as a generic term; instead, specify 'terminal' or clarify the OS context.
Where PowerShell is used, ensure Bash or equivalent Linux shell examples are equally prominent and not secondary.
Review tab/pivot ordering to avoid defaulting to Windows/PowerShell first.
Continue to use cross-platform tools (like curl) in examples, and avoid Windows-only tools or patterns unless absolutely necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates mild Windows bias by listing Windows tools (robocopy) before Linux equivalents (rsync) when discussing SMB data migration and replication. Additionally, robocopy is the only SMB tool mentioned, which is Windows-specific, while no Linux/Unix-native SMB copy tools (such as smbclient or cifs-utils) are referenced. However, both NFS (rsync) and SMB (robocopy) tools are mentioned, and the documentation does not provide command-line examples for either, reducing the overall impact of the bias.

Recommendations:

Mention Linux/Unix-native SMB copy tools (e.g., smbclient, cifs-utils, or mount.cifs with cp/rsync) alongside robocopy to provide parity for Linux users.
When listing tools, alternate the order (e.g., mention rsync and robocopy together, or rotate which is listed first) to avoid the perception of Windows-first bias.
Provide brief example commands for both Windows and Linux environments to ensure equal clarity for users of both platforms.
Explicitly state that both Windows and Linux tools are supported for SMB and NFS, and provide links to relevant documentation for each.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation provides both Azure CLI (Bash) and PowerShell examples for all major scenarios, ensuring parity in scripting approaches. However, there is evidence of Windows bias in the underlying implementation details and references. Specifically, the documentation references the Windows-specific CommandLineToArgvW system call for argument parsing, and PowerShell (traditionally a Windows tool) is given equal prominence to Bash/CLI, despite its Windows origins. Additionally, the documentation refers to Windows-style escaping (e.g., double-escaping quotes) and PowerShell cmdlets, which may be less familiar to Linux users. The mention of Connect-AzAccount and Start-Sleep, both PowerShell-specific, further reinforces this bias. However, there are no missing Linux examples, and Bash/CLI examples are present throughout.

Recommendations:

When referencing system calls or argument parsing, provide Linux equivalents or clarify that the implementation is cross-platform (e.g., explain how arguments are parsed in Linux containers).
Where PowerShell-specific tools or patterns are mentioned (e.g., Connect-AzAccount, Start-Sleep), offer equivalent Bash/CLI guidance or note that these are PowerShell-specific.
Clarify that PowerShell is available cross-platform, but also highlight native Linux/Bash scripting patterns where appropriate.
Review and balance the order of presentation so that Bash/CLI and PowerShell are alternated or presented in a way that does not always prioritize Windows/PowerShell concepts.
Add a brief section explaining the cross-platform nature of deployment scripts, including any differences in behavior or environment between Windows and Linux containers.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing a security rule example that exclusively targets Windows server sign-in failures, without offering a comparable Linux example. Throughout the document, there is an implicit assumption of Windows environments, and no Linux-specific queries, scripts, or scenarios are provided, despite the cross-platform capabilities of Azure Arc and Microsoft Defender for Cloud.

Recommendations:

Include equivalent Linux-focused examples, such as a scheduled query rule for failed SSH logins on Linux servers.
When demonstrating security rules or queries, provide both Windows and Linux scenarios side by side.
Explicitly mention that the integration process supports both Windows and Linux VMs, and provide links or references to Linux-specific documentation where appropriate.
If scripts are generated for onboarding, clarify whether both Windows (PowerShell) and Linux (Bash/Shell) scripts are available, and show examples of both.
In the 'Create rules to identify security threats' section, add a Linux example query (e.g., detecting multiple failed sudo attempts or SSH login failures).

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page primarily describes known issues and workarounds for Azure VMware Solution, with a few instances referencing Windows-specific tooling (notably, VMware Tools for Windows and the Azure VMware Solution Run command Set-Tools-Repo). There are no explicit PowerShell-heavy or Windows-first examples, but Linux equivalents or cross-platform guidance are missing where Windows tools are mentioned.

Recommendations:

When referencing VMware Tools updates, clarify if instructions or tooling are applicable to both Windows and Linux VMs. If not, provide Linux-specific remediation steps or note any differences.
For commands like Set-Tools-Repo, specify if/how Linux VMs are affected or remediated, and provide equivalent instructions or links for Linux environments.
Where possible, include cross-platform guidance or explicitly state platform applicability for all remediation steps.
Review all references to tools or commands to ensure Linux administrators are not left without clear instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation consistently references the Azure portal and VMware tools/interfaces but does not provide any OS-specific command-line examples. However, where OS-level interaction is mentioned (e.g., enabling SSH, signing in to the VM), there is an implicit assumption of familiarity with Linux (e.g., root password, SSH), but no explicit Linux or Windows command-line examples are provided. The only references to command-line usage are generic (e.g., running transporter-status.sh), with no PowerShell, Windows CMD, or Linux shell commands shown. The documentation is Azure-centric and assumes use of the Azure portal for all management tasks, which may bias toward Windows users but does not explicitly exclude Linux users. There are no examples of using Linux tools or CLI for deployment, configuration, or troubleshooting, nor are there any Windows-specific tools or scripts mentioned.

Recommendations:

Provide explicit Linux and Windows command-line examples for tasks such as transferring OVA files, deploying OVA, and verifying connectivity (e.g., using scp, WinSCP, or Azure CLI).
Include instructions for both Linux and Windows users when SSH access or file transfer is required (e.g., using PuTTY on Windows, OpenSSH on Linux).
Where Azure portal is referenced, mention equivalent Azure CLI or PowerShell commands for cross-platform parity.
Add troubleshooting steps or verification commands for both Linux and Windows environments.
Clarify any OS-specific requirements or recommendations for the reverse proxy VM (e.g., supported guest OS, SSH client compatibility).

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page exhibits a subtle Windows bias by referencing 'Windows Isolated v2' as the minimum charge for regional deployments, without mentioning Linux equivalents or clarifying Linux support. No command-line examples are provided, but the only OS-specific reference is to Windows, and Linux is not mentioned in deployment or pricing contexts.

Recommendations:

Explicitly mention Linux support and pricing for App Service Environment v3, especially in sections discussing deployment types and minimum charges.
If there are differences in features, pricing, or deployment steps between Windows and Linux, provide clear comparisons or links to relevant Linux documentation.
Include examples or notes for both Windows and Linux where OS-specific behavior or options exist.
Review all references to OS-specific SKUs (such as 'Windows Isolated v2') and clarify if Linux equivalents exist or if the information is Windows-only.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation provides environment variable setup instructions in the order: Windows (cmd), PowerShell, then Linux/macOS (bash). This ordering prioritizes Windows tooling and patterns, which may suggest a subtle Windows-first bias. However, all platforms are represented and no platform is omitted.

Recommendations:

Rotate or randomize the order of platform-specific instructions, or explicitly state that the order does not imply priority.
Consider grouping all environment variable setup commands in a table for parity, or present Linux/macOS first if usage data supports it.
Add a note acknowledging cross-platform usage and encourage users to select the instructions appropriate for their OS.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation references Azure PowerShell before Azure CLI when discussing supported versions for the 'count' property, and the 'Next steps' section links only to a PowerShell deployment guide, omitting equivalent Linux/CLI deployment documentation. No explicit Linux/CLI examples or links are provided, which may give the impression of Windows/Powershell preference.

Recommendations:

When listing supported tools (PowerShell, CLI, REST), alternate the order or mention Azure CLI first to avoid Windows-first bias.
In the 'Next steps' section, include links to both Azure PowerShell and Azure CLI deployment guides to ensure Linux parity.
Wherever deployment instructions or examples are referenced, provide both PowerShell and CLI options, or link to documentation that covers both.
Explicitly mention that Azure CLI is cross-platform and suitable for Linux/macOS users.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation page does not provide any OS-specific configuration examples, scripts, or tooling references. However, it also does not include any practical examples or command-line instructions at all—neither for Windows (e.g., PowerShell) nor for Linux (e.g., Bash, iproute2, or Linux-based BGP tools). The content is entirely conceptual and vendor-neutral, focusing on Azure, VMware, and network architecture concepts. There is a lack of practical, step-by-step configuration guidance for either platform, which could be considered a missed opportunity for Linux parity if future examples are added.

Recommendations:

When adding configuration examples or step-by-step guides, ensure both Windows (PowerShell, Windows Server routing) and Linux (Bash, FRRouting, Quagga, or native Linux networking tools) examples are provided.
Explicitly mention that the guidance applies to both Windows and Linux-based on-premises environments, and call out any differences if they exist.
If referencing NVAs or BGP configuration, provide sample configuration snippets for popular Linux-based routers (e.g., FRRouting) as well as Windows-based solutions.
Include links to documentation for both Windows and Linux network configuration where relevant.

Create pull request

No problematic pages found in this scan. All pages appear to be Linux-friendly! 🐧