Scan Details - Linux-first Docs for Azure

479

Pages Scanned

64

Pages Flagged

479

Changed Pages

13.4%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:01:00 Scan started

Scan Information

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

Finished At: In Progress

Status: in_progress

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by presenting Azure PowerShell instructions and references before Azure CLI in all relevant sections. PowerShell is a Windows-centric tool, and its precedence over CLI (which is cross-platform and more common on Linux/macOS) may disadvantage Linux users. Additionally, there are no explicit Linux-specific examples or screenshots, and the use of PowerShell cmdlets as the primary scripting example further reinforces the Windows-first approach.

Recommendations:

Present Azure CLI instructions before or alongside PowerShell in all sections, as CLI is cross-platform and preferred by many Linux users.
Include explicit notes or examples for Linux/macOS environments, such as shell commands or terminal screenshots.
Where scripting is shown, provide Bash or shell script equivalents to PowerShell cmdlets.
Clarify that both Azure CLI and PowerShell are supported on all platforms, and link to installation guides for each.
Ensure screenshots and UI walkthroughs do not assume a Windows environment (e.g., avoid showing Windows-specific UI elements or file paths).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and cmdlets for migration and preview registration, without providing equivalent Azure CLI (cross-platform) or Bash examples. The only command-line examples use PowerShell syntax, and the migration script is specifically described as a PowerShell script. There is no mention of Linux-specific tools, nor are cross-platform alternatives (such as Bash or native Azure CLI commands) presented alongside or before the PowerShell examples.

Recommendations:

Provide Azure CLI (bash/shell) examples alongside all PowerShell commands, especially for migration and preview registration/unregistration.
Clarify that Azure CLI commands are cross-platform and can be used on Linux, macOS, and Windows.
If migration scripts are only available in PowerShell, offer equivalent scripts or guidance for Bash or Python where possible.
In 'Next steps', include links to tutorials or modules that use Azure CLI and/or Bash, not just PowerShell.
Review and update language to avoid implying PowerShell is the default or only supported automation tool.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a bias toward Windows by providing only a PowerShell example for resource cleanup (Remove-AzResourceGroup), referencing IIS (a Windows web server) as the default backend for validation, and omitting Linux/CLI alternatives for these steps. There are no Linux-specific examples or mentions of Linux tools for validation or resource management.

Recommendations:

Provide equivalent Azure CLI commands for resource group deletion (e.g., az group delete --name <resource group name>), which work cross-platform.
Include instructions or examples for validating the deployment using a Linux-based backend (such as Apache or Nginx) in addition to IIS.
When referencing backend VMs, clarify that Linux VMs can be used and provide sample scripts or guidance for setting up a simple web server on Linux.
Ensure that all PowerShell examples are paired with Azure CLI equivalents, and present both options side-by-side or in parallel sections.
Avoid assuming IIS as the default test method; offer browser-based or curl-based validation steps that are OS-agnostic.

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 use Windows-specific tools such as the App Service Migration Assistant (available as an MSI installer) and PowerShell scripts. There are no references to Linux-based .NET hosting environments (such as Kestrel, Apache, or Nginx), nor are there migration paths or tools described for Linux servers. The documentation consistently mentions Windows and Windows tools first (and often exclusively), with no Linux parity in examples, tools, or migration scenarios.

Recommendations:

Add documentation and tooling for migrating .NET web apps hosted on Linux servers (e.g., Kestrel, Apache, Nginx) to Azure App Service.
Provide Linux-specific migration examples and scripts, such as Bash or shell scripts, alongside PowerShell scripts.
Mention Linux migration scenarios and tools in parallel with Windows/IIS scenarios, not just as an afterthought.
Clarify whether the App Service Migration Assistant or similar tools support Linux-based .NET apps, and if not, provide guidance or alternatives for Linux users.
Include references to containerization for Linux-based .NET apps, not just Windows Containers.
Ensure that resource tables and tool lists include Linux-compatible options where available.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a moderate Windows bias. It references Windows-specific tools and patterns (such as web.config and iisnode), omits equivalent Linux-native configuration examples, and presents Windows approaches before mentioning Linux alternatives. While there is some mention of Linux (e.g., using PM2 for Node.js), the guidance is generally Windows-centric, and Linux-specific best practices are underrepresented.

Recommendations:

For features like auto-healing, provide Linux-native configuration guidance (e.g., using app settings or startup scripts) alongside web.config instructions.
When mentioning iisnode or web.config, clarify that these are Windows-specific and provide equivalent Linux approaches (such as using process managers like PM2, or configuring environment variables).
Ensure that examples and recommendations are presented for both Windows and Linux App Service environments, ideally side-by-side.
Where possible, avoid assuming the use of Windows-specific file structures or configuration files; instead, mention both Windows and Linux paths and conventions.
Expand troubleshooting and best practices sections to include Linux-native tools and diagnostics (e.g., using Kudu, SSH, or Linux logs).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. In sections where both Windows and Linux are relevant (such as SKU availability), Windows examples and terminology are presented first. The automation section provides both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric) examples, but does not mention Bash scripting or Linux-native automation tools. The UI walkthroughs and screenshots are based on the Azure Portal, which is platform-agnostic, but the scripting focus leans toward Windows tools and patterns.

Recommendations:

Ensure Linux and Windows examples are given equal prominence and order is alternated or clarified as arbitrary.
Include Bash or shell script examples for Linux users alongside PowerShell examples, especially in automation sections.
Explicitly state that Azure CLI commands work on all platforms and can be run in Bash, PowerShell, or Cloud Shell.
If referencing PowerShell, consider also referencing Linux-native scripting environments where appropriate.
Where possible, clarify that the Azure Portal UI is the same across platforms to avoid perceived bias.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias in several areas. Windows examples and terminology are presented before Linux equivalents, especially in the availability section. PowerShell scripting is highlighted alongside Azure CLI, but there are no Linux shell (bash) or scripting examples. The use of Windows-centric tools and patterns (e.g., PowerShell, references to Windows SKUs) is prevalent, while Linux-specific automation or deployment workflows are not covered. There is also a lack of parity in scripting examples for Linux users.

Recommendations:

Present Linux and Windows options in parallel or alternate their order to avoid a Windows-first impression.
Include bash shell scripting examples for automating tasks, not just Azure CLI and PowerShell.
Expand automation sections to mention Linux-native tools and scripting environments (e.g., bash, sh) and provide equivalent examples.
Clarify when instructions or features are Windows-specific, and provide Linux-specific guidance where applicable.
Ensure that all code samples and automation workflows are cross-platform or provide platform-specific variants side by side.

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, while Linux alternatives are sometimes less detailed or missing. The Windows GUI is featured prominently, with Linux users directed to CLI-only workflows. Troubleshooting and connectivity testing examples use Windows-centric tools (e.g., PowerShell's Test-NetConnection) without providing equivalent Linux commands. Some sections, such as upgrade instructions and troubleshooting, focus on Windows-specific patterns or omit Linux parity.

Recommendations:

Provide Linux command-line equivalents for all PowerShell examples (e.g., use 'nc', 'telnet', or 'curl' for connectivity tests).
When presenting instructions, alternate or parallelize Windows and Linux sections rather than always listing Windows first.
Include more detailed Linux installation, configuration, and troubleshooting steps, matching the depth given to Windows.
Highlight any differences or limitations for Linux users up front, and offer workarounds or alternatives where possible.
Where GUI tools are Windows-only, suggest or develop equivalent CLI workflows for Linux and document them clearly.
In troubleshooting, include Linux-native tools (e.g., 'ss', 'netcat', 'dig', 'nslookup') alongside Windows tools.
Ensure parity in upgrade and maintenance instructions for both platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows bias primarily in the section addressing the identification of impacted Traffic Manager endpoints, where only a PowerShell script is provided for detecting non-Azure endpoints. There are no equivalent Bash, Azure CLI, or cross-platform scripting examples for Linux/macOS users. The instructions for running the script assume a Windows/PowerShell environment and do not mention alternatives for Linux users. Elsewhere, the documentation does use Azure CLI and REST API examples, which are cross-platform, but the exclusive reliance on PowerShell for a key scenario stands out.

Recommendations:

Provide equivalent Bash or Azure CLI scripts for identifying non-Azure Traffic Manager endpoints, or at least mention how Linux/macOS users can achieve the same result.
When referencing scripts, clarify OS compatibility and offer alternatives or guidance for non-Windows environments.
Where possible, prioritize Azure CLI examples (which are cross-platform) or present them alongside PowerShell scripts to ensure parity.
Explicitly state when a tool or script is Windows-only and direct users to cross-platform documentation or community solutions.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation 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. The tools and patterns described (Azure Migrate appliance, IIS, VMware) are all Windows-oriented, and Linux alternatives are not addressed.

Recommendations:

Include information on discovering .NET web apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel).
Provide examples or guidance for using Azure Migrate or other tools to discover Linux-based .NET deployments.
Mention Linux environments explicitly where applicable, and clarify any limitations or differences in discovery capabilities between Windows and Linux.
Add references or links to documentation covering Linux discovery scenarios for .NET apps.

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 with iisnode. All configuration, troubleshooting, and operational examples are tailored to Windows, referencing Windows-specific tools (e.g., CMD, PowerShell, web.config, iisnode, Win32 error codes, named pipes, d:\ paths). There are no Linux equivalents, examples, or guidance, and Linux-based deployment or troubleshooting is not addressed.

