Scan Details - Linux-first Docs for Azure

1489

Pages Scanned

58

Pages Flagged

1489

Changed Pages

3.9%

% Pages Flagged

Scan Information

Started At: 2025-08-07 00:00:07

Finished At: 2025-08-07 00:32:50

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a Windows bias by providing only Azure PowerShell examples for command-line operations, with no mention of Azure CLI (which is cross-platform and commonly used on Linux/macOS). Instructions for installing and using PowerShell are given, but there are no equivalent steps or code samples for Linux users. The focus on PowerShell and lack of Azure CLI or Bash examples may disadvantage users on non-Windows platforms.

Recommendations:

Add Azure CLI examples alongside PowerShell for all command-line operations, as Azure CLI is cross-platform and widely used on Linux and macOS.
When referencing installation steps for command-line tools, include both PowerShell and Azure CLI, with links to their respective installation guides for Windows, Linux, and macOS.
Ensure that code blocks and instructions are labeled clearly for both PowerShell and CLI/Bash, and provide parity in the depth and detail of examples.
Consider restructuring sections so that cross-platform tools (like Azure CLI) are presented before or alongside Windows-specific tools (like PowerShell), to avoid a 'Windows-first' impression.
Explicitly mention that all operations can be performed from Linux, macOS, or Windows, and provide any OS-specific notes where necessary.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation provides both Azure CLI and PowerShell examples for programmatic management, but PowerShell is given equal or greater prominence, and is often shown before or alongside CLI. PowerShell is a Windows-centric tool, and its inclusion as a primary example may indicate a bias toward Windows users. There are no explicit Linux shell (bash) or scripting examples, and no mention of Linux-specific tools or workflows. The use of PowerShell and references to it as a main automation method may disadvantage Linux-first users, despite Azure CLI being cross-platform.

Recommendations:

Prioritize Azure CLI examples before PowerShell, as CLI is cross-platform and more familiar to Linux users.
Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and can be run in native terminals.
Where PowerShell examples are given, provide equivalent bash shell script examples for Linux users.
Clarify that Cloud Shell supports both Bash and PowerShell, and show how to select Bash.
Avoid referring to PowerShell as the default or primary automation tool; instead, present it as an option alongside CLI.
Add a section or callout for Linux users, highlighting any nuances or best practices for managing access restrictions from Linux environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates Windows bias primarily in the section addressing the identification of Azure Traffic Manager endpoints. It exclusively recommends and provides instructions for a PowerShell script (a Windows-centric tool) to identify non-Azure endpoints, without mentioning or providing alternatives for Linux/macOS users (such as Azure CLI, Bash, or cross-platform scripts). Additionally, the step-by-step instructions for running the script assume a PowerShell environment, and there is no guidance for users on other operating systems. In other sections, while Azure CLI and REST API are referenced, there are no explicit shell or command-line examples, and the only explicit script-based example is Windows/PowerShell.

Recommendations:

Provide equivalent Azure CLI or Bash scripts for identifying Traffic Manager endpoints, or at least mention how Linux/macOS users can achieve the same result.
When referencing scripts or tools, indicate their platform compatibility and, where possible, offer cross-platform alternatives.
Include explicit instructions or examples for Linux/macOS users alongside PowerShell/Windows instructions.
If a PowerShell script is the only available tool, clarify how it can be run on Linux/macOS (e.g., using PowerShell Core), or provide a note about its limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows-first bias by providing PowerShell automation examples and referencing Azure PowerShell scripts, while Linux-specific automation (such as Bash or shell scripting) is not shown. The 'Automate with scripts' section lists Azure CLI and PowerShell, but the PowerShell example is shown inline, whereas the CLI example is only linked. There are no explicit Linux command-line or scripting examples, and no mention of Linux tools or workflows for certificate management. The only Linux-specific reference is a link to a Node.js configuration guide, which is not prominent.

Recommendations:

Provide explicit Bash or shell script examples for Linux users in the 'Automate with scripts' section, similar to the PowerShell example.
Ensure Azure CLI examples are shown inline, not just as links, to give Linux users parity with PowerShell users.
Mention common Linux tools (such as OpenSSL) for certificate management and provide example commands for uploading or converting certificates.
Balance references to platform-specific guides (e.g., include links to Linux, macOS, and Windows guides for language-specific configuration).
Review screenshots and UI instructions to ensure they are not Windows-centric (e.g., avoid showing only Windows browser UIs if possible).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by providing PowerShell examples alongside Azure CLI, mentioning Windows-specific support (e.g., outbound IPv6), and omitting explicit Linux shell or Bash examples where appropriate. Windows/Powershell commands are presented before or alongside CLI, but there are no Linux-specific instructions or clarifications, and Windows-specific features are highlighted without Linux parity.

Recommendations:

For every PowerShell example, provide an equivalent Bash/Linux shell example, especially for commands that can be run locally (e.g., using curl, dig, or nslookup).
When listing command-line examples, present Azure CLI (cross-platform) first, and PowerShell second, or clarify that both are supported equally.
Where features are Windows-only (such as outbound IPv6), clearly state the Linux status and provide alternative guidance or a roadmap for Linux users.
Include explicit Linux/Bash instructions for common administrative tasks, such as querying properties with jq or using REST APIs directly.
If referencing tools or environments (like Cloud Shell), clarify that both Bash and PowerShell are available and show examples for both.
Review all screenshots and UI instructions to ensure they are not Windows-centric (e.g., avoid showing only Windows-style file paths or dialogs).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation page demonstrates a Windows bias by prioritizing Windows-centric tools and workflows (e.g., Visual Studio deployment to Windows App Service) and omitting explicit Linux deployment examples or Linux-specific tooling. References to Visual Studio and Kudu are made without clarifying Linux compatibility or providing equivalent Linux-first guidance. There is no mention of Linux App Service or cross-platform deployment nuances.

Recommendations:

Add explicit examples and guidance for deploying WebJobs to Linux-based App Service plans, including any differences in supported runtimes, file types, or deployment steps.
Include Linux-friendly deployment workflows, such as using Azure CLI, GitHub Actions, or zip deployment from a Linux environment, and clarify any platform-specific considerations.
Mention cross-platform editors and tools (e.g., VS Code, command-line tools) alongside Visual Studio, and avoid implying that Visual Studio is the primary or only supported tool.
Clarify Kudu's availability and feature parity on Linux App Service plans, or provide alternative troubleshooting/monitoring guidance for Linux.
Ensure that all examples and references are inclusive of both Windows and Linux environments, or clearly indicate when a feature or workflow is Windows-specific.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

⚠️ windows_tools

Summary:

The documentation demonstrates a significant Windows bias. PowerShell is the only scripting example provided for automating Key Vault integration, with no equivalent Azure CLI or Bash/Linux shell examples. References to automation and scripting consistently mention PowerShell first or exclusively. There are no Linux-specific instructions or parity in command-line examples, and the 'Next steps' section links only to a PowerShell-based guide.

Recommendations:

Provide equivalent Azure CLI examples alongside PowerShell for all automation steps, especially for referencing Key Vault secrets and configuring Application Gateway.
Include Bash or Linux shell scripting examples where relevant, to ensure parity for Linux users.
When mentioning automation tools (PowerShell, CLI, ARM templates, Bicep), list them in a neutral or rotating order, not always with PowerShell first.
Add a 'Next steps' link to an Azure CLI-based guide for configuring TLS termination with Key Vault certificates.
Explicitly state that all steps can be performed on both Windows and Linux, and clarify any OS-specific considerations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation provides installation instructions for the required NuGet packages using both the .NET Core CLI and the Visual Studio Package Manager Console (PowerShell-based), but it lists the Visual Studio/PowerShell method second. However, there is a subtle bias in that the Package Manager Console is a Windows/Visual Studio-specific tool, and there is no explicit mention of Linux or macOS environments beyond the .NET Core CLI. The documentation does not provide Linux-specific guidance or examples, nor does it mention cross-platform editors or tools outside of Visual Studio.

Recommendations:

Explicitly mention that the .NET Core CLI commands work on Windows, Linux, and macOS, and recommend it as the primary cross-platform installation method.
Add instructions for installing the packages using other cross-platform editors (e.g., Visual Studio Code) or via editing the project file directly.
Clarify that the Package Manager Console is specific to Visual Studio on Windows, and suggest alternatives for Linux/macOS users.
Consider providing a table or section that summarizes installation options for different operating systems and development environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias, particularly in the Helm installation section, where Windows instructions (including a PowerShell/winget example) are presented before Linux instructions. The use of Windows-specific tooling (winget) is highlighted, while the Linux section is less detailed and lacks parity in installation options. However, most core deployment and management commands use cross-platform tools (Azure CLI, Helm, kubectl) and Bash syntax, which are suitable for both Linux and Windows environments.

Recommendations:

Present Linux and Windows instructions in parallel or with equal prominence, rather than listing Windows first.
For Helm installation, provide equivalent detail and multiple installation options for both Linux and Windows (e.g., package managers like apt, yum, snap for Linux, and choco for Windows).
Avoid highlighting Windows-specific tools (like winget) without mentioning Linux equivalents (such as apt, yum, or snap).
Where possible, use cross-platform installation instructions or clearly indicate which commands are OS-specific.
Consider including macOS instructions for broader parity.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell in the 'Next steps' section for creating an autoscaling, zone redundant application gateway. There are no equivalent instructions or links for Linux users (e.g., using Azure CLI or ARM templates), and the only explicit tooling example is PowerShell, which is most commonly associated with Windows environments.

Recommendations:

Add equivalent Azure CLI (az) tutorials and references for Linux/macOS users alongside PowerShell instructions.
Include ARM/Bicep template examples for cross-platform automation.
In the 'Next steps' section, ensure that links to Linux-friendly tools (Azure CLI, REST API) are presented with equal prominence as PowerShell.
Explicitly mention that the features and configuration steps are platform-agnostic where possible, and clarify when a tool is available on multiple platforms.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation page does not provide any OS-specific command-line examples, but the only linked tutorial for further configuration uses PowerShell, which is Windows-centric. There is no mention of Linux tools, Bash, or cross-platform CLI alternatives, and the documentation implicitly assumes a Windows-first approach by directing users to a PowerShell-based guide.

Recommendations:

Include links to equivalent tutorials using Azure CLI (az), which is cross-platform and works on both Linux and Windows.
Explicitly mention that configuration can be performed using Azure CLI, ARM templates, or the Azure portal, not just PowerShell.
Provide example commands or references for both PowerShell and Bash/Azure CLI where relevant.
Ensure that next steps and further reading sections offer parity between Windows and Linux users by linking to platform-agnostic or platform-specific guides as appropriate.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by referencing PowerShell and CLI as the primary configuration tools, with PowerShell mentioned first and linked as the main method for configuring TLS policies. There are no explicit Linux or Bash examples, and the 'Next steps' section only links to a PowerShell-based guide. The documentation does not mention or provide parity for Linux-native tools or workflows.

Recommendations:

Provide explicit Bash/Azure CLI examples alongside or before PowerShell examples for configuring TLS policies.
In the 'Next steps' section, include links to both PowerShell and Bash/CLI documentation for configuring TLS policies.
Avoid referencing PowerShell as the sole or primary method; instead, present both Windows and Linux workflows equally.
Wherever configuration is discussed, clarify that Azure CLI is cross-platform and provide sample commands for both Windows (PowerShell) and Linux (Bash).
If portal or REST API methods are available, mention them as platform-neutral alternatives.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation page demonstrates a Windows bias by primarily referencing Azure PowerShell scripts and commands for migration and preview registration/unregistration tasks. The examples and instructions for registering/unregistering the Basic SKU preview use PowerShell cmdlets (e.g., Set-AzContext, Register-AzProviderFeature), and the migration script is only mentioned as being available in the PowerShell Gallery. There are no equivalent Bash, Azure CLI (cross-platform), or Linux-native instructions provided. Additionally, in the 'Next steps' section, the tutorial linked is specifically for PowerShell, and PowerShell is mentioned before Azure CLI or portal options.

Recommendations:

Provide equivalent Azure CLI (az) commands for all PowerShell-based instructions, especially for registration, unregistration, and migration tasks.
When referencing scripts or automation, mention both PowerShell and Bash/CLI options, or clarify if a cross-platform solution is available.
In 'Next steps' and similar sections, list Azure CLI and portal options before or alongside PowerShell to avoid the impression that Windows tools are preferred.
If migration scripts are only available in PowerShell, note this limitation explicitly and provide guidance or alternatives for Linux/macOS users.
Consider including example commands or scripts that are platform-agnostic or specify which platforms are supported for each example.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation demonstrates a Windows bias by providing PowerShell as the only CLI example for checking settings, exclusively recommending Fiddler (a Windows-centric tool) for network debugging, and referencing Windows installation patterns (e.g., 'Run as administrator'). There are no Linux or cross-platform CLI examples, nor are Linux-friendly tools (such as tcpdump, Wireshark, or curl) mentioned. The document also assumes a Windows environment in its troubleshooting steps and screenshots.

Recommendations:

Provide equivalent Azure CLI and/or Azure Cloud Shell examples for checking Application Gateway settings, alongside or instead of PowerShell.
Include Linux-friendly network debugging tools such as tcpdump, Wireshark, or curl, and provide instructions or examples for their use.
When referencing downloadable tools, mention cross-platform alternatives (e.g., Wireshark, mitmproxy) and provide installation instructions for Linux/macOS.
Avoid Windows-specific instructions like 'Run as administrator' unless also providing the Linux/macOS equivalent (e.g., 'run with sudo').
Ensure screenshots and step-by-step instructions are not exclusively based on Windows UI/tools.
Rephrase sections to be OS-neutral where possible, or clearly separate instructions for Windows and Linux/macOS users.

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 Azure PowerShell command-line examples for automation account management, with no equivalent examples for Azure CLI (which is cross-platform and more common on Linux) or bash scripting. The PowerShell examples are presented as the sole scripting/command-line automation method. Additionally, the structure and language of the documentation prioritize Windows-centric tools and patterns, with no mention of Linux-native approaches or parity in command-line instructions.

Recommendations:

Add Azure CLI examples alongside PowerShell for all automation account management tasks, including deleting accounts and solutions.
Explicitly mention that Azure CLI commands can be run on Linux, macOS, and Windows, and provide bash syntax where appropriate.
Where PowerShell is referenced, clarify that it is available cross-platform, but also provide native bash or shell script equivalents for Linux users.
Include a section or tab for Linux users, demonstrating how to perform the same actions using the Azure CLI and/or REST API with curl.
Review all command-line examples to ensure Linux parity and avoid implying that PowerShell is the only or primary automation tool.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by emphasizing PowerShell and Windows-centric tools and patterns throughout. PowerShell and DSC (Desired State Configuration) are highlighted as primary automation and configuration mechanisms, with minimal mention of Linux-native equivalents. Examples and terminology (such as modules, cmdlets, and references to Windows services like Active Directory and SQL Server) are Windows-focused. Linux support is mentioned, but Linux-specific examples, tools, or patterns are absent or secondary.

