Scan Details - Linux-first Docs for Azure

1057

Pages Scanned

37

Pages Flagged

1057

Changed Pages

3.5%

% Pages Flagged

Scan Information

Started At: 2025-09-04 00:00:39

Finished At: 2025-09-04 00:22:39

Status: completed

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 tools and patterns (such as web.config and iisnode) without providing equivalent Linux guidance or examples. Linux-specific instructions are minimal and appear after Windows-centric advice. There are no Linux command-line examples or references to Linux-native configuration files, and the use of Windows terminology (like web.config) is presented as the default.

Recommendations:

Provide Linux-specific configuration examples alongside Windows examples, such as using app settings or environment variables instead of web.config for auto-healing.
Include Linux-native process management and monitoring tools (e.g., systemd, supervisord) in addition to iisnode and web.config.
When mentioning tools like iisnode or web.config, clarify their applicability (Windows only) and immediately offer Linux alternatives.
Add examples for configuring Node.js apps on Linux App Service (e.g., startup commands, environment variables) and reference Linux-specific documentation.
Ensure that troubleshooting and best practice sections include parity for both Windows and Linux hosting environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by presenting Windows SKU availability before Linux, providing Azure PowerShell automation examples (which are Windows-centric), and referencing Windows-specific patterns and tools. While Linux is mentioned and a Linux-specific CLI command is given for SKU availability, there are no Linux shell (bash) or scripting examples, and PowerShell is presented as a primary automation tool. The documentation does not offer parity in Linux-native scripting or tooling guidance.

Recommendations:

Present Linux and Windows options in parallel, or alternate which is shown first to avoid a Windows-first impression.
Include Linux-native automation examples, such as bash scripts using Azure CLI, alongside PowerShell examples.
Clarify that Azure CLI is cross-platform and can be used on both Windows and Linux, and provide example commands in both environments.
Where PowerShell is referenced, note its availability on Linux, or provide bash equivalents.
Ensure that any references to Windows-specific tools or patterns are matched with Linux equivalents, or clearly state any platform limitations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only automation example for identifying impacted Traffic Manager profiles, without offering equivalent Bash, Azure CLI, or cross-platform alternatives. References to 'Open PowerShell' and running '.ps1' scripts assume a Windows environment. No Linux shell or Bash examples are provided for these scenarios, and there is no mention of how to perform these tasks on non-Windows platforms.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for all PowerShell automation examples, ensuring Linux and macOS users can perform the same tasks.
When referencing downloadable scripts, offer both PowerShell and Bash versions, or clarify how to run PowerShell scripts on Linux/macOS (e.g., via PowerShell Core).
Avoid instructions that assume the user is on Windows (e.g., 'Open PowerShell'); instead, use cross-platform language such as 'Open your terminal or command prompt'.
Explicitly mention cross-platform compatibility for scripts and tools, and provide guidance for users on Linux/macOS where necessary.
Where possible, use Azure CLI or REST API examples as the primary automation method, as these are natively cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation attempts to provide parity between Windows and Linux, but there are several areas where Windows is prioritized or Linux is underrepresented. Windows examples and tools (such as Kudu, Advanced Tools, and FTPS) are sometimes mentioned first or exclusively. Some instructions, especially around process management and diagnostics (e.g., finding Java PIDs, using Kudu/Process Explorer), are Windows-centric or lack equivalent Linux guidance. There are also references to Windows-specific conventions (like web.config) and tools without always providing Linux alternatives or clarifying differences. In some cases, Linux-specific details are present but less detailed or less prominent than their Windows counterparts.

Recommendations:

Ensure that for every Windows-specific tool or workflow (e.g., Kudu, Process Explorer, FTPS), there is a clear Linux equivalent or an explicit note if not available.
When presenting examples or instructions, alternate the order (sometimes Linux first) or present both platforms side-by-side to avoid 'windows_first' bias.
Expand Linux troubleshooting and diagnostic sections to match the detail provided for Windows (e.g., how to find Java PIDs, manage files, or access logs without Kudu).
Avoid referencing Windows-only files (like web.config) in a way that could confuse Linux users; clarify when something is not applicable.
Where possible, provide cross-platform CLI examples and highlight any differences in behavior or file locations between Windows and Linux.
Review all included links and references to ensure Linux documentation is as comprehensive and discoverable as Windows documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page exhibits a strong Windows bias. All migration tools and examples focus exclusively on migrating from Windows environments, specifically IIS servers, and make extensive use of Windows-specific tools such as the App Service Migration Assistant (Windows MSI) and PowerShell scripts. There is no mention of Linux-based .NET hosting environments (e.g., Apache, Nginx, Kestrel on Linux), nor are there migration paths, tools, or examples for Linux-hosted .NET apps. The documentation repeatedly references Windows containers and IIS, and does not provide parity for Linux users.