Recommendations:

Provide equivalent guidance and examples for Node.js applications running on Azure App Service for Linux.
Include Linux-specific troubleshooting steps, such as using SSH, Bash, and Linux file paths.
Reference Linux-native process managers (e.g., PM2, systemd) and configuration files instead of only iisnode and web.config.
Add examples for monitoring, logging, and debugging on Linux (e.g., using stdout logs, Linux diagnostic tools, and Azure Kudu Bash console).
Clearly separate Windows-specific and Linux-specific instructions, or provide a platform selection pivot at the top of the article.
Mention Linux equivalents for any Windows-specific tools or patterns referenced (e.g., how to check logs, manage processes, or debug on Linux).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias by referencing Azure Storage Explorer with a direct link to Windows-specific instructions and not providing equivalent Linux tooling or instructions. The Storage Explorer SAS generation link includes a '?tabs=windows' parameter, and there are no examples or notes for Linux users regarding uploading files or generating SAS tokens. All command-line examples use Azure CLI, which is cross-platform, but the only GUI tool mentioned is Storage Explorer with a Windows focus. There is no mention of Linux-native tools (e.g., azcopy, Linux file managers) or parity in GUI instructions.

Recommendations:

Add explicit instructions or links for Linux and macOS users on how to upload files and generate SAS tokens, either using Azure Storage Explorer (with appropriate tabs/sections for each OS) or alternative tools like azcopy.
Remove or supplement the '?tabs=windows' parameter in documentation links to ensure cross-platform guidance is visible.
Mention that Azure Storage Explorer is available on Windows, macOS, and Linux, and provide platform-specific instructions or clarify that the steps are similar across platforms.
Consider including CLI-based alternatives (e.g., az storage blob upload, az storage blob generate-sas) for users who prefer or require command-line solutions, especially on Linux.
Review all tool references to ensure Linux users are not left without clear, actionable steps.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page exhibits 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 similar tasks on Linux-based App Service plans. There are no Linux-specific instructions or examples, and Windows tools and patterns are presented as the default or only option.

Recommendations:

Add equivalent instructions and examples for Linux-based App Service plans, including how to check .NET runtime versions and access diagnostic tools on Linux.
Provide Linux shell (bash) commands alongside CMD/PowerShell examples, and clarify when a command or tool is Windows-specific.
Mention and link to documentation for configuring ASP.NET apps on Linux App Service, including differences in environment variable access, file paths, and diagnostic tooling.
Clearly indicate when a section applies only to Windows and provide parity for Linux scenarios to ensure cross-platform inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for advanced Tomcat server-level configuration, but the Windows section is significantly longer, more detailed, and uses Windows-specific tools (PowerShell, CMD scripts, Windows paths) without equivalent Linux scripting examples. Windows instructions are presented before Linux in some places, and the PowerShell script is much more elaborate than the Linux shell script. There is no explicit parity in scripting complexity or guidance for Linux users.

Recommendations:

Provide a Linux shell script example for automating Tomcat configuration changes, matching the detail and robustness of the Windows PowerShell script.
Ensure that Linux and Windows instructions are presented with equal prominence and in parallel structure, rather than Windows-first.
Include Linux-native tooling and patterns (e.g., bash, sh, systemd, cron) where appropriate, not just Windows tools.
Offer a downloadable sample Linux startup script that mirrors the PowerShell script's logic (checking for marker files, copying Tomcat, applying XSLT, etc.).
Clarify any differences in capabilities or limitations between Windows and Linux App Service environments for Tomcat configuration.
Where possible, use cross-platform tools or highlight them (e.g., using Azure CLI for both platforms) and avoid assuming Windows as the default.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page presents Windows container information before Linux, and the Windows section lacks parity with the Linux section. Only browser-based SSH is described for Windows containers, with no mention of CLI or PowerShell-based access, while the Linux section provides detailed Azure CLI and SSH command-line instructions. There are no PowerShell or Windows-native SSH client examples, and the documentation does not mention Windows command-line tools or provide equivalent instructions for Windows users.

Recommendations:

Provide equivalent command-line SSH access instructions for Windows containers, or clearly state if such access is unsupported.
If CLI-based SSH access is not available for Windows containers, explain the limitation and suggest any available alternatives (such as PowerShell remoting, RDP, or other tools).
Include examples using Windows-native SSH clients or PowerShell where appropriate, especially for users on Windows workstations.
Balance the order of presentation so that Linux and Windows instructions are given equal prominence, or use parallel structure in the documentation.
If certain features are only available on Linux, explicitly state this at the top of the page to set expectations for Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, describing deployment directories and behaviors primarily in Windows terms, and omitting explicit Linux/macOS command-line examples or file system details. There is also a reliance on Windows-centric patterns (backslashes in paths, drive letters) and no Linux-specific troubleshooting or parity in examples.

Recommendations:

Present both Windows and Linux file paths together, or list Linux paths first where appropriate (e.g., "/home/site/wwwroot" alongside "D:\home\site\wwwroot").
Include Linux/macOS-specific examples and notes, especially for file system operations, directory creation, and troubleshooting.
Avoid using only Windows-style paths (backslashes, drive letters) in explanations; always provide the Linux equivalent.
Explicitly mention any differences in behavior or requirements between Windows and Linux App Service plans.
Add troubleshooting tips relevant to Linux environments (e.g., permissions, case sensitivity).
Where possible, use platform-neutral language and examples, or provide tabs/switchers for Windows and Linux instructions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows by referencing Windows/Visual Studio tooling and workflows first (e.g., right-click instructions, NuGet Package Manager in Visual Studio), and omits explicit Linux or cross-platform command-line examples for key steps such as file creation and package installation. There are no Linux-specific or cross-platform instructions for tasks like editing files, managing secrets, or deploying, and the CLI instructions are only linked, not shown inline.

Recommendations:

Provide explicit Linux and cross-platform command-line instructions for all steps, including file creation (e.g., using 'touch' and editors like 'nano' or 'vim'), package installation (using 'dotnet CLI' and 'nuget CLI'), and environment variable management.
When referencing tools, mention cross-platform options (e.g., VS Code, JetBrains Rider) alongside Visual Studio, and avoid assuming a GUI workflow.
Include inline examples for both Windows and Linux for critical steps, such as setting environment variables, managing Azure Key Vault secrets, and deploying to App Service.
Structure instructions so that CLI/cross-platform approaches are presented before or alongside Windows/GUI-specific methods.
Add a note clarifying that all steps are possible on Linux/macOS and provide links to relevant documentation for those platforms.

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 users (such as Azure CLI/bash). The use of PowerShell cmdlets and Windows-centric scripting patterns is exclusive, and no mention is made of Linux-native tools or workflows. The PowerShell section appears before any mention of cross-platform or ARM template approaches, reinforcing the Windows-first perspective.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands to support Linux and macOS users.
Include bash shell script examples alongside PowerShell to demonstrate parity.
Explicitly mention that both PowerShell and Azure CLI can be used, and provide links to cross-platform tool documentation.
Reorder sections or provide parallel examples so that Windows and Linux workflows are presented equally.
Clarify that ARM templates are platform-agnostic and can be used from any OS, and provide command-line deployment examples using az CLI.

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 the CLI examples without clarifying platform applicability. There is no explicit mention that PowerShell commands are Windows-centric or that Azure CLI is cross-platform. Additionally, outbound IPv6 support is noted as being available only for Windows apps, but there is no guidance or parity for Linux users beyond stating the limitation. No Linux-specific tools or shell examples (e.g., bash scripting) are provided, and the documentation does not clarify that Azure CLI commands work identically on Linux, macOS, and Windows.

Recommendations:

Clearly label PowerShell examples as Windows-specific and Azure CLI examples as cross-platform (Linux, macOS, Windows).
Present Azure CLI (cross-platform) examples before PowerShell (Windows-centric) examples to avoid 'windows_first' bias.
Add explicit notes or callouts for Linux/macOS users, confirming that Azure CLI commands are fully supported on those platforms.
Where outbound IPv6 support is Windows-only, provide a clear roadmap or workaround for Linux users, or link to relevant feature requests.
Consider including bash or shell script examples for common tasks, especially in sections where only PowerShell is shown.
Where features are Windows-only, provide context and alternatives for Linux users, or at least acknowledge the gap.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-style paths (e.g., D:\home), using Windows terminology and tools (such as Kudu/SCM), and omitting Linux-specific examples or guidance. While there is a brief mention of Linux containers, the main documentation, examples, and folder structures are Windows-centric, with no equivalent Linux paths, commands, or operational details provided.

Recommendations:

Include Linux-specific examples and folder paths (e.g., /home/site/wwwroot) alongside Windows examples.
Clarify differences in local cache behavior and configuration for Linux-based App Service plans.
Provide parity in tooling instructions, such as how to inspect environment variables or folder structures on Linux (e.g., using SSH or Linux shell commands).
Explicitly state when a feature or instruction is Windows-only, and offer alternatives or workarounds for Linux users.
Reference Linux tools or commands (such as ls, du, or cat) where appropriate, and provide equivalent instructions for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by providing detailed, explicit guidance and calculations for Windows Containers (e.g., subnet sizing), while Linux-specific scenarios are only briefly mentioned (such as a single note about Linux continuous deployment network dependencies). There are no Linux container-specific examples or parity in subnet/IP calculations, and Windows terminology and features (e.g., Windows Server Active Directory, NetBIOS) are referenced without Linux equivalents or alternatives. The overall structure and examples prioritize Windows scenarios and tools.

Recommendations:

Add equivalent subnet/IP address calculation examples for Linux containers, including any unique considerations or limitations.
Provide Linux-specific guidance for App Service plans, such as scaling, networking, and known limitations, similar to the Windows Containers section.
Include Linux-relevant features or caveats (e.g., integration with Linux authentication systems, Linux-specific networking behaviors) where Windows-specific features are discussed.
Ensure that Linux and Windows examples are presented with equal prominence, or alternate which platform is discussed first in each section.
Where Windows-only features are mentioned (e.g., NetBIOS, Windows Server Active Directory), explicitly state their absence or alternatives for Linux workloads.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias: logging types and features are described with Windows as the primary or only supported platform in several sections, with Linux-specific instructions and capabilities less detailed or omitted. Several advanced logging features (web server logging, detailed error messages, failed request tracing) are described only for Windows, with no Linux equivalents or workarounds mentioned. Tooling references (e.g., Log Parser, W3C log format) are Windows-centric. Linux logging options are described more briefly and lack parity in detail and functionality.

Recommendations:

Provide equivalent Linux examples and instructions for all logging types, or clearly state if a feature is unavailable on Linux.
Explicitly document any feature gaps between Windows and Linux App Service plans, and suggest alternative approaches or workarounds for Linux users.
Include Linux-friendly tooling and log analysis options (e.g., mention open-source log viewers, CLI tools, or how to access logs via SSH/SFTP).
Ensure that for every Windows-specific section, there is a corresponding Linux section or a clear note about platform support.
List platform support for each logging feature in a summary table at the top for quick reference.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows-specific tools and patterns, such as IIS diagnostics, PowerShell commands, and references to Windows-only features (e.g., Procdump, .NET Profiler for Windows). There is a lack of Linux-specific troubleshooting guidance, and Linux-native tools or examples are not mentioned. The Kudu Console is described in terms of PowerShell and DOS commands, with no mention of Bash or Linux shell support. Diagnostic and mitigation steps are presented from a Windows-centric perspective, with Linux alternatives either omitted or not given equal prominence.

Recommendations:

Add explicit Linux troubleshooting steps and examples, such as using Bash in Kudu, Linux-native diagnostic tools (e.g., strace, lsof, top), and log file locations for Linux-based App Service plans.
When referencing tools like Procdump or IIS logs, provide Linux equivalents or note their applicability (e.g., using gcore for memory dumps on Linux).
In sections about enabling diagnostics or profiling, clarify which features are available on Linux App Service and provide links to relevant Linux documentation.
Balance PowerShell examples with Azure CLI or Bash alternatives, especially for app management and automation tasks.
Review all tool and feature references to ensure Linux users are not left without guidance or are directed to appropriate resources.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation is heavily focused on Windows and PowerShell tooling, with all examples and instructions using PowerShell modules and cmdlets. There is no mention of Linux, Bash, or cross-platform scripting alternatives, and the credential management workflow is described solely in terms of Windows PowerShell constructs. The documentation assumes the use of Windows-centric tools and patterns throughout.

Recommendations:

Provide equivalent examples using Azure CLI (az) and Bash scripting for Linux and cross-platform users.
Mention that Azure Automation supports Python runbooks and provide a Python example for credential management and resource automation.
Clarify which steps and modules are cross-platform, and which are Windows-only, to help non-Windows users understand applicability.
Include references to Linux authentication workflows, such as using service principals or managed identities with az CLI.
Reorder sections or add parallel instructions so that Linux/cross-platform methods are not always secondary to Windows/PowerShell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation shows a mild Windows bias: Windows-specific tools and patterns are mentioned prominently, such as recommending WSL for Windows users and referencing Windows Terminal. Azure PowerShell is listed alongside Azure CLI for retrieving cache keys, and in some places, Windows-specific terminology (e.g., 'console', 'terminal') is used before Linux equivalents. However, Linux installation and usage are well covered, and most command-line examples are cross-platform.

Recommendations:

When listing methods to retrieve cache keys, mention Azure CLI before Azure PowerShell, or provide both examples together with equal prominence.
In installation instructions, clarify that redis-cli runs natively on Linux and macOS, and that Windows users can use WSL or native Windows builds (if available), rather than implying WSL is the only way.
When referencing terminals or shells, use neutral language (e.g., 'open a terminal or command prompt') and provide equivalent instructions for Linux, macOS, and Windows.
For alternative tools, clarify platform support for each tool and avoid listing Windows-specific tools or patterns first.
Consider providing explicit Linux/macOS command examples for retrieving cache keys (e.g., using Azure CLI), not just referencing PowerShell.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. In several sections, Windows-specific tools, settings, and commands are mentioned before or more prominently than their Linux equivalents. Some examples, such as checking or setting the 32-bit/64-bit worker process, are shown only for Windows or are presented with Windows first. In deployment and debugging sections, Visual Studio (a Windows-centric tool) is emphasized, and Linux-specific guidance is less detailed or deferred. There are also places where Linux-specific examples or clarifications are missing or less visible.

Recommendations:

Ensure that all CLI commands and configuration examples are provided for both Windows and Linux, with equal prominence and clarity.
When referencing tools like Visual Studio, also mention and provide equivalent instructions for cross-platform alternatives such as Visual Studio Code or JetBrains Rider.
In tables or lists where both Windows and Linux options exist, present them in parallel or in alphabetical order, rather than Windows first.
For deployment, debugging, and performance optimization sections, include explicit Linux examples and troubleshooting steps, not just Windows-focused guidance.
Review all references to settings (e.g., netFrameworkVersion, linuxFxVersion) to ensure both Windows and Linux are equally covered, and that Linux-specific requirements are not only in footnotes or secondary tabs.
Where PowerShell or Windows-specific commands are mentioned, provide Bash or Linux shell equivalents.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias. While it provides both Bash and Windows Command Prompt (Cmd) examples for Maven and Azure CLI commands, the structure consistently presents Windows (Cmd) examples immediately after Bash, sometimes with more prominence. There is also a notable emphasis on Visual Studio Code and other Microsoft-centric tools, which are more commonly associated with Windows environments. However, Linux is represented in the OS support tables, and Bash examples are present throughout. There are no exclusive PowerShell-only instructions, but the documentation does not mention Linux-specific tools or patterns (e.g., native Linux package managers, shell scripting, or troubleshooting).

Recommendations:

Present Bash (Linux/macOS) examples before Windows (Cmd) examples to reflect the prevalence of Linux in Java development.
Include explicit references to Linux/macOS Terminal in all command-line instructions, not just 'Terminal' or 'command prompt'.
Add troubleshooting or setup notes for common Linux/macOS issues (e.g., setting JAVA_HOME, file permissions).
Mention Linux-native editors (e.g., Vim, Emacs) or tools where appropriate, or at least acknowledge their use.
Ensure parity in tool recommendations by highlighting cross-platform tools and workflows, not just Microsoft-centric ones.
Where OS-specific instructions are needed, provide equal detail for Linux/macOS and Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation generally maintains good cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows terminology ("command prompt") is used alongside or before more neutral terms ("terminal"). Visual Studio Code is highlighted as the primary editor, which is cross-platform but often associated with Windows. The publishing workflow recommends remote build for users developing on Windows, and local build is discouraged for Windows users. There is also a reference to the Python standard library being installed with Python on Windows, while on Unix-based systems it's provided by package collections, which may suggest a Windows-centric perspective. However, most code examples, commands, and folder structures are platform-neutral, and Linux hosting is clearly stated as the only supported production environment for Python on Azure Functions.

Recommendations:

Use platform-neutral terms such as "terminal" or "shell" instead of "command prompt" unless specifically referring to Windows.
When listing development environments or tools, present cross-platform options first or equally (e.g., "Terminal or command prompt" before "Visual Studio Code" or vice versa, but clarify both are cross-platform).
Clarify that Visual Studio Code is available on all major platforms, not just Windows.
In the package management and publishing sections, provide explicit Linux/macOS command-line examples where appropriate (e.g., bash/zsh), and clarify any platform-specific differences.
When referencing the Python standard library, note that it is included in all official Python distributions, regardless of OS, to avoid implying Windows is the default.
If mentioning Windows-specific behaviors or recommendations (such as remote build), provide equivalent guidance for Linux/macOS users.
Ensure that all instructions, especially for local development and deployment, are equally clear for Linux/macOS users (e.g., mention bash/zsh shells, Homebrew, etc., if relevant).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively providing instructions and examples for managing SMB permissions and shares using Windows tools (e.g., MMC, Windows SMB client). There are no examples or guidance for Linux clients or tools, even though SMB is cross-platform and Linux clients are commonly used. The documentation assumes Windows as the primary environment for SMB management and omits Linux equivalents or alternative methods.

Recommendations:

Add instructions for managing SMB share and NTFS permissions from Linux clients, such as using smbclient, mount.cifs, or setfacl.
Include examples of mounting SMB volumes from Linux systems, referencing relevant commands and authentication methods.
When describing tools (e.g., MMC), mention Linux alternatives or clarify that similar operations can be performed from Linux with appropriate tools.
Ensure that both Windows and Linux client scenarios are covered in sections about access control, permissions, and share management.
Where possible, provide parity in screenshots and step-by-step guides for both platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in its command-line examples and tooling. All registration and feature management examples use Azure PowerShell cmdlets, with Azure CLI (cross-platform) only mentioned in passing and without explicit command examples. There are no Linux- or macOS-specific instructions or screenshots, and the workflow assumes familiarity with Windows-centric patterns (e.g., right-click context menus in the Azure Portal).

Recommendations:

Provide explicit Azure CLI command examples (e.g., 'az feature register', 'az feature show') alongside PowerShell for all registration steps, with full syntax and example output.
Include notes or sections clarifying that all Azure CLI commands work on Linux, macOS, and Windows, and provide any OS-specific prerequisites if needed.
Balance the order of presentation: list Azure CLI examples before or alongside PowerShell, not only as an afterthought.
Where UI instructions are given (e.g., 'right-click'), clarify that these actions are performed in the Azure Portal web interface, which is OS-agnostic.
Add a brief section or note for Linux/macOS users, confirming that all features are accessible via CLI and Portal, and link to relevant cross-platform setup guides.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing detailed, step-by-step instructions for setting SACLs (auditing) on SMB shares using the Windows GUI, while the equivalent Linux/NFS instructions lack step-by-step guidance and instead refer users to a separate document. Windows tools and patterns (such as right-clicking in Windows Explorer) are described explicitly, whereas Linux/UNIX methods are not. Additionally, the Windows method is presented first, reinforcing the bias.

Recommendations:

Provide step-by-step instructions for setting Audit ACEs on NFSv4.1 exports from a Linux client, including example commands (e.g., using nfs4_setfacl or setfacl).
Ensure that Linux/NFS instructions are as detailed and accessible as the Windows/SMB instructions, possibly using side-by-side tabs or sections.
Avoid always presenting Windows instructions first; alternate the order or present both equally.
Include command-line examples for both Windows (e.g., PowerShell) and Linux (e.g., Bash) where applicable.
Reference Linux-native tools and workflows explicitly, not just by linking to other documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias in several areas. In the '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 shell scripting or specific Linux tooling. The order of tools often places PowerShell before or alongside CLI, and there are no explicit Linux/Unix shell examples or references. Additionally, scripting examples reference a Microsoft blog post about SQL Server and T-SQL, which are Windows-centric technologies, without providing Linux/NFS-focused examples. There is no mention of Linux-native management patterns, and the documentation does not provide parity for Linux administrators.

Recommendations:

Provide explicit Linux shell (bash) examples for snapshot management using Azure CLI, demonstrating commands in a Linux terminal context.
Include references to Linux/Unix scripting and automation patterns (e.g., bash scripts, cron jobs) for automating snapshot operations.
Ensure that tool lists do not always place PowerShell before CLI or REST API; consider listing CLI and REST API first, as they are cross-platform.
Add examples or references for managing NFS volumes and snapshots from Linux clients, including mounting and accessing .snapshot directories.
Reference Linux-native backup and restore workflows, especially for NFS volumes, and provide guidance for Linux administrators.
Balance scripting examples by including both PowerShell and bash script samples where scripting is discussed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation for Azure NetApp Files demonstrates a mild Windows bias. Features and enhancements related to Windows technologies (such as SMB, Active Directory, and Windows File Explorer) are frequently mentioned, sometimes with more detail or prominence than their Linux/NFS counterparts. Several features are described primarily in the context of Windows clients or tools, and some security or access features are explained with reference to Windows behaviors. While Linux/NFS support is present and discussed, there are areas where Linux-specific examples, tools, or workflows are less emphasized or missing.

