1262
Pages Scanned
17
Pages Flagged
1262
Changed Pages
1.3%
% Pages Flagged

Scan Information

Started At: 2025-09-03 00:00:38

Finished At: 2025-09-03 00:28:27

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
Summary:
The documentation demonstrates a mild Windows bias by presenting Windows-related information and tools before their Linux equivalents. In the 'Premium V3 availability' section, the Windows SKU availability command is listed before the Linux one. The automation section provides both Azure CLI and Azure PowerShell examples, but PowerShell (a Windows-centric tool) is given a dedicated section, while no Linux shell (e.g., Bash) or scripting examples are provided. The use of Azure PowerShell is highlighted, but no mention is made of Linux-native scripting approaches beyond the CLI.
Recommendations:
  • Present Linux and Windows commands/examples in parallel or alternate their order to avoid always listing Windows first.
  • Include Bash shell scripting examples for automation, not just Azure CLI and PowerShell.
  • When referencing tools, clarify their cross-platform availability (e.g., Azure CLI runs on Windows, Linux, and macOS).
  • Explicitly mention that both Azure CLI and PowerShell can be used on Linux, and provide links or notes for Linux users.
  • Consider adding a table or section summarizing automation options for both Windows and Linux environments.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a strong Windows bias. All migration tools and examples focus exclusively on migrating from Windows environments, specifically from IIS servers, and rely heavily on PowerShell scripts. There is no mention of Linux-based hosting environments (such as Apache or Nginx on Linux), nor are there any Linux-specific migration tools, instructions, or examples. The documentation consistently refers to Windows tools and patterns, with no Linux parity.
Recommendations:
  • Add migration guidance and tooling for .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel).
  • Provide Linux shell (bash) script equivalents for PowerShell-based migration steps.
  • Include examples and walkthroughs for migrating .NET Core/ASP.NET Core apps from Linux environments to Azure App Service.
  • Mention and link to any Azure Migrate or App Service tools that support Linux-based workloads, or clarify current limitations.
  • Ensure documentation tables and tool descriptions clearly indicate OS support and provide parity where possible.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a subtle Windows bias. It references Windows-specific configuration files (web.config), mentions iisnode (a Windows IIS module) as the default Node.js integration, and omits Linux-specific equivalents or examples in several sections. Although there is a brief mention of running on Linux with PM2, the overall guidance and examples are Windows-centric, with Linux alternatives either missing or less emphasized.
Recommendations:
  • For features like auto-healing, provide Linux-specific configuration guidance (e.g., app settings, startup scripts) alongside or before Windows/web.config instructions.
  • When discussing Node.js hosting, explain the differences between iisnode (Windows) and PM2 or other process managers (Linux), and offer configuration examples for both platforms.
  • Wherever a Windows tool or pattern is mentioned (e.g., web.config, iisnode), explicitly mention the Linux equivalent or alternative, and provide code/configuration samples.
  • Ensure that troubleshooting and best practice sections include parity for both Windows and Linux App Service environments, with clear headings or callouts for each.
  • Consider adding a table or matrix summarizing which features and configurations apply to Windows, Linux, or both, to help users quickly find relevant guidance.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows-related information and tooling (e.g., PowerShell) are presented before Linux equivalents, and some instructions or examples are Windows-centric. While Linux is mentioned (e.g., Linux SKU availability), Linux-specific automation examples (such as Bash scripting) are missing, and PowerShell is highlighted as a primary automation tool. There is also a lack of parity in examples for Linux users, particularly in scripting and automation sections.
Recommendations:
  • Provide Linux/Bash scripting examples alongside PowerShell for automation tasks.
  • Ensure that Linux-specific instructions and tools are given equal prominence and are not always listed after Windows equivalents.
  • Include explicit Linux container deployment examples where relevant.
  • Clarify any differences in process or tooling for Linux users, especially where the Azure portal or CLI may behave differently.
  • Add a section or callout for Linux users to highlight any unique considerations or best practices.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows is frequently mentioned first in installation and usage instructions, and Windows-specific tools (such as the Hybrid Connection Manager GUI and PowerShell commands) are highlighted or exclusively available. Troubleshooting steps and connectivity tests use PowerShell commands without providing equivalent Linux commands. The Linux experience is often described as lacking features (e.g., no GUI), and some instructions are less detailed for Linux users.
