Scan Details - Linux-first Docs for Azure

527

Pages Scanned

40

Pages Flagged

527

Changed Pages

7.6%

% Pages Flagged

Live Progress

🔴 Connecting...

0%

Phase: discovery

Processing: Initializing...

Activity Feed

00:00:14 Scan started

Scan Information

Started At: 2025-08-26 00:00:14

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:

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by referencing Visual Studio Code (a Microsoft product, though cross-platform) and GitHub Copilot as the only suggested tools for testing the MCP server, without mentioning Linux-native alternatives or command-line approaches. All instructions are oriented around the Azure Portal GUI, which is platform-agnostic, but there is no mention of Linux-specific workflows, CLI tools, or examples. The documentation implicitly assumes a Windows-centric development environment by not providing parity for Linux users.

Recommendations:

Provide examples of testing the MCP server using cross-platform command-line tools such as curl or httpie, which are commonly used on Linux.
Mention and demonstrate the use of Azure CLI or REST API calls for managing and testing MCP servers, ensuring instructions are not limited to GUI-based workflows.
List alternative editors and tools for Linux users (e.g., Vim, Emacs, or JetBrains IDEs) when suggesting Visual Studio Code.
Explicitly state that the instructions are platform-agnostic or provide separate sections for Windows and Linux where workflows differ.
Include screenshots or terminal examples from Linux environments where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by consistently presenting Azure PowerShell instructions before Azure CLI, and by referencing PowerShell-specific cmdlets for status checks even in CLI sections. There are no explicit Linux or Bash shell examples, and the CLI output examples reference PowerShell cmdlets rather than native CLI commands. The documentation does not mention or illustrate Linux-specific tools, shell environments, or scripting approaches, which may disadvantage Linux users.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples, especially in sections likely to be used by Linux administrators.
Ensure that CLI output examples use native Azure CLI commands (e.g., 'az feature show') rather than PowerShell cmdlets, and provide sample outputs for both.
Add explicit Bash shell examples for common tasks, such as feature registration and status checks, to support Linux users.
Reference cross-platform scripting approaches (e.g., Bash, Cloud Shell) where appropriate, and clarify that both PowerShell and CLI are available in Azure Cloud Shell.
When listing tools or methods, avoid always listing PowerShell first; alternate or clarify that order does not imply preference.
Include notes or links to Linux-specific guidance or troubleshooting where relevant.

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 tasks, with no equivalent Bash or Linux shell examples. The use of 'Set-AzContext', 'Get-AzProviderFeature', and 'Register-AzProviderFeature' are PowerShell-specific and the only code blocks provided are in PowerShell syntax. There is no mention of Linux-native tools or cross-platform command-line alternatives, and the PowerShell approach is presented as the default or only method for several operations.

Recommendations:

Provide equivalent Azure CLI (az) commands in Bash syntax for all PowerShell examples, especially for migration and feature registration/unregistration.
Explicitly mention that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows.
Include links or references to Linux/macOS setup guides for Azure CLI and relevant tools.
Where PowerShell is referenced, clarify that it is available cross-platform, or provide Bash alternatives side-by-side.
Review tutorial and next steps links to ensure Linux users are equally supported (e.g., link to CLI-based tutorials, not just PowerShell).

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

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

Recommendations:

Provide equivalent Azure CLI and/or Bash examples for resource cleanup (e.g., az group delete).
Include instructions for deploying and validating with a Linux-based web server (such as Nginx or Apache) on the backend VMs.
Offer both Windows and Linux VM configuration options in the ARM template or as selectable parameters.
When referencing tools (like IIS), clarify that it is a Windows example and provide a parallel Linux example.
Ensure that all critical steps (deployment, validation, cleanup) have both Windows and Linux command-line options presented side-by-side or in tabs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a strong Windows bias. All migration tools and examples focus exclusively on migrating from Windows environments, specifically IIS servers, and make heavy use of Windows-specific tools such as the App Service Migration Assistant (MSI installer) and PowerShell scripts. There is no mention of Linux-based hosting environments, migration from Linux web servers, or equivalent Linux tooling. The documentation does not provide guidance or examples for users running .NET apps on Linux servers (e.g., Apache, Nginx, Kestrel), nor does it mention cross-platform migration scenarios.

Recommendations:

Add sections or examples for migrating .NET apps hosted on Linux servers (e.g., Apache, Nginx, Kestrel) to Azure App Service.
Include Linux-specific migration tools or manual migration steps, such as using rsync, SCP, or Azure CLI on Linux.
Provide parity in documentation by offering both Windows and Linux migration paths, including sample scripts and commands for each.
Mention and link to any available cross-platform or Linux-compatible migration tools, or clarify if such tools are not available.
Ensure that PowerShell scripts are accompanied by Bash or shell script equivalents where possible.
Explicitly state the limitations or lack of support for Linux-based migrations if that is the case, and provide guidance for manual migration.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a subtle Windows bias by referencing Windows-centric tools and configuration patterns (such as web.config and iisnode) without providing equivalent Linux-native examples or alternatives. While there is a brief mention of Linux (regarding PM2 for Node.js), most configuration and troubleshooting guidance assumes a Windows environment or omits Linux-specific instructions.

