191
Pages Scanned
34
Pages Flagged
191
Changed Pages
17.8%
% Pages Flagged

Scan Information

Started At: 2026-02-05 00:00:08

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

Status: completed

Target Repo: Azure

Current Phase: discovery

Files Queued: 191

Files Completed: 191

Problematic Pages

35 issues found
Artifact Signing Set up signing integrations to use Artifact Signing ...ticles/artifact-signing/how-to-signing-integrations.md
High Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The documentation for setting up signing integrations with Artifact Signing is heavily focused on Windows environments. The primary integration described is SignTool, which is a Windows-only tool, and all setup instructions, examples, and installation steps are tailored for Windows users. PowerShell commands are used exclusively for installation and configuration, and Windows-specific package managers (winget, MSI installers) are referenced. There are no equivalent instructions or examples for Linux or macOS users, nor is there mention of cross-platform alternatives for signing artifacts.
Recommendations
  • Add explicit notes clarifying platform support for each integration, especially where Windows-only tools are required.
  • Provide Linux/macOS alternatives or guidance for artifact signing, such as using OpenSSL, GPG, or cross-platform .NET tools if supported.
  • Include examples for setting up signing integrations on Linux/macOS, or clarify if these platforms are not supported.
  • For GitHub Actions and Azure DevOps, highlight any platform-agnostic usage or provide sample workflows for Linux runners.
  • If Artifact Signing SDK supports cross-platform usage, add setup and usage instructions for Linux/macOS environments.
Automation Azure Automation data security ...b/main/articles/automation/automation-managing-data.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 both Windows and Linux guidance for TLS configuration, but Windows instructions and PowerShell cmdlets are mentioned first and more frequently, especially in backup/export and retention sections. Linux-specific examples for exporting or managing Automation account data are missing, and most command-line examples use Windows PowerShell cmdlets without Linux CLI or scripting alternatives.
Recommendations
  • Provide equivalent Linux CLI or scripting examples (e.g., using Azure CLI, az automation, or REST API) for tasks like exporting runbooks, DSC configurations, and managing assets.
  • When listing platform-specific instructions, alternate the order or present Linux and Windows equally rather than always listing Windows first.
  • Include references to Linux-compatible tools and commands (such as Bash scripts or Azure CLI) alongside PowerShell cmdlets.
  • Clarify when a feature or cmdlet is Windows-only, and suggest Linux alternatives where possible.
Application Gateway Scaling and Zone-redundant Application Gateway v2 ...eway/application-gateway-autoscaling-zone-redundant.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation page references Azure PowerShell in the 'Next steps' section as the only example for creating an autoscaling, zone-redundant Application Gateway. No equivalent Azure CLI or ARM template example is provided, which may create friction for Linux/macOS users who typically use CLI or templates rather than PowerShell.
Recommendations
  • Add links or examples for creating an autoscaling, zone-redundant Application Gateway using Azure CLI.
  • Include ARM/Bicep template instructions for cross-platform automation.
  • Present PowerShell and CLI examples side-by-side, or clarify that PowerShell is available cross-platform.
Automation Manage certificates in Azure Automation ...n/articles/automation/shared-resources/certificates.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 page for managing certificates in Azure Automation is heavily focused on PowerShell and Windows-centric tooling. All CLI examples for certificate creation and management use PowerShell cmdlets, with no mention of Linux/macOS equivalents or cross-platform CLI tools (e.g., Azure CLI). The recommended workaround for portal upload issues is PowerShell, and PowerShell examples are presented first and in greater detail than Python. There is no guidance for Linux/macOS users on how to perform these tasks outside of PowerShell.
Recommendations
  • Add Azure CLI examples for certificate management tasks (creation, upload, retrieval) to provide parity for Linux/macOS users.
  • Explicitly mention platform requirements for PowerShell cmdlets and note alternatives for non-Windows environments.
  • Include guidance or links for certificate management using REST API or ARM templates from non-Windows platforms.
  • Clarify whether PowerShell Core (pwsh) on Linux/macOS is supported for these cmdlets, and provide examples if so.
Azure Functions Azure Functions networking options ...ticles/azure-functions/functions-networking-options.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_only_feature ⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation is generally cross-platform, but the 'Hybrid Connections' feature is Windows-only and is described before clarifying Linux is unsupported. CLI, PowerShell, and portal examples are provided for enabling dynamic scale monitoring, but PowerShell is given equal prominence. In subnet sizing recommendations, Windows is mentioned before Linux. Most networking features and automation examples are platform-neutral, but some minor ordering and example choices favor Windows.
Recommendations
  • In the 'Hybrid Connections' section, clarify upfront that this feature is Windows-only before describing its usage.
  • Where subnet sizing recommendations are given, present Linux and Windows requirements together or alternate which is listed first.
  • For automation and configuration examples, ensure that CLI, PowerShell, and portal instructions are presented in parallel tabs, and consider showing CLI (cross-platform) first.
  • Add explicit notes or links for Linux/macOS users where features are Windows-only, and suggest alternatives if available.
  • Review screenshots and UI instructions to ensure they are not Windows-centric unless the feature is Windows-only.
