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 several troubleshooting steps and command examples for Azure Arc resource bridge, but there is a notable Windows bias. Windows/PowerShell is referenced first or exclusively in some sections (e.g., troubleshooting HTTP/2 errors, DNS resolution, and remote access), and some command-line examples use PowerShell syntax without Linux equivalents. Linux troubleshooting steps (such as using ldd or nslookup) are present but less emphasized, and in some cases, Linux users must infer the equivalent steps. There are also sections where only Windows tools (PowerShell, RDP) are mentioned for remote access or troubleshooting, with no mention of SSH or Linux-native tools.

Recommendations

Provide Linux/macOS equivalents for all PowerShell or Windows-specific commands (e.g., curl for HTTP/2 troubleshooting, dig/nslookup for DNS, SSH for remote access).
When referencing remote access, mention SSH and Linux terminal options alongside RDP and PowerShell.
Ensure troubleshooting steps and examples are presented for both Windows and Linux environments, ideally side-by-side.
Where file paths or command syntax differ between platforms, clarify the differences and provide platform-specific instructions.
Review sections that mention Windows tools or patterns first and alternate the order, or present both options equally.

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

⚠️ powershell_heavy ⚠️ windows_tools ⚠️ windows_first

Summary

The documentation provides comprehensive guidance for both Windows and Linux platforms, with clear sections and examples for each. However, there is a notable bias toward Windows in several areas: PowerShell is heavily used for automation and scripting examples (especially for cleanup tasks), Windows-specific tools and update mechanisms (Microsoft Update, WSUS, Configuration Manager) are described in detail, and Windows instructions or examples sometimes appear before Linux equivalents. Linux parity is generally good for installation, upgrade, and uninstall tasks, but advanced automation and scripting guidance is Windows-centric.

Recommendations

Provide equivalent automation and cleanup scripts for Linux environments (e.g., Bash scripts using Azure CLI or SDKs to identify and delete stale Arc resources).
Include more Linux CLI examples for tasks currently shown only in PowerShell (such as resource cleanup).
When describing update mechanisms, mention Linux equivalents (such as unattended-upgrades, cron jobs, or configuration management tools like Ansible or Chef) for keeping the agent up to date.
Ensure that Linux instructions/examples are presented with equal prominence and detail as Windows instructions, and consider alternating which platform is shown first in sections.
Where possible, link to cross-platform Azure CLI documentation and encourage its use for automation tasks.

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: 3 bias types

Detected Bias Types

⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ 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 exclusively, with no Azure CLI or Bash examples. The deployment commands are shown only in PowerShell syntax, and the instructions for deploying and verifying extensions reference PowerShell first and exclusively. This creates friction for Linux/macOS users who may prefer or require Azure CLI or Bash. Additionally, the PowerShell examples use Windows-style file paths (e.g., D:\Azure\Templates), which may confuse Linux/macOS users.

Recommendations

Add equivalent Azure CLI deployment commands for ARM template deployments, especially for Linux/macOS users.
Show both Windows (PowerShell) and Linux/macOS (Bash/CLI) file path examples when referencing template files.
Explicitly mention that ARM template deployments can be performed using Azure CLI, and link to relevant documentation.
Consider presenting deployment commands for both platforms side-by-side, or at least clarify platform applicability.
If PowerShell is required for some reason, explain why and provide guidance for Linux/macOS users on installing and using PowerShell Core.

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: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ windows_tools ⚠️ missing_linux_example

Summary

The documentation page presents examples and scenarios that reference Windows-centric tools and patterns (such as Group Policy Objects and WSUS) before or instead of Linux equivalents. There are no explicit Linux management examples or mentions of Linux-native tools, despite Azure Arc supporting both Windows and Linux servers. This may create friction for Linux users seeking parity in onboarding, patching, and configuration management.

Recommendations