Recommendations:
  • Alternate the order of Windows and Linux instructions so Linux is not always second.
  • Where PowerShell commands are given (e.g., Test-NetConnection), provide equivalent Linux commands (e.g., nc, telnet, or curl).
  • Expand Linux installation and usage instructions to match the detail level of Windows sections.
  • Where a GUI is not available on Linux, suggest or document equivalent CLI workflows and provide screenshots or examples.
  • In troubleshooting, provide Linux-native commands for DNS resolution (e.g., dig, host, nslookup) and connectivity testing.
  • Ensure all features and steps are covered for both platforms, or clearly state any limitations with suggested workarounds.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by focusing exclusively on Windows-based deployment and configuration patterns for ASP.NET apps. All runtime version examples reference Windows file paths and tools (CMD, PowerShell, Kudu), with no mention of Linux equivalents or how to perform these tasks on Linux-based App Service plans. There are no Linux-specific instructions or examples, and Windows tools and patterns are presented as the default or only option.
Recommendations:
  • Add parallel instructions and examples for Linux-based App Service plans, including how to check installed .NET runtimes and access diagnostic tools on Linux.
  • Include Linux shell (bash) commands and file paths where appropriate, alongside or in place of Windows CMD/PowerShell examples.
  • Clarify which instructions apply only to Windows-based hosting and provide clear guidance for Linux-based hosting scenarios.
  • Reference Linux-specific tools (such as SSH, bash, or Linux Kudu equivalents) where relevant.
  • Ensure that all configuration and troubleshooting steps are covered for both Windows and Linux environments to achieve parity.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
Summary:
The documentation provides both Linux and Windows instructions for configuring Tomcat data sources, but the Windows section is notably more detailed, with step-by-step PowerShell scripts and explicit use of Windows-specific tools and environment variables. The Windows approach relies heavily on PowerShell and Windows directory conventions, while the Linux instructions are more concise and assume familiarity with shell scripting and Linux tools. In some places, Windows examples and tools (like PowerShell and Windows paths) are presented before or more prominently than their Linux equivalents.
Recommendations:
  • Ensure Linux and Windows instructions are equally detailed, providing step-by-step guidance and example scripts for both platforms.
  • Avoid assuming greater familiarity with Linux tooling; provide explicit Linux shell script examples where PowerShell is used for Windows.
  • Present Linux and Windows instructions in parallel or in the same level of detail/order, rather than giving Windows first or more prominence.
  • Where possible, use cross-platform tools or highlight them (e.g., Azure CLI, bash scripts) instead of Windows-only tools like PowerShell.
  • Include troubleshooting and best practices sections for both Linux and Windows environments to ensure parity.
GitHub 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 servers within VMware environments, which are Windows-centric technologies. There are no references to 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 examples assume a Windows/IIS context, omitting Linux scenarios entirely.
Recommendations:
  • Include guidance and examples for discovering .NET apps hosted on Linux web servers (e.g., Apache, Nginx, Kestrel).
  • Mention whether Azure Migrate supports Linux-based .NET app discovery, and if not, clarify this limitation.
  • Provide parity in documentation by listing Linux discovery steps, tools, or limitations alongside Windows/IIS instructions.
  • Reference Linux-specific migration resources or tools where applicable.
GitHub 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. It exclusively references Windows tools, file paths, and configuration patterns (e.g., web.config, node.exe, named pipes, Win32 error codes, IIS, Kudu CMD/PowerShell). There are no Linux or cross-platform equivalents, examples, or troubleshooting steps provided. The entire guide assumes a Windows deployment and omits any mention of Linux-based App Service or general Node.js hosting best practices outside the Windows ecosystem.
Recommendations:
  • Add a parallel section or a separate guide for Node.js on Azure App Service Linux, covering equivalent configuration, troubleshooting, and best practices.
  • Include Linux-specific examples (e.g., using PM2, systemd, or NGINX as a reverse proxy) and reference Linux file paths and logs.
  • When discussing tools like Kudu, provide instructions for both CMD/PowerShell (Windows) and Bash (Linux) environments.
  • Avoid assuming the use of web.config, IIS, or iisnode; mention alternatives for Linux (e.g., app.js as entry point, environment variables, process managers).
  • Reference both Windows and Linux error codes and log locations where applicable.
  • Balance the order of presentation so that Linux and Windows are treated equally, or clearly indicate when content is Windows-specific in the title and introduction.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