App Service Use TLS/SSL Certificates in App Code ...icles/app-service/configure-ssl-certificate-in-code.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation page demonstrates a moderate Windows bias. Windows examples and certificate store patterns are presented first and in greater detail, including both C# and Java code for accessing certificates from the Windows certificate store. Linux guidance is less prominent, with Linux-specific code examples only shown for C# and only in the container section. There are no direct Linux examples for Java, Node.js, PHP, or Python, and users of those platforms are referred to external documentation. Windows-specific tools and environment variables are described before their Linux equivalents.
Recommendations
  • Add Linux-specific code samples for Java, Node.js, PHP, and Python, demonstrating how to load certificates from the Linux file system paths provided.
  • Present Linux and Windows examples side-by-side or in parallel tabs throughout the documentation, rather than focusing on Windows first.
  • Include explicit instructions for accessing certificates in Linux App Service apps (not just containers), especially for popular languages.
  • Clarify any platform-specific limitations or differences in certificate handling between Windows and Linux.
  • Reference Linux tools and patterns (such as OpenSSL, environment variables, etc.) where appropriate.
App Service Install a TLS/SSL Certificate for Your App ...main/articles/app-service/configure-ssl-certificate.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation generally provides cross-platform guidance, but there are some areas where Windows tools and patterns are mentioned first or exclusively. For example, when exporting certificates, Windows tools like IIS and Certreq.exe are referenced, and PowerShell is given as a primary automation example alongside Azure CLI. In automation and certificate export sections, Linux/macOS equivalents are not always provided or are mentioned after Windows tools.
Recommendations
  • When referencing certificate export, provide explicit Linux/macOS alternatives (e.g., OpenSSL commands) alongside or before Windows tools like IIS/Certreq.exe.
  • In automation sections, ensure that Azure CLI examples are shown before or alongside PowerShell, and clarify that both are cross-platform.
  • Where possible, add bash/shell script examples for common tasks (such as certificate management) to improve parity for Linux/macOS users.
  • Review screenshots and UI instructions to ensure they are not overly Windows-centric if the portal experience is the same across platforms.
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation generally presents Azure App Service plans in a cross-platform manner, mentioning both Windows and Linux as supported operating systems. However, there is a notable Windows bias in the 'Managed Instance on Azure App Service (preview)' section, which is exclusively Windows-focused and highlights Windows-specific features and tools (e.g., PowerShell, RDP, IIS customization). Additionally, some links and feature tables reference Windows pricing details first, and there are no Linux-specific examples or guidance for Linux users in areas where parity might be relevant.
Recommendations
  • Add explicit Linux examples or guidance where applicable, such as deployment, scaling, and feature availability.
  • Clarify which features and tiers are available for Linux-based App Service plans, especially in feature tables and pricing links.
  • When introducing new features (like Managed Instance), clearly state their OS limitations upfront and provide equivalent Linux guidance or alternatives if available.
  • Ensure that documentation links (e.g., pricing details) do not default to Windows unless the feature is Windows-only.
Application Gateway Migrate from V1 to V2 - Azure Application Gateway ...lob/main/articles/application-gateway/migrate-v1-v2.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools
Summary
The documentation for migrating Azure Application Gateway from V1 to V2 is heavily PowerShell-centric, with all migration scripts, examples, and instructions provided exclusively for Azure PowerShell. There are no CLI (az), Bash, or Linux/macOS-specific examples or guidance. The documentation assumes the use of PowerShell modules and tools, which are native to Windows and require additional setup or workarounds on Linux/macOS. This creates friction for users on non-Windows platforms, as they must install PowerShell Core and manually adapt the instructions.
Recommendations
  • Provide equivalent migration instructions and scripts for Azure CLI (az), which is cross-platform and natively supported on Linux/macOS.
  • Include Bash or shell script examples where possible, especially for certificate handling and resource management.
  • Explicitly document how to run PowerShell scripts on Linux/macOS using PowerShell Core, including installation steps and platform-specific caveats.
  • Add a section comparing PowerShell and CLI approaches, and recommend the CLI for cross-platform users.
  • Where scripts are only available in PowerShell, clarify this limitation and provide links or guidance for Linux/macOS users.
