Azure Docs
14605
Total Pages
12420
Linux-Friendly Pages
2185
Pages with Bias
15.0%
Bias Rate
Bias Trend Over Time
Pages with Bias Issues
2185 issues found
Showing 1576-1600 of 2185 flagged pages
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-functions/python-memory-profiler-reference.md
...es/azure-functions/python-memory-profiler-reference.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Powershell Heavy
Summary
The documentation demonstrates a mild Windows bias, particularly in the local development setup instructions. Windows PowerShell is mentioned first, and Windows-specific commands and paths (such as `.venv\Scripts\Activate.ps1` and `<ProjectRoot>\HttpTriggerAsync\__init__.py`) are shown before their Linux equivalents. While Linux alternatives are provided, they are consistently listed after the Windows instructions, and the use of Windows path separators in sample output further reinforces the bias.
Recommendations
- Present Linux and Windows instructions side-by-side or in parallel tabs, rather than always listing Windows first.
- Use platform-agnostic language where possible (e.g., 'terminal' instead of 'PowerShell or Linux shell').
- Show both Windows and Linux/MacOS path separators in sample outputs, or clarify that the output may differ by OS.
- Where commands differ, clearly label them as 'Windows' and 'Linux/MacOS' rather than defaulting to Windows.
- Consider including screenshots or examples from both Windows and Linux environments to ensure parity.
Create Pull Request
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-health-insights/includes/example-inference-follow-up-communication-json-request.md
...example-inference-follow-up-communication-json-request.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Summary
The documentation page references 'Powerscribe', a Windows-centric radiology dictation tool, and mentions faxing results, which is more common in Windows-based healthcare environments. There are no explicit Linux or cross-platform tool references, and no examples or patterns relevant to Linux users are provided.
Recommendations
- Include examples or references to cross-platform or Linux-friendly tools for radiology reporting and document transmission.
- If mentioning proprietary or Windows-only tools like Powerscribe, also mention open-source or Linux-compatible alternatives (e.g., Mirth Connect, OpenEMR, or DICOM viewers).
- Avoid assuming faxing or Windows-based workflows are universal; describe workflows in a platform-neutral way where possible.
- Provide sample data or scenarios that include Linux or cross-platform tools and environments.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-government/documentation-government-overview-jps.md
...re-government/documentation-government-overview-jps.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Summary
The documentation references Windows-specific cryptographic modules and the Windows FIPS validation program multiple times, especially in the context of FIPS 140 compliance and authentication. While it mentions that Azure uses both Linux and Windows, the detailed compliance and cryptography examples and links are focused on Windows. There are no Linux-specific examples, tools, or validation references provided, and Windows is consistently mentioned first or exclusively in technical compliance contexts.
Recommendations
- Include explicit references to Linux-based cryptographic modules and their FIPS 140 validation status where applicable.
- Provide parity in documentation by linking to Linux security/compliance resources alongside Windows resources.
- When discussing authentication and cryptography, clarify how Linux-based workloads and environments are supported and validated.
- If possible, add Linux-specific examples or guidance for public safety and justice workloads in Azure.
- Avoid mentioning Windows tools or validation programs exclusively; ensure Linux equivalents are mentioned with equal prominence.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/devtest-labs/devtest-lab-create-custom-image-from-vm-using-portal.md
...tps://github.com/MicrosoftDocs/azure-docs/blob/main//articles/devtest-labs/devtest-lab-create-custom-image-from-vm-using-portal.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation references both Windows (sysprep) and Linux (deprovision) generalization steps, but Windows is mentioned first and in more detail. There are no explicit Linux command examples or screenshots, and the generalization process is described primarily in Windows terms, with Linux as a secondary note. No Linux-specific tools, commands, or UI differences are discussed.
Recommendations
- Present Windows and Linux generalization steps with equal prominence, possibly in parallel bullet points or a comparison table.
- Include explicit Linux command examples (e.g., the waagent deprovision command) alongside the Windows sysprep example.
- Add screenshots or UI notes if the process differs for Linux VMs.
- Ensure that references to documentation for both Windows and Linux are equally visible and accessible.
- Consider alternating the order in which Windows and Linux are mentioned, or use neutral phrasing such as 'For Windows, run sysprep; for Linux, run deprovision.'
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-government/documentation-government-get-started-connect-with-cli.md
...ps://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-government/documentation-government-get-started-connect-with-cli.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Summary
The documentation page assumes a generic CLI usage but omits any discussion of platform-specific differences, such as login browser launching on headless Linux systems or CLI installation nuances. It references the lack of Azure Cloud Shell in Azure Government but does not provide Linux-specific alternatives or troubleshooting. There is a subtle Windows-first bias in assuming browser-based login will work seamlessly, which is not always the case on Linux servers.
Recommendations
- Add explicit instructions or notes for Linux users, especially regarding browser-based login (e.g., using device code authentication with 'az login --use-device-code' for headless systems).
- Include a brief section or callout on installing Azure CLI on Linux, or link directly to Linux-specific installation instructions.
- Mention common Linux shell environments (bash, zsh) in addition to generic CLI usage.
- If screenshots are provided, consider including examples from both Windows and Linux terminals.
- Clarify any differences in experience or troubleshooting steps for Linux users, especially where browser-based authentication or file paths may differ.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-government/documentation-government-overview-itar.md
...e-government/documentation-government-overview-itar.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Windows First
Summary
The documentation is largely platform-neutral in its discussion of Azure export controls, but in the section on FIPS 140 validated cryptography, it specifically references the 'Microsoft Windows FIPS validation program' and provides a link to modules used by Windows Server. While it mentions that Azure uses both Linux and Windows operating systems, the only detailed reference and external link for cryptographic validation is for Windows, not Linux. There are no command-line examples or tool usage instructions, but the documentation does not provide Linux-specific parity in its discussion of cryptographic modules or validation programs.
Recommendations
- Include explicit references to FIPS 140 validation for Linux-based cryptographic modules used in Azure, with links to relevant documentation or validation certificates.
- Provide equal detail for both Windows and Linux in sections discussing cryptographic modules, validation, and security practices.
- If referencing Windows-specific validation programs or modules, add parallel information for Linux to ensure parity and avoid the impression that only Windows is supported or validated.
- Consider including examples or references to cross-platform tools or commands (where applicable) to demonstrate Azure's support for both Windows and Linux environments.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-large-instances/faq.md
...-docs/blob/main//articles/azure-large-instances/faq.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Summary
The documentation does not provide any OS-specific examples or instructions, but all references to tooling and configuration are centered around the Azure portal and Azure-specific workflows, which are typically more familiar to Windows users. There is no mention of Linux command-line tools, CLI, or PowerShell, but also no Linux-specific guidance or parity. The documentation implicitly assumes use of the Azure portal (a GUI), which may be less familiar or less preferred by Linux-centric users who often rely on CLI tools. There are no examples or instructions for managing Azure Large Instances via Azure CLI, Bash, or other cross-platform tools.
Recommendations
- Add examples for managing Azure Large Instances using Azure CLI commands, which are cross-platform and commonly used on Linux.
- Include references to Bash scripting or automation for monitoring and alerting, not just Azure portal workflows.
- Explicitly mention that all instructions are applicable regardless of OS, or provide parallel instructions for both GUI (portal) and CLI (Azure CLI, Bash).
- If PowerShell or Windows-specific tools are not required, clarify this to reassure Linux users.
- Consider adding a section on integrating third-party Linux monitoring/logging agents, with example commands.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-large-instances/find-your-subscription-id.md
...les/azure-large-instances/find-your-subscription-id.md
Medium Priority
View Details →
Detected Bias Types
Missing Linux Example
Windows First
Summary
The documentation provides only a portal-based (web UI) method for finding the subscription ID and does not mention any command-line alternatives. There are no examples using cross-platform tools such as Azure CLI, and no Linux-specific instructions are provided. This can be seen as a subtle Windows bias, as the Azure portal is often associated with Windows-centric workflows, and users on Linux or those preferring CLI tools are not addressed.
Recommendations
- Add instructions for finding the subscription ID using Azure CLI (az account show), which works on Windows, Linux, and macOS.
- Include PowerShell examples if desired, but ensure they are presented alongside Azure CLI examples, not before.
- Explicitly mention that the Azure portal is accessible from any OS, to avoid the impression of a Windows-only workflow.
- Consider adding a table summarizing all available methods (Portal, Azure CLI, PowerShell) for parity.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/how-to-dataset-geojson.md
...ob/main//articles/azure-maps/how-to-dataset-geojson.md
Medium Priority
View Details →
Detected Bias Types
Windows Tools
Missing Linux Example
Summary
The documentation demonstrates Windows bias by recommending the use of the Guidgen.exe tool (available with Visual Studio) for generating GUIDs, which is a Windows-only utility. There are no equivalent Linux or cross-platform GUID generation methods mentioned, and no Linux-specific examples or tools are provided in this context.
Recommendations
- Mention cross-platform methods for generating GUIDs, such as using 'uuidgen' on Linux/macOS or platform-agnostic libraries in Python, Node.js, etc.
- Provide example commands for both Windows (Guidgen.exe, PowerShell) and Linux/macOS (uuidgen, openssl rand, etc.) when suggesting GUID generation.
- Avoid referencing only Windows-specific tools like Visual Studio without offering alternatives for other platforms.
- Review the documentation for other implicit Windows-first assumptions and ensure parity in instructions and tool recommendations.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/elevation-data-services.md
...b/main//articles/azure-maps/elevation-data-services.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation demonstrates a mild Windows bias. While most of the workflow is cross-platform (using QGIS, Python, PostgreSQL/PostGIS), Windows-specific tools and patterns are mentioned first or exclusively in some places. For example, Azure Storage Explorer (a Windows-centric tool) is recommended for uploading to Azure Blob Storage, and the guide assumes a Windows environment by referencing WSL (Windows Subsystem for Linux) for running Linux tools. There is no explicit Linux or macOS guidance for these steps, and the workaround for running rio-rgbify is described in the context of WSL rather than native Linux or macOS.
Recommendations
- Provide explicit instructions for Linux and macOS users, such as how to install and run rio-rgbify natively on those platforms.
- Mention and provide alternatives to Azure Storage Explorer, such as the Azure CLI (az storage blob upload) or cross-platform tools like rclone.
- When referencing WSL, clarify that the steps are for Windows users and provide equivalent native Linux/macOS commands where possible.
- Ensure that any required tools or steps are described in a platform-agnostic way, or provide parallel instructions for each major OS.
- Consider reordering instructions so that cross-platform or Linux-native approaches are presented first, or at least alongside Windows-specific guidance.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/how-to-secure-daemon-app.md
.../main//articles/azure-maps/how-to-secure-daemon-app.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation demonstrates a subtle Windows bias by listing 'Windows Service' as a primary example of a daemon application and not providing equivalent Linux examples (such as systemd services or Linux daemons). There are no command-line or code examples specific to Linux environments, nor is there mention of Linux-native tools or patterns for hosting or securing daemon applications. The documentation assumes Azure-centric workflows and UI navigation, which are platform-agnostic, but the omission of Linux-specific hosting patterns or examples results in a lack of parity.
Recommendations
- Include Linux-native examples for daemon applications, such as referencing systemd services or background processes on Linux.
- When listing examples of daemon applications, mention both Windows Services and Linux daemons/systemd units to provide cross-platform context.
- Provide sample code snippets or command-line instructions for both Windows (PowerShell, Windows Service) and Linux (bash, systemd) environments where relevant.
- Explicitly state that the guidance applies to both Windows and Linux environments, and highlight any platform-specific considerations.
- If using screenshots or UI walkthroughs, consider including CLI alternatives (such as Azure CLI commands) that are platform-neutral.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/how-to-use-npm-package.md
...ob/main//articles/azure-maps/how-to-use-npm-package.md
Medium Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Summary
The documentation consistently uses PowerShell syntax (e.g., 'npm install ...' and 'npm run build' in PowerShell code blocks) for all command-line examples, which may imply a Windows-first approach. There are no explicit Linux or macOS shell examples, nor is there mention of cross-platform command-line usage. While the content itself is cross-platform (Node.js, npm, webpack), the exclusive use of PowerShell code blocks and lack of Linux/macOS terminal examples could make Linux users feel less directly supported.
Recommendations
- Provide both Windows (PowerShell or CMD) and Linux/macOS (bash/sh) command-line examples, or use generic shell code blocks (e.g., 'sh' or 'bash') for npm commands.
- Add a note clarifying that all npm and Node.js commands work cross-platform, and that the examples are not Windows-specific.
- Where relevant, mention any OS-specific differences (e.g., file paths, environment variables) to ensure Linux/macOS users are aware of how to adapt instructions.
- Consider alternating the order of examples or using tabs to allow users to select their OS for command-line instructions.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/set-drawing-options.md
.../blob/main//articles/azure-maps/set-drawing-options.md
Medium Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Summary
The documentation includes a code snippet using PowerShell syntax for npm installation (`npm install --save-dev style-loader css-loader`) and presents this as the primary or only shell example. There are no explicit Linux/macOS shell (bash) equivalents, and the use of PowerShell is not contextualized as Windows-specific, which may confuse or exclude Linux/macOS users.
Recommendations
- Provide both PowerShell (Windows) and bash (Linux/macOS) command examples for npm installation steps. For example, use a generic shell prompt (`$`) or explicitly show both (`npm install --save-dev style-loader css-loader`).
- Avoid using PowerShell-specific prompts or syntax unless the documentation is Windows-specific. Use cross-platform shell commands where possible.
- Add a note clarifying that npm commands are the same across platforms, and that the example applies to all operating systems.
- If referencing tools or workflows that differ between platforms (e.g., file paths, environment variables), include Linux/macOS equivalents or mention any differences.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/tutorial-ev-routing.md
.../blob/main//articles/azure-maps/tutorial-ev-routing.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The tutorial consistently references Visual Studio Code (VS Code) and its integrated terminal for running commands and opening Jupyter Notebooks, but does not mention or provide instructions for Linux or macOS users. All instructions and screenshots assume a Windows environment (e.g., right-click context menu for 'Open with > Visual Studio Code'), and there are no examples or notes for Linux-specific workflows, terminal usage, or alternative editors. There is also no mention of cross-platform considerations for installing Python packages or opening files.
Recommendations
- Explicitly mention that VS Code and Jupyter Notebooks are cross-platform and provide links or notes for Linux/macOS installation and usage.
- Include Linux/macOS equivalents for steps such as opening files (e.g., using the command line: 'code EVrouting.ipynb') and installing packages.
- Add screenshots or text instructions that show how to perform key actions (like opening a notebook) on Linux/macOS.
- Avoid language that assumes Windows-specific UI conventions (e.g., right-click context menus) or supplement with cross-platform alternatives.
- Clarify that the terminal commands (e.g., 'pip install ...') work on all platforms, and note any platform-specific prerequisites if applicable.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-maps/weather-service-tutorial.md
.../main//articles/azure-maps/weather-service-tutorial.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation consistently references Visual Studio Code (VS Code) and its terminal, but all instructions and screenshots assume a Windows environment. There are no explicit mentions or examples for Linux or macOS users, such as alternative ways to open files, install packages, or launch Jupyter Notebooks. The instructions for opening files and running commands are written in a way that presumes a Windows file explorer and context menu, with no mention of Linux equivalents.
Recommendations
- Include instructions and screenshots for opening Jupyter Notebooks in VS Code on Linux (and macOS), such as using the command line (e.g., `code weatherDataMaps.ipynb`) or file manager alternatives.
- Clarify that the 'Visual Studio terminal' refers to the integrated terminal in VS Code, which is available on all platforms, and provide examples for both Windows (Command Prompt/PowerShell) and Linux/macOS (bash/zsh).
- Explicitly mention that all pip commands and Python code are cross-platform, and note any platform-specific considerations if they exist.
- Add a note or section for Linux/macOS users, highlighting any differences in file paths, keyboard shortcuts, or environment setup.
- Ensure that screenshots and UI instructions are not Windows-specific, or provide parallel images for other platforms.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-netapp-files/azacsnap-release-notes.md
.../articles/azure-netapp-files/azacsnap-release-notes.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation generally presents both Linux and Windows as supported platforms for AzAcSnap, with download links for both. However, there is a noticeable Windows-first bias in the feature announcements (e.g., Microsoft SQL Server support is always described as 'on Windows', and Windows support is called out explicitly before Linux in some places). There are no explicit Linux-specific examples, troubleshooting steps, or parity notes, and some features (like SQL Server support) are only available on Windows, with no mention of Linux equivalents or roadmaps. There are also no examples or guidance tailored for Linux users (e.g., shell commands, systemd integration, or Linux-specific troubleshooting), which may leave Linux administrators underserved.
Recommendations
- When announcing new features, mention Linux and Windows support together, or alternate the order to avoid a Windows-first impression.
- If a feature is Windows-only (such as SQL Server support), explicitly state this and provide a roadmap or rationale for Linux support.
- Include Linux-specific usage examples, such as shell commands for installation, configuration, and troubleshooting.
- Add guidance for integrating AzAcSnap with common Linux tools (e.g., systemd service files, log file locations, SELinux/AppArmor considerations).
- Ensure troubleshooting and configuration sections address both Linux and Windows environments equally.
- Provide parity tables or matrices showing which features are available on each platform.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/devtest-labs/devtest-lab-redeploy-vm.md
...main//articles/devtest-labs/devtest-lab-redeploy-vm.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation page focuses on troubleshooting remote desktop connection issues, specifically mentioning Windows-based VMs, and does not address Linux VMs or provide Linux-specific guidance or examples. The language and troubleshooting context are Windows-centric, with no mention of SSH or Linux remote access scenarios.
Recommendations
- Include guidance for redeploying Linux-based VMs, such as troubleshooting SSH connectivity issues.
- Update the introductory paragraph to mention both Windows and Linux VMs, and reference both RDP and SSH as common remote access methods.
- Add examples or notes for users managing Linux VMs, clarifying that the redeploy process is applicable regardless of the operating system.
- Where screenshots or UI elements are shown, clarify that the process is the same for Linux VMs, or provide Linux-specific visuals if there are differences.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/devtest-labs/devtest-lab-shared-ip.md
...b/main//articles/devtest-labs/devtest-lab-shared-ip.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation presents Windows connection instructions before Linux, and while it mentions SSH for Linux, it does not provide a concrete command-line example (e.g., an actual ssh command). In contrast, Windows users are given a clear, actionable step (downloading an RDP file). This prioritizes Windows workflows and leaves Linux users with less detailed guidance.
Recommendations
- Provide explicit SSH command-line examples for Linux users (e.g., ssh user@contoso.westus3.cloudapp.azure.com -p 65013).
- Present Windows and Linux instructions in parallel, or alternate which comes first to avoid implicit prioritization.
- Include screenshots or step-by-step instructions for Linux SSH connection, similar to the RDP instructions for Windows.
- Mention any platform-specific prerequisites (e.g., SSH client for Windows, RDP client for Linux) to ensure parity.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-netapp-files/convert-nfsv3-nfsv41.md
...n//articles/azure-netapp-files/convert-nfsv3-nfsv41.md
Medium Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Summary
The documentation shows a moderate Windows bias in the feature registration section, where Azure PowerShell commands are presented first and in detail, with Azure CLI (cross-platform) only mentioned in passing. However, the main conversion workflow and client-side instructions are Linux-focused, using Linux commands and patterns (e.g., mount, umount, /etc/fstab). There are no explicit Windows-only tools or examples for the NFS client side, but the registration steps could disadvantage Linux/macOS users by prioritizing PowerShell.
Recommendations
- Provide Azure CLI registration commands alongside or before PowerShell commands, with full syntax and examples.
- Explicitly state that both Azure CLI and PowerShell are supported, and provide parity in instructions for both.
- If relevant, clarify whether any steps require Windows or can be performed cross-platform.
- Continue to use Linux-native examples for NFS client operations, but ensure any Azure management steps are equally accessible from Linux/macOS environments.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-netapp-files/faq-integration.md
...b/main//articles/azure-netapp-files/faq-integration.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation shows a subtle Windows bias by mentioning Windows VMs and their ability to mount SMB shares before Linux equivalents. While both Windows and Linux are referenced for NFS mounts, only Windows is mentioned for SMB, with no guidance for Linux SMB clients. There are no Linux-specific examples or instructions, especially for SMB usage.
Recommendations
- Include explicit instructions or examples for mounting SMB shares from Linux VMs, not just Windows.
- When listing supported platforms, alternate the order or mention both Windows and Linux together to avoid 'windows_first' bias.
- Add parity in examples and guidance for both Windows and Linux environments, especially for common integration scenarios.
- If a feature is not supported on Linux (e.g., SMB mounting), clearly state this to avoid ambiguity.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-netapp-files/default-individual-user-group-quotas-introduction.md
...s/default-individual-user-group-quotas-introduction.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Tools
Summary
The documentation presents both Windows and Linux client perspectives for observing user quota settings and consumption. However, the Windows client section is presented first, and Windows-specific tools (Windows Explorer, dir command) are mentioned before their Linux equivalents. There is also a reference to Windows security identifiers (SID) before UNIX user/group IDs when describing individual user quotas. No PowerShell-heavy or missing Linux example biases are present, as Linux examples and commands are included and described.
Recommendations
- Alternate the order of Windows and Linux client sections, or present them in parallel, to avoid always prioritizing Windows.
- When describing user/group identification, mention UNIX user/group IDs and Windows SIDs together, or alternate their order in different sections.
- Where possible, provide equal depth and detail for both Windows and Linux client experiences, including screenshots and command examples.
- Avoid linking only to Windows-specific concepts (such as Security Identifiers) in the 'Next steps' section; consider adding links to relevant Linux/UNIX identity documentation.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/communication-services/concepts/sdk-options.md
...rticles/communication-services/concepts/sdk-options.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Windows Heavy
Summary
The documentation page demonstrates a Windows-first bias, particularly in the SDK platform support section, where Windows and .NET/WinUI platforms are described in greater detail and listed before Linux and macOS. The .NET section provides specific Windows version support and features, while Linux and macOS are only briefly mentioned as supported via .NET Standard 2.0, without further details or guidance. There are no explicit Linux or macOS usage examples, and the documentation does not mention Linux-specific tools or patterns.
Recommendations
- Provide explicit Linux and macOS platform support details, including supported distributions/versions, installation instructions, and known limitations.
- Include Linux/macOS-specific usage examples or troubleshooting tips, especially for SDK installation and usage.
- Balance the order of platform presentation by listing Linux and macOS alongside Windows, rather than after detailed Windows sections.
- Mention cross-platform CLI tools (e.g., Azure CLI, curl) and provide examples for REST API usage on Linux/macOS.
- If there are any platform-specific caveats or requirements for Linux/macOS, document them clearly.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/devtest-labs/devtest-lab-store-secrets-in-key-vault.md
...devtest-labs/devtest-lab-store-secrets-in-key-vault.md
Medium Priority
View Details →
Detected Bias Types
Windows First
Missing Linux Example
Summary
The documentation page refers to 'passwords for your Windows VMs' and 'public SSH keys for your Linux VMs', but all subsequent instructions, screenshots, and examples are generic and do not provide specific Linux-oriented workflows or examples. The initial mention of Windows precedes Linux, and there are no Linux-specific examples or command-line instructions (e.g., using Bash or Linux tools) for interacting with the key vault or using secrets with Linux VMs.
Recommendations
- Provide explicit Linux-focused examples, such as how to use stored SSH keys with Linux VMs.
- Include command-line instructions for both Windows (PowerShell) and Linux (Bash) environments where relevant.
- Ensure that screenshots and UI instructions mention Linux VM scenarios equally, not just Windows password entry.
- When listing use cases, alternate or balance the order of Windows and Linux examples to avoid a 'Windows-first' impression.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-netapp-files/reestablish-deleted-volume-relationships.md
...tapp-files/reestablish-deleted-volume-relationships.md
Medium Priority
View Details →
Detected Bias Types
Powershell Heavy
Windows First
Summary
The documentation primarily provides Azure PowerShell commands for feature registration, with PowerShell examples shown first and in detail. Although Azure CLI is mentioned, it is only referenced in passing via a link, with no explicit CLI command examples given. This approach favors Windows/PowerShell users and may disadvantage Linux or cross-platform users who typically use Azure CLI.
Recommendations
- Provide explicit Azure CLI command examples (e.g., 'az feature register --namespace Microsoft.NetApp --name ANFReestablishReplication') alongside PowerShell examples.
- Present both PowerShell and CLI examples in parallel or in a clearly separated manner, rather than favoring one over the other.
- Consider mentioning that Azure CLI is cross-platform and suitable for Linux/macOS users.
- Ensure that all command-line instructions are available in both PowerShell and CLI formats to improve accessibility for non-Windows users.
Azure Docs
https://github.com/MicrosoftDocs/azure-docs/blob/main//articles/azure-netapp-files/performance-oracle-multiple-volumes.md
...re-netapp-files/performance-oracle-multiple-volumes.md
Medium Priority
View Details →
Detected Bias Types
Linux Only
Missing Windows Example
Summary
The documentation is heavily focused on Linux environments, with all configuration, tuning, and command-line examples (such as 'ip a', 'ethtool', and sysctl settings) being specific to Linux. There are no examples, instructions, or considerations provided for Windows-based Oracle deployments, nor is there any mention of Windows tools or PowerShell. This creates a bias toward Linux and may leave Windows administrators without guidance.
Recommendations
- Add equivalent instructions and examples for deploying and configuring Oracle on Windows Server VMs, including guidance for mounting Azure NetApp Files via SMB or NFS on Windows.
- Provide PowerShell or Windows command-line alternatives for network and NIC configuration checks (e.g., using 'Get-NetAdapter', 'Get-NetIPAddress', or 'Get-NetAdapterAdvancedProperty').
- Document any differences or limitations when using Azure NetApp Files with Oracle on Windows, such as supported protocols, performance tuning, and best practices.
- Include sample Windows system configuration settings relevant to Oracle (e.g., registry tweaks, Windows networking stack tuning, etc.).
- Clarify in the introduction or prerequisites that the guidance is Linux-centric, or explicitly state if Windows is not supported for this scenario.