Recommendations:

Add documentation and tooling for migrating .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Include Linux-specific migration examples and workflows, such as using Bash scripts or Linux-native tools.
Mention Linux migration scenarios alongside Windows scenarios, rather than focusing exclusively on Windows/IIS.
Provide parity in downloadable tools (e.g., a Linux-compatible migration assistant or containerization scripts).
Clarify in the documentation which tools are Windows-only and provide alternatives or guidance for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias, particularly in the .NET/ASP.NET Core sections, where Windows tools (Visual Studio, Azure PowerShell) are listed before cross-platform or Linux-native tools. Some quickstart links and examples default to Windows or PowerShell, and the 'Next step' call-to-action promotes an ASP.NET (typically Windows-centric) workflow. In contrast, Linux and CLI-first options are less prominent or appear later, and in some stacks (e.g., Python), Windows is included in the quickstart tabs even for Linux scenarios.

Recommendations:

Ensure all stacks provide both Windows and Linux examples equally, with clear labeling and parity in depth.
When listing tools or workflows, alternate the order or group by platform rather than listing Windows tools first.
Provide Azure CLI and Bash examples alongside or before PowerShell, especially in quickstart and deployment guides.
Review quickstart links and tabs to ensure Linux options are not hidden behind Windows defaults or tabs.
For the 'Next step' section, offer multiple next steps for different platforms/stacks, not just ASP.NET/Windows.
Highlight cross-platform tools (e.g., Visual Studio Code, Azure CLI) as primary options where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by listing Windows SKU availability before Linux, providing both Azure CLI and Azure PowerShell automation examples (with PowerShell being Windows-centric), and referencing Windows containers before Linux containers. There are no Linux shell-specific examples or explicit Linux command-line instructions beyond the Azure CLI, and PowerShell is presented as a primary automation tool.

Recommendations:

Present Linux and Windows options in parallel or alternate their order to avoid always listing Windows first.
Include Bash or shell script examples for automation, not just Azure CLI and PowerShell.
When referencing containers, alternate or combine mentions of Windows and Linux containers, or explicitly state support for both up front.
Clarify that Azure CLI commands work identically on Linux, macOS, and Windows, and provide any OS-specific notes if needed.
Consider adding a section or callout for Linux users, especially for automation and scripting scenarios.

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. PowerShell commands are used for connectivity tests without Linux equivalents. The GUI for Hybrid Connection Manager is only available on Windows, and the documentation provides more detailed, step-by-step guidance for Windows users. Linux instructions are present but sometimes less detailed or refer users to other sections. Some troubleshooting steps and tools (e.g., Test-NetConnection) are Windows-specific, with no direct Linux alternatives provided.

Recommendations:

Provide Linux equivalents for all PowerShell commands (e.g., use 'nc', 'telnet', or 'curl' for connectivity tests).
When listing instructions or tools, present both Windows and Linux options side by side, or alternate which comes first.
Expand Linux installation and usage instructions to match the detail level of Windows sections.
Offer guidance on using common Linux troubleshooting tools (e.g., 'nslookup', 'dig', 'ss', 'netcat') where only Windows tools are mentioned.
Clarify any feature parity differences (such as the absence of a GUI on Linux) and suggest alternative workflows for Linux users.
Ensure all screenshots and examples have Linux equivalents where possible, or provide terminal output samples for Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias. It assumes the use of Windows-based App Service instances, referencing Windows file paths, tools (CMD, PowerShell, Kudu), and Visual Studio workflows exclusively. There are no Linux-specific instructions, examples, or mentions of Linux-based App Service environments for ASP.NET (non-Core) apps. Linux equivalents for listing .NET Framework versions, accessing diagnostic tools, or configuring the environment are missing.

Recommendations:

Add explicit notes clarifying whether instructions apply to Windows, Linux, or both App Service environments.
Provide Linux-specific instructions or clearly state if certain features (e.g., .NET Framework, not .NET Core) are only available on Windows App Service.
Include examples using Linux tools (e.g., Bash, SSH, Linux file paths) where applicable, or explain the lack of support.
Mention and link to documentation for running ASP.NET apps in Linux containers, if that's the only Linux option.
Balance the order of presentation: if both Windows and Linux are supported, present them side-by-side or alternate which comes first.
Clarify that Visual Studio and Kudu are Windows-centric tools, and suggest alternatives for Linux-based workflows (e.g., VS Code, Azure CLI, FTP/SSH).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring server-level data sources in Tomcat, but the Windows section is notably more detailed, with step-by-step PowerShell scripts and explicit use of Windows-specific tools and paths. The Windows instructions are longer, more prescriptive, and introduce Windows tools (PowerShell, cmd, Windows paths) before or more prominently than their Linux equivalents. The Linux section, while present, is less detailed and assumes more prior knowledge. There is also a reliance on PowerShell and Windows environment variables in the Windows section, which is not matched by equivalent Linux scripting guidance.