Application Gateway What is Azure Application Gateway v2? .../blob/main/articles/application-gateway/overview-v2.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation page for Azure Application Gateway v2 shows a moderate Windows/PowerShell bias. Migration guidance and registration/unregistration steps are provided exclusively using Azure PowerShell and Azure CLI commands, with no mention of Bash, Linux, or macOS-specific instructions. The primary tutorial linked is PowerShell-based, and there is no parity for Linux shell or cross-platform examples. However, the core product features are platform-agnostic, and most of the documentation is not inherently Windows-specific.
Recommendations
  • Add equivalent Bash/Azure CLI examples for registration, unregistration, and migration steps.
  • Provide links to tutorials using Bash or cross-platform Azure CLI, not just PowerShell.
  • Clarify that Azure CLI commands can be run on Linux/macOS, and provide sample commands for those environments.
  • When referencing scripts or automation, specify if they are PowerShell-only and offer alternatives for Bash users.
App Service Environment Variables and App Settings Reference ...ob/main/articles/app-service/reference-app-settings.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation page provides comprehensive coverage of environment variables and app settings for Azure App Service, but there is a noticeable Windows bias. Windows-specific paths (e.g., D:\home), tools (e.g., msbuild, Web Deploy/MSDeploy), and configuration patterns are often mentioned first or exclusively, with Linux equivalents sometimes missing or described later. Several examples and explanations use Windows-centric terminology, and some environment variables reference Windows-only features or behaviors, even when Linux equivalents exist. In some sections, Linux-specific details are present but less emphasized or lack parity in examples.
Recommendations
  • Ensure Linux and macOS paths (e.g., /home) are shown alongside Windows paths in all examples and tables.
  • When describing environment variables, provide both Windows and Linux usage patterns and default values, especially for file paths and deployment behaviors.
  • Balance the order of presentation so that Linux and Windows are treated equally (e.g., alternate which platform is mentioned first, or use neutral language).
  • Where Windows tools (e.g., msbuild, Web Deploy/MSDeploy) are referenced, include Linux alternatives (e.g., Oryx, zip deploy) and provide links to relevant documentation.
  • Add explicit Linux/macOS examples for environment variable usage, especially in sections where only Windows examples are given.
  • Clearly mark Windows-only settings and features to avoid confusion for Linux users.
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation provides detailed instructions for enabling diagnostic logging on Azure Application Gateway using PowerShell, but does not offer equivalent CLI or Bash examples for Linux/macOS users. The PowerShell method is presented before the Azure portal method, and there is no mention of Azure CLI or Bash scripting alternatives. This creates friction for users on non-Windows platforms who may not have access to PowerShell or prefer command-line tools native to their OS.
Recommendations
  • Add equivalent Azure CLI examples for enabling diagnostic logging, as Azure CLI is cross-platform and widely used on Linux/macOS.
  • Present both PowerShell and CLI examples side-by-side, or at least mention CLI alternatives and link to relevant documentation.
  • Ensure that command-line instructions are not Windows-centric and clarify that PowerShell is optional, not required.
  • Consider listing the Azure portal method first, as it is platform-neutral.
Application Gateway FAQ on V1 retirement ...ob/main/articles/application-gateway/retirement-faq.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example
Summary
The documentation page on Application Gateway V1 retirement and migration to V2 heavily references Azure PowerShell scripts for migration tasks, such as configuration migration and public IP retention. There are no CLI (az CLI), Bash, or Linux/macOS-specific examples or guidance. The migration process is described almost exclusively in terms of PowerShell tooling, which is native to Windows and less commonly used on Linux/macOS. This creates friction for users on non-Windows platforms who may prefer or require cross-platform tools.
Recommendations
  • Provide equivalent migration instructions and scripts using Azure CLI (az), which is fully cross-platform and widely used on Linux/macOS.
  • Include Bash script examples or guidance for key migration steps, especially for public IP retention and configuration migration.
  • Explicitly note PowerShell Core compatibility if scripts are cross-platform, or clarify Windows-only requirements.
  • Add a section comparing PowerShell and Azure CLI approaches, and recommend the best option for Linux/macOS users.
Application Gateway Tutorial: Improve web application access - Azure Application Gateway .../articles/application-gateway/tutorial-autoscale-ps.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ missing_linux_example ⚠️ windows_tools ⚠️ windows_first
Summary
The tutorial is heavily focused on Azure PowerShell and Windows tooling. All code examples use PowerShell cmdlets, and the creation of a self-signed certificate relies on the Windows-specific New-SelfSignedCertificate cmdlet. There are no CLI (az), Bash, or Linux/macOS-compatible instructions or alternatives provided. File paths and certificate management steps assume a Windows environment. This creates significant friction for Linux/macOS users, who may not have access to PowerShell or the same certificate tooling.
Recommendations
  • Provide equivalent instructions and code samples using the Azure CLI (az), which is cross-platform and widely used on Linux/macOS.
  • For certificate creation, include OpenSSL-based instructions for Linux/macOS users alongside the PowerShell example.
  • Use platform-agnostic file paths or clarify when a step is Windows-specific, and offer alternatives for other OSes.
  • Add a note at the beginning clarifying that the tutorial is PowerShell-focused, and link to any available CLI or portal-based tutorials for Linux/macOS users.
  • Where possible, structure examples so that Linux/macOS steps are presented alongside or before Windows-specific ones.