Include examples of onboarding Linux servers to Azure Arc, such as referencing Linux-specific deployment methods (e.g., using shell scripts or Ansible).
When discussing phased adoption, mention Linux patching workflows (e.g., integration with native package managers like apt, yum, or zypper) alongside Windows Update Manager.
Provide examples of configuration management overlap for Linux, such as using Azure machine configuration in audit mode alongside tools like Ansible, Chef, or Puppet.
Reference Linux equivalents when mentioning Windows tools (e.g., instead of only GPOs and WSUS, mention Linux configuration management and update mechanisms).
Ensure that automation and training sections include Linux CLI examples and highlight cross-platform capabilities.

Create Pull Request

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

Medium 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 managing Helm charts in Azure Container Registry, but in several places, it defaults to Windows-style commands (e.g., 'set' for environment variables) and does not consistently provide Linux/macOS equivalents. The Azure CLI and Helm commands themselves are cross-platform, but some setup steps and environment variable instructions are Windows-centric, which may cause confusion or friction for Linux/macOS users.

Recommendations

For environment variable setup, provide both Windows (e.g., 'set') and Linux/macOS (e.g., 'export') command examples side-by-side.
Explicitly state that Azure CLI and Helm commands work on Windows, Linux, and macOS, and clarify any OS-specific differences.
Where file operations are shown (e.g., 'rm -rf *'), clarify that these are Unix-style and provide Windows equivalents if relevant.
Review all code blocks to ensure parity, especially in authentication and setup sections, so Linux/macOS users are not left to infer the correct commands.

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 ⚠️ powershell_heavy ⚠️ windows_tools

Summary

The release notes for the Azure Connected Machine agent generally provide parity between Windows and Linux, listing features, fixes, and improvements for both platforms. However, there is evidence of mild Windows bias: Windows download links and version numbers are consistently listed before Linux, installer troubleshooting focuses on Windows (with PowerShell/Command Prompt instructions), and some improvements reference Windows tools (e.g., .ps1 scripts, msiexec). Linux-specific issues and enhancements are present, but Windows patterns and terminology are more prominent.

Recommendations

Alternate the order of Windows and Linux download links and version numbers to avoid implicit prioritization.
Include Linux installer troubleshooting steps and common commands (e.g., rpm, dpkg, systemctl) alongside Windows instructions.
Where Windows tools/scripts are mentioned (e.g., ExtensionCleanup.ps1), clarify if Linux equivalents exist or note their absence.
Ensure that bug fixes and improvements for both platforms are described with equal detail and visibility.

Create Pull Request

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

Low Priority View Details →

Reviewed by: LLM Analysis

Issues: 3 bias types

Detected Bias Types

⚠️ windows_first ⚠️ powershell_heavy ⚠️ windows_tools

Summary

The documentation exhibits mild Windows bias in several areas. Windows authentication options are described first, and Windows-specific certificate store usage is detailed before Linux equivalents. The only explicit tooling reference for obtaining an access token is the PowerShell Get-AzAccessToken cmdlet, with no Linux/macOS alternative (e.g., Azure CLI) mentioned. However, most examples and instructions are cross-platform, and Linux authentication flows are described.

Recommendations

In the 'Access token' section, add an example for obtaining an access token using Azure CLI (e.g., 'az account get-access-token') for Linux/macOS users.
When describing authentication options, avoid listing Windows-only methods first unless they are truly the most common. Consider grouping cross-platform methods together or clarifying platform applicability.
For certificate-based authentication, provide Linux/macOS instructions (e.g., storing PEM/PFX files in a secure directory) alongside Windows certificate store instructions.
Where Windows-specific tooling or patterns are mentioned, offer Linux/macOS equivalents in parallel.

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 Bash is shown first and PowerShell second. The PowerShell example is present, but there is a slight bias in ordering. All other commands use Azure CLI and kubectl, which are cross-platform and do not favor Windows tools or patterns. No critical steps are Windows-only, and Linux/macOS users can follow all instructions without friction.

Recommendations

Consider explicitly stating that both Bash and PowerShell examples are provided for cross-platform compatibility.
Alternate the order of Bash and PowerShell tabs in future documentation to avoid perceived bias.
Ensure that any OS-specific nuances (e.g., file path formats, shell differences) are noted for both platforms.

Create Pull Request

Scan Information

Problematic Pages