1139
Pages Scanned
71
Pages Flagged
1139
Changed Pages
6.2%
% Pages Flagged

Scan Information

Started At: 2025-08-22 00:01:04

Finished At: 2025-08-22 00:25:39

Status: completed

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

Current Phase: discovery

Problematic Pages

Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a subtle Windows bias by referencing Windows-specific tools and patterns (such as web.config and iisnode) without providing equivalent Linux guidance or examples. While there is some mention of Linux (e.g., using PM2 for Node.js), most configuration and troubleshooting advice assumes a Windows environment, and Linux alternatives are not consistently presented.
Recommendations:
  • For every mention of Windows-specific configuration files (e.g., web.config), provide equivalent instructions for Linux (e.g., app settings, environment variables, or startup scripts).
  • When referencing iisnode or IIS-based settings, include guidance for Node.js apps running on Linux, such as using PM2, Nginx, or other process managers.
  • Ensure all code/configuration examples are provided for both Windows and Linux environments, or clearly indicate when a step is platform-specific.
  • Where possible, use cross-platform terminology and tools, or provide side-by-side instructions for both platforms.
  • Expand troubleshooting and best practices sections to explicitly address Linux-based App Service environments, including differences in diagnostics, scaling, and process management.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ missing_linux_example
⚠️ windows_first
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing Visual Studio Code (a Microsoft product) and GitHub Copilot for testing, without mentioning Linux-native alternatives or command-line tools. All instructions assume use of the Azure portal, which is browser-based and cross-platform, but there are no examples or guidance for Linux users (e.g., using curl, httpie, or other CLI tools). The documentation does not provide parity for Linux environments or mention Linux-specific workflows.
Recommendations:
  • Include examples of testing the MCP server using Linux command-line tools such as curl or httpie.
  • Mention that Visual Studio Code and GitHub Copilot are available on Linux, or suggest alternative editors and tools commonly used in Linux environments.
  • Provide step-by-step instructions for testing the MCP server from a Linux shell, including sample requests.
  • Ensure that any screenshots or instructions do not assume a Windows-only environment.
  • Explicitly state cross-platform compatibility where relevant, and avoid implying Windows as the default platform.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation page demonstrates a strong Windows bias. All migration tools and examples focus exclusively on Windows environments, specifically IIS servers and PowerShell scripts. There are no examples or guidance for migrating .NET apps from Linux environments, nor are Linux-native tools or command-line examples provided. The documentation repeatedly references Windows-specific technologies and omits any mention of Linux-based .NET hosting or migration scenarios.
Recommendations:
  • Add guidance and examples for migrating .NET apps hosted on Linux servers (e.g., Apache, Nginx) to Azure App Service.
  • Include Linux-native tooling or scripts (such as Bash or shell scripts) for discovery, assessment, and migration.
  • Mention and document migration paths for .NET Core or ASP.NET Core apps running on Linux.
  • Ensure parity in documentation by providing Linux examples alongside Windows examples, rather than focusing solely on Windows/IIS.
  • Reference cross-platform tools and approaches where possible, and clarify any Windows-only limitations in the tools described.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
Summary:
The documentation exhibits a mild Windows bias. In several sections, Windows terminology and tools (such as Azure PowerShell) are presented before or more prominently than their Linux counterparts. The Azure CLI is included, which is cross-platform, but the PowerShell section is given equal prominence, and there is no mention of Bash scripting or Linux-native automation. The portal UI instructions do not clarify parity for Linux users, and screenshots are Windows-centric. There are no explicit Linux shell script examples, and the documentation does not discuss Linux-specific considerations or workflows.
Recommendations:
  • Ensure that Linux and cross-platform automation examples (e.g., Bash scripts) are provided alongside or before PowerShell examples.
  • Clarify in portal instructions and screenshots whether the experience is identical for Linux-hosted apps and users.
  • Add explicit notes or sections for Linux users, including any differences or considerations when using the Premium V3 tier.
  • Consider including Linux-native CLI usage patterns (e.g., Bash for loops, environment variables) in automation sections.
  • Review screenshots and UI instructions to ensure they are not Windows-specific or clarify if the experience is the same on Linux.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
Summary:
The documentation demonstrates a moderate Windows bias. Windows is mentioned first in availability sections, and Azure PowerShell (a Windows-centric tool) is given equal prominence to Azure CLI, despite the CLI being more cross-platform. The portal instructions and screenshots are also Windows-oriented, and there is no mention of Linux-native scripting or automation tools (e.g., Bash, shell scripts). While Linux is supported and examples are present (notably in the CLI commands), the ordering and tool selection subtly prioritize Windows users.
Recommendations:
  • Alternate the order of Windows and Linux instructions/examples, or present them in parallel to avoid 'Windows first' bias.
  • Include explicit Bash/shell script examples for automation, not just Azure CLI and PowerShell.
  • Clarify that Azure CLI is fully cross-platform and highlight its use in both Linux and Windows environments.
  • Add notes or screenshots showing the Azure portal experience on Linux (if differences exist), or clarify that the portal is OS-agnostic.
  • Where PowerShell is mentioned, also mention Bash or other Linux-native scripting options for parity.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows bias in several ways: Windows installation and usage instructions are consistently presented before Linux equivalents, with more detail and screenshots for Windows GUI tools. Troubleshooting examples rely on Windows-specific tools like PowerShell's Test-NetConnection, with no Linux alternatives given. The Hybrid Connection Manager GUI is only available on Windows, and its usage is described in depth, while Linux users are directed to CLI usage with less visual guidance. Some troubleshooting steps and connectivity tests are Windows-centric, and Linux users are left to infer equivalent commands.
Recommendations:
  • Present Linux and Windows instructions in parallel, giving equal prominence to both platforms.
  • Include Linux equivalents for all troubleshooting commands (e.g., provide 'nc', 'telnet', or 'curl' examples alongside PowerShell).
  • Add more screenshots or step-by-step instructions for Linux CLI usage, similar to the Windows GUI walkthrough.
  • Explicitly mention limitations or differences for Linux users (e.g., lack of GUI) at the start of relevant sections.
  • Where a tool or feature is Windows-only (like the GUI), suggest alternative workflows or third-party tools for Linux.
  • Ensure all code snippets and connectivity tests have Linux versions, not just Windows/PowerShell.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page exclusively discusses discovery of .NET web apps hosted on IIS web servers within VMware environments, which are Windows-centric technologies. There is no mention of Linux-based hosting options (such as Kestrel, Apache, or Nginx), nor are there any examples or guidance for discovering .NET apps running on Linux servers. All tools and workflows referenced (Azure Migrate appliance, IIS) are Windows-specific.
Recommendations:
  • Include information about discovering .NET web apps hosted on Linux servers, such as those running on Kestrel, Apache, or Nginx.
  • Provide parallel examples or workflows for Linux environments, including any differences in the discovery process.
  • Mention and link to tools or documentation relevant to Linux-based .NET app discovery, if supported.
  • Clarify in the introduction or prerequisites if the discovery process is currently limited to Windows/IIS environments, and provide guidance for Linux users.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
Summary:
The documentation provides both Linux and Windows instructions for configuring data sources in Tomcat and JBoss on Azure App Service. However, the Windows section is more detailed, with explicit PowerShell scripts and Windows-specific file paths and tools (e.g., PowerShell, %HOME%, %LOCAL_EXPANDED%). The Windows approach is described with more step-by-step scripting, while the Linux section is more concise and assumes familiarity with shell scripting and Linux tools. In some cases, Windows-specific tools and patterns (like PowerShell and .cmd files) are emphasized, and the Windows instructions are presented before or in more detail than their Linux equivalents.
Recommendations:
  • Ensure Linux and Windows instructions are presented with equal detail and clarity. For example, provide a full sample Linux shell script for the Tomcat server.xml transformation, similar to the detailed PowerShell script for Windows.
  • Where possible, present Linux and Windows instructions in parallel, rather than giving one platform a more prominent or detailed section.
  • Avoid assuming more technical familiarity for Linux users; provide step-by-step instructions and explanations for both platforms.
  • Include Linux-native tools and patterns (e.g., bash scripts, systemd, cron) with the same prominence as Windows tools (e.g., PowerShell, .cmd files).
  • Where Azure CLI commands are shown, ensure both Windows and Linux path conventions are included in examples.
  • Consider providing a summary table or section that highlights the differences and similarities between Linux and Windows approaches, to help users quickly find the relevant instructions for their platform.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by focusing exclusively on Windows-based deployment and configuration patterns for ASP.NET apps. All runtime version checks, file paths, and tooling references (such as Kudu, CMD, PowerShell, and Visual Studio) are Windows-centric, with no equivalent Linux examples or instructions. Linux-based App Service environments and their configuration methods are not mentioned, leaving a gap for users deploying to Linux.
Recommendations:
  • Add parallel Linux-based instructions and examples for each section, especially for runtime version checks and environment variable access.
  • Include Linux file paths and commands (e.g., using Bash in Kudu or SSH) alongside Windows CMD/PowerShell examples.
  • Clarify which instructions apply to Windows App Service plans and which to Linux, and provide links to Linux-specific documentation where appropriate.
  • Mention and demonstrate deployment and configuration using cross-platform tools (such as the Azure CLI in Bash) and editors (such as VS Code) in addition to Visual Studio.
  • Explicitly state any differences in behavior or configuration between Windows and Linux App Service environments.