Application Gateway Overview of mutual authentication on Azure Application Gateway .../application-gateway/mutual-authentication-overview.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation provides configuration instructions for mutual authentication on Azure Application Gateway, with a notable emphasis on Azure PowerShell examples and references. PowerShell instructions are presented first and in greater detail than Azure CLI, and the 'Next steps' section directs users to a PowerShell-specific guide. There are no explicit Linux/macOS shell examples (e.g., Bash), and the CLI instructions are minimal by comparison. This creates friction for Linux/macOS users who may prefer Bash or other non-Windows tools.
Recommendations
  • Provide Bash examples for Azure CLI commands, including certificate management steps relevant to Linux/macOS environments.
  • Ensure parity in example depth and clarity between PowerShell and CLI sections.
  • In 'Next steps', include links to both PowerShell and CLI/Bash configuration guides.
  • Clarify that PowerShell is cross-platform, but also highlight CLI/Bash workflows for Linux/macOS users.
  • Add notes or sections on extracting and managing certificates using Linux tools (e.g., openssl) where relevant.
Automation Manage credentials in Azure Automation ...in/articles/automation/shared-resources/credentials.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation for managing credentials in Azure Automation is heavily PowerShell-centric, with all CLI examples and cmdlet references using Windows PowerShell syntax and concepts. There are no Bash, Linux shell, or cross-platform CLI examples provided, and PowerShell is presented first and in more detail than Python. This creates friction for Linux/macOS users who may prefer or require non-PowerShell approaches.
Recommendations
  • Add Azure CLI (az) examples for credential management, as Azure CLI is cross-platform and widely used on Linux/macOS.
  • Clarify whether PowerShell Core (pwsh) is supported for these cmdlets and provide examples for it if so.
  • If credential management is possible via REST API or SDKs (e.g., Python, .NET), include references and basic usage examples.
  • Explicitly note any platform limitations for cmdlets (e.g., if some are Windows PowerShell only).
  • Consider adding Bash or shell script examples for common tasks, or at least mention how Linux users can perform equivalent actions.
Automation Disaster recovery for Azure Automation ...in/articles/automation/automation-disaster-recovery.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 for disaster recovery in Azure Automation is heavily focused on PowerShell scripts and workflows for asset migration, with no mention of Bash, Python, or cross-platform alternatives. All migration examples and instructions are PowerShell-based, which is more native to Windows environments. While the page claims applicability to both Linux and Windows VMs, Linux users are left without platform-native guidance or examples, and PowerShell is assumed as the default automation tool. Additionally, links and tabs for Hybrid Runbook Worker installation default to Windows, with Linux instructions only referenced indirectly.
Recommendations
  • Provide equivalent Bash or Python scripts for asset migration, or clarify PowerShell Core (pwsh) compatibility on Linux/macOS.
  • Explicitly document how Linux users can install and use PowerShell (Core) for these tasks, including prerequisites and platform-specific caveats.
  • Add Linux/macOS specific examples or tabs for Hybrid Runbook Worker installation and migration steps.
  • Where PowerShell is required, clarify whether Windows PowerShell or PowerShell Core is supported, and highlight cross-platform usage.
  • Consider listing Linux instructions/examples before or alongside Windows ones to avoid implicit prioritization.
Automation Use Microsoft Entra ID in Azure Automation to authenticate to Azure ...ob/main/articles/automation/automation-use-azure-ad.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ missing_linux_example ⚠️ windows_first
Summary
The documentation is heavily focused on PowerShell and Windows-centric tools and patterns. All code examples and module references are for PowerShell, with no mention of Bash, Azure CLI, or cross-platform scripting options. The process for creating credential assets and managing Azure resources is only described using PowerShell cmdlets, which may not be familiar or accessible to Linux/macOS users. The phrase 'Windows PowerShell' is used, and there is no parity for Linux or macOS environments.
Recommendations
  • Add equivalent Azure CLI (az) examples for credential management and authentication, which are cross-platform.
  • Clarify that PowerShell Core (pwsh) is supported on Linux/macOS and provide examples or notes for those platforms.
  • Where possible, provide Bash or Python SDK examples for common automation tasks.
  • Avoid using 'Windows PowerShell' unless the feature is truly Windows-only; otherwise, use 'PowerShell' to indicate cross-platform support.
  • Explicitly state platform requirements and alternatives for non-Windows users.
