283
Pages Scanned
38
Pages Flagged
283
Changed Pages
13.4%
% Pages Flagged

Live Progress

🔴 Connecting...
20%
Phase: discovery
Processing: Initializing...
Activity Feed
00:00:07 Scan started

Scan Information

Started At: 2025-08-02 00:00:07

Finished At: In Progress

Status: cancelled

Target Repo: Azure

Current Phase: discovery

Files Queued: 1401

Files Completed: 274

Problematic Pages

38 issues found
API Management https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/api-management/api-management-howto-use-managed-service-identity.md ...t/api-management-howto-use-managed-service-identity.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_first âš ī¸ missing_linux_example âš ī¸ windows_tools
Summary
The documentation demonstrates a Windows bias by providing only Azure PowerShell examples for command-line operations, with no mention of Azure CLI (which is cross-platform and commonly used on Linux/macOS). The PowerShell sections are prominent and detailed, while Linux-native tools or workflows are not addressed. Instructions for installing or using PowerShell are given, but there is no equivalent guidance for Linux users. The documentation implicitly assumes a Windows environment for scripting and automation.
Recommendations
  • Add equivalent Azure CLI examples alongside all Azure PowerShell examples, especially for creating and managing managed identities and API Management instances.
  • Include installation and usage instructions for Azure CLI, and clarify that it is cross-platform (Windows, Linux, macOS).
  • Where PowerShell is referenced, add a note or section for Bash/shell users, highlighting any differences or considerations.
  • Ensure that all automation and scripting instructions are provided for both PowerShell and Bash/CLI environments.
  • Review and update screenshots or UI references to ensure they are not Windows-specific if possible.
  • Explicitly mention cross-platform support and recommend tools that work equally well on Linux, macOS, and Windows.
API Management https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/api-management/export-rest-mcp-server.md ...main/articles/api-management/export-rest-mcp-server.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ missing_linux_example âš ī¸ windows_tools
Summary
The documentation page demonstrates a Windows bias by exclusively referencing Visual Studio Code (VS Code) and GitHub Copilot for testing and using the MCP server, without mentioning or providing examples for Linux-native tools or command-line alternatives. The instructions for configuration and usage are centered around the VS Code GUI and its settings files, which, while cross-platform, are most commonly associated with Windows workflows. There are no examples using Linux command-line tools (such as curl, httpie, or native Linux editors), nor are there references to Linux-specific environments or shell commands.
Recommendations
  • Provide equivalent instructions and examples for testing the MCP server using cross-platform command-line tools such as curl or httpie, which are widely available on Linux.
  • Include sample configuration and usage steps for Linux environments, such as editing JSON configuration files with nano, vim, or other Linux editors.
  • Mention and demonstrate how to interact with the MCP server using Linux-native tools or scripts, not just through VS Code.
  • Clarify that VS Code is available on Linux and macOS, but also offer alternative workflows for users who prefer not to use VS Code.
  • Ensure that any screenshots or file paths shown are either cross-platform or include Linux/macOS equivalents.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/configure-ssl-bindings.md ...ob/main/articles/app-service/configure-ssl-bindings.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy âš ī¸ missing_linux_example
Summary
The documentation page demonstrates a mild Windows bias. While the main workflow is described via the Azure Portal (which is cross-platform), the automation section lists PowerShell before Azure CLI, and only the PowerShell script is shown inline, with no equivalent Bash or Linux shell example. There is no mention of Linux-specific tools or workflows for uploading certificates or managing bindings, and the only explicit code sample is for PowerShell. The only nod to Linux is an indirect reference to a 'Linux Node.js configuration' guide in the FAQ, but no Linux command-line or scripting examples are provided on this page.
Recommendations
  • Provide Bash or Linux shell script examples alongside PowerShell in the automation section, or at least link to them.
  • List Azure CLI examples before or alongside PowerShell to avoid the appearance of Windows-first bias.
  • Include explicit instructions or references for Linux users when uploading certificates (e.g., how to generate or upload .pfx files from Linux).
  • Ensure that all code samples have both Windows (PowerShell) and Linux (Bash/CLI) equivalents.
  • Mention any platform-specific considerations (such as file paths or certificate handling differences) where relevant.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/overview-inbound-outbound-ips.md .../articles/app-service/overview-inbound-outbound-ips.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_first âš ī¸ missing_linux_example âš ī¸ windows_tools
Summary
The documentation page exhibits a moderate Windows bias. PowerShell examples are provided alongside Azure CLI, but there are no explicit Linux shell or Bash alternatives for PowerShell commands. The outbound IPv6 support section specifically notes that outbound IPv6 is only available for Windows apps, with Linux apps limited to IPv4. In several places, PowerShell is presented as a primary or co-equal method, but Linux-native tools or scripts are not mentioned. There is also a lack of explicit mention of Linux environments or tools, and the documentation does not clarify cross-platform compatibility for all commands.
Recommendations
  • For every PowerShell example, provide an equivalent Bash or Linux-native command (e.g., using Azure CLI in Bash, or REST API with curl).
  • Clarify in each code example which platforms are supported (e.g., 'This PowerShell command is for Windows; use Azure CLI for cross-platform').
  • Where outbound IPv6 is Windows-only, explicitly state this in summary tables and provide a roadmap or workaround for Linux users.
  • Add a section or callout summarizing cross-platform support for all commands and features discussed.
  • Ensure that Linux users are not required to use PowerShell for any management tasks; always provide a CLI or REST alternative.
  • Where the Azure portal is referenced, clarify that it is platform-agnostic.