GitHub Create pull request
Bias Types:
⚠️ missing_windows_example
⚠️ linux_tools
⚠️ linux_first
Summary:
The documentation provides detailed, step-by-step instructions and command-line examples for Linux containers, including Azure CLI usage and SSH client commands. In contrast, Windows containers are only mentioned briefly, with no equivalent command-line or tool-based examples. The Linux workflow is prioritized and illustrated with actual commands and output, while Windows users are told only that browser SSH is supported and Azure CLI is not. No Windows-specific tools, PowerShell, or workflow details are given.
Recommendations:
  • Add equivalent step-by-step instructions for connecting to Windows containers, including any available command-line tools (e.g., PowerShell, Windows SSH clients) or alternative workflows.
  • Clarify whether Windows containers support SSH via any local tools, and provide examples if possible.
  • If browser SSH is the only supported method for Windows, provide screenshots and a detailed walkthrough similar to the Linux section.
  • Explicitly mention any limitations or differences for Windows containers up front, and consider a parity table comparing Linux and Windows SSH access options.
  • Ensure that both Linux and Windows sections have similar depth and clarity in their instructions.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
⚠️ windows_first
Summary:
The documentation page demonstrates a Windows bias primarily in the section for identifying Azure Traffic Manager endpoints, where only a PowerShell script is provided for detection of non-Azure endpoints. There are no equivalent Bash, Azure CLI, or cross-platform scripting examples for Linux or macOS users. The instructions for running the script assume a Windows/PowerShell environment, and there is no mention of how to perform the same task on Linux or macOS. Elsewhere, while REST API and Azure CLI commands are referenced (which are cross-platform), the only explicit scripting example is PowerShell. This may hinder Linux/macOS users from easily following the guidance.
Recommendations:
  • Provide equivalent Bash or Azure CLI scripts for identifying Traffic Manager endpoints, or at least mention how Linux/macOS users can perform the same checks.
  • When referencing scripts, clarify if they are cross-platform or provide alternatives for non-Windows environments.
  • Add explicit instructions or links for running the detection queries or scripts in Linux/macOS environments.
  • Review future documentation to ensure that scripting and automation examples are not Windows/PowerShell-centric unless absolutely necessary, and always provide parity for Linux users.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates Windows bias by referencing Windows directory paths (e.g., D:\home\site\wwwroot, D:\home\data\SitePackages) before mentioning Linux equivalents, and by using Windows-style path separators in examples. There is a lack of explicit Linux-specific instructions or examples, and the documentation assumes familiarity with Windows conventions and tools, such as FTP and directory creation in Windows paths. Linux paths are mentioned only parenthetically and not in examples or step-by-step instructions.
Recommendations:
  • Provide Linux-specific examples alongside Windows ones, including explicit Linux directory paths (e.g., /home/site/wwwroot, /home/data/SitePackages) in commands and instructions.
  • Use platform-agnostic language and path separators, or clearly distinguish between Windows and Linux instructions.
  • Include troubleshooting and deployment steps that address Linux-specific scenarios, such as permissions and file system differences.
  • Add examples using Linux-native tools (e.g., SCP, SFTP, rsync) for uploading ZIP packages, in addition to FTP.
  • Ensure parity in documentation for both Windows and Linux App Service environments, including screenshots or terminal outputs where appropriate.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation is heavily focused on Windows environments, specifically Azure App Service on Windows with iisnode. All configuration and troubleshooting steps are tailored to Windows, referencing Windows-specific tools (e.g., iisnode, web.config, named pipes, Win32 error codes, Kudu CMD/PowerShell). There are no Linux or cross-platform examples, and Linux equivalents for configuration, logging, or debugging are not mentioned.
Recommendations:
  • Add equivalent sections or links for Node.js on Azure App Service Linux, including best practices and troubleshooting steps.
  • Provide Linux-based configuration and troubleshooting examples, such as using PM2, NGINX, or Linux file paths.
  • Include Linux shell (bash) commands and screenshots for common tasks (e.g., installing profiler tools, accessing logs).
  • Reference Linux-specific error logs and diagnostic tools (e.g., /var/log, journalctl) where appropriate.
  • Clearly indicate at the start of the document that the content is Windows-specific, and provide a link to Linux-focused documentation if available.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation consistently lists Windows-related options and SKUs before Linux equivalents, and pricing is described in terms of Windows SKUs (e.g., 'charged as if you have one instance of Windows I1v2'). There is a lack of Linux-specific examples, pricing references, or parity in SKU explanations. Windows containers and plans are mentioned with specific notes, while Linux is only referenced generically, with no detailed Linux-specific guidance or examples.