Recommendations:

Ensure Linux and Windows sections have parity in detail and step-by-step guidance. For example, provide a full sample Linux shell script (not just a snippet) for the startup process, similar to the PowerShell script for Windows.
Introduce Linux instructions before or alongside Windows instructions, rather than after, to avoid a 'Windows-first' impression.
Where Windows-specific tools (like PowerShell) are used, provide equivalent Linux shell (bash/sh) scripts and explain their usage in equal detail.
Use neutral language and structure (e.g., present both OS tabs together, or default to Linux if usage data supports it).
Explicitly mention any differences in capabilities or limitations between Linux and Windows App Service environments.
Where possible, use cross-platform tools or commands (e.g., Azure CLI) in examples, and clarify any OS-specific steps.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by referencing Azure Storage Explorer (a GUI tool with a primary focus on Windows) for uploading files and generating SAS tokens, and by linking specifically to the Windows tab for SAS generation. There are no explicit Linux or cross-platform CLI examples for these steps, and no mention of Linux-native tools or workflows for uploading files or generating SAS tokens. All command-line examples use Azure CLI, which is cross-platform, but the initial file upload and SAS generation steps are Windows-centric.

Recommendations:

Provide CLI-based examples (using az storage blob upload and az storage blob generate-sas) for uploading files and generating SAS tokens, which work on both Linux and Windows.
Mention and link to Linux/macOS-compatible alternatives to Azure Storage Explorer, or clarify that Storage Explorer is available cross-platform.
Avoid linking only to the Windows tab for Storage Explorer instructions; ensure parity by including Linux/macOS tabs or CLI alternatives.
Include a note or section specifically addressing Linux users, outlining equivalent steps for file upload and SAS generation.
Where GUI tools are mentioned, always provide a CLI alternative for parity.

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 hosting scenarios, Linux web servers (such as Apache or Nginx), or discovery of .NET Core/ASP.NET Core apps running on Linux. All examples and capabilities are described in the context of Windows tools and environments.

Recommendations:

Include information about discovering .NET (Core) web apps hosted on Linux servers, including supported distributions and web servers (e.g., Apache, Nginx).
Provide parallel documentation and examples for Linux-based environments, not just IIS/Windows.
Clarify whether Azure Migrate supports Linux-hosted .NET apps and, if so, describe the process and any differences.
Mention any limitations or roadmap items if Linux discovery is not currently supported.
Ensure that references and linked resources also cover Linux scenarios where applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows using iisnode. All configuration and troubleshooting steps reference Windows-specific tools, file paths, and concepts (e.g., web.config, named pipes, Win32 error codes, node.exe, Kudu CMD/PowerShell). There are no equivalent examples or guidance for Linux-based App Service environments, nor are cross-platform considerations discussed.

Recommendations:

Add a parallel section or separate article for Node.js on Azure App Service Linux, covering best practices and troubleshooting steps relevant to Linux environments.
Provide Linux-specific examples, such as using PM2 or systemd for process management, and reference Linux file paths and logging locations.
Include instructions for accessing the Kudu SSH/Bash console on Linux App Service, not just CMD/PowerShell.
When discussing configuration (e.g., process management, logging, debugging), mention both Windows (iisnode/web.config) and Linux (e.g., PM2/ecosystem.config.js, environment variables) approaches.
Clarify at the start of the article that the content is Windows-specific, and provide clear links to Linux-focused documentation.
Balance the order of presentation so that Linux and Windows approaches are given equal prominence where both are supported.

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-based CLI examples for per-app scaling, with no equivalent examples for Linux-native tools (such as Azure CLI/bash). The exclusive use of PowerShell cmdlets and the absence of Linux or cross-platform command-line instructions may hinder accessibility for Linux or macOS users. Additionally, the documentation metadata and custom tags emphasize Azure PowerShell, reinforcing the Windows-centric approach.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands shown, using bash syntax to support Linux/macOS users.
Explicitly mention that both PowerShell and Azure CLI can be used, and provide guidance for users on different platforms.
Include a section or callout for Linux/macOS users, highlighting any differences or considerations.
Review and update documentation metadata and custom tags to reflect cross-platform tooling, not just Azure PowerShell.
Consider the order of presentation: present Azure CLI and PowerShell examples side-by-side or with equal prominence, rather than PowerShell first or exclusively.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation displays a moderate Windows bias. PowerShell is featured prominently as a primary automation tool, and there are no explicit Linux shell (bash) or cross-platform scripting examples outside of Azure CLI. In several sections, PowerShell examples are provided, but Linux-native equivalents (e.g., bash scripts, curl commands) are missing. The documentation assumes familiarity with PowerShell and Windows tooling, and does not address Linux-specific workflows or tools beyond the Azure CLI.