Application Gateway https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/application-gateway/for-containers/quickstart-deploy-application-gateway-for-containers-alb-controller.md ...ploy-application-gateway-for-containers-alb-controller.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy âš ī¸ windows_tools
Summary
The documentation demonstrates a mild Windows bias, particularly in the Helm installation section, where Windows instructions (including a PowerShell/winget example) are presented before Linux instructions. The Windows-specific tool 'winget' is highlighted, while the Linux section is less detailed. However, most command-line instructions throughout the document use Azure CLI and Bash-compatible syntax, which is cross-platform. There are no Linux examples missing, but the ordering and detail favor Windows slightly.
Recommendations
  • Present Linux and Windows installation instructions for Helm with equal prominence and detail, possibly using side-by-side tabs or presenting Linux first.
  • Include explicit Bash and PowerShell equivalents for any command-line examples where differences exist.
  • Avoid highlighting Windows-specific tools (like winget) before cross-platform or Linux-native methods; instead, mention both approaches together or in parallel.
  • Ensure that all instructions are equally accessible and detailed for both Windows and Linux users, including troubleshooting tips or common issues for both platforms.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-web-configure-tls-mutual-auth.md ...p-service/app-service-web-configure-tls-mutual-auth.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy âš ī¸ windows_tools
Summary
The documentation demonstrates a moderate Windows bias. It prioritizes ASP.NET and ASP.NET Web Forms (Windows-centric frameworks) in its code samples, providing them before cross-platform or Linux-native frameworks. There is no mention of Linux-specific tools or shell commands (e.g., Bash, OpenSSL) for certificate management or validation. The Azure CLI example is cross-platform, but there are no Linux-specific configuration or troubleshooting examples, and the overall structure and sample order favor Windows development patterns.
Recommendations
  • Add Linux shell (Bash) and OpenSSL examples for certificate inspection and validation.
  • Include troubleshooting steps or notes for common Linux client/server environments (e.g., NGINX, Apache).
  • Provide parity in sample order: present cross-platform (Node.js, Java, Python) or Linux-native frameworks before or alongside Windows-centric ones.
  • Mention and link to Linux tools for certificate management (e.g., OpenSSL, certbot) where relevant.
  • Clarify that the Azure CLI commands work identically on Linux, macOS, and Windows.
  • If possible, add a section or tab for configuring mutual TLS in Linux-based App Service containers (e.g., Dockerfile or startup script examples).
Application Gateway https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/application-gateway/application-gateway-ssl-policy-overview.md ...ion-gateway/application-gateway-ssl-policy-overview.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation page demonstrates a Windows bias by referencing PowerShell and CLI as the primary tools for configuration and management, with PowerShell consistently mentioned first. There are no explicit Linux or Bash examples, and the only configuration walkthrough linked is for PowerShell. The documentation does not provide parity for Linux users or mention Linux-native tools or shell commands.
Recommendations
  • Provide explicit Bash/Azure CLI examples alongside or before PowerShell examples for all configuration steps.
  • Include links to Linux/Bash-focused configuration guides, not just PowerShell.
  • When referencing tools or commands, use cross-platform terminology (e.g., 'Azure CLI or PowerShell'), and ensure both are covered equally.
  • Add a 'Platform compatibility' section clarifying that all features are available via both Windows and Linux command-line tools.
  • Ensure that all 'Next steps' and example links include both PowerShell and Bash/CLI walkthroughs.
Application Gateway https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/application-gateway/application-gateway-autoscaling-zone-redundant.md ...eway/application-gateway-autoscaling-zone-redundant.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_tools âš ī¸ missing_linux_example
Summary
The documentation page references Azure PowerShell as the only example for creating an autoscaling, zone redundant application gateway, without mentioning or linking to equivalent instructions for Linux users (e.g., Azure CLI, ARM templates, or Bicep). This creates a bias toward Windows users and PowerShell-centric workflows, while omitting Linux-preferred tools and examples.
Recommendations
  • Add links to equivalent tutorials using Azure CLI, ARM templates, or Bicep for creating autoscaling, zone redundant application gateways.
  • When listing 'Next steps', ensure that both PowerShell and CLI (cross-platform) options are presented, ideally with CLI listed first or alongside PowerShell.
  • Explicitly mention that Azure CLI and ARM/Bicep templates are supported and provide references or code snippets for these tools.
  • Review the documentation for other sections where only PowerShell is referenced and add Linux-friendly alternatives.
Application Gateway https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/application-gateway/how-to-troubleshoot-application-gateway-session-affinity-issues.md ...oubleshoot-application-gateway-session-affinity-issues.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_tools âš ī¸ missing_linux_example âš ī¸ windows_first
Summary
The documentation demonstrates a Windows bias by providing PowerShell as the only CLI example for checking Application Gateway settings, exclusively referencing the Windows-only Fiddler tool for network debugging, and omitting equivalent Linux command-line or tool instructions. No Linux-native alternatives (such as Azure CLI, curl, tcpdump, or Wireshark) are mentioned, and the order of presentation assumes a Windows environment by default.
Recommendations
  • Provide Azure CLI examples (az network application-gateway ...) alongside or instead of PowerShell for cross-platform parity.
  • Mention and give examples using Linux-compatible network debugging tools such as tcpdump, Wireshark, or mitmproxy in addition to Fiddler.
  • Include instructions for installing and using these tools on Linux/macOS, not just Windows.
  • When referencing tools or commands, avoid assuming the user is on Windows; present cross-platform options or note OS-specific steps.
  • Ensure screenshots and walkthroughs include at least one example from a Linux or macOS environment.
