← Back to Dashboard
31
Pages Scanned
8
Pages Flagged
31
Changed Pages
25.8%
% Pages Flagged

Scan Information

Started At: 2026-01-30 00:00:07

Finished At: 2026-02-10 18:44:36

Status: completed

Target Repo: Azure Management

Current Phase: discovery

Files Queued: 31

Files Completed: 31

Problematic Pages

8 issues found
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 demonstrates mild Windows bias by referencing Windows-centric tools (Group Policy Objects, WSUS) and listing them before or without Linux equivalents. Examples and overlap scenarios focus on Windows management patterns, with no explicit mention of Linux-native tools or practices. There are no Linux-specific onboarding, configuration, or patching examples, which may create friction for Linux users transitioning to Azure Arc.
Recommendations
  • Include Linux-specific examples for onboarding, configuration, and patching (e.g., demonstrate using Azure Update Manager with Linux servers, mention Linux package managers like apt/yum/zypper).
  • Reference Linux-native management tools (such as Ansible, Chef, or native OS configuration management) in overlap scenarios alongside Windows tools.
  • Provide guidance or links for Linux server administrators on transitioning their existing management workflows to Azure Arc.
  • Ensure examples and scenarios explicitly mention support for both Windows and Linux, or provide parallel examples where appropriate.
GitHub Create Pull Request
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 sections show Windows bias: PowerShell is used for network troubleshooting and proxy validation examples, Windows-specific terminology (RDP, 'Remote PowerShell') is referenced, and Windows tools/commands are mentioned before or instead of Linux equivalents. Some troubleshooting steps (e.g., checking DNS resolution, proxy issues) only provide PowerShell or Windows command prompt examples, with no Linux/macOS alternatives. The documentation does mention Linux-specific errors (GLIBC version), but overall, Linux/macOS users may need to adapt instructions themselves.
Recommendations
  • For every PowerShell or Windows command prompt example (e.g., nslookup, ping, Resolve-DnsName, Invoke-WebRequest), provide equivalent Linux/macOS commands (e.g., dig, host, curl, wget).
  • When referencing remote access methods (RDP, Remote PowerShell), mention SSH and Linux console sessions as alternatives.
  • Explicitly state that all Azure CLI commands work on Linux/macOS, and clarify any OS-specific requirements for the management machine.
  • For troubleshooting steps involving file permissions (SSH folder), provide Linux/macOS instructions (e.g., chmod, ls -l) alongside Windows guidance.
  • Review all troubleshooting steps to ensure Linux/macOS users are not required to infer or translate instructions themselves.
GitHub 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 provides authentication options for both Windows and Linux, but Windows-specific methods and tools (such as interactive browser login and Windows certificate store usage) are described first and in more detail. The only explicit tool for obtaining access tokens mentioned is PowerShell's Get-AzAccessToken, with no Linux/macOS alternatives. Windows certificate store options are described, but Linux equivalents (such as using PEM/PFX files) are less emphasized. Most examples are OS-neutral, but the authentication section and some flag descriptions prioritize Windows workflows.
Recommendations
  • Add explicit Linux/macOS examples for obtaining access tokens (e.g., using Azure CLI: 'az account get-access-token').
  • Reorder authentication options so that OS-neutral or Linux-default methods (device code, service principal with PEM/PFX) are described before Windows-specific options.
  • Provide parity in certificate authentication guidance, including Linux file system storage and permissions.
  • Clarify which authentication methods are recommended for Linux/macOS and provide example commands.
  • Mention cross-platform alternatives to PowerShell tools when referencing access token acquisition.
GitHub 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, maintaining parity in template content. However, all deployment command examples use Azure PowerShell exclusively, with no Azure CLI or Bash alternatives shown. Additionally, PowerShell deployment commands are presented first and throughout, which may create friction for Linux/macOS users who prefer CLI or Bash. The documentation is not Windows-only, but the deployment workflow is PowerShell-centric.
Recommendations
  • Add equivalent Azure CLI deployment commands (e.g., az deployment group create) alongside PowerShell examples.
  • Explicitly note that deployment can be performed from Linux/macOS using Azure CLI, and provide sample Bash/CLI commands.
  • Consider presenting CLI and PowerShell examples side-by-side, or alternate which is shown first.
  • Clarify that the ARM templates themselves are cross-platform and can be deployed from any OS.