Recommendations:

Ensure that for every Windows/SMB example or feature description, an equivalent Linux/NFS example or workflow is provided, including command-line examples where appropriate.
When describing features like Access-based Enumeration or non-browsable shares, include explicit details on how these behave or can be managed from Linux/NFS clients, not just Windows clients.
Avoid language that frames Windows tools or behaviors as the default (e.g., 'Windows client hides the folder'), and instead present both Windows and Linux behaviors in parallel.
For troubleshooting and management tools, mention or provide Linux-native tools and commands alongside Windows/Powershell tools.
Review the order of protocol mentions (e.g., 'SMB and NFS' vs. 'NFS and SMB') to ensure Linux/NFS is not consistently listed after Windows/SMB.
Where features are described as being for 'Windows File Explorer', also mention the equivalent experience for Linux file managers or CLI tools.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell as the tool for restoring encrypted VMs, and by only linking to Windows-specific encryption documentation. There are no Linux-specific examples, tools, or references provided for VM restore scenarios, especially for encrypted VMs. The documentation also lists Windows scenarios and tools before (or instead of) Linux equivalents, and omits Linux-specific guidance in key restore workflows.

Recommendations:

Add explicit Linux restore examples, especially for encrypted VMs, including references to Linux disk encryption and restore workflows.
Include links to Linux VM encryption documentation (e.g., Azure Disk Encryption for Linux) alongside Windows links.
Provide CLI or Bash-based restore instructions in addition to PowerShell, ensuring parity for Linux administrators.
Where PowerShell is referenced, clarify if/when Azure CLI or other cross-platform tools can be used, and provide those examples.
Review restore scenarios to ensure Linux-specific considerations (such as file system types, mount instructions, or agent requirements) are addressed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page exhibits a Windows bias in several ways: Windows and PowerShell are mentioned or linked first and more frequently than Linux equivalents, especially in examples and guidance for restoring VMs with special configurations. There are multiple references to Windows-specific tools (e.g., PowerShell, bcdedit, netdom), and links to Windows documentation, while Linux-specific instructions are sparse or absent. Where Linux is mentioned, it is often as a note or afterthought, and there are no concrete Linux command examples or links to Linux VM restore scenarios.

Recommendations:

Provide Linux-specific examples and guidance alongside Windows instructions, especially for restoring VMs, handling network configurations, and post-restore steps.
Include links to Linux VM documentation (e.g., restoring Ubuntu/CentOS VMs, using cloud-init, troubleshooting Linux VM restore issues).
Offer equivalent CLI or shell (bash/az CLI) commands for all PowerShell and Windows command-line examples.
Avoid mentioning Windows tools or patterns (e.g., PowerShell, bcdedit, netdom) exclusively; when referenced, provide Linux alternatives (e.g., grub, systemctl, SSH troubleshooting).
Ensure that references to documentation for special VM types (e.g., SQL VMs, domain controllers) include Linux-based options where applicable (e.g., restoring Linux SQL VMs).
Balance the order of presentation so that Linux and Windows are treated equally (e.g., do not always mention Windows first or exclusively in lists or tables).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell/CLI scripts for permissions without specifying or providing Linux shell examples, and by focusing on Azure Portal workflows (which are often more familiar to Windows users). There is no explicit mention of Linux-specific commands, tools, or workflows, despite SAP HANA's common deployment on Linux. The documentation does not provide parity for Linux administrators, omitting bash or Linux CLI examples and not clarifying cross-platform steps.

Recommendations:

Include explicit Linux shell (bash) command examples for all steps where PowerShell or CLI scripts are referenced.
Clarify that the instructions apply to both Windows and Linux VMs, or specify any OS-specific differences.
Provide Linux-native workflow screenshots and terminal commands, especially for mounting disks and managing permissions.
When referencing 'PowerShell or CLI script', specify and provide both PowerShell (for Windows) and Bash/Azure CLI (for Linux) equivalents.
Add a section or callout for Linux administrators, highlighting any nuances or best practices for SAP HANA on Linux VMs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation page demonstrates a mild Windows bias by consistently listing Azure PowerShell (a Windows-centric tool) before Azure CLI in configuration tables, and by providing more detailed PowerShell references. There are no explicit Linux-specific examples or mentions of Linux tools, and the documentation assumes familiarity with Windows patterns (e.g., PowerShell cmdlets). However, Azure CLI (which is cross-platform) is also included, and SSH (a Linux-native protocol) is referenced, but without Linux-specific guidance.

Recommendations:

Alternate the order of Azure PowerShell and Azure CLI in tables and examples, or list Azure CLI first in some sections to avoid implicit prioritization of Windows tools.
Add explicit Linux-focused examples or notes, such as using Bash scripts or Linux shell commands for configuration.
Include references to Linux-native tools or workflows where appropriate (e.g., using SSH from a Linux terminal).
Clarify that Azure CLI is cross-platform and provide sample commands run from both Windows and Linux environments.
Where PowerShell is referenced, consider also referencing Azure Cloud Shell (which supports Bash and PowerShell) to highlight cross-platform options.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides detailed instructions and code samples for performing tasks using Azure PowerShell, but does not include equivalent examples for Linux/Unix command-line tools (such as Azure CLI or Bash). The only automation example is PowerShell, which is primarily a Windows tool, and there is no mention of cross-platform alternatives. This may disadvantage Linux/macOS users or those who prefer command-line interfaces other than PowerShell.

Recommendations:

Add Azure CLI examples alongside PowerShell for all automation steps, as Azure CLI is cross-platform and widely used on Linux/macOS.
Explicitly mention that PowerShell Core is available cross-platform, if PowerShell is to be retained, and provide installation links for non-Windows users.
Where possible, provide Bash script equivalents or reference how to perform the same actions using REST APIs or SDKs.
Ensure that the order of presentation does not prioritize Windows/PowerShell over cross-platform tools; consider presenting Azure CLI first or in parallel.
Clarify in the prerequisites or relevant sections that all steps can be performed from any OS using the Azure portal or Azure CLI.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation is heavily biased towards Windows and PowerShell environments. All scripting examples are provided exclusively in PowerShell (.ps1), and users are instructed to use PowerShell in Azure Cloud Shell, with no mention of Bash or cross-platform alternatives. The instructions and screenshots prioritize PowerShell selection, and there are no Linux shell (Bash) script examples or guidance for non-Windows users. The use of .ps1 files and PowerShell-specific cmdlets further reinforces this bias.

Recommendations:

Provide equivalent Bash (or cross-platform) script examples for Linux/macOS users.
Include instructions for running the migration script in Bash within Azure Cloud Shell, or clarify if it is not possible.
Mention and demonstrate how to use Azure CLI (az) commands where possible, as these are cross-platform.
Add notes or sections specifically addressing Linux/macOS users, including any prerequisites or differences in workflow.
If PowerShell is required, clarify that PowerShell Core is available on Linux/macOS and provide installation instructions or references.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing the Azure portal (a web GUI) and does not provide any command-line examples, such as Azure CLI or scripting, which are commonly used in Linux or cross-platform environments. All instructions and validation steps are centered around the Azure portal, with no mention of alternative tools or methods (e.g., Azure CLI, Bash, or REST API) that are platform-agnostic. There are also references to PowerShell scripts and tools (such as in the export jobs section), but no equivalent Bash or Linux-native tooling is mentioned. This approach assumes users are comfortable with or prefer GUI and Windows-centric workflows, potentially excluding Linux-first or automation-focused users.

