Scan Details - Linux-first Docs for Azure

1172

Pages Scanned

58

Pages Flagged

1172

Changed Pages

4.9%

% Pages Flagged

Scan Information

Started At: 2025-08-29 00:01:11

Finished At: 2025-08-29 00:28:03

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. In sections where command-line examples are provided, Azure PowerShell (a Windows-centric tool) is consistently presented before Azure CLI, and PowerShell-specific cmdlets are referenced for status checks even in the CLI section. There are no explicit Linux shell or Bash examples, and no mention of Linux-specific tools or workflows. The documentation assumes familiarity with PowerShell, which may disadvantage Linux users.

Recommendations:

Present Azure CLI examples before or alongside PowerShell examples, as Azure CLI is cross-platform and more familiar to Linux users.
When referencing status checks or outputs, provide both Azure CLI and PowerShell equivalents, rather than only PowerShell cmdlets (e.g., use 'az feature show' for CLI status instead of 'Get-AzProviderFeature').
Explicitly mention that Azure CLI commands work natively on Linux, macOS, and Windows, and provide Bash shell snippets where appropriate.
Consider including a short section or note for Linux users, clarifying that all portal and CLI steps are fully supported on Linux systems.
Avoid assuming PowerShell as the default scripting environment; where scripting is discussed, offer Bash or shell script alternatives.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and commands, both for migration and preview registration/unregistration. The only command-line examples provided use Azure PowerShell cmdlets (Set-AzContext, Get-AzProviderFeature, Register-AzProviderFeature), with no equivalent Azure CLI (az) or Bash/Linux shell examples. The 'Next steps' section also lists a PowerShell-based tutorial first, and the page metadata references 'devx-track-azurepowershell', further reinforcing the Windows/PowerShell focus. There is no mention of Linux or cross-platform tooling, nor are there examples for Linux users.

Recommendations:

Provide Azure CLI (az) command examples alongside or before PowerShell cmdlets for all operations, including preview registration, unregistration, and migration.
Explicitly mention that all features and scripts are available cross-platform, and clarify any platform-specific requirements.
Include Bash/Linux shell script examples where relevant, especially for migration and automation scenarios.
Balance tutorial and 'Next steps' links by including both PowerShell and Azure CLI/Bash-based guides.
Update page metadata to reflect cross-platform support, not just Azure PowerShell.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page 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 any Linux/CLI equivalents for these steps. There are no Linux-specific instructions or examples for deploying, validating, or cleaning up resources.

Recommendations:

Provide equivalent Azure CLI (cross-platform) commands for resource cleanup, such as 'az group delete --name <resource group name>'.
Include examples using a Linux-based backend (e.g., NGINX or Apache) for validation, or at least mention how to adapt the template for Linux VMs.
Where PowerShell is referenced, always offer Azure CLI alternatives and present them with equal prominence.
Clarify that the instructions apply to both Windows and Linux users, and link to relevant Linux/CLI quickstarts where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation page exhibits a strong Windows bias: all migration tools and examples focus exclusively on Windows environments, specifically IIS servers and PowerShell scripts. There is no mention of Linux-based hosting scenarios, migration from Linux web servers, or Linux-compatible tools. The App Service Migration Assistant and related scripts are only available for Windows, and Windows terminology and tools are consistently prioritized and presented without Linux alternatives.

Recommendations:

Include migration guidance and tooling for .NET apps hosted on Linux web servers (e.g., Apache, Nginx).
Provide Linux shell (bash) script equivalents for PowerShell-based migration steps.
Mention and link to any Linux-compatible migration tools, or clarify the lack thereof and suggest workarounds.
Add examples and documentation for containerizing and migrating .NET Core/ASP.NET Core apps running on Linux.
Balance the presentation by explicitly addressing both Windows and Linux scenarios in tool tables and migration workflows.
If Windows-only support is intentional, clearly state this limitation at the top of the documentation.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a subtle Windows bias by referencing Windows-specific configuration files (web.config), mentioning iisnode settings for Node.js apps, and omitting equivalent Linux-native configuration or troubleshooting examples. While there is a brief mention of running on Linux with PM2, most configuration and diagnostic guidance assumes a Windows environment or uses Windows-centric tools and patterns.

Recommendations:

Provide Linux-native equivalents for configuration steps, such as using environment variables or appsettings.json instead of web.config.
Include examples for configuring auto-healing and diagnostics on Linux-based App Service plans.
Mention and demonstrate Linux-native process managers (e.g., systemd, supervisord) where relevant, in addition to PM2.
When referencing iisnode or web.config, clarify that these are Windows-specific and provide parallel guidance for Linux containers or App Service on Linux.
Ensure troubleshooting and best practice sections include both Windows and Linux workflows, tools, and file locations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by listing Windows-specific options and tools before their Linux equivalents, providing PowerShell automation examples alongside Azure CLI, and referencing Windows-centric patterns (such as 'Windows containers' before 'Linux containers'). While Linux is supported and examples are present, Windows is consistently mentioned first or given equal prominence even where Linux is more common (e.g., scripting with PowerShell).

Recommendations:

Alternate the order of Windows and Linux mentions throughout the documentation, sometimes listing Linux first.
Provide Bash or shell scripting examples alongside PowerShell, especially in automation sections.
Clarify when instructions or tools are cross-platform (e.g., Azure CLI) and note any OS-specific differences.
In sections discussing containers, mention Linux containers first or provide parity in explanation and examples.
Where possible, add explicit Linux-focused guidance or troubleshooting steps, not just parity in commands.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias in several ways: Windows SKU availability is shown before Linux, PowerShell scripting is featured alongside Azure CLI but no Linux shell (bash) examples are provided, and portal instructions are written generically but implicitly assume familiarity with Windows-centric tools. There is no mention of Linux-specific scripting or automation tools, and the PowerShell example is not paired with a bash or shell script equivalent.

Recommendations:

Present Linux and Windows instructions/examples in parallel, or alternate which comes first.
Include bash or shell script examples for automation, not just Azure CLI and PowerShell.
Explicitly mention Linux compatibility and provide Linux-specific guidance where relevant (e.g., for custom containers).
Clarify when instructions are platform-agnostic versus platform-specific.
Where PowerShell is shown, provide a comparable bash example for Linux users.
Highlight any differences in process or tooling between Windows and Linux deployments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally provides both Windows and Linux instructions for installing and using the Hybrid Connection Manager, but there is a noticeable Windows-first bias. Windows instructions, tools, and screenshots are often presented before Linux equivalents, and some troubleshooting steps (such as using PowerShell's Test-NetConnection) only provide Windows examples. The GUI for Hybrid Connection Manager is only available on Windows, with Linux users directed to CLI usage. Some diagnostic steps and tools (e.g., PowerShell, GUI) are Windows-specific, and Linux alternatives are not always provided or are less detailed.

Recommendations:

Provide Linux command-line equivalents for all troubleshooting steps that currently only show Windows/PowerShell commands (e.g., suggest 'nc', 'telnet', or 'curl' for connectivity tests).
Where GUI tools are only available on Windows, offer more detailed CLI instructions and screenshots for Linux users to achieve parity.
Present Windows and Linux instructions in parallel or in a more balanced order, rather than always listing Windows first.
Include Linux-specific troubleshooting tips and common issues, similar to the detail given for Windows.
Where possible, provide cross-platform examples for all commands and tools, or explicitly state when a feature is Windows-only and suggest best alternatives for Linux.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows/Powershell bias by providing only PowerShell scripts for advanced resource discovery (e.g., identifying Traffic Manager endpoints), without offering Bash, Azure CLI, or cross-platform alternatives. References to automation or scripting are exclusively PowerShell-based, and there are no Linux shell or Bash script equivalents. This may disadvantage users on Linux or macOS who do not use PowerShell.

Recommendations:

For every PowerShell script or automation example, provide an equivalent Bash or Azure CLI script where possible, or at least reference cross-platform alternatives.
Explicitly mention that PowerShell Core is cross-platform if PowerShell is the only option, and provide installation guidance for non-Windows users.
When linking to scripts or tools, clarify their platform compatibility and offer guidance for Linux/macOS users.
Instruct users on how to use Azure CLI (which is cross-platform) for resource discovery tasks, especially for scenarios where only PowerShell scripts are currently referenced.
Review all automation and scripting guidance to ensure Linux and macOS users are not excluded or left with a more difficult workflow.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation focuses exclusively on discovering ASP.NET web apps hosted on IIS servers within VMware environments, which are Windows-centric technologies. There are no references to Linux-based hosting, such as Kestrel or Apache/Nginx, nor are there any Linux-specific discovery instructions or examples. All tools and workflows mentioned (Azure Migrate appliance, IIS) are Windows-specific, and Linux scenarios are omitted.

Recommendations:

Include information about discovering .NET web apps hosted on Linux servers (e.g., using Kestrel, Apache, or Nginx).
Provide parity in examples and workflows for both Windows (IIS) and Linux-based deployments.
Mention any limitations or support status for Linux-based .NET app discovery with Azure Migrate.
Add links to Linux-specific documentation or migration guides if available.
Clarify in the introduction that the current guidance is Windows/IIS-specific, and outline steps for Linux users if supported.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration and troubleshooting steps reference Windows-specific tools, paths, and concepts (e.g., node.exe, web.config, named pipes, Win32 error codes, IIS, PowerShell, CMD). There are no examples or guidance for Linux-based App Service environments, and Linux equivalents (such as PM2, systemd, or Linux file paths) are not mentioned. The use of Windows command shells (CMD/PowerShell) is assumed throughout.

Recommendations:

Add a parallel section or page for Node.js on Azure App Service Linux, covering best practices and troubleshooting steps relevant to Linux environments.
Include Linux-specific configuration and troubleshooting examples (e.g., using PM2, systemd, or Linux process management tools).
Provide Linux shell (bash) command examples alongside Windows CMD/PowerShell examples.
Reference Linux file paths and logging locations where appropriate.
Clarify at the top of the page that the guidance is Windows-specific, and link to Linux-specific documentation if available.
Mention cross-platform Node.js debugging and profiling tools, and provide instructions for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by referencing Azure Storage Explorer with a direct link to the Windows-specific tab for generating SAS tokens, without mentioning Linux or macOS alternatives. There are no explicit PowerShell examples, but the only GUI tool mentioned is typically associated with Windows. No Linux command-line or GUI alternatives are provided, and the documentation does not clarify cross-platform support for Storage Explorer or offer Linux-specific instructions.

Recommendations:

Explicitly state that Azure Storage Explorer is available on Windows, macOS, and Linux, and provide links or instructions for all platforms.
Avoid linking directly to Windows-specific tabs in documentation; instead, use platform-neutral links or provide parallel instructions for Linux/macOS.
Include command-line alternatives (e.g., using Azure CLI or azcopy) for generating SAS tokens, which work across platforms.
If GUI instructions are given, provide screenshots or steps for Linux/macOS where the UI differs.
Add a note or section clarifying that all Azure CLI commands are cross-platform and can be run on Windows, Linux, or macOS.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Windows-based deployment patterns, tools, and file paths (such as Kudu, CMD/PowerShell consoles, and Windows directory structures). There are no Linux-specific instructions, examples, or parity for Linux App Service environments, and the documentation assumes the use of Visual Studio and Windows-centric workflows.

Recommendations:

Add explicit sections or notes for configuring ASP.NET apps on Linux-based App Service plans, including how to check .NET runtime versions and access environment variables.
Provide Linux shell (bash) command examples alongside CMD/PowerShell commands, especially for Kudu or SSH-based access.
Mention Linux-specific deployment patterns and tools (such as using FTP, SCP, or Azure CLI from a Linux shell).
Clarify when instructions are Windows-only and provide equivalent steps for Linux where possible.
Include screenshots or references to Linux-based App Service environments in the Azure portal where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides both Linux and Windows instructions for configuring server-level data sources in Tomcat, but the Windows section is longer, more detailed, and features Windows-specific tools (PowerShell, .cmd scripts, Windows environment variables) prominently. The Windows instructions are also presented before the Linux ones in the Tomcat section, and the PowerShell-based automation is described in detail, while the Linux automation is less elaborate. There are no missing Linux examples, but the Windows approach is more thoroughly explained and uses Windows-centric tooling.

Recommendations:

Ensure Linux and Windows instructions are equally detailed, especially for automation and scripting.
Provide Linux shell script examples that match the depth and automation of the Windows PowerShell scripts.
Where possible, present Linux and Windows instructions in parallel or with equal prominence, rather than Windows-first.
Highlight cross-platform tools (such as Azure CLI, bash, or Python scripts) where feasible, instead of Windows-only tools like PowerShell.
Clarify any platform-specific limitations or differences up front, so users can quickly find the relevant section.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation generally provides parity between Linux and Windows, but there are subtle signs of Windows bias. In several sections, Windows instructions or tools (such as Kudu, Advanced Tools, and FTPS) are mentioned first or in more detail. Some diagnostic and profiler steps for Windows use the Kudu/SCM portal and FTPS, which are more familiar to Windows users, while Linux sections focus on SSH and CLI. There are also references to Windows-specific conventions (such as web.config) and file paths (C:\home), and some notes are specifically about Windows behavior. However, Linux coverage is strong, with detailed SSH, CLI, and container-based examples, and Linux is often mentioned explicitly in configuration and deployment examples.

Recommendations:

Ensure that Linux and Windows instructions are always presented in parallel, with neither platform consistently preceding the other.
Where Windows tools like Kudu/SCM or FTPS are mentioned, provide equivalent Linux-native approaches (e.g., SCP, SFTP, rsync) or clarify that these tools are cross-platform.
Avoid Windows-centric terminology (such as 'web.config') in general notes; clarify when something is Windows-only.
For sections like Java Flight Recorder and logging, ensure Linux and Windows have equally detailed, step-by-step instructions, including troubleshooting tips.
Highlight Linux-specific best practices and tools (e.g., using package managers, shell scripting) as prominently as Windows tools.
Review for any subtle ordering bias (e.g., always listing Windows before Linux) and alternate the order or present both together.

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, focusing on Windows-style directory structures, and omitting explicit Linux command-line or file path examples. All deployment and troubleshooting examples use Windows paths, and there are no Linux-specific instructions or parity in examples.

Recommendations:

Provide Linux file path equivalents (e.g., /home/site/wwwroot) alongside Windows paths in all relevant sections, not just in passing.
Include explicit Linux command-line examples or notes, especially where file system operations or directory creation are discussed.
Clarify that Azure CLI commands are cross-platform, and, where relevant, show both Windows (cmd/PowerShell) and Linux (bash) command syntax.
When mentioning directory structures or deployment paths, always present both Windows and Linux formats together.
Add troubleshooting notes specific to Linux environments if any differences exist.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page exhibits a moderate Windows bias, especially in the .NET/ASP.NET section, where Windows tools (Visual Studio, Azure PowerShell) are listed before cross-platform or Linux-native tools. Some Python and database examples default to Windows tabs or instructions, and the 'Next step' call-to-action promotes an ASP.NET (typically Windows-centric) quickstart. Linux and CLI options are present but are often listed after Windows-centric tools or not highlighted equally.

Recommendations:

Ensure that for every Windows-specific tool or example (e.g., Visual Studio, Azure PowerShell), equivalent Linux or cross-platform alternatives (e.g., VS Code, Azure CLI, Bash) are listed with equal prominence and, where possible, listed first or side-by-side.
Review all quickstart and tutorial links to ensure Linux tabs/examples are available and, if possible, default to cross-platform or Linux-first views.
Avoid defaulting to Windows tabs or instructions in code samples and links, especially for languages and stacks that are commonly used on Linux (e.g., Python, Node.js, PHP).
Balance the 'Next step' call-to-action by either rotating through different stacks or providing a neutral/cross-platform example, rather than defaulting to ASP.NET.
Explicitly mention when steps or tools are cross-platform, and clarify when a tool is Windows-only.
For .NET/ASP.NET, highlight .NET Core's cross-platform capabilities and provide explicit Linux deployment examples.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a bias toward Windows environments by referencing Visual Studio and its NuGet package manager as the primary method for installing dependencies, with CLI instructions only mentioned secondarily. There are no explicit Linux or cross-platform development environment examples (such as VS Code, JetBrains Rider, or command-line editors), nor are there any Linux-specific deployment or configuration instructions. The workflow assumes a GUI-based, Windows-centric development process and omits Linux terminal commands or guidance for common Linux scenarios.

Recommendations:

Provide explicit Linux and cross-platform instructions for all steps, including package installation (e.g., using dotnet CLI and NuGet CLI, not just Visual Studio).
Include examples and screenshots for Linux-based development environments (e.g., VS Code on Ubuntu, JetBrains Rider, or command-line editors like Vim/Nano).
When referencing tools, mention cross-platform or Linux-native tools first or equally (e.g., dotnet CLI before Visual Studio GUI).
Add deployment and configuration steps that are specific to Linux environments, such as setting environment variables via the command line or using Azure CLI/Bash scripts.
Ensure that all code and configuration examples are validated to work on both Windows and Linux platforms, and explicitly state any OS-specific requirements or differences.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a strong Windows bias by providing only PowerShell-based CLI examples for per-app scaling, with no equivalent examples for Linux users (such as Azure CLI or Bash). The use of PowerShell cmdlets and the absence of cross-platform command-line instructions or explicit mention of Linux tooling may hinder accessibility for non-Windows developers.

Recommendations:

Add Azure CLI (az) examples for all PowerShell commands shown, as Azure CLI is cross-platform and widely used on Linux and macOS.
Include Bash script examples where appropriate to illustrate configuration steps for Linux users.
When introducing command-line examples, present Azure CLI or REST API options before or alongside PowerShell to avoid a 'Windows-first' impression.
Explicitly state that per-app scaling can be configured using cross-platform tools, not just PowerShell.
Review and update the documentation to ensure parity in instructions and examples for both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and Azure PowerShell examples for finding outbound IP addresses, but PowerShell is presented alongside CLI without clarifying platform parity. There is no explicit mention of Linux-specific tools or shell environments, and PowerShell examples are included without noting that PowerShell is primarily a Windows tool (even though it is now cross-platform, many users still associate it with Windows). There are no Linux-specific command-line examples (e.g., using curl, jq, or bash scripting) for querying IP addresses via the REST API or Azure CLI output parsing. Additionally, outbound IPv6 support is noted as being available only for Windows apps, but this is a product limitation rather than a documentation bias.

Recommendations:

Clearly indicate which commands are cross-platform (e.g., Azure CLI) and which are Windows-centric (e.g., Azure PowerShell), and recommend CLI as the default for cross-platform compatibility.
Add Linux-native command-line examples (e.g., using curl, jq, or bash scripting) for querying and parsing IP addresses, especially for users who may not use PowerShell.
When presenting multiple command-line options, list Azure CLI examples first to emphasize cross-platform support.
Explicitly state that PowerShell examples are optional and primarily for users who prefer or require PowerShell.
Where product limitations exist (such as outbound IPv6 support only for Windows apps), clarify that this is a platform limitation and not a documentation bias.

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-centric terminology and tools (such as Kudu/SCM), and omitting Linux-specific examples or guidance. While there is a note mentioning that the feature is not supported in Linux containers and a link to an alternative (App Cache), the main documentation and all examples are presented from a Windows perspective, with no parity for Linux App Service environments.

Recommendations:

Include equivalent Linux file paths and behaviors (e.g., /home/site) alongside Windows paths in all relevant sections.
Provide explicit examples and instructions for enabling and managing local cache (or its alternatives) on Linux-based App Service plans.
Clarify which features, settings, and tools are available or behave differently on Linux App Service, and provide links to Linux-specific documentation where appropriate.
Where features are not supported on Linux, offer clear guidance and migration paths (such as using App Cache), including usage examples.
Ensure that any references to tools (e.g., Kudu/SCM) mention their Linux equivalents (e.g., KuduLite) and note any differences in usage or availability.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page subtly favors Windows by mentioning Windows-specific tools (such as Azure PowerShell) and development environments (Visual Studio) before or more prominently than their Linux or cross-platform equivalents. There are no explicit Linux command-line examples or references to Linux-specific tooling, and the mention of 'command line tools you already use' lists Azure PowerShell alongside Azure CLI, which may imply a Windows-first perspective. Linux support is mentioned in passing, but not demonstrated or exemplified.

Recommendations:

Provide explicit Linux command-line examples (e.g., bash, Azure CLI) alongside or before Windows/PowerShell examples.
Highlight cross-platform IDEs and tools (such as Visual Studio Code, IntelliJ, Eclipse) equally, and clarify their support on Linux.
When listing command-line tools, mention Azure CLI before Azure PowerShell to reflect cross-platform parity.
Include references or links to Linux-specific deployment guides or troubleshooting resources.
Ensure that application templates and marketplace offerings highlight Linux-friendly stacks and frameworks.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. It provides detailed calculations and considerations specifically for Windows Containers, including subnet sizing and networking units, while not offering equivalent details for Linux containers. The only explicit mention of Linux is in a brief note about continuous deployment network dependencies, which is less prominent and detailed compared to the Windows section. There are no Linux-specific examples, troubleshooting steps, or parity in container-specific guidance. The documentation also references Windows-centric features (e.g., Windows Server Active Directory domain join) and tools (Kudu console UI) without mentioning Linux alternatives.

Recommendations:

Add a parallel section detailing subnet/IP requirements and networking unit calculations for Linux containers, if applicable.
Provide Linux-specific examples or notes wherever Windows-specific guidance is given (e.g., for container scaling, networking, and environment variables).
Include troubleshooting steps and best practices for Linux-based App Service apps, matching the detail given to Windows scenarios.
Mention Linux alternatives or equivalents for tools like the Kudu console UI, or clarify their cross-platform applicability.
Ensure that any Windows-specific limitations or features are clearly marked as such, and provide Linux-specific notes where behavior differs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias in several ways: Windows paths and conventions are often given as the primary or only example (e.g., 'D:\home'), Windows-specific tools and settings (such as MSDeploy, Web Deploy, and references to w3wp.exe) are described in detail, and Windows-specific environment variables and behaviors are explained more thoroughly or before their Linux equivalents. In some cases, Linux options are mentioned as exceptions or afterthoughts, and Linux-specific examples or explanations are missing or less detailed.

Recommendations:

For every environment variable or feature, provide both Windows and Linux examples side by side, especially for file paths, default values, and behaviors.
Avoid presenting Windows as the default or primary platform; instead, use neutral language or alternate the order of Windows and Linux references.
Include Linux-native tools and deployment patterns (e.g., rsync, scp, tar) where Windows tools like MSDeploy or Web Deploy are mentioned.
Ensure that Linux-specific environment variables, behaviors, and troubleshooting steps are as detailed and prominent as their Windows counterparts.
Where platform-specific behaviors exist, clearly indicate them in a comparative table or section, rather than embedding Linux as an exception in Windows-focused text.
Add Linux/POSIX shell command examples (e.g., export, echo $VAR) where PowerShell or Windows command prompt examples are given.
Review and expand documentation for Linux container scenarios, ensuring parity in depth and clarity with Windows container documentation.

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 App Service apps, such as web server logging, detailed error messages, and failed request tracing, which are not available or not documented for Linux. Examples and explanations for advanced logging features are focused on Windows, with Linux instructions being brief and lacking equivalent depth. Additionally, Windows-specific tools and log formats (e.g., W3C, Log Parser) are mentioned without Linux alternatives.

Recommendations:

Provide equivalent, detailed instructions for enabling and accessing advanced logging features (such as web server logging, detailed error messages, and failed request tracing) for Linux and container-based App Service apps, or clearly state if these features are unavailable.
Include Linux-specific examples and tools for accessing and parsing logs, such as using tail, grep, or jq, and mention Linux log formats if they differ.
Where features are Windows-only, add explicit notes and suggest alternative troubleshooting or logging strategies for Linux users.
Balance the order of presentation so that Linux and Windows instructions are given equal prominence, or group them together for easy comparison.
Expand the 'Add log messages in code' section to include more Linux-relevant frameworks and languages, with code samples for each.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing Windows-specific tools (IIS, Procdump, SysInternals), focusing on .NET/ASP.NET examples, and providing PowerShell-based management guidance without Linux or cross-platform equivalents. The Kudu console is described in terms of PowerShell and DOS commands, and links and examples are often Windows-centric. There is a lack of Linux-specific troubleshooting steps, tools, or examples, despite Azure App Service supporting Linux-based apps.

Recommendations:

Provide equivalent Linux-based troubleshooting steps and examples, such as using Bash in Kudu, and referencing Linux log file locations.
Mention Linux-compatible tools for memory dumps and diagnostics (e.g., gcore, lsof, strace) alongside Procdump/SysInternals.
Include examples for managing and restarting apps using Azure CLI (which is cross-platform), not just Azure PowerShell.
Clarify which features or tools are available or behave differently on Linux-based App Service plans.
Add application diagnostics examples for non-.NET stacks (Node.js, Python, Java) and how to enable logging/tracing for those environments.
Balance references to Windows and Linux in both text and linked resources, ensuring parity in troubleshooting guidance.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Visual Studio Code (VS Code) is the only editor/IDE mentioned for local test running, and all GUI screenshots are from the Azure Portal, which is platform-agnostic but often associated with Windows workflows. There are no explicit Linux/macOS-specific instructions, terminal screenshots, or mentions of alternative editors or shells. The environment setup and CLI commands are generally cross-platform, but the documentation assumes familiarity with Windows-centric tools and patterns, especially in the 'Run your tests' and 'Set up your environment' sections. There are no Linux/macOS-specific troubleshooting tips, and the only editor extension referenced is for VS Code.

Recommendations:

Add explicit Linux/macOS instructions or notes where relevant, such as for environment variable setup, CLI usage, and file paths.
Include at least one example or screenshot using a Linux/macOS terminal or file explorer to demonstrate parity.
Mention alternative editors (such as JetBrains IDEs, Atom, or even Vim/Emacs) or at least clarify that the steps work in any editor, not just Visual Studio Code.
Provide troubleshooting tips or notes for common Linux/macOS issues (e.g., file permissions, line endings, shell differences).
Where screenshots are used, consider including at least one from a Linux or macOS environment to visually reinforce cross-platform support.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific concepts (such as registry keys, Windows services, and file paths) are often described in greater detail or appear first. Powershell and Windows file paths are used in examples and queries before Linux equivalents. The registry monitoring section is exclusively Windows-focused, and alerting examples prioritize Windows paths and services. Linux is supported and mentioned, but often as a secondary consideration, with fewer detailed examples or explanations.

Recommendations:

Provide Linux-specific examples and explanations alongside Windows ones, especially for alerting queries, file paths, and service/daemon monitoring.
Balance the order of presentation so Linux and Windows are treated equally (e.g., alternate which OS is mentioned first in tables and examples).
Expand the registry monitoring section to clarify that Linux does not have a direct equivalent, and offer guidance on monitoring Linux configuration files or similar artifacts.
Include Linux command-line examples (e.g., bash, systemctl) where Powershell or Windows commands are shown.
Ensure screenshots and UI walkthroughs show both Windows and Linux scenarios where applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes Windows-specific tools (setx, PowerShell) with detailed steps. Linux/macOS instructions are present but consistently listed after Windows, and less explanation is given for their environment variable persistence. There are no missing Linux examples, but the ordering and emphasis show a Windows-first bias.

Recommendations:

Present Linux/macOS and Windows instructions in parallel (side-by-side tabs or equal prominence), or list Linux/macOS first if usage data supports it.
Provide equal detail for Linux/macOS environment variable persistence (e.g., mention adding to ~/.bashrc or ~/.zshrc for permanence).
Avoid giving Windows tools (setx, PowerShell) more prominence or detail than their Linux/macOS equivalents.
Consider using tabbed code blocks for each OS to avoid implicit prioritization.
Explicitly state that all major platforms are supported and tested.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Azure CLI and PowerShell examples for configuring active geo-replication, but PowerShell (a Windows-centric tool) is given equal prominence to Azure CLI, and no explicit Linux shell or Bash examples are provided. The CLI examples use the Azure CLI, which is cross-platform, but there is no mention of Linux-specific considerations, nor are there Bash script samples or references to Linux tools. PowerShell is presented as a primary automation option, which may suggest a Windows bias.

Recommendations:

Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide example invocations in Bash or other common Linux shells.
Add a section or note for Linux users, highlighting any OS-specific considerations or prerequisites (such as installing Azure CLI on Linux).
If possible, provide Bash script examples for automation, or at least show the CLI commands in a Linux terminal context.
Clarify that PowerShell Core is cross-platform, but also acknowledge that many Linux users may prefer Bash or other shells.
Avoid presenting PowerShell as the only scripting/automation alternative to Azure CLI; mention Bash scripting as a peer option.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation demonstrates a moderate Windows bias. Windows-specific tools and patterns are mentioned prominently, such as recommending Windows Subsystem for Linux (WSL) as the primary way to use redis-cli on Windows, and referencing Windows Terminal. Azure PowerShell is listed alongside Azure CLI for retrieving cache keys, and in some places, Windows-specific instructions precede or are more detailed than Linux equivalents. While Linux is covered, Windows-centric approaches are emphasized, and native Linux workflows are sometimes only accessible via Windows (through WSL).

Recommendations:

Provide native redis-cli installation instructions for Windows (e.g., via pre-built binaries or third-party packages), not just via WSL.
When listing tools for retrieving cache keys, present Azure CLI (cross-platform) before Azure PowerShell (Windows-centric), or give equal prominence.
Avoid assuming Windows users must use WSL; clarify that redis-cli can be run natively on Linux, macOS, and (with some effort) Windows.
Where Windows-specific tools (like Windows Terminal) are mentioned, also mention Linux/macOS equivalents (e.g., GNOME Terminal, iTerm2).
Ensure that all example commands and workflows are presented in a cross-platform manner, and explicitly note any platform-specific differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation exhibits a mild Windows bias. In several places, Windows-specific tools, settings, and instructions are mentioned before their Linux equivalents, or Linux guidance is less detailed. Some CLI and deployment examples focus on Windows or mention Windows-specific options first. There are also areas where Linux-specific instructions are less prominent or absent, such as ReadyToRun guidance and debugging steps.

Recommendations:

Ensure all CLI and deployment instructions are provided for both Windows and Linux, with equal detail and prominence.
When listing platform-specific settings (e.g., netFrameworkVersion for Windows, linuxFxVersion for Linux), present them together or in parallel tabbed sections, not with Windows first.
For performance and publishing guidance (e.g., ReadyToRun, runtime identifiers), include explicit Linux examples and clarify any differences or limitations.
In debugging and development sections, provide Linux-specific instructions and troubleshooting steps, not just Windows/Visual Studio workflows.
When referencing tools (e.g., Azure CLI, PowerShell), ensure Linux and cross-platform tools are given equal or greater prominence compared to Windows-only tools.
Review all code and command snippets to ensure parity between Windows and Linux, including file paths, environment variables, and shell syntax.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. It assumes the use of Visual Studio Code and Azurite (which are cross-platform), but key steps and tooling are presented in a way that prioritizes or assumes Windows environments. For example, instructions for starting Azurite and running/debugging the function app use Visual Studio Code commands and function keys (e.g., F5, Ctrl+C) without mentioning terminal alternatives or Linux/macOS-specific workflows. There are no explicit Linux/macOS shell commands or troubleshooting notes for non-Windows users. The documentation also references Core Tools and Azurite without clarifying installation or usage differences across platforms.

Recommendations:

Provide explicit instructions or notes for Linux/macOS users, including alternative commands for starting Azurite and running/debugging the function app (e.g., using terminal commands like `func start` or `azurite` in bash/zsh).
Clarify that Visual Studio Code, Azurite, and Azure Functions Core Tools are cross-platform, and provide installation links or steps for Linux/macOS.
When referencing keyboard shortcuts (e.g., F5, Ctrl+C), add notes about how these may differ on macOS (e.g., Cmd+C instead of Ctrl+C) or how to perform the same actions in the terminal.
Include troubleshooting tips or common issues for Linux/macOS environments, such as permissions, path differences, or dependency installation.
Ensure that all code and configuration examples (such as file paths, environment variables, and CLI commands) are valid for both Windows and Linux/macOS users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides both Bash and Windows CMD examples for most CLI operations, but consistently lists Windows CMD tabs after Bash. However, there is a subtle bias in that some sections (such as the initial project scaffolding and logging) present Bash and CMD examples, but do not mention Linux-specific tools or patterns beyond Bash. There are no explicit PowerShell examples, but the presence of CMD and Bash only may leave out users of other shells (e.g., zsh, fish) or those on macOS. The documentation does not provide Linux-specific troubleshooting, nor does it mention any Linux-specific behaviors or differences. The Java version support table lists Windows before Linux, and the default Java version is described in terms of the Maven archetype, which is platform-agnostic. Overall, the bias is mild, but there is a slight preference for Windows-first ordering and a lack of Linux-specific guidance.

Recommendations:

Ensure that all CLI examples explicitly mention compatibility with Linux/macOS as well as Windows, and consider including a note about shell compatibility (e.g., Bash, zsh, fish).
Wherever possible, add Linux/macOS-specific troubleshooting tips or notes, especially for environment variables, file paths, and permissions.
In tables and lists, alternate or randomize the order of Windows and Linux to avoid always listing Windows first.
If there are any differences in behavior or requirements between Windows and Linux (e.g., file system case sensitivity, path separators), call these out explicitly.
Consider adding a section or appendix summarizing any known Linux/macOS-specific issues or best practices for Java Azure Functions development.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a mild Windows bias, particularly in its developer guidance and example sections. PowerShell is highlighted in notes and examples, with explicit references to the Azure PowerShell Az module and AzureRM, and PowerShell cmdlets are given as a primary method for querying endpoints. Although Azure CLI is also mentioned, PowerShell receives more detailed attention and is referenced first in some cases. There is a lack of explicit Linux or Bash shell examples, and Windows-centric tools and workflows (such as Visual Studio and PowerShell) are referenced without Linux alternatives.

Recommendations:

Provide Bash/Linux shell equivalents for all PowerShell examples, especially for Azure CLI commands.
When referencing PowerShell, ensure Azure CLI (with Bash syntax) is presented with equal prominence and detail.
Include explicit guidance for Linux/macOS users, such as using Bash, zsh, or other common shells.
When mentioning Visual Studio or other Windows-specific tools, also mention cross-platform or Linux-friendly alternatives (e.g., VS Code, JetBrains Rider).
Review all code snippets and notes to ensure parity between Windows and Linux development environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias primarily through the exclusive use of Windows-specific links and terminology. For example, the link to 'Create a PPG using the Azure portal' points to a Windows-specific path (/azure/virtual-machines/windows/proximity-placement-groups-portal), with no mention of Linux equivalents. There are no Linux-specific instructions, examples, or references, and the documentation does not clarify whether the described procedures or tools are equally applicable to Linux-based SAP HANA deployments. This may lead Linux users to feel unsupported or uncertain about parity.

Recommendations:

Provide parallel links and instructions for both Windows and Linux environments, especially for tasks like creating proximity placement groups (PPGs). For example, include a link to /azure/virtual-machines/linux/proximity-placement-groups-portal alongside the Windows link.
Explicitly state when procedures are OS-agnostic or, if there are differences, provide clear Linux-specific guidance.
Include Linux-based terminology and examples where relevant (e.g., referencing Linux VMs, Linux command-line tools, or SAP HANA on Linux best practices).
Review all cross-references and ensure that Linux users are not directed only to Windows-centric documentation.
Add a section or note clarifying support and best practices for SAP HANA deployments on Linux, which is the most common OS for SAP HANA.

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 (MMC, Windows SMB client), without mentioning or providing equivalent Linux methods. The only client-side instructions for access control and share management are Windows-specific, and there are no Linux or cross-platform alternatives or examples. Additionally, Windows terminology and tools are referenced first and exclusively.

Recommendations:

Add instructions for managing SMB permissions and shares from Linux clients, such as using the 'smbclient' or 'smbcacls' tools.
Include examples of mounting and accessing SMB shares from Linux systems, referencing relevant commands (e.g., 'mount -t cifs', 'smbclient').
Provide guidance on setting file and share permissions from non-Windows environments, or clarify any limitations.
Ensure that references to client-side management tools include both Windows and Linux options, or explicitly state if certain operations are only possible from Windows.
Where screenshots or step-by-step instructions are given for Windows, consider adding parallel Linux examples or links to relevant Linux documentation.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias primarily in the registration steps for enabling cool access features. All command-line examples use Azure PowerShell cmdlets, which are most familiar to Windows users, and these are presented before mentioning Azure CLI alternatives. There are no explicit Linux/Unix shell examples, and the Azure CLI commands are only referenced in text, not shown as full command blocks. The UI instructions also use Windows-centric terminology (e.g., 'right-click'), which may not be as intuitive for Linux users.

Recommendations:

Provide full Azure CLI command examples (e.g., 'az feature register ...') alongside PowerShell, formatted as code blocks, not just referenced in text.
When listing command-line options, present Azure CLI (cross-platform) examples before or alongside PowerShell to avoid Windows-first bias.
Clarify that both Azure PowerShell and Azure CLI are cross-platform, but that Azure CLI is often preferred on Linux/macOS.
Replace or supplement 'right-click' UI instructions with alternatives suitable for non-Windows environments (e.g., 'select the context menu for the item').
Explicitly mention that all steps can be performed from Linux/macOS as well as Windows, and provide any necessary prerequisites or environment notes for non-Windows users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing detailed, step-by-step instructions for setting SACLs using Windows GUI tools, while Linux/NFS instructions are minimal and refer users to another page. The (commented-out) feature registration example uses Azure PowerShell first, with Azure CLI only mentioned secondarily. There are no Linux command-line examples for setting audit ACEs or SACLs, and Windows administration hosts and tools are referenced explicitly and in detail.

Recommendations:

Provide equivalent, step-by-step instructions for setting Audit ACEs on NFSv4.1 volumes from a Linux client, including example commands (e.g., using nfs4_setfacl).
When describing feature registration, present Azure CLI and PowerShell examples side-by-side or in parallel, not with PowerShell first.
Avoid referring to 'Windows administration host' exclusively; mention 'Linux administration host' or 'Linux client' where appropriate.
Include screenshots or command-line examples for Linux-based workflows, not just Windows GUI.
Ensure that all procedures (enabling/disabling logs, setting ACLs) have both Windows and Linux instructions where applicable.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a mild Windows bias by listing PowerShell as a primary tool for snapshot management, mentioning it alongside Azure CLI and REST API, but not providing any Linux/Unix shell or scripting examples. The ordering of tools often places PowerShell before or alongside cross-platform options, and there are no explicit Linux/Unix command-line examples or references to Linux-native tooling or scripting patterns. This may make Linux users feel less directly supported or require them to infer how to use the service from Windows-centric instructions.

Recommendations:

Add explicit Linux/Unix shell (bash) examples for snapshot management using Azure CLI, demonstrating common Linux scripting patterns.
When listing tools, alternate or randomize the order of Azure CLI and PowerShell, or list Azure CLI first to reflect its cross-platform nature.
Include references or links to Linux/Unix automation and scripting guides for Azure NetApp Files.
Provide sample scripts or walkthroughs for both Windows (PowerShell) and Linux (bash) environments.
Clarify that all features are available and supported on both Windows and Linux clients, and highlight any OS-specific considerations where relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by prioritizing Windows/SMB and Active Directory scenarios, referencing Windows-specific tools and features (e.g., Group Policy, registry settings), and providing detailed explanations for Windows-centric encryption mechanisms. Linux/NFS examples are present but less detailed, and there are no explicit Linux command-line or configuration examples. LDAP and Kerberos sections also focus on Microsoft Active Directory, with little mention of non-Windows LDAP/Kerberos environments.

Recommendations:

Provide parallel Linux/NFS examples and configuration steps where Windows/SMB examples are given, including relevant Linux commands or configuration file snippets.
When discussing LDAP, include examples and notes for common Linux LDAP servers (e.g., OpenLDAP) and clients, not just Active Directory.
Balance the order of presentation: introduce NFS/Linux scenarios before or alongside SMB/Windows scenarios, rather than always after.
Reference Linux tools (e.g., kinit, nfs-utils, sssd, ldap-utils) and configuration files (e.g., /etc/krb5.conf, /etc/nfsmount.conf) where appropriate.
Clarify which features and encryption options are available and supported for both Windows and Linux clients, and note any differences.
Add troubleshooting and best practices sections for Linux environments, similar to the Windows/SMB performance and security notes.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation provides only PowerShell/PowerCLI examples for verifying DNS resolution, with no equivalent Linux or cross-platform CLI examples. The use of PowerShell cmdlets is presented as the primary (and only) method for interacting with the NSX-T Policy API, and there are no references to Linux-native tools or instructions for users on non-Windows platforms.

Recommendations:

Provide equivalent Linux-based examples for verifying DNS resolution, such as using curl, wget, or direct API calls with tools like curl or httpie.
Include examples using the NSX-T Policy API via REST calls, demonstrating how to perform the same operations from Linux/macOS or any platform.
Mention and document the use of native Linux tools (e.g., dig, nslookup) for DNS verification, especially since the raw answer in the PowerShell example references DiG output.
Ensure that any scripting or automation steps are shown in both PowerShell and Bash (or other common shells) to support cross-platform administrators.
Clarify in the documentation that PowerCLI is not required, and provide alternative methods for users who do not have access to Windows environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation prioritizes Windows-centric tools and workflows. Azure PowerShell is presented as the primary command-line automation example, with detailed steps and multiple commands, while Azure CLI (cross-platform) is only mentioned later and with less detail. There are no Linux-specific examples or references to Linux environments, and the PowerShell approach is described before the CLI, reinforcing a Windows-first perspective.

Recommendations:

Provide Azure CLI examples alongside or before PowerShell examples, as Azure CLI is cross-platform and widely used on Linux and macOS.
Explicitly mention that Azure CLI commands can be run on Linux, macOS, and Windows, and provide any necessary prerequisites or installation links for non-Windows platforms.
If scripting is required, include bash script examples or note how to adapt the process for Linux shells.
Balance the order of presentation so that cross-platform tools (like Azure CLI) are not always listed after Windows-specific tools.
Add a note clarifying that all steps can be performed from Linux or macOS using the Azure CLI, and provide troubleshooting tips for those environments if needed.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates Windows bias by providing restore scenarios and encrypted VM restore instructions that reference only Windows-specific tools and documentation. In the 'Restore an encrypted VM' scenario, only Windows VM encryption links and PowerShell are mentioned, with no mention of Linux VM encryption or restore processes. There are no Linux-specific examples or references, and Windows tools and patterns are presented exclusively.

Recommendations:

Add equivalent restore instructions and documentation links for Linux VMs, especially for encrypted Linux VM restore scenarios.
Include examples or references for restoring Linux VMs, such as using Azure CLI or relevant Linux tools, alongside PowerShell.
Ensure that both Windows and Linux scenarios are covered equally in tables and explanations, or clearly indicate when a scenario is Windows-only.
Provide parity in documentation links, such as linking to both Windows and Linux disk encryption documentation where appropriate.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation is heavily focused on Windows environments, specifically Windows Server-based Active Directory. All examples, tools, and procedures are Windows-centric, with explicit use of Windows tools (e.g., PowerShell, ntdsutil.exe) and no mention of Linux-based domain controllers or cross-platform scenarios. Linux is not referenced at all, and all backup/restore instructions assume a Windows operating system.

Recommendations:

Acknowledge that Active Directory Domain Services (AD DS) is a Windows technology, but clarify whether Azure Backup supports Samba/LDAP-based domain controllers on Linux (if applicable).
If Linux-based domain controllers (e.g., Samba AD) are supported, provide equivalent backup and restore guidance, including Linux command-line examples and tools.
Where PowerShell scripts are provided, offer bash or shell script equivalents if Linux is supported.
Explicitly state in the prerequisites or introduction that the procedures apply only to Windows Server-based AD DS if Linux is not supported, to avoid confusion.
Include a comparison table or section outlining backup/restore options for both Windows and Linux environments, even if only to clarify limitations.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page focuses on assessing .NET web apps for migration to Azure App Service but does not mention Linux-based .NET hosting, Linux tools, or provide any Linux-specific guidance or examples. All references and linked resources implicitly assume a Windows/IIS/ASP.NET context, with no parity for Linux-based .NET Core or ASP.NET Core apps.

Recommendations:

Explicitly mention that both Windows and Linux-based .NET web apps can be assessed and migrated, if supported.
Include examples or guidance for assessing .NET Core/ASP.NET Core apps running on Linux (e.g., on Apache, Nginx, or Kestrel).
Reference Linux-compatible assessment tools or scripts, if available.
Clarify any differences in assessment or migration steps for Linux-hosted .NET apps.
Add links to documentation or tutorials specifically covering Linux scenarios.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-first bias by referencing the Windows deployment path (C:\home\site\wwwroot) before mentioning Linux, and only provides a Linux-specific note as an aside. There are no Linux-specific examples or screenshots, and the Linux path is only mentioned in a note, not in the main instructions or examples.

Recommendations:

Present both Windows and Linux file paths side by side in the main instructions, not just in a note.
Include explicit Linux examples (e.g., using /home/site/wwwroot/auth.json) in step-by-step instructions and configuration samples.
Clarify platform-specific differences early in the document, ideally in a dedicated section or table.
Where possible, provide parity in screenshots, CLI commands, and file path references for both Windows and Linux environments.

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 and configuration. The Windows section lacks command-line or PowerShell examples, but the Linux section provides detailed CLI instructions and examples. There is a slight 'windows_first' ordering bias and a lack of parity in example depth for Windows (no CLI/PowerShell examples), but the Linux section is actually more detailed. There is no evidence of 'powershell_heavy' or 'windows_tools' bias, and Linux is not omitted, but the ordering and lack of Windows CLI parity are notable.

Recommendations:

Provide equivalent command-line or PowerShell examples for Windows containers, or explicitly state if such access is not supported.
Clarify in both sections the supported SSH access methods (browser, CLI, etc.) for each OS to avoid confusion.
Consider presenting Linux and Windows instructions in parallel or with equal prominence, rather than always listing Windows first.
If CLI access is not available for Windows containers, explain why and offer any available alternatives.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation references a Python (Flask) app and is generally cross-platform, but there is evidence of Windows bias. The quickstart link in the prerequisites uses the 'windows' tab by default, and there are no explicit Linux or macOS command-line examples or deployment instructions. All environment variable setup and deployment instructions are described in terms of the Azure Portal or App Service, with no mention of Linux-specific workflows (e.g., bash commands, Linux file paths, or systemd services). There are no PowerShell-specific commands, but the absence of Linux-specific examples and the default to Windows in quickstart links indicate a subtle Windows-first approach.

Recommendations:

Ensure that quickstart and sample links default to a neutral or Linux tab, or provide parallel links for both Windows and Linux.
Add explicit Linux/macOS command-line examples for setting environment variables, running the app, and deploying (e.g., using bash, export commands, systemd, or gunicorn).
Include Linux-specific notes or troubleshooting tips for common issues (such as file permissions or case sensitivity).
When referencing the Azure Portal, also mention equivalent CLI commands (az cli) for Linux users.
Review all code snippets and instructions to ensure they are platform-agnostic or provide both Windows and Linux variants where differences exist.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation assumes usage of GitHub Codespaces and Azure App Service, which are cross-platform, but all terminal instructions and environment references are generic or implicitly Windows/.NET-centric. There are no explicit Linux or macOS command-line examples, nor any mention of Linux-specific tools or deployment patterns. The workflow and code samples are focused on .NET and Azure, which are cross-platform, but the documentation does not acknowledge or provide guidance for Linux users (e.g., local development, deployment, or troubleshooting on Linux).

Recommendations:

Explicitly mention that all terminal commands work on Windows, Linux, and macOS, and clarify any OS-specific differences if they exist.
Provide example commands for common Linux shells (e.g., bash/zsh) where relevant, especially for deployment or environment variable management.
Include notes or links for Linux/macOS users on how to run and test .NET apps locally (e.g., using dotnet CLI on Ubuntu/macOS).
If using Codespaces, clarify that it provides a Linux-based environment, and mention how to replicate the setup locally on Linux.
Add troubleshooting tips or references for Linux users, such as installing .NET SDK or handling file permissions.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a subtle Windows bias by referencing Visual Studio Credential as the first and only concrete example of a development environment, which is primarily a Windows tool. There are no explicit code examples or command-line instructions, but the mention of Visual Studio as the default development context and the lack of Linux-specific or cross-platform tooling references (such as VS Code, CLI, or Bash) indicate a Windows-first perspective. No Linux or cross-platform development environments or workflows are mentioned.

Recommendations:

Include examples that reference cross-platform development environments, such as Visual Studio Code, Azure CLI, or JetBrains Rider.
When mentioning authentication methods, provide parity by listing Linux/macOS-friendly options (e.g., Azure CLI Credential, EnvironmentCredential) alongside Visual Studio Credential.
Explicitly state that the instructions apply to all platforms and, where relevant, provide platform-specific notes or examples.
Add a section or note on how to perform role assignments using Azure CLI or Azure PowerShell, both of which are cross-platform.
Avoid assuming Visual Studio as the default development environment; mention it as one of several options.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates environment-based configuration using Azure App Configuration in the context of an ASP.NET Core app. It references modifying 'launchSettings.json' and running the app with 'dotnet run', which are cross-platform, but the workflow and examples implicitly assume a Visual Studio/Windows development environment. There are no explicit instructions or examples for Linux or macOS users, such as using environment variables via the shell or running the app outside of Visual Studio tooling.

Recommendations:

Add explicit instructions for setting environment variables on Linux/macOS (e.g., using 'export ASPNETCORE_ENVIRONMENT=Production' in the shell) and running the app from the command line.
Mention that 'launchSettings.json' is primarily used by Visual Studio and that on Linux/macOS or in CI/CD, environment variables are typically set via the shell or pipeline configuration.
Provide a Linux/macOS example alongside the 'launchSettings.json' example to ensure parity.
Clarify that the 'dotnet' CLI commands are cross-platform, and provide any OS-specific notes if behavior differs.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page generally maintains parity between Linux and Windows by providing separate, clearly labeled sections for each platform's solutions. However, there is evidence of subtle Windows bias: in several multi-platform solution areas (such as SAP NetWeaver), Windows is listed before Linux, and Windows-specific tools (like DFS Namespaces and SMB) are mentioned explicitly, sometimes without equivalent Linux alternatives or with less detail. Some sections (e.g., Virtual Desktop Infrastructure) focus almost exclusively on Windows-based solutions, with little or no mention of Linux-based VDI options.

Recommendations:

Ensure that in all multi-platform solution sections (e.g., SAP NetWeaver), Linux and Windows are presented with equal prominence, and alternate the order in which they are listed or use a neutral grouping.
When referencing Windows-specific tools (e.g., DFS Namespaces, SMB), also mention and provide links to equivalent Linux technologies (e.g., NFS, autofs, Linux-based DFS alternatives) where applicable.
Expand the Virtual Desktop Infrastructure section to include Linux-based VDI solutions or explicitly state if such solutions are not supported, to avoid the impression of omission.
For each reference architecture or solution, provide both Windows and Linux implementation examples or case studies where possible.
Review the language throughout the document to ensure that neither platform is implied as the default or primary use case.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation page demonstrates a mild Windows bias by providing an Azure PowerShell example first for checking feature registration, with the Azure CLI (cross-platform) option mentioned only secondarily and without a concrete example. No Linux-specific tools or shell commands are shown, and the only command-line example is PowerShell. However, the page does reference Linux in the context of performance benchmarks, and does not mention any Windows-only tools or patterns beyond the PowerShell example.

Recommendations:

Provide both Azure PowerShell and Azure CLI examples side by side for feature registration, with equal prominence.
Include explicit Linux shell (bash) command examples where relevant, especially for Azure CLI usage.
Avoid presenting Windows-specific tools or commands first; instead, present cross-platform options or alternate between them.
Where possible, clarify that Azure CLI commands work on all platforms (Windows, Linux, macOS).
Consider adding a note or section for Linux administrators, especially in areas where platform-specific steps may differ.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates bias by exclusively referencing the Azure portal (a web GUI) and omitting any command-line examples, such as Azure CLI or PowerShell. There are no Linux-specific instructions or examples, nor is there mention of cross-platform tools. The only tool-based guidance refers to the Azure portal and a 'Migration Operations' tool, which are typically more familiar to Windows users. There is no parity for users who prefer or require command-line or Linux-native workflows.

Recommendations:

Add Azure CLI examples for moving App Service resources, as the CLI is cross-platform and widely used on Linux.
If PowerShell examples are provided elsewhere, ensure Azure CLI equivalents are present and given equal prominence.
Explicitly mention that all operations can be performed from Linux, macOS, or Windows using the Azure CLI.
Include screenshots or terminal output from Linux environments where relevant.
Reference Linux-friendly tools and workflows alongside portal-based instructions.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation does not provide any platform-specific command-line examples, but it implicitly assumes the use of traditional enterprise DNS servers (such as Windows Server DNS) for on-premises DNS configuration and conditional forwarding. There are no Linux/BIND examples or references, and the instructions for creating forwarders and zones are generic but align with Windows DNS management patterns. No Linux-native DNS tools or configuration steps are mentioned.

Recommendations:

Add explicit examples for configuring DNS forwarders and zones using Linux-based DNS servers (e.g., BIND/named.conf).
Include sample configuration snippets for both Windows Server DNS and Linux/BIND to ensure parity.
Mention common Linux DNS tools (such as BIND, dnsmasq, or Unbound) alongside Windows DNS Server when referring to on-premises DNS solutions.
Clarify that the steps apply to any DNS server and provide links or references to both Windows and Linux DNS documentation for creating forwarders and zones.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation exclusively describes role assignment using the Azure Portal GUI, which is typically accessed via a web browser on Windows systems. There are no examples or instructions for performing these tasks via command-line tools such as Azure CLI or PowerShell, nor are there any Linux-specific instructions or parity for automation or scripting. This approach implicitly favors Windows/GUI workflows and omits guidance for Linux users or those preferring CLI-based automation.

Recommendations:

Add equivalent instructions for performing role assignments using Azure CLI, which is cross-platform and works on Linux, macOS, and Windows.
Include PowerShell examples if desired, but ensure Azure CLI examples are presented first or alongside them.
Explicitly mention that these tasks can be performed from any OS using the Azure CLI or REST API, and provide sample commands.
Consider adding a table or section comparing GUI, PowerShell, and Azure CLI approaches for maximum inclusivity.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page lists .NET and ASP.NET Core providers first, which are traditionally Windows-centric technologies, before mentioning Java, Python, JavaScript, and Go providers. There is no explicit mention of Windows-only tools or PowerShell, nor are there missing Linux examples or exclusive references to Windows patterns. However, the ordering of platforms and the focus on .NET/ASP.NET may subtly prioritize Windows environments.

Recommendations:

Reorder the provider libraries table to group by language family or popularity, or rotate the order periodically to avoid implicit prioritization.
Explicitly mention cross-platform compatibility for .NET Core and ASP.NET Core providers, highlighting their support on Linux and macOS as well as Windows.
Add a brief section or note clarifying that all listed providers are supported on both Windows and Linux (where applicable), and provide links to Linux-specific setup guides if available.
Ensure that any future examples or walkthroughs include both Windows and Linux command-line instructions where relevant.

Create pull request

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