GitHub 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 both Windows and Linux instructions for all major lifecycle tasks (install, upgrade, uninstall, proxy config), using tabbed sections for each OS/package manager. However, there is a notable Windows bias in several areas: Windows instructions and tools (Control Panel, MSI installer, PowerShell, Group Policy, WSUS, Configuration Manager) are often described in greater detail, with more step-by-step guidance and troubleshooting. Windows examples (especially PowerShell) are sometimes presented before Linux equivalents, and the only provided cleanup script for stale resources is in PowerShell, with no Linux shell or Azure CLI alternative. Linux instructions are present and generally sufficient, but less detailed and lack parity in automation examples.
Recommendations
  • Provide equivalent automation scripts for Linux users (e.g., Bash/Azure CLI script for stale resource cleanup).
  • Ensure Linux instructions are as detailed as Windows instructions (e.g., troubleshooting, package manager nuances, log file locations).
  • Where possible, present OS options in parallel or randomize order, rather than consistently listing Windows first.
  • Add more Linux-specific operational guidance, such as using systemd for service restarts, or integration with Linux configuration management tools.
  • For proxy configuration, clarify Linux service restart procedures and provide troubleshooting steps similar to those for Windows.
GitHub 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: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools
Summary
The documentation generally provides parity between Windows and Linux, with separate download links and clear indication of OS-specific changes. However, Windows is often listed first in download links, tables, and feature descriptions. Some installer troubleshooting and feature improvements reference Windows tools (e.g., PowerShell, msiexec) without equivalent Linux guidance. There are a few Windows-only improvements, but these are appropriately marked.
Recommendations
  • Alternate the order of Windows and Linux in download links and tables, or list alphabetically to avoid implicit prioritization.
  • Where troubleshooting or installation steps reference Windows tools (e.g., PowerShell, msiexec), provide equivalent Linux commands (e.g., shell commands for .rpm/.deb packages) or link to Linux installation guidance.
  • Ensure that any OS-specific improvements or bug fixes are clearly labeled, as is already done.
  • Consider adding a brief section or link to Linux-specific troubleshooting tips, mirroring the Windows installer guidance.
GitHub 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: 1 bias type
Detected Bias Types
⚠️ windows_first
Summary
The documentation provides both Bash and PowerShell examples for generating the protected settings JSON file, but the Bash example is presented first. All other command-line instructions use Azure CLI and kubectl, which are cross-platform and do not show Windows-specific bias. No Windows-only tools or patterns are used, and Linux/macOS users are fully supported.
Recommendations
  • Maintain the current approach of providing both Bash and PowerShell examples for critical steps.
  • Optionally, clarify that Azure CLI and kubectl commands work on Windows, Linux, and macOS.
  • If possible, provide a short note that PowerShell Core is available cross-platform, to further reduce perceived bias.
GitHub 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: 1 bias type
Detected Bias Types
⚠️ windows_first
Summary
The documentation provides cross-platform instructions for storing Helm charts in Azure Container Registry, primarily using Helm CLI and Azure CLI commands, which are available on Windows, Linux, and macOS. However, there is minor Windows bias in the environment variable setup section, where the 'set' command (Windows syntax) is shown before any Linux/macOS alternative, and no explicit Linux/macOS equivalent ('export') is provided. All other commands and examples are platform-neutral or use Bash syntax, which is common on Linux/macOS and supported in Windows environments via WSL or PowerShell. No PowerShell-specific examples or Windows-only tools are present.
Recommendations
  • In the environment variable setup section, add the Linux/macOS equivalent command (e.g., 'export ACR_NAME=<container-registry-name>') alongside the Windows 'set' command.
  • Wherever environment variables are referenced, clarify syntax differences between Windows (cmd), PowerShell, and Bash.
  • Consider explicitly stating that all CLI commands work on Linux, macOS, and Windows (with Bash/WSL/PowerShell), and link to platform-specific setup guides if available.
GitHub Create Pull Request