Scan Details - Linux-first Docs for Azure

Azure Arc Troubleshoot Azure Arc resource bridge issues ...re-arc/resource-bridge/troubleshoot-resource-bridge.md

Medium Priority View Details →

Reviewed by: LLM Analysis

Issues: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example

Summary

The documentation provides troubleshooting guidance for Azure Arc resource bridge, which is a cross-platform solution. However, several examples and troubleshooting steps are presented with a Windows-first bias. PowerShell is used for network troubleshooting and proxy validation, while equivalent Linux commands (e.g., curl, wget, nslookup, dig) are not provided. Some instructions reference Windows-specific paths or behaviors (e.g., C:\Program Files), and in places, Windows tools or terminology are used before Linux equivalents. There are also sections where only Windows/PowerShell examples are given, and Linux/macOS users are left to infer the appropriate commands.

Recommendations

Provide Linux/macOS equivalents for all PowerShell or Windows command-line examples (e.g., curl, wget, dig, nslookup, ping).
When referencing file paths or CLI errors, clarify the equivalent locations or error formats for Linux/macOS.
Ensure troubleshooting steps are platform-neutral or include both Windows and Linux/macOS instructions side by side.
Explicitly mention supported platforms for the Azure CLI and arcappliance extension, and note any platform-specific requirements or limitations.
Add notes or links to Linux/macOS proxy configuration and troubleshooting guides where relevant.

Create Pull Request

Azure Arc CLI reference for `azcmagent connect` ...b/main/articles/azure-arc/servers/azcmagent-connect.md

Medium Priority View Details →

Reviewed by: LLM Analysis

Issues: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy ⚠️ windows_tools

Summary

The documentation for `azcmagent connect` generally presents authentication and usage options that apply to both Windows and Linux. However, there are several instances of Windows bias: Windows authentication methods are described first, Windows-specific certificate store options are detailed, and PowerShell tooling (`Get-AzAccessToken`) is mentioned as the primary way to obtain access tokens, with no Linux equivalent provided. Linux/macOS users may need to infer or research equivalent steps for some tasks.

Recommendations

When describing authentication methods, present Linux and Windows options in parallel or clarify which are cross-platform.
For access token acquisition, provide Linux/macOS equivalents (e.g., using Azure CLI: `az account get-access-token`) alongside PowerShell examples.
When discussing certificate-based authentication, clarify Linux certificate storage and access patterns, not just Windows certificate stores.
Ensure examples and instructions are not Windows-first unless there is a technical reason.

Create Pull Request

Azure Arc Next steps for cloud-native server management with Azure Arc-enabled servers .../articles/azure-arc/servers/cloud-native/next-steps.md

Medium Priority View Details →

Reviewed by: LLM Analysis

Issues: 2 bias types

Detected Bias Types

⚠️ windows_tools ⚠️ windows_first

Summary

The documentation references Windows-centric management tools (such as Group Policy Objects and WSUS) as examples of legacy/on-premises solutions, and these are mentioned before or instead of Linux equivalents. There are no explicit Linux management tool examples (e.g., Ansible, Chef, or Linux-native patching/compliance solutions), which may make Linux users feel less represented in the transition guidance.

Recommendations

Include examples of Linux management tools (e.g., Ansible, Chef, Puppet, or native package managers like apt/yum/dnf) alongside Windows tools when discussing legacy/on-premises management.
When describing phased adoption or overlap scenarios, mention how Linux users might continue using their existing tools (such as cron jobs, configuration management systems, or Linux-native compliance solutions) in parallel with Azure services.
Provide explicit examples or links for onboarding Linux servers, and clarify that Azure Arc supports both Windows and Linux environments.
Ensure that training and operational procedure sections reference Linux command-line tools and workflows (e.g., Bash, SSH, Linux-specific Azure CLI usage) where appropriate.

Create Pull Request

Azure Arc Enable VM Extensions Using Azure Resource Manager Template ...les/azure-arc/servers/manage-vm-extensions-template.md