Automation Configure runbook input parameters in Azure Automation ...b/main/articles/automation/runbook-input-parameters.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 4 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_tools ⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation is heavily focused on PowerShell and Windows-centric tools and patterns. All code examples for interacting with Azure Automation runbooks (defining parameters, starting runbooks, passing JSON, etc.) use PowerShell or C#. There are no CLI (az), Bash, or Linux-native examples for starting runbooks or passing parameters, and PowerShell is assumed as the primary interface. The only non-PowerShell runbook type discussed is Python, but even there, examples for starting Python runbooks from non-PowerShell environments are missing.
Recommendations
  • Add examples using Azure CLI (az automation runbook start) for starting runbooks and passing parameters, including JSON objects.
  • Include Bash or shell script examples for Linux/macOS users, especially for tasks like reading JSON and invoking REST APIs.
  • Clarify that PowerShell examples work cross-platform (if true), or provide guidance for PowerShell Core/7+ on Linux/macOS.
  • Provide parity in examples for Python runbooks, such as how to start them and pass parameters using CLI or REST from Linux/macOS.
  • Mention or link to documentation for installing and using Azure PowerShell on Linux/macOS, if PowerShell is required.
Azure Cache For Redis Azure Cache for Redis with Azure Private Link ...n/articles/azure-cache-for-redis/cache-private-link.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 step-by-step instructions for creating and managing Azure Cache for Redis with Private Link primarily through the Azure portal UI, which is platform-agnostic. However, in the command-line sections, PowerShell examples are presented first and in greater detail, followed by Azure CLI examples. There are no Linux/macOS-specific shell examples (e.g., Bash), nor are there references to Linux tools or workflows. The FAQ and troubleshooting sections reference generic commands (like nslookup) but do not provide OS-specific guidance.
Recommendations
  • Present Azure CLI examples before or alongside PowerShell examples, as Azure CLI is cross-platform and preferred by many Linux/macOS users.
  • Explicitly mention that Azure CLI commands work on Linux, macOS, and Windows, and provide Bash syntax for variable assignment and usage.
  • Where PowerShell is used, clarify that it is primarily for Windows users and suggest Azure CLI for Linux/macOS users.
  • Add troubleshooting steps or command examples for Linux/macOS (e.g., using dig instead of nslookup, if appropriate).
  • Ensure that all REST API examples are accompanied by curl commands for Linux/macOS users.
Azure Change Tracking Inventory Azure Change Tracking and Inventory Overview by Using Azure Monitor Agent ...change-tracking-inventory/overview-monitoring-agent.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation generally describes Azure Change Tracking and Inventory as supporting both Windows and Linux. However, the 'Track registry keys' section is exclusively focused on Windows registry monitoring, with no mention of Linux equivalents (such as configuration file monitoring or Linux-specific extensibility points). Additionally, examples and tables in this section are Windows-only, and there is no comparable coverage for Linux systems. Other sections, such as file change tracking and inventory, do mention Linux, but Windows examples and terminology are more prominent.
Recommendations
  • Add a section describing Linux-specific configuration monitoring (e.g., tracking changes in /etc, systemd unit files, or other Linux daemon/service configurations).
  • If registry key monitoring is Windows-only, explicitly state this and provide parallel information for Linux users about what is monitored (e.g., config files, service definitions).
  • Include Linux-focused examples and tables where appropriate, such as listing default tracked files or directories on Linux.
  • Ensure that screenshots and walkthroughs show both Windows and Linux scenarios where supported.
Azure Functions Guide for running C# Azure Functions in an isolated worker process ...icles/azure-functions/dotnet-isolated-process-guide.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 generally provides a cross-platform overview, but there are several areas where Windows is mentioned first or exclusively, and Linux-specific guidance is less prominent. Windows tools and configuration steps are often listed before Linux equivalents, and some examples or CLI commands are shown only for Windows or with Windows-centric language. In some sections, Linux users must infer the correct steps or settings, as explicit Linux examples or instructions are missing or less detailed.
Recommendations
  • Ensure that all CLI examples (such as az functionapp config set) are shown for both Windows and Linux, or clarify when the command is identical across platforms.
  • When listing deployment or configuration steps, present Linux and Windows instructions in parallel, or use tabs to allow users to select their OS.
  • Where PowerShell or Windows-specific tools are mentioned, provide equivalent Bash/Linux commands or note if there is no equivalent.
  • In sections like ReadyToRun and deployment requirements, ensure Linux instructions are as detailed and prominent as Windows instructions.
  • Review the order of presentation in tables and lists to avoid consistently listing Windows before Linux, which can subtly reinforce a Windows-first bias.
  • Add explicit Linux/macOS troubleshooting notes where environment variable or file path differences may affect users.