⚠️ windows_first
Summary:
The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager endpoints, without offering equivalent Bash or cross-platform CLI scripts. References to running scripts assume a Windows/PowerShell environment, and there is no mention of Linux or macOS alternatives. The guidance for automation and scripting is Windows-centric, which may hinder users on Linux or macOS from following the instructions directly.
Recommendations:
  • Provide equivalent Bash or Azure CLI scripts for all PowerShell examples, especially for identifying Traffic Manager endpoints.
  • Explicitly mention that the PowerShell scripts can be run on PowerShell Core (cross-platform) or provide instructions for Linux/macOS users.
  • Where automation is referenced, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) alternatives, or clarify if a solution is cross-platform.
  • Add notes or links to documentation on running PowerShell scripts on non-Windows platforms if PowerShell is required.
  • Review all scripting and automation guidance to ensure Linux and macOS users are not excluded or forced to adapt Windows-centric instructions.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation provides both Linux and Windows instructions for most tasks, but there are several areas where Windows is prioritized or receives more detailed coverage. Windows-specific tools and patterns (such as Kudu, Advanced Tools, and web.config) are referenced, sometimes without Linux equivalents or with less detail for Linux. Some sections, like Java Flight Recorder usage, provide more step-by-step guidance for Windows (e.g., using Kudu Process Explorer), while Linux instructions assume more familiarity. In a few places, Windows is mentioned first or exclusively, and some advanced configuration notes are only present for Windows.
Recommendations:
  • Ensure that for every Windows-specific tool or workflow (e.g., Kudu, Advanced Tools, web.config), an equivalent Linux approach is described, or explicitly state if not applicable.
  • Balance the order of presentation: alternate between Linux-first and Windows-first, or present both platforms in parallel.
  • Provide equally detailed, step-by-step instructions for Linux as are given for Windows, especially for advanced diagnostics and configuration (e.g., finding Java process IDs, using SSH, log file locations).
  • Where Windows-specific notes are given (such as not needing web.config for Tomcat), add corresponding Linux notes or clarify if not needed.
  • Audit for any missing Linux examples, especially in sections where only Windows tools or paths are referenced, and add Linux equivalents.
  • Review terminology to avoid implying Windows is the default or primary platform (e.g., avoid phrases like 'on Windows you can...' without a Linux counterpart).
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a moderate Windows bias. It references Azure Storage Explorer with a direct link to Windows-specific instructions for generating an SAS, and does not provide equivalent Linux or cross-platform alternatives for this step. All command-line examples use Azure CLI, which is cross-platform, but the only GUI tool mentioned is Storage Explorer with a Windows tab. There are no Linux-specific examples or notes about using Storage Explorer on Linux/macOS, nor are alternative Linux-native tools (such as azcopy or command-line SAS generation) discussed.
Recommendations:
  • Provide explicit instructions or links for generating SAS tokens using Azure CLI or azcopy, which are cross-platform, instead of referencing only the Storage Explorer Windows tab.
  • Mention that Azure Storage Explorer is available on Linux and macOS, and provide relevant links or instructions for those platforms.
  • Ensure that all GUI tool instructions are either cross-platform or are supplemented with equivalent Linux/macOS command-line alternatives.
  • Avoid linking directly to Windows-specific tabs or documentation unless cross-platform alternatives are equally highlighted.
  • Add a note or section for Linux/macOS users on how to perform each step, especially for uploading files and generating SAS tokens.
GitHub Create pull request
Bias Types:
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page focuses exclusively on assessing ASP.NET web apps, which are traditionally Windows-centric, and does not mention Linux-based .NET web apps or provide examples/tools relevant to Linux environments. All referenced materials and linked tutorials implicitly assume a Windows context, with no guidance for users running .NET apps on Linux or using Linux-native tools.
Recommendations:
  • Include explicit mention of assessing .NET web apps hosted on Linux, such as ASP.NET Core apps running on Linux servers.
  • Provide examples or references for assessment tools and procedures that are compatible with Linux environments.
  • Add guidance or links for users who need to assess .NET apps deployed on Linux, including command-line examples using Bash or Linux-native utilities.
  • Clarify whether the assessment process and tools support both Windows and Linux hosting scenarios, and highlight any differences.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