Application Gateway https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/application-gateway/key-vault-certs.md ...b/main/articles/application-gateway/key-vault-certs.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_first âš ī¸ missing_linux_example âš ī¸ windows_tools
Summary
The documentation page demonstrates a significant Windows bias. PowerShell is the only scripting example provided for configuring Key Vault integration with Application Gateway, with no equivalent Azure CLI (cross-platform) or Bash/Linux shell examples. The narrative and examples prioritize PowerShell and Windows-centric tools, and the 'Next steps' section links only to a PowerShell-based guide. There is no mention of Linux-specific workflows or parity in command-line instructions.
Recommendations
  • Provide equivalent Azure CLI examples for all PowerShell scripts, as Azure CLI is cross-platform and widely used on Linux and macOS.
  • Include Bash or shell script snippets where appropriate, especially for deployment automation.
  • In sections where PowerShell is referenced, mention Azure CLI as an alternative and provide links to relevant CLI documentation.
  • Ensure that 'Next steps' and further reading sections include links to both PowerShell and Azure CLI guides.
  • Explicitly state that all operations can be performed from Linux/macOS using Azure CLI or ARM/Bicep templates, and provide examples.
  • Review screenshots and UI instructions to ensure they are not Windows-specific, or clarify that the steps are platform-agnostic.
Automation https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/automation/manage-runtime-environment.md ...main/articles/automation/manage-runtime-environment.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_tools âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation exhibits a clear bias toward Windows and PowerShell environments. Most examples, especially for creating and managing runtime environments and runbooks, focus on PowerShell, with detailed steps and REST API payloads for PowerShell scenarios. References to Windows-specific tools (e.g., PowerShell Gallery, Get-Module cmdlet, .zip files for modules) are prevalent, while Linux/Python equivalents are either briefly mentioned or omitted. The documentation often presents PowerShell/Windows approaches first and in more detail, with Linux/Python support appearing as side notes or afterthoughts.
Recommendations
  • Provide parallel, detailed examples for Python runbooks and Linux-based runtime environments, including REST API payloads and portal steps.
  • Include Linux/Python-specific tooling and patterns (e.g., using pip, requirements.txt, .tar.gz/.whl files) alongside PowerShell/Windows instructions.
  • Balance the order of presentation so that Linux/Python approaches are given equal prominence and detail as PowerShell/Windows.
  • Reference both PowerShell Gallery and Python Package Index (PyPI) for package management, and provide guidance for both ecosystems.
  • Add explicit Linux/Python code snippets and screenshots where only PowerShell/Windows examples are currently shown.
  • Clarify when instructions or features are Windows/PowerShell-specific versus cross-platform.
Automation https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/automation/troubleshoot/extension-based-hybrid-runbook-worker.md .../troubleshoot/extension-based-hybrid-runbook-worker.md
High Priority View Details →
Reviewed by: Unknown
Issues: 5 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ powershell_heavy âš ī¸ windows_registry_focus âš ī¸ windows_event_log_focus
Summary
The documentation generally provides parity between Windows and Linux for most troubleshooting steps, with separate sections and commands for each OS. However, there is a consistent pattern of presenting Windows examples, tools, and troubleshooting steps before their Linux equivalents. Several scenarios and troubleshooting steps are Windows-specific, focusing on PowerShell commands, Windows registry, event logs, and folder permissions, with less emphasis or equivalent detail for Linux. Some troubleshooting advice and monitoring steps reference Windows-only tools or logs (e.g., Microsoft-SMA event logs, registry keys), and Windows-specific issues are described in more detail than Linux-specific ones.
Recommendations
  • Alternate the order of Windows and Linux instructions or present them in parallel to avoid always listing Windows first.
  • Where possible, provide equivalent Linux commands or log locations for steps that currently reference only Windows tools (e.g., event logs, registry).
  • Expand Linux troubleshooting scenarios to match the depth and specificity of Windows-focused sections (e.g., permissions, user management, service status).
  • Include Linux-native troubleshooting tools and patterns (e.g., journalctl, systemd logs, Linux file permissions) alongside Windows event logs and registry references.
  • Ensure that all PowerShell-heavy instructions have Bash or Python equivalents for Linux environments.
  • Add more Linux-specific troubleshooting scenarios, especially for common issues like permissions, service failures, or log analysis.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/dotnet-isolated-process-guide.md ...icles/azure-functions/dotnet-isolated-process-guide.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ missing_linux_example
Summary
The documentation demonstrates a mild Windows bias. Windows-specific tools and configuration steps are often mentioned before or in more detail than their Linux equivalents. Some CLI examples and configuration steps are provided only for Windows or are presented with Windows first, and PowerShell/Azure PowerShell is referenced as a primary method for resource creation. Linux-specific instructions are present but sometimes less prominent or detailed. There are also sections where Linux deployment/configuration is only briefly mentioned or lacks parity in example depth.
Recommendations
  • Ensure that all CLI and configuration examples are provided for both Windows and Linux, with equal prominence and detail.
  • When listing tools or methods (e.g., Visual Studio, Visual Studio Code, CLI, PowerShell), alternate the order or present them in parallel lists/tables to avoid always listing Windows-first.
  • Where PowerShell is mentioned, ensure Bash/Azure CLI equivalents are also included and shown with equal detail.
  • For deployment and configuration commands, provide both Windows and Linux command-line examples side by side, not just as tabs.
  • Explicitly mention any differences or caveats for Linux users, especially for local development, debugging, and deployment.
  • Audit all code snippets and walkthroughs to ensure Linux users are not required to infer steps or commands from Windows-centric instructions.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-app-settings.md ...ain/articles/azure-functions/functions-app-settings.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ powershell_heavy