Azure Functions Quickstart: Create a Durable Functions app that uses the MSSQL storage provider ...n/articles/azure-functions/durable/quickstart-mssql.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first ⚠️ missing_linux_example
Summary
The documentation page demonstrates a notable Windows bias in its local SQL Server setup section. PowerShell is used exclusively for Docker commands, and no equivalent Bash or shell script examples are provided for Linux/macOS users. The SQL Server Express option is described as 'on your local Windows computer' before mentioning Docker, and troubleshooting steps reference Docker Desktop, which is primarily a Windows/macOS tool. While Docker is cross-platform, the lack of Linux/macOS-specific instructions or examples may create friction for non-Windows users.
Recommendations
  • Provide Bash/shell script equivalents for all PowerShell commands, especially for Docker setup and database creation.
  • Explicitly mention and demonstrate how to run SQL Server Express or Docker containers on Linux/macOS, including installation and troubleshooting steps.
  • Reference Linux-native tools (e.g., terminal, package managers) where appropriate, and clarify that Docker and SQL Server can be used on all major platforms.
  • Add screenshots or CLI output examples from Linux/macOS environments to improve parity.
  • When troubleshooting, include steps for Linux users (e.g., using 'docker ps', 'docker exec', file system navigation) instead of only referencing Docker Desktop.
Azure Functions Azure Functions Core Tools reference ...cles/azure-functions/functions-core-tools-reference.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 for Azure Functions Core Tools is generally cross-platform, but several areas show Windows bias. Windows-specific issues (such as Python packaging on Windows for Linux deployment) are called out, and PowerShell is included as a first-class runtime. However, examples and troubleshooting guidance tend to focus on Windows scenarios, and Linux/macOS-specific instructions or examples are often missing or less detailed. In some cases, Windows terminology (e.g., 'func.exe') is used, and commands like certificate creation default to Windows behaviors without clarifying Linux/macOS differences.
Recommendations
  • Provide explicit Linux/macOS examples alongside Windows ones, especially for commands that behave differently or require extra steps on non-Windows platforms (e.g., certificate creation, Python packaging).
  • Clarify when instructions or defaults differ for Linux/macOS users (e.g., trusted certificate creation with --useHttps, Docker usage).
  • Include troubleshooting tips for Linux/macOS users, especially where Windows-specific issues are mentioned (e.g., Python native dependencies).
  • Avoid Windows-centric terminology (such as 'func.exe') in cross-platform contexts; use 'func' or 'Azure Functions Core Tools' instead.
  • Ensure parity in runtime support documentation (e.g., PowerShell is Windows-centric; clarify Linux/macOS support status).
Azure Functions Migrate C# app from in-process to isolated worker model ...es/azure-functions/migrate-dotnet-to-isolated-model.md
Medium Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation provides only Azure PowerShell examples for identifying function apps to migrate, with no mention of Azure CLI or cross-platform alternatives. PowerShell is Windows-centric, and the absence of Linux/macOS-friendly instructions creates friction for non-Windows users. Additionally, the PowerShell example appears before any mention of other tooling, reinforcing a Windows-first approach.
Recommendations
  • Add equivalent Azure CLI examples for identifying function apps to migrate, as Azure CLI is cross-platform and widely used on Linux/macOS.
  • Explicitly mention that Azure CLI can be used as an alternative to PowerShell, and provide links or code snippets.
  • Where possible, present CLI and PowerShell examples side-by-side, or use tabs to allow users to select their preferred environment.
  • Review other sections for implicit Windows tooling assumptions and clarify when steps are platform-agnostic.