Recommendations:

Add bash and curl examples alongside PowerShell for token retrieval and identity management, especially in sections currently showing only PowerShell scripts.
Explicitly mention that Azure CLI commands are cross-platform and provide sample shell scripts for Linux/macOS environments.
Where PowerShell is used for automation, provide equivalent bash scripts or note any limitations for Linux users.
In sections where PowerShell is the only programmatic example (e.g., retrieving tokens, assigning identities), ensure parity by including Linux-native command-line examples.
Review the ordering of examples to avoid always listing Windows/PowerShell first; consider rotating or grouping by platform.
Clarify in notes or callouts when a feature or command is not available on Linux, and suggest alternatives if possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias. While the content is mostly platform-neutral, there are sections that provide detailed information and calculations specifically for Windows Containers, without equivalent details for Linux containers. Windows-specific features and limitations (such as extra IP usage for Windows Containers) are discussed in depth, while Linux-specific scenarios are only briefly mentioned (e.g., a short note about Linux continuous deployment network dependencies). There are no Linux command-line or configuration examples, and the troubleshooting and management sections reference tools and UI patterns more familiar to Windows users (e.g., Kudu console UI), with no mention of Linux equivalents.

Recommendations:

Add equivalent sections for Linux Containers, including subnet/IP usage calculations and any unique limitations or considerations.
Provide Linux-specific examples or notes where Windows-specific ones are given (e.g., if Windows Containers have extra IP requirements, clarify if/how Linux Containers differ).
Include Linux command-line examples (e.g., using Azure CLI or Bash) for common tasks such as configuring VNet integration, in addition to or instead of portal/UI instructions.
Reference Linux-friendly tools (such as SSH, Bash, or Linux-native troubleshooting utilities) alongside or instead of Windows-centric tools like Kudu.
Ensure parity in troubleshooting steps and management guidance for both Windows and Linux hosting scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias in several ways: Windows-specific deployment methods (Web Deploy) are described in detail, with explicit instructions to use Windows agents, while Linux alternatives are not discussed. The FAQ and error messages focus on Windows agent requirements, and there is no equivalent coverage for Linux deployment tools or troubleshooting. Examples and templates often default to .NET/ASP.NET (traditionally Windows-centric), and Windows-specific deployment patterns (e.g., Web Deploy, IIS references) are mentioned without Linux parity.

Recommendations:

Provide equivalent Linux deployment examples, especially for scenarios where Web Deploy is not available (e.g., using zip deploy, FTP, or Kudu REST API on Linux agents).
Include troubleshooting steps and error messages relevant to Linux agents, not just Windows.
When referencing deployment methods, mention Linux-compatible alternatives alongside Windows tools, and clarify which methods are cross-platform.
Balance .NET/ASP.NET examples with examples for Node.js, Python, Java, etc., and ensure these include both Windows and Linux deployment scenarios.
Explicitly state platform limitations (e.g., Web Deploy is Windows-only) and suggest best practices for Linux users.
Add links to documentation on Linux deployment tools and patterns, such as Azure CLI, SCP, or Git-based deployments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for finding outbound IP addresses, but the PowerShell examples are presented alongside CLI without clarifying that Azure PowerShell is primarily a Windows tool. There is no explicit mention of Linux-specific tools or shell environments, and the PowerShell examples may not be directly usable on Linux systems. Additionally, the outbound IPv6 support section highlights that outbound IPv6 is only available for Windows apps, with no Linux support, but does not offer Linux alternatives or guidance.

Recommendations:

Clarify that Azure PowerShell examples are primarily for Windows users and may require additional setup on Linux.
Provide explicit Linux shell (bash) examples where possible, especially for common tasks like querying IP addresses.
When mentioning features only available on Windows (e.g., outbound IPv6), offer guidance or workarounds for Linux users, or clearly state the lack of parity.
Consider presenting Azure CLI examples before PowerShell, as CLI is cross-platform and more universally applicable.
Add notes or links to documentation on how to use Azure PowerShell on Linux if PowerShell examples are retained.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) as the default location for the configuration file, and only later mentioning the Linux equivalent. The example path in the instructions is Windows-specific, and Linux instructions are relegated to a note. There are no Linux-specific examples or screenshots, and the documentation does not provide parity in guidance for Linux users. Additionally, the documentation refers to Windows path conventions and does not provide a Linux example in the main instructional steps.

Recommendations:

Present both Windows and Linux paths side by side in all relevant steps, not just in notes.
Use platform-agnostic language and examples where possible (e.g., refer to '/home/site/wwwroot/auth.json' and 'C:\home\site\wwwroot\auth.json' together).
Include explicit Linux examples and instructions in the main flow, not just as an afterthought or in notes.
Clarify differences in path requirements (relative vs. absolute) in a table or highlighted section for quick reference.
Where tools or file locations are mentioned, provide both Windows and Linux equivalents with equal prominence.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows-specific SKUs and features first (e.g., 'I1v2 Windows'), providing detailed IP address calculations only for Windows Containers, and listing Windows-centric tools (Visual Studio remote debugging, Web Deploy) in port tables without mentioning Linux equivalents or alternatives. There are no Linux-specific examples or parity in technical details, especially regarding container IP usage or deployment/debugging tools.

Recommendations:

Provide equivalent examples and calculations for Linux Containers, including how IP address usage differs (if at all) from Windows Containers.
When listing App Service plan OS/SKU combinations, mention Linux SKUs alongside Windows, or clarify if differences exist.
In port tables, include Linux-relevant deployment and debugging tools (e.g., SSH, SFTP, VS Code Remote), or note if certain features are Windows-only.
Ensure that any technical notes or calculations (such as IP address requirements) are presented for both Windows and Linux, or explicitly state if they are not applicable to Linux.
Review the order of presentation to avoid always listing Windows first; alternate or group by OS where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by referencing Windows directory paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and by describing deployment flows and file locations primarily in Windows terms. There are no explicit Linux or cross-platform command-line examples, and the instructions for manual deployment (e.g., creating directories or files) use Windows-style paths without showing Linux equivalents. Additionally, tools and patterns referenced (such as directory structures and file creation) are described in a Windows-centric way.

Recommendations:

Provide Linux/macOS directory path equivalents (e.g., /home/site/wwwroot) alongside Windows paths in all relevant sections, not just in passing.
Include explicit Linux/macOS command-line examples (e.g., using Bash or shell commands) for tasks such as creating directories or files, in addition to or instead of Windows examples.
When describing manual steps (like creating packagename.txt or directories), show both Windows and Linux commands (e.g., mkdir, echo > file.txt) or use cross-platform tools.
Avoid referencing only Windows tools or patterns (such as drive letters or backslashes); use forward slashes or note both styles where appropriate.
Ensure that troubleshooting and notes sections mention Linux-specific considerations where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a bias toward Windows by referencing Visual Studio and its NuGet package manager as the primary method for installing Semantic Kernel, with CLI instructions only mentioned secondarily. There are no explicit Linux or cross-platform development environment examples (e.g., VS Code, JetBrains Rider, or command-line workflows). The instructions for file operations (e.g., 'Right-click the Pages folder') assume a GUI-based IDE, typical of Windows/Visual Studio, and do not provide equivalent command-line or editor-agnostic steps. No Linux-specific deployment, configuration, or troubleshooting guidance is provided.

Recommendations:

Provide parallel instructions for Linux users, such as using VS Code or JetBrains Rider, and include command-line alternatives for file creation and editing.
List CLI-based NuGet installation instructions before or alongside Visual Studio GUI instructions, emphasizing cross-platform compatibility.
Avoid GUI-specific language like 'Right-click' or provide equivalent command-line instructions (e.g., 'Create a new file named OpenAI.razor in the Pages directory').
Include Linux-specific notes for environment variable configuration, deployment, and troubleshooting, especially for App Service deployments from non-Windows systems.
Explicitly mention that all steps can be performed on Linux, Mac, or Windows, and provide any necessary prerequisites or differences for non-Windows platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias in several areas. Windows-specific paths (e.g., D:\home), tools (e.g., Web Deploy/MSDeploy, IIS, w3wp.exe), and configuration patterns are mentioned or prioritized, often without equivalent Linux examples or with Linux information presented as secondary. Many environment variables and descriptions are tailored to Windows or reference Windows behaviors, with Linux details sometimes appended or omitted. Some features and settings are described only in the context of Windows tools or processes, and examples often use Windows paths or conventions.

Recommendations:

For every Windows-specific example or path (e.g., D:\home), provide the Linux equivalent (e.g., /home).
When referencing Windows tools (e.g., Web Deploy/MSDeploy, IIS, w3wp.exe), also mention or link to Linux-native alternatives or clarify their applicability.
Ensure that Linux-specific behaviors, defaults, and limitations are described with equal prominence and detail as Windows.
Where features are not available or differ on Linux, explicitly state this and provide guidance or workarounds.
In tables and descriptions, avoid listing Windows details first by default; consider parallel presentation (Windows | Linux) or alternating order.
Add Linux/POSIX shell examples where PowerShell or Windows command-line examples are given.
Audit for environment variables or settings that are Windows-only and clearly mark them as such, while also highlighting Linux-only or cross-platform equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific paths (e.g., D:\home), tools, and deployment patterns throughout, without providing equivalent Linux examples or clarifying Linux-specific behaviors. The only mention of Linux is in the context of unsupported scenarios, and there are no Linux shell or file system examples. Tools like Kudu are referenced without noting their differences or availability on Linux App Service. The guidance and examples are tailored to Windows environments, leaving Linux users with little actionable information.