Recommendations:

For features like auto-healing, provide Linux-native configuration examples (e.g., using app settings or startup scripts) alongside web.config instructions.
When referencing iisnode or web.config, clarify their applicability to Windows-based App Service plans and provide alternatives for Linux-based plans (such as using process managers like PM2 or configuring environment variables).
Include explicit Linux examples for diagnostics, scaling, and backup configuration, ensuring parity with Windows instructions.
When mentioning tools or configuration files (like web.config), always note their platform specificity and link to Linux equivalents or documentation.
Review all troubleshooting and best practice sections to ensure that both Windows and Linux workflows are equally represented and easy to follow.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a moderate Windows bias. In sections where both Windows and Linux are relevant (such as SKU availability), the Windows example is presented first, and the Linux example is secondary. The automation section provides both Azure CLI (cross-platform) and Azure PowerShell (Windows-centric) examples, but does not mention Linux-native scripting tools or workflows. The portal instructions and screenshots do not clarify any differences for Linux users, and the 'Development tools' section references features (like 'Clone app') without noting platform-specific considerations.

Recommendations:

Alternate the order of Windows and Linux examples, or present them side-by-side to avoid 'windows_first' bias.
Explicitly mention that Azure CLI is cross-platform and suitable for both Windows and Linux users.
If providing PowerShell examples, consider also providing Bash or shell script equivalents for Linux users.
Clarify in portal instructions and screenshots whether the experience is identical for Linux and Windows App Service plans, or note any differences.
In the 'Automate with scripts' section, add a Bash script example for Linux users, especially for tasks like redeployment or automation.
Review tool recommendations to ensure Linux-native tools and workflows are equally represented and explained.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a moderate Windows bias. Windows terminology and tools (such as PowerShell) are mentioned prominently and often before their Linux equivalents. The 'Automate with scripts' section provides both Azure CLI and PowerShell examples, but PowerShell is a Windows-centric tool. There are no explicit Linux shell (bash) or scripting examples, and the documentation does not mention Linux-native tools or patterns. In the availability section, Windows SKU availability is listed before Linux, and the overall tone and examples lean towards Windows-first usage.

Recommendations:

Provide bash shell scripting examples alongside PowerShell for automation, especially in the 'Automate with scripts' section.
When listing availability or features, present Linux and Windows options in parallel or alternate the order to avoid Windows-first bias.
Mention Linux-native tools or scripting environments (e.g., bash, sh) where automation is discussed.
Clarify in the prerequisites and automation sections that all CLI commands work cross-platform, and explicitly state any differences or requirements for Linux users.
Include screenshots or walkthroughs from both Windows and Linux perspectives where applicable, especially for command-line operations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions, tools, and troubleshooting steps are often presented first or exclusively, with more detailed guidance and GUI options for Windows users. Linux support is present but less emphasized, with some features (like the GUI) unavailable and some troubleshooting steps (e.g., PowerShell commands) lacking Linux equivalents.

Recommendations:

Provide Linux examples alongside Windows ones, especially in troubleshooting sections (e.g., suggest 'nc' or 'telnet' as alternatives to 'Test-NetConnection' in PowerShell).
Avoid presenting Windows instructions or tools first by default; use parallel tabbed instructions for both platforms wherever possible.
Where a feature is Windows-only (e.g., GUI), clearly state this early and offer equivalent CLI workflows for Linux, with equal detail and screenshots.
In troubleshooting, include Linux-native commands for network testing (e.g., 'nslookup', 'dig', 'nc', 'curl') and explain how to interpret their results.
Balance the use of screenshots and step-by-step guides for both Windows and Linux, ensuring Linux users have visual aids and detailed instructions.
When referencing tools or commands, avoid assuming PowerShell is available; always provide a Linux alternative.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell scripts as the only example for scripting/automation tasks (such as identifying Traffic Manager endpoints), referencing PowerShell before or instead of cross-platform alternatives, and omitting equivalent Bash or Linux shell examples. There is no mention of Linux/macOS-compatible scripting or tooling for users who do not use Windows or PowerShell.

Recommendations:

Provide Bash/Azure CLI script examples alongside PowerShell scripts for all automation and resource identification tasks.
Explicitly mention that PowerShell scripts can be run cross-platform using PowerShell Core, or provide alternative instructions for Linux/macOS users.
When referencing scripts or tools, avoid assuming the user is on Windows; instead, present both Windows and Linux options, or clarify cross-platform compatibility.
For each scenario where a PowerShell script is linked or described, add a corresponding Bash/Azure CLI example or link to a GitHub repository with cross-platform scripts.
Instruct users on how to use Azure CLI (which is cross-platform) for resource queries and management, not just PowerShell.
Review all step-by-step instructions to ensure they are not Windows-centric and that Linux users are equally supported.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page exclusively discusses discovery of ASP.NET web apps hosted on IIS servers within VMware environments, which are Windows-centric technologies. There are no references to Linux-based web servers (such as Apache or Nginx), nor are there any examples or guidance for discovering .NET apps hosted on Linux. All tools and processes described (e.g., Azure Migrate appliance, IIS) are Windows-specific, and Linux scenarios are entirely omitted.