Azure Functions How to target Azure Functions runtime versions ...b/main/articles/azure-functions/set-runtime-version.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 both Windows and Linux guidance, but there is a subtle Windows bias. PowerShell examples are given equal prominence to Azure CLI, but PowerShell is more Windows-centric. In some sections, PowerShell is presented as a primary method alongside CLI, while Linux-specific instructions are separated and sometimes less detailed. For example, setting the runtime version via PowerShell is described, but there is no equivalent Bash or Linux shell example. Additionally, some instructions (like setting linuxFxVersion) note that PowerShell and portal are not supported, but do not offer Linux-native alternatives beyond Azure CLI.
Recommendations
  • Provide Bash or Linux shell script equivalents for all PowerShell examples, especially for Linux users who may not use PowerShell.
  • When listing methods (portal, CLI, PowerShell), avoid always listing PowerShell before Linux-native options.
  • Clarify in each section which methods are cross-platform and which are Windows-specific.
  • Where PowerShell is used, explicitly note its platform limitations and suggest alternatives for Linux/macOS users.
  • Consider including a table or matrix summarizing which management tools are available for each platform.
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation provides both Bash and PowerShell examples for Azure CLI commands, but PowerShell examples are included for every step and are presented immediately after Bash, indicating a slight Windows-first and PowerShell-heavy bias. There are no Linux-specific tools or patterns missing, but the inclusion and formatting of PowerShell examples may create minor friction for Linux/macOS users.
Recommendations
  • Clearly label Bash and PowerShell sections to help users quickly find the relevant example for their platform.
  • Consider presenting Bash (Linux/macOS) examples before PowerShell (Windows) examples to reduce perceived Windows-first bias.
  • Add a note clarifying that Bash examples are suitable for Linux/macOS and PowerShell for Windows, improving clarity for cross-platform users.
  • Ensure variable naming consistency between Bash and PowerShell examples to avoid confusion.
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 Azure CLI commands, but the PowerShell versions are shown immediately after the Bash ones, and the formatting and comments explicitly call out PowerShell. This may create a perception of Windows-first bias, though Linux/macOS users are not blocked from completing the task.
Recommendations
  • Clearly label Bash and PowerShell examples with headings or tabs to help users quickly find their preferred shell.
  • Consider presenting Bash (Linux/macOS) and PowerShell (Windows) examples in parallel tabs or sections, rather than one after the other.
  • Add a note clarifying that Bash examples are for Linux/macOS and PowerShell for Windows, to improve clarity for cross-platform users.
API Management Deploy an Azure API Management Instance to Multiple Azure Regions ...management/api-management-howto-deploy-multi-region.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_tools ⚠️ powershell_heavy ⚠️ windows_first
Summary
The documentation references Azure PowerShell cmdlets (set-azapimanagement) alongside Azure CLI and REST API for managing regional gateways, and lists PowerShell before CLI in the tools section. However, the only explicit command-line examples provided are for Azure CLI, which is cross-platform. No Linux-specific examples or tools are mentioned, and there is no indication of Linux/macOS incompatibility for the described tasks.
Recommendations
  • Ensure that all command-line examples are provided for both Azure CLI and PowerShell, with clear notes on cross-platform compatibility.
  • When listing management tools, mention Azure CLI before PowerShell to avoid Windows-first bias, or clarify that both are supported across platforms.
  • Explicitly state that all tasks can be performed from Linux/macOS using Azure CLI and REST API, and provide links to installation guides for these platforms.
  • If PowerShell is referenced, clarify that Azure PowerShell is available on Linux/macOS and provide installation instructions.
Application Gateway Quickstart: Deploy Application Gateway for Containers ALB Controller ...ploy-application-gateway-for-containers-alb-controller.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 1 bias type
Detected Bias Types
⚠️ windows_first
Summary
The documentation provides both Windows and Linux instructions for installing Helm, but the Windows instructions are presented first. All other commands and examples use Azure CLI, Helm, and kubectl, which are cross-platform tools and do not show a Windows bias. No PowerShell-heavy or Windows-only tooling is present, and Linux parity is maintained throughout.
Recommendations
  • Present Linux and Windows installation instructions for Helm in parallel tabs or list Linux first, as Linux is the most common platform for Kubernetes workloads.
  • Explicitly mention that Azure CLI, Helm, and kubectl commands work on Linux, macOS, and Windows, and provide troubleshooting notes for each OS if relevant.
  • Ensure future updates continue to provide parity for Linux/macOS users, especially for installation and environment setup steps.
Azure Functions App settings reference for Azure Functions ...ain/articles/azure-functions/functions-app-settings.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools
Summary
The documentation is generally cross-platform and provides information relevant to both Windows and Linux users. However, there are minor instances of Windows bias: (1) In the explanation of hierarchical delimiters for app settings, Windows behavior is described first and in more detail, with Linux mentioned secondarily; (2) The sample for AzureWebJobs_TypeScriptPath uses a Windows-style path (%HOME%\typescript) without a Linux equivalent; (3) The WEBSITE_NODE_DEFAULT_VERSION setting is marked as 'Windows only' but does not immediately clarify the Linux alternative or link to it; (4) The guidance for updating application settings programmatically recommends Azure CLI or Azure PowerShell, mentioning PowerShell before CLI, which is more cross-platform.
Recommendations
  • When showing path examples (e.g., AzureWebJobs_TypeScriptPath), include both Windows and Linux formats (e.g., %HOME%\typescript and $HOME/typescript).
  • For settings that are OS-specific (e.g., WEBSITE_NODE_DEFAULT_VERSION), explicitly state the Linux equivalent or link to relevant Linux documentation.
  • When describing delimiter behavior, present Windows and Linux behaviors in parallel, and clarify differences without prioritizing one OS.
  • When recommending tools for programmatic configuration, mention Azure CLI first or equally with PowerShell, as CLI is cross-platform.
  • Audit all examples and settings to ensure Linux/macOS equivalents are present where applicable.
