Scan Details - Linux-first Docs for Azure

10229

Pages Scanned

98

Pages Flagged

10229

Changed Pages

1.0%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:00 Scan started

Scan Information

Started At: 2025-08-17 00:01:00

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:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific configuration files (such as web.config), mentioning iisnode settings for Node.js apps, and omitting equivalent Linux-native examples or tools. While there is a brief mention of running on Linux and using PM2, most configuration and troubleshooting guidance assumes a Windows/IIS environment, with no parallel Linux-native instructions or examples.

Recommendations:

For every mention of Windows-specific configuration (e.g., web.config, iisnode), provide equivalent Linux-native instructions (e.g., app settings, environment variables, or nginx/apache configuration).
Include Linux-specific troubleshooting and configuration examples, such as using process managers like systemd or supervisord, and how to configure auto-healing or recycling on Linux-based App Service plans.
Clarify when a feature or recommendation applies only to Windows-based App Service plans, and provide Linux alternatives or note if unavailable.
Expand Node.js sections to include Linux-native process management and configuration (beyond PM2), and avoid assuming iisnode is always relevant.
Where possible, present examples for both Windows and Linux platforms side by side to ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. Windows SKUs and examples are presented before Linux equivalents, and Azure PowerShell (a Windows-centric tool) is featured alongside Azure CLI. Portal instructions and screenshots use Windows terminology and UI patterns. While Linux is mentioned, it is often secondary, and there are no Linux shell or scripting examples beyond Azure CLI.

Recommendations:

Present Linux and Windows options in parallel, rather than listing Windows first.
Include explicit Linux shell (bash) scripting examples where automation is discussed, not just Azure CLI and PowerShell.
Ensure screenshots and UI instructions clarify any differences between Windows and Linux app workflows.
When referencing Azure PowerShell, also mention cross-platform compatibility or alternatives for Linux users.
Where possible, provide parity in troubleshooting and error-handling guidance for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively, with more detailed guidance and screenshots for Windows users. Windows-specific tools (like PowerShell and GUI) are referenced without always providing equivalent Linux commands or alternatives. Some troubleshooting and connectivity test examples rely on Windows tools, and the Linux experience is sometimes described as less feature-rich (e.g., no GUI support).

Recommendations:

Provide Linux examples alongside Windows examples, especially for troubleshooting steps (e.g., include Linux equivalents for PowerShell commands like 'Test-NetConnection', such as 'nc', 'telnet', or 'curl').
When referencing tools or commands, list both Windows and Linux options together, or alternate the order to avoid always putting Windows first.
Expand Linux-specific guidance, such as offering more detailed CLI usage instructions and screenshots for Linux where possible.
Where a GUI is only available for Windows, suggest or document alternative workflows for Linux users, and clarify feature parity.
Ensure that all steps (installation, configuration, troubleshooting) are equally covered for both platforms, and avoid assuming the user is on Windows.
Where possible, use cross-platform tools (e.g., Azure CLI, curl) in examples to promote parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias. Windows is consistently mentioned before Linux in lists of supported workloads and pricing details. Pricing and SKU tables often refer to Windows-specific plans and limitations (e.g., 'Windows container plans don't support memory-intensive SKUs'), while Linux-specific details are less prominent or absent. There are no Linux-specific examples, tools, or guidance, and the documentation does not provide parity in discussing Linux-specific considerations or features.

Recommendations:

Alternate the order of Windows and Linux in lists and tables to avoid implying priority.
Include Linux-specific examples, guidance, or notes where relevant (e.g., mention any Linux container limitations or features).
Where Windows-specific limitations are called out, also note any Linux-specific constraints or advantages.
Add sections or notes highlighting Linux deployment patterns, troubleshooting, or best practices for App Service Environment.
Ensure parity in documentation by providing equivalent detail for both Windows and Linux workloads, including references to Linux tools or command-line usage where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell examples are provided alongside Azure CLI, and Windows-specific tools (IIS, Certreq.exe) are mentioned for certificate export, while Linux equivalents are not. In automation and FAQ sections, PowerShell is listed before CLI, and Windows container limitations are called out, but Linux-specific guidance is minimal or absent.

Recommendations:

For every PowerShell example, provide an equivalent Azure CLI or bash example, and present both side by side.
When mentioning Windows tools like IIS or Certreq.exe for certificate export, also mention Linux/Unix alternatives (e.g., OpenSSL, certutil) and provide corresponding instructions or links.
In automation and FAQ sections, present Azure CLI and PowerShell options in parallel, or alternate their order to avoid always listing Windows tools first.
Explicitly call out any differences or limitations for Linux-based App Service plans, and provide Linux-specific troubleshooting or best practices where relevant.
Ensure screenshots and UI walkthroughs are not Windows-centric and clarify if steps differ for Linux-hosted apps.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias primarily in the section addressing Azure Traffic Manager endpoints, where only a PowerShell script is provided for identifying non-Azure endpoints. There are no equivalent Bash, Azure CLI, or cross-platform scripting examples for Linux/macOS users. The instructions for running the script explicitly reference PowerShell, and there is no mention of how to achieve the same outcome on non-Windows platforms. Throughout the rest of the document, examples are generally platform-neutral (using REST API and Azure CLI), but the exclusive reliance on PowerShell for a key scenario introduces a significant Windows-centric bias.

Recommendations:

Provide an equivalent Azure CLI or Bash script for identifying non-Azure Traffic Manager endpoints, or at least describe how Linux/macOS users can perform the same check.
When referencing scripts or tooling, always include cross-platform alternatives or explicitly state if a solution is Windows-only.
Instruct users on how to run PowerShell scripts on non-Windows platforms (e.g., via PowerShell Core on Linux/macOS), if no alternative exists.
Review all example commands and scripts to ensure parity between Windows and Linux users, especially for common administrative tasks.
Consider including a table or section summarizing all available methods (PowerShell, CLI, REST API) for each scenario, indicating platform compatibility.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on discovering ASP.NET web apps hosted on IIS web servers within VMware environments, which are Windows-centric technologies. There is no mention of Linux-based web servers (such as Apache or Nginx), nor are there examples or guidance for discovering .NET apps running on Linux. All discovery capabilities and tooling referenced (Azure Migrate appliance, IIS) are Windows-specific, and Linux scenarios are omitted.

Recommendations:

Include information on discovering .NET web apps hosted on Linux servers, such as those running on Apache, Nginx, or Kestrel.
Provide examples and guidance for using Azure Migrate or other tools to discover Linux-hosted .NET applications.
Mention Linux environments explicitly in the overview and capabilities sections, clarifying whether and how they are supported.
If Linux discovery is not currently supported, clearly state this limitation and provide links to relevant feature requests or roadmaps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows evidence of Windows bias primarily through the exclusive mention and linking of Azure Storage Explorer with a Windows-specific tab for generating SAS tokens, without providing equivalent Linux or cross-platform alternatives. There are no Linux-specific instructions or examples for uploading files or generating SAS tokens, and the only tool mentioned for these tasks is Storage Explorer, which is often associated with Windows workflows. All command-line examples use Azure CLI, which is cross-platform, but GUI instructions and links are Windows-centric.

Recommendations:

Include instructions and examples for uploading files and generating SAS tokens using cross-platform command-line tools such as Azure CLI or azcopy, not just Azure Storage Explorer.
When referencing Azure Storage Explorer, clarify its cross-platform availability and provide Linux/macOS-specific instructions or screenshots where applicable.
Avoid linking directly to Windows-specific tabs or instructions; instead, provide parallel steps for Linux and macOS users.
Explicitly mention that all Azure CLI commands work on Linux, macOS, and Windows, and provide any OS-specific notes if needed.
Consider adding a section or callout for Linux/macOS users to ensure parity and inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias by focusing exclusively on Windows-based deployment and management patterns for ASP.NET apps. All runtime version discovery and file system examples use Windows paths and tools (CMD, PowerShell, Kudu), with no mention of Linux equivalents. There are no examples or instructions for configuring or troubleshooting ASP.NET apps running on Linux App Service plans, nor are Linux-specific tools or file paths referenced.

Recommendations:

Add parallel instructions and examples for ASP.NET apps running on Linux App Service plans, including how to check and set runtime versions, and where to find relevant files.
Include Linux shell (bash) commands and file paths alongside Windows CMD/PowerShell examples, especially for tasks like listing installed runtimes or accessing logs.
Mention and link to Linux-specific management tools or interfaces (e.g., SSH, Kudu for Linux, or App Service SSH console) where appropriate.
Clearly indicate which instructions are Windows-specific and provide equivalent guidance for Linux environments.
Ensure that references to deployment tools (such as Visual Studio) are balanced with cross-platform alternatives (such as Azure CLI, GitHub Actions, or VS Code).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration, troubleshooting, and examples are tailored to Windows, referencing Windows-specific tools (IIS, iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell). There are no examples or guidance for Linux-based Azure App Service or cross-platform scenarios. Linux equivalents (e.g., process management, logging, debugging, configuration) are not mentioned or linked.

Recommendations:

Add a parallel section or separate guide for Node.js on Azure App Service for Linux, covering best practices, troubleshooting, and configuration.
Include Linux-specific examples for common tasks (e.g., process management with PM2, logging locations, configuration files like .env or ecosystem.config.js).
Reference Linux tools and patterns (e.g., systemd, Linux file paths, Bash shell, SSH access) alongside Windows tools.
When describing troubleshooting steps (e.g., checking logs, debugging, profiling), provide both Windows and Linux command-line instructions.
Avoid assuming iisnode/web.config as the only deployment model; mention alternatives like Nginx/Apache reverse proxy setups for Linux.
Link to official Azure documentation for Node.js on App Service for Linux where available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias: Windows-specific instructions and code samples (C#, Java using Windows-MY store) are presented before Linux equivalents, and in greater detail. Windows tools and concepts (certificate store, user profile, Windows-specific environment variables) are emphasized, while Linux instructions are less detailed and often deferred or generic (e.g., 'see the documentation for the respective language or web platform' for non-.NET languages). There is a lack of parity in language coverage and depth for Linux, especially for non-.NET stacks.

Recommendations:

Provide Linux examples alongside Windows examples in all sections, not just in the container section.
Include code samples for loading certificates in popular languages (Node.js, Python, Java, PHP) on Linux, not just C#.
Avoid referring users to 'see the documentation for the respective language' for Linux scenarios—offer at least one concrete example per major language.
Present Windows and Linux instructions in parallel or in clearly separated, equally detailed sections/tabs.
Clarify when instructions are Windows-specific and offer Linux alternatives immediately, rather than as afterthoughts.
Balance the use of Windows tools (certificate store, user profile) with Linux-native patterns (file-based certificates, environment variables).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing Windows-style paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and by providing detailed operational instructions and examples that are specific to Windows environments. Linux paths are mentioned only parenthetically, and there are no Linux-specific examples or instructions for common deployment scenarios. Additionally, Windows-centric tools and patterns (such as directory structures and path formats) are described in detail, while Linux equivalents are not elaborated.

Recommendations:

Provide Linux-specific examples and instructions alongside Windows examples, including explicit Linux path formats (e.g., /home/site/wwwroot) in all relevant sections.
When describing directory structures or operational steps, present both Windows and Linux paths equally, rather than mentioning Linux as an aside.
Include troubleshooting tips and deployment nuances that are specific to Linux environments.
If there are differences in behavior or requirements between Windows and Linux App Service environments, clearly document them.
Where possible, use cross-platform tools and commands, or provide platform-specific alternatives (e.g., Bash scripts for Linux, PowerShell for Windows).

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates subtle Windows bias. It references PowerShell as a means to query Azure activity logs, and mentions Visual Studio integration for Application Insights, both of which are primarily Windows-centric tools. There are no explicit Linux or cross-platform command-line examples (such as Bash or Azure CLI), and the order of tool mentions (PowerShell before CLI) suggests a Windows-first approach. No Linux-specific monitoring or troubleshooting patterns are discussed, and there are no examples or references to Linux-native tools or workflows.

Recommendations:

Provide explicit examples using Azure CLI (az) commands alongside or before PowerShell for querying logs and managing monitoring features.
Mention and demonstrate integration with cross-platform editors and tools (e.g., VS Code, JetBrains Rider) in addition to Visual Studio.
Include Linux-specific troubleshooting and log access patterns, such as using SSH, tailing logs, or using Linux-native tools.
Ensure that all monitoring and diagnostic workflows are described in a platform-neutral way, or with parity between Windows and Linux approaches.
Add examples or links for Linux App Service environments, including how to access logs, set up Application Insights, and monitor metrics from a Linux perspective.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Windows-centric tools and workflows (such as Visual Studio and right-click actions), omitting explicit Linux or cross-platform instructions for key steps like file creation, package installation, and deployment. CLI alternatives are only linked, not shown inline, and Linux-specific guidance is missing throughout.

Recommendations:

Provide explicit Linux and cross-platform instructions for creating files (e.g., using 'touch' and editing with nano/vim/code) alongside Visual Studio/Windows steps.
Include .NET CLI commands for project/file creation and NuGet package installation directly in the documentation, not just as links.
Show how to manage environment variables and app settings using both Azure Portal (GUI) and Azure CLI/PowerShell, with examples for Linux shells.
Mention and demonstrate code editing using popular cross-platform editors (e.g., VS Code) in addition to Visual Studio.
Ensure that all steps, especially deployment and configuration, have Linux/macOS equivalents or are clearly marked as cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation demonstrates a Windows bias in several ways: Windows-specific paths and environment variables (e.g., %HOME%, D:\home\site\wwwroot) are used exclusively or before Linux equivalents; file upload instructions and examples reference Windows-style paths; the Kudu DebugConsole and FTP instructions are described in a Windows-centric manner; and PowerShell is mentioned as a scripting option alongside Azure CLI, but no Linux shell or Bash scripting examples are provided. Linux paths and conventions are only mentioned in passing, and there are no explicit Linux command-line or file system examples.

Recommendations:

Provide Linux-specific examples and instructions alongside Windows ones, including Linux file paths (e.g., /home/site/wwwroot) and environment variables.
When referencing file uploads or directory locations, include both Windows and Linux paths, or clarify the differences for each OS.
Include Bash or shell scripting examples in addition to PowerShell, and mention Linux-native tools where appropriate.
Ensure that screenshots and walkthroughs are not exclusively from Windows environments; add Linux-based screenshots or notes.
Where Kudu DebugConsole or FTP is referenced, clarify how Linux users can access or use these tools, including command-line alternatives.
In tables and lists, present Windows and Linux information in parallel, rather than Windows-first or Windows-only.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by requiring PowerShell for both the migration script and for decoding base64 strings, providing only PowerShell script examples, and not offering Linux shell or Bash alternatives. The migration script is a PowerShell (.ps1) script, and there are no Bash or shell script equivalents or instructions for Linux/macOS users. The prerequisites and step-by-step instructions assume a Windows environment, potentially excluding or confusing Linux users.

Recommendations:

Provide equivalent Bash or shell script examples for all PowerShell commands, especially for decoding base64 and running migration scripts.
Offer a Bash version of the migration script or document how to use the script on Linux/macOS (e.g., via PowerShell Core or alternative tooling).
List prerequisites in a cross-platform manner, mentioning both PowerShell and Bash/shell as options.
When referencing scripts, provide both .ps1 (PowerShell) and .sh (Bash) versions, or clarify cross-platform compatibility.
Ensure that all command-line examples (such as for decoding base64) include both Windows (PowerShell) and Linux/macOS (Bash) syntax.
Explicitly state platform compatibility for all tools and scripts, and provide guidance for users on non-Windows systems.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page is heavily focused on Windows-based App Service apps, with terminology, environment variables, and examples that are specific to Windows (e.g., %SystemDrive%, %ResourceDrive%, IIS, ASP.NET, COM components, registry access, and Windows event logs). Linux is only mentioned briefly in a note, with no equivalent details or examples for Linux-based App Service environments. There are no Linux-specific environment variables, file system paths, or diagnostic/logging mechanisms discussed. Windows tools and patterns (such as PowerShell, IIS, and the Windows registry) are mentioned exclusively, and there are no Linux command-line or shell examples.

Recommendations:

Add parallel sections or notes for Linux-based App Service apps, describing their file system layout, environment variables (e.g., $HOME, /tmp), and storage persistence.
Provide Linux-specific examples for file access, such as using $HOME/site or /home/site, and clarify differences in temporary storage and persistence.
Discuss diagnostic and logging mechanisms available in Linux containers (e.g., syslog, stdout/stderr, Azure Monitor integration) and how they differ from Windows.
Mention Linux-specific process and code execution capabilities (e.g., bash, sh, shell scripts) alongside PowerShell and Windows command shell.
Clarify the absence of Windows-specific features (like registry and event logs) in Linux environments, and describe any Linux equivalents or alternatives.
Ensure that Linux tools and patterns are given equal prominence and are not relegated to footnotes or brief mentions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily in the 'Static IP restrictions' section, where features and configuration options are described specifically for 'App Service on Windows' (such as web.config and dynamic IP security), with no mention of Linux equivalents or guidance for Linux-based App Service. There are no Linux-specific examples or parity notes, and Windows terminology and tools (like web.config) are referenced without alternatives.

Recommendations:

For every Windows-specific feature or configuration (e.g., web.config, dynamic IP security), explicitly state whether there is a Linux equivalent or if the feature is unavailable on Linux App Service.
Add Linux-specific examples or configuration guidance where possible, or provide links to relevant Linux documentation.
When listing features or instructions, avoid leading with Windows-only options unless Linux is not supported; otherwise, present both platforms equally or clarify differences.
Include a comparison table or section outlining feature parity and differences between App Service on Windows and Linux, especially for security-related features.
If a feature is not available on Linux, recommend best practices or workarounds for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by providing only PowerShell examples for command-line operations, with no equivalent examples for Linux shells (such as Bash or Azure CLI). The use of PowerShell-specific cmdlets (e.g., New-AzAppServicePlan, Set-AzAppServicePlan) and the absence of cross-platform or Linux-native tooling (like Azure CLI) may disadvantage users on Linux or macOS. The documentation also introduces PowerShell before any mention of ARM templates, reinforcing a Windows-first approach.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell command-line instructions, as Azure CLI is cross-platform and widely used on Linux and macOS.
Explicitly mention that PowerShell examples are for Windows users and provide Bash/Azure CLI alternatives for Linux/macOS users.
Consider reordering sections so that cross-platform tools (like Azure CLI or ARM templates) are presented before or alongside PowerShell.
Where possible, provide guidance on how to accomplish the same tasks using REST API calls or SDKs, which are platform-agnostic.
Review and update documentation metadata (such as ms.custom) to reflect support for cross-platform tools, not just Azure PowerShell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation displays a mild Windows bias. Windows-specific features (such as Windows Containers and Windows Server Active Directory) are mentioned explicitly, with detailed calculations and limitations, while Linux equivalents are not discussed in similar depth. There is a lack of Linux-specific examples or guidance, except for a brief mention of Linux continuous deployment network dependencies. Windows tools and patterns (e.g., Kudu console, Windows Containers) are referenced without providing Linux alternatives or parity in explanation.

Recommendations:

Provide equivalent Linux container guidance, including subnet/IP calculations and limitations for Linux-based App Service plans.
Include Linux-specific examples and scenarios, such as how environment variables or networking features are surfaced in Linux environments (e.g., via SSH or Kudu for Linux).
When referencing Windows-specific features (e.g., Windows Containers, Active Directory), also mention Linux alternatives or explicitly state if not supported.
Ensure that any tooling or portal instructions (such as Kudu console) clarify whether they apply to both Windows and Linux, or provide Linux-specific instructions where needed.
Balance the order of presentation so that Linux and Windows are given equal prominence, or clarify when a feature or limitation is OS-specific.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ visual_studio_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by prioritizing Visual Studio and Windows App Service deployment in both the deployment options and next steps. There are no explicit Linux or cross-platform deployment examples, and Visual Studio (a Windows-centric tool) is highlighted before mentioning more platform-agnostic methods. The page also lacks Linux-specific guidance or parity in tooling references.

Recommendations:

Add explicit examples and guidance for deploying WebJobs from Linux/macOS environments using Azure CLI, zip deployment, or other cross-platform tools.
Balance the deployment section by mentioning Visual Studio and cross-platform methods (e.g., VS Code, CLI, GitHub Actions) together, or list platform-agnostic options first.
Include references to Linux-compatible development and deployment workflows in the 'Next steps' section, such as using VS Code, Azure CLI, or GitHub Actions.
Clarify that WebJobs can be developed and deployed from any OS, and provide links to relevant Linux/macOS documentation where available.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias by frequently specifying features as 'Windows apps only' (e.g., proactive CPU monitoring, proactive auto-healing, Navigator) and providing more detailed descriptions and tool availability for Windows than for Linux. Linux support is mentioned but often as an afterthought, with fewer details and no Linux-specific troubleshooting examples or tool walkthroughs. There are no Linux command-line or shell examples, and the documentation does not provide parity in tool descriptions or usage scenarios for Linux-based App Service apps.

Recommendations:

Provide Linux-specific troubleshooting examples and walkthroughs, including screenshots and step-by-step instructions.
Ensure that all diagnostic tools and features are clearly marked for both Windows and Linux, with equivalent detail for each platform.
Add Linux shell/command-line examples where relevant, not just references to Windows or portal-based workflows.
Where features are Windows-only, explicitly state if and when Linux support is planned, and suggest alternative approaches for Linux users.
Reorder sections or provide parallel subsections for Windows and Linux to avoid the perception of Windows as the default or primary platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing Windows file paths (e.g., D:\home), Windows-specific deployment patterns, and tools (such as Kudu/SCM) without providing equivalent Linux examples or clarifying Linux path differences. The only mention of Linux is in the context of unsupported scenarios, and there are no Linux-specific instructions or examples for enabling or managing local cache. Additionally, the documentation refers to Windows containers and provides links for them, but does not offer parity for Linux containers beyond stating their lack of support.

Recommendations:

Include Linux-specific examples and file path references (e.g., /home/site) alongside Windows examples.
Clarify differences in local cache behavior and configuration between Windows and Linux App Service plans.
Provide instructions or notes for Linux users, even if the feature is unsupported, to guide them to alternatives (such as App Cache) with clear steps.
Ensure that all tools and site extension recommendations (like Azure Web Apps Disk Usage) are available or have alternatives for Linux environments, or explicitly state their availability.
When mentioning unsupported scenarios, provide links or references to Linux-specific documentation or workarounds.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing features and tooling (such as Process Explorer and diagnostic information collection) that are only available for Windows applications, without mentioning Linux equivalents or clarifying Linux limitations in detail. Several advanced monitoring and diagnostic features are described as Windows-only, and there are no Linux-specific examples or guidance for parity. Additionally, the note about the 'x-ms-auth-internal-token' header being Windows-only is buried, and there are no Linux-specific troubleshooting or configuration examples.

Recommendations:

Explicitly state feature parity or limitations for Linux throughout the documentation, not just in notes.
Provide Linux-specific guidance or alternatives for features like process monitoring and diagnostic information collection.
Include Linux examples or clarify when a feature is Windows-only, ideally at the start of each relevant section.
If a feature is unavailable on Linux, suggest alternative approaches or tools (such as using SSH, Azure Monitor, or Linux-native diagnostic tools).
Ensure that all code and configuration examples are tested and applicable on both Windows and Linux, or provide separate examples as needed.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation provides extensive Azure PowerShell examples and references, with some CLI parity but no explicit Linux shell (bash) or cross-platform scripting examples. PowerShell is presented as a primary automation tool, and certain instructions (such as for user-assigned identities in Functions) are only available in PowerShell. There is no mention of Linux-specific tools, nor are bash or shell script examples provided. The CLI examples are present but sometimes marked as 'azurepowershell-interactive', which may confuse Linux users. The documentation implicitly assumes familiarity with PowerShell and Windows-centric tooling.

Recommendations:

Add explicit bash/shell script examples for all CLI operations, ensuring parity with PowerShell instructions.
Clarify that Azure CLI commands are cross-platform and provide Linux/macOS terminal usage notes where appropriate.
Avoid labeling CLI examples as 'azurepowershell-interactive' when they are not PowerShell-specific.
Where PowerShell is the only supported method (e.g., for Functions user-assigned identity assignment), explicitly state the lack of Linux-native support and provide workarounds or roadmap information.
Include references to Linux-native tools or scripting environments where possible.
Ensure that CLI and ARM template examples are presented before or alongside PowerShell examples to avoid a 'windows_first' impression.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_examples

⚠️ uneven_linux_examples

Summary:

The documentation provides both Linux and Windows examples for basic App Service deployments, but Windows examples are often listed before Linux ones and there are more Windows-specific templates (e.g., Windows container, Windows with MySQL/PostgreSQL) than Linux equivalents. Some resource integrations (like database connections) are split into separate Linux and Windows sections, but the general 'App with connected resources' section defaults to Windows. There are no explicit PowerShell or Windows tool biases, but the ordering and coverage favor Windows scenarios.

Recommendations:

Ensure Linux and Windows examples are presented with equal prominence, alternating their order or grouping them together.
Add Linux equivalents for all Windows-specific templates, such as Linux container app templates and Linux app with Azure SQL Database.
Combine 'App with connected resources' into a unified section with both Linux and Windows examples side by side.
Clearly label which templates are for Linux and which are for Windows in all sections.
Review for parity in advanced scenarios (e.g., deployment slots, VNet integration, App Service Environment) to ensure Linux is equally represented.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. While Azure CLI examples (which are cross-platform) are provided, PowerShell examples are also given equal prominence, and in some sections, PowerShell is the only non-CLI scripting example. There is no mention of Linux-specific tools or shell environments (e.g., bash, curl, grep) except for a single 'curl' command for IPv6 testing. The documentation refers to the Azure Cloud Shell, which can be used from any OS, but does not clarify that PowerShell commands are Windows-centric. Outbound IPv6 support is noted as 'Windows apps only' without further Linux guidance. No Linux-specific troubleshooting or command-line examples (e.g., using dig instead of nslookup, or bash scripting) are present.

Recommendations:

For every PowerShell example, provide an equivalent bash or Linux shell example where possible, especially for scripting or automation tasks.
Clarify in the documentation that PowerShell commands are primarily for Windows users, and suggest alternatives for Linux/macOS users.
Where 'nslookup' is suggested, mention 'dig' as an alternative for Linux users.
For outbound IPv6 support, explicitly state the current limitations for Linux apps and provide guidance or workarounds for Linux users.
Include more Linux-native command-line examples (e.g., using curl, jq, grep) for querying and parsing Azure CLI output.
When referencing the Azure Cloud Shell, note that both Bash and PowerShell environments are available, and provide examples for both.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides only a PowerShell example (Remove-AzResourceGroup) for cleaning up resources, with no equivalent command for Linux users (such as Azure CLI or Bash). This suggests a bias towards Windows tooling and omits guidance for users on other platforms.

Recommendations:

Include Azure CLI examples (e.g., 'az group delete --name <your resource group name>') alongside PowerShell commands for resource group deletion.
When referencing command-line operations, provide both PowerShell and Bash/Azure CLI syntax to ensure cross-platform accessibility.
Clarify that the Azure Portal and Azure CLI are cross-platform options, and provide links or instructions for each where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-specific concepts, tools, and examples. It provides instructions and examples that are either exclusive to Windows environments (such as referencing the Windows registry, web.config, and Windows-specific patching), or do not mention Linux equivalents. The Kudu console examples and runtime version queries are all Windows-centric, and there is no guidance for Linux-based App Service plans. The only runtime configuration file mentioned is web.config (Windows/IIS), and the note about Node.js versioning explicitly references 'Windows App Service'.

Recommendations:

Include equivalent instructions and examples for Linux-based App Service plans, such as how to check OS and runtime versions on Linux.
Provide Linux-specific configuration file examples (e.g., appsettings.json, environment variables, or startup scripts) alongside web.config.
Clarify when instructions or examples apply only to Windows, and provide parallel Linux instructions where possible.
Mention Linux patching cadence and mechanisms if they differ from Windows.
In tables and code samples, add Linux shell commands (e.g., cat /etc/os-release, lsb_release -a) for querying OS information.
Avoid referencing Windows registry or Windows-specific tools without Linux alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Visual Studio (Windows-only) is presented as the primary IDE, with detailed, image-rich instructions, while Visual Studio for Mac is only mentioned in a table and not covered in the main flow. PowerShell is given a dedicated section, but Linux shell (bash) is only referenced via Azure CLI, and the PowerShell section explicitly recommends using Azure CLI for Linux. In PowerShell deployment steps, only Windows file paths and commands (e.g., Compress-Archive, cd bin\Release\net8.0\publish) are shown, with no Linux equivalents. Some PowerShell Linux deployment instructions are commented out and not visible to users. Throughout, Windows tools and patterns (e.g., Solution Explorer, right-click Publish) are emphasized, and screenshots are exclusively from Windows environments.

Recommendations:

Provide parity in instructions and screenshots for Linux and macOS users, especially for command-line and VS Code workflows.
Include explicit bash/zsh shell commands and file paths alongside PowerShell commands, particularly for packaging and deploying with Azure CLI.
Uncomment and surface the PowerShell Linux deployment instructions, or better yet, provide cross-platform PowerShell Core examples.
Add more guidance for Visual Studio for Mac and clarify any differences in steps or UI.
Balance the order of presentation so that cross-platform tools (CLI, VS Code) are not always secondary to Windows/Visual Studio.
Where possible, use neutral language and examples that work on all platforms, or clearly indicate platform-specific steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows and Visual Studio workflows, with all examples and instructions assuming a Windows environment and Visual Studio as the primary tool. There is no mention of Linux-based development environments, cross-platform tooling, or alternative editors/IDEs. All file paths, configuration steps, and screenshots are Windows/Visual Studio-centric. Tools like Log Parser and FTP instructions are Windows-oriented, and there are no CLI or Linux-native alternatives provided.

Recommendations:

Add equivalent instructions and examples for Linux and macOS environments, including how to troubleshoot and debug Azure App Service apps using VS Code, Azure CLI, or other cross-platform tools.
Include examples using Azure CLI, az webapp log, and remote debugging via VS Code or other editors, not just Visual Studio.
Provide guidance for accessing logs and files using SFTP/FTP clients available on Linux/macOS, and mention cross-platform tools for log analysis (e.g., jq, grep, awk, or open-source log viewers).
Mention and show how to configure and manage App Service apps using the Azure Portal and Azure CLI, not just through Visual Studio's Server Explorer.
When referencing file paths or configuration files, use platform-agnostic notation or provide both Windows and Linux/macOS examples.
List Linux/macOS alternatives to Windows-specific tools like Log Parser, or recommend open-source, cross-platform log analysis tools.
Explicitly state the supported platforms for each feature, and if something is Visual Studio/Windows-only, suggest alternative approaches for other platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation displays a mild Windows bias in the prerequisites section, where Windows and PowerShell options are listed before Linux alternatives, and there is a strong emphasis on Visual Studio Code (a Microsoft tool). However, the main Terraform examples are provided for both Linux and Windows containers in parallel, and the implementation steps use Bash commands, which are cross-platform. There are no missing Linux examples, but the ordering and tool recommendations slightly favor Windows users.

Recommendations:

List Linux/Bash options before Windows/PowerShell in the prerequisites to avoid the impression of Windows-first bias.
Include explicit mention that Bash commands work on both Linux and macOS, not just Windows (via WSL or Git Bash).
Provide alternative editor instructions for users who do not use Visual Studio Code (e.g., nano, vim, or other editors).
Clarify that the Azure Cloud Shell is available in both Bash and PowerShell, and works identically across platforms.
Where possible, balance the mention of Windows and Linux tools and avoid defaulting to Microsoft-centric tooling.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias in several ways: Windows-specific paths and tools are often mentioned before or instead of Linux equivalents (e.g., 'D:\home' before '/home'), and many environment variables and examples reference Windows concepts (such as IIS, Web Deploy, MSDeploy, and .NET/ASP.NET specifics) without always providing Linux or cross-platform alternatives. Some sections, especially around build automation and deployment, provide detailed Windows/Kudu/MSDeploy guidance but only briefly mention Oryx/Linux or relegate Linux info to separate tabs. Several environment variables are described as 'Windows only' or default to Windows behaviors, and some features/tools (like Web Deploy) are described in detail for Windows but not for Linux. There are also cases where Linux-specific examples or usage patterns are missing or less detailed.

Recommendations:

For every Windows-specific path or tool mentioned (e.g., 'D:\home', IIS, MSDeploy), provide the Linux equivalent (e.g., '/home', Nginx/Apache, Oryx) side-by-side or in parallel.
Ensure that all environment variable descriptions specify both Windows and Linux behaviors, defaults, and paths where applicable.
Where build and deployment automation is discussed, give equal prominence and detail to Oryx/Linux workflows as to Kudu/Windows workflows, rather than relegating Linux to a secondary tab.
Add Linux-specific examples and usage notes in all relevant sections, especially where only Windows or PowerShell examples are currently given.
Avoid Windows-centric language such as 'applicationHost.config', 'w3wp.exe', or '%HOME%' without also providing Linux context (e.g., 'web.config', 'dotnet', '/home', '$HOME').
Where features are not available or behave differently on Linux, clearly state this and provide Linux alternatives or workarounds if possible.
Review all tables and examples for parity, ensuring that Linux users can find relevant, actionable information without needing to infer or search elsewhere.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page shows some evidence of Windows bias. Windows-specific samples (such as 'basic Windows app', 'Windows container app', and 'App with MySQL on Windows') are present and sometimes precede or are more detailed than Linux equivalents. There is also a lack of parity in certain scenarios: for example, there is a sample for 'App with MySQL on Windows' but not for Linux, and Windows containers are mentioned without a Linux container counterpart. Additionally, the documentation does not provide Linux-specific tools, patterns, or examples where relevant.

Recommendations:

Ensure that for every Windows-specific sample (e.g., Windows app, Windows container, MySQL on Windows), there is a corresponding Linux sample (e.g., Linux app, Linux container, MySQL on Linux).
Present Linux and Windows examples in parallel or alternate their order to avoid always listing Windows first.
Add explicit Linux container deployment samples to match the Windows container example.
Where possible, mention cross-platform tools and avoid referencing only Windows-specific tools or patterns.
Review all scenarios to ensure Linux users have equivalent guidance and sample coverage.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally provides parity between Linux and Windows deployment options, especially in CLI and VS Code workflows. However, there are subtle biases: Windows-specific tools (e.g., Visual Studio Code, FileZilla) are mentioned without Linux alternatives; in the VS Code workflow, the Windows deployment path is more complex and described in greater detail, with additional troubleshooting steps and screenshots. The use of 'right-click' and GUI-driven instructions is more common in Windows contexts. Some sections (e.g., web.config generation) are only discussed for Windows, and Linux-specific troubleshooting or nuances are not equally covered. There is also a lack of explicit Linux tool recommendations (e.g., Linux FTP clients), and Windows is sometimes mentioned first or in more detail.

Recommendations:

When mentioning tools like Visual Studio Code or FileZilla, explicitly note their cross-platform availability or suggest Linux-native alternatives (e.g., GNOME Files, lftp, or command-line sftp).
Ensure that troubleshooting and configuration steps (such as web.config or build automation) are equally detailed for Linux, or explicitly state when they are not needed on Linux.
Balance the order of presentation: alternate between Linux-first and Windows-first examples, or present both together where possible.
Where GUI instructions are given (e.g., 'right-click'), clarify equivalent actions for Linux desktop environments or provide command-line alternatives.
Add Linux-specific tips or troubleshooting sections, especially for common issues (e.g., file permissions, case sensitivity, or package installation differences).
In all screenshots and walkthroughs, ensure that Linux and Windows environments are equally represented.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

While the documentation is focused on deploying Python apps to Azure App Service on Linux and generally uses cross-platform Azure CLI commands, there are several instances of Windows bias. In command examples, Windows-specific shells (PowerShell, Cmd) are often presented alongside or even before Bash, and in some cases, Linux-specific instructions are missing or less detailed. The use of 'py -3' (a Windows Python launcher) in PowerShell and Cmd examples, without clear Linux alternatives, may confuse Linux users. The documentation does not always provide parity in example commands or troubleshooting steps for Linux users.

Recommendations:

Ensure that Bash (Linux/macOS) examples are always presented first, especially in a Linux-focused quickstart.
Where multiple shell examples are given, provide equal detail and clarity for Bash/Linux as for Windows shells.
Avoid using Windows-specific Python launchers (like 'py -3') in cross-platform documentation; prefer 'python3' which works on Linux/macOS and is increasingly standard on Windows.
Explicitly note any differences in command usage or environment setup between Windows and Linux, rather than assuming cross-platform equivalence.
Review all troubleshooting and setup steps to ensure Linux users are fully supported and not directed to Windows-centric solutions.
Where possible, consolidate examples to use the most cross-platform commands (e.g., 'python3'), and only add platform-specific tabs where absolutely necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias in several areas. Windows-specific features and tools (such as IIS Application Initialization and .NET Core stdout logging) are discussed in detail, with Linux equivalents mentioned only briefly or as afterthoughts. Linux guidance is often limited to a single sentence or setting, lacking the depth and examples provided for Windows. There are no Linux-specific code samples or detailed configuration instructions, and Windows terminology and modules are referenced without parallel Linux explanations.

Recommendations:

Provide equally detailed Linux examples and explanations alongside Windows ones, especially for features like application initialization and logging.
Include Linux-specific tools, modules, and configuration patterns (e.g., NGINX/Apache warm-up, systemd service readiness, Linux logging best practices) where relevant.
When referencing Windows features (such as IIS Application Initialization), immediately follow with the Linux equivalent, including step-by-step instructions or links to relevant documentation.
Add sample configuration snippets or code for Linux environments, not just mention environment variables.
Ensure that all features and troubleshooting steps are described for both platforms, or clearly state if a feature is Windows-only and suggest alternatives for Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows-centric tools and workflows (such as Visual Studio, Solution Explorer, and PowerShell/Package Manager Console) and omitting Linux-native equivalents. It assumes the use of Windows development environments and does not provide parallel instructions for Linux users, particularly for publishing, package management, and local debugging. There is also a lack of explicit Linux or cross-platform guidance for key steps.

Recommendations:

Provide Linux and cross-platform alternatives for all development and deployment steps, such as using the dotnet CLI for package management and publishing instead of Visual Studio and Package Manager Console.
Include instructions for common Linux editors (e.g., VS Code, JetBrains Rider) and terminal-based workflows.
Offer examples for connecting to SQL Database using Linux-native tools (e.g., sqlcmd on Linux, Azure Data Studio) alongside SSMS.
Clarify which steps are platform-agnostic and which are Windows-specific, and provide equivalent commands or guidance for macOS and Linux.
Explicitly mention and demonstrate how to perform local debugging and authentication flows on non-Windows platforms.
Where screenshots are provided, include or reference Linux/macOS UI equivalents if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias. In troubleshooting steps, Windows-specific commands (e.g., 'ipconfig /flushdns') are mentioned without Linux/macOS equivalents. The FAQ references PowerShell cmdlets for resource movement but does not mention Azure CLI or cross-platform alternatives. There are no Linux or macOS-specific troubleshooting steps or examples, and Windows tools/commands are given exclusively or first in relevant contexts.

Recommendations:

When suggesting DNS cache clearing, include Linux/macOS equivalents (e.g., 'sudo systemd-resolve --flush-caches' or 'sudo dscacheutil -flushcache').
When referencing PowerShell cmdlets (e.g., Move-AzResource), also provide Azure CLI equivalents (e.g., 'az resource move').
Wherever commands or tools are mentioned, ensure parity by including cross-platform or OS-specific alternatives.
Add examples or notes for Linux/macOS users in troubleshooting steps, especially where platform-specific actions are required.
Review the documentation for other implicit Windows assumptions and address them to ensure inclusivity for all major platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation is focused exclusively on creating an Azure Windows web app, with no mention of Linux web apps or examples for Linux. All references, including verification steps, are tailored to Windows web apps, and there is no guidance or parity for Linux-based scenarios.

Recommendations:

Add a parallel section or quickstart for creating an Azure Linux web app with a backup using Terraform.
Include examples and code snippets for both Windows and Linux web apps, or clearly indicate how to adapt the steps for Linux.
In verification steps, show how to use the Azure CLI to check both Windows and Linux web apps, or clarify any differences.
Update the checklist and outputs to mention Linux web app scenarios where applicable.
Consider a more neutral title or provide links to equivalent Linux documentation for users interested in non-Windows stacks.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exclusively demonstrates deploying App Service on Windows, using only azurerm_service_plan with os_type set to 'Windows' and azurerm_windows_web_app resources. There are no examples or mentions of Linux-based App Service plans or azurerm_linux_web_app resources, nor any guidance for Linux users. This creates a Windows-centric bias and omits Linux parity for users who may wish to deploy Linux-based web apps.

Recommendations:

Add parallel examples for deploying Linux-based App Service plans using os_type = 'Linux' and azurerm_linux_web_app resources.
Explicitly mention that both Windows and Linux App Service plans are supported, and provide guidance or links for Linux scenarios.
Where possible, use neutral naming (e.g., azurerm_app_service_plan and azurerm_web_app) or show both Windows and Linux resource blocks to illustrate cross-platform support.
Clarify any differences in configuration or prerequisites between Windows and Linux App Service deployments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias by presenting detailed instructions and features for Windows App Service apps before Linux equivalents, and in some cases, omitting Linux support entirely (e.g., web server logging, detailed error messages, failed request tracing). Several advanced logging features are described as Windows-only, and examples or references to tools (such as Log Parser and W3C log formats) are Windows-centric. Linux and container scenarios are generally treated as secondary, with less detail and fewer examples.

Recommendations:

Provide equivalent, detailed step-by-step instructions and feature descriptions for Linux and container-based App Service apps wherever possible.
Explicitly state feature parity or limitations for Linux vs. Windows at the start of each relevant section, and link to Linux-specific alternatives or workarounds if a feature is not available.
Include Linux-specific examples for log access, streaming, and analysis (e.g., using Linux CLI tools, tailing logs, or parsing logs with common Linux utilities).
Mention and recommend cross-platform or Linux-native tools for log analysis, not just Windows tools like Log Parser.
Where features are Windows-only, suggest alternative approaches for Linux users (such as using OpenTelemetry, custom logging, or third-party monitoring solutions).
Ensure that all code and configuration examples are provided for both Windows and Linux stacks, or clearly indicate when a feature is not supported on one platform.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell and DOS commands as the primary or only command-line examples, mentioning Windows-specific tools (ProcDump, Sysinternals), and omitting equivalent Linux tooling or shell examples. The Kudu debug console is described in terms of PowerShell and DOS commands, with no mention of Bash or Linux commands. The guidance for managing and restarting the app highlights Azure PowerShell but does not mention Azure CLI or Linux-native approaches.

Recommendations:

Include examples and instructions for using Bash or Linux shell commands in the Kudu debug console, alongside PowerShell and DOS.
Mention and provide guidance for Linux-native diagnostic tools (e.g., gcore, strace, lsof) as alternatives to ProcDump for memory dumps and troubleshooting.
Reference Azure CLI commands for app management and restarting, not just Azure PowerShell, to ensure parity for Linux and cross-platform users.
When listing command-line options or tools, present cross-platform options together or in parallel sections, rather than defaulting to Windows-first.
Clarify that Kudu supports both Windows and Linux containers, and highlight any differences in available tools or shell environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias, particularly in the 'Set up your dev environment' section. Visual Studio for Windows is presented first and in greater detail, with Visual Studio for Mac and cross-platform options following. Windows-specific tools (Visual Studio, Azure PowerShell) are mentioned before their Linux/macOS equivalents. PowerShell is included as a primary authentication method, and the overall structure assumes familiarity with Windows-centric development environments and workflows.

Recommendations:

Reorder the 'Set up your dev environment' section to present cross-platform or Linux/macOS options (such as Azure CLI and Visual Studio Code) before or alongside Windows-specific tools.
Provide explicit Linux/macOS setup instructions and examples, including common shell environments (bash/zsh) and package managers (apt, yum, brew) for installing Azure CLI and SDKs.
Balance the detail level between Visual Studio for Windows and other development environments (VS Code, JetBrains IDEs, command-line).
Clarify that PowerShell is optional and provide equivalent bash/zsh commands where relevant.
Add troubleshooting tips or notes for Linux/macOS users, especially for authentication and environment setup.
Where possible, use neutral language and tool-agnostic instructions, emphasizing cross-platform compatibility.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by focusing on Windows-specific tools (IIS diagnostics, Procdump, PowerShell, web.config), referencing Windows in links and tool names, and omitting Linux-specific instructions or examples. Diagnostic and mitigation steps are described primarily in the context of Windows environments, with no mention of Linux equivalents or cross-platform alternatives.

Recommendations:

Provide Linux-specific examples and instructions for diagnostics, such as using Linux logs, strace, lsof, or other native tools.
When mentioning PowerShell or DOS commands in Kudu, also mention Bash and Linux shell support, and provide equivalent Linux command examples.
Reference both Windows and Linux App Service environments when discussing features like Application Insights Profiler, Kudu, and auto-heal, clarifying any differences.
Include links to Linux-focused documentation or blog posts where available.
Avoid Windows-centric terminology (e.g., web.config, IIS, Procdump) without also describing Linux alternatives (e.g., appsettings, NGINX/Apache logs, gcore for dumps).
Explicitly state when a feature or tool is only available on Windows, and suggest Linux workarounds or alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is structured with a clear separation between Windows and Linux instructions using pivots. However, the Windows section is presented first and is significantly more prescriptive, with detailed step-by-step instructions using Windows-specific tools (Visual Studio, Windows Explorer, PowerShell scripts, Docker for Windows). The Windows example is tightly coupled to the Windows ecosystem (e.g., installing fonts via Windows Explorer, using .sln files, and PowerShell scripts), while the Linux section is more generic, CLI-focused, and uses a different sample app (Django/Flask vs. ASP.NET). There is no Linux equivalent for the Windows-specific scenario (custom fonts in the OS), and the Windows workflow is heavily dependent on Visual Studio and PowerShell, with no cross-platform alternatives suggested.

Recommendations:

Provide Linux-first or at least parallel Linux and Windows instructions, ensuring neither is prioritized by order or detail.
For scenarios like installing custom fonts or OS-level dependencies, include a Linux example (e.g., installing fonts in a Linux container) to demonstrate parity.
Offer cross-platform alternatives to Visual Studio and PowerShell, such as VS Code, Docker CLI, or Bash scripts, and reference them in both pivots.
Where possible, use sample apps and workflows that are analogous across both platforms, so users can see how to achieve similar outcomes regardless of OS.
Explicitly mention when a scenario is only possible on Windows or Linux, and provide rationale or workarounds for the other platform.
Avoid assuming the user is on Windows in shared prerequisites or introductory sections; clarify platform-specific requirements in each pivot.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ uneven_detail

⚠️ windows_tools

Summary:

The documentation provides both Windows and Linux pivots for deployment steps, but Windows instructions and terminology are often presented first, and some details (such as directory structure and runtime versions) are clearer or more consistent for Windows. The use of Azure portal UI steps and references to 'Advanced Tools' (Kudu), which are more familiar to Windows users, further reinforce a Windows-centric approach. There is also inconsistent parity in runtime versions and directory naming between platforms.

Recommendations:

Alternate the order of Windows and Linux pivots throughout the documentation, or present Linux instructions first in some sections to avoid implicit prioritization.
Ensure that runtime versions and directory structures are consistent and clearly explained for both Windows and Linux (e.g., use the same Node.js version in both pivots unless there is a technical reason).
Where Azure portal tools are referenced (such as 'Advanced Tools'), clarify their availability and behavior on both Windows and Linux App Service plans.
Provide explicit notes or troubleshooting steps for Linux-specific issues, such as file permissions, case sensitivity, or differences in deployment tooling.
Review all examples and ensure that any command-line or portal-based steps are equally detailed and accurate for both platforms.
Consider adding a summary table or section comparing Windows and Linux behaviors, limitations, or best practices for App Service authentication.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation shows a clear Windows bias. Windows/PowerShell tools and workflows are prioritized or exclusively presented in several key steps, such as connecting to Azure SQL Database (using sqlcmd in PowerShell) and development environment setup (Visual Studio for Windows, Visual Studio Code, Azure PowerShell). There are no explicit Linux or cross-platform command-line examples for database access or development, and the instructions assume a Windows-centric development environment.

Recommendations:

Provide explicit Linux/macOS examples for connecting to Azure SQL Database, such as using sqlcmd in Bash or Azure Data Studio.
Include cross-platform development environment instructions, such as using Visual Studio Code or JetBrains Rider on Linux/macOS, and clarify how to configure authentication in those environments.
When showing command-line examples (e.g., sqlcmd), provide both Windows (PowerShell/cmd) and Linux/macOS (Bash) variants, including installation instructions for required tools on all platforms.
Avoid assuming Visual Studio for Windows as the default IDE; mention and provide parity for Visual Studio Code and other cross-platform editors.
Highlight any platform-specific differences or requirements, especially for .NET development on Linux/macOS.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page references Azure PowerShell and the Azure portal as the only methods for setting up peering, with no mention of Linux-native tools, CLI, or cross-platform alternatives. There are no examples or instructions for Linux users, and the focus on PowerShell and portal may implicitly favor Windows environments.

Recommendations:

Include instructions and examples for setting up peering using Azure CLI, which is cross-platform and works natively on Linux, macOS, and Windows.
Explicitly mention that Azure CLI can be used from Linux systems, and provide equivalent command examples.
If PowerShell is referenced, clarify that Azure PowerShell is available on Linux and macOS as well, or provide links to installation instructions for non-Windows platforms.
Ensure that walkthroughs and related content include Linux-friendly steps and screenshots where applicable.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a bias toward Windows and Microsoft-centric tools and workflows. It exclusively references Microsoft Azure services, Power BI, Azure SQL Server, and Microsoft Teams, all of which are more commonly associated with Windows environments. There are no examples, mentions, or guidance for Linux-based tools, open-source alternatives, or cross-platform workflows. The data repository and visualization tools are described in terms of their native integration with Microsoft products, with no mention of Linux-compatible or open-source equivalents.

Recommendations:

Include examples or references to Linux-compatible tools for data storage (e.g., PostgreSQL, MySQL) and visualization (e.g., Grafana, Kibana) alongside Azure SQL Server and Power BI.
Mention cross-platform alternatives for care coordination and dashboards, such as open-source messaging or dashboarding tools.
Clarify that Azure services can be accessed and managed from Linux environments, and provide CLI or REST API examples that are platform-agnostic.
Add notes or links to documentation for deploying and managing these services from Linux or macOS, not just Windows.
Balance the order of tool mentions, e.g., list open-source or cross-platform options before or alongside Microsoft-specific ones.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for deployment, resource review, and cleanup. However, it consistently presents Azure PowerShell (a Windows-centric tool) as an equal alternative to Azure CLI, and includes PowerShell prerequisites and instructions. There is no mention of Linux-specific considerations, nor are there examples for Bash scripting or other Linux-native tools. The structure and language assume parity between CLI and PowerShell, which may unintentionally prioritize Windows users or workflows.

Recommendations:

Clearly indicate that Azure CLI is cross-platform and preferred for Linux/macOS users, while PowerShell is primarily for Windows (unless using PowerShell Core).
Add explicit Bash shell examples or notes for Linux/macOS users, especially for file operations (e.g., saving the Bicep file).
Reorder sections to present Azure CLI examples before PowerShell, or clarify that CLI is the default for non-Windows environments.
Include a note or section on running these commands on Linux/macOS, including any differences in prerequisites or environment setup.
Remove or de-emphasize PowerShell prerequisites for users not on Windows, or provide equivalent Linux/macOS setup instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily biased toward Windows environments. All prerequisites, setup steps, and tooling (BitLocker, NTFS, WAImportExport tool) are Windows-specific. There are no instructions or examples for Linux or macOS users, and all command-line examples for disk preparation and encryption use Windows tools (manage-bde, BitLocker, PowerShell). The only cross-platform section is the Azure CLI, but it is only used for job creation, not for disk preparation or encryption.

Recommendations:

Clearly state at the beginning if the Azure Import/Export tool and workflow are only supported on Windows, and if so, explain why.
If Linux or macOS support is possible, provide equivalent instructions for preparing disks, encrypting with open-source tools (e.g., LUKS/dm-crypt), and copying data.
Mention and document any cross-platform alternatives or limitations explicitly.
If only Windows is supported, suggest workarounds for Linux users (e.g., using a Windows VM or container for disk preparation).
Add a table or section comparing Windows and Linux/macOS support for each step, so users can quickly see platform requirements.
For Azure CLI and PowerShell sections, clarify which steps are platform-agnostic and which require Windows.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_error_codes

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily through the use of Windows-specific error codes (e.g., 'UploadErrorWin32', Win32 error codes 267 and 123) and terminology. There are no examples or references to Linux-specific errors, file system behaviors, or tools. The documentation does not provide Linux-oriented troubleshooting steps or mention how logs/errors might differ on Linux systems.

Recommendations:

Include examples of errors and error codes that may be encountered on Linux systems, such as common Linux file system errors.
Clarify whether 'UploadErrorWin32' and related error codes are relevant only to Windows-formatted drives, and provide equivalent Linux error scenarios if applicable.
Add troubleshooting guidance for Linux users, including how to interpret logs and error messages on Linux.
Mention any differences in log formats or error handling between Windows and Linux environments.
If tools or commands are referenced (e.g., for viewing logs), provide both Windows (PowerShell, File Explorer) and Linux (bash, ls, cat) examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation is heavily biased towards Windows. All prerequisites, tool requirements, and usage examples are specific to Windows environments (e.g., requiring Windows 7 or newer, .NET Framework, BitLocker, and drive letters). There are no mentions of Linux or cross-platform alternatives, and all command-line examples use Windows paths and conventions.

Recommendations:

Clearly state in the introduction whether the tool is Windows-only, or provide Linux/macOS support if available.
If a Linux version or alternative exists, include equivalent installation and usage instructions for Linux.
Provide Linux-specific examples, including command-line syntax, file paths, and prerequisites (e.g., required packages, mounting drives).
Mention Linux-compatible encryption tools if BitLocker is not available, or provide guidance for preparing drives on Linux.
If the tool is not supported on Linux, suggest alternative workflows for Linux users or clarify the limitation explicitly.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation exhibits a strong Windows bias by exclusively referencing the WAImportExport tool, which is only available for 64-bit Windows operating systems. There are no Linux or macOS alternatives or examples provided, and the documentation does not mention any cross-platform tools or workflows. The use of BitLocker (a Windows-centric encryption technology) is also emphasized without discussion of Linux-compatible options. This effectively excludes Linux users from using the Import/Export service directly.

Recommendations:

Provide or reference a cross-platform (Linux/macOS) version of the WAImportExport tool, or document alternative workflows for non-Windows users.
Include explicit guidance or examples for Linux users, such as how to prepare drives, encrypt data, and interact with the Import/Export service from Linux systems.
Mention any third-party or open-source tools that can be used on Linux for similar purposes, if available.
If BitLocker is required, document how Linux users can interact with BitLocker-encrypted drives (e.g., using dislocker or similar tools), or provide alternative encryption options.
Clearly state the platform limitations at the beginning of the documentation and provide links to feature requests or feedback channels for non-Windows support.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell before CLI in the prerequisites for enabling soft-delete and purge protection, and by linking to a PowerShell-specific recovery command in the troubleshooting section. There are no explicit Linux or cross-platform command-line examples, and the documentation assumes use of the Azure Portal UI, which is platform-agnostic but does not address command-line parity for Linux users.

Recommendations:

When referencing enabling soft-delete and purge protection, list CLI instructions before or alongside PowerShell, and clarify that Azure CLI is cross-platform.
In troubleshooting sections, provide both PowerShell and Azure CLI (or REST API) equivalents for recovery operations, such as undoing key removal.
Include explicit Azure CLI examples for all key management operations, ensuring Linux users have clear, first-class guidance.
Where possible, provide bash shell script snippets or note any OS-specific considerations for Linux users.
Review all linked articles to ensure Linux and cross-platform parity is maintained throughout the documentation journey.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation is heavily focused on PowerShell scripts for automation, with all scripting examples and pipeline steps using PowerShell. While PowerShell 7 is cross-platform, there are no equivalent Bash or shell script examples, nor is there guidance for Linux-native tools or patterns. The documentation also references Visual Studio Code (a Microsoft tool) as the primary editor, and does not mention Linux-specific editors or alternatives. This creates a bias toward Windows and Microsoft-centric tooling, potentially making it less accessible for Linux-first users.

Recommendations:

Provide equivalent Bash or shell script examples for key automation steps, especially for generating configuration files and interacting with Azure services.
Include instructions and examples for using Azure CLI directly in Bash, where possible, instead of only PowerShell.
Mention and provide examples for Linux-native editors (e.g., Vim, Nano) alongside Visual Studio Code.
Clarify that all steps can be performed on Linux and macOS, and highlight any platform-specific considerations.
Reference and link to documentation for using Azure Pipelines with non-Windows agents and runners.
Consider providing a Docker-based workflow example for cross-platform parity.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation exhibits a Windows bias by exclusively referencing and providing examples for Windows-specific tools (e.g., WAImportExport.exe, BitLocker, PowerShell), omitting Linux equivalents or instructions. The disk unlocking and verification steps are Windows-centric, and there is no mention of how to perform these actions on Linux or macOS. PowerShell is given a dedicated section, and the only disk-unlock command provided is for a Windows executable, with no cross-platform alternatives.

Recommendations:

Provide instructions and examples for unlocking BitLocker-encrypted drives on Linux (e.g., using dislocker or cryptsetup) and macOS.
Include Linux/macOS command-line examples for verifying data transfer and reading logs.
Mention and document any cross-platform tools or third-party utilities that can be used in place of WAImportExport.exe.
Clearly indicate platform-specific requirements and offer parity in guidance for non-Windows users.
Where PowerShell is referenced, also provide Bash or shell script equivalents for Linux/macOS environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page exclusively references and provides examples for the Windows-based WAImportExport.exe tool, with all command-line examples using Windows file paths and syntax. There is no mention of Linux or cross-platform alternatives, nor are there any Linux-specific instructions or examples. The documentation refers to the tool as 'Microsoft Azure Import/Export Tool' but only demonstrates usage in a Windows context, and the tool's name and file paths reinforce this bias.

Recommendations:

Explicitly state whether the Azure Import/Export Tool is available for Linux or provide alternatives if it is not.
If a Linux version or equivalent CLI exists, provide parallel Linux command-line examples using Linux file paths and syntax.
If the tool is Windows-only, clearly mention this limitation at the beginning of the documentation.
Consider referencing or linking to cross-platform tools or scripts (e.g., Azure CLI, PowerShell Core, or REST API usage) that can be used for similar repair/validation tasks on Linux.
Ensure documentation parity by including troubleshooting or workflow guidance for users on non-Windows platforms.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily biased towards Windows: it requires the use of a Windows system, only provides Windows command-line and PowerShell examples, and references a Windows-only executable tool. There are no instructions or examples for Linux or macOS users, nor any mention of cross-platform alternatives.

Recommendations:

Clearly state in the prerequisites if the tool is Windows-only, and if so, explain why.
If possible, provide or reference a cross-platform version of the Azure Import/Export tool, or suggest alternatives for Linux/macOS users.
Include Linux (bash) and macOS terminal examples if the tool or equivalent functionality is available.
If the tool is not available for Linux/macOS, suggest using a Windows VM or container as a workaround, and provide guidance for those platforms.
Consider advocating for or developing a cross-platform version of the tool to ensure parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias, especially in the 'Use a custom DNS server' section, where only Windows-specific tools (Chocolatey, ARMClient via PowerShell) are mentioned for interacting with Azure APIs. There are no equivalent Linux/macOS instructions or examples. The troubleshooting section references tools like 'Test-NetConnection' (PowerShell), and while 'nslookup' is cross-platform, the context and order still favor Windows environments. No Linux-native package managers, CLI tools, or shell examples are provided.

Recommendations:

Provide equivalent instructions for Linux/macOS users, such as using curl or Azure CLI (az rest) to interact with Azure REST APIs instead of ARMClient.
Include installation instructions for ARMClient (if cross-platform) or suggest alternatives for Linux (e.g., using curl with authentication).
Mention Linux package managers (apt, yum, etc.) if third-party tools are required, or clarify that ARMClient is Windows-only.
In troubleshooting, include Linux-native commands (e.g., dig, host) alongside nslookup, and avoid referencing PowerShell-only tools like Test-NetConnection without alternatives.
Structure examples so that cross-platform or Linux instructions are given equal prominence, not just as an afterthought.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides detailed instructions and examples for creating an Azure HPC Cache using the Azure Portal, Azure CLI, and Azure PowerShell. However, there is a noticeable Windows bias: PowerShell (a Windows-centric tool) is given a dedicated section with detailed setup and usage instructions, while there is no equivalent section for Linux shell scripting or Bash. The CLI examples are generic but do not explicitly mention or show Linux-specific usage patterns (such as Bash scripting or Linux environment setup). There are no examples or guidance for Linux users beyond the Azure CLI, and no mention of Linux-native tools or workflows. The PowerShell section is more prominent and detailed than any Linux-specific guidance, reinforcing a Windows-first approach.

Recommendations:

Add a dedicated section or tab for Linux/Bash users, including Bash shell scripting examples for cache creation and management.
Explicitly mention that Azure CLI works cross-platform and provide Linux-specific setup steps (e.g., installing Azure CLI on Ubuntu, using Bash variables).
Balance the PowerShell section with equivalent Bash/Linux shell examples for all major operations.
Where PowerShell is mentioned, clarify its cross-platform availability, but also provide native Linux alternatives.
Include troubleshooting or environment setup notes relevant to Linux users (e.g., using Azure CLI in a Linux terminal, authentication differences, file path formats).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation for Azure Import/Export service demonstrates a strong Windows bias. All operating system requirements, software prerequisites, and usage instructions are exclusively focused on Windows platforms. Only Windows and Windows Server are listed as supported OSes, with no mention of Linux or macOS. Required tools and commands (e.g., PowerShell, .NET Framework, BitLocker) are Windows-specific, and all example commands use PowerShell. There are no Linux equivalents or guidance for non-Windows users.

Recommendations:

Explicitly state whether Linux and macOS are supported or unsupported for the WAImportExport tool and the Import/Export process.
If Linux/macOS are unsupported, provide a clear rationale and suggest alternative workflows for non-Windows users.
If partial support exists, document any available Linux-compatible tools or methods (e.g., using AzCopy, third-party BitLocker-compatible utilities, or mounting NTFS drives).
Include example commands for checking disk sector size and preparing disks on Linux (e.g., using lsblk, fdisk, or hdparm).
Mention cross-platform alternatives for required software (e.g., .NET Core, open-source disk encryption tools) where possible.
Ensure that documentation for related tools (like AzCopy) includes parity in examples and instructions for Linux and macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation references both Azure CLI and PowerShell for managing connectivity, but does not mention or provide examples for Linux-specific tools or workflows. PowerShell is a Windows-centric tool, and its mention alongside Azure CLI (which is cross-platform) without explicit Linux/Bash examples or guidance may imply a Windows-first approach. There are no Linux/Bash command examples or references to Linux firewall tools, and the documentation does not clarify how to perform equivalent tasks on Linux systems.

Recommendations:

Add explicit Linux/Bash command examples for managing firewall rules and querying DPS IP addresses.
Mention Linux-native tools (such as iptables, ufw, or firewalld) for firewall configuration alongside Windows firewall.
Clarify that Azure CLI is cross-platform and provide sample commands for both Windows (PowerShell/CMD) and Linux (Bash).
Avoid listing PowerShell before Azure CLI, or provide parallel examples for both environments.
Include a section or note for Linux users outlining any differences or additional steps required.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias, with Windows tools and workflows (such as Visual Studio, PowerShell, and Windows command prompts) being mentioned before or more prominently than Linux equivalents. In several sections, Windows-specific instructions and tools are detailed, while Linux alternatives are either briefly referenced, deferred to external links, or presented after the Windows instructions. Some programming language pivots (notably C and Python) assume a Windows-based machine by default. The use of PowerShell for key derivation is highlighted, and Visual Studio is the primary IDE discussed for C development, with Linux instructions relegated to linked SDK documentation. While Linux examples are present (notably for device key derivation and some SDK usage), they are less detailed or less immediately accessible.

Recommendations:

Present Linux and Windows instructions with equal prominence and in parallel, rather than defaulting to Windows-first.
For each programming language, provide explicit, step-by-step Linux setup and usage instructions alongside Windows instructions, rather than referring users to external SDK documentation for Linux.
Include Linux-native tools (e.g., gcc, make, VS Code, or CLion) as alternatives to Visual Studio for C/C++ development.
Where PowerShell is used for Windows, provide a Bash or Python script alternative for Linux/macOS in the same section.
Avoid language such as 'This tutorial is oriented toward a Windows-based workstation'—instead, state that the tutorial supports both Windows and Linux, and provide side-by-side instructions.
Ensure all command-line examples are shown for both Windows (cmd/PowerShell) and Linux (bash), especially for environment variable setting and running SDK samples.
Where possible, provide screenshots or terminal output from both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a clear Windows bias. Windows is mentioned first and most prominently throughout, with explicit references to 'your Windows machine' and 'Windows-based workstation.' Prerequisites and setup instructions focus on Windows tools (Visual Studio, CMD, Git Bash), and Linux alternatives are either relegated to external links or not described in detail. Command-line examples use Windows syntax (cmd) exclusively, and there are no explicit Linux shell (bash) equivalents. The only mention of Linux is a pointer to a separate tutorial, rather than integrated parity within the main flow.

Recommendations:

Provide parallel Linux/macOS instructions and examples alongside Windows steps, not just as external links.
Include bash shell equivalents for all command-line instructions (e.g., git, cmake, npm, pip, java commands).
Mention and support Linux-native tools (e.g., GCC, Clang, make) where Visual Studio is referenced, and clarify how to use them.
Adjust language to be platform-neutral (e.g., 'your development machine' instead of 'your Windows machine').
Where environment variables are set, show both Windows (set) and Linux/macOS (export) syntax.
For code editing and building, mention cross-platform editors (e.g., VS Code) and build systems (e.g., CMake, Maven) with Linux usage notes.
Ensure screenshots and UI instructions are not Windows-specific, or provide Linux equivalents where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows is often mentioned first when describing development environments and requirements. There are several references to Windows-specific tools and workflows, such as IoT Edge for Linux on Windows (EFLOW), and some example outputs (e.g., docker ps) are shown in PowerShell format. While Linux is supported and mentioned, Linux-specific instructions, troubleshooting, or examples are less prominent, and there are few, if any, explicit Linux shell or terminal examples. Some sections (e.g., Docker context, remote debugging) use Windows-centric paths or screenshots. There is a lack of explicit parity in examples and troubleshooting for Linux users.

Recommendations:

Ensure that all example commands and outputs are shown in both Windows (PowerShell/CMD) and Linux (bash) formats where appropriate.
When listing supported platforms or prerequisites, alternate the order of Windows and Linux, or mention Linux first in some sections.
Provide explicit Linux shell/terminal examples and troubleshooting steps, especially for Docker and SSH-related workflows.
Include Linux-specific notes, such as file paths, permissions, and common issues (e.g., Docker group membership, SELinux/AppArmor).
Add screenshots or terminal outputs from Linux environments alongside Windows examples.
Where Windows-only tools or workflows are mentioned (e.g., EFLOW), provide equivalent Linux-native alternatives or clarify when they are not needed on Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exclusively describes configuration steps using the Azure Portal UI and does not provide any command-line examples. There are no references to Windows-specific tools like PowerShell, but the absence of CLI examples (such as Azure CLI or Bash scripts) means Linux and cross-platform users lack parity. The documentation implicitly assumes a GUI workflow, which is more common on Windows, and does not address automation or scripting scenarios typical for Linux environments.

Recommendations:

Add Azure CLI examples for all major configuration steps, such as app registration, authentication provider setup, and permission assignment.
Where possible, provide Bash script snippets alongside any UI instructions to support automation and Linux users.
Explicitly mention that all steps can be performed on any OS using the Azure CLI or REST API, and link to relevant cross-platform guides.
If PowerShell or Windows tools are referenced in related content, ensure equivalent Linux/Bash/Azure CLI alternatives are provided and linked.
Include a section summarizing cross-platform options for managing authentication configuration, highlighting both GUI and CLI approaches.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows containers first and describes their SSH access in a brief, positive manner ('require no modifications'), while the Linux section is more detailed but only provides CLI-based SSH instructions for Linux containers. There are no equivalent CLI or PowerShell instructions for Windows containers, and the browser-based SSH session is only mentioned as working for Windows, with no parity in command-line access. This creates a 'Windows first' impression and omits Linux parity for browser SSH and Windows parity for CLI SSH.

Recommendations:

Present Linux and Windows container instructions in parallel, rather than always listing Windows first.
Provide explicit CLI or PowerShell instructions for accessing Windows containers via SSH, or clearly state if such access is not supported.
Clarify whether browser-based SSH is available for Linux containers and, if so, provide instructions.
If certain features are only available on one platform, explain the reason and suggest workarounds or alternatives for the other platform.
Ensure that both Linux and Windows sections have equivalent depth and example coverage, including troubleshooting tips and sample commands.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides a troubleshooting step for clearing the DNS cache that only mentions the Windows-specific command ('ipconfig /flushdns') and does not provide equivalent instructions for Linux or macOS users. No PowerShell scripts or Windows-only tools are otherwise present, but the only explicit command-line example is Windows-specific, and no Linux or cross-platform alternatives are mentioned.

Recommendations:

When providing troubleshooting steps such as clearing DNS cache, include equivalent commands 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').
If mentioning OS-specific commands, group them together and clearly label them for each operating system.
Review the documentation for other places where implicit Windows-first assumptions may exist and ensure parity by including Linux/macOS alternatives.
Consider adding a note or section on cross-platform DNS troubleshooting to help all users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) before mentioning the Linux equivalent, and by providing a detailed example path for Windows but only a brief note for Linux. There are no Linux-specific examples or step-by-step instructions, and the Linux path is only mentioned in a note, not in the main instructional flow.

Recommendations:

Provide Linux-specific examples alongside Windows examples, such as using '/home/site/wwwroot' in the main instructions and code snippets.
Rephrase instructions to mention both Windows and Linux paths equally, or use platform-agnostic language where possible.
Include a table or section explicitly comparing Windows and Linux behaviors and requirements for config file paths.
Add step-by-step Linux deployment instructions or references, not just a note.
Ensure that all examples and sample paths are provided for both platforms to improve parity and reduce confusion for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by referencing Windows first in the sample app quickstart link (with 'tabs=flask,windows,azure-cli,...'), and does not provide explicit Linux-specific or cross-platform deployment instructions or examples. While the core instructions are generally OS-agnostic (Python, Flask, environment variables), there is a lack of parity in showing Linux or WSL-specific commands, environment variable setup, or deployment flows, especially given the 'linux-related-content' tag.

Recommendations:

Provide explicit Linux/WSL/macOS instructions and examples alongside or before Windows ones, especially in quickstart links and deployment steps.
Ensure that all referenced quickstarts and code tabs include Linux and macOS options, not just Windows.
Add examples of setting environment variables and running the app on Linux (e.g., using export in Bash, systemd service setup, etc.).
Include Linux-specific deployment guidance for Azure App Service (e.g., using Azure CLI from Bash, VS Code on Linux, or GitHub Actions from Linux runners).
Review all links and ensure that Linux tabs are present and not omitted in favor of Windows.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation references using a dialog to set deployment settings, which is typically a Windows or Azure Portal pattern, without providing equivalent command-line or Linux-native instructions. There are no examples for Linux users (e.g., using environment variables in bash or CLI commands).

Recommendations:

Provide equivalent instructions for setting SCM_DO_BUILD_DURING_DEPLOYMENT using the Azure CLI or in a Linux shell.
Include examples for both Windows (PowerShell/cmd) and Linux (bash) environments.
Clarify whether the 'dialog' refers to the Azure Portal UI, and if so, link to CLI-based alternatives for cross-platform users.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in the 'Hybrid Connections' section, where it specifies that the required relay agent (Hybrid Connection Manager) must be installed on a Windows Server 2012 or newer host. There is no mention of Linux support or alternatives for this component. No command-line examples (PowerShell, Bash, etc.) are present, but the only explicit tooling requirement is Windows-based. This omission may mislead Linux users or limit their perceived options.

Recommendations:

Clarify whether Hybrid Connection Manager is available for Linux, and if so, provide installation and usage instructions for Linux hosts.
If Hybrid Connection Manager is Windows-only, explicitly state this limitation and suggest alternative approaches for Linux environments (such as VPN, VNet Integration, or other supported connectivity methods).
Wherever platform-specific requirements exist, present both Windows and Linux options (or note the lack thereof) to ensure parity and transparency.
Consider including examples or references for Linux-based deployments and tooling throughout the documentation, especially in sections discussing agent installation or network configuration.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation page presents Windows-related pivots (Visual Studio, PowerShell, CLI, Azure Portal) before Linux equivalents, and includes a dedicated PowerShell section for Windows but not for Linux. This ordering and tooling focus may suggest a Windows-first bias and heavier emphasis on Windows-native tools.

Recommendations:

Reorder the pivots so that Linux and Windows options are presented in a parallel or alternating fashion, or group them together for parity.
Add a Linux-specific CLI or shell example if not already present, to match the PowerShell coverage for Windows.
Ensure that Linux tools and workflows (such as Bash, Linux CLI, or VS Code on Linux) are given equal prominence and detail as Windows tools.
Consider including a table or matrix at the top summarizing all platform/tool combinations for quick navigation and parity.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses exclusively on scaling via the Azure Portal UI and does not provide any command-line examples. Where pricing details are mentioned, the link points to the Windows-specific App Service pricing page. There are no examples or references to Linux-specific workflows, tools, or parity considerations. This may implicitly bias the documentation toward Windows users or those deploying Windows-based apps, while Linux users are not directly addressed.

Recommendations:

Include CLI-based examples for scaling up App Service plans using Azure CLI (az), which is cross-platform and commonly used on Linux.
When linking to pricing details, provide both Windows and Linux App Service pricing pages, or clarify the differences.
Explicitly mention that the scaling process applies to both Windows and Linux App Service plans, and note any differences if they exist.
Add a section or note about scaling App Service plans for Linux-based apps, including any relevant considerations or links.
If screenshots are OS-specific, consider including Linux-relevant visuals or clarifying that the UI is the same regardless of OS.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a bias toward Windows by exclusively referencing Azure App Service (which is often associated with Windows hosting, though it can host Linux), and by omitting any mention of Linux-specific workflows, tools, or deployment patterns. All command-line instructions use Azure Developer CLI (azd), which is cross-platform, but there are no explicit Linux shell or deployment examples, nor any mention of Linux-specific considerations. The tutorial assumes the use of the Azure Portal and Codespaces, which are cross-platform, but does not address Linux environments or tools (e.g., SSH, systemd, Linux file paths, or troubleshooting on Linux-based App Service plans). There are no PowerShell-specific commands, but the absence of Linux-specific content or examples constitutes a subtle bias.

Recommendations:

Explicitly mention that Azure App Service supports both Windows and Linux hosting plans, and clarify which is being used in the tutorial.
Include Linux-specific notes or troubleshooting steps, such as how to access logs or environment variables via SSH on Linux App Service.
Provide examples of deploying and managing the app from a Linux terminal, including any differences in file paths, permissions, or environment variable configuration.
If the sample app or infrastructure is platform-agnostic, state this clearly to reassure Linux users.
Add a section or callout addressing any differences in behavior or setup between Windows and Linux App Service plans, especially for .NET/Blazor apps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Bash and PowerShell examples for most steps, but consistently presents Bash (Linux/macOS) examples before PowerShell (Windows) ones. However, PowerShell examples are present for every step, which is not always the case in cross-platform docs. There is no exclusive use of Windows tools or patterns, and Linux examples are not missing. The use of Azure CLI and kubectl is cross-platform, but the presence of PowerShell examples throughout may indicate a slight Windows bias, especially since PowerShell is not the default shell on most non-Windows systems.

Recommendations:

Clarify in the introduction that both Linux/macOS (Bash) and Windows (PowerShell) users are supported, and explain how to choose the appropriate tab.
Consider including a note that PowerShell Core is available cross-platform, but Bash is the default on most Linux/macOS systems.
Where possible, provide a single, unified script with cross-platform variable syntax, or explicitly mention any differences in environment variable handling between Bash and PowerShell.
Ensure that any references to file paths, environment variables, or shell-specific behavior are clearly marked as Bash- or PowerShell-specific.
If possible, add a short section or callout for users on WSL (Windows Subsystem for Linux), as this is a common cross-platform scenario.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation presents the Windows (IIS module) architecture before the Linux/containers architecture and references IIS (a Windows-specific technology) without mentioning equivalent Linux web server modules or patterns. There are no explicit Linux command-line or configuration examples, but the architecture section does acknowledge Linux/container deployments. No PowerShell or Windows-only CLI examples are present, and the only CLI examples use the cross-platform Azure CLI.

Recommendations:

Present Linux/container architecture before or alongside Windows/IIS to avoid the impression of Windows primacy.
When mentioning IIS modules for Windows, also mention the equivalent Linux web server context (e.g., NGINX/Apache modules or reverse proxy patterns), or clarify that the Linux/container implementation uses a sidecar/ambassador pattern.
Include Linux-specific operational notes or troubleshooting tips where relevant (e.g., log locations, integration caveats).
Ensure that all examples, especially CLI commands, are cross-platform (which is already the case here), and explicitly state that the Azure CLI commands work on Windows, Linux, and macOS.
If referencing file-based configuration, provide example file paths or commands for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides command-line examples for Azure CLI and Azure PowerShell, with PowerShell examples given equal prominence to CLI. However, there is a subtle Windows bias: PowerShell is a Windows-centric tool, and its inclusion as a primary example (alongside CLI) can be seen as favoring Windows users. Additionally, in the feature comparison table, 'Platform support' lists 'Windows, Linux, Windows containers' for regional integration but only 'Windows' for gateway-based, which is accurate but may reinforce a Windows-centric view. No Linux-specific shell (e.g., Bash) or scripting examples are given, and there is no mention of Linux-native tools or patterns. The documentation does not provide Linux-first or Linux-specific guidance, and PowerShell is not as commonly used on Linux as on Windows.

Recommendations:

Add explicit Bash shell examples (in addition to Azure CLI), showing commands as they would be run in a typical Linux environment.
Clarify that Azure CLI commands are cross-platform and can be run in Bash, Cloud Shell, or Windows Command Prompt.
Where PowerShell is shown, consider adding a note that PowerShell Core is available on Linux, or provide Bash alternatives for scripting scenarios.
In the prerequisites and migration steps, mention that all steps can be performed from Linux or macOS using Azure CLI.
Consider reordering examples to show Azure CLI (Bash) first, then PowerShell, to avoid a 'Windows first' impression.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by referencing 'local cache for Windows apps' as a mitigation for cold starts, without mentioning an equivalent or alternative for Linux-based App Service apps. There are no Linux-specific examples or guidance, and the only platform-specific advice is for Windows. No PowerShell or Windows-only tools are mentioned, but the omission of Linux parity is notable.

Recommendations:

Provide equivalent guidance or explicitly state options for Linux-based App Service apps regarding cold start mitigation (e.g., mention if local cache is available or suggest alternatives).
Include examples or notes for both Windows and Linux App Service environments where platform-specific features or behaviors are discussed.
Review all platform-specific recommendations to ensure Linux users are not left without guidance or workarounds.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents separate pivots for Java app deployment on Azure App Service, with Tomcat (Linux) and Java SE/JBoss (Windows) options. However, for Java SE and JBoss, only Windows-based instructions/examples are provided, while Linux-based equivalents are missing. This creates a bias by prioritizing Windows deployment scenarios for these runtimes and omitting Linux guidance.

Recommendations:

Add Linux-based quickstart pivots/examples for Java SE and JBoss runtimes, ensuring parity with the Windows instructions.
Ensure that for each Java runtime (Tomcat, Java SE, JBoss), both Windows and Linux deployment options are clearly documented and equally accessible.
Review included markdown files to verify that Linux instructions are present and up-to-date for all supported runtimes.
Consider presenting Linux and Windows options side-by-side or in a consistent order to avoid implicit prioritization.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page provides Terraform samples for Azure App Service, but the listed examples are exclusively focused on Windows-based App Service scenarios. There are no examples for Linux-based App Service deployments, and the scripts specifically mention 'Windows web app' and 'Windows container app' without Linux equivalents.

Recommendations:

Add Terraform sample scripts for creating and managing Linux-based App Service apps.
Ensure that for every Windows-specific example, there is a parallel Linux example (e.g., 'Create an Azure Linux web app with a backup').
Explicitly mention both Windows and Linux options in script descriptions and titles where applicable.
Consider a table structure that clearly distinguishes between Windows and Linux scenarios to help users find relevant samples for their platform.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes a development environment based on GitHub Codespaces and .NET, but does not provide any explicit Windows-specific commands or tools. However, it lacks any mention of Linux-specific workflows, terminal commands, or deployment patterns outside of the Codespaces/Azure CLI context. There are no PowerShell or Windows-only tools, but the absence of Linux-native examples (such as local development on Linux, or using Linux package managers) and the focus on .NET (which is cross-platform but often associated with Windows) may make the documentation less approachable for Linux users who do not use Codespaces.

Recommendations:

Add explicit instructions for running the sample app locally on Linux (e.g., Ubuntu), including installation of .NET SDK and any dependencies.
Provide terminal commands for both Windows (PowerShell/CMD) and Linux (bash) where relevant, especially for deployment and running the app.
Mention how to use local development environments outside of Codespaces, including Linux and macOS.
Clarify that all commands are cross-platform, or provide platform-specific notes if any step differs between Windows and Linux.
Include troubleshooting tips for common Linux-specific issues (e.g., file permissions, port conflicts, .NET installation).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation avoids overt Windows-specific tools and commands, but it demonstrates subtle Windows bias by omitting explicit Linux instructions or considerations. It assumes the use of GitHub Codespaces (cloud-based, cross-platform) and Azure CLI (cross-platform), but does not provide any Linux-specific guidance or troubleshooting. There are no PowerShell or Windows-only commands, but the lack of Linux-specific notes or parity checks (such as file path differences, environment variable handling, or local development outside Codespaces) may disadvantage Linux users.

Recommendations:

Add a section or notes about running the sample locally on Linux (e.g., Ubuntu), including any prerequisites or differences in environment setup.
Explicitly mention that all CLI commands (azd, az, dotnet) are cross-platform, and provide troubleshooting tips for common Linux issues (such as permissions, firewall, or dependency installation).
Include examples or screenshots from Linux environments, not just browser-based Codespaces.
If any steps differ on Linux (such as file permissions or case sensitivity), call these out in the instructions.
Encourage feedback from Linux users to further improve parity and documentation completeness.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation provides a C# client example (commonly associated with Windows environments) and does not include equivalent examples for Linux-prevalent languages or tools (such as curl, Python, or bash). There are no references to Linux command-line tools or cross-platform approaches, and the only code sample is Windows-centric.

Recommendations:

Add equivalent examples using curl or HTTPie to demonstrate how to set custom headers from a Linux or cross-platform command line.
Include sample code in other popular, cross-platform languages such as Python (requests), JavaScript (fetch or axios), or Java.
Explicitly mention that the feature is accessible from any platform that can set HTTP headers, not just via the C# client.
Ensure that future documentation provides parity between Windows-centric and Linux-centric tools and languages.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation references associating Peer ASN using a guide that is specifically for PowerShell (howto-subscription-association-powershell.md), which is a Windows-centric tool. There are no examples or instructions for Linux users or for using cross-platform tools like Azure CLI. The absence of Linux or cross-platform examples and the exclusive mention of PowerShell indicate a bias toward Windows environments.

Recommendations:

Provide equivalent instructions for associating Peer ASN using Azure CLI, which is cross-platform and works on Linux, macOS, and Windows.
Include explicit Linux/macOS command-line examples where relevant.
Reference both PowerShell and Azure CLI documentation links, and clarify which tools are supported on which platforms.
Consider including a table or section summarizing available tools (PowerShell, Azure CLI, Portal) and their platform compatibility.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exclusively describes configuration and management using the Azure portal UI, with no mention of command-line tools, scripts, or automation options for either Windows (e.g., PowerShell) or Linux (e.g., Azure CLI, Bash). However, the only tool mentioned is the Azure portal, which is a web-based interface and not OS-specific, but the absence of any Linux-friendly automation or CLI examples (such as Azure CLI commands) indicates a bias towards GUI-based workflows, which are more commonly associated with Windows environments. There is also an explicit statement that APIs are not supported and configuration can only be done via the Azure portal, further limiting Linux parity and automation options.

Recommendations:

Add equivalent Azure CLI (az) command examples for all portal-based steps, enabling Linux and cross-platform users to automate or script the process.
Document any REST API endpoints or planned API support, even if currently unavailable, to inform users about future automation possibilities.
If PowerShell or Windows-specific tools are not required, explicitly state that the process is OS-agnostic, but still provide CLI examples for parity.
Include troubleshooting and validation steps that can be performed from Linux environments (e.g., using curl, dig, or traceroute) where relevant.
Solicit feedback from Linux users to identify additional parity gaps in the onboarding and management process.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exclusively uses Azure Portal (GUI) and ARM template examples for configuration, with no mention of command-line tools such as Azure CLI, PowerShell, or Bash. While this avoids explicit Windows-only tools, the heavy reliance on GUI workflows and the absence of cross-platform CLI instructions (especially Azure CLI/Bash, which are common on Linux and macOS) results in an implicit Windows bias. The documentation does not provide Linux-friendly automation or scripting options, nor does it acknowledge non-Windows environments.

Recommendations:

Add Azure CLI examples for all major steps (enabling managed identity, assigning roles, updating encryption keys, etc.), as Azure CLI is cross-platform and widely used on Linux.
If PowerShell examples are included, ensure equivalent Bash/Azure CLI examples are provided and presented first or side-by-side.
Explicitly mention that all steps can be performed from any OS using Azure CLI or ARM templates, not just via the Azure Portal.
Include sample scripts or command snippets for Linux/macOS users to automate the process.
Review screenshots and instructions to ensure they do not assume a Windows environment (e.g., file paths, UI conventions).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation does not provide any platform-specific troubleshooting steps, but it implicitly assumes the use of Windows tools and workflows. There are no examples or instructions for Linux users, nor are Linux-compatible tools or commands mentioned. The guidance around deleting journal files and rerunning commands presumes familiarity with the default (Windows-based) Import/Export tool, which is not natively available on Linux.

Recommendations:

Include explicit instructions or notes for Linux users, such as how to manage journal files and run Import/Export operations using cross-platform tools or Azure CLI.
Mention whether the Import/Export tool is available for Linux, and if not, provide alternatives or workarounds.
Add troubleshooting examples or command-line snippets for both Windows (PowerShell/Command Prompt) and Linux (Bash/Azure CLI) environments.
Clarify any platform-specific limitations or requirements, such as file system compatibility or tool availability.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation shows a mild Windows bias by referencing 'time.windows.com' as the default NTP server and providing its IP address as an example. This is a Windows-centric default, and no alternative (e.g., pool.ntp.org) is mentioned. However, the command-line examples for network and storage checks are Linux/Unix-based (e.g., openssl, rpcinfo), and there are no PowerShell or Windows-only command examples. The documentation does not provide explicit Linux or Windows client setup examples, but the only NTP example is Windows-specific.

Recommendations:

Mention cross-platform NTP servers such as pool.ntp.org as alternatives to time.windows.com, or clarify that any standards-compliant NTP server can be used.
If referencing time.windows.com, also provide a Linux-friendly example (e.g., pool.ntp.org) and its configuration.
Explicitly state that the command-line examples (openssl, rpcinfo) are for Linux/Unix systems, and provide equivalent PowerShell or Windows commands if relevant, or clarify that Linux is the expected environment for these checks.
Ensure that any default values or examples (such as DNS or NTP servers) are not Windows-specific unless required by Azure, and if so, explain why.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exclusively describes how to create integration environments using the Azure Portal UI, which is a graphical interface most commonly associated with Windows workflows. There are no command-line examples (such as Azure CLI, PowerShell, or Bash), nor are there any references to Linux or cross-platform tooling. This approach implicitly favors Windows users and leaves out Linux-first or automation-focused users.

Recommendations:

Add equivalent instructions for creating integration environments using the Azure CLI, which is cross-platform and widely used on Linux and macOS.
If applicable, provide examples using Azure PowerShell and clearly indicate that PowerShell Core is available cross-platform.
Include screenshots or terminal output from Linux environments where relevant.
Explicitly mention that all steps can be performed from any OS using the Azure Portal, but highlight automation and scripting options for non-Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exclusively describes how to associate an ASN with an Azure subscription using the Azure portal, which is a web-based GUI. There are no command-line examples provided for any platform (Windows, Linux, or macOS), but the reliance on the Azure portal and absence of CLI/automation options can be considered a form of Windows-first bias, as enterprise Windows users are more likely to use GUI workflows. There is no mention of Linux tools, shell commands, or cross-platform automation methods (such as Azure CLI or PowerShell Core), and no guidance for users who may prefer or require non-GUI, scriptable approaches.

Recommendations:

Add step-by-step instructions for associating an ASN using the Azure CLI (az peering commands), which is cross-platform and works on Linux, macOS, and Windows.
Provide PowerShell Core examples for users who prefer scripting, making sure to specify that these work on all major platforms.
Include a section comparing portal, CLI, and PowerShell approaches, highlighting their cross-platform compatibility.
Explicitly mention that the Azure portal is web-based and accessible from any OS, but also provide automation-friendly alternatives for Linux and macOS users.
Ensure screenshots and terminology are not Windows-specific (e.g., avoid referencing Windows-only tools or UI conventions).

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exclusively references Microsoft-centric workflow tools (Power Automate and Azure Logic Apps) for integrating Azure IoT Central, with no mention of Linux-native or cross-platform alternatives, nor any command-line or scripting examples that would be relevant to Linux users. All examples and instructions are tailored to the Microsoft ecosystem, which is most commonly associated with Windows environments.

Recommendations:

Include examples or references for integrating with Azure IoT Central using cross-platform tools such as Azure CLI, REST API calls (with curl or similar), or open-source workflow engines (e.g., Apache Airflow, Node-RED) that can run on Linux.
Provide sample scripts or automation flows using bash, Python, or other languages commonly used on Linux.
Explicitly mention that Power Automate and Logic Apps are web-based and can be used from any OS, but also offer guidance for users who prefer or require Linux-native solutions.
Add a section comparing Microsoft workflow tools with open-source or third-party alternatives, and provide links or references for further reading.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page primarily describes how to manage public network access for Azure IoT Device Provisioning Service using the Azure Portal, with no command-line examples. Where command-line management is mentioned, it lists Azure CLI and PowerShell together, but does not provide any concrete examples for either, nor does it mention Linux-specific tools or workflows. The ordering of 'Azure CLI, PowerShell, or service APIs' puts the cross-platform CLI first, but the lack of examples for Linux users or explicit mention of Linux environments may leave Linux users underserved.

Recommendations:

Add explicit command-line examples for both Azure CLI and PowerShell, showing how to enable/disable public network access.
Ensure that Azure CLI examples are clearly marked as cross-platform and runnable on Linux, macOS, and Windows.
Include notes or sections specifically addressing Linux users, such as how to install and use Azure CLI on Linux.
If PowerShell examples are included, provide Bash equivalents to ensure parity.
Review the documentation for any implicit assumptions about the user's operating system and clarify where necessary.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation exclusively uses Azure CLI commands for all examples and does not provide any OS-specific instructions or examples. While Azure CLI is cross-platform and works on both Windows and Linux, there are no examples or mentions of Windows-specific tools (like PowerShell) or Linux-specific tools (like Bash scripts). However, the absence of any Linux-specific context or troubleshooting (such as shell differences, DNS tools, or networking commands) may leave Linux users without guidance for platform-specific scenarios.

Recommendations:

Explicitly mention that Azure CLI commands work on both Windows, Linux, and macOS, and provide installation links for each platform.
Where relevant, add Linux-specific troubleshooting tips (e.g., using dig or nslookup for DNS verification, checking network connectivity with curl or wget).
If there are any differences in behavior or prerequisites between Windows and Linux environments (such as file path formats, environment variables, or shell syntax), document these explicitly.
Consider including at least one example using Bash scripting for automation, or reference how to run the Azure CLI commands in a Linux shell.
If PowerShell or Windows-specific tools are not required, clarify that the instructions are platform-agnostic to reassure Linux users.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation presents both Windows and Linux default values for DNS settings in a table, but consistently lists Windows defaults before Linux. There are no platform-specific command-line examples (e.g., PowerShell or Bash), and the Azure CLI is used throughout, which is cross-platform. However, the ordering of Windows before Linux in explanations and tables subtly prioritizes Windows. There are also more notes about limitations on Windows (e.g., DNS over TCP not supported), but no equivalent Linux-specific notes or caveats.

Recommendations:

Alternate the order of Windows and Linux in tables and explanations, or present them alphabetically (Linux, Windows) to avoid implicit prioritization.
Add Linux-specific notes or caveats if any exist, to ensure parity of information.
Explicitly state that Azure CLI commands work identically on both Windows and Linux, or provide platform-specific notes if there are differences.
Where possible, use neutral phrasing (e.g., 'On Linux, the default is X; on Windows, the default is Y') rather than always listing Windows first.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation provides a conceptual overview of TPM attestation with Azure DPS but does not include any platform-specific examples or tooling instructions. However, it references 'the set of TPM tools being used, and the device operating system' without providing any concrete examples for either Windows or Linux. The absence of any examples or tool references means there is a lack of parity, but not explicit Windows bias. Still, Linux users may find the lack of Linux-specific guidance or examples limiting.

Recommendations:

Add practical examples for both Windows (e.g., using PowerShell or Windows TPM tools) and Linux (e.g., using tpm2-tools) to illustrate how to extract EK_pub and SRK_pub, take ownership, or clear a TPM.
Include references or links to official documentation for both Windows and Linux TPM management tools.
Explicitly mention common cross-platform tools (such as tpm2-tools for Linux) alongside any Windows tools, ensuring both are given equal prominence.
Provide example commands or scripts for both operating systems to help users perform key TPM operations relevant to DPS attestation.

Create pull request

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