Summary
The documentation is generally cross-platform, but there are subtle Windows biases. In several places, Windows-specific tools or patterns are mentioned first or exclusively (e.g., PowerShell, Windows environment variable delimiters, and Windows-specific settings like WEBSITE_NODE_DEFAULT_VERSION). PowerShell is listed as a first-class language, and some settings (like AzureWebJobs_TypeScriptPath) use Windows path syntax. In a few cases, Windows-specific behaviors or settings are described in more detail than Linux equivalents. However, Linux is referenced in many places, and Linux-specific settings are present, but parity in examples and ordering could be improved.
Recommendations
  • When listing environment variable delimiters or behaviors, always present Linux and Windows equally (e.g., mention both colon and double-underscore, and clarify differences).
  • For settings that have OS-specific values (like WEBSITE_TIME_ZONE), always provide both Windows and Linux examples side by side.
  • Avoid using Windows path syntax (e.g., %HOME%\typescript) in examples unless also providing the Linux equivalent (e.g., $HOME/typescript).
  • When referencing tools for managing settings (e.g., Azure CLI, Azure PowerShell), list cross-platform tools first or equally, and avoid suggesting PowerShell as the default.
  • For settings that are Windows-only (like WEBSITE_NODE_DEFAULT_VERSION), clearly label them and, where possible, provide the Linux alternative or clarify the Linux behavior.
  • Review ordering of language runtimes and examples to ensure Linux-native languages and tools (e.g., bash, Python) are not always listed after Windows/PowerShell.
  • Where PowerShell is referenced for dependency management or configuration, provide equivalent bash or shell script examples for Linux users.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/create-first-function-vs-code-node.md .../azure-functions/create-first-function-vs-code-node.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ missing_linux_example
Summary
The documentation page is largely cross-platform in its use of Visual Studio Code and JavaScript, but there are subtle signs of Windows bias. The troubleshooting section specifically references Windows (e.g., default terminal shell and WSL Bash) without mentioning Linux or macOS equivalents. There are no explicit Linux/macOS-specific instructions, nor are there examples or troubleshooting tips for those platforms. Windows-specific issues are mentioned first and exclusively, and there is an implicit assumption that users are familiar with Windows tools and patterns.
Recommendations
  • Add troubleshooting steps and notes for Linux and macOS users, such as common issues with permissions, shell environments, or dependencies.
  • When referencing terminal shells, mention Linux/macOS shells (e.g., bash, zsh) alongside Windows shells (e.g., Command Prompt, PowerShell, WSL Bash).
  • Ensure that any platform-specific instructions or caveats are provided for all supported operating systems, not just Windows.
  • Explicitly state that the instructions apply to Windows, Linux, and macOS, and provide parity in examples and troubleshooting.
  • Consider adding a table or section summarizing any OS-specific differences in setup, usage, or troubleshooting.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-java.md ...n/articles/azure-functions/functions-reference-java.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy âš ī¸ missing_linux_example
Summary
The documentation generally provides both Bash (Linux/macOS) and Cmd (Windows) examples for command-line operations, but there is a consistent pattern of presenting Windows (Cmd) examples alongside or immediately after Bash, sometimes with more detailed instructions for Windows users. There is also a notable absence of explicit Linux-specific troubleshooting, environment setup, or tool references, and no mention of Linux-specific editors or shell environments beyond Bash. PowerShell is not directly referenced, but the presence of Cmd examples and the 'windows_first' ordering in some tables and explanations indicates a subtle Windows bias.
Recommendations
  • Ensure that Linux/Bash examples are always presented first, or alternate the order to avoid implicit prioritization of Windows.
  • Include explicit Linux troubleshooting steps or notes where environment variables, file paths, or permissions may differ from Windows.
  • Reference Linux-native editors (such as Vim, Emacs, or GNOME Text Editor) in addition to Windows-centric IDEs.
  • Where Cmd examples are given, consider also providing PowerShell and Zsh/Fish shell equivalents for completeness.
  • Add a section on common Linux-specific issues (e.g., case sensitivity, file permissions) that may affect Java Azure Functions development.
  • Highlight any differences in local development experience between Windows and Linux, especially regarding Java version management and environment setup.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/create-active-directory-connections.md ...re-netapp-files/create-active-directory-connections.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_tools âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation demonstrates a Windows bias by providing only Windows/PowerShell command examples for Active Directory operations, referencing Windows-specific tools and policies (such as Group Policy and registry keys), and omitting equivalent Linux/Unix commands or tools for managing Kerberos, LDAP, or AD integration. Windows terminology and tools are introduced first or exclusively, and there are no examples or guidance for Linux administrators who may need to interact with AD or configure Kerberos/NFS integration from non-Windows environments.
Recommendations
  • Provide equivalent Linux command-line examples (e.g., using 'kinit', 'ktutil', 'adcli', or 'realm' for Kerberos/AD integration) alongside PowerShell commands.
  • Reference and explain Linux/Unix tools and configuration files (such as /etc/krb5.conf, /etc/sssd/sssd.conf, or /etc/nsswitch.conf) where relevant, especially for NFS and Kerberos setup.
  • Include guidance for managing Kerberos encryption types and LDAP settings on Linux systems, not just via Windows Group Policy or registry.
  • Clarify which steps are required or different for Linux-based clients or administrators, especially in sections discussing SMB, NFS, and dual-protocol volumes.
  • Add troubleshooting tips and best practices for Linux environments, including how to verify AD connectivity, Kerberos ticket acquisition, and LDAP queries from Linux hosts.
  • Where screenshots or UI steps are shown, note any differences for Linux-based management tools or CLI workflows.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-develop-local.md ...in/articles/azure-functions/functions-develop-local.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ powershell_heavy
Summary
The documentation page demonstrates some Windows bias by listing Windows-centric tools (such as Visual Studio and PowerShell) before cross-platform or Linux-native alternatives, and by providing more detailed instructions or references for Windows-specific environments. PowerShell is mentioned as an HTTP test tool, and Visual Studio (Windows-only) is consistently listed first in environment tables, even when cross-platform options like VS Code are available. There are no explicit Linux-only examples or tools, and Linux is only mentioned as a supported platform, not as a first-class development environment.
Recommendations
  • List cross-platform tools (such as Visual Studio Code and Azure Functions Core Tools) before Windows-only tools in tables and lists to avoid implying Windows primacy.
  • Include Linux-specific examples or screenshots where relevant, especially for command-line usage and environment setup.
  • Mention Linux-native HTTP testing tools (such as httpie or wget) alongside curl and PowerShell.
  • Clarify when a tool or workflow is Windows-only, and provide equivalent Linux/macOS instructions or alternatives.
  • Add a section or callout highlighting Linux development workflows, including package installation commands and common troubleshooting tips for Linux users.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/manage-file-access-logs.md ...articles/azure-netapp-files/manage-file-access-logs.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy âš ī¸ windows_tools âš ī¸ missing_linux_example
