Scan Details - Linux-first Docs for Azure

965

Pages Scanned

59

Pages Flagged

965

Changed Pages

6.1%

% Pages Flagged

Scan Information

Started At: 2025-08-20 00:01:04

Finished At: 2025-08-20 00:45:17

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by presenting Azure PowerShell instructions and terminology before Azure CLI equivalents throughout the feature registration and unregistration sections. There is a heavy reliance on PowerShell examples, and no explicit Linux or Bash shell examples are provided. The CLI examples are present but are not contextualized for Linux users (e.g., no Bash scripting, no mention of shell environments). The documentation assumes familiarity with Windows-centric tools and patterns, and does not address Linux-specific workflows or considerations.

Recommendations:

Alternate the order of PowerShell and CLI instructions, or present CLI (cross-platform) first to avoid Windows-first bias.
Explicitly mention that Azure CLI commands can be run on Linux, macOS, and Windows, and provide example shell environments where appropriate.
Include Bash shell script examples for common tasks, especially for steps that are likely to be automated in Linux environments.
Where screenshots or UI steps are provided, consider including CLI or script-based alternatives for users who prefer or require non-GUI workflows.
Add a section or callout for Linux users, highlighting any differences or tips for using the Azure CLI or other tools on Linux.
Ensure that references to tools (e.g., PowerShell, CLI) clarify their cross-platform availability and usage.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily through the exclusive use of Azure PowerShell commands and references, with no mention or examples of equivalent Bash or Linux-native CLI usage. The PowerShell-based workflow is presented as the default or only method for migration and preview registration tasks. There is also a lack of explicit Linux or cross-platform guidance, and the ordering of tools and tutorials often places PowerShell before Azure CLI or other platform-agnostic options.

Recommendations:

Provide Azure CLI (bash) examples alongside or before PowerShell commands for all operational tasks, such as migration and preview registration.
Explicitly mention that Azure CLI is cross-platform and supported on Linux/macOS, and provide links to relevant installation and usage guides.
Where PowerShell is referenced, clarify that it is available on Linux/macOS as well, or provide alternative shell-specific instructions.
Balance the ordering of tool references (e.g., 'Azure CLI, Azure PowerShell, or Azure portal') to avoid always listing Windows-centric tools first.
Add a section or note highlighting Linux support and any platform-specific considerations for Application Gateway v2.

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 Windows environments, particularly IIS servers and PowerShell scripts. There is no mention of Linux-based .NET hosting scenarios, Linux migration tools, or cross-platform alternatives. The documentation assumes the source environment is Windows and does not provide guidance for users migrating from Linux servers or using Linux-native tools.

Recommendations:

Include migration guidance and tools for .NET apps hosted on Linux (e.g., Apache, Nginx, Kestrel).
Provide Linux shell (bash) script examples alongside PowerShell scripts.
Mention and document any cross-platform migration tools or clarify if current tools are Windows-only.
Add a section addressing migration from Linux-based environments, including common challenges and solutions.
Ensure parity in documentation for both Windows and Linux users by listing Linux options and examples wherever Windows tools/scripts are mentioned.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific configuration files (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 with PM2, most configuration and troubleshooting guidance assumes a Windows/IIS environment, and Linux alternatives are not presented or are mentioned only secondarily.

Recommendations:

For every mention of web.config or IIS/iisnode, provide equivalent Linux-native configuration examples (e.g., environment variables, process managers like systemd or PM2).
When discussing auto-healing or diagnostics, include instructions for both Windows (web.config/IIS) and Linux (startup scripts, App Service settings, or container health checks).
If referencing iisnode, also describe how to configure Node.js apps on Linux App Service (e.g., using PM2, npm scripts, or custom startup commands).
Ensure that all troubleshooting and best practice sections include Linux-specific guidance where applicable, not just Windows/IIS-centric advice.
Consider reordering examples or providing parallel examples for both platforms to avoid a 'Windows first' impression.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. While both Windows and Linux are mentioned as supported platforms, and Azure CLI examples are provided (which are cross-platform), the structure and ordering of content often present Windows-first. For example, in the 'Premium V3 availability' section, the Windows SKU availability command is listed before the Linux one. Additionally, 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 PowerShell-specific parameters (like -WorkerSize) also reinforces a Windows-centric approach. There are no explicit Linux shell or scripting examples, and the documentation does not mention Linux-specific considerations or tools beyond the single CLI command for Linux workers.

Recommendations:

Alternate the order of Windows and Linux examples to avoid always listing Windows first.
Provide Bash or shell script examples for Linux users, especially in the automation section.
Include Linux-specific notes or troubleshooting tips where relevant.
Clarify that Azure CLI commands are cross-platform and can be run on both Windows and Linux.
If PowerShell examples are included, consider also including equivalent Bash or shell scripting examples for parity.
Ensure screenshots and UI instructions are not Windows-centric (e.g., avoid only showing Windows UI if there are differences).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by presenting Windows-related information and tools before Linux equivalents, and by including Azure PowerShell (a Windows-centric tool) as a primary automation method. While Linux is mentioned and Azure CLI examples are provided (which are cross-platform), the ordering and emphasis tend to favor Windows. There are no Linux shell or scripting examples, and the 'Automate with scripts' section highlights PowerShell after CLI, but does not provide Bash or Linux-native automation examples.

Recommendations:

Ensure Linux and Windows instructions/examples are presented with equal prominence and in parallel where possible.
Add Bash or shell script examples for Linux users, especially in the automation section.
When listing tools or commands, avoid always listing Windows/PowerShell first; alternate or present both together.
Clarify in the 'Automate with scripts' section that Azure CLI is fully cross-platform and may be preferred for Linux users.
Where screenshots or UI steps are shown, note any OS-specific differences or provide Linux-specific guidance if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions and tools (such as the GUI and PowerShell commands) are often presented first or exclusively, with Linux alternatives sometimes less detailed or missing. Windows-specific troubleshooting steps and tools are emphasized, and some features (like the Hybrid Connection Manager GUI) are only available on Windows, with Linux users directed to CLI alternatives. Some troubleshooting commands are only shown for Windows/PowerShell, with no direct Linux equivalents provided.

Recommendations:

Present Linux and Windows instructions in parallel, or alternate which OS is presented first in each section.
Where PowerShell commands are provided for troubleshooting (e.g., Test-NetConnection), include equivalent Linux commands (e.g., nc, curl, or telnet).
For GUI-only features on Windows, provide more detailed CLI instructions for Linux users, including screenshots or step-by-step guides.
In troubleshooting sections, ensure all diagnostic steps have Linux equivalents, not just Windows/PowerShell.
Highlight Linux support and parity where available, and clearly note any feature gaps.
Consider providing more examples and sample commands for Linux users, especially for common tasks like connectivity testing and service management.

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 script examples for Linux/macOS users. The instructions for running the script assume a Windows/PowerShell environment, and no alternative is offered. While the rest of the documentation uses Azure Resource Graph (ARG) queries and Azure CLI/REST API references (which are cross-platform), the exclusive use of PowerShell for a key scenario and lack of Linux/macOS guidance indicate a bias.

Recommendations:

Provide an equivalent Bash or Azure CLI script for identifying non-Azure Traffic Manager endpoints, or at least link to a cross-platform solution.
Explicitly mention that the PowerShell script can be run on PowerShell Core (pwsh) on Linux/macOS, if applicable, and provide installation instructions.
When referencing scripts or tools, offer both Windows (PowerShell) and Linux/macOS (Bash/CLI) examples where possible.
Review other sections for subtle Windows-first language or assumptions, and clarify that all CLI/API instructions are cross-platform.
Consider including a table or section summarizing which tools/scripts are available for each platform.

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 references are tailored to Windows/IIS scenarios, omitting Linux equivalents.

Recommendations:

Include information on discovering .NET web apps hosted on Linux servers (e.g., Kestrel, Apache, Nginx).
Provide examples or references for Linux-based discovery workflows, including any supported tools or limitations.
Clarify in the introduction whether Linux-hosted .NET apps are supported or not, and if not, provide guidance or links to relevant migration resources.
Ensure parity in documentation by mentioning both Windows and Linux scenarios where applicable, and by providing platform-agnostic guidance where possible.

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 and troubleshooting steps are tailored to Windows, referencing Windows-specific tools (e.g., iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell). There are no Linux equivalents or examples, and Linux troubleshooting or deployment patterns are not mentioned. The use of Windows paths and error codes further reinforces the Windows-centric approach.

Recommendations:

Provide parallel documentation or sections for Linux-based Azure App Service environments, including configuration and troubleshooting steps relevant to Linux.
Include Linux-specific examples, such as using PM2 or systemd for process management, and nginx or Apache for reverse proxying.
Reference Linux file paths, error logs, and common debugging tools (e.g., journalctl, tail, lsof) alongside or instead of Windows-specific ones.
Offer guidance on differences between iisnode (Windows) and alternatives like Azure App Service for Linux, including how to configure and debug Node.js apps in those environments.
Balance the order of presentation so that Linux and Windows are given equal prominence, or clearly indicate when content is Windows-only and link to Linux equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by referencing the Windows file path (C:\home\site\wwwroot) as the default location for the configuration file, mentioning Windows path conventions first, and omitting Linux command-line or file system examples. Linux support is mentioned only as a note, and no Linux-specific instructions or examples are provided for file creation or deployment.

Recommendations:

Present both Windows and Linux file paths side-by-side when describing where to place the configuration file (e.g., 'C:\home\site\wwwroot\auth.json' for Windows, '/home/site/wwwroot/auth.json' for Linux).
Include explicit Linux examples and instructions, such as how to create or deploy the configuration file using Linux commands (e.g., using 'touch', 'cp', or 'vi').
Avoid assuming Windows as the default environment; instead, clarify instructions for both platforms equally.
Where platform-specific behavior exists (such as path requirements), provide a clear, parallel example for each platform in the main instruction flow, not just in a note.
Consider adding a table or section summarizing differences and best practices for both Windows and Linux App Service environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a mild Windows bias by referencing Azure Storage Explorer (which is primarily a GUI tool with a strong Windows association) for uploading files and generating SAS tokens, and by linking to Storage Explorer instructions with a '?tabs=windows' parameter. There are no Linux-specific instructions or CLI-based alternatives for these steps, and the only detailed example for generating a SAS is via the Windows-centric Storage Explorer. While the rest of the guide uses Azure CLI (which is cross-platform), the initial setup and file upload steps lack Linux parity.

Recommendations:

Provide Azure CLI or AzCopy command-line examples for uploading package files and generating SAS tokens, ensuring Linux users have clear, first-class instructions.
Avoid linking only to Windows-specific tabs or instructions; ensure links and examples are either cross-platform or explicitly include Linux/macOS alternatives.
Mention cross-platform tools (e.g., AzCopy, Azure CLI) before or alongside GUI tools like Storage Explorer, and clarify their availability on Linux.
Add a note or section highlighting Linux/macOS compatibility and any differences in workflow, especially for steps currently described only with Windows tools.

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.

Recommendations:

Add equivalent instructions and examples for Linux-based App Service plans, including how to check available .NET runtimes and access diagnostic tools.
Include Linux shell (bash) commands and file paths where appropriate, especially for runtime version discovery and environment variable access.
Clarify when instructions are Windows-specific and provide parallel Linux guidance, or explicitly state if a feature is not available on Linux.
Mention Linux deployment tools and patterns (e.g., SSH, bash, Linux containers) alongside Windows tools like Kudu and PowerShell.
Provide links to Linux-specific documentation or troubleshooting guides for ASP.NET apps on Azure App Service (Linux).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring data sources in Tomcat and JBoss on Azure App Service. However, in the Tomcat server-level configuration section, the Windows instructions are more detailed, appear first, and rely heavily on Windows-specific tools and scripting (PowerShell, .cmd files, Windows environment variables). The Linux instructions are present and functional, but the Windows approach is described in greater depth and with more step-by-step scripting, while the Linux approach is more concise and assumes more user familiarity with shell scripting and Linux tools.

Recommendations:

Ensure Linux and Windows instructions are presented in parallel structure and depth, with equal detail and step-by-step guidance.
Provide Linux shell script examples with the same level of explanation as the Windows PowerShell scripts.
Where possible, use cross-platform tools or highlight equivalent Linux tools (e.g., bash scripts, Linux environment variables) alongside Windows tools.
Avoid presenting Windows instructions or tools before Linux equivalents; use side-by-side tabs or pivots for parity.
Expand Linux sections to include troubleshooting, best practices, and automation tips similar to those given for Windows.
Ensure all code samples (e.g., for deploying JDBC drivers) are shown for both platforms with matching clarity.

Create pull request

Bias Types:

⚠️ linux_first

⚠️ missing_windows_example

⚠️ linux_tools

Summary:

The documentation page demonstrates a Linux-first bias, especially in the sections about Java key store management. It provides detailed instructions and examples for Linux environments (e.g., file paths, SSH, keytool usage) but omits equivalent instructions or examples for Windows-based App Service environments. There are no PowerShell or Windows command-line examples, and Windows-specific file paths or tools are not mentioned. The documentation assumes Linux as the default or primary environment for Java apps on Azure App Service.

Recommendations:

Add parallel instructions and examples for Windows-based App Service environments, including file paths for Java key stores (e.g., %JAVA_HOME%\lib\security\cacerts), and describe where certificates are stored on Windows.
Include examples of how to interact with the Java key store on Windows, such as using Command Prompt or PowerShell, and reference the Windows version of the keytool documentation.
Mention how to open a remote session or terminal on Windows App Service (e.g., Kudu/SCM site) and provide equivalent keytool usage instructions.
Ensure that all environment variable references use both Linux ($VAR) and Windows (%VAR%) syntax where appropriate.
Balance the order of presentation so that Windows and Linux instructions/examples are given equal prominence, or clarify when a feature is Linux-only.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell examples are provided alongside Azure CLI, but there are references to Windows-specific tools (IIS, Certreq.exe) for certificate export without equivalent Linux instructions. In automation and FAQ sections, PowerShell is mentioned before or alongside CLI, but Linux-native tools or workflows are not equally highlighted. The document assumes familiarity with Windows tooling and does not provide parity for Linux users in several steps.

Recommendations:

For certificate export, provide explicit Linux/OpenSSL instructions alongside or before Windows/IIS/Certreq.exe steps.
Where PowerShell is shown, ensure Azure CLI (cross-platform) examples are always present and, where possible, shown first.
In automation and FAQ sections, include Bash scripting or Linux-native automation examples, not just PowerShell.
Reference Linux and macOS environments explicitly in prerequisites and examples, not just Windows.
Where Windows-specific tools are mentioned (e.g., IIS, Certreq.exe), add equivalent Linux/macOS guidance or links.
Review screenshots and UI instructions to ensure they are not Windows-centric if the portal experience is cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first bias by referencing Windows directory paths (e.g., D:\home\site\wwwroot) before Linux equivalents, and by describing deployment behaviors and manual steps (such as creating directories and files) only in terms of Windows paths. There are no explicit Linux or cross-platform command-line examples, and the documentation does not provide Linux-specific instructions or clarify differences in behavior for Linux-based App Service plans.

Recommendations:

Provide Linux directory paths alongside Windows paths wherever file system locations are mentioned (e.g., /home/site/wwwroot in addition to D:\home\site\wwwroot).
Include explicit Linux/macOS shell command examples (e.g., using Bash) where manual file operations are described, or clarify if such manual steps are not required or differ on Linux-based App Service plans.
Clarify any behavioral differences between Windows and Linux App Service environments, especially regarding file system structure and deployment nuances.
Ensure that all examples, troubleshooting steps, and notes are cross-platform or provide platform-specific instructions as needed.
Add a section or callout summarizing key differences and considerations for Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by referencing Visual Studio and its NuGet package manager as the primary method for installing packages, and by using Windows-centric UI actions (e.g., right-clicking in Solution Explorer) without providing equivalent Linux or cross-platform instructions. While CLI alternatives are mentioned for NuGet, there are no explicit Linux or cross-platform development environment examples, nor is there guidance for using common Linux editors or deployment workflows.

Recommendations:

Provide explicit Linux and cross-platform instructions for all steps, including file creation and editing (e.g., using VS Code, nano, or command-line tools).
List CLI-based package installation (e.g., dotnet CLI) before or alongside Visual Studio/NuGet Manager instructions.
Include deployment instructions using Azure CLI and/or GitHub Actions, not just portal-based workflows.
Avoid assuming Visual Studio or Windows-specific workflows; clarify that any editor or OS can be used.
Show environment variable setup using both Azure Portal and CLI (az command), and mention how to set secrets locally on Linux/macOS.
Add a note or section for Linux/macOS users, highlighting any differences or additional steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. In the prerequisites and quickstart links, 'windows' is explicitly listed as a tab, and there is a lack of explicit Linux/macOS command-line or deployment examples. The instructions for setting environment variables and deployment reference the Azure portal and Visual Studio (Windows-centric tools) without mentioning Linux alternatives or command-line equivalents. There are no PowerShell-specific commands, but the absence of Linux shell examples and the prioritization of Windows tools and patterns indicate a subtle bias.

Recommendations:

Add explicit Linux/macOS tabs or examples alongside Windows in all quickstart and setup links.
Include Linux shell (bash) commands for environment variable setup and deployment, not just portal or Visual Studio instructions.
Mention cross-platform deployment tools (e.g., Azure CLI, GitHub Actions) and provide examples for both Windows and Linux.
Clarify that the instructions apply to both Windows and Linux, and provide any OS-specific notes where necessary.
Where Visual Studio is mentioned, also mention VS Code and command-line alternatives for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a strong Windows bias by exclusively providing PowerShell examples for per-app scaling, referencing only Windows-centric tools and cmdlets (e.g., New-AzAppServicePlan, Set-AzAppServicePlan), and omitting equivalent examples for Linux/macOS users (such as Azure CLI or Bash). The PowerShell approach is presented first and most prominently, with no mention of cross-platform alternatives.

Recommendations:

Add equivalent Azure CLI examples for all PowerShell commands, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash scripting examples where appropriate, especially for configuring app settings or deploying ARM templates.
Explicitly state that PowerShell examples are for Windows and provide links or inline examples for Linux/macOS users.
Reorganize sections so that cross-platform tools (Azure CLI, ARM templates) are presented before or alongside PowerShell.
Mention that Azure Cloud Shell supports both Bash and PowerShell, and show how to use both for these tasks.

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 PowerShell examples are always presented alongside or immediately after CLI, with no explicit mention of Linux shell alternatives (e.g., Bash scripting or jq for JSON parsing). There is also a note that outbound IPv6 support is only available for Windows apps, with no Linux parity or roadmap. No Linux-specific tools or workflows are mentioned, and the documentation does not clarify that Azure CLI commands are cross-platform or provide Linux-specific context.

Recommendations:

Explicitly state that Azure CLI commands are cross-platform and can be run on Linux, macOS, and Windows.
Provide Linux shell (bash) examples for parsing JSON output from Azure CLI, such as using jq or grep, especially in sections where PowerShell is shown.
When listing command-line examples, present Azure CLI (cross-platform) before PowerShell, or group them under clear OS headings.
For features (like outbound IPv6) that are Windows-only, clearly indicate the lack of Linux support and, if possible, provide a roadmap or alternatives for Linux users.
Include troubleshooting or environment notes for Linux users where relevant (e.g., differences in DNS tools or network testing).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias. Windows-specific features and limitations (such as Windows Containers subnet sizing and Windows Server Active Directory) are discussed in detail, while Linux-specific scenarios are only briefly mentioned or relegated to a single section. There is a lack of Linux-focused examples, and Windows terminology and patterns (e.g., Kudu console, Windows Containers) are referenced without equivalent Linux context. The only explicit Linux mention is in the context of continuous deployment network dependencies, which is brief and lacks parity with the Windows coverage.

Recommendations:

Add Linux-specific examples and scenarios, such as subnet sizing and limitations for Linux containers, to match the detail given for Windows Containers.
Provide parity in troubleshooting and operational guidance for both Windows and Linux environments (e.g., mention Linux equivalents for Kudu console or clarify if Kudu is available for Linux).
Include Linux-focused deployment and integration patterns, not just a single note about continuous deployment network dependencies.
When listing limitations or features, always clarify applicability to both Windows and Linux, or provide separate sections if behaviors differ.
Review terminology to ensure cross-platform neutrality (e.g., avoid assuming Kudu or Windows tools are the default).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias, with detailed instructions and features (such as web server logging, detailed error messages, and failed request tracing) provided exclusively or primarily for Windows. Linux and container scenarios are often mentioned secondarily, with less detail and fewer features. Some tools and log formats referenced (e.g., W3C logs, Log Parser) are Windows-centric, and there are missing Linux equivalents or examples.

Recommendations:

Provide equivalent, detailed instructions for enabling and accessing all available logging features on Linux and container-based App Service plans.
Clearly indicate which features are Windows-only and, where possible, suggest Linux/container alternatives or workarounds.
Include Linux-specific examples and tools for accessing and analyzing logs (e.g., using tail, less, grep, or open-source log viewers).
List Linux/container logging capabilities and limitations in a dedicated section or table for transparency.
Avoid referencing only Windows tools (such as Log Parser) without suggesting cross-platform or Linux-native alternatives.
Where features are not available on Linux, provide guidance or links to feature requests or roadmap information.

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 (IIS, Procdump, PowerShell), referencing Windows terminology (web.config, .NET Profiler for Windows), and omitting Linux-specific instructions or equivalents. Examples and tool mentions (e.g., Kudu console, Procdump, PowerShell) are Windows-centric, with no parallel guidance for Linux-based App Service environments.

Recommendations:

Provide Linux-specific instructions and examples alongside Windows ones, especially for diagnostics, logging, and troubleshooting steps.
Mention Linux equivalents for tools like Procdump (e.g., gcore, dotnet-dump) and clarify which features are available on Linux App Service plans.
Include guidance for enabling diagnostics and collecting logs on Linux-based App Service (e.g., using XPlat diagnostics, Application Insights for Linux).
Avoid assuming IIS or web.config is present; note differences for Linux (e.g., nginx, Apache, appsettings.json).
When referencing PowerShell, also provide Azure CLI or Bash examples for parity.
Clarify in each section whether the feature or tool applies to Windows, Linux, or both App Service environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. Windows-specific instructions, tools, and examples (especially PowerShell) are presented first and in greater detail. Windows tools and file paths are often mentioned before their Linux equivalents, and some sections (such as credential management and runbook authentication) provide only Windows/PowerShell examples or focus heavily on Windows workflows. Linux instructions are present but sometimes less detailed or appear after Windows content. There are also more PowerShell-based code samples than bash or Python equivalents, and some features (like Hybrid Worker Credentials) are noted as unsupported on Linux without offering Linux alternatives.

Recommendations:

Present Windows and Linux instructions/examples in parallel sections or tabs, ensuring equal prominence.
Provide Linux (bash or Python) code samples wherever PowerShell examples are given, especially for runbook authentication and management tasks.
When referencing tools (e.g., certificate management, environment variable setup), mention both Windows and Linux tools with equal detail and order.
Clarify feature parity and, where Linux support is lacking (e.g., Hybrid Worker Credentials), suggest alternative Linux-compatible approaches or workarounds.
Include Linux-specific troubleshooting and operational guidance alongside Windows content.
Balance references to Windows file paths and registry locations with Linux equivalents throughout the documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias by referencing Windows-specific tools and workflows (such as WSL and Windows Terminal) before or more prominently than native Linux equivalents. Azure PowerShell is mentioned alongside Azure CLI, but with a slight preference in ordering and visibility. The installation instructions for redis-cli on Windows rely on WSL, which is a Windows-specific solution to run Linux tools, rather than suggesting native Windows binaries or cross-platform alternatives. Linux is well-represented in installation and usage examples, but Windows users are directed to emulate Linux environments rather than use native Windows solutions.

Recommendations:

Provide explicit instructions for installing redis-cli natively on Windows (e.g., using precompiled binaries or via package managers like Chocolatey or Scoop), if available, rather than only via WSL.
When listing methods to retrieve cache keys, present Azure CLI and Azure PowerShell in a neutral or alternating order, or explicitly note that both are cross-platform.
Include example commands or screenshots from both Linux and Windows environments (e.g., Command Prompt or PowerShell) where possible.
Mention that redis-cli commands are the same across platforms, but clarify any platform-specific nuances or limitations.
When referencing tools like Windows Terminal, also mention equivalent terminal applications on Linux and macOS for parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific tools and configuration steps (such as Visual Studio, PowerShell, and Windows-specific CLI commands) are often mentioned first or exclusively, with Linux equivalents sometimes only referenced later or in passing. Some deployment and configuration examples (e.g., ReadyToRun, runtime identifiers, and debugging) provide more detail for Windows than Linux, and PowerShell is listed as a primary automation option without equal emphasis on Bash or Linux scripting. In a few cases, Linux-specific instructions are present but less prominent or lack parity in detail.

Recommendations:

Ensure that all command-line examples (e.g., Azure CLI, deployment, debugging) include both Windows and Linux syntax and context, ideally side-by-side or in clearly marked tabs.
When listing tools or workflows (e.g., Visual Studio, Visual Studio Code, PowerShell), always include Linux-native or cross-platform alternatives (e.g., Bash, zsh, JetBrains Rider) with equal prominence.
For sections like ReadyToRun and runtime identifiers, provide Linux examples and explanations with the same level of detail as Windows.
Avoid listing Windows tools or workflows first by default; alternate the order or use neutral/cross-platform ordering.
Where PowerShell is mentioned, also mention Bash or other common Linux shells for scripting and automation.
In debugging and deployment sections, ensure Linux workflows are fully documented and not just referenced as an afterthought.
Audit all code snippets and configuration examples to ensure Linux users are not required to infer steps from Windows-centric instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there are subtle biases. Windows command-line examples (Cmd) are consistently presented alongside Bash, but Cmd is always listed second, which is a minor 'windows_first' bias. There is a heavier focus on Windows-specific terminology (e.g., 'command prompt') and some references to Windows in tables and explanations. However, Linux is also covered in most places, and Bash examples are provided. There are no explicit PowerShell examples, but the presence of Cmd tabs and references to 'command prompt' may be interpreted as a Windows-centric approach. No Linux-specific tools or troubleshooting are highlighted, and there are no explicit Linux-only examples or guidance, which could be seen as a 'missing_linux_example' bias.

Recommendations:

Ensure that all command-line examples are presented with equal prominence for both Bash (Linux/macOS) and Cmd (Windows), and consider including PowerShell where appropriate.
Avoid using Windows-centric terminology like 'command prompt' without also mentioning 'terminal' or 'shell' for Linux/macOS users.
Where OS-specific instructions are necessary, provide clear, parallel guidance for both Windows and Linux, including troubleshooting steps.
Highlight any Linux/macOS-specific considerations, such as file permissions, case sensitivity, or environment variable differences.
Consider including a section or appendix specifically addressing Linux/macOS development environments, common issues, and best practices.
When referencing supported Java versions or runtime behaviors, ensure that Linux and Windows are given equal detail and placement in tables and explanations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a mild Windows bias by listing Windows-centric tools (Visual Studio, PowerShell) before cross-platform or Linux-native equivalents, especially in C# and deployment sections. Visual Studio (Windows-only) is often mentioned first, and PowerShell is given its own language pivot, which can imply a Windows-first development workflow. However, Linux-compatible tools (Azure CLI, Visual Studio Code, Maven, Gradle) are also documented and available, and there are no outright missing Linux examples.

Recommendations:

When listing tools or workflows, avoid always listing Visual Studio (Windows-only) first; instead, alternate or group cross-platform tools (e.g., Visual Studio Code, Azure CLI) before or alongside Windows-specific tools.
Explicitly mention that Azure CLI and Visual Studio Code are cross-platform and supported on Linux and macOS, to reinforce parity.
Where PowerShell is referenced, consider also mentioning Bash or shell equivalents for Linux users, or clarify when PowerShell Core (cross-platform) is supported.
In deployment and quickstart sections, provide explicit Linux/macOS command-line examples or links, not just 'command prompt', which can be ambiguous.
Review language in all sections to ensure it does not implicitly assume a Windows environment (e.g., avoid 'command prompt' in favor of 'terminal' or specify OS 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 exclusively providing instructions and examples for Windows environments, particularly for managing SMB permissions and share properties. It references Windows-specific tools (MMC, Windows File Browser, Control Panel), and does not mention or provide equivalent Linux commands or tools for accessing or managing SMB shares. Linux access patterns and tools are omitted, despite SMB being cross-platform.

Recommendations:

Include Linux-based instructions for mounting and managing SMB shares, such as using the 'mount.cifs' command or 'smbclient'.
Provide examples of setting SMB permissions from Linux clients, or clarify any limitations.
Mention Linux GUI tools (e.g., Nautilus, Dolphin) for browsing SMB shares, if applicable.
Where Windows tools (MMC, File Browser) are referenced, add Linux equivalents or note the differences in management approaches.
Add a section or callout on how Linux and macOS clients can connect to and use SMB volumes, including authentication and permission considerations.
Ensure that any troubleshooting or next steps include Linux-relevant guidance.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page references PowerShell and REST API usage with PowerShell, but does not provide equivalent Linux or cross-platform automation examples (e.g., Bash, curl, or Python). The REST API section specifically links to 'REST API using PowerShell for Azure NetApp Files', suggesting a Windows-centric approach. No explicit Linux or cross-platform command-line examples are provided for REST API usage, and the only automation example is PowerShell-focused.

Recommendations:

Provide REST API usage examples using cross-platform tools such as curl or HTTPie, and/or include sample scripts in Bash or Python.
When referencing REST API automation, link to or include both PowerShell and Bash/curl examples to ensure parity.
Explicitly state that the Azure CLI is cross-platform and can be used on Windows, Linux, and macOS.
Avoid referencing PowerShell as the primary or sole automation tool; instead, present it alongside alternatives.
Add a section or note for Linux/macOS users on how to perform equivalent operations using native tools.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page contains a section specifically addressing Windows NFS client configuration issues, providing PowerShell commands and Windows-specific mount examples, but does not provide equivalent troubleshooting or configuration guidance for Linux clients. This creates a Windows bias by focusing on Windows tools and omitting Linux examples in areas where both platforms are relevant.

Recommendations:

For sections that address client-side configuration or troubleshooting (e.g., improving folder lookup performance), provide equivalent Linux commands and configuration steps alongside Windows instructions.
When presenting examples (such as mounting NFS volumes), include both Windows and Linux command-line examples to ensure parity.
If a Windows-specific issue is discussed (such as CaseSensitiveLookup), clarify whether similar issues exist on Linux and, if so, provide guidance; if not, explicitly state that the issue is Windows-only.
Review all sections for platform parity and ensure that Linux administrators are equally supported, especially given that NFS is more commonly used in Linux environments.
Consider reordering examples or explanations so that Linux and Windows are presented with equal prominence, or alternate which platform is presented first.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell examples for feature registration, mentioning PowerShell commands before Azure CLI, and omitting direct Linux/CLI examples or screenshots. The registration steps are shown exclusively with PowerShell, and while Azure CLI is referenced, no explicit CLI command examples are given. There are no Linux-specific instructions or parity in command-line guidance.

Recommendations:

Provide explicit Azure CLI command examples (e.g., 'az feature register ...') alongside PowerShell for all registration and status-check steps.
Present Azure CLI examples before or at least equally with PowerShell to avoid Windows-first ordering.
Include screenshots or instructions that are platform-agnostic or show both Windows and Linux environments where applicable.
Clarify that all operations can be performed from Linux/macOS using Azure CLI, and link to relevant CLI documentation.
Consider adding a section or callout for Linux/macOS users to ensure parity and inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by presenting Windows/Powershell workflows and tools first or exclusively in several sections. The instructions for setting SACLs on SMB shares are detailed for Windows administration hosts, with no equivalent step-by-step guidance for Linux clients. Powershell commands are shown (even if commented out), and Windows GUI tools are described in detail, while Linux/NFSv4.1 instructions are minimal and refer to external documentation. There is also a lack of parity in example depth and clarity between Windows and Linux workflows.

Recommendations:

Provide equivalent, step-by-step instructions for setting Audit ACEs on NFSv4.1 shares from a Linux client, including command-line examples (e.g., using nfs4_setfacl).
When mentioning registration or configuration steps, include both Powershell and Azure CLI examples side-by-side, not just as a note.
Balance the depth of explanation for Windows and Linux workflows, ensuring both have clear, actionable steps in the documentation.
Avoid always listing Windows tools or workflows first; alternate or present both platforms in parallel tabs or sections.
Explicitly mention and provide guidance for Linux administration hosts where applicable, not just Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in the way it presents tooling and examples. In the 'Ways to create snapshots' section, PowerShell is listed as a primary tool alongside Azure Portal, REST API, and Azure CLI, but there is no mention of Linux-specific command-line usage or examples. The documentation does not provide explicit Linux shell (bash) examples or highlight Linux-native scripting approaches, and PowerShell is mentioned before any Linux-native alternatives. There are no Linux-specific instructions or parity in scripting examples, and the only scripting reference points to a SQL Server/Windows-centric blog post.

Recommendations:

Add explicit Linux/bash shell examples for snapshot management using Azure CLI, including sample commands.
When listing tools, present Azure CLI and REST API before PowerShell, or group them neutrally, to avoid a Windows-first impression.
Include references or links to Linux/Unix scripting guides for Azure NetApp Files snapshot management.
Provide example scripts for both PowerShell and bash to ensure parity.
Ensure that any external blog or script references include Linux-compatible examples, not just Windows/SQL Server/PowerShell scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows tools, settings, and workflows (such as PowerShell, Notepad, Notepad++, Windows Terminal, Windows Explorer, and region settings) are frequently mentioned first or in greater detail than their Linux equivalents. PowerShell and CMD examples are provided for encoding and file manipulation, while Linux examples are often secondary or less detailed. Some sections (e.g., file encoding conversion) focus on Windows tools and only briefly mention Linux alternatives. There are also more screenshots and step-by-step instructions for Windows environments compared to Linux.

Recommendations:

Ensure Linux examples are presented alongside Windows examples, not just after or as an aside.
Provide equivalent step-by-step instructions and screenshots for Linux tools (e.g., GNOME Terminal, KDE Konsole, nano/vim for encoding, locale settings in Linux, etc.).
When discussing encoding conversion, offer Linux-first examples (e.g., using iconv, file, or recode) before or alongside PowerShell/Windows methods.
Highlight Linux-specific behaviors and troubleshooting tips (e.g., dealing with locale or font issues in popular Linux terminals).
Mention Linux tools (such as Midnight Commander, GNOME Files, or xdg-open) for file management and encoding inspection, not just Windows Explorer.
Balance the number of screenshots and detailed walkthroughs between Windows and Linux environments.
Where possible, use cross-platform tools or commands (e.g., Python scripts, cross-platform editors) to demonstrate encoding handling.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation consistently presents PowerShell (a Windows-centric tool) examples alongside Azure CLI, often listing PowerShell before CLI in explanations and code samples. There is a strong focus on PowerShell-specific switches, parameters, and output handling, with detailed PowerShell scripting shown. No explicit Linux shell (bash) or cross-platform scripting examples are provided beyond Azure CLI, and PowerShell is treated as a primary interface. The documentation assumes familiarity with PowerShell cmdlets and patterns, which may disadvantage Linux/macOS users who do not use PowerShell.

Recommendations:

Ensure Azure CLI examples are always presented first, as it is natively cross-platform and more familiar to Linux/macOS users.
Where PowerShell scripting is shown, provide equivalent bash scripting examples for common tasks (e.g., looping over results, variable assignment).
Clarify that PowerShell Core is available cross-platform, but also provide bash/zsh examples for Linux/macOS users.
Avoid using Windows-specific terminology (e.g., 'module', 'cmdlet') without explanation or Linux equivalents.
Explicitly mention that all Azure CLI commands work identically on Linux, macOS, and Windows, and highlight any OS-specific considerations.
Add a section or callout for Linux/macOS users, linking to relevant shell scripting resources or Azure CLI documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page exhibits a Windows bias by providing restore examples and links that are exclusively or primarily focused on Windows VMs. In the 'Restore an encrypted VM' scenario, only Windows-specific encryption scenarios and PowerShell are mentioned, with no reference to Linux VMs or their restore/encryption processes. There are no Linux-specific examples, tools, or documentation links, and the restore process references (such as PowerShell) are Windows-centric.

Recommendations:

Include equivalent Linux VM restore scenarios, especially for encrypted VMs, with links to relevant Linux documentation.
Provide examples and instructions for restoring both Windows and Linux VMs, including any differences in process or tooling.
Mention and link to Linux-native tools (such as Bash/CLI commands) alongside PowerShell where applicable.
Ensure that documentation for features like Item Level Restore (ILR) and disk encryption covers both Windows and Linux use cases.
Balance references to Windows and Linux in tables and scenario descriptions, so Linux users can easily find relevant guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias in several ways: Windows and PowerShell are referenced more frequently and often before Linux equivalents. Many example links and guidance for advanced scenarios (e.g., restoring with custom images, availability sets, network configurations) point to Windows-specific documentation or PowerShell usage, while Linux or cross-platform alternatives are missing or only mentioned in passing. Some post-restore steps and troubleshooting commands are provided only for Windows (e.g., bcdedit, netdom), with no Linux equivalents or guidance.

Recommendations:

Provide parallel Linux examples and links (e.g., for restoring VMs with custom images, availability sets, or special network configurations, include Linux documentation and CLI/Bash examples).
When referencing PowerShell, also provide Azure CLI or Bash alternatives for all major operations, especially for VM creation and disk attachment.
In post-restore steps, include Linux-specific troubleshooting and recovery guidance (e.g., how to reset SSH keys, repair bootloaders, or rejoin a Linux VM to a domain or directory service).
Avoid linking only to Windows-specific documentation (such as /windows/ URLs); always include or prioritize Linux or cross-platform links where available.
Explicitly mention any differences or additional steps required for Linux VMs in scenarios such as restoring SQL VMs, domain controllers, or VMs with special configurations.
Ensure that screenshots and UI walkthroughs are not Windows-centric, and clarify when steps are identical for Linux VMs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation references Windows-specific tools (Volume Shadow Copy Service - VSS) before mentioning the Linux equivalent (*fsfreeze*), and links to Windows-specific agent and extension documentation without providing Linux equivalents. There are no Linux-specific examples or links, and the pattern of mentioning Windows first suggests a subtle Windows bias.

Recommendations:

When mentioning consistency mechanisms, present Linux and Windows tools in parallel (e.g., 'Volume Shadow Copy Service (VSS) for Windows or fsfreeze for Linux').
Provide links to both Windows and Linux VM Agent and snapshot extension documentation.
Include explicit Linux examples or scenarios, such as referencing the Linux VM agent or snapshot extension documentation.
Ensure that any references to scripts or tools (such as pre/post scripts for Linux) are accompanied by links or further explanation, matching the detail given for Windows.
Review the order of presentation to avoid always listing Windows tools or documentation first.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing more detailed and prioritized information for Windows VMs, especially regarding snapshot consistency and backup tooling. Windows-specific tools (VSS, PowerShell) are mentioned first or exclusively, while Linux guidance is less detailed and relies on users to provide their own scripts. There are no concrete Linux command examples, and automation/restoration guidance is PowerShell-centric.

Recommendations:

Provide Linux command-line examples (e.g., using Azure CLI or Bash) alongside or before PowerShell examples, especially for restore operations.
Offer more detailed, step-by-step Linux backup and restore procedures, including sample pre/post scripts for common applications (e.g., MySQL, PostgreSQL).
Balance the explanation of snapshot consistency mechanisms by giving equal detail to Linux (e.g., describe the 'freeze' tool and common Linux application consistency strategies).
When referencing tools (e.g., VSS for Windows), also mention and explain Linux equivalents (e.g., fsfreeze, LVM snapshots) and their integration with Azure Backup.
Ensure that best practices and troubleshooting sections include Linux-specific advice and not just Windows/PowerShell-centric guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing the Azure portal and PowerShell/CLI scripts for permission management, without providing explicit Linux shell or command-line examples. There is no mention of Linux-specific tools or workflows, and the instructions assume a GUI or PowerShell-centric approach, which may not align with common Linux administration practices for SAP HANA.

Recommendations:

Include explicit Linux shell (bash) command examples for tasks such as mounting disks, managing permissions, and interacting with Azure resources (e.g., using Azure CLI in bash).
Provide parity in instructions for both Windows (PowerShell) and Linux (bash/CLI), ensuring that Linux administrators can follow along without needing to translate PowerShell commands.
Mention Linux-native tools and workflows (such as using SSH, Linux mount commands, and file system management) where relevant, especially for mounting and restoring disks.
Clarify that the procedures are applicable to both Windows and Linux VMs, or specify any OS-specific considerations.
Add screenshots or terminal output examples from Linux environments where GUI steps are not available or not preferred.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides a detailed PowerShell script for configuring NSG rules but does not include equivalent examples using cross-platform tools such as Azure CLI, Bash, or ARM templates. This approach assumes or prioritizes Windows/PowerShell users, potentially excluding Linux or macOS administrators who may prefer or require non-PowerShell tooling.

Recommendations:

Add equivalent Azure CLI (az network nsg rule create ...) examples for all NSG rule creation steps, ideally in Bash syntax.
Consider providing ARM/Bicep template snippets for infrastructure-as-code parity.
Explicitly state that PowerShell is just one option, and link to cross-platform alternatives.
Where possible, present Azure CLI or REST API examples before or alongside PowerShell to emphasize platform neutrality.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation page demonstrates a moderate Windows bias. In configuration tables, Azure PowerShell (a Windows-centric tool) is consistently listed before Azure CLI (which is cross-platform and more common on Linux). There are no explicit Linux-specific examples or references to Linux-native tools or workflows. The documentation assumes familiarity with Windows tools and patterns, such as PowerShell, and does not provide parity for Linux users beyond mentioning Azure CLI.

Recommendations:

Alternate the order of Azure PowerShell and Azure CLI in tables and examples, or list Azure CLI first to better reflect cross-platform usage.
Include explicit Linux-focused examples or notes, such as using Bash scripts or referencing Linux terminal commands where appropriate.
Add guidance or links for configuring Azure Bastion using Linux-native tools or environments, such as Bash, Cloud Shell, or automation via shell scripts.
Clarify that Azure CLI is cross-platform and provide sample commands that can be run on Linux/macOS terminals.
Where PowerShell is mentioned, consider also referencing PowerShell Core (pwsh), which is cross-platform, or clarify when Windows PowerShell is required.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides step-by-step instructions for performing tasks via the Azure Portal (web UI) and Azure PowerShell, but does not include equivalent command-line examples for Linux users (e.g., Azure CLI or Bash). PowerShell is a Windows-centric tool, and its exclusive use in scripting examples may disadvantage Linux or cross-platform users. There are no references to Linux-native tools or shell environments, and no Azure CLI examples are provided.

Recommendations:

Add Azure CLI examples alongside PowerShell for all scripted operations, such as adding or removing custom domains.
Include Bash shell command examples where appropriate, especially for DNS record management or validation.
Explicitly mention that PowerShell Core is cross-platform if PowerShell is to be retained, but still provide Azure CLI as the primary or an equal alternative.
Ensure that any references to tools or commands are not Windows-specific unless absolutely necessary, and always provide Linux/macOS equivalents.
Consider reordering examples to present cross-platform (CLI) options before or alongside Windows-specific tools.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps for migration to Azure App Service, but it does not mention Linux-based .NET hosting scenarios or provide Linux-specific assessment guidance or examples. The linked resources and terminology (e.g., ASP.NET, which has historically been Windows-centric) reinforce a Windows-first perspective, and there is no mention of Linux tools, patterns, or parity.

Recommendations:

Include examples and guidance for assessing .NET web apps hosted on Linux, such as those running on .NET Core or ASP.NET Core on Linux servers.
Mention and link to Linux-compatible assessment tools or scripts, if available.
Clarify whether the assessment process and recommendations apply equally to Linux-hosted .NET apps, and highlight any differences.
Add Linux-specific best practices or considerations for migration readiness and blocker identification.
Ensure that terminology and linked resources reflect both Windows and Linux hosting scenarios where applicable.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation provides detailed, step-by-step SSH access instructions and CLI examples exclusively for Linux containers, while Windows containers are only mentioned in general terms without equivalent technical detail or command-line examples. Additionally, the Windows section appears before the Linux section, which may reinforce a 'windows_first' bias.

Recommendations:

Add equivalent technical details and step-by-step instructions for SSH access to Windows containers, including any available command-line or PowerShell methods, or explicitly state if such options are not supported.
If SSH via CLI is not supported for Windows containers, clarify this limitation early and provide alternative troubleshooting or remote access options for Windows users.
Consider presenting Linux and Windows instructions in parallel or side-by-side to avoid the impression of prioritizing one platform over the other.
Ensure that both Linux and Windows sections include comparable levels of detail, including example commands, screenshots, and troubleshooting tips.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes the use of GitHub Codespaces and Azure App Service, which are cross-platform, but all terminal and deployment instructions are generic and do not mention or show any Linux-specific commands, shell environments, or deployment patterns. There are no explicit Windows-only tools, but the lack of Linux-specific guidance (such as bash commands, Linux package management, or alternative editors) and the absence of any mention of running locally on Linux or WSL, may make Linux users feel less directly supported. The documentation also refers to 'Open in Browser' and other UI actions that may be more familiar to Windows/VS Code users.

Recommendations:

Add explicit instructions or notes for running the sample app and deploying from a local Linux or WSL environment, not just Codespaces.
Include bash/zsh shell command examples alongside dotnet CLI commands, and clarify that all commands work on Linux, macOS, and Windows.
Mention Linux package management for .NET SDK installation (e.g., apt, yum) in prerequisites if not already covered elsewhere.
Clarify that 'Open in Browser' and other UI actions can be performed in any OS, and provide alternative instructions for users working in a purely terminal environment.
Consider adding a section or callout for Linux/macOS users to ensure parity and inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation generally maintains good cross-platform parity, but there are subtle signs of Windows bias. In particular, references to 'command prompt' and 'Terminal or command prompt' as development environments, and recommendations to use remote build when developing on Windows, suggest a Windows-first perspective. The documentation also mentions that Python is supported only on Linux-based hosting plans, but local development on Windows is possible. There are no explicit PowerShell-heavy examples, and Linux is well-represented in hosting and deployment sections. However, Linux CLI tools (like bash) are not mentioned, and Windows terminology (e.g., 'command prompt') is used preferentially.

Recommendations:

Use neutral terminology such as 'terminal' or 'shell' instead of 'command prompt' to avoid Windows-centric language.
Explicitly mention both Windows and Linux/macOS development environments and tools (e.g., 'Command Prompt or Bash terminal') in all relevant sections.
Provide example commands for both Windows and Linux shells where applicable, especially in setup and deployment instructions.
Clarify that Azure Functions Core Tools and related workflows are fully supported on Linux/macOS, and link to any Linux/macOS-specific guidance if available.
When recommending remote or local build, explain the rationale for both Windows and Linux users, and avoid implying that Windows is the default or primary development environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation generally uses cross-platform command-line tools (Azure CLI, Azure Functions Core Tools) and avoids explicit Windows-only instructions. However, there is subtle Windows bias in the ordering and presentation of examples: in the Java section, PowerShell and Cmd examples are given alongside Bash, and Windows-specific command shells are mentioned before Bash. File path examples (e.g., '\src\main\java\com\fabrikam') use Windows-style backslashes. There is no explicit Linux example for certain steps, and Windows command-line environments are referenced more prominently than Linux equivalents.

Recommendations:

In the Java section, present Bash examples before PowerShell and Cmd, or group all shell examples equally without implying priority.
When referencing file paths, use POSIX-style forward slashes or provide both Windows and Linux path formats.
Explicitly mention that all Azure CLI and Azure Functions Core Tools commands work on Linux, macOS, and Windows, and provide example terminal commands for both Bash and PowerShell/Cmd where appropriate.
Ensure that any references to command prompts or shells (e.g., 'terminal or command prompt') clarify that this includes Linux/macOS terminals, not just Windows Command Prompt.
If referencing tools like jq, clarify installation steps for both Windows and Linux, or link to cross-platform installation instructions.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides a PowerShell example for checking feature registration status and mentions Azure CLI as an alternative, but does not provide a direct Linux shell or Bash example. The PowerShell example is presented first, which may suggest a Windows-centric approach. No explicit Linux-only tools or patterns are referenced, and the CLI mention is generic, but the ordering and example selection indicate a mild Windows bias.

Recommendations:

Provide both Azure PowerShell and Azure CLI (Bash/shell) examples side-by-side when showing command-line instructions.
Present Azure CLI (which is cross-platform and commonly used on Linux) examples before or alongside PowerShell examples.
Explicitly mention that Azure CLI commands can be run in Bash or other Unix shells, and provide sample Bash command blocks.
Where possible, include Linux-specific considerations or links, especially since performance benchmarks for Linux are referenced.
Review all command snippets and ensure parity for both Windows and Linux users in instructions and examples.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation demonstrates a moderate Windows bias by presenting Azure PowerShell commands first and in detail for feature registration, with Azure CLI (cross-platform) only mentioned in passing. No Linux-specific examples, screenshots, or command-line patterns are provided, and the initial registration steps assume familiarity with PowerShell.

Recommendations:

Provide Azure CLI examples alongside PowerShell for all command-line operations, not just as a mention.
Explicitly state that both PowerShell and CLI are supported, and clarify which is cross-platform.
Include screenshots or terminal examples from Linux environments where applicable.
Avoid assuming PowerShell as the default; present CLI and PowerShell examples in parallel or alternate their order.
Add a note about platform compatibility for all command-line instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation provides both Linux (NFS) and Windows (SMB) examples for restoring files from snapshots. However, the Windows section includes additional GUI-based methods (such as using 'Previous Versions') and screenshots, while the Linux section is limited to basic command-line instructions. Windows-specific tools and patterns (GUI navigation, context menus, 'Previous Versions' tab) are described in more detail, and the Windows section is longer and more visually supported. The Linux section lacks parity in terms of advanced or alternative restoration methods (e.g., using file managers or snapshot browsing tools).

Recommendations:

Add screenshots or step-by-step instructions for restoring files using popular Linux desktop file managers (e.g., Nautilus, Dolphin) to match the Windows GUI approach.
Include information about advanced Linux restoration options, such as using graphical snapshot browsers if available, or integrating with desktop environment features.
Provide parity in detail and visual aids for both Linux and Windows sections to ensure equal clarity and usability.
Mention any Linux equivalents to the Windows 'Previous Versions' feature, or clarify if such features are not available.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation provides extensive coverage of both Windows/SMB and Linux/NFS features, protocols, and enhancements. However, there is a notable tendency to mention Windows/SMB (e.g., Windows File Explorer, NTFS, Active Directory, SMB-specific features) before Linux/NFS equivalents in several feature descriptions. Some features and examples are described primarily in Windows terms (e.g., 'Windows client hides the folder', 'Windows File Explorer', 'NTFS security style') without always providing parallel Linux/NFS terminology or examples. There are also several references to Windows-centric tools and workflows (e.g., FSLogix, Citrix App Layering, Azure VMware Solution) that may not have direct Linux analogs.

Recommendations:

When describing features that apply to both SMB/Windows and NFS/Linux, ensure that Linux/NFS terminology and usage are mentioned alongside or before Windows/SMB terms.
Where features are described in Windows-centric terms (e.g., 'Windows File Explorer', 'NTFS security style'), add equivalent Linux/NFS explanations (e.g., 'Linux directory listing', 'UNIX permissions') and provide examples for both platforms.
For features that are only relevant to Windows/SMB (e.g., FSLogix, Citrix App Layering), clarify their scope and, where possible, mention if there are similar Linux/NFS solutions or explicitly state that the feature is Windows-only.
Review the ordering of protocol mentions (e.g., 'SMB, NFSv4.1, and dual-protocol') to avoid consistently listing Windows/SMB first, which can subtly reinforce a Windows-first perception.
Where tools or workflows are described (e.g., restoring files, managing shares), provide example commands or procedures for both Windows and Linux clients where applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for deployment commands and role assignment, but PowerShell is consistently presented before CLI in some sections (e.g., role assignment), and there is no mention of Linux-specific considerations or examples. The use of PowerShell commands and references to Azure PowerShell may implicitly favor Windows users, as PowerShell is more native to Windows environments, even though it is cross-platform. There are no explicit Linux-only examples, nor is there guidance for Linux users regarding shell usage or environment differences.

Recommendations:

Present Azure CLI examples before PowerShell examples, as Azure CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide shell-agnostic examples (e.g., bash/zsh).
Where PowerShell is used, clarify that PowerShell Core is available on Linux and macOS, or provide equivalent bash examples if possible.
Include a brief section or note on running these commands from Linux terminals, including any prerequisites or differences (e.g., line continuation characters).
Ensure that all code tabs and examples are balanced between CLI and PowerShell, and avoid defaulting to PowerShell in narrative explanations.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a mild Windows bias. Specifically, the only explicit tooling example given for remediation (the Azure VMware Solution Run command Set-Tools-Repo) is associated with VMware Tools for Windows, and there are no Linux-specific examples or equivalent Linux remediation guidance. There are no PowerShell scripts or Windows command-line examples, but the mention of 'VMware Tools for Windows' and lack of Linux parity in those entries is notable. Most other issues are platform-agnostic or refer to VMware/NSX/ESXi interfaces, which are cross-platform.

Recommendations:

Where remediation steps mention 'VMware Tools for Windows', also specify if there are equivalent steps or requirements for VMware Tools for Linux or other guest OSes.
If the 'Set-Tools-Repo' command is applicable to Linux VMs, clarify this; if not, provide Linux-specific remediation steps or note any differences.
For any guest OS-related vulnerabilities or updates, explicitly mention both Windows and Linux guest considerations, or state if the issue is Windows-only.
Consider adding a note in the relevant issues table rows to clarify platform applicability (e.g., 'Affects Windows guests only', 'Linux guests not impacted', or 'See Linux instructions here').

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation demonstrates a 'windows_first' bias, as it references Windows-specific VM creation instructions before Linux equivalents and provides a more detailed, step-by-step installation process for the Windows VM agent compared to Linux. However, both Windows and Linux agent installation methods are mentioned, and the rest of the guide is largely platform-agnostic, focusing on the Azure portal UI.

Recommendations:

Provide parallel links to both Windows and Linux VM creation guides in the introduction, or use a neutral link that covers both.
Ensure that installation instructions for the VM agent are equally detailed for both Windows and Linux, including explicit commands or steps for common Linux distributions.
Where possible, present Windows and Linux instructions side-by-side or in tabs, rather than listing Windows first.
Review all screenshots and examples to ensure they are not Windows-centric and represent both platforms where relevant.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display overt Windows bias in terms of tools, commands, or PowerShell usage. However, it lacks any platform-specific examples, and all SDK code samples are limited to C# (.NET) and JavaScript, with no Linux- or Unix-specific command-line, shell, or environment examples. There is no mention of Linux tools, shell commands, or cross-platform CLI usage, and the developer workflow is described entirely through the Azure Portal UI and SDKs, which may implicitly favor Windows/.NET developers.

Recommendations:

Add explicit Linux/Unix command-line examples for provisioning and sending SMS, such as using the Azure CLI or cURL.
Include Python SDK examples as soon as the SDK is available, and mention its roadmap.
Clarify that the APIs and SDKs are cross-platform and can be used from Linux, macOS, and Windows environments.
Provide guidance or links for headless/server-side provisioning and sending (e.g., via CLI or REST), not just Azure Portal UI.
Mention any platform-specific requirements or parity (e.g., if all SDKs work identically on Linux and Windows).

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display overt Windows bias in the form of Windows-specific commands, PowerShell usage, or Windows-first ordering. However, it lacks any explicit Linux or cross-platform shell examples, and does not mention OS-specific considerations. All command-line instructions are given using the Azure CLI, which is cross-platform, but there are no examples or notes about running these commands in Linux/macOS shells, nor are there any references to Linux-specific tools or environments.

Recommendations:

Explicitly state that Azure CLI commands work on Windows, Linux, and macOS, and provide any necessary notes about shell differences (e.g., line continuation syntax).
Add example commands or screenshots from a Linux terminal to demonstrate parity.
If there are any OS-specific prerequisites or behaviors (such as file path formats or authentication methods), document these for both Windows and Linux.
Where screenshots are used, consider including at least one from a Linux environment.
If referencing local development or testing, mention both Windows and Linux environments to ensure inclusivity.

Create pull request

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