Recommendations:

Provide equivalent Azure CLI and/or REST API instructions for all major actions (e.g., starting migration, validating billing account setup, managing roles), alongside portal-based steps.
Include Bash and cross-platform scripting examples where PowerShell or Windows tools are referenced, especially for automation tasks like export jobs.
Explicitly mention that all steps can be performed from Linux, macOS, or Windows, and link to relevant cross-platform tool documentation.
Where screenshots or instructions are GUI-only, add notes or links to command-line alternatives for users who prefer or require automation.
Review references to PowerShell or Windows-specific tools and ensure Linux-native or cross-platform alternatives are documented and equally discoverable.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Microsoft-centric tools and portals (such as Azure portal, Microsoft Admin Center, Microsoft 365 admin center, Power BI, and Microsoft Entra) without mentioning or providing parity for Linux or cross-platform alternatives. There are no command-line examples (Windows or Linux), but where automation or scripting is referenced (e.g., 'PowerShell scripts', 'Azure Commerce Toolbox'), only Windows-native tooling is mentioned. All video and walkthrough examples are based on the Azure portal or Microsoft admin interfaces, which are web-based but often assume a Windows-centric workflow. There is no mention of Linux CLI, Azure CLI, or cross-platform automation approaches, and no Linux-specific guidance or examples are provided.

Recommendations:

Include references to Azure CLI (which is cross-platform) alongside or instead of PowerShell and Windows-specific tools when discussing automation, scripting, or API usage.
Provide explicit examples or links for managing billing, subscriptions, and automation tasks using Linux/macOS environments, such as bash scripts or Azure CLI commands.
When mentioning tools like Power BI or Microsoft Admin Center, clarify their platform compatibility and suggest alternatives or access methods for Linux users if available.
Ensure that any references to scripting or automation (such as recreating export jobs) include both PowerShell and bash/Azure CLI examples.
Review all video and tutorial links to ensure at least some demonstrate cross-platform or Linux-compatible workflows, or add notes about how Linux users can accomplish the same tasks.
Where possible, avoid assuming the user is operating from a Windows environment; use neutral, cross-platform language and tool recommendations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell for command-line management of reservations, without mentioning or providing examples for cross-platform tools such as Azure CLI or REST API. The 'Grant access with PowerShell' section and related links only discuss PowerShell, which is traditionally associated with Windows environments, and there are no Linux- or macOS-specific instructions or examples. This may hinder Linux users or those preferring cross-platform tooling.

Recommendations:

Add equivalent Azure CLI examples and instructions alongside PowerShell for all command-line operations, especially in the 'Grant access' and management sections.
Explicitly mention that Azure CLI is cross-platform and provide links to relevant CLI documentation.
Where PowerShell is referenced, clarify that Azure PowerShell is available cross-platform, but also offer CLI and REST API alternatives.
Include a table or section comparing PowerShell, Azure CLI, and REST API approaches for managing reservation permissions.
Ensure that all code snippets and walkthroughs are available for both PowerShell and Azure CLI to support users on Linux, macOS, and Windows equally.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively providing PowerShell scripts for programmatic discovery of impacted objects, with no mention of Linux or cross-platform alternatives (such as Bash, Azure CLI, or Python). The guidance assumes the use of Windows tools and patterns, and does not address how Linux or macOS users can achieve the same tasks. There are no Linux-specific instructions or examples, and the only automation guidance is via PowerShell, which is traditionally associated with Windows environments.

Recommendations:

Provide equivalent examples using Azure CLI, Bash scripts, or Python for programmatic discovery of impacted objects, ensuring Linux and macOS users are supported.
Explicitly mention whether the provided PowerShell scripts are compatible with PowerShell Core on Linux/macOS, and provide installation guidance if so.
Add a section or note addressing cross-platform usage, including any prerequisites or differences for Linux users.
Where possible, offer downloadable scripts or command snippets in both PowerShell and Bash/Azure CLI formats.
Review all automation and scripting guidance to ensure parity for users on non-Windows platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing PowerShell scripts and WinGet (both Windows-specific tools) as the primary and recommended methods for Dev Box customizations. There are no examples or mentions of Linux shell scripting, Linux package managers, or cross-platform alternatives. The language and examples assume a Windows environment, and Linux or macOS scenarios are not addressed.

Recommendations:

Include examples of using Bash scripts or other Linux shell scripts as customization tasks, if supported by Dev Box.
Document support (or lack thereof) for Linux-based Dev Boxes, and clarify whether customizations can be applied to non-Windows environments.
If Dev Box supports Linux images, provide equivalent instructions for using Linux-native tools (e.g., apt, yum, zypper) in customization tasks.
Mention cross-platform scripting options (such as Python or Node.js scripts) if applicable.
Explicitly state platform limitations and provide guidance for users who require Linux or macOS development environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by focusing exclusively on Windows-specific tools (such as WinGet and PowerShell), referencing Windows configuration patterns, and omitting any mention of Linux or cross-platform alternatives. All examples and workflows assume a Windows environment, with no guidance for Linux users or parity in tooling.

Recommendations:

Include examples of customization files and tasks that are relevant for Linux-based dev boxes, if supported.
Mention and provide guidance for Linux package managers (e.g., apt, yum) or scripting (e.g., Bash) where appropriate, alongside or instead of WinGet and PowerShell.
Clarify whether user customizations are supported on non-Windows dev boxes, and if not, state this explicitly.
If the Dev Box service is Windows-only, add a note at the top of the documentation to set user expectations.
Provide parity in documentation structure: for every Windows-specific example or tool, offer a Linux equivalent or explain the limitations.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page references Azure PowerShell as a configuration method and does not mention or provide examples for Linux-native tools (such as Azure CLI or Bash scripting). The 'Next steps' section lists Azure PowerShell before any other automation or scripting options, and there are no Linux-specific instructions or parity in examples. This may create the impression that Windows or PowerShell is the primary or preferred environment for managing ExpressRoute FastPath, potentially disadvantaging Linux users.

Recommendations:

Add explicit instructions and examples for configuring ExpressRoute FastPath using Azure CLI (az), which is cross-platform and commonly used on Linux.
Ensure that both Azure PowerShell and Azure CLI guides are referenced equally in the 'Next steps' section, ideally listing CLI first or side-by-side.
Wherever PowerShell commands are mentioned, provide equivalent Bash/Azure CLI commands.
Include notes clarifying that all features are accessible from both Windows and Linux environments.
Review linked configuration guides to ensure Linux parity and update them if necessary.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing only Azure PowerShell examples for gateway subnet creation, with no equivalent Azure CLI (cross-platform) or ARM template examples. The technical resources section lists only PowerShell and REST API links, omitting Azure CLI references. This focus on PowerShell and lack of Linux/cross-platform examples may hinder users on non-Windows platforms.

Recommendations:

Add Azure CLI examples alongside PowerShell for all code snippets, especially for gateway subnet creation.
Include references and links to Azure CLI documentation in the technical resources section.
Where possible, provide ARM/Bicep template examples for infrastructure-as-code parity.
Review the documentation for other areas where only PowerShell is mentioned and ensure CLI parity.
Explicitly state that both PowerShell and CLI are supported, and clarify any platform-specific requirements.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page shows a moderate Windows bias. PowerShell is mentioned as a primary automation/configuration tool, and some configuration guides and links reference PowerShell cmdlets or scripts before (or instead of) equivalent Azure CLI or Linux-native instructions. There are no explicit Linux or cross-platform command examples, and the documentation assumes familiarity with Windows-centric tools and patterns.

Recommendations:

Provide Azure CLI examples alongside or before PowerShell examples for all configuration and management tasks.
Explicitly mention Linux/macOS compatibility for all command-line instructions and tools.
Link to both PowerShell and Azure CLI documentation where relevant, ensuring parity in guidance.
Include examples or references for Linux-based automation (e.g., Bash scripts) where appropriate.
Avoid assuming the use of Windows-only tools or environments; clarify when steps are cross-platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides instructions for the Azure portal, Azure CLI, and Azure PowerShell. While Azure CLI is cross-platform, there is a notable emphasis on PowerShell (a Windows-centric tool) throughout the guide. In several places, PowerShell examples and instructions are given prominence, sometimes being referenced as the preferred or only method for certain steps (e.g., creating the virtual network gateway in the portal section refers users to PowerShell). There are no explicit Linux-specific shell examples (e.g., Bash), and PowerShell is treated as a primary automation tool, which may disadvantage Linux users unfamiliar with it.

Recommendations:

Wherever PowerShell is referenced as the only or preferred automation method, ensure equivalent Azure CLI (Bash-friendly) instructions are provided and clearly marked as cross-platform.
Avoid language such as 'use the PowerShell instructions' in portal sections; instead, offer both CLI and PowerShell alternatives, or clarify that CLI is cross-platform.
Add explicit Bash shell examples where possible, especially for scripting scenarios, to improve accessibility for Linux users.
In summary tables or step lists, avoid listing PowerShell before CLI, or alternate the order to avoid implicit prioritization.
Clarify in the prerequisites and tool installation sections that Azure CLI is fully supported on Linux and macOS, and provide links or notes for Linux users.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation focuses exclusively on assessing ASP.NET web apps, which are traditionally Windows-centric, and does not mention Linux-based .NET web apps or provide Linux-specific assessment guidance or examples. All referenced tools and linked resources implicitly target Windows environments, with no mention of Linux compatibility or alternatives.

Recommendations:

Explicitly mention whether the assessment process and tools support both Windows and Linux-based .NET web apps.
Include examples or guidance for assessing .NET web apps hosted on Linux, if supported.
Reference Linux-compatible tools or provide parity in instructions for Linux environments.
Clarify any limitations or differences in assessment for Linux-hosted .NET apps versus Windows-hosted ones.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) before mentioning the Linux equivalent, and by providing a concrete example path only for Windows in the main instructions. The Linux path is only mentioned later in a note, and no Linux-specific example or command is provided. There are no Linux shell or tooling examples, and the documentation assumes familiarity with Windows file paths.

Recommendations:

Present both Windows and Linux file paths together in all relevant instructions and examples, e.g., 'C:\home\site\wwwroot\auth.json' (Windows) and '/home/site/wwwroot/auth.json' (Linux).
Include explicit Linux examples or commands where file paths or environment specifics are discussed.
Avoid assuming Windows as the default by rephrasing instructions to be platform-neutral, or by listing Linux first in some cases.
Where platform differences exist (such as path formats), provide clear, parallel examples for both Windows and Linux.
Consider adding a table or section summarizing key differences between Windows and Linux deployments for this feature.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation focuses exclusively on configuring GitHub authentication via the Azure Portal UI, which is a platform-agnostic web interface. However, it omits any command-line instructions or automation examples. There is an implicit bias in that, for Azure documentation, CLI or scripting examples (such as Azure CLI, PowerShell, or Bash) are often provided, but here, no such examples are given. This can disadvantage Linux users who prefer or require CLI-based workflows, especially since Azure documentation often defaults to PowerShell or Windows tools when examples are given.

Recommendations:

Add Azure CLI examples for configuring GitHub authentication, including commands to set up identity providers and manage secrets.
Include Bash shell examples for Linux users, especially for automation scenarios.
If PowerShell examples are added in the future, ensure that equivalent Bash/Azure CLI examples are provided and presented with equal prominence.
Explicitly mention that all steps can be performed from any OS via the Azure Portal, but highlight CLI options for users who prefer non-GUI workflows.

Create pull request

Bias Types:

⚠️ linux_first

⚠️ missing_windows_example

Summary:

The documentation page demonstrates a Linux-first bias in the sections related to Java key store and certificate management. Detailed instructions, file paths, and troubleshooting steps are provided only for Linux-based App Service environments, with no equivalent coverage for Windows-based environments. There are no PowerShell or Windows tool examples, and Windows-specific patterns are not mentioned, which may leave Windows users without sufficient guidance.

Recommendations:

Add a section detailing how Java key stores and certificates are managed on Windows-based App Service environments, including default file locations and any differences in behavior.
Provide examples of how to interact with the Java key store on Windows, such as using Command Prompt or PowerShell, and specify any relevant differences in environment variables or file paths.
Include troubleshooting steps and manual certificate loading instructions for Windows, similar to the Linux guidance.
Ensure parity in documentation by explicitly stating when a feature or behavior is Linux-only, and provide alternatives or workarounds for Windows users where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias. In the prerequisites and quickstart links, 'windows' is listed as a tab before Linux, and there are no explicit Linux or cross-platform command-line examples. The instructions for environment variable setup and deployment reference the Azure portal and App Service, which are platform-agnostic, but there are no examples or guidance for Linux-specific workflows or tools (e.g., bash scripts, Linux file paths, or Linux deployment methods). The only shell command shown is 'pip install', which is cross-platform, but there is no mention of Linux-specific nuances or alternative approaches.

Recommendations:

Ensure that all quickstart and sample links include Linux tabs or examples, and mention them alongside or before Windows.
Add explicit Linux command-line examples where relevant, such as using bash to set environment variables or deploy the app.
Include Linux file path examples and clarify any differences in file handling or permissions.
Reference Linux deployment methods (e.g., using Azure CLI on Linux, deploying from a Linux workstation) in addition to portal-based instructions.
If mentioning Visual Studio or Windows-specific tools, also mention VS Code and cross-platform alternatives.
Review all code and instructions to ensure they are tested and work identically on Linux environments.

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 instructions and deployment steps are shown using .NET CLI and Azure Developer CLI without explicit mention of Linux or Mac environments. There are no examples or notes for Linux-specific workflows, such as using a local Linux terminal, package managers, or alternative editors. The documentation also references Visual Studio Code features (like 'Open in Browser') that may behave differently on Windows versus Linux/Mac, but does not clarify or provide alternatives.

Recommendations:

Explicitly state that all CLI commands work on Linux, Mac, and Windows, and provide any necessary prerequisites for Linux (e.g., installing .NET SDK, Azure CLI).
Include notes or examples for running the sample app and deploying from a local Linux or Mac terminal, not just from Codespaces.
Clarify how to open the app in a browser from the terminal on Linux/Mac (e.g., using 'xdg-open' or 'open' commands) in addition to the Codespaces/VS Code UI.
Mention any differences in environment variables or file paths that may affect Linux users.
If referencing Azure App Service, note that it runs on both Windows and Linux, and clarify any differences in deployment or runtime behavior.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates environment-based configuration using ASP.NET Core and Azure App Configuration, but it assumes usage patterns and tooling common to Windows development. It references modifying launchSettings.json (a Visual Studio/Windows-centric file) and does not mention or provide examples for Linux or cross-platform environment variable management. There are no instructions for setting environment variables or running the app in Linux shells, nor any mention of Linux development workflows.

Recommendations:

Include instructions or examples for setting environment variables in Linux/macOS shells (e.g., using 'export ASPNETCORE_ENVIRONMENT=Production' in bash/zsh).
Mention alternative ways to configure environment variables outside of launchSettings.json, such as through shell commands or CI/CD pipelines.
Clarify that the steps apply to both Windows and Linux, and provide parallel examples for Linux users.
Reference cross-platform editors and tools, not just Visual Studio/Windows-specific files.
Add a note or section on running and testing the app in Linux environments, including relevant commands.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation exhibits a mild Windows bias by linking to Windows-specific documentation for creating proximity placement groups (PPGs) and by referencing Windows paths in URLs before any mention of Linux equivalents. There are no explicit Linux or cross-platform examples or instructions, and the only direct example for PPG creation points to a Windows-centric guide.

Recommendations:

Provide links to both Windows and Linux (or cross-platform) documentation for creating and managing proximity placement groups (PPGs). For example, include a link to the Azure CLI or Azure Portal documentation that is not Windows-specific.
When referencing Azure documentation, avoid using Windows-specific paths (such as /azure/virtual-machines/windows/proximity-placement-groups-portal) as the only example. Instead, offer both Windows and Linux (or generic) alternatives, or use the most general documentation available.
Explicitly mention that the procedures and requirements apply equally to both Windows and Linux SAP HANA deployments, unless there are platform-specific differences.
If any command-line examples or scripts are added in the future, ensure parity by providing both PowerShell and Bash/Azure CLI examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation is organized with a clear separation between Linux and Windows solutions, but Windows workloads and tools are often presented first or with greater detail in some sections. Windows-specific technologies (such as DFS Namespaces, FSLogix, SMB, and Windows Virtual Desktop) are highlighted, and some solution areas (like Virtual Desktop Infrastructure) focus almost exclusively on Windows scenarios. However, Linux solutions are also well-represented, especially for SAP, HPC, and OSS workloads.

Recommendations:

Ensure Linux and Windows solution sections are given equal prominence and detail, including in introductory summaries and diagrams.
Where Windows tools (e.g., DFS Namespaces, FSLogix, SMB) are mentioned, provide equivalent Linux/NFS or open-source alternatives and reference their documentation.
For Virtual Desktop Infrastructure, include references to Linux-based VDI solutions or clarify if only Windows is supported.
In sections where Windows examples or tools are discussed (such as SAP NetWeaver with Windows DFS-N), add parallel Linux/NFS guidance if available.
Review the order of presentation in mixed-OS sections to avoid consistently listing Windows first, which can imply priority.
Where possible, add practical Linux command-line or configuration examples alongside Windows/Powershell ones, especially in technical guides linked from this page.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation page demonstrates a moderate Windows bias by providing an Azure PowerShell example first and in detail for feature registration, with only a brief mention of the Azure CLI alternative. There are no Linux-specific examples or explicit parity in command-line instructions, and the documentation assumes familiarity with PowerShell. However, the page does reference Linux in the context of performance benchmarks, and does not mention Windows-exclusive tools or patterns elsewhere.

Recommendations:

Provide both Azure PowerShell and Azure CLI examples side-by-side for feature registration and status checking, with equal prominence and explanation.
Include explicit Linux command-line instructions (e.g., bash/CLI) where relevant, not just references.
Avoid assuming PowerShell as the default; clarify that both Windows and Linux users are supported.
Where possible, add links or examples for managing large volumes from Linux environments (e.g., using Azure CLI in bash).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page primarily describes known issues and their workarounds for Azure VMware Solution, with very few command-line or tooling examples. However, in the two instances where a remediation command is mentioned (for VMware Tools vulnerabilities), only the Azure VMware Solution Run command Set-Tools-Repo is referenced, with no mention of Linux/Unix alternatives or cross-platform guidance. Additionally, one vulnerability is specifically described as 'VMware Tools for Windows,' but there is no mention of Linux guest tools or their update/remediation process. There are no explicit PowerShell or Windows command examples, but the lack of Linux parity in these cases indicates a subtle Windows bias.

Recommendations:

When referencing remediation steps for VMware Tools, include guidance for both Windows and Linux guest operating systems, or clarify if the process is identical for both.
If the Set-Tools-Repo command applies to all guest OS types, explicitly state this. If not, provide equivalent instructions for Linux guests (e.g., how to update open-vm-tools or VMware Tools on Linux).
For any guest OS-specific vulnerabilities (e.g., 'VMware Tools for Windows'), add a note about the status or remediation for Linux guests.
Review future documentation to ensure that any command-line or tooling instructions are provided for both Windows and Linux environments, or that cross-platform applicability is clearly stated.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for retrieving the service principal ID, but the PowerShell example is given after the CLI example. There are no explicit Linux-specific instructions or examples, but the use of Azure CLI (which is cross-platform) mitigates this. However, the presence of Azure PowerShell (traditionally associated with Windows) and the lack of explicit mention of Linux or bash scripting may suggest a mild Windows-first and PowerShell-heavy bias.

Recommendations:

Explicitly state that Azure CLI commands work on Windows, Linux, and macOS to reinforce cross-platform support.
Add bash shell examples where relevant, especially for REST API calls (e.g., using curl or httpie) to demonstrate Linux parity.
Clarify that Azure PowerShell is available cross-platform, but also provide equivalent bash or shell scripting examples for Linux users.
Consider including a table or section summarizing command options for Windows (PowerShell), Linux (bash), and macOS users.
Where portal instructions are given, note any OS-agnostic aspects to further reduce perceived bias.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page presents .NET/.NET Core (Microsoft technologies, typically associated with Windows) provider libraries and examples first in all lists and tables, before Java, Python, JavaScript, and Go equivalents. There are no explicit Linux or cross-platform command-line examples, but the ordering implicitly prioritizes Windows-centric technologies.

Recommendations:

Reorder the provider libraries table to rotate or randomize the order, or group by language family (e.g., statically typed, dynamically typed) rather than always listing .NET/.NET Core first.
Explicitly mention the cross-platform nature of the provider libraries, especially for .NET Core, Java, Python, JavaScript, and Go.
Add a section or note clarifying that all listed libraries are supported on both Windows and Linux (where applicable), and provide links to platform-specific setup guides if differences exist.
Ensure that future documentation includes Linux/Unix-specific examples or notes where relevant (e.g., environment variable setup, file paths), even if not present on this page.
Consider including a table column or icon indicating cross-platform compatibility for each provider.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page demonstrates a subtle 'windows_first' bias by listing PowerShell before Azure CLI when mentioning tools for creating a resource group. No explicit Linux or Bash examples are provided, but both PowerShell and Azure CLI are mentioned. No exclusive use of Windows tools or missing Linux examples are present, but the ordering may suggest a preference for Windows-centric tooling.

Recommendations:

When listing tools or methods, alternate the order (e.g., mention Azure CLI before PowerShell in some places) or list them alphabetically to avoid perceived preference.
Where possible, provide explicit examples for both PowerShell and Azure CLI (or Bash) to ensure parity.
Consider including a brief note that Azure CLI is cross-platform and works on Linux, macOS, and Windows.
Audit other documentation pages for similar ordering or example disparities to ensure consistent cross-platform inclusivity.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation does not display overt Windows bias in terms of tools, patterns, or terminology. However, it lacks any command-line or shell examples (such as Bash or PowerShell) and only provides SDK code samples in C# and JavaScript. There are no Linux-specific instructions, CLI walkthroughs, or references to Linux environments. The provisioning and usage flows are described entirely via the Azure portal UI and SDKs, with no mention of cross-platform command-line automation or Linux developer workflows.

Recommendations:

Add CLI-based examples using Azure CLI or Bash scripts to demonstrate provisioning and sending SMS, ensuring parity for Linux and cross-platform users.
Include explicit references to Linux and macOS environments in setup and troubleshooting sections, clarifying that the SDKs and APIs are cross-platform.
Provide sample Dockerfiles or containerization tips for running Messaging Connect integrations on Linux servers.
If PowerShell or Windows-specific tools are not needed, explicitly state that all features are available and supported on Linux, macOS, and Windows.
Expand the SDK tutorial section to include Python and Java examples as soon as those SDKs are available, and clarify their cross-platform compatibility.

Create pull request

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