Recommendations:

Include information about discovering .NET web apps hosted on Linux servers, such as those running on Apache, Nginx, or Kestrel.
Provide equivalent discovery guidance and tooling for Linux environments, or clearly state any current limitations.
Add examples or documentation links for Linux-based .NET app discovery and migration.
Ensure that references to tools and processes are inclusive of both Windows and Linux hosting scenarios, or explicitly clarify the scope.

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 using iisnode. All configuration and troubleshooting steps are tailored to Windows, with exclusive references to Windows-specific tools (e.g., iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell). There are no examples or guidance for Linux-based App Service or cross-platform scenarios, and Linux equivalents (such as PM2, systemd, or nginx) are not mentioned.

Recommendations:

Add equivalent guidance and examples for Node.js applications running on Azure App Service Linux, including configuration, troubleshooting, and monitoring steps.
Include Linux-specific tools and patterns (e.g., PM2, systemd, nginx, environment variables) alongside or before Windows/iisnode examples.
Provide cross-platform troubleshooting steps and clarify which instructions apply only to Windows.
Offer PowerShell and Bash (or shell) command examples side-by-side where relevant.
Reference Linux log file locations and diagnostic tools (e.g., /var/log, journalctl) in troubleshooting sections.
Link to Linux-focused documentation or external resources for parity.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by exclusively referencing Azure Storage Explorer (a GUI tool with a primary focus on Windows) for uploading files and generating SAS tokens, and by linking to Storage Explorer instructions with a Windows-specific tab in the URL. There are no examples or instructions for performing these tasks using Linux-native tools (such as the Azure CLI, azcopy, or command-line methods). The rest of the guide uses Azure CLI, which is cross-platform, but the initial steps and tooling references favor Windows users.

Recommendations:

Provide equivalent instructions for uploading files and generating SAS tokens using Azure CLI and/or azcopy, which are cross-platform and work on Linux, macOS, and Windows.
Avoid linking to Storage Explorer documentation with a Windows-specific tab in the URL, or provide links/tabs for Linux and macOS as well.
Explicitly mention that Storage Explorer is available on multiple platforms, and provide download links for all supported OSes.
Where GUI tools are referenced, also provide command-line alternatives for Linux users.
Add a section or callout for Linux/macOS users to ensure parity in the onboarding and setup experience.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page demonstrates a Windows bias by focusing exclusively on Windows-based deployment and configuration patterns for ASP.NET apps. All runtime version discovery commands use Windows file paths and Kudu's CMD/PowerShell consoles, with no mention of Linux equivalents. Visual Studio (a Windows-centric tool) is assumed as the primary deployment method, and there are no examples or guidance for Linux-based App Service environments or tools. Linux or cross-platform scenarios are only mentioned in passing, with no actionable instructions.

Recommendations:

Add explicit instructions and examples for configuring ASP.NET apps on Linux-based App Service plans, including how to check installed .NET runtimes and access diagnostic tools.
Provide Linux shell (bash) equivalents for all file system and runtime inspection commands, and clarify when a command is Windows-specific.
Include deployment guidance using cross-platform tools (such as the .NET CLI and VS Code) alongside Visual Studio instructions.
Clearly indicate which instructions apply to Windows, Linux, or both, and ensure Linux guidance is not relegated to footnotes or external links.
Mention and demonstrate use of Kudu SSH/bash console for Linux App Service, not just CMD/PowerShell for Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring Tomcat data sources, but the Windows section is notably more detailed, featuring extensive PowerShell scripting and Windows-specific patterns (e.g., use of startup.cmd, %HOME% paths, and PowerShell for XML transforms). Windows tools and patterns (PowerShell, Windows environment variables) are emphasized and explained in greater depth than their Linux equivalents. The Linux instructions are present and functional, but the Windows approach is more elaborate and receives more step-by-step attention.

Recommendations:

Ensure Linux and Windows sections are equally detailed, with step-by-step Linux shell script examples matching the depth of the Windows PowerShell instructions.
Provide Linux-native alternatives for all Windows-specific tools and patterns (e.g., show how to use Bash scripts for XML transforms, not just PowerShell).
When introducing cross-platform steps, present Linux and Windows instructions in parallel, rather than giving more prominence or detail to Windows.
Where possible, use platform-agnostic tools or highlight them first, then provide OS-specific details as needed.
Expand on Linux troubleshooting, file locations, and automation patterns to match the clarity and completeness of the Windows section.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias by referencing Windows file paths (e.g., D:\home\site\wwwroot) before Linux equivalents, describing deployment behaviors primarily in terms of Windows directories, and omitting explicit Linux command-line or file path examples. There is also an assumption of Windows-style directory structures and deployment patterns, with little to no mention of Linux-specific nuances or parity in examples.

Recommendations:

Provide Linux-specific examples and file paths (e.g., /home/site/wwwroot) alongside Windows ones in all relevant sections.
Explicitly mention Linux behaviors and differences where applicable, such as directory permissions, file system case sensitivity, and deployment nuances.
Include sample commands and troubleshooting steps that are relevant to Linux environments (e.g., bash commands, Linux CLI nuances).
Ensure that all references to file paths, deployment directories, and manual steps are presented in both Windows and Linux formats.
Clarify any differences in behavior or limitations between Windows and Linux App Service plans.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows by primarily referencing Windows development tools and workflows (e.g., Visual Studio, right-click actions), and omitting explicit Linux or cross-platform instructions. Package installation is described first via Visual Studio (a Windows-centric tool), with CLI instructions only linked and not shown inline. There are no Linux-specific or cross-platform development environment examples, and no mention of Linux file managers or editors. The guidance assumes a GUI-based workflow typical of Windows, with no parity for Linux users.

Recommendations:

Provide explicit CLI-based instructions for all steps, including file creation and editing, to support Linux and cross-platform users.
Include examples using cross-platform editors (e.g., VS Code, nano, vim) and file system navigation commands (e.g., mkdir, touch, cp).
Present package installation instructions for both Visual Studio (Windows) and dotnet CLI (cross-platform) side-by-side, not just as links.
Avoid instructions that assume a GUI (e.g., 'right-click'), or supplement them with equivalent terminal commands.
Add a section or callouts for Linux/macOS users, highlighting any differences or additional steps required.
Ensure screenshots (if any) and terminology are inclusive of both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a mild Windows bias. In the prerequisites and quickstart links, Windows is listed first in tabbed instructions and URLs (e.g., 'tabs=flask,windows,azure-cli,...'), and there is an implicit assumption of Azure Portal/GUI usage (which is more common on Windows). There are no explicit Linux or cross-platform shell examples for environment variable setup or deployment, and the instructions for setting environment variables and app settings focus on the Azure Portal UI, which is more familiar to Windows users. There is also no mention of Linux-specific tools or shell commands for local development, aside from generic Python commands.

Recommendations:

Provide explicit Linux/macOS shell examples for setting environment variables (e.g., export commands) and running the app.
Ensure that quickstart and prerequisite links include Linux and macOS tabs/examples, not just Windows.
Mention and demonstrate use of cross-platform tools (such as Azure CLI in Bash) for all setup and deployment steps.
Clarify that all Python and Azure CLI commands work identically on Linux/macOS, and provide any necessary platform-specific notes.
Include screenshots or instructions for both Azure Portal (GUI) and CLI-based configuration to support users on all 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-native tools (such as Bash, Azure CLI, or REST API via curl). The exclusive use of PowerShell and references to Azure PowerShell cmdlets assume a Windows environment or familiarity with Windows tooling. No mention is made of cross-platform or Linux-first approaches, and the PowerShell section appears before any mention of ARM templates or other platform-neutral methods.

Recommendations:

Add equivalent Azure CLI (az) examples for all PowerShell commands to ensure Linux and macOS users have clear, native instructions.
Include Bash shell and REST API (curl) examples where appropriate, especially for scripting and automation scenarios.
Explicitly state that PowerShell examples can be run cross-platform (if true), or clarify any platform limitations.
Reorder sections to present cross-platform or platform-neutral methods (such as Azure CLI or ARM templates) before or alongside PowerShell examples.
Add a note or table summarizing available tooling for both Windows and Linux environments, helping users choose the best fit for their platform.

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 given equal prominence to CLI, and there is no explicit mention that PowerShell commands are Windows-specific or how to run them on Linux. The only explicit Linux/Unix command is 'nslookup' and 'curl', but there are no Bash scripting or Linux-native tool examples for interacting with Azure beyond Azure CLI. The section on outbound IPv6 support specifically notes that outbound IPv6 is only available for Windows apps, with no Linux equivalent or roadmap. Overall, the documentation assumes familiarity with Windows tools and patterns, and does not clarify cross-platform differences or provide Linux-specific guidance where Windows-only features are mentioned.

Recommendations:

Clearly indicate that Azure PowerShell commands are Windows-centric and provide guidance for running them on Linux (e.g., via PowerShell Core).
Prioritize Azure CLI examples before PowerShell, as CLI is fully cross-platform.
Where outbound IPv6 support is Windows-only, explicitly state the lack of Linux support and, if possible, provide a roadmap or alternatives for Linux users.
Add more Linux-native examples or troubleshooting tips (e.g., using Bash scripting, jq for JSON parsing, or other common Linux tools).
In sections where Windows-only features are discussed, provide equivalent Linux guidance or clearly state when a feature is not available for Linux.
Consider a 'Platform differences' callout box summarizing any disparities between Windows and Linux App Service behaviors.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a Windows-first bias. All file paths and examples use Windows-style paths (e.g., D:\home), and the discussion of folder structure and cache locations is entirely in Windows terms. There is no mention of Linux equivalents or file paths. The only tool mentioned for checking disk usage is the 'Azure Web Apps Disk Usage' site extension, which is primarily relevant to Windows-based App Service. While the page notes that local cache is not supported for Linux containers and points to an alternative ('App Cache'), it does not provide Linux-native examples or guidance for Linux App Service environments.

Recommendations:

Include Linux-specific paths and behaviors (e.g., /home/site/wwwroot) alongside Windows paths when describing folder structure and cache locations.
Provide examples or instructions for enabling and managing local cache on Linux-based App Service plans, or clearly state if the feature is unavailable.
Mention Linux-compatible tools or commands for checking disk usage (e.g., using 'du' in SSH/Kudu Bash) in addition to or instead of Windows-specific site extensions.
Clarify the differences in feature support and behavior between Windows and Linux App Service environments early in the documentation.
If local cache is not supported on Linux, provide a clear link to the Linux equivalent feature documentation and summarize key differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. Windows-specific concepts and limitations (e.g., Windows Containers subnet sizing, Windows Server Active Directory, NetBIOS) are discussed in detail, while Linux-specific scenarios are only briefly mentioned. There are no Linux-specific configuration or troubleshooting examples, and the only explicit Linux mention is a short note about continuous deployment dependencies. No Linux command-line examples or tools are provided, and Windows terminology (e.g., Kudu console) is used without Linux equivalents.

Recommendations:

Add explicit Linux-focused sections or examples, such as Linux container subnet sizing, common Linux networking issues, or Linux-specific environment variables.
Include Linux CLI (bash/az CLI) command examples for configuring and troubleshooting VNet integration, alongside any PowerShell or portal instructions.
Balance the coverage of Windows and Linux limitations and features, ensuring that Linux-specific caveats (e.g., file system mounts, SELinux, DNS resolution) are addressed.
Reference Linux-native tools (e.g., curl, dig, ip, netcat) for network troubleshooting, not just Windows tools or the Kudu console.
Where Windows-specific features are mentioned (e.g., Windows Containers, Active Directory), provide parallel Linux context or explicitly state if a feature is not applicable to Linux.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows-first bias by providing more detailed instructions and features for Windows-based App Service apps, including exclusive logging types (web server logging, detailed error messages, failed request tracing) and examples. Linux instructions are present but less detailed, and some features are unavailable or not described for Linux. Windows tools and file paths are referenced more frequently, and Linux-specific tools or patterns are not mentioned.

Recommendations:

Provide equivalent, detailed instructions and examples for Linux-based App Service apps wherever possible, including logging types and file access.
Clearly indicate feature parity or differences between Windows and Linux, and offer workarounds or alternatives for Linux where features are missing.
Include Linux-specific tools, file paths, and troubleshooting patterns alongside Windows ones (e.g., mention Linux text editors, log viewers, or CLI utilities).
When referencing tools like Log Parser or file paths, provide Linux equivalents or note their applicability.
Where features are Windows-only, explain why and suggest alternative monitoring/logging strategies for Linux users.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-centric bias by referencing Windows-specific tools (IIS, Procdump, SysInternals), focusing on PowerShell for management, and linking to Windows-oriented resources. There is a lack of Linux-specific troubleshooting guidance, examples, or mention of Linux-native tools, despite Azure App Service supporting Linux-based apps.

Recommendations:

Provide equivalent Linux troubleshooting steps, including how to access logs, collect diagnostics, and use the Kudu console or SSH for Linux-based App Service plans.
Include examples for managing and restarting apps using Azure CLI (cross-platform) alongside or before PowerShell.
Mention Linux-native tools (such as strace, lsof, top, or dotnet-trace for .NET Core on Linux) for diagnostics and profiling.
Clarify which features or tools are Windows-only and provide Linux alternatives or workarounds where possible.
Add links to Linux-specific documentation for Application Insights Profiler, diagnostic logging, and Kudu features on Linux.
Balance references to Windows and Linux in both text and linked resources to ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a moderate Windows bias. It consistently references the Azure portal (a web UI, but often associated with Windows-centric workflows), Visual Studio Code (with screenshots and instructions), and .NET/NUnit (with PowerShell/dotnet CLI commands). There is no mention of Linux-specific workflows, tools, or terminal environments. All CLI examples are generic, but the focus on Visual Studio Code and .NET/NUnit, as well as the absence of Linux/macOS-specific instructions or screenshots, suggests a Windows-first approach. There are no explicit Linux shell or environment variable examples (e.g., export vs. set), and no mention of Linux package managers or shell environments.

Recommendations:

Add explicit Linux/macOS shell examples for setting environment variables (e.g., export PLAYWRIGHT_SERVICE_URL=...) alongside Windows/PowerShell equivalents.
Include screenshots or instructions for running Playwright tests in popular Linux environments or terminals.
Mention cross-platform compatibility for the Azure CLI and Playwright CLI, and provide installation links or notes for Linux/macOS users.
Balance Visual Studio Code instructions with alternative editors or CLI-only workflows, especially for Linux users.
Clarify that all steps and tools (Azure CLI, Playwright CLI, .NET, etc.) are cross-platform, and provide troubleshooting notes for Linux/macOS where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a Windows-first and PowerShell-centric bias. Windows instructions, tools, and examples are consistently presented before Linux equivalents, and in some sections, Linux examples are less detailed or omitted. PowerShell and Windows-specific tools (e.g., Control Panel, Windows environment variable dialogs, Windows certificate stores) are emphasized, while Linux instructions are often more generic or less prominent. PowerShell cmdlets are used exclusively in authentication and runbook examples, with no Bash or Python script equivalents for Linux users. Some advanced features (like Hybrid Worker Credentials) are noted as unsupported on Linux, but without Linux alternatives or workarounds.