Recommendations:

Provide parallel Linux examples for file paths (e.g., /home/site/wwwroot instead of D:\home\site).
Clarify how local cache works (or does not work) on Linux App Service plans, including any differences in behavior, configuration, or limitations.
Include Linux shell commands or instructions where appropriate, especially for tasks like checking folder sizes or environment variables.
Mention Linux-specific tools or equivalents to Kudu (such as KuduLite), and clarify any differences in management or diagnostics.
Clearly indicate in each section whether the instructions apply to Windows, Linux, or both, and provide guidance for Linux users where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows instructions and examples are consistently presented before Linux equivalents, and some tooling references (such as directory structure and deployment commands) are more tailored to Windows conventions. There are also sections (e.g., troubleshooting with 'Advanced Tools') that reference Windows-centric Azure portal features without clarifying Linux parity or alternatives. Some steps, such as directory navigation, use Windows-style paths or assumptions. While Linux instructions are present, they are sometimes less detailed or appear as adaptations rather than first-class guidance.

Recommendations:

Alternate the order of Windows and Linux instructions or present them side-by-side to avoid always prioritizing Windows.
Ensure all tooling and troubleshooting steps are equally applicable to Linux App Service, or clearly document Linux-specific equivalents (e.g., clarify if 'Advanced Tools' is available and behaves the same on Linux).
Use neutral directory structures and command syntax where possible, or provide both Windows and Linux variants explicitly.
Review all examples and ensure Linux instructions are as detailed and complete as Windows ones, including any differences in deployment, configuration, or troubleshooting.
Where features or tools are Windows-only, explicitly note this and provide Linux alternatives or workarounds.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by focusing on Windows-specific tools and patterns (such as IIS diagnostics, Procdump, and PowerShell), referencing Windows in links and tool names, and omitting Linux-specific troubleshooting guidance or examples. There are no Linux command-line or diagnostic tool examples, and the Kudu Console is described in terms of PowerShell and DOS commands, with no mention of Bash or Linux shell usage. The Application Insights Profiler section links only to Windows-specific documentation. Overall, Linux users are left without clear guidance for equivalent troubleshooting steps.

Recommendations:

Include Linux-specific troubleshooting steps and examples, such as using Bash in the Kudu Console, and mention Linux-compatible diagnostic tools.
Provide parity in documentation links (e.g., link to both Windows and Linux versions of Application Insights Profiler setup).
When describing Kudu Console, mention that Bash is available for Linux-based App Service plans and provide relevant examples.
Add examples for collecting diagnostics and logs on Linux-based App Service plans, such as using stdout/stderr logs, and reference Linux log file locations.
Avoid using Windows terminology (e.g., IIS, web.config, Procdump) without clarifying Linux equivalents or alternatives.
Ensure that PowerShell is not the only CLI example; include Azure CLI and Bash examples where appropriate.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias towards Windows by providing only a PowerShell example for resource cleanup, referencing IIS (a Windows-only web server) for validation, and omitting equivalent Linux/CLI examples for these steps. No Linux-native tools or commands are mentioned, and the validation process assumes a Windows environment.

Recommendations:

Provide Azure CLI and/or Bash examples for resource cleanup (e.g., using 'az group delete').
Include instructions for deploying and validating with a Linux-based web server (such as Nginx or Apache) as an alternative to IIS.
Ensure that all command-line instructions are presented with both PowerShell and CLI/Bash equivalents, or at least reference where to find them.
Explicitly mention that IIS is used for demonstration but that Linux-based VMs/web servers are equally supported, with links or steps for those scenarios.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. While the main configuration steps use Azure CLI (cross-platform), several critical operations and examples reference Windows-centric tools (e.g., SQL Server Management Studio, Visual Studio, and sqlcmd) without offering Linux or cross-platform alternatives. Publishing instructions prioritize Visual Studio and Git Bash, but do not mention Linux-native editors or deployment workflows. Local debugging guidance is focused on Visual Studio remote debugging, with no mention of Linux or VS Code debugging. There are no explicit Linux command-line or tool examples for database management or local development.

Recommendations:

Provide equivalent instructions for Linux and macOS users, such as using Azure Data Studio or sqlcmd on Linux for database management.
Include examples for publishing/deploying from Linux environments, such as using VS Code, Azure CLI, or Git from a Linux terminal.
Offer local debugging guidance for Linux (e.g., using VS Code remote debugging or Azure CLI for token acquisition).
When referencing tools like SQL Server Management Studio, also mention cross-platform alternatives (e.g., Azure Data Studio) and provide links.
Ensure that all command-line examples are explicitly cross-platform, and clarify any OS-specific requirements or differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows and Visual Studio (Windows) workflows, using PowerShell and Windows-specific tools (e.g., sqlcmd, Visual Studio menus), and omitting explicit Linux or cross-platform command-line examples for key steps such as database permission grants. Linux development environments are only briefly mentioned via Azure CLI, with no detailed guidance for Linux users on tasks like connecting to SQL Database or running migrations.