Recommendations:

Provide Linux-native examples alongside PowerShell, such as Bash or Python runbooks specifically for Linux scenarios.
Explicitly mention and document Linux configuration management options (e.g., Ansible, Chef, native Linux DSC support) where relevant.
Balance references to Windows tools (e.g., Active Directory, SQL Server) with Linux equivalents (e.g., OpenLDAP, MySQL/PostgreSQL).
Include Linux-specific modules, package management, and automation patterns in the shared resources and scenarios sections.
Ensure that all features and capabilities are described with parity for both Windows and Linux, including any limitations or differences.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a Windows bias by exclusively referencing Azure PowerShell scripts for migration tasks, without mentioning or providing examples for Azure CLI, Bash, or other cross-platform tools. There are no Linux-specific instructions or examples, and the reliance on PowerShell may disadvantage users on Linux or macOS systems.

Recommendations:

Provide equivalent Azure CLI (az) commands and scripts for all migration steps, alongside PowerShell examples.
Explicitly mention that migration can be performed from Linux/macOS using Azure CLI or Bash, and provide guidance or links.
Include a section comparing PowerShell and CLI approaches, highlighting cross-platform compatibility.
Ensure that all tooling references (e.g., for scripting, automation) are not Windows-specific unless absolutely necessary, and note any platform limitations.
Add troubleshooting and support instructions relevant to Linux users, such as common issues with CLI or Bash environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates some Windows bias, particularly in the order and emphasis of examples and tooling. While the core certificate generation steps use OpenSSL (cross-platform), Windows-specific tools and workflows are often mentioned first or exclusively. The Azure PowerShell example is provided in detail, with no equivalent Azure CLI (cross-platform) example. IIS (Windows) is listed before Apache and NGINX, and references to editing the hosts file link to Windows-centric documentation. The PowerShell script uses Windows file paths, and there is no explicit Linux or macOS guidance for uploading certificates to Application Gateway.

Recommendations:

Provide Azure CLI examples alongside or before Azure PowerShell, especially for certificate upload and Application Gateway configuration.
Include Linux/macOS-specific instructions for tasks like editing the hosts file and importing root certificates into the trusted store.
When listing web server configuration examples, rotate or randomize the order (e.g., sometimes start with Apache or NGINX instead of IIS).
Use platform-neutral file paths in code samples, or provide both Windows and Linux/macOS path examples.
Link to cross-platform documentation for tasks like editing the hosts file or importing certificates, rather than Windows-only resources.
Explicitly mention that all OpenSSL commands work on both Windows and Linux, and note any OS-specific differences if relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a moderate Windows bias. Windows instructions and examples are consistently presented before Linux equivalents, and PowerShell (a Windows-centric tool) is used exclusively in all code samples for runbook authentication, management, and execution. Windows-specific tools and paths (e.g., Control Panel, cert store locations, Windows file paths) are referenced in detail, while Linux instructions are often less detailed or missing (e.g., no Linux example for starting a runbook via CLI, no Linux-specific credential asset support). Some advanced features (like Hybrid Worker Credentials) are not supported on Linux, and this is noted but not compensated for with Linux alternatives.

Recommendations:

Provide Linux examples alongside Windows examples for all key scenarios, especially for starting runbooks, configuring environment variables, and authentication.
Include Bash or Python code samples for Linux where PowerShell is used for Windows.
Present Windows and Linux instructions in parallel sections or tabs, rather than always listing Windows first.
Where features are unsupported on Linux (e.g., Hybrid Worker Credentials), suggest alternative Linux-native approaches or workarounds.
Reference Linux tools and paths with the same level of detail as Windows (e.g., environment variable setup, log locations, certificate/key management).
Add explicit Linux CLI examples for tasks like starting a runbook, managing credentials, and configuring permissions.
Ensure parity in troubleshooting and logging guidance for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows and PowerShell-centric bias. PowerShell (a traditionally Windows-first technology) is presented as the primary and recommended runbook type, with extensive detail and examples focused on Windows paths, tools, and cmdlets. Many examples and known issues reference Windows-specific file paths (e.g., C:\modules), environment variables, and behaviors. Linux-specific guidance is minimal or absent, and there are no Linux shell (bash) examples. Even in sections mentioning Linux support (e.g., Hybrid Runbook Workers), practical Linux usage patterns, troubleshooting, or examples are missing.

Recommendations:

Provide Linux-specific examples for runbook authoring and troubleshooting, such as using Linux file paths and shell commands where appropriate.
Clarify and expand on Linux Hybrid Runbook Worker support, including any limitations, best practices, and differences from Windows workers.
Include parity in examples: for every PowerShell/Windows example, provide an equivalent for Linux environments (e.g., bash or Python scripts interacting with Azure).
Avoid referencing only Windows paths (like C:\modules); include Linux equivalents (e.g., /opt/automation/modules) where relevant.
Document any Linux-specific issues, workarounds, or environment variables for Python and PowerShell runbooks on Linux Hybrid Workers.
Reorder sections or tables to avoid always listing Windows/PowerShell first, or explicitly state that ordering does not imply preference.
Highlight cross-platform capabilities and provide guidance for users working in non-Windows environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page demonstrates a strong bias toward Windows and PowerShell environments. PowerShell is consistently presented as the primary or default scripting language, with detailed instructions and examples focused on PowerShell modules, cmdlets, and package management. References to Windows-specific patterns (e.g., .zip for PowerShell modules, PowerShell Gallery) are prevalent, while Linux/Python guidance is minimal, often limited to brief notes or parenthetical mentions. There are no concrete Linux shell or Python package management examples, and REST API samples are PowerShell-centric. This results in insufficient guidance for users working in Linux or Python environments.

Recommendations:

Provide equal, step-by-step examples for both PowerShell and Python runbooks, including screenshots and REST API payloads for each.
Include Linux-specific instructions and examples, such as using .whl files for Python, and demonstrate how to upload and manage Python packages in detail.
Reference Linux tools and package sources (e.g., PyPI) alongside PowerShell Gallery, and clarify differences in package formats and management workflows.
When mentioning PowerShell modules or cmdlets, offer equivalent Python code snippets or commands where possible.
Avoid presenting PowerShell/Windows options first by interleaving or parallelizing instructions for both environments.
Add troubleshooting and best practices sections for Python/Linux runbooks, not just PowerShell.
Explicitly state OS/runtime compatibility and limitations for both PowerShell and Python environments.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ windows_registry_focus

Summary:

The documentation generally provides parity between Windows and Linux for most troubleshooting steps, but there is a noticeable Windows-first bias in the ordering and depth of examples. Windows tools, paths, and PowerShell scripts are often mentioned first or in greater detail, and several scenarios (such as registry key manipulation and event log checks) are Windows-specific or lack Linux equivalents. Some troubleshooting steps and error investigations are described only for Windows, especially those involving PowerShell, registry, and event logs.

Recommendations:

Alternate the order of Windows and Linux instructions throughout the document, or group them together under clear subheadings to avoid a Windows-first impression.
Where PowerShell or Windows registry steps are provided, ensure equivalent Linux commands or configuration file edits are described, or explicitly state if not applicable.
For event log troubleshooting, provide Linux equivalents (such as journalctl, syslog, or custom log file locations) where possible.
Add more Linux-specific troubleshooting scenarios, especially for authentication, permissions, and service management, to match the depth of Windows coverage.
Where Windows-specific tools or logs are referenced (e.g., Microsoft-SMA event logs), clarify what Linux users should check instead.
Ensure that all code snippets and examples are balanced in number and detail for both platforms.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ cmd_heavy

⚠️ powershell_examples

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform parity, but there are several subtle Windows biases. In command examples, Windows (Cmd) and PowerShell are often presented before or more prominently than Linux/macOS equivalents. Some sections provide detailed Cmd and PowerShell scripts, while Linux/bash examples are less detailed or missing (e.g., in Java deployment and function invocation). The use of 'command prompt' as a generic term and the inclusion of PowerShell-specific pivots also reinforce a Windows-centric approach. Linux/macOS users may find some steps less clear or less prioritized.

Recommendations:

Ensure that for every Windows (Cmd or PowerShell) example, an equivalent Linux/macOS (bash/sh) example is provided and given equal prominence.
When listing multiple platforms, alternate the order or present Linux/macOS first in some sections to avoid always prioritizing Windows.
Use neutral terms like 'terminal' instead of 'command prompt' when referring to the command line.
Where PowerShell is used, clarify its cross-platform availability or provide bash alternatives.
Audit all code snippets and pivots to ensure Linux/macOS users are not missing context or steps (e.g., in Java deployment, ensure bash and Cmd examples are equally detailed).
Consider a summary table or section that explicitly states cross-platform compatibility and any OS-specific caveats.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally aims for cross-platform coverage, but there are several instances of Windows bias. Windows-specific tools and patterns (such as PowerShell, Windows environment variable syntax, and Windows-only settings) are mentioned, sometimes without equivalent Linux examples or with Windows examples given first. Some settings and explanations are Windows-centric, and PowerShell is given special attention compared to other shells. In a few places, Linux alternatives are missing or only briefly referenced.

Recommendations:

When providing examples for environment variable paths or values (e.g., AzureWebJobs_TypeScriptPath), include both Windows and Linux formats side by side.
For settings that are OS-specific (e.g., WEBSITE_NODE_DEFAULT_VERSION), clarify Linux alternatives or explicitly state the Linux equivalent or lack thereof.
Where PowerShell is referenced for scripting or automation, provide Bash or shell equivalents for Linux users.
In sections that discuss reserved characters or delimiters (e.g., double-underscore vs. colon), provide explicit Linux behavior and examples, not just Windows.
Ensure that all sample commands, file paths, and configuration snippets are shown for both Windows and Linux where applicable.
Review all references to Azure CLI and Azure PowerShell, and ensure Azure CLI (which is cross-platform) is not presented after PowerShell or as an afterthought.
Where legacy or deprecated settings are Windows-only, clearly mark them as such and suggest Linux alternatives or note the lack thereof.
For settings that behave differently on Windows and Linux (e.g., WEBSITE_TIME_ZONE), always show both example values and clarify the mapping.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias. Windows-specific tools and configuration steps are often mentioned before their Linux equivalents, and some examples or instructions are provided only for Windows or with Windows-centric language. There are also cases where Linux-specific guidance is less detailed or omitted, and Windows tools (such as Visual Studio and PowerShell) are highlighted more prominently than Linux alternatives.

Recommendations:

Ensure all CLI and configuration examples are provided for both Windows and Linux, ideally side-by-side or with clear tabs.
When listing tools or instructions (e.g., Visual Studio, Visual Studio Code, Azure CLI, Azure PowerShell), present Linux-friendly options (such as Azure CLI and VS Code) before or alongside Windows-centric tools.
Avoid language that assumes Windows as the default; explicitly mention Linux where applicable.
For deployment and debugging sections, provide equivalent Linux workflows and commands, not just Windows/PowerShell or Visual Studio instructions.
Where ReadyToRun or runtime identifier tables are shown, ensure Linux is given equal prominence and detail as Windows.
For any references to file paths, environment variables, or shell commands, include both Windows and Linux syntax.
Add more Linux-specific troubleshooting and best practices, especially for local development and deployment.

Create pull request

Bias Types:

⚠️ windows_tools

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation focuses exclusively on configuration steps for Visual Studio and Visual Studio Code, both of which are primarily associated with Windows development environments. There are no instructions or examples for configuring the Roslyn Analyzer in Linux-native editors or command-line environments, nor is there mention of cross-platform workflows (e.g., JetBrains Rider, CLI usage, or integration with CI/CD pipelines). The ordering and content implicitly assume a Windows-centric development workflow.

Recommendations:

Add instructions for configuring and running the Roslyn Analyzer using the .NET CLI (dotnet build/analyze) to support Linux and macOS users.
Include examples or references for popular cross-platform editors such as JetBrains Rider or Vim/Emacs with OmniSharp.
Clarify that Visual Studio Code is cross-platform and provide explicit steps for Linux/macOS users, including any prerequisites.
Mention how to use the analyzer in CI/CD pipelines (e.g., GitHub Actions, Azure Pipelines) to ensure parity for non-Windows environments.
Consider reordering sections or adding a note to indicate cross-platform support and alternatives to Windows-specific tools.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation generally provides both Bash and Windows Command Prompt (cmd) examples for CLI operations, but consistently lists Windows/cmd examples immediately after Bash, sometimes with more detail or parity. There is no explicit PowerShell usage, but the presence of 'cmd' tabs and references to 'command prompt' in getting started sections may suggest a slight Windows-first orientation. There are no Linux-specific tools or patterns mentioned, and some sections (such as the initial 'Getting started' table) refer to 'terminal/command prompt' without clarifying Linux vs. Windows. There are no Linux-only examples or guidance, and no mention of Linux-specific troubleshooting or behaviors.

Recommendations:

Ensure that all command-line examples are provided for Bash (Linux/macOS), Windows cmd, and PowerShell where appropriate, and that Bash examples are not treated as secondary.
In getting started and tooling sections, explicitly mention Linux and macOS support, not just 'terminal/command prompt'.
Add Linux/macOS-specific notes or troubleshooting tips where behaviors may differ (e.g., file paths, environment variable syntax).
Where possible, provide parity in screenshots or step-by-step instructions for both Windows and Linux environments.
Consider adding a section or callout for common Linux/macOS developer workflows, such as using VS Code on Linux, or running Maven from a Unix shell.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows-centric bias by providing only PowerShell and Windows tool examples for Active Directory management, referencing Windows-specific registry keys and Group Policy settings, and omitting equivalent Linux or cross-platform instructions. Azure CLI is mentioned, but only as an alternative to PowerShell, and no Linux-native AD management tools or workflows are discussed. The documentation assumes a Windows AD DS environment and does not address Linux-based AD integration or management scenarios.

Recommendations:

Provide equivalent Linux command-line examples (e.g., using 'realm', 'adcli', or 'ldapmodify') for managing AD user attributes and Kerberos encryption types.
Include guidance for managing Active Directory from Linux systems, such as using Samba tools or openldap utilities.
When referencing PowerShell or Windows tools, offer parallel instructions for Azure CLI, Bash, or other cross-platform tools where possible.
Explicitly mention any platform limitations or prerequisites (e.g., if certain features require Windows-only tools) and suggest workarounds or alternatives for Linux administrators.
Add examples or links for integrating Azure NetApp Files with Linux-based AD environments or with non-Windows clients.
Reorder sections or examples to present cross-platform or platform-neutral approaches before Windows-specific instructions where feasible.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page primarily provides Azure PowerShell commands for feature registration and management, with only a brief mention of Azure CLI as an alternative. The PowerShell examples are presented first and in detail, while no explicit Linux shell or cross-platform CLI examples are shown. This may make it less accessible for Linux users or those who prefer CLI tools.

Recommendations:

Provide full Azure CLI command examples alongside PowerShell, including registration, status checking, and unregistration steps.
Present CLI (az) examples before or alongside PowerShell to avoid implying a Windows-first workflow.
Clarify that all actions can be performed from any platform using Azure CLI, and provide shell-friendly command blocks.
Consider including screenshots or instructions from the Azure Portal for a platform-neutral approach.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation page exhibits a moderate Windows bias. Windows and Windows Server are mentioned explicitly as examples for encryption in transit (SMB 3.0), while Linux equivalents are not discussed. There is a reference to PowerShell attacks in the security monitoring section, and several linked blog posts focus on Windows-centric attack vectors (e.g., PowerShell, Sysmon). Linux is only mentioned in passing in two blog post titles, and there are no explicit Linux or cross-platform command-line examples or tool references. The documentation assumes familiarity with Windows tools and patterns, and does not provide parity for Linux users.

Recommendations:

When mentioning Windows-specific features (e.g., SMB 3.0 encryption), also describe Linux equivalents, such as NFS with Kerberos or SMB 3.0 support on Linux.
Include Linux command-line or configuration examples alongside any Windows or PowerShell examples.
Reference Linux-native security tools (e.g., auditd, SELinux, AppArmor) where appropriate, especially in sections discussing monitoring and threat detection.
Balance blog post references to include more Linux-focused security scenarios and guidance.
Explicitly state cross-platform support and provide links to Linux documentation or guides where relevant.
Avoid assuming the reader is using Windows; use neutral language and examples that apply to both Windows and Linux environments.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation is generally neutral and focused on NFS, which is primarily a Linux/UNIX protocol. However, there is a section ('When I try to access NFS volumes through a Windows client...') that provides only Windows-specific troubleshooting and PowerShell commands, without equivalent Linux guidance. Additionally, Windows tools and patterns (PowerShell, Mount command with Windows syntax) are mentioned exclusively in that section, and the Windows client scenario is given its own FAQ entry, which may suggest a slight prioritization of Windows use cases.

Recommendations:

For every Windows-specific example or troubleshooting step, provide an equivalent Linux example (e.g., how to enable case-sensitive lookups or optimize NFS performance on Linux clients).
When mentioning tools or commands (such as PowerShell or the Windows Mount command), also mention the analogous Linux tools (e.g., mount command with appropriate options).
If a Windows-specific FAQ is included, consider adding a parallel FAQ for common Linux client issues or optimizations to balance the coverage.
Where possible, present Linux and Windows instructions side by side or in parallel sections to avoid the perception of platform prioritization.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The tutorial exhibits a mild Windows bias by referencing Microsoft Excel and Notepad for data preparation and preview, and by describing UI actions (such as 'File > Save As...') in a way that is most familiar to Windows users. No Linux or cross-platform alternatives (such as LibreOffice, Google Sheets, or command-line tools) are mentioned for converting or viewing tab-delimited files. The only editor explicitly recommended is Visual Studio Code, which is cross-platform, but the workflow and screenshots assume a Windows environment. There are no explicit PowerShell or Windows command-line instructions, but the lack of Linux-specific guidance or examples may hinder parity.

Recommendations:

When describing how to convert Excel files to tab-delimited text, mention cross-platform alternatives such as LibreOffice Calc or Google Sheets, and provide instructions for those tools.
For viewing or editing text files, suggest cross-platform editors (e.g., VS Code, Sublime Text, nano, vim) instead of only Notepad.
Where UI actions are described (e.g., 'File > Save As...'), clarify that the steps may differ on non-Windows platforms and link to relevant documentation for Linux/macOS users.
Consider providing command-line alternatives for data conversion (e.g., using csvkit or pandas in Python) for users who prefer or require CLI workflows.
Add a note or section confirming that all steps can be performed on Linux/macOS, and highlight any differences or additional requirements.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation generally presents Windows/SMB concepts and tools as the default or primary use case, with Linux/NFS support described as secondary. Windows terminology (NTFS, Active Directory, SID, NTLM) and tools are referenced without Linux equivalents, and official support is only noted for Windows/macOS SMB clients, not Linux. There are no Linux command-line examples for SMB access or configuration, and Linux tools/patterns (e.g., Samba, mount.cifs) are not described in parity with Windows tools.

Recommendations:

Provide Linux/Samba command-line examples for SMB access and configuration, similar to the Windows/Active Directory focus.
Explicitly mention and provide parity for Linux tools and patterns (e.g., Samba, mount.cifs, Linux ACLs) wherever Windows tools (NTFS, SID, NTLM) are referenced.
When discussing dual-protocol and identity mapping, include Linux-centric workflows and troubleshooting steps, not just Active Directory scenarios.
Clarify the support status and best practices for Linux SMB clients, and provide links to relevant Linux documentation.
Balance the order of presentation so that Linux/NFS and Windows/SMB are introduced and described with equal prominence, rather than Windows/SMB first or exclusively.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ windows_tools

Summary:

The documentation demonstrates some Windows bias, particularly in the ordering and emphasis of installation instructions and tooling. Windows-specific tools (Visual Studio, PowerShell, Chocolatey, Winget) are highlighted, and Windows instructions often appear before or more prominently than Linux/macOS equivalents. PowerShell is used heavily in Windows manual install examples, and Visual Studio (a Windows-only IDE) is given a dedicated section before cross-platform alternatives. However, Linux and macOS installation steps are present and reasonably detailed.

Recommendations:

Ensure that cross-platform and Linux/macOS instructions are presented with equal prominence and ordering as Windows instructions.
Avoid presenting Windows-specific tools (e.g., Visual Studio, PowerShell, Chocolatey, Winget) before cross-platform or Linux-native alternatives unless there is a clear user base justification.
Provide CLI examples using Bash (or sh) for Linux/macOS wherever PowerShell is used for Windows, and vice versa.
Consider adding a summary table at the top that clearly indicates cross-platform support and links to OS-specific sections, rather than leading with Windows-centric tools.
Where possible, recommend cross-platform editors (e.g., VS Code) before Windows-only editors (e.g., Visual Studio), or present them in parallel.
Balance the depth and detail of installation steps across all platforms to avoid the perception of Windows as the 'default' environment.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ missing_linux_example

Summary:

The documentation demonstrates a Windows bias by providing detailed instructions and screenshots for managing LDAP POSIX attributes using Windows tools (Active Directory Users and Computers MMC snap-in), while omitting equivalent Linux-based methods. The only explicit step-by-step example for attribute management is for Windows, and there are no Linux command-line or GUI alternatives mentioned. Additionally, Windows terminology and tools are referenced first or exclusively in several sections, and Linux client configuration is relegated to a link rather than being included inline.

Recommendations:

Include Linux-based examples for managing LDAP POSIX attributes, such as using ldapmodify, ldapadd, or tools like Apache Directory Studio.
Provide step-by-step instructions or command-line examples for editing user and group attributes on Linux LDAP servers (e.g., OpenLDAP).
Balance the documentation by presenting both Windows and Linux methods side-by-side where relevant, especially in sections on attribute management and client configuration.
Add screenshots or code snippets for Linux tools or commands to match the level of detail given for Windows.
When referencing tools or workflows, avoid defaulting to Windows-first language; instead, introduce both Windows and Linux options together.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation references Azure PowerShell and links to a PowerShell-specific guide for exporting blueprint definitions, without mentioning or providing equivalent Azure CLI (cross-platform) instructions. The mention of Azure CLI comes only later and is not accompanied by examples or links. No Linux- or cross-platform-specific guidance or examples are provided.

Recommendations:

Provide Azure CLI commands and examples alongside or before PowerShell instructions for all steps, especially for exporting blueprint definitions.
Link to both PowerShell and Azure CLI documentation for relevant tasks, ensuring parity.
Explicitly mention that all steps can be performed on Linux, macOS, and Windows, and clarify any platform-specific considerations.
Include sample commands or scripts using Azure CLI for key migration steps.
Avoid linking exclusively to PowerShell guides; offer a balanced set of resources for both Windows and Linux users.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ osplatform_windows_only

Summary:

The documentation page is largely neutral in terms of platform-specific instructions, as it focuses on JSON templates and UI definition files for Azure Resource Manager, which are platform-agnostic. However, there is a subtle Windows bias in the use of the 'osPlatform' property, which is always set to 'Windows' in all provided examples, and in the use of Windows-centric control types (e.g., Microsoft.Compute.UserNameTextBox with osPlatform: Windows, and VM size selectors with osPlatform: Windows). There are no examples or mentions of Linux or cross-platform scenarios, nor are Linux-specific values or guidance provided.

Recommendations:

Include examples where the 'osPlatform' property is set to 'Linux' or 'cross-platform', especially for controls like user name, password, and VM size selectors.
Add notes or examples that show how to handle Linux-specific requirements or differences in createUiDefinition.json files.
Where appropriate, mention that the controls and templates can be used for both Windows and Linux VMs, and provide parity in documentation.
If there are differences in validation, constraints, or default values between Windows and Linux, document these explicitly.
Ensure that references to control types or properties do not imply Windows is the only or primary supported platform.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

⚠️ powershell_heavy

Summary:

The documentation presents Windows (SMB) client instructions before Linux (NFS) client instructions, with more detailed steps and screenshots for Windows tools (File Explorer, dir command). Windows-specific tools and UI patterns are described in greater detail, while Linux instructions are more concise. The REST API section also references PowerShell specifically, without mentioning Linux scripting equivalents.

Recommendations:

Alternate the order of Windows and Linux sections, or present them in parallel to avoid 'Windows first' bias.
Provide equally detailed instructions and screenshots for Linux tools (e.g., showing GNOME/KDE file manager properties or terminal output).
Mention Linux scripting or automation options (e.g., Bash scripts, cron jobs) alongside PowerShell in the REST API section.
Ensure that Linux commands and tools are given parity in explanation and visual aids.
Where possible, use neutral language and avoid implying Windows is the default or primary environment.

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 the equivalent Linux/NFSv4.1 instructions are minimal and defer to another page. Feature registration examples are shown first in Azure PowerShell, with Azure CLI (cross-platform) only mentioned as an alternative. There are no explicit Linux command-line examples for setting audit ACEs or managing file access logs, and Windows tools and patterns are prioritized or exclusively described.

Recommendations:

Provide step-by-step command-line examples for setting Audit ACEs on NFSv4.1 volumes using Linux tools (e.g., setfacl, nfs4_setfacl).
Present Azure CLI examples alongside or before PowerShell examples for feature registration and management tasks.
Balance the detail level between Windows and Linux instructions, ensuring both platforms have clear, actionable steps.
Include screenshots or terminal output for Linux-based workflows, similar to the Windows GUI walkthrough.
Explicitly mention and link to Linux tools and commands where Windows tools are referenced.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

⚠️ missing_linux_example

Summary:

The documentation demonstrates a mild Windows bias by listing PowerShell as a primary tool for snapshot management alongside Azure Portal, REST API, and Azure CLI, but does not provide Linux-specific command-line examples or mention Linux-native tools. While the Azure CLI is cross-platform, there is no explicit guidance or examples for Linux users, and PowerShell is mentioned before any Linux alternatives. No Linux/Unix shell (bash) examples or references to Linux-specific patterns are present, and the only scripting example links to a SQL Server (Windows-centric) use case.

Recommendations:

Add explicit Linux/Unix shell (bash) command examples for snapshot management using Azure CLI.
Clarify that Azure CLI commands work identically on Linux, macOS, and Windows, and provide sample commands in a Linux shell context.
Balance the mention of PowerShell with equivalent bash or shell script examples for common snapshot tasks.
Include references or links to Linux/Unix documentation or community resources for managing Azure NetApp Files snapshots.
If scripting is discussed, provide at least one example using bash or Python, not just PowerShell or Windows-centric tools.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_tools

⚠️ windows_first

Summary:

The documentation demonstrates a moderate Windows bias. PowerShell is featured as a first-class scripting option alongside Azure CLI throughout, and several explanations and code comments reference Windows-specific tools, APIs, or conventions. For example, the documentation references the Windows API CommandLineToArgvW for argument parsing, and the use of Connect-AzAccount is described in a way that assumes PowerShell familiarity. The PowerShell examples are as prominent as the CLI (Bash) ones, but some explanations (such as error handling and identity management) are more detailed for PowerShell. There is also a tendency to mention PowerShell or Windows-related tools before their Linux/Bash equivalents, and some terminology (e.g., 'cmdlet', 'Connect-AzAccount') is Windows-centric.

Recommendations:

Wherever PowerShell-specific tools or APIs are mentioned (e.g., Connect-AzAccount, CommandLineToArgvW), provide equivalent Linux/Bash or cross-platform alternatives or explanations.
Ensure that CLI (Bash) and PowerShell examples are equally detailed, especially in sections about error handling, identity management, and output handling.
When referencing system calls or APIs (such as CommandLineToArgvW), clarify their relevance in a cross-platform context and, if possible, describe the behavior in platform-neutral terms.
Review the order of presentation so that Linux/Bash/CLI examples are not consistently secondary to PowerShell/Windows ones.
Avoid Windows-centric terminology (like 'cmdlet') without also referencing the equivalent Bash/CLI concepts.
Explicitly state that both Bash and PowerShell scripts are supported on Linux-based containers, and clarify any platform-specific behaviors or limitations.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation page is generally platform-neutral, focusing on Azure portal steps and DNS configuration. However, in the troubleshooting section, the only example given for clearing the DNS cache is for Windows (`ipconfig /flushdns`), with no mention of the equivalent commands for Linux or macOS. This presents a subtle 'windows_first' and 'missing_linux_example' bias.

Recommendations:

When providing command-line instructions (such as clearing DNS cache), include equivalent commands for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo resolvectl flush-caches`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
If referencing OS-specific troubleshooting steps, present them in a cross-platform way, either listing all major OSes together or linking to a cross-platform troubleshooting guide.
Review other sections for similar subtle platform-specific references and ensure parity for Linux and macOS users.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses on enabling authentication for Azure App Service but only references configuration via the Azure portal and app settings, without providing any command-line examples. There is no mention of Linux-specific tools or workflows (such as Azure CLI on Linux), nor are there any examples using Bash or Linux shell environments. The lack of cross-platform command-line instructions implicitly prioritizes the Windows GUI experience, which is more common for Windows users.

Recommendations:

Add step-by-step examples using Azure CLI commands that can be run on Linux, macOS, or Windows.
Include Bash shell snippets alongside any PowerShell or portal instructions.
Explicitly mention that configuration can be performed from any platform, and provide parity in instructions for both Windows and Linux users.
If referencing app settings, show how to set them using both Azure Portal (GUI) and Azure CLI (cross-platform).

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation only provides instructions for cleaning up resources via the Azure portal, which is a graphical interface commonly associated with Windows workflows. There are no examples or instructions for performing the same task using cross-platform tools such as the Azure CLI or Bash scripts, which are preferred by many Linux users.

Recommendations:

Add equivalent instructions for deleting the resource group using the Azure CLI, with example commands.
Include both Windows (PowerShell) and Linux (Bash) command-line examples where applicable.
Explicitly mention that the Azure portal is cross-platform, but also provide command-line alternatives for users who prefer non-GUI workflows.

Create pull request

Bias Types:

⚠️ powershell_heavy

⚠️ windows_first

Summary:

The documentation provides both PowerShell and Azure CLI scripts for granting Microsoft Graph API permissions, but PowerShell is presented first and in greater detail. PowerShell is more commonly associated with Windows environments, and its placement before the cross-platform Azure CLI may signal a preference for Windows tooling. There are no explicit Linux-specific instructions or examples, and the PowerShell example is more verbose and detailed than the Azure CLI example.

Recommendations:

Present Azure CLI examples before PowerShell examples, as Azure CLI is cross-platform and works natively on Linux, macOS, and Windows.
Ensure parity in detail and explanation between PowerShell and Azure CLI examples.
Explicitly mention that Azure CLI commands can be run on Linux, macOS, and Windows, and provide any Linux-specific notes if relevant.
Consider including Bash script examples or notes for Linux users where appropriate.
Avoid assuming Visual Studio usage, as it is primarily a Windows tool; mention cross-platform alternatives (e.g., VS Code, command-line deployment) where possible.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation is generally cross-platform neutral, focusing on Azure Portal UI steps. However, in the troubleshooting section, only a Windows-specific method ('ipconfig /flushdns') is provided for clearing the DNS cache, with no mention of Linux or macOS equivalents. This presents a subtle 'windows_first' and 'missing_linux_example' bias.

Recommendations:

When providing command-line troubleshooting steps (such as clearing DNS cache), include equivalent commands for Linux (e.g., 'sudo systemd-resolve --flush-caches' or 'sudo resolvectl flush-caches') and macOS (e.g., 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder').
If referencing OS-specific tools or commands, present them for all major platforms or link to external documentation covering all platforms.
Consider adding a short note or table summarizing how to clear DNS cache on Windows, Linux, and macOS to ensure parity.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ missing_linux_example

Summary:

The documentation assumes a development environment based on .NET and Azure App Service, with all examples and instructions tailored to ASP.NET Core and related Microsoft tooling. It references GitHub Codespaces and Azure CLI, which are cross-platform, but there are no explicit Linux-specific instructions, troubleshooting, or examples. The workflow and code samples are exclusively for .NET on App Service, with no mention of Linux hosting, deployment, or alternative frameworks. The documentation does not provide parity for Linux users or those using non-Windows environments beyond the implicit support via Codespaces.

Recommendations:

Add explicit instructions for running and deploying the sample app on Linux (e.g., Ubuntu) using local development environments, including package installation and environment setup.
Include Linux shell (bash) command examples alongside or instead of generic 'codespace terminal' instructions, clarifying that all steps work on Linux as well as Windows.
Mention and provide guidance for deploying to Azure App Service for Linux, not just the generic App Service, and clarify any differences.
Provide troubleshooting tips for common Linux-specific issues (e.g., file permissions, case sensitivity, dependency installation).
Reference alternative OpenAPI tools or libraries commonly used in Linux/.NET environments, if applicable.
Ensure that all CLI commands (dotnet, azd) are shown in a way that is clearly cross-platform, and note any OS-specific prerequisites.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation presents configuration options in the order: Azure portal, Azure PowerShell, and then Azure CLI. The PowerShell section is detailed and comes before the CLI section, which may suggest a Windows-first or PowerShell-preferred workflow. There are no Linux-specific examples, nor are cross-platform shell examples (e.g., Bash) provided. However, the CLI section does provide parity in steps, and the CLI is cross-platform, but the ordering and prominence of PowerShell may indicate a subtle Windows bias.

Recommendations:

Alternate the order of PowerShell and CLI sections, or present CLI before PowerShell to avoid implying a Windows-first workflow.
Explicitly state that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows.
Where possible, provide Bash shell script examples or mention Linux/macOS terminal usage for CLI commands.
Add a note or section for Linux users, highlighting any OS-specific considerations or confirming there are none.
Ensure that references to prerequisites and tooling do not assume a Windows environment (e.g., avoid only mentioning PowerShell installation).

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before macOS/Linux (bash), and gives both setx (cmd) and PowerShell examples, which can be seen as a Windows-first and PowerShell-heavy approach. However, Linux/macOS instructions are present and not omitted.

Recommendations:

Present Linux/macOS (bash) instructions before or alongside Windows instructions to avoid Windows-first ordering.
Group all OS-specific instructions in a table or side-by-side tabs for equal visibility.
Avoid giving multiple Windows-specific methods (cmd and PowerShell) unless also providing equivalent alternatives for Linux/macOS (e.g., bash and zsh).
Explicitly mention that all platforms are supported and tested, and provide troubleshooting tips for Linux/macOS users if relevant.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes both Windows Command Prompt and PowerShell commands, which can be seen as a Windows-first and PowerShell-heavy approach. Linux/macOS instructions are present but always listed after Windows instructions. There are no missing Linux examples or exclusive use of Windows tools, but the ordering and emphasis could be improved for parity.

Recommendations:

Alternate the order of OS instructions, sometimes listing Linux/macOS first to avoid implicit prioritization of Windows.
Group OS-specific instructions in tabs or collapsible sections to give equal prominence to all platforms.
Explicitly state that all platforms are supported and that the instructions are equivalent, to reinforce parity.
Consider reducing the number of separate Windows command examples (cmd and PowerShell) if not strictly necessary, or provide a rationale for their inclusion.
Where possible, use cross-platform commands (like 'export' for environment variables) in the main flow, and move OS-specific details to an appendix or footnote.

Create pull request

Bias Types:

⚠️ missing_linux_example

⚠️ windows_first

Summary:

The documentation page focuses exclusively on ASP.NET Core and Azure services, providing instructions and code samples only for C# and .NET environments. There are no references to Linux-specific workflows, tools, or command-line instructions (e.g., Bash), nor are there cross-platform considerations or examples. The instructions assume use of the Azure Portal (web UI) and .NET, which are available on both Windows and Linux, but the lack of explicit Linux parity (such as CLI examples or Linux-specific notes) may disadvantage Linux users. The structure and language implicitly prioritize Windows-centric development patterns.

Recommendations:

Add equivalent instructions and examples for Linux environments, such as using the Azure CLI (az) or Bash scripts to perform tasks like adding Key Vault references or managing App Configuration.
Include notes or sections that clarify cross-platform compatibility, especially for .NET Core/ASP.NET Core projects that run on Linux.
Provide sample commands for both PowerShell (if used) and Bash where relevant.
Mention and link to Linux-specific documentation or troubleshooting guides for common issues encountered on Linux.
Explicitly state that the steps and code samples are applicable to both Windows and Linux, or highlight any differences.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation page demonstrates a mild Windows bias by consistently listing Windows-centric tools (such as Visual Studio and PowerShell) before cross-platform or Linux-native alternatives. Visual Studio, a Windows-first IDE, is always mentioned first in C# sections, and PowerShell is highlighted as an HTTP test tool before mentioning curl. However, the documentation does include cross-platform options (Visual Studio Code, IntelliJ, Eclipse, Maven, curl, Azurite via npm) and notes Linux/macOS support, but Windows tools and patterns are often foregrounded.

Recommendations:

When listing development environments, alternate the order or explicitly call out cross-platform and Linux-native tools first in relevant sections.
In tables and lists, avoid always placing Windows-only tools (e.g., Visual Studio, PowerShell) at the top; consider grouping by platform or marking platform compatibility clearly.
In the HTTP test tools section, list curl (a ubiquitous Linux tool) before PowerShell and Edge, or provide explicit Linux/macOS examples.
Add explicit Linux/macOS command-line examples where only Windows/PowerShell patterns are described (e.g., for changing ports or running tools).
Where Visual Studio is mentioned, clarify its platform support and suggest alternatives for Linux users (e.g., JetBrains Rider, MonoDevelop, or VS Code).
Ensure that all screenshots, code snippets, and walkthroughs are available for Linux/macOS as well as Windows.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ powershell_heavy

Summary:

The documentation generally provides both Windows and Linux examples for Bicep and ARM templates, and covers Linux-specific hosting plans (including Flex Consumption, Container Apps, and Azure Arc). However, there is a consistent pattern of presenting Windows examples before Linux ones ("windows_first"), especially in code tabs and explanations. Additionally, PowerShell is the only scripting language shown for command-line deployment automation, with no Bash or Linux shell equivalents ("powershell_heavy"). There are no exclusive references to Windows-only tools, but the ordering and scripting language choices may subtly prioritize Windows users.

Recommendations:

Alternate the order of Windows and Linux examples/tabs, or default to Linux first in some sections, especially for plans that are Linux-only.
Provide Bash/Azure CLI shell script equivalents for all PowerShell deployment examples, especially in the 'Deploy your template' section.
Where possible, clarify when a feature or example is Windows- or Linux-specific, and ensure parity in depth and detail for both platforms.
Highlight cross-platform tools (like Azure CLI) more prominently, and avoid implying PowerShell is the default for all users.
In summary tables and introductory text, avoid listing Windows before Linux by default—consider alphabetical or usage-based ordering.

Create pull request

Bias Types:

⚠️ windows_first

⚠️ windows_tools

Summary:

The documentation demonstrates a mild Windows bias by consistently mentioning Windows tools (such as robocopy) alongside Linux tools (such as rsync), but always listing the Windows tool second and only for SMB scenarios. There are no explicit PowerShell-heavy examples, but the documentation refers to Windows-native tools and patterns (robocopy for SMB) without providing equivalent Linux-native SMB copy tools or examples. There are no missing Linux examples for NFS, but Linux-based SMB migration options are not discussed.

Recommendations:

Include Linux-native SMB copy tools (such as smbclient, cifs-utils, or rsync with SMB mounts) as alternatives to robocopy for SMB data migration.
Provide example commands for both Windows and Linux environments for SMB migrations, not just NFS.
Ensure that when listing tools, both Windows and Linux options are presented together and with equal prominence.
Consider adding a table or section comparing migration tools for both platforms, including their pros and cons.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation page demonstrates a 'windows_first' bias by mentioning Windows Isolated v2 as the minimum charge for App Service plans in regional deployments, without referencing Linux equivalents or clarifying Linux support. There are no explicit Linux examples, nor is Linux parity discussed. However, there are no PowerShell-heavy examples, Windows tools, or missing Linux command-line instructions, as the guide is portal-focused.

Recommendations:

Clarify whether Linux-based App Service plans are supported in all deployment types, and if so, specify any differences in minimum charges or instance types for Linux.
Where Windows-specific SKUs or terms are mentioned (e.g., 'Windows Isolated v2'), also mention the Linux equivalents or explicitly state if there are none.
Add a section or note on Linux support and considerations for App Service Environment deployments.
If possible, provide parity in examples, such as showing how to deploy both Windows and Linux web apps in the created environment.
Review all references to ensure Linux users are not left with ambiguity regarding support, pricing, or configuration.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation provides environment variable setup instructions in the order of Windows (cmd), PowerShell, and then macOS/Linux, which is a common 'windows_first' bias. However, all platforms are covered and there are no missing Linux examples or exclusive use of Windows tools.

Recommendations:

Present environment variable setup instructions with Linux/macOS first, or present all platforms in parallel (e.g., a table or side-by-side code blocks) to avoid implicit prioritization.
Ensure that Linux/macOS instructions are as detailed and prominent as Windows instructions.
Consider explicitly stating that the instructions apply equally to all platforms to reinforce parity.

Create pull request

Bias Types:

⚠️ windows_first

Summary:

The documentation is generally cross-platform and focuses on Visual Studio Code, which is available on Windows, Linux, and macOS. However, there is a subtle Windows bias in the troubleshooting section, where a specific troubleshooting step for Windows users is mentioned before any Linux-specific guidance, and there is no equivalent Linux troubleshooting advice. No PowerShell-specific commands, Windows-only tools, or missing Linux examples are present, but the mention of WSL Bash as a potential issue for Windows users is the only OS-specific guidance given.

Recommendations:

Add Linux-specific troubleshooting tips, such as common issues with permissions, shell environments, or dependencies on Linux.
Balance OS-specific troubleshooting by including macOS and Linux notes where relevant, not just Windows.
Explicitly state that the instructions apply equally to Windows, Linux, and macOS, and provide links to platform-specific setup guides if available.
If mentioning WSL Bash as a potential issue, also mention common shell or terminal issues that may occur on Linux or macOS.

Create pull request

Bias Types:

⚠️ missing_linux_example

Summary:

The documentation page does not display overt Windows bias in terms of command-line examples, tooling, or explicit mention of Windows-specific patterns. However, it is missing any platform-specific operational examples (such as deployment, configuration, or troubleshooting steps) for either Windows or Linux. All code samples are in C# and focus on Azure Functions' .NET isolated worker model, which is cross-platform, but there are no examples or notes addressing Linux-specific scenarios, nor any mention of Linux shell commands, deployment scripts, or environment differences. This absence could be considered a subtle bias by omission, as it does not acknowledge or assist Linux users with platform-specific guidance.

Recommendations:

Add explicit notes or examples for both Windows and Linux environments where operational steps are relevant (e.g., how to edit host.json, deploy, or manage worker processes on each OS).
If any command-line or scripting is referenced in future updates, provide both PowerShell (Windows) and Bash (Linux) equivalents.
Mention any OS-specific considerations for Durable Functions (such as file system paths, environment variable differences, or deployment nuances) where applicable.
Clarify in the prerequisites or troubleshooting sections that the .NET isolated worker model and Durable Functions are supported on both Windows and Linux, and link to relevant cross-platform deployment documentation.

Create pull request

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