Recommendations:

Present Windows and Linux instructions/examples in parallel or in clearly separated, equally detailed sections.
Provide Linux/Bash/Python script examples alongside PowerShell examples, especially for authentication, runbook management, and automation tasks.
When referencing tools (e.g., environment variable management, certificate/key management), include Linux-native tools and commands (e.g., export, /etc/environment, openssl, gpg) with step-by-step instructions.
Avoid assuming PowerShell as the default scripting language; clarify when features are PowerShell-specific and offer alternatives for Bash/Python where possible.
For features not supported on Linux (e.g., Hybrid Worker Credentials), suggest Linux-native alternatives or explicitly state the limitation and potential workarounds.
Balance the order of presentation so that Linux and Windows users can quickly find relevant information without perceiving one platform as secondary.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific tools, settings, and instructions are often mentioned before or more prominently than their Linux equivalents. Some sections provide only Windows-oriented examples (e.g., ReadyToRun, checking 32/64-bit status), or use Windows-centric terminology and commands. While Linux is mentioned and supported, parity in examples and guidance is inconsistent, and some Linux-specific details are relegated to secondary tabs or footnotes.

Recommendations:

Ensure all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
When referencing tools (e.g., Azure CLI, PowerShell), always provide both Windows and Linux command variants, or clarify cross-platform compatibility.
Avoid listing Windows methods or tools first by default; alternate order or present both together.
Expand ReadyToRun and deployment sections to include explicit Linux examples (e.g., dotnet publish --runtime linux-x64, project file snippets for Linux).
Where tabs are used for OS-specific instructions, ensure both tabs are equally detailed and easy to find.
Explicitly mention any differences or limitations for Linux users up front, rather than as footnotes.
Audit for any references to Visual Studio or PowerShell that lack corresponding VS Code or Bash/Linux alternatives, and add them where missing.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally maintains cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows command-line examples (Cmd) are presented alongside Bash, but Cmd is often listed second, which is good. However, the documentation refers to 'command prompt' and 'terminal' together, which can be confusing. There is also a reliance on Azure CLI, which is cross-platform, but some terminology and example structures (e.g., 'command prompt', 'cmd') are more familiar to Windows users. No Linux-specific tools or shell environments (like zsh or fish) are mentioned, and there are no explicit Linux troubleshooting notes or examples. The documentation does not provide PowerShell-specific examples, which is positive, but it also does not highlight Linux-first workflows or tools.

Recommendations:

Ensure that all references to 'command prompt' or 'cmd' are paired with clear references to 'terminal' or 'shell' for Linux/macOS users.
Wherever command examples are given, consider listing Bash (Linux/macOS) before Cmd (Windows) to reinforce Linux parity.
Add explicit notes or tips for Linux users where file paths, environment variables, or permissions may differ from Windows.
Include troubleshooting tips or common issues for Linux environments, such as case sensitivity or shell differences.
Consider mentioning or linking to Linux-specific tools or workflows (e.g., using zsh, fish, or Linux package managers for JDK installation).
Review all language to ensure that Windows terminology does not dominate, and that Linux/macOS users feel equally addressed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page is generally cross-platform and Linux-friendly, but there are subtle signs of Windows bias. In several places, Windows terminology ("command prompt") is used before or instead of Linux/Unix equivalents ("terminal"), and some folder structure examples use Windows-style command prompt code blocks. The remote build workflow is recommended specifically for Windows users, and local build is discouraged for Windows, but not for Linux. There is also mention of the Python standard library being installed with Python on Windows, while on Unix-based systems it's described as provided by package collections, which may imply a more complex experience on Linux. However, there are no outright missing Linux examples, and Linux hosting is clearly the default for Python on Azure Functions.

Recommendations:

Use neutral, cross-platform terminology such as 'terminal' or 'shell' instead of 'command prompt' or 'cmd', or mention both (e.g., 'terminal or command prompt').
When showing folder structures, use generic code blocks or 'tree' command output, or provide both Windows and Unix-style examples.
Clarify that both Windows and Linux users can use the Azure Functions Core Tools and provide any OS-specific instructions as needed.
When discussing package management or the Python standard library, avoid implying that Linux is more complex; instead, provide clear, parallel instructions for both platforms.
If recommending remote build for Windows, also state the recommended approach for Linux/Mac users for parity.
Explicitly mention Linux/Mac equivalents for any Windows-specific tools or paths, and ensure all CLI commands work on both platforms.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a moderate Windows bias, particularly in the developer guidance section. PowerShell is highlighted with a dedicated note about module changes, and PowerShell cmdlets are given equal prominence to Azure CLI, with explicit links and examples. References to Windows-centric tools (e.g., Visual Studio, System Center Operations Manager) are present, and some cross-platform tools are mentioned only after Windows-specific ones. There is no explicit Linux example or mention of Linux-native tools (e.g., Bash, shell scripts), and the documentation assumes familiarity with Windows-based administration patterns.