Recommendations:

Provide explicit Linux/macOS examples for connecting to Azure SQL Database, such as using sqlcmd or Azure Data Studio on Linux/macOS, or using Dockerized tools.
Include bash/zsh command-line instructions for all steps currently shown only with PowerShell or Windows tools.
Reorganize sections so that cross-platform or Linux-native workflows (e.g., Azure CLI, VS Code) are presented alongside or before Windows/PowerShell-specific instructions.
Clarify which steps are platform-agnostic and which are Windows-specific, and offer alternatives where possible.
Add guidance for running and debugging .NET apps on Linux/macOS, including database migration and publishing steps using dotnet CLI and VS Code.
Ensure all screenshots and menu paths have Linux/macOS equivalents or note when a feature is Windows-only.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias, primarily through the use of PowerShell commands and references to Windows-centric tools (such as AzPowershell and Azure PowerShell) in both GitHub Actions and Azure Pipelines examples. While the CI runners are set to 'ubuntu-latest' (Linux), the scripts and authentication steps often rely on PowerShell or Windows-specific patterns, and there is a lack of explicit Linux shell (bash/sh) alternatives. Additionally, Windows tools and patterns are mentioned before or instead of their Linux equivalents, and some examples (such as dotnet CLI usage) are shown only in PowerShell or C# contexts, with no explicit Linux shell or cross-platform alternatives.

Recommendations:

Provide equivalent bash/sh shell commands alongside PowerShell examples, especially for authentication and setup steps.
When referencing Azure CLI or PowerShell, clarify cross-platform compatibility and provide both Windows and Linux command variants where applicable.
Avoid using Windows-centric terminology (e.g., 'AzPowershell', 'PowerShell@2') as the default; instead, present both PowerShell and bash options, or use platform-agnostic tools where possible.
Explicitly state that the examples work on both Windows and Linux runners, or provide separate tabs for each OS where commands differ.
For .NET/NUnit examples, show both Windows and Linux command-line invocations (e.g., dotnet CLI in bash and PowerShell).
Ensure that all code snippets and workflow steps are tested and documented for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation shows a moderate Windows bias. Visual Studio Code (VS Code) and Azure Portal are presented as the primary UI tools, with no mention of Linux-native editors or terminal workflows. The CLI and PowerShell examples are present, but there are no explicit Linux shell or environment variable examples (e.g., export vs. set). The documentation assumes familiarity with Windows-centric tools and patterns, and does not provide Linux-specific guidance for environment setup, authentication, or test execution.

Recommendations:

Include explicit Linux/macOS shell command examples for setting environment variables (e.g., export PLAYWRIGHT_SERVICE_URL=...) alongside Windows/PowerShell equivalents.
Mention Linux-native editors (e.g., Vim, Nano) or terminal workflows for users not using Visual Studio Code.
Clarify that all CLI commands (npm, npx, dotnet, az) are cross-platform, and provide any OS-specific notes where behavior may differ.
Add screenshots or terminal output examples from Linux environments to balance the current Windows/VS Code focus.
Where file paths or configuration files are referenced, note any differences in path syntax or file permissions that may affect Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by prioritizing Azure PowerShell scripts and cmdlets for migration and preview registration/unregistration tasks, with no mention or examples of Bash, Linux shell, or cross-platform CLI alternatives. The only command-line examples use PowerShell syntax and cmdlets (e.g., Set-AzContext, Register-AzProviderFeature), and the migration script is only referenced as a PowerShell solution. There is no guidance or parity for Linux or macOS users, nor are Azure CLI (az) commands provided as alternatives.

Recommendations:

Provide equivalent Azure CLI (az) command examples for all PowerShell commands, as Azure CLI is cross-platform and widely used on Linux and macOS.
Mention both Azure PowerShell and Azure CLI as supported options for management and migration tasks, and avoid implying that PowerShell is the default or only supported tool.
If migration scripts are only available in PowerShell, clarify this limitation and provide guidance or links for Linux/macOS users (e.g., running PowerShell Core on Linux, or alternative migration approaches).
In 'Next steps' and tutorial links, ensure that both PowerShell and CLI-based tutorials are referenced equally, or provide a choice.
Review all code blocks and command references to ensure Linux users are not excluded, and add Bash/CLI examples where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows container SSH access first, even though the Linux workflow is more feature-rich and commonly used. The Windows section is brief and lacks parity with the Linux section, which provides detailed CLI-based SSH instructions and examples. There are no equivalent CLI or PowerShell examples for Windows containers, nor is there a discussion of Windows-native SSH tools or workflows.