Azure Functions Migrate Consumption plan apps to Flex Consumption in Azure Functions ...unctions/migration/migrate-plan-consumption-to-flex.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ linux_first ⚠️ linux_tools ⚠️ windows_parity
Summary
This documentation is intentionally cross-platform and, if anything, slightly Linux-focused. The migration automation (az functionapp flex-migration) is currently only available for Linux apps, and Linux instructions and tooling are often presented first. Windows users are provided with parity guidance, but must perform more manual steps. There is no evidence of Windows bias; rather, Linux is prioritized where automation exists.
Recommendations
  • Continue to clearly indicate where features are Linux-only and provide equivalent manual steps for Windows.
  • Monitor for future CLI or automation support for Windows and update documentation to ensure parity.
  • Consider adding a summary table at the top to clarify which steps are automated for Linux and which require manual effort for Windows.
  • Solicit feedback from Windows users to ensure manual migration steps are clear and complete.
Azure Functions Develop and run Azure Functions locally ...in/articles/azure-functions/functions-develop-local.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ windows_tools
Summary
The documentation page generally maintains good cross-platform coverage, explicitly stating support for Linux, macOS, and Windows in most sections. However, there are minor signs of Windows bias: Visual Studio (a Windows-only IDE) is consistently listed first in C# sections, and Windows-specific tools such as PowerShell Invoke-RestMethod and Visual Studio are mentioned before their Linux/macOS equivalents in the HTTP test tools list. While Linux/macOS options are present and described, Windows-centric tools and workflows are sometimes prioritized in ordering and examples.
Recommendations
  • List cross-platform tools (e.g., Visual Studio Code, command line) before Windows-only tools (e.g., Visual Studio) in tables and lists, especially in C# sections.
  • When mentioning HTTP test tools, consider listing curl (cross-platform) before PowerShell and Visual Studio.
  • Explicitly note when a tool or workflow is Windows-only to help Linux/macOS users avoid confusion.
  • Add more explicit Linux/macOS example commands or screenshots where appropriate, especially in sections referencing command prompts or terminals.
  • Ensure parity in depth and detail for Linux/macOS workflows compared to Windows ones.
Azure Functions Troubleshoot Python function apps in Azure Functions ...n/articles/azure-functions/recover-python-functions.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 3 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy ⚠️ missing_linux_example
Summary
The documentation generally aims for cross-platform support, but some sections show a Windows-first or PowerShell-heavy bias. For example, in the 'Diagnose the cygrpc reference error' section, the Windows/PowerShell command is shown before the Unix/Linux equivalent. In the 'Troubleshoot: could not load file or assembly' section, PowerShell and Cmd examples are given alongside Bash, but Bash is not always presented first. There are also places where Windows tools or patterns (such as 'py' launcher) are mentioned before their Linux counterparts, and some explanations assume familiarity with Windows conventions. However, Linux and macOS users are generally not blocked from completing tasks, as alternatives are provided.
Recommendations
  • When presenting command-line examples, show Bash/Linux commands first or side-by-side with Windows/PowerShell equivalents.
  • Avoid presenting Windows/PowerShell commands as the default or primary example; use tabs or clear headings for each OS.
  • Where Windows-specific tools (like 'py' launcher) are mentioned, ensure the Linux/macOS equivalent is given equal prominence.
  • Review all troubleshooting steps to ensure Linux/macOS users are not required to infer steps from Windows instructions.
  • Explicitly state when a command or tool is Windows-only, and provide clear alternatives for Linux/macOS.
Azure Functions Storage considerations for Azure Functions ...ain/articles/azure-functions/storage-considerations.md
Low Priority View Details →
Reviewed by: LLM Analysis
Issues: 2 bias types
Detected Bias Types
⚠️ windows_first ⚠️ powershell_heavy
Summary
The documentation generally maintains platform neutrality, but there are minor signs of Windows bias. In the 'Mount file shares' section, both Azure CLI (Linux-focused) and Azure PowerShell (Windows-focused) examples are provided, with CLI shown first. However, PowerShell is given equal prominence, and some references (such as log streaming limitations and scaling notes) mention Windows before Linux. The overall guidance and examples are available for both platforms, and Linux-specific features (like mounting Azure Files shares) are clearly called out. There are no critical sections that exclude Linux/macOS users.
Recommendations
  • Continue to provide both Azure CLI and PowerShell examples, but clarify platform applicability (e.g., explicitly state which commands are for Windows and which are for Linux/macOS).
  • Where Windows is mentioned first (e.g., in scaling or deployment notes), consider reordering or providing parallel Linux guidance for parity.
  • Ensure that any references to tooling or deployment methods include Linux/macOS equivalents where possible.
  • Add explicit notes when features are Windows-only or Linux-only to avoid confusion.