Recommendations:

Provide Linux-specific examples alongside PowerShell, such as Bash or shell script equivalents for Azure CLI usage.
When referencing PowerShell modules, also mention and link to Azure CLI and its installation/usage guides for Linux and macOS.
In developer tool guidance, include references to cross-platform editors (e.g., VS Code) and command-line tools, not just Visual Studio.
For SDK and endpoint configuration, provide sample configuration snippets for both Windows and Linux environments.
Ensure that any references to Windows tools or workflows are balanced with Linux alternatives or at least acknowledge cross-platform options.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Windows tools and workflows for managing SMB permissions (e.g., MMC, Windows Security tab), and by omitting Linux-based SMB client instructions or examples. All examples and screenshots are Windows-centric, and there is no mention of how to access or manage SMB volumes from Linux clients, despite SMB being cross-platform.

Recommendations:

Include instructions and examples for accessing and managing SMB volumes from Linux clients, such as using smbclient, mount.cifs, or Nautilus.
Provide Linux command-line examples for mounting SMB shares and setting permissions (where applicable).
Mention Linux tools (e.g., smbclient, cifs-utils) alongside Windows tools when discussing SMB access and management.
Add screenshots or terminal output from Linux environments to balance the visual representation.
Clarify any differences or limitations when using SMB volumes from Linux clients, if applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for mounting NFS volumes, but there are subtle biases. The Windows section is presented after Linux, but the Windows mounting process requires first mounting on a Linux/Unix VM and running chmod, which may not be familiar or accessible to Windows-only administrators. The Linux section is detailed with explicit mount command examples, while the Windows section lacks a full, step-by-step example (e.g., enabling NFS client, prerequisites). The Windows example references the 'Mount' command but does not provide parity in detail compared to Linux. There is also an assumption that users have access to a Linux/Unix system for initial setup, which may not be true for all Windows environments.

Recommendations:

Provide a complete, standalone Windows workflow for mounting NFS volumes, including prerequisites (e.g., enabling NFS client feature in Windows), and any required permissions or configuration steps.
Offer alternative approaches for Windows-only environments that do not require a Linux/Unix VM for initial chmod operations, or clarify how to set permissions from Windows if possible.
Ensure that both Linux and Windows sections include equally detailed, step-by-step instructions and troubleshooting tips.
Include references to Windows-specific NFS documentation and tools in the same level of detail as Linux.
Consider adding a table comparing feature support and limitations for NFS on Linux vs. Windows to set clear expectations.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses exclusively on assessing ASP.NET web apps for migration, but implicitly assumes a Windows environment by referencing only ASP.NET (traditionally Windows/IIS-based) and omitting any mention of Linux-hosted .NET web apps, Linux tools, or cross-platform assessment methods. There are no examples or guidance for users running .NET apps on Linux, nor are Linux-specific tools or patterns mentioned.

Recommendations:

Explicitly mention support for assessing .NET web apps hosted on Linux, including .NET Core/ASP.NET Core apps.
Provide examples or references for assessment processes on Linux environments, such as using Bash scripts or Linux-native tools.
Clarify whether the assessment tools and recommendations apply equally to Linux-hosted .NET apps, and if not, provide guidance or links for Linux users.
Include parity in documentation for both Windows and Linux scenarios, ensuring that Linux users are not excluded from the assessment workflow.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by referencing the Windows file path ('C:\home\site\wwwroot') as the default location for the configuration file, and only later mentioning the Linux equivalent. There are no explicit Linux command-line or file system examples, and Linux-specific instructions are minimal and only provided as a note. No Linux shell commands or patterns are shown, and the documentation assumes familiarity with Windows paths and conventions.

Recommendations:

Present both Windows and Linux file paths together when describing file locations (e.g., 'C:\home\site\wwwroot\auth.json' for Windows and '/home/site/wwwroot/auth.json' for Linux).
Include explicit Linux examples and instructions alongside Windows ones, such as how to create or deploy the configuration file on Linux-based App Service environments.
Avoid assuming Windows as the default platform; use neutral language or parallel examples.
Add a table or section summarizing platform-specific differences (e.g., path formats, deployment nuances) for clarity.
Where relevant, provide Linux shell command examples (e.g., using cp, mv, or echo) in addition to any Windows/Powershell commands.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page presents Windows container SSH access first and describes it as requiring no modifications, while Linux custom containers require extra steps. The Windows section lacks command-line or PowerShell examples, but the Linux section provides detailed Azure CLI and SSH command-line instructions. There are no equivalent CLI or PowerShell instructions for Windows containers, and the Linux section is more comprehensive in terms of actionable steps. However, the initial placement of Windows content and the lack of parity in example depth may suggest a subtle 'windows_first' and 'missing_linux_example' bias (in reverse: missing Windows CLI example).

Recommendations:

Provide equivalent command-line (e.g., PowerShell or Azure CLI) instructions for opening SSH sessions to Windows containers, if supported.
Ensure that both Windows and Linux sections have similar levels of detail and actionable examples.
If SSH via CLI is not supported for Windows containers, explicitly state this and offer alternative remote management options for Windows containers.
Consider presenting Linux and Windows instructions in parallel or with equal prominence, rather than always listing Windows first.
Clarify any feature gaps between Windows and Linux containers to set user expectations.

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 workflows are presented generically without explicit mention of Windows or Linux. However, there is an implicit Windows/.NET bias due to the exclusive focus on ASP.NET Core, NuGet, and .NET CLI tools, with no mention of Linux-specific development environments, shell commands, or alternative (non-Windows) deployment patterns. There are no PowerShell-specific commands, but the lack of Linux/Unix shell examples or explicit Linux parity is notable.

Recommendations:

Explicitly mention that all .NET CLI commands work on Linux, macOS, and Windows, and clarify that the tutorial is platform-agnostic.
Add a note or section describing how to run the sample app and commands in a local Linux or macOS environment (e.g., using bash/zsh instead of just 'codespace terminal').
Provide alternative instructions for deploying from a local Linux shell (e.g., using Azure CLI in bash) in addition to Codespaces.
If referencing file paths, use forward slashes or clarify path conventions for both Windows and Linux.
Include a brief section or callout for Linux users, confirming that all tools and steps are supported cross-platform and linking to .NET installation instructions for Linux.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page demonstrates configuring environment-specific values in Azure App Configuration using an ASP.NET Core app. All examples and instructions assume the use of .NET Core tooling and workflows, but they reference only the modification of launchSettings.json (a Visual Studio/Windows-centric file) for environment variables, without mentioning Linux/macOS equivalents (such as setting environment variables via shell or using other configuration files). There are no examples for setting environment variables or running the app in Linux/macOS environments, and the workflow implicitly assumes a Windows/Visual Studio context.

Recommendations:

Add instructions for setting the ASPNETCORE_ENVIRONMENT variable in Linux/macOS shells (e.g., export ASPNETCORE_ENVIRONMENT=Production dotnet run).
Mention that launchSettings.json is primarily used by Visual Studio and dotnet CLI, and provide alternative methods for other environments.
Include examples or notes on how to run and configure the app in Linux/macOS terminals.
Ensure screenshots and file paths are not Windows-specific, or provide cross-platform alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates mild Windows bias by emphasizing Windows-specific patterns and tools. For example, the Windows installation section recommends using Windows Subsystem for Linux (WSL) rather than providing native Windows redis-cli installation guidance or alternatives. Additionally, Windows tools like Windows Terminal are mentioned, and Azure PowerShell is listed alongside Azure CLI, sometimes before or equally with Linux-native tools. However, Linux installation and usage are well covered, and most command examples are cross-platform.

Recommendations:

Provide explicit instructions or references for native redis-cli installation on Windows (e.g., using precompiled binaries or third-party distributions), not just via WSL.
When listing ways to retrieve cache keys, mention Azure CLI (cross-platform) before Azure PowerShell (Windows-centric), or present both equally with clear cross-platform notes.
When referencing terminals, mention cross-platform options (e.g., Windows Terminal, macOS Terminal, GNOME Terminal) rather than focusing on Windows Terminal.
Ensure that all alternative tools and workflows are described with equal clarity for both Linux and Windows users.
Consider adding a troubleshooting section for common issues on both Linux and Windows platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a mild Windows bias by referencing Windows-specific documentation first (e.g., linking to '/azure/virtual-machines/windows/proximity-placement-groups-portal') and not mentioning Linux equivalents or providing Linux-specific guidance for proximity placement groups or related Azure VM operations. There are no PowerShell-heavy examples or command-line snippets, but the absence of Linux parity in references and links is notable.

Recommendations:

Include links to both Windows and Linux documentation for Azure VM features such as proximity placement groups (e.g., '/azure/virtual-machines/linux/proximity-placement-groups-portal').
Where VM or infrastructure operations are discussed, clarify that the guidance applies to both Windows and Linux VMs, or provide Linux-specific notes where relevant.
Ensure that all referenced workflows, forms, and best practices are equally accessible and documented for Linux-based SAP HANA deployments.
Review all cross-references and examples to ensure Linux users are not overlooked, especially in environments where SAP HANA is commonly deployed on Linux.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core (Windows-centric platforms) configuration providers first in both the library table and the feature matrix, with Linux/Unix-first platforms (such as Python, Go, and JavaScript) appearing later. There are no explicit Windows-only tools or PowerShell examples, but the ordering and emphasis on .NET/Windows frameworks may suggest a subtle Windows bias.

Recommendations:

Reorder the configuration provider libraries table to alternate or group by language family (e.g., .NET, Java, Python, JavaScript, Go) rather than placing all .NET/Windows-centric providers first.
Explicitly mention cross-platform compatibility for each provider, especially for .NET Standard and .NET Core, which run on Linux and macOS as well as Windows.
Add a note clarifying that Azure App Configuration is supported equally on Linux and Windows, and that most providers are cross-platform.
Consider including at least one Linux/Unix-specific example or reference (e.g., using the Python or Go provider on Linux) to balance the implicit focus on Windows.
If possible, provide parity in sample links and documentation depth for Linux/Unix-targeted languages (Python, Go, JavaScript) as is done for .NET.

Create pull request

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