Medium Priority View Details →

Reviewed by: LLM Analysis

Issues: 2 bias types

Detected Bias Types

⚠️ powershell_heavy ⚠️ windows_first

Summary

The documentation provides ARM template examples for both Linux and Windows VM extensions, ensuring parity in template content. However, all deployment instructions and command-line examples use Azure PowerShell, with no mention or examples of Azure CLI or Bash commands. Additionally, PowerShell deployment commands are presented first and exclusively, which may create friction for Linux/macOS users who prefer Bash or Azure CLI.

Recommendations

Add equivalent Azure CLI deployment commands for ARM template deployments, alongside PowerShell examples.
Explicitly state that both Azure PowerShell and Azure CLI can be used for deployments, and link to relevant CLI documentation.
Consider providing Bash script examples for Linux users, especially for template deployments.
Present PowerShell and CLI examples side-by-side, or alternate which is shown first, to avoid implicit prioritization.

Create Pull Request

Azure Arc Manage and maintain the Azure Connected Machine agent ...s/blob/main/articles/azure-arc/servers/manage-agent.md

Medium Priority View Details →

Reviewed by: LLM Analysis

Issues: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy ⚠️ windows_tools

Summary

The documentation provides comprehensive coverage for both Windows and Linux platforms, with clear sections and examples for each. However, there is a mild bias toward Windows in several areas: Windows examples and instructions are often presented first, PowerShell scripts are featured for tasks like cleaning up stale resources, and Windows-specific tools (Control Panel, Group Policy, Microsoft Update, WSUS, Configuration Manager) receive detailed attention. While Linux parity is generally strong, some automation examples (such as the stale resource cleanup script) are only provided for Windows/PowerShell, and Windows administrative patterns are described in greater depth.

Recommendations

Provide equivalent automation scripts for Linux environments (e.g., Bash scripts using Azure CLI or REST API for stale resource cleanup).
Alternate the order of Windows and Linux sections or present them in parallel to avoid Windows-first bias.
Include references to Linux-native management tools (such as Ansible, systemd, or cron) where appropriate, especially for update and configuration automation.
Ensure that all major workflows (install, upgrade, uninstall, cleanup) have Linux examples that match the detail and coverage of Windows instructions.

Create Pull Request

Azure Arc What's new with Azure Connected Machine agent ...main/articles/azure-arc/servers/agent-release-notes.md

Low Priority View Details →

Reviewed by: LLM Analysis

Issues: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ windows_tools ⚠️ powershell_heavy

Summary

The documentation provides both Windows and Linux release notes and download links, but consistently lists Windows first in download links and feature tables. Some instructions and known issues reference Windows-specific tools (e.g., PowerShell, msiexec) without Linux equivalents. There are also several Windows-only improvements and bug fixes, but these are clearly marked. Linux-specific changes are included where relevant, but Linux users may need to follow links for installation instructions rather than having direct commands shown.

Recommendations

Alternate the order of Windows and Linux in download links and feature tables, or list them alphabetically.
Where Windows-specific installation instructions are given (e.g., using msiexec or PowerShell), provide equivalent Linux commands or a direct link to Linux installation instructions.
Add explicit Linux installation/upgrade command examples in the release notes for parity with Windows instructions.
Continue clearly marking OS-specific changes, but ensure Linux improvements are highlighted equally.

Create Pull Request

Azure Arc Run command on Azure Arc-enabled servers (Preview) ...cs/blob/main/articles/azure-arc/servers/run-command.md

Low Priority View Details →

Reviewed by: LLM Analysis

Issues: 2 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy

Summary

The documentation mentions both Windows and Linux support for Run command on Azure Arc-enabled servers, but it lists PowerShell and Azure CLI as the primary experiences, with PowerShell examples and links shown before Linux-specific details. There are no explicit Linux command examples or Linux tool references in the main page, and the 'Next steps' section lists PowerShell before REST API and does not highlight Linux-specific guidance.

Recommendations