Recommendations:
  • When listing supported workloads, alternate or parallelize the order of Windows and Linux (e.g., 'Linux web apps, Windows web apps').
  • In pricing sections, provide Linux-specific pricing details and examples alongside Windows, or clarify if pricing is identical.
  • In SKU tables and notes, explicitly mention Linux container support and any limitations, not just Windows.
  • Where Windows-specific limitations are called out (e.g., 'Windows containers don't support large SKUs'), provide equivalent Linux information, even if just to state there are no such limitations.
  • Include Linux-focused usage scenarios or configuration examples to ensure parity.
  • If referencing Windows tools or patterns (such as SKUs named after Windows), clarify Linux applicability or provide Linux-specific alternatives.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows bias by referencing Visual Studio and its NuGet package manager as the primary method for installing dependencies, with CLI instructions only mentioned secondarily. It also describes UI-based steps such as right-clicking folders and using the Azure Portal, which are more familiar to Windows users. There are no explicit Linux or cross-platform development environment examples, nor are there terminal-based instructions for common Linux workflows (e.g., using VS Code, command-line file creation, or deployment via CLI).
Recommendations:
  • Provide parallel instructions for Linux users, such as using VS Code or command-line editors to create and edit files.
  • List CLI-based NuGet installation instructions before or alongside Visual Studio GUI steps.
  • Include examples of setting environment variables and deploying using Azure CLI or GitHub Actions, not just via the Azure Portal.
  • Avoid Windows-centric terminology like 'right-click' and instead describe file creation in a platform-neutral way.
  • Explicitly mention that all steps can be performed on Linux, macOS, or Windows, and provide any OS-specific notes as needed.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page exhibits Windows bias primarily by referencing Azure Storage Explorer with Windows-specific instructions and links (e.g., 'tabs=windows'), and by omitting Linux equivalents or cross-platform alternatives for key steps such as generating SAS tokens and uploading files. There are no examples or guidance for Linux users regarding these operations, and the only GUI tool mentioned is Storage Explorer, which is often presented with a Windows focus. The CLI examples (Azure CLI) are cross-platform, but initial setup and file management steps lack Linux parity.
Recommendations:
  • Provide explicit instructions or examples for Linux users, such as using Azure CLI or azcopy for uploading files and generating SAS tokens.
  • Avoid linking to documentation or instructions that are Windows-specific unless Linux/macOS alternatives are also provided.
  • Mention and demonstrate cross-platform tools (e.g., azcopy, Azure CLI) for all file management and SAS generation tasks.
  • If referencing Azure Storage Explorer, clarify its availability on Linux/macOS and provide relevant instructions or screenshots.
  • Ensure that all steps, especially those involving file operations, have both GUI and CLI options, with clear notes on platform compatibility.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ windows_first
Summary:
The documentation page demonstrates a strong Windows bias by exclusively providing PowerShell examples for per-app scaling, referencing Azure PowerShell cmdlets, and omitting equivalent CLI or Linux-native instructions. There are no Bash, Azure CLI, or cross-platform scripting examples, and the PowerShell approach is presented first and exclusively, which may disadvantage Linux or macOS users.
Recommendations:
  • Add equivalent Azure CLI (az) examples for all PowerShell commands to ensure Linux and macOS users can follow along without needing PowerShell.
  • Include Bash scripting examples where appropriate, especially for configuring app settings or deploying ARM templates.
  • Explicitly mention that PowerShell examples are cross-platform only if true, or clarify platform requirements.
  • Reorder or parallelize documentation sections so that PowerShell and CLI examples are presented together, or alternate which comes first.
  • Reference Linux-native tools or workflows where possible, such as using curl or jq for REST API calls, or using the Azure portal for platform-agnostic instructions.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation provides both Azure CLI and Azure PowerShell examples for finding outbound IP addresses, but the PowerShell examples are presented alongside CLI examples without clarifying platform applicability. There is no explicit mention that PowerShell commands are Windows-centric, nor is there a Bash/Linux shell example for PowerShell commands. Additionally, outbound IPv6 support is noted as being available only for Windows apps, with no Linux parity or roadmap mentioned.
Recommendations:
  • Clearly indicate which commands are platform-specific (e.g., label PowerShell examples as Windows-only, and Azure CLI as cross-platform).
  • Provide Bash/Linux shell equivalents for PowerShell commands, or clarify that Azure CLI commands are recommended for Linux/macOS users.
  • When mentioning features (like outbound IPv6) that are Windows-only, provide a status update or roadmap for Linux support, or at least acknowledge the limitation more prominently.
  • Where possible, provide Linux-specific troubleshooting or usage notes, especially in sections that discuss testing connectivity or command-line usage.
  • Consider ordering examples with cross-platform tools (Azure CLI) first, and PowerShell (Windows-specific) second, to avoid implicit Windows-first bias.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation exhibits mild Windows bias. Windows-specific features and limitations (such as Windows Containers subnet sizing and Windows Server Active Directory domain join) are described in detail, while Linux-specific scenarios are only briefly mentioned (e.g., a single note about Linux continuous deployment network dependencies). There are no Linux-specific configuration examples, troubleshooting steps, or parity discussions. Windows terminology and features (e.g., Kudu console, Windows Containers, Windows Server AD) are referenced without Linux equivalents or alternatives.
Recommendations:
  • Add Linux-specific examples for subnet sizing, container deployment, and troubleshooting (e.g., how Linux containers affect subnet IP usage).
  • Include equivalent Linux tools and patterns (e.g., reference SSH, Bash, or Linux-native troubleshooting utilities alongside Kudu and Windows tools).
  • Provide parity in limitations and feature descriptions for Linux (e.g., discuss any Linux-specific networking or integration caveats).
  • Expand the Linux continuous deployment section to include more details and examples, such as common dependencies, troubleshooting, and configuration steps.
  • Ensure that references to Windows features (e.g., Windows Containers, Windows Server AD) are balanced with Linux alternatives or a clear statement if not applicable.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing the Azure portal (a web UI, but often associated with Windows-centric workflows), and in the 'Next steps' section, it only provides guidance for integrating with Power BI, a Microsoft Windows tool. There are no examples or references to Linux-native tools, CLI workflows, or open-source alternatives for monitoring or visualizing metrics. No Linux command-line (e.g., Azure CLI, Bash, or Kusto Query Language via CLI) examples are provided, and the documentation does not mention or prioritize Linux or cross-platform approaches.
Recommendations:
  • Include examples using Azure CLI and Bash scripts to retrieve and visualize metrics, ensuring parity with portal-based instructions.
  • Add references and examples for open-source or cross-platform visualization tools (e.g., Grafana) that can consume Azure Monitor metrics.
  • Provide Kusto Query Language (KQL) examples that can be run from the Azure Cloud Shell (which is cross-platform) or from Linux terminals.
  • In the 'Next steps' section, include links to documentation on integrating Azure Monitor with non-Windows tools and environments.
  • Explicitly mention that the Azure portal and Azure Monitor are accessible from any OS, and provide screenshots or instructions from a Linux perspective where relevant.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page exhibits several signs of Windows bias. It references Windows-specific tools (such as IIS diagnostics, Procdump, and PowerShell), and links to resources with 'Windows' in the title. Examples and instructions for troubleshooting and diagnostics (e.g., enabling .NET Profiler, using Kudu console) are focused on Windows environments, with no mention of Linux equivalents or alternatives. PowerShell is suggested for app management, but Bash/CLI alternatives are not presented. There are no examples or guidance for Linux-based App Service environments, which are common in Azure.
Recommendations:
  • Add explicit instructions and examples for Linux-based App Service environments, including how to enable diagnostics, collect logs, and troubleshoot performance issues.
  • Include Bash/Azure CLI commands alongside PowerShell for managing and restarting apps.
  • Reference Linux-compatible tools for memory dumps and diagnostics (e.g., gcore, strace, lsof), and explain how to use them in App Service on Linux.
  • Clarify which features and extensions (such as Application Insights Profiler, Kudu console) are available or behave differently on Linux, and provide links to Linux-specific documentation.
  • Avoid using 'Windows' in resource titles or links unless the content is truly Windows-only; provide parity links for Linux where possible.
  • Ensure that troubleshooting steps and mitigation strategies are presented for both Windows and Linux environments, or clearly indicate any platform limitations.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation demonstrates a Windows-first bias: logging types and features are described for Windows in more detail and are listed first, with Linux-specific instructions and limitations often relegated to later sections or footnotes. Several advanced logging features (web server logging, detailed error messages, failed request tracing) are available only for Windows, with no Linux equivalents or workarounds described. Examples and tooling references (such as Log Parser and Visual Studio) are Windows-centric, and Linux-specific logging patterns or tools are not mentioned.
Recommendations:
  • Provide Linux-specific examples and instructions alongside Windows instructions, not after them.
  • Clearly indicate feature parity (or lack thereof) for Linux and suggest alternative approaches or workarounds for missing features.
  • Include references to Linux-native tools for log access and analysis (e.g., tail, grep, less, jq for JSON logs) where appropriate.
  • Offer code samples for logging in popular Linux-supported languages and frameworks (e.g., Node.js, Python, Java) and show how to configure them for Azure App Service.
  • If certain logging types (like web server logging or failed request tracing) are unavailable on Linux, explicitly state this and suggest alternative monitoring or debugging strategies.
  • Mention cross-platform tools (such as Azure CLI, Kudu, or Azure Storage Explorer) equally for both platforms.
  • Balance the order of presentation so that Linux and Windows instructions are given equal prominence.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows-specific instructions, tools, and examples (such as PowerShell cmdlets, Windows environment variable setup, and certificate management) are presented first and in greater detail. PowerShell-based authentication and runbook examples are provided without equivalent Bash or Python/Linux-native examples. Some features (like Hybrid Worker Credentials) are explicitly unsupported on Linux, but this is not always clearly highlighted up front. Linux instructions are present but often less detailed, and Linux-native scripting or tooling (other than GPG for signing) is underrepresented.
Recommendations:
  • Provide Linux-native command-line examples (e.g., Bash scripts) alongside PowerShell examples for common tasks such as starting runbooks, authentication, and environment variable management.
  • Present Windows and Linux instructions in parallel sections or tabs, rather than listing Windows first and Linux second.
  • Include Linux-specific troubleshooting steps and references to Linux tools (e.g., systemd, journalctl, or relevant log file locations) where appropriate.
  • Where features are unsupported on Linux (e.g., Hybrid Worker Credentials), clearly state this at the beginning of the relevant section.
  • Offer Python or Bash runbook examples in addition to PowerShell, especially in authentication and automation scenarios.
  • Reference Linux documentation (e.g., man pages, official Python or Bash docs) as frequently as Windows/PowerShell documentation.
  • Ensure parity in detail and clarity between Windows and Linux instructions, including explicit steps for common Linux distributions.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ windows_first
Summary:
The documentation provides detailed instructions and a code sample for enabling diagnostic logs using PowerShell, a Windows-centric tool, but does not provide equivalent examples for Linux users (e.g., Azure CLI, Bash, or ARM templates). The only automation example is in PowerShell, and there is no mention of Linux-native tools or cross-platform alternatives. The order of presentation also places the PowerShell example before any mention of Azure CLI or Bash, which are more commonly used on Linux.
Recommendations:
  • Add equivalent Azure CLI (az) examples for enabling diagnostic logs, as Azure CLI is cross-platform and widely used on Linux.
  • Include Bash script samples or ARM/Bicep template snippets to demonstrate automation for Linux and cross-platform users.
  • Explicitly mention that PowerShell is just one way to automate configuration, and provide links or references to Linux-friendly tools.
  • Reorder the automation sections to present Azure CLI or cross-platform methods before or alongside PowerShell, to avoid implying Windows-first workflows.
  • Consider adding a table comparing methods (Portal, PowerShell, Azure CLI, ARM/Bicep) for enabling diagnostic logs, with links to each.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows/Powershell bias by providing migration and registration/unregistration examples exclusively using Azure PowerShell commands, with no equivalent Bash or Linux-native Azure CLI examples. The only automation script referenced is a PowerShell script, and there is no mention of Linux tools or cross-platform scripting approaches. This may disadvantage Linux users or those preferring Bash scripting.
Recommendations:
  • Provide equivalent Azure CLI (bash/shell) command examples alongside PowerShell commands for all operations, especially for migration and feature registration/unregistration.
  • Reference both PowerShell and Bash/CLI scripts where automation is discussed, or clarify if scripts are cross-platform.
  • Explicitly mention cross-platform compatibility of tools and scripts, or provide links to Linux/macOS instructions where available.
  • Ensure that tutorials and 'Next steps' sections include links to both PowerShell and CLI-based guides.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation demonstrates some Windows bias, particularly in the Java section where PowerShell and Cmd examples are given equal prominence to Bash, and Windows-specific patterns (e.g., referencing Cmd, PowerShell, and Windows-style paths) are present. The general instructions refer to 'command prompt' alongside 'terminal', and some file path examples use backslashes. However, Linux tools like jq and Bash are mentioned, and most CLI examples are cross-platform. There are no outright missing Linux examples, but Windows tools and patterns are sometimes mentioned first or exclusively.
Recommendations:
  • Ensure that Bash/Linux examples are always presented first or at least equally alongside Windows (PowerShell/Cmd) examples.
  • Avoid using Windows-style paths (backslashes) in generic instructions; use forward slashes or note both styles.
  • Where possible, use 'terminal' as the default term, and only mention 'command prompt' or 'PowerShell' when specifically relevant.
  • In tables or multi-tabbed code blocks, default to Bash or provide clear parity between Bash and Windows shells.
  • Review all file references and code snippets to ensure they are cross-platform, and explicitly call out any OS-specific differences.
  • Where Windows tools or patterns are mentioned, ensure Linux equivalents are also referenced and given equal prominence.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation for creating an SMB volume in Azure NetApp Files demonstrates a Windows-centric bias. All examples and instructions for managing SMB permissions and shares are provided exclusively for Windows environments, using Windows tools such as MMC and referencing Windows-specific workflows. There are no examples or guidance for Linux clients, even though SMB is supported on Linux via tools like smbclient or mount.cifs. The documentation assumes the administrator is operating from a Windows system, omitting parity for Linux-based management or access.
Recommendations:
  • Add equivalent instructions and examples for managing SMB shares and permissions from Linux clients, using tools such as smbclient, mount.cifs, or setfacl.
  • Include screenshots or command-line examples for accessing and mounting SMB volumes from Linux systems.
  • When describing SMB features (such as encryption or access-based enumeration), clarify how these features behave or can be configured from both Windows and Linux clients.
  • Avoid assuming the use of Windows-only tools (like MMC) and provide cross-platform alternatives where possible.
  • In sections where Windows-specific commands or interfaces are mentioned, add parallel Linux instructions or links to relevant Linux documentation.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation page exhibits a subtle Windows bias. While it covers multiple programming languages, the installation instructions and environment variable conventions are presented in a way that implicitly assumes Windows as the default environment. For example, the use of double underscores (`__`) in environment variable names aligns with Windows conventions, while the Linux/UNIX convention of using colons (`:`) is only mentioned in a note. There are no explicit Linux shell (bash) or cross-platform CLI examples, and PowerShell is listed as a primary language pivot, but Linux-specific instructions or examples are missing.
Recommendations:
  • Provide explicit Linux/bash examples for environment variable configuration, such as using colons (`:`) in shell exports.
  • Include cross-platform CLI instructions (e.g., Azure CLI commands) for installing extensions and setting environment variables.
  • Add a section or note at the beginning clarifying environment variable naming differences between Windows and Linux, with examples for both.
  • Ensure that PowerShell is not presented as the default or only scripting example; include bash/zsh equivalents where relevant.
  • List Linux and Windows instructions side-by-side when discussing local development, configuration, or tooling.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows-specific tools, settings, and commands are often mentioned before or more prominently than their Linux equivalents. Some CLI examples and configuration instructions are Windows-centric or lack explicit Linux parity. PowerShell and Visual Studio are highlighted as primary tools, with less emphasis on Linux-native workflows or editors. In some areas, Linux instructions are present but less detailed or appear after Windows instructions.
Recommendations:
  • Ensure all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
  • Where PowerShell or Windows-specific tools are mentioned, provide equivalent Bash or Linux-native commands and workflows.
  • In tables and lists, avoid listing Windows tools or editors first by default; alternate or group by platform.
  • Expand Linux-specific guidance, especially for deployment, debugging, and environment configuration.
  • Highlight cross-platform tools (such as VS Code, Azure CLI, and .NET CLI) before platform-specific ones.
  • Where Visual Studio is mentioned, ensure parity with VS Code and CLI-based workflows for Linux users.
  • Review all code and command snippets to ensure they are either cross-platform or have clear Linux alternatives.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation demonstrates a moderate Windows bias. Windows and SQL Server solutions are given their own prominent section, and Windows-specific tools and patterns (such as DFS Namespaces, SMB, FSLogix, and Windows DFS-N) are mentioned explicitly and sometimes before Linux equivalents. Some sections (e.g., Virtual Desktop Infrastructure) focus almost exclusively on Windows technologies, with little or no Linux alternative coverage. There are also references to Windows-specific high availability and deployment guides for SAP, sometimes listed before Linux guides. While Linux workloads are represented, the structure and example selection often prioritize or assume Windows environments.
Recommendations:
  • Ensure Linux and Windows solutions are presented with equal prominence and parallel structure, including in section ordering and headings.
  • For every Windows-specific tool or pattern (e.g., DFS-N, SMB, FSLogix), provide Linux/NFS or open-source alternatives and examples, or explicitly state if not applicable.
  • Where possible, add Linux-focused examples for Virtual Desktop Infrastructure (e.g., Linux VDI solutions or profile management).
  • In SAP solution sections, alternate the order of Windows and Linux guides, or group by OS with clear parity.
  • Review all reference lists to ensure that for each Windows example, a Linux equivalent is provided where feasible.
  • Highlight cross-platform tools and patterns (e.g., NFS, Trident, Kubernetes) in both Windows and Linux contexts.
  • Avoid language that assumes Windows as the default or primary platform.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows bias by prioritizing Windows tools and workflows, providing detailed step-by-step instructions for setting SACLs using Windows GUI, and referencing PowerShell for feature registration. Linux/NFS instructions are less detailed, often referring users to other documentation rather than providing direct steps. There is a lack of parity in example depth and tool coverage for Linux users.
Recommendations:
  • Provide step-by-step instructions for setting Audit ACEs on NFSv4.1 volumes directly in this document, using common Linux tools (e.g., setfacl, nfs4_setfacl), rather than linking out.
  • Include CLI examples for both Azure PowerShell and Azure CLI side-by-side when discussing feature registration and management.
  • Balance the order of presentation so that Linux/NFS instructions are given equal prominence and detail as Windows/SMB instructions.
  • Explicitly mention Linux equivalents for all Windows-specific tools and workflows, including screenshots or command-line examples where appropriate.
  • Add troubleshooting and best practices sections for Linux environments, similar to those provided for Windows.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows bias by providing only Azure PowerShell commands for feature registration and status checking, with Azure CLI (cross-platform) commands mentioned only as an afterthought in text, not as explicit examples. No Linux- or macOS-specific instructions or screenshots are provided, and the step-by-step examples assume a GUI workflow without clarifying platform neutrality.
Recommendations:
  • Provide explicit Azure CLI command examples alongside PowerShell commands for all registration and status-checking steps.
  • Present Azure CLI examples before or alongside PowerShell examples to avoid implying Windows-first workflows.
  • Clarify that the GUI steps are platform-agnostic or provide notes/screenshots for Linux/macOS users if there are differences.
  • Include a section or note confirming that all steps can be performed from Linux/macOS environments using Azure CLI or the Azure Portal.
  • Where possible, use neutral terminology (e.g., 'run this command in your terminal or shell') instead of assuming PowerShell usage.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows bias by explicitly mentioning PowerShell and the Azure portal as management tools, without referencing Linux-native tools or CLI alternatives. The examples and workflow descriptions prioritize Windows-centric tools and patterns, with no mention of Bash, Azure CLI, or Linux automation approaches. There are no Linux-specific examples or guidance, which may leave Linux users underserved.
Recommendations:
  • Include Azure CLI (az) examples alongside or instead of PowerShell for management tasks, as Azure CLI is cross-platform and widely used on Linux.
  • Mention Bash scripting and Linux automation tools as alternatives to PowerShell for DevOps workflows.
  • Explicitly state that all management operations can be performed from Linux, macOS, or Windows, and provide links to relevant cross-platform documentation.
  • Balance references to the Azure portal and PowerShell with equivalent instructions or links for Linux users.
  • Add a section or callout highlighting cross-platform support and best practices for Linux-based environments.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by exclusively using Azure portal and PowerShell/cmdlet-based workflows for all configuration steps, with no mention of Linux CLI or automation alternatives. Windows VM prerequisites are listed before Linux, and all operational examples are based on Windows-centric tools and patterns.
Recommendations:
  • Provide equivalent Linux command-line (e.g., Azure CLI, Bash, or REST API) instructions for each configuration task, not just PowerShell/cmdlets.
  • Include automation examples using cross-platform tools (such as Terraform, Ansible, or REST API calls) where possible.
  • List Linux and Windows VM prerequisites together or alternate their order to avoid implicit prioritization.
  • Reference Linux administration tools or scripts for managing vSAN features, where applicable.
  • Explicitly state if certain operations are only possible via Windows tools, and suggest workarounds or alternatives for Linux users.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias in several ways: PowerShell is used as the primary example for feature registration, with Azure CLI only mentioned secondarily and without explicit examples. There are no Linux-specific instructions or screenshots, and the UI instructions reference right-click actions, which are more typical of Windows environments. No parity is provided for Linux shell or automation workflows, and the documentation does not address Linux-specific considerations or tools.
Recommendations:
  • Provide explicit Azure CLI examples for all feature registration and management steps, including sample commands and expected output.
  • Include Linux shell (bash) equivalents for any PowerShell commands, especially for registration and status checking.
  • Add screenshots or instructions for Linux environments, such as using the Azure Portal in browsers on Linux or using CLI tools.
  • Avoid UI instructions that assume Windows-specific interactions (e.g., right-click); clarify how these actions are performed on other platforms.
  • Mention any Linux-specific considerations for NFS/SMB volumes, such as mount options, permissions, or automation scripts.
  • Ensure that all steps and examples are presented in a cross-platform manner, or provide tabs for Windows and Linux workflows.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation page demonstrates Windows bias by listing PowerShell as a primary tool for snapshot management, referencing Windows-centric scripting (PowerShell) before Linux alternatives, and omitting explicit Linux shell or command-line examples. While Azure CLI and REST API are mentioned (which are cross-platform), PowerShell is specifically highlighted, and there are no bash or Linux shell script examples. Additionally, external script examples reference SQL Server (a Windows-centric workload), and there is no mention of Linux-specific tools or usage patterns.
Recommendations:
  • Add explicit Linux shell (bash) examples for snapshot management alongside PowerShell, especially for common operations like create, restore, and delete.
  • When listing tools, mention cross-platform options (Azure CLI, REST API) before platform-specific ones (PowerShell), or group them together to avoid perceived prioritization.
  • Include example scripts for Linux environments, such as bash scripts using Azure CLI, to demonstrate parity.
  • Reference Linux workloads (e.g., Oracle, PostgreSQL) in addition to Windows-centric ones like SQL Server when discussing application-consistent snapshots.
  • Clarify that all listed tools (Azure CLI, REST API, PowerShell) are available on both Windows and Linux, and provide links to installation guides for both platforms.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ windows_heavy_examples
Summary:
The documentation for Azure NetApp Files exhibits a moderate Windows bias. Features and enhancements related to Windows technologies (such as SMB, Active Directory, and Windows-specific tools) are frequently mentioned, often before or in greater detail than their Linux/NFS counterparts. Several features are described primarily in the context of Windows environments (e.g., SMB Continuous Availability, Access-based Enumeration, non-browsable shares, and integration with Windows tools like Windows File Explorer). In some cases, Windows/SMB scenarios are explained in depth, while Linux/NFS features are mentioned more briefly or as secondary considerations. However, there is also significant Linux/NFS and dual-protocol coverage, and some Linux-specific tools (like AzAcSnap) are highlighted, indicating an effort toward cross-platform support.
Recommendations:
  • Ensure that for every Windows/SMB example or feature description, equivalent Linux/NFS examples and scenarios are provided with equal detail and prominence.
  • When introducing features that are protocol-specific (e.g., SMB vs. NFS), present both protocols together, or alternate which is mentioned first to avoid a consistent Windows-first ordering.
  • Where Windows tools or workflows (e.g., Windows File Explorer, Active Directory) are referenced, include parallel Linux tools or workflows (e.g., Linux file managers, LDAP, Kerberos) and provide usage guidance.
  • Expand documentation for Linux/NFS-specific features to match the depth and clarity of Windows/SMB sections, including troubleshooting, best practices, and integration tips.
  • Review language to ensure that Linux/NFS use cases are not treated as secondary or optional, but as first-class scenarios.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows bias by referencing Windows security features (e.g., BitLocker), mentioning Windows OS versions before Linux in prerequisites, and describing VBS as protecting 'windows system' specifically. There are no Linux-specific configuration examples or mentions of Linux disk encryption tools or security features, despite Linux being listed as a supported guest OS.
Recommendations:
  • Provide Linux-specific examples for vTPM usage, such as configuring disk encryption with LUKS or integrating with Linux security modules.
  • Mention Linux guest OS versions and features before or alongside Windows equivalents in prerequisites and feature descriptions.
  • Describe VBS benefits in a cross-platform manner, highlighting protections for both Windows and Linux systems.
  • Reference Linux security tools (e.g., dm-crypt, LUKS, SELinux) where BitLocker is mentioned for Windows.
  • Include screenshots or step-by-step instructions for configuring vTPM on Linux VMs, not just Windows.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation shows a mild Windows bias. Where remediation steps involve VMware Tools, the instructions reference 'VMware Tools for Windows' and provide no mention of Linux or cross-platform equivalents. The use of the Azure VMware Solution Run command 'Set-Tools-Repo' is described without clarifying its applicability to non-Windows environments. No Linux-specific examples or guidance are provided, and Windows is mentioned explicitly before Linux in the context of vulnerabilities and updates.
Recommendations:
  • For any mention of VMware Tools updates or vulnerabilities, specify whether the issue and remediation apply to both Windows and Linux guest operating systems. If remediation steps differ, provide instructions for both platforms.
  • When referencing commands like 'Set-Tools-Repo', clarify if they are applicable to Linux guests, and if not, provide equivalent steps or note any limitations.
  • Avoid using 'VMware Tools for Windows' as the default phrasing; instead, use 'VMware Tools' and then specify platform differences as needed.
  • Wherever possible, include Linux-specific examples or notes alongside Windows instructions to ensure parity.
  • Review all workaround instructions for implicit Windows assumptions and add Linux guidance where relevant.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation demonstrates a strong Windows/Azure VMware Solution bias. All operational instructions for installing, configuring, and managing JetStream DR are centered around the Azure portal and its 'Run command' feature, which is a Windows/Azure-specific tool. Cmdlet-based workflows (e.g., Invoke-PreflightJetDRInstall) are used throughout, with no mention of equivalent Linux CLI, shell, or cross-platform alternatives. There are no Linux or non-Azure examples, and the documentation assumes the use of Azure-specific tools and patterns, omitting any guidance for users operating in Linux environments or outside Azure.
Recommendations:
  • Provide equivalent Linux shell (bash) or cross-platform CLI instructions for installing, configuring, and managing JetStream DR, especially for on-premises deployments.
  • Include examples using standard VMware tools (e.g., vSphere CLI, ovftool) that are available on Linux, not just Azure portal or PowerShell cmdlets.
  • Document manual installation and configuration steps that do not rely on Azure 'Run command' or Windows-centric tools, for users who may not have access to these features.
  • Clearly indicate which steps are Azure-specific and provide alternative instructions for non-Azure or hybrid environments.
  • Add troubleshooting and operational guidance for Linux administrators, including how to monitor, manage, and automate JetStream DR from Linux systems.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ powershell_heavy
⚠️ missing_linux_example
Summary:
The documentation is heavily oriented toward Windows environments. All examples and instructions assume the use of Windows tools (Registry Editor, Certificate Import Wizard, right-click context menus, Notepad, etc.), and there is no mention of Linux equivalents or alternative procedures for Linux-based Azure Backup Server installations. The registry modification and certificate import steps are Windows-specific, and individual file recovery is only supported for Windows VMs. No Linux command-line or GUI alternatives are provided, and the documentation does not acknowledge or guide users who may be running Azure Backup Server on Linux or managing Linux VMs.
Recommendations:
  • Add instructions and examples for Linux environments, including certificate import steps using Linux tools (e.g., openssl, update-ca-certificates).
  • Clarify whether Azure Backup Server can be installed and used on Linux, and if not, explicitly state the Windows-only support.
  • Provide guidance for backing up and restoring Linux VMs, including any limitations or differences compared to Windows VMs.
  • Include alternative procedures for registry modifications or configuration changes for Linux, if applicable.
  • Ensure that individual file recovery instructions address Linux VMs, or clearly state the limitation and suggest alternative approaches for Linux workloads.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows bias by providing only PowerShell/PowerCLI examples for verifying DNS resolution, with no equivalent Linux or cross-platform command-line examples (such as nslookup or dig). The use of PowerCLI (a Windows/PowerShell-centric tool) is presented as the sole method for DNS verification, and no Linux-native tools or instructions are mentioned. The documentation also implicitly assumes the reader is using Windows tools by not offering alternatives.
Recommendations:
  • Add Linux-native command-line examples (e.g., using nslookup or dig from a Linux VM connected to the workload segment) for verifying DNS resolution.
  • Include instructions for performing DNS lookups from both Windows and Linux VMs within the Azure VMware Solution environment.
  • Where PowerCLI is used, provide equivalent steps using REST API calls (e.g., via curl) or platform-agnostic SDKs.
  • Explicitly mention that PowerCLI is optional and provide parity for users on non-Windows platforms.
  • Consider reordering or parallelizing examples so that Windows and Linux methods are presented together, rather than Windows/PowerShell first or exclusively.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation demonstrates Windows bias by exclusively referencing Windows-centric tools and workflows, such as PowerShell cmdlets (e.g., Set-vSANDataInTransitEncryption), and Azure portal Run command features that are typically Windows-oriented. There are no Linux CLI or automation examples, nor are Linux-specific tools or patterns mentioned. Windows Server Failover Clusters are called out as supported, but no equivalent Linux clustering solutions are referenced.
Recommendations:
  • Provide Linux CLI examples (e.g., using SSH, VMware CLI tools, or REST APIs) for configuring vSAN features.
  • Mention Linux-based clustering solutions (such as Pacemaker or Corosync) if supported, alongside Windows Server Failover Clusters.
  • Clarify whether the PowerShell cmdlets and Azure portal Run command features are accessible from Linux environments, or provide alternative instructions for Linux users.
  • Include notes or sections on how Linux administrators can perform equivalent configuration tasks, ensuring parity in guidance.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page demonstrates a Windows bias by providing restore scenarios and examples that focus exclusively on Windows VMs, particularly in the 'Restore an encrypted VM' scenario, which only references Windows-specific encryption and PowerShell tooling. There are no Linux-specific examples, nor are Linux disk encryption or restore processes mentioned, and Windows patterns/tools (PowerShell, Entra ID) are referenced without Linux equivalents.
Recommendations:
  • Add Linux-specific restore scenarios, especially for encrypted VMs (e.g., restoring VMs encrypted with Azure Disk Encryption for Linux or using dm-crypt).
  • Include examples and references for Linux tools and commands (such as Azure CLI or Bash scripts) alongside or before PowerShell examples.
  • Mention both Windows and Linux VM restore processes and any differences in supported features or steps.
  • Provide links to Linux documentation for disk encryption and restore processes, similar to the Windows links provided.
  • Ensure that general restore steps and terminology are OS-neutral unless a scenario is truly Windows-only, in which case clarify this explicitly.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ powershell_heavy
Summary:
The documentation exhibits a Windows bias in several ways: Windows-specific examples and references (such as PowerShell and Windows VM tutorials) are provided without equivalent Linux examples; Windows tools and patterns (like bcdedit, netdom, and RDP) are mentioned exclusively or before Linux alternatives; and guidance for Linux VMs is minimal or absent in key restore scenarios. This may hinder Linux users from fully understanding or utilizing the restore process.
Recommendations:
  • Provide Linux-specific examples and guidance alongside Windows instructions, especially in sections discussing restore scenarios, post-restore steps, and special configurations.
  • Include references to Linux tools and commands (e.g., using SSH, cloud-init, or Linux disk mounting procedures) where Windows tools like PowerShell, bcdedit, or netdom are mentioned.
  • Ensure that links to documentation for Linux VMs (such as restoring to availability sets, attaching disks, or resetting passwords) are present and as prominent as Windows links.
  • Add troubleshooting steps and post-restore actions specific to common Linux distributions, including guidance for handling cloud-init, SSH key management, and agent installation.
  • Balance the order of presentation so that Linux and Windows procedures are given equal prominence, or clearly indicate when a step is OS-specific.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows-first bias by mentioning Windows tools (Volume Shadow Copy Service - VSS) before Linux equivalents (fsfreeze) when discussing backup consistency mechanisms. It references Windows-specific VM Agent and snapshot extension documentation, but does not provide equivalent Linux links or examples. There are no Linux-specific backup configuration examples or guidance, and Linux tooling is mentioned only briefly and secondarily.
Recommendations:
  • Provide equal detail and documentation links for Linux VM Agent and snapshot extension equivalents.
  • Include Linux-specific examples or guidance for configuring crash-consistent and application-consistent backups.
  • Mention Linux tools (such as fsfreeze) before or alongside Windows tools (VSS) to avoid Windows-first ordering.
  • Add references to Linux documentation for VM backup consistency and agent installation.
  • Clarify any differences in backup behavior or requirements between Windows and Linux VMs.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation exhibits a Windows bias in several areas: Windows tools and processes (such as VSS and PowerShell) are mentioned first and in more detail, while Linux equivalents are described more generically or left to the user to implement (e.g., custom pre/post scripts). There are explicit PowerShell instructions for restore operations, but no equivalent CLI or Linux-native examples. Windows-specific backup mechanisms (VSS) are explained in depth, while Linux backup consistency is left to user scripting, with less guidance or examples.
Recommendations:
  • Provide Linux CLI (e.g., Bash, Azure CLI) examples alongside PowerShell for backup and restore operations.
  • Offer more detailed guidance and sample scripts for Linux app-consistent backups, similar to the VSS explanation for Windows.
  • Mention Linux tools (e.g., fsfreeze, LVM snapshots) explicitly and describe their role in backup consistency.
  • Ensure that Linux processes and tools are described with equal prominence and detail as Windows equivalents.
  • Where PowerShell is referenced for restore operations, include equivalent Azure CLI or Bash commands for Linux users.
GitHub Create pull request
Bias Types:
⚠️ missing_linux_example
⚠️ windows_tools
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation for the MARS agent is exclusively focused on Windows environments. All supported operating systems listed are Windows variants, and all installation, configuration, and troubleshooting steps reference Windows-specific tools (e.g., PowerShell, MMC, registry edits, DISM.exe). There are no examples, instructions, or even mentions of Linux or non-Windows platforms. The documentation assumes the reader is operating in a Windows-only environment, with no guidance for Linux users or parity in cross-platform support.
Recommendations:
  • Explicitly state in the introduction that the MARS agent is only supported on Windows, and provide links to equivalent Azure Backup solutions for Linux systems.
  • Where possible, mention alternative backup agents or methods for Linux (such as Azure Backup for Linux VMs or Azure Backup Server with Linux support).
  • If any cross-platform features exist (e.g., backup of files from SMB/NFS shares hosted on Linux), document them with clear Linux-specific instructions and examples.
  • Avoid assuming the use of Windows tools (like PowerShell, MMC, registry editing) without clarifying that these are not available on Linux, and offer Linux alternatives or workarounds where feasible.
  • Add a comparison table or section outlining backup options for both Windows and Linux environments, helping users choose the right solution for their OS.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation page exhibits Windows bias by prioritizing Windows-specific instructions and tools. PowerShell is mentioned as the method for creating a VM from restored disks, with no equivalent Linux CLI or Azure CLI example provided. The OS disk swap note links only to Windows documentation, and Linux-specific restore steps are relegated to a separate section with minimal detail. There is a lack of parity in examples and guidance for Linux users.
Recommendations:
  • Provide Azure CLI and/or Bash examples for restoring VMs and disks, alongside PowerShell instructions.
  • Include links to Linux-specific documentation for disk swap and VM restore operations.
  • Ensure that Linux restore steps are integrated throughout the main workflow, not separated or minimized.
  • Mention Linux tools and patterns (e.g., cloud-init, SSH) where relevant, and provide guidance for Linux-specific scenarios.
  • Review and update notes and references to avoid Windows-only links and terminology.
GitHub Create pull request
Bias Types:
⚠️ missing_linux_example
⚠️ windows_tools
Summary:
The documentation page focuses exclusively on assessing ASP.NET web apps, implicitly targeting Windows-based workloads (since classic ASP.NET is a Windows technology). There are no examples, tools, or guidance for assessing .NET web apps running on Linux, nor is there mention of Linux-specific considerations or tools. All referenced materials and linked tutorials appear to assume a Windows environment.
Recommendations:
  • Explicitly mention whether the assessment process supports both Windows and Linux-based .NET web apps, or clarify any limitations.
  • Include examples or notes for assessing .NET Core/ASP.NET Core apps running on Linux, if supported.
  • Reference Linux-compatible tools or command-line instructions (e.g., Bash, CLI) alongside any Windows/Powershell guidance.
  • Add a section addressing common Linux-specific migration or assessment concerns (such as file system differences, case sensitivity, or service dependencies).
  • Ensure that linked tutorials and best practices cover both Windows and Linux scenarios where applicable.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates Windows bias by referencing the Windows file path (C:\home\site\wwwroot) first and providing more detail for Windows path handling. Linux is only mentioned in a note, with no Linux-specific example or step-by-step guidance. There are no Linux shell or tool references, and the configuration instructions and examples are Windows-centric.
Recommendations:
  • Provide explicit Linux examples alongside Windows ones, such as using /home/site/wwwroot for file paths.
  • Include step-by-step instructions for Linux environments, not just notes about differences.
  • Mention Linux deployment tools or patterns where relevant, such as using SCP, SFTP, or Linux-based CI/CD pipelines.
  • Ensure parity in detail and clarity for both Windows and Linux users throughout the documentation.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation generally presents platform-neutral guidance, but there is evidence of Windows bias in the ordering and depth of examples. Key security configuration sections (authentication, Key Vault references, TLS/SSL) do not distinguish between Windows and Linux, and do not provide Linux-specific command-line examples or highlight Linux-specific tools until the 'Java key store in Linux' section, which appears last. There are no PowerShell or Windows command-line examples, but Linux-specific instructions (such as using SSH and keytool) are only mentioned in the Linux section, and not in the main authentication or Key Vault sections. The documentation refers to Azure portal configuration throughout, which is platform-neutral, but does not provide parity for Linux CLI workflows or troubleshooting until later.
Recommendations:
  • Add Linux-specific examples and command-line instructions (such as using SSH, keytool, or Azure CLI) in all relevant sections, not just the key store section.
  • Ensure that Linux workflows (such as configuring authentication, Key Vault references, and TLS/SSL) are described alongside or before Windows/portal workflows.
  • Explicitly mention any platform differences or limitations in each section, so Linux users know what applies to them.
  • Provide troubleshooting steps and examples for both Windows and Linux environments in all major configuration areas.
  • Consider adding a table or pivoted content at the top of each section to clarify platform-specific steps.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates Windows bias by referencing Windows in the quickstart links and example tabs (e.g., 'flask, windows, azure-cli, vscode-deploy, ...'), and by not providing explicit Linux or cross-platform deployment instructions. There are no Linux-specific examples, and Windows appears first in the context of setup and tooling. The documentation does not mention Linux tools or patterns, nor does it provide parity in example commands or environment setup for Linux users.
Recommendations:
  • Ensure that quickstart and setup instructions include explicit Linux and macOS tabs/examples alongside Windows, especially for environment setup and deployment.
  • Provide Linux-specific deployment instructions (e.g., using Bash, systemd, or Linux-native Azure CLI usage) in addition to or before Windows instructions.
  • Avoid referencing Windows first in tab lists or examples; use neutral or alphabetical ordering, or highlight cross-platform approaches.
  • Include troubleshooting or environment variable setup examples for Linux (e.g., exporting variables in Bash, using .env files in Linux environments).
  • Reference Linux tools (such as Bash, nano/vim for editing files, or Linux package managers) where appropriate, and ensure parity with Windows tooling.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation presents both Azure PowerShell and Azure CLI examples for feature registration and unregistration, but consistently lists PowerShell (a Windows-centric tool) before CLI. The CLI examples are present and correct, but there is a subtle 'Windows-first' ordering bias. No Linux-specific tools or shell examples (such as Bash scripts) are provided, and there is no mention of Linux environments or considerations. The documentation does not provide any examples that are exclusive to Windows, but the ordering and emphasis may suggest a preference.
Recommendations:
  • Alternate the order of PowerShell and CLI examples in different sections, or explicitly state that both are cross-platform and equally supported.
  • Add explicit mention that Azure CLI is cross-platform and can be used on Windows, Linux, and macOS.
  • Where possible, include Bash or shell script snippets for common tasks, especially in sections likely to be automated by Linux users.
  • Consider including a short section or note on using these commands in Linux environments (e.g., running Azure CLI in Bash).
  • Ensure parity in screenshots and walkthroughs by including CLI/terminal examples, not just portal or PowerShell interfaces.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation provides both Linux and Windows examples for filtering logs, but the Windows example is given immediately after the Linux one, and uses Windows-specific CLI patterns (findstr). There is a slight Windows bias in the ordering and explicit inclusion of Windows CLI syntax, while Linux is presented first. No PowerShell-only or Windows-only tools are used, and most commands are cross-platform (kubectl, helm). However, the documentation could improve Linux parity by ensuring equal prominence and clarity for Linux commands and avoiding Windows-first ordering or unnecessary Windows-specific syntax.
Recommendations:
  • Present Linux and Windows examples in parallel tabs or sections with equal prominence.
  • Clarify that most commands are cross-platform and only the filtering syntax differs.
  • Consider providing a table or side-by-side comparison for log filtering commands.
  • Avoid unnecessary repetition of Windows CLI syntax unless required for a specific use case.
  • Ensure Linux examples are not overshadowed by Windows-specific instructions.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates a Windows/.NET bias by listing .NET-based provider libraries first, providing only .NET Framework and ASP.NET Core sample links (which are Windows-centric), and omitting explicit Linux or cross-platform usage examples. There is no mention of Linux-specific tools, patterns, or sample applications, and the ordering prioritizes Windows technologies over Linux-native frameworks.
Recommendations:
  • Add explicit Linux usage examples for each provider library, especially for .NET (e.g., running on Ubuntu, Docker, or other Linux environments).
  • Include links to sample applications or guides for deploying configuration providers in Linux containers, cloud-native environments, or with Linux-based orchestration tools.
  • Balance the order of provider libraries to avoid implicit prioritization of Windows/.NET; consider grouping by language or platform family.
  • Mention cross-platform compatibility for .NET Standard and .NET Core providers, clarifying that they run on Linux and macOS as well as Windows.
  • Provide guidance or references for using configuration providers in popular Linux scenarios (e.g., with systemd services, in Kubernetes pods, etc.).
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation assumes a Windows-centric development environment by referencing Azure App Service, ASP.NET Core, and NuGet packages, and by providing instructions that implicitly target Windows users (e.g., use of GitHub Codespaces, dotnet CLI, and Azure Developer CLI without mentioning Linux-specific alternatives or considerations). There are no examples or instructions for Linux environments, such as using Linux-native tools, package managers, or deployment patterns. The tutorial does not mention how to run or deploy the sample app on Linux, nor does it address potential differences in configuration, permissions, or troubleshooting for Linux users.
Recommendations:
  • Add explicit instructions for running and deploying the sample app on Linux environments, including common Linux distributions.
  • Provide Linux-specific examples for installing .NET SDK, running dotnet CLI commands, and deploying to Azure App Service from Linux terminals.
  • Mention any differences in environment variables, file paths, or permissions that Linux users might encounter.
  • Include troubleshooting tips for Linux users, such as resolving common issues with .NET on Linux or configuring HTTPS.
  • Reference Linux-native editors (e.g., VS Code on Linux) and terminal usage, not just GitHub Codespaces.
  • Clarify that Azure App Service supports both Windows and Linux hosting, and link to documentation for Linux-based App Service plans.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation demonstrates per-environment configuration using Azure App Configuration in the context of an ASP.NET Core application. It references modifying 'launchSettings.json' and uses .NET CLI commands, but only describes environment setup via 'launchSettings.json', which is a Visual Studio/Windows-centric pattern. There are no examples or instructions for setting environment variables or running the app in Linux or macOS environments, nor is there mention of cross-platform development tools or patterns.
Recommendations:
  • Add instructions for setting environment variables in Linux/macOS (e.g., using export in bash or setting variables inline before dotnet run).
  • Mention alternative to 'launchSettings.json' for non-Windows environments, such as using shell environment variables or .env files.
  • Provide explicit examples for running the application in Linux/macOS terminals.
  • Clarify that the .NET CLI is cross-platform, and show parity in environment setup across operating systems.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page consistently references Power BI Desktop as the primary environment for examples and instructions, which is a Windows-only application. All screenshots and step-by-step guides are based on Power BI Desktop, with no mention of Power BI on Linux or alternative platforms. There are no examples or guidance for Linux users, nor any mention of Linux-specific tools or patterns.
Recommendations:
  • Include explicit guidance for Power BI users on Linux, such as using Power BI service via web browsers.
  • Add screenshots and examples for Power BI service (web) to demonstrate cross-platform usage.
  • Clarify platform limitations early in the documentation, and direct Linux users to supported alternatives.
  • Where possible, provide parity in instructions for both Windows (Power BI Desktop) and web-based Power BI service.
  • Avoid assuming Power BI Desktop as the default experience; balance examples between desktop and web.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation demonstrates a mild Windows bias by prioritizing Windows-specific tools and guidance. For example, in the installation section, Windows users are directed to use WSL (Windows Subsystem for Linux) rather than providing a native Windows redis-cli solution or mentioning third-party Windows builds. Additionally, Azure PowerShell is mentioned alongside Azure CLI for retrieving cache keys, and Windows Terminal is referenced as a way to access the Linux command line on Windows. Linux instructions are present and clear, but Windows users are consistently guided to use Linux tooling via WSL, which may not be ideal for all users.
Recommendations:
  • Provide information about native redis-cli builds for Windows, such as third-party binaries or official recommendations, if available.
  • Include explicit command examples for both Linux/macOS and Windows (native or via WSL), clarifying when WSL is required and when native tools can be used.
  • When listing methods to retrieve cache keys, present Azure CLI and Azure portal before Azure PowerShell, or group them without order bias.
  • Mention cross-platform alternatives (such as RedisInsight) earlier and emphasize their parity across operating systems.
  • Avoid referencing Windows-specific tools (like Windows Terminal) unless also mentioning equivalents for Linux/macOS.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation shows a mild Windows bias by using DOS-style code blocks (```dos) for all redis-benchmark command examples, which may imply a Windows command prompt context. There is no explicit mention of Linux or Bash environments in the redis-benchmark sections, and no Linux-specific guidance or examples are provided. However, the tools discussed (redis-benchmark, memtier-benchmark) are cross-platform, and the memtier-benchmark section uses Bash code blocks. No PowerShell-specific commands or Windows-only tools are present, but the ordering and code block types suggest a Windows-first perspective.
Recommendations:
  • Provide both Windows (CMD/PowerShell) and Linux (Bash) command examples for redis-benchmark usage.
  • Use neutral code block types (e.g., ```sh or ```bash) for redis-benchmark commands, or provide tabs for both environments.
  • Explicitly mention that redis-benchmark and memtier-benchmark are available on both Windows and Linux, and provide installation instructions or links for both platforms.
  • Add notes or troubleshooting tips for common Linux environments (e.g., Ubuntu, CentOS) alongside any Windows-specific advice.
  • Ensure that any references to CLI or shell usage clarify that both Windows and Linux shells are supported.
GitHub Create pull request
Bias Types:
⚠️ powershell_heavy
⚠️ windows_first
Summary:
The documentation provides a PowerShell example (Get-AzProviderFeature) for checking feature registration status, and only secondarily mentions the Azure CLI, without giving a concrete CLI example. No Linux-specific tools or shell commands are shown, and the PowerShell example is presented first, which may suggest a Windows-centric approach.
Recommendations:
  • Provide both Azure CLI and PowerShell command examples side by side, with equal prominence.
  • Include explicit Linux shell/CLI examples (e.g., az feature show) with sample output, not just a reference link.
  • When referencing tools or commands, avoid listing Windows/PowerShell first by default; alternate order or present both together.
  • Where possible, add notes about cross-platform compatibility for all commands and tools mentioned.
  • Consider including a table or section summarizing equivalent commands for Windows (PowerShell), Linux (Bash/CLI), and macOS.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ powershell_heavy
Summary:
The documentation generally maintains cross-platform parity, but there is a subtle Windows bias in the ordering and presentation of command-line examples. In several places, Windows (cmd) examples are presented alongside or before Bash, and PowerShell/CMD tabs are always present even when not strictly necessary. However, Linux-specific tools, patterns, or troubleshooting are not missing, and Linux is treated as a first-class citizen in most technical content.
Recommendations:
  • Ensure that Bash (Linux/macOS) examples are always presented first or at least equally with Windows CMD/PowerShell examples, especially in tabbed code blocks.
  • Where possible, clarify that all CLI commands work identically on Linux, macOS, and Windows, and highlight any OS-specific differences.
  • Consider including explicit Linux/macOS troubleshooting tips or environment notes where relevant (e.g., JAVA_HOME setup, file path conventions).
  • Avoid defaulting to Windows-centric terminology such as 'command prompt' without mentioning 'terminal' or 'shell' for Linux/macOS users.
  • Audit the order of tool recommendations (e.g., Visual Studio Code, IntelliJ, Eclipse) to ensure no implicit prioritization of Windows-preferred tools.
  • Add a brief section or callout at the top confirming full Linux/macOS support for all development workflows described.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation page demonstrates Windows bias primarily by referencing Windows-specific resources first, such as linking to the 'Create a PPG using the Azure portal' under the Windows documentation path (/azure/virtual-machines/windows/proximity-placement-groups-portal), without mentioning or providing equivalent Linux guidance. There are no examples or instructions tailored for Linux environments, and no Linux-specific tools or patterns are referenced.
Recommendations:
  • Include links to both Windows and Linux versions of Azure documentation when referencing platform-specific features (e.g., proximity placement groups).
  • Provide examples or instructions for creating and managing proximity placement groups and related resources using Linux tools (such as Azure CLI or Bash scripts), not just through the Azure portal or Windows-centric paths.
  • Explicitly mention that the guidance applies to both Windows and Linux SAP HANA deployments, or clarify any platform-specific differences.
  • Add Linux-focused best practices or considerations where relevant, especially for network configuration and VM management.
GitHub Create pull request
Bias Types:
⚠️ windows_tools
⚠️ missing_linux_example
Summary:
The documentation exclusively references VMware vSphere client GUI workflows and does not provide any examples or guidance for Linux-based management tools, CLI workflows, or cross-platform alternatives. All instructions assume use of the vCenter web client, which is most commonly accessed from Windows environments, and there is no mention of Linux command-line tools (such as ESXCLI, PowerCLI for Linux, or REST API usage from Linux shells) or parity for Linux administrators.
Recommendations:
  • Add examples for performing mount, unmount, attach, and detach operations using CLI tools available on Linux (e.g., ESXCLI, PowerCLI for Linux, or REST API calls via curl).
  • Explicitly mention cross-platform access to vCenter (e.g., using browsers on Linux, or using open-source clients).
  • Provide REST API usage examples with Linux shell commands (curl, jq) for operations currently described only via GUI.
  • Clarify that all operations can be performed from any OS with access to vCenter, and highlight any platform-specific considerations.
  • Include troubleshooting and verification steps that can be performed from Linux environments.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation demonstrates a Windows bias by exclusively referencing Windows-based jump boxes (Windows 10 or Windows Server) for management access, without mentioning Linux alternatives. There are no examples or guidance for deploying or accessing Azure VMware Solution environments using Linux VMs or tools. The documentation also refers to Active Directory-integrated DNS and domain controllers as the primary identity and DNS solution, which are Windows-centric technologies, with no mention of Linux-based identity or DNS options.
Recommendations:
  • Include examples and guidance for deploying Linux-based jump boxes for accessing Azure VMware Solution environments.
  • Mention SSH access patterns and Linux management tools alongside RDP and Windows tools.
  • Provide parity in instructions for configuring DNS and identity services using Linux-based solutions (e.g., Samba/Bind for DNS, LDAP/Kerberos for identity).
  • Clarify that both Windows and Linux VMs can be used for management and operational tasks, and provide links or references to relevant Linux documentation.
  • When discussing best practices, avoid assuming Windows as the default and present alternatives for Linux environments.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation consistently references Azure portal, Azure PowerShell, and Azure CLI for resource creation, but does not provide any Linux-specific examples or mention Linux tools or workflows. All configuration and management steps are described using the Azure portal UI or generic Azure CLI/PowerShell commands, with no reference to Linux-based administration, iSCSI multipathing configuration, or Linux VMFS mounting. The documentation assumes a Windows-centric workflow and omits Linux parity in examples and operational guidance.
Recommendations:
  • Add explicit Linux-based examples for connecting to Elastic SAN, such as using open-iscsi and multipath-tools for iSCSI configuration.
  • Include CLI commands and configuration steps for Linux environments, such as mounting VMFS datastores from Linux VMs.
  • Mention Linux equivalents alongside Azure PowerShell and CLI, and clarify cross-platform compatibility for all steps.
  • Provide troubleshooting guidance for Linux hosts, including log file locations and error handling.
  • Ensure screenshots and UI instructions are supplemented with command-line alternatives suitable for Linux administrators.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation demonstrates a Windows-first bias by instructing users to connect to the VM via RDP and linking to Windows-specific connection instructions. There is no mention of Linux-based access methods (such as SSH) for connecting to the VM, nor are Linux client tools or workflows referenced for accessing the vCenter or managing the deployment. However, later steps for configuring the appliance itself use Linux commands, indicating the appliance is Linux-based.
Recommendations:
  • Provide parallel instructions for connecting to the VM using SSH from Linux/macOS clients, not just RDP/Windows.
  • Include links to documentation for connecting to Azure VMs from Linux/macOS (e.g., using SSH or remote desktop clients available on those platforms).
  • When referencing connection methods, mention both RDP and SSH, and clarify which is appropriate for Windows and Linux users.
  • Ensure that all steps involving client-side actions (such as accessing vCenter or the VM) have Linux/macOS equivalents or alternatives documented alongside Windows instructions.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ missing_linux_example
Summary:
The documentation consistently references Windows-based virtual machines and links to Windows-specific guides (e.g., creating a Windows VM), without providing equivalent Linux examples or guidance. There are no Linux command-line or portal instructions, and the only VM creation example is for Windows. This creates a Windows-first impression and omits Linux parity.
Recommendations:
  • Include parallel instructions and links for creating and using Linux-based virtual machines in Azure, not just Windows VMs.
  • When referencing VM creation, provide both Windows and Linux quick-create guides, or use a neutral link to the general VM creation documentation.
  • Add examples or notes for validating connectivity and accessing vCenter/NSX Manager from both Windows and Linux VMs.
  • Review all screenshots and instructions to ensure they are not exclusively Windows-centric, or provide Linux equivalents where appropriate.
GitHub Create pull request
Bias Types:
⚠️ windows_first
⚠️ windows_tools
Summary:
The documentation page demonstrates a mild Windows bias. In the 'Install the VM agent' section, instructions for Windows appear first and are more detailed, including links to MSI installers and explicit file paths. The Linux instructions are less detailed and refer to distribution repositories, with a secondary mention of GitHub. The initial VM creation link points to a Windows-specific quickstart, and there is no mention of Linux VM creation or parity in portal operations. No PowerShell or CLI examples are present, and most steps are portal-based and OS-agnostic, but where OS-specific details are given, Windows is prioritized.
Recommendations:
  • Present Linux instructions before or alongside Windows instructions in the VM agent installation section.
  • Provide a link to the Linux VM creation quickstart in the introduction, alongside the Windows VM creation link.
  • Expand Linux agent installation details, including example commands for RPM/DEB installation and verification steps.
  • Ensure that screenshots and examples do not implicitly assume Windows VMs; clarify when steps apply equally to Linux VMs.
  • Add a note on any OS-specific backup considerations, such as application consistency or agent limitations, for both Windows and Linux.
GitHub Create pull request
Bias Types:
⚠️ windows_first
Summary:
The documentation page references PowerShell before Azure CLI when listing tools for creating resource groups, which may imply a Windows-first bias. However, both PowerShell and Azure CLI are mentioned, and no examples or commands are shown. There are no exclusive references to Windows tools, nor are there missing Linux examples, but the ordering suggests a subtle prioritization of Windows-centric tooling.
Recommendations:
  • When listing cross-platform tools such as PowerShell and Azure CLI, alternate their order or explicitly state that both are cross-platform.
  • Consider mentioning Azure CLI before or alongside PowerShell, as Azure CLI is often the default on Linux and macOS.
  • Where possible, provide explicit examples for both PowerShell and Azure CLI, or clarify that both are supported on all major platforms.
  • Avoid implying a default or preferred platform by tool ordering unless there is a technical reason.
GitHub Create pull request

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