Summary:
The documentation provides both Azure CLI and PowerShell examples for programmatic management, but PowerShell examples are often given equal or greater prominence, and some advanced scenarios (such as multi-source rules and Azure Front Door restrictions) are illustrated only with PowerShell. There are no explicit Linux shell/bash examples, and PowerShell is traditionally associated with Windows environments, which may disadvantage Linux users. However, the use of Azure CLI (which is cross-platform) mitigates this bias to some extent. There is no mention of Windows-specific tools or patterns outside of PowerShell usage.
Recommendations:
  • For every PowerShell example, provide an equivalent Azure CLI example, especially in advanced scenarios like multi-source rules and Azure Front Door restrictions.
  • Where possible, include bash shell script examples for common tasks, to better support Linux-native workflows.
  • Clarify that both Azure CLI and PowerShell are available in Azure Cloud Shell, which is cross-platform, to reduce perceived Windows bias.
  • Where PowerShell is shown first or exclusively, alternate the order or default to Azure CLI, as it is more universally accessible.
  • Explicitly state that all features are available regardless of the underlying OS of the App Service (Windows or Linux), and call out any exceptions if they exist.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a 'windows_first' bias by describing Windows container SSH access before Linux, despite Linux being the more common SSH use case. Additionally, it lacks parity in example depth: Windows containers are only described in terms of browser SSH (with no CLI or native SSH client instructions), while Linux containers receive detailed CLI and SSH client instructions. There are no PowerShell or Windows-native SSH client examples, but the lack of equivalent CLI/SSH client instructions for Windows containers constitutes a 'missing_linux_example' bias in reverse (i.e., missing Windows parity for CLI/SSH).
Recommendations:
  • Reorder sections to present Linux and Windows instructions in parallel or start with Linux, as SSH is more commonly associated with Linux.
  • Provide equivalent CLI/SSH client instructions for Windows containers, if supported, or clearly state their absence and suggest alternatives.
  • If Windows containers support SSH via native Windows tools (e.g., PowerShell, Windows OpenSSH client), include those examples.
  • Ensure both Linux and Windows sections have comparable depth and clarity in their instructions, including troubleshooting and example outputs.
  • Explicitly mention any platform limitations (e.g., 'SSH via CLI is not supported for Windows containers') early and clearly.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) before mentioning the Linux equivalent, and by providing only a Linux path as a note rather than as a first-class example. There are no Linux-specific examples or step-by-step instructions, and the primary example uses a Windows path. Linux users may find it less clear how to apply the instructions to their environment.
Recommendations:
  • Present both Windows and Linux file paths in all examples, or use platform-agnostic language (e.g., '<project root>/auth.json').
  • Include explicit Linux examples alongside Windows ones, especially in step-by-step instructions.
  • In the 'Enable file-based configuration' section, show both Windows and Linux paths in the main text, not just in a note.
  • Clarify any platform-specific differences (such as path requirements) in a dedicated section or table for quick reference.
  • Consider providing a table or code block showing both Windows and Linux configuration file paths side by side.
GitHub Create pull request
Bias Types:
⚠️ windows_first
Summary:
The documentation presents default values and behaviors for both Windows and Linux, but consistently lists Windows defaults before Linux in tables and explanations. There are no explicit examples or commands that are Windows-specific (such as PowerShell), nor are there Windows-only tools or patterns promoted. However, the ordering and phrasing (e.g., 'Windows default value' before 'Linux default value') may subtly prioritize Windows. There are no missing Linux examples, but the note about Windows Container apps and a limitation specific to Windows are called out, which is appropriate but could be balanced with Linux-specific notes if relevant.
Recommendations:
  • Alternate the order in which Windows and Linux defaults are presented, or present them in parallel columns to avoid implicit prioritization.
  • Where possible, provide Linux-specific notes or limitations alongside Windows ones for parity, or explicitly state when there are no such limitations on Linux.
  • If there are platform-specific CLI commands or behaviors, provide both Windows and Linux examples, or clarify when commands are platform-agnostic.
  • Consider a summary table at the start that clearly delineates differences and similarities between Windows and Linux App Service environments.
GitHub Create pull request

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