Add explicit examples or references for Linux shell usage (e.g., Bash scripts) in the main documentation.
Ensure parity in the 'Next steps' section by including links or notes for Linux-specific usage, such as Bash or shell scripting.
Where PowerShell is mentioned, clarify that Bash or other Linux shells are equally supported and provide examples.
Consider alternating the order of Windows and Linux references, or presenting them side-by-side, to avoid implicit prioritization.

Create Pull Request

Container Registry Store Helm Charts in Azure Container Registry ...es/container-registry/container-registry-helm-repos.md

Low Priority View Details →

Reviewed by: LLM Analysis

Issues: 2 bias types

Detected Bias Types

⚠️ windows_first ⚠️ missing_linux_example

Summary

The documentation page provides command-line examples for Helm and Azure CLI, which are cross-platform tools. However, there is a subtle Windows bias in the use of the 'set' command for environment variable assignment, which is specific to Windows CMD. No explicit Linux/macOS equivalent ('export') is shown, and the Windows-style example appears first. All other commands use syntax compatible with Linux/macOS (bash), but the initial environment variable setup may confuse non-Windows users. No PowerShell-specific or Windows-only tools are used, and the overall workflow is cross-platform.

Recommendations

Provide both Windows (CMD/PowerShell) and Linux/macOS (bash) syntax for environment variable assignment. For example, show 'set ACR_NAME=...' for Windows and 'export ACR_NAME=...' for Linux/macOS.
Add a note clarifying which commands are platform-specific and which are universal.
Where possible, use bash-style syntax for environment variables, as this is more widely compatible across platforms and shells.
Consider including a short section or table summarizing command differences for Windows, Linux, and macOS users.

Create Pull Request

Container Registry Deploy the Connected Registry Arc Extension ...iner-registry/quickstart-connected-registry-arc-cli.md

Low Priority View Details →

Reviewed by: LLM Analysis

Issues: 2 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy

Summary

The documentation provides both Bash and PowerShell examples for generating the protected settings JSON file, but the PowerShell example is shown after Bash. There is no evidence of exclusive use of Windows tools or missing Linux examples; all critical steps (deployment, verification, cleanup) use Azure CLI and kubectl, which are cross-platform. The PowerShell example is present for Windows parity, but Bash is shown first, which is a minor bias toward Linux/macOS users.

Recommendations

Present Bash and PowerShell examples side-by-side or in a tabbed format to emphasize equal support for both platforms.
Explicitly state that all Azure CLI and kubectl commands work on Linux, macOS, and Windows.
Ensure that any platform-specific nuances (e.g., file path differences, shell quoting) are mentioned for both Bash and PowerShell users.

Create Pull Request

Container Registry Azure Container Registry Authentication Options Explained ...ontainer-registry/container-registry-authentication.md

Low Priority View Details →

Reviewed by: LLM Analysis

Issues: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy ⚠️ minor_windows_tools

Summary

The documentation provides both Azure CLI and Azure PowerShell examples for authentication, but PowerShell (a Windows-centric tool) is consistently presented alongside CLI, and sometimes before or with equal prominence. The table of authentication methods lists PowerShell commands for each method, and PowerShell examples are given their own dedicated sections. However, Linux/macOS users are not blocked from completing any tasks, as Azure CLI and Docker commands are fully documented and cross-platform. There is a minor Windows-first bias in the order and prominence of PowerShell examples, but Linux parity is generally maintained.

Recommendations

Explicitly state that Azure CLI commands work on Linux/macOS and Windows, and that PowerShell is primarily for Windows users.
In example sections, present Azure CLI (cross-platform) examples before PowerShell (Windows-centric) ones.
Add a brief note clarifying that PowerShell examples are for users who prefer or require PowerShell, and that CLI is recommended for cross-platform workflows.
Consider including bash script examples for common automation scenarios, especially in sections discussing scripting.
Where environment variables are referenced (e.g., DOCKER_COMMAND), clarify syntax differences between Windows (set) and Linux/macOS (export).

Create Pull Request

Scan Information

Problematic Pages