Summary
The documentation demonstrates a Windows bias by providing detailed, step-by-step instructions for setting SACLs using Windows GUI tools, while Linux/NFS instructions are minimal and refer users elsewhere. Feature registration examples use Azure PowerShell by default, with Azure CLI only mentioned secondarily. There are no Linux command-line examples for setting audit ACEs, and Windows administration tools are referenced first and in more detail.
Recommendations
  • Provide equivalent, step-by-step instructions for setting Audit ACEs on NFSv4.1 volumes from a Linux client, including example commands (e.g., using setfacl or nfs4_setfacl).
  • When describing feature registration, present both Azure PowerShell and Azure CLI examples side-by-side, or default to CLI for cross-platform parity.
  • Avoid referring to 'Windows administration host' as the default; instead, clarify that either Windows or Linux administration hosts can be used, depending on the protocol/security style.
  • Include screenshots or terminal output for Linux-based workflows, similar to the Windows GUI screenshots provided.
  • Explicitly state that all operations can be performed from both Windows and Linux where applicable, and provide links to relevant Linux documentation or tools.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/disable-showmount.md .../main/articles/azure-netapp-files/disable-showmount.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation page provides only Azure PowerShell examples for registering and unregistering the feature, with Azure CLI mentioned only as an aside. There are no Linux shell (bash) or cross-platform CLI examples shown, and the PowerShell commands are presented first and in detail, which may disadvantage Linux users or those who prefer CLI tools.
Recommendations
  • Provide full Azure CLI (az) command examples alongside PowerShell, not just as a mention or link.
  • Consider listing Azure CLI (cross-platform) commands first or in parallel with PowerShell to avoid Windows-first bias.
  • Explicitly state that both PowerShell and CLI methods are supported, and clarify which is recommended for Linux/macOS users.
  • If relevant, include bash script examples for automation on Linux.
  • Ensure screenshots and UI references are not Windows-specific unless necessary.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/faq-nfs.md ...-docs/blob/main/articles/azure-netapp-files/faq-nfs.md
High Priority View Details →
Reviewed by: Unknown
Issues: 4 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_tools âš ī¸ missing_linux_example âš ī¸ windows_first
Summary
The documentation page generally maintains a neutral stance between Windows and Linux, especially in the context of NFS, which is predominantly a Unix/Linux protocol. However, in the section addressing performance issues when accessing NFS volumes from Windows clients, only Windows-specific tools and PowerShell commands are provided, with no equivalent Linux troubleshooting or configuration examples. This creates a 'powershell_heavy' and 'windows_tools' bias. Additionally, the absence of Linux examples in this context ('missing_linux_example'), and the fact that the only detailed mounting example is for Windows, may give the impression of 'windows_first' bias.
Recommendations
  • For every Windows-specific example (such as PowerShell commands or mount instructions), provide equivalent Linux commands (e.g., using mount, /etc/fstab, or nfs-utils).
  • In the section about improving folder lookup performance, add troubleshooting steps or configuration tips for Linux NFS clients, such as adjusting mount options or client-side caching.
  • Where Windows tools or patterns are mentioned, ensure Linux tools (e.g., nfsstat, showmount, or systemd mount units) are also referenced.
  • If a section is only relevant to Windows (such as CaseSensitiveLookup), clarify this and, if possible, provide a parallel section for Linux users, even if just to state that the issue does not apply.
  • Review all examples and ensure Linux is not omitted, especially since NFS is most commonly used in Linux/Unix environments.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/monitor-volume-capacity.md ...articles/azure-netapp-files/monitor-volume-capacity.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ powershell_heavy
Summary
The documentation presents Windows (SMB) client instructions before Linux (NFS) client instructions, with more detailed steps and screenshots for Windows (including both GUI and command-line methods). Windows-specific tools and patterns (File Explorer, 'dir' command) are described in detail, while the Linux section is shorter and only mentions the 'df' command. The REST API section references PowerShell specifically, but does not mention Linux scripting or tools.
Recommendations
  • Present Windows and Linux client instructions in parallel or alternate the order to avoid always listing Windows first.
  • Expand the Linux section to include both GUI (if applicable, e.g., GNOME Files or KDE Dolphin) and command-line methods, similar to the Windows section.
  • Provide equivalent Linux shell commands for all Windows command-line examples (e.g., show both 'dir' and 'df' outputs side by side).
  • In the REST API section, mention Linux scripting options (e.g., curl, bash, Python) alongside PowerShell.
  • Ensure screenshots and step-by-step instructions are balanced between Windows and Linux environments.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/snapshots-introduction.md .../articles/azure-netapp-files/snapshots-introduction.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy âš ī¸ missing_linux_example
Summary
The documentation page demonstrates a mild Windows bias by listing PowerShell as a primary tool for snapshot management and automation, and by referencing Windows-centric scripting (PowerShell) before or instead of Linux/Unix equivalents. There are no explicit Linux/Unix command-line examples (such as Bash or shell scripts), and the examples and tooling references (e.g., PowerShell cmdlets) are not balanced with Linux-native alternatives. While the documentation mentions NFS and SMB, which are cross-platform, the operational guidance and scripting focus is skewed toward Windows tools.
Recommendations
  • Provide Linux/Unix CLI examples (e.g., Bash scripts using Azure CLI) alongside or before PowerShell examples.
  • Mention and demonstrate Linux-native tools (such as shell scripting with az CLI) for snapshot management and automation.
  • Ensure that scripting and automation sections include parity for both Windows (PowerShell) and Linux (Bash/shell) environments.
  • Where possible, use cross-platform tools (like Azure CLI) as the primary example, and reference platform-specific tools (PowerShell, Bash) as alternatives.
  • Explicitly state that all features are accessible from both Windows and Linux environments, and provide links or references to relevant Linux documentation.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/create-volumes-dual-protocol.md ...les/azure-netapp-files/create-volumes-dual-protocol.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ missing_linux_example