Recommendations:

Present Linux and Windows instructions in parallel or start with Linux, as it is more commonly used for SSH workflows.
Provide equivalent command-line (e.g., PowerShell or Windows SSH client) instructions for Windows containers, or clearly state if such functionality is not available.
If CLI-based SSH access is not supported for Windows containers, explicitly mention this limitation and suggest alternative approaches.
Include references to Windows-native SSH tools (such as OpenSSH in Windows 10/11, PuTTY, or PowerShell SSH commands) where appropriate.
Ensure that both Linux and Windows sections have similar depth and structure, including troubleshooting tips, example commands, and expected output.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page discusses assessing .NET web apps for migration to Azure App Service but implicitly assumes a Windows/ASP.NET context (e.g., references to ASP.NET, which is historically Windows-centric). There are no explicit examples, tools, or instructions for Linux-based .NET web apps or cross-platform scenarios. All referenced materials and terminology focus on traditional Windows environments, with no mention of Linux-compatible assessment tools or workflows.

Recommendations:

Include explicit references and examples for assessing .NET web apps running on Linux (e.g., ASP.NET Core on Linux).
Mention and link to tools or workflows that support Linux-based .NET applications, such as command-line tools or scripts compatible with Bash.
Clarify whether the assessment process and recommendations apply equally to Linux-hosted .NET apps, and if not, provide guidance for those scenarios.
Add a section or note highlighting cross-platform support and any differences in assessment steps or recommendations for Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation references a Python/Flask application and is generally cross-platform, but there is subtle Windows bias in the way quickstart links and tabs are presented. The quickstart link for creating the sample app includes 'windows' as a tab before 'terminal-bash', and there are no explicit Linux or macOS-specific instructions or examples. All environment variable and deployment instructions are presented in a way that assumes use of the Azure Portal or Visual Studio, with no mention of Linux-native workflows, shell commands, or deployment tools (e.g., Azure CLI from Bash, Linux file paths, or systemd services). There are no PowerShell-specific commands, but the absence of Linux-specific guidance or parity in examples constitutes a 'missing_linux_example' and a 'windows_first' ordering bias.

Recommendations:

Ensure that all quickstart and sample links include Linux and macOS tabs/examples, and that these are presented equally or before Windows where appropriate.
Add explicit Linux/macOS instructions for environment variable management (e.g., using export in Bash, .env files, or systemd service files).
Include deployment instructions using Azure CLI from Bash and/or GitHub Actions, not just Azure Portal or Visual Studio.
When referencing file paths or commands, provide both Windows and Linux/macOS equivalents.
Review all code snippets and instructions to ensure they are platform-agnostic or provide platform-specific notes where necessary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_heavy

Summary:

The documentation presents some evidence of Windows bias. In the 'Configure name resolution behavior' section, default values for DNS settings are listed with 'Windows default value' before 'Linux default value' in the table, and the note about unsupported features specifically calls out Windows Container apps. However, the documentation does provide Linux values and does not exclusively focus on Windows tools or examples. There are no PowerShell or Windows-only command-line examples; all CLI examples use the cross-platform Azure CLI. There are no missing Linux examples, but Windows is generally mentioned first and more prominently.

Recommendations:

Alternate the order of Windows and Linux in tables or mention Linux first in some cases to avoid always prioritizing Windows.
Where limitations are called out for Windows, also explicitly state if there are Linux-specific limitations for parity.
Consider adding a brief section or callout summarizing any Linux-specific behaviors or differences, to balance the Windows-specific notes.
Ensure that any future examples or troubleshooting steps include both Windows and Linux contexts equally, especially if OS-specific commands or tools are needed.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation provides configuration and usage examples for Playwright Workspaces using TypeScript (Playwright test runner) and C# (NUnit test runner), but does not include any Linux-specific instructions, shell commands, or examples. There is no mention of Linux tools, patterns, or environment-specific considerations, nor are there any examples that demonstrate usage on Linux systems. The documentation is neutral in terms of operating system, but the absence of Linux-specific guidance or parity checks may disadvantage Linux users.

Recommendations:

Add explicit Linux usage examples, such as running Playwright tests in a Linux shell or terminal, and note any OS-specific considerations (e.g., environment variables, file paths).
Include a section or note confirming that the instructions and examples work identically on Linux, or highlight any differences if present.
If there are any prerequisites or dependencies that differ on Linux (such as package installation or network configuration), document them clearly.
Consider providing bash/zsh command-line examples alongside the existing ones, especially for common Linux workflows.
Mention Linux-specific troubleshooting steps or tips, if applicable, to ensure parity and confidence for Linux users.

Create pull request

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