Summary
The documentation demonstrates a Windows bias by prioritizing Windows tools and workflows, such as the use of the Active Directory Users and Computers MMC snap-in and detailed steps for accessing the Attribute Editor on Windows. There are no equivalent instructions or examples for managing POSIX attributes or LDAP users/groups from Linux environments, nor are Linux tools or workflows mentioned for these tasks. Additionally, the only example of attribute management is via Windows tools, and the order of presentation often puts Windows/SMB concepts and terminology first.
Recommendations
  • Provide equivalent Linux-based instructions for managing LDAP POSIX attributes, such as using ldapmodify, ldapadd, or tools like Apache Directory Studio.
  • Include examples or references for configuring and managing LDAP users and groups from Linux systems.
  • Balance the order of presentation so that Linux/NFS and Windows/SMB concepts are introduced together or alternate the order to avoid always putting Windows first.
  • Where screenshots or step-by-step guides are given for Windows tools, provide parallel guides for common Linux tools.
  • Explicitly mention cross-platform alternatives and clarify that both Windows and Linux environments are supported for administrative tasks.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/network-attached-storage-protocols.md ...ure-netapp-files/network-attached-storage-protocols.md
High Priority View Details →
Reviewed by: Unknown
Issues: 3 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools âš ī¸ missing_linux_example
Summary
The documentation generally presents Windows/SMB concepts and terminology before or with more emphasis than Linux/NFS equivalents, especially in sections discussing dual-protocol and permissions. Windows tools and patterns (Active Directory, NTFS ACLs, SID translation, Kerberos/NTLM) are described in detail, while Linux equivalents (such as POSIX ACLs, idmapd, Samba configuration) are mentioned but not explained or exemplified. There are no Linux command-line or configuration examples, and Linux/Samba support is described as unofficial, which may discourage Linux users.
Recommendations
  • Provide parallel Linux/NFS examples and explanations wherever Windows/SMB tools or workflows are described (e.g., show how to view or set NFSv4 ACLs on Linux, or how to configure idmapd.conf).
  • Include Linux/Samba configuration guidance or references for connecting to Azure NetApp Files, even if support is limited.
  • Balance the order of presentation: when discussing dual-protocol or permissions, describe both Windows and Linux approaches side by side, rather than focusing on Windows/Active Directory first.
  • Clarify the level of support for Linux/Samba clients and provide troubleshooting tips or links for common interoperability issues.
  • Add Linux command-line examples (e.g., using getfacl/setfacl, mount options, rpcinfo, id mapping) to match the level of detail given for Windows tools.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/app-service-web-tutorial-custom-domain.md .../app-service/app-service-web-tutorial-custom-domain.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation contains a subtle Windows bias in the troubleshooting section, where only the Windows-specific command ('ipconfig /flushdns') is provided for clearing the DNS cache. No equivalent Linux or macOS commands are mentioned, and Windows is the only OS explicitly referenced in this context. The rest of the documentation is platform-neutral, focusing on Azure Portal UI and DNS provider interfaces.
Recommendations
  • Provide equivalent DNS cache flush commands for Linux (e.g., 'sudo systemd-resolve --flush-caches' or 'sudo service nscd restart') and macOS (e.g., 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder').
  • Rephrase troubleshooting steps to address users on all major platforms, not just Windows.
  • Where OS-specific instructions are needed, present them in a tabbed or bulleted format, giving parity to Windows, Linux, and macOS.
  • Review future documentation for similar single-platform troubleshooting tips and ensure cross-platform inclusivity.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/tutorial-secure-domain-certificate.md ...cles/app-service/tutorial-secure-domain-certificate.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation is generally platform-neutral, focusing on Azure Portal UI steps. However, in the troubleshooting section for clearing DNS cache, only the Windows-specific command (`ipconfig /flushdns`) is provided, with no mention of Linux or macOS equivalents. This presents a subtle 'windows_first' and 'missing_linux_example' bias.
Recommendations
  • When providing troubleshooting steps involving command-line tools, include equivalent commands for Linux (e.g., `sudo systemd-resolve --flush-caches` or `sudo resolvectl flush-caches`) and macOS (e.g., `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`).
  • If referencing OS-specific tools or commands, present them in a cross-platform table or list, or at least mention that steps may differ on non-Windows systems.
  • Consider adding a note or section for non-Windows users, especially in troubleshooting, to ensure parity and inclusivity.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/tutorial-ai-integrate-azure-ai-agent-dotnet.md ...service/tutorial-ai-integrate-azure-ai-agent-dotnet.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ missing_linux_example
Summary
The documentation assumes the use of GitHub Codespaces and Azure App Service, which are cross-platform, but all examples and instructions are focused on .NET and do not mention Linux-specific workflows or tools. There are no explicit Windows-only tools (like PowerShell), but the lack of Linux terminal commands, package managers, or deployment instructions (e.g., for self-hosted Linux environments) indicates a bias toward Windows-centric or abstracted (cloud) environments. There are no examples for running or deploying the app on a local Linux machine, nor any mention of Linux-specific considerations.
Recommendations
  • Include instructions for running and deploying the sample app on a local Linux machine (e.g., Ubuntu), including installation of .NET SDK and required dependencies.
  • Provide Linux shell (bash) equivalents for any terminal commands, especially for package installation and running the app.
  • Mention how to use editors and tools commonly available on Linux (e.g., VS Code on Linux, nano/vim for editing files).
  • Add a note clarifying that the tutorial works on both Windows and Linux, and highlight any OS-specific steps if applicable.
  • If using Azure CLI or GitHub Codespaces, clarify that these are cross-platform and provide links to Linux setup guides where relevant.
Azure App Configuration https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-app-configuration/quickstart-go-web-app.md ...icles/azure-app-configuration/quickstart-go-web-app.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy
Summary
The documentation presents environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and provides both setx (cmd) and PowerShell commands, which may suggest a Windows-first and PowerShell-heavy approach. However, Linux/macOS instructions are present and correct, and the rest of the guide uses cross-platform Go and Bash commands.
Recommendations
  • Present Linux/macOS and Windows instructions in parallel (side-by-side tabs or tables) rather than listing Windows first.
  • Avoid giving Windows command prompt and PowerShell commands more prominence than Linux/macOS equivalents.
  • Consider leading with Bash/Linux/macOS examples, as Go developers often use cross-platform tools.
  • Explicitly state that all commands are cross-platform where possible, and only provide OS-specific instructions when necessary.
  • If using tabbed instructions, ensure Linux/macOS is a first-class tab alongside Windows.
Azure App Configuration https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-app-configuration/reload-key-vault-secrets-dotnet.md ...e-app-configuration/reload-key-vault-secrets-dotnet.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ missing_linux_example âš ī¸ windows_first
Summary
The documentation page assumes usage of ASP.NET Core and provides instructions and code samples only for .NET (C#) applications, which are most commonly associated with Windows development. There are no examples, notes, or instructions for Linux-based environments, nor is there mention of cross-platform considerations (such as running on Linux containers or using Linux command-line tools). The Azure Portal UI steps are platform-agnostic, but the overall context and code focus on Windows-centric development patterns.
Recommendations
  • Add explicit notes or examples for running ASP.NET Core apps on Linux (e.g., in Docker containers or on Azure App Service for Linux).
  • Include Linux shell (bash) equivalents for any command-line steps, even if minimal.
  • Clarify that the code samples work cross-platform and mention any OS-specific considerations (such as file permissions or environment variable handling on Linux).
  • Provide links or references to documentation for deploying and managing ASP.NET Core apps on Linux environments.
  • If relevant, mention how to perform similar configuration using CLI tools (e.g., Azure CLI) with Linux shell examples.
Azure App Configuration https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-app-configuration/quickstart-go-console-app.md ...s/azure-app-configuration/quickstart-go-console-app.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy
Summary
The documentation provides environment variable setup instructions for Windows (cmd and PowerShell) before Linux/macOS, and includes explicit PowerShell examples. While Linux/macOS instructions are present, Windows command-line and PowerShell commands are consistently listed first, which may signal a Windows-centric approach.
Recommendations
  • Alternate the order of platform instructions (e.g., list Linux/macOS first in some sections, or use tabs for OS-specific instructions).
  • Use tabbed or collapsible sections for platform-specific commands to give equal prominence to Windows and Linux/macOS.
  • Where possible, provide cross-platform commands (e.g., using env files or cross-platform tools) or clarify that the order does not imply priority.
  • Explicitly state that all major platforms are supported and tested.
  • Consider including screenshots or CLI output from both Windows and Linux/macOS terminals to reinforce parity.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/configure-monitoring.md .../main/articles/azure-functions/configure-monitoring.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ powershell_heavy âš ī¸ windows_first
Summary
The documentation provides both Azure CLI and PowerShell examples for overriding monitoring configuration, but the PowerShell example is given its own tab and is presented immediately after the Azure CLI example. There is no explicit mention of Linux shell (bash) or cross-platform scripting alternatives, and PowerShell is a Windows-centric tool (though available cross-platform, it is still more familiar to Windows users). Additionally, the note about app settings with periods not being supported on Linux plans is present, but no Linux-specific example or workaround is provided. There are no explicit Linux command-line examples or references to Linux-native tools.
Recommendations
  • Include bash or shell script examples alongside Azure CLI and PowerShell, especially for common configuration tasks.
  • Clarify that Azure CLI is cross-platform and can be used on Linux, macOS, and Windows.
  • When presenting command-line examples, avoid giving PowerShell its own tab unless also providing a Linux shell tab.
  • Where platform-specific limitations exist (e.g., app settings with periods on Linux), provide clear Linux-specific guidance or workarounds.
  • Explicitly mention that PowerShell Core is available cross-platform if including PowerShell examples, or clarify which version is being referenced.
  • Consider the order of examples: present cross-platform (CLI/bash) examples before Windows-specific (PowerShell) ones.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/create-first-function-azure-developer-cli.md ...functions/create-first-function-azure-developer-cli.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ powershell_heavy
Summary
The documentation generally maintains cross-platform parity, but there are subtle signs of Windows bias. In several places, Windows-specific shells (Cmd, PowerShell) are listed before Linux/macOS equivalents, and PowerShell is treated as a first-class language option. Some command examples and folder structures reference Windows conventions or tools before Linux ones, and the PowerShell language is given equal prominence to others, which may not reflect its usage share across platforms.
Recommendations
  • When presenting command-line examples, list Linux/macOS (bash) examples before Windows (Cmd/PowerShell) examples, or present them side-by-side to avoid implying a default platform.
  • Ensure that all shell command examples (e.g., for setting environment variables, activating virtual environments) are present for both Linux/macOS and Windows, and that Linux/macOS is not treated as a secondary platform.
  • Where possible, use platform-agnostic language (e.g., 'terminal' instead of 'command prompt') and clarify when instructions differ by OS.
  • For PowerShell-specific sections, clarify that PowerShell is cross-platform, but also provide bash equivalents where appropriate.
  • Review folder structure and file path examples to ensure they are not Windows-centric (e.g., use forward slashes or clarify path differences).
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/functions-reference-python.md ...articles/azure-functions/functions-reference-python.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools
Summary
The documentation is generally cross-platform and Linux-friendly, especially in its guidance for Azure Functions Python development. However, there are subtle signs of Windows bias: Windows terminology ('command prompt') is used alongside 'terminal', and remote build is recommended specifically for users developing on Windows. There is also a reference to the Python standard library being installed with Python on Windows, while on Unix-based systems it is provided by package collections, which could be misleading. No explicit Linux shell or Linux-specific examples are given, and no Linux-first guidance is present.
Recommendations
  • Use neutral, cross-platform terminology such as 'terminal' or 'shell' instead of 'command prompt', or clarify with 'terminal (Linux/macOS) or command prompt (Windows)'.
  • When recommending remote build for Windows users, also provide guidance for Linux/macOS users, and clarify the pros and cons for each OS.
  • Add Linux/macOS-specific examples or notes where relevant, such as using bash/zsh for commands, or referencing Linux filesystem paths.
  • In the section about the Python standard library, clarify that official Python distributions include the standard library on all platforms, and that package management may differ only for system Python installations on some Linux distributions.
  • Ensure that all instructions and examples are explicitly cross-platform, and avoid implying that Windows is the default or primary development environment.
Azure Netapp Files https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-netapp-files/faq-data-migration-protection.md ...es/azure-netapp-files/faq-data-migration-protection.md
Medium Priority View Details →
Reviewed by: Unknown
Issues: 2 bias types
Detected Bias Types
âš ī¸ windows_first âš ī¸ windows_tools
Summary
The documentation demonstrates mild Windows bias by listing the Windows-specific tool 'robocopy' as the primary example for SMB data migration, while only mentioning the Linux/Unix tool 'rsync' for NFS. There are no explicit PowerShell-heavy examples or missing Linux examples, but the pattern of pairing rsync with NFS and robocopy with SMB implicitly assumes Windows for SMB workloads and Linux/Unix for NFS, without mentioning cross-platform alternatives or Linux SMB tools. Additionally, robocopy is referenced before any Linux-based SMB copy tools, and no Linux-native SMB migration tools (such as smbclient or cifs-utils) are mentioned.
Recommendations
  • Include Linux-native SMB copy tools (e.g., smbclient, cifs-utils, or mount.cifs with rsync/cp) as alternatives to robocopy for SMB migrations.
  • Explicitly state that both rsync and robocopy are examples, and mention that cross-platform tools exist for both NFS and SMB.
  • Provide example commands or links for both Windows and Linux environments for both NFS and SMB scenarios.
  • Avoid implying that SMB is only for Windows and NFS is only for Linux/Unix by clarifying that both protocols can be accessed from multiple operating systems.
App Service https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/app-service/environment/creation.md ...blob/main/articles/app-service/environment/creation.md
Low Priority View Details →
Reviewed by: Unknown
Issues: 1 bias type
Detected Bias Types
âš ī¸ windows_first
Summary
The documentation page exhibits a subtle Windows bias by referencing 'Windows Isolated v2' as the minimum charge for App Service plans in regional deployments, without mentioning Linux equivalents or clarifying Linux support. No explicit Linux examples, tools, or deployment considerations are provided, and the only OS-specific reference is to Windows.
Recommendations
  • Explicitly mention Linux support and pricing models for App Service Environment, especially in sections discussing minimum charges or instance types.
  • Add clarifying statements or examples for both Windows and Linux deployments where relevant, such as supported runtimes or differences in configuration.
  • Ensure parity in documentation by providing Linux-specific considerations, if any, or stating that the process is identical for Linux-based App Service plans.
  • Avoid referencing only Windows SKUs or features unless there is a technical limitation, and if so, clearly state it.
Azure App Configuration https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-app-configuration/howto-telemetry-python.md ...cles/azure-app-configuration/howto-telemetry-python.md
Low Priority View Details →
Reviewed by: Unknown
Issues: 1 bias type
Detected Bias Types
âš ī¸ windows_first
Summary
The documentation provides environment variable setup instructions in the order: Windows (cmd), PowerShell, then macOS/Linux (bash). While all platforms are covered, Windows commands are presented first, which may signal a subtle preference or bias toward Windows users.
Recommendations
  • Present environment variable setup instructions in a neutral or rotating order (e.g., Linux/macOS first, or group all together without prioritizing one OS).
  • Consider using tabbed code blocks or collapsible sections for each platform to give equal prominence.
  • Explicitly state that the instructions apply to all major platforms and that the order does not imply priority.
  • Review other sections for similar ordering and ensure parity in example prominence.
Azure Functions https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/azure-functions/durable/durable-task-scheduler/durable-task-scheduler-versioning.md ...le-task-scheduler/durable-task-scheduler-versioning.md
Low Priority View Details →
Reviewed by: Unknown
Issues: 1 bias type
Detected Bias Types
âš ī¸ missing_linux_example
Summary
The documentation does not provide any OS-specific examples, but it does show a bias by omission: there are no Linux- or Unix-specific instructions, shell commands, or references. The only OS-specific pivot is 'powershell', which is present but contains only a generic limitations include, not actual PowerShell commands. No Windows tools, file paths, or patterns are mentioned, but Linux/Unix parity is not addressed, and there are no bash or shell examples. The documentation focuses on SDKs (C#, Java, JavaScript, Python), but the Python SDK is noted as unsupported for this feature.
Recommendations
  • If any OS-specific setup or orchestration management is required (such as CLI commands, environment variables, or deployment scripts), provide both Windows (PowerShell/CMD) and Linux (bash/sh) examples.
  • If the 'powershell' pivot is included, consider adding a corresponding 'bash' or 'shell' pivot for Linux users, even if only to state limitations or provide parity.
  • Explicitly mention that the SDKs and features are cross-platform, and clarify any OS-specific requirements or differences.
  • If there are no OS-specific steps, state this clearly to reassure Linux users that the instructions are applicable to their environment.