79
Pages Scanned
18
Pages Flagged
79
Changed Pages
22.8%
% Pages Flagged
Scan Information
Started At: 2026-01-22 01:38:43
Finished At: 2026-01-22 01:44:42
Status: completed
Target Repo: Azure
Current Phase: discovery
Files Queued: 79
Files Completed: 79
Problematic Pages
19 issues found
VPN Gateway
Troubleshoot Azure point-to-site connection problems
...way-troubleshoot-vpn-point-to-site-connection-problems.md
Medium Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
missing_linux_example
Summary
The documentation for troubleshooting Azure point-to-site VPN connections is heavily Windows-centric. Most troubleshooting steps, error messages, and solutions reference Windows-specific tools (Certificate Manager, mmc.exe, registry edits, Device Manager), PowerShell commands, and Windows file paths. There are no examples or guidance for Linux or macOS VPN clients, nor are equivalent troubleshooting steps provided for non-Windows platforms. This creates friction for users on Linux or macOS, who may encounter similar issues but lack documentation support.
Recommendations
- Add troubleshooting sections for Linux and macOS VPN clients, including common error messages and solutions.
- Provide equivalent commands and file paths for certificate management and VPN configuration on Linux/macOS (e.g., using OpenVPN, NetworkManager, strongSwan, or native tools).
- Include Linux/macOS examples for checking certificate installation, DNS resolution, and network connectivity.
- Where PowerShell or Windows registry edits are mentioned, offer alternative steps for Linux/macOS (such as editing configuration files or using system utilities).
- Clearly indicate which issues are Windows-only and which are cross-platform, to help users quickly identify relevant guidance.
Create Pull Request
Artifact Signing
Set up signing integrations to use Artifact Signing
...ticles/artifact-signing/how-to-signing-integrations.md
Medium Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
missing_linux_example
Summary
The documentation page for 'Set up signing integrations to use Artifact Signing' demonstrates notable Windows bias in the SignTool integration section. All setup instructions, prerequisites, and examples are exclusively for Windows environments, relying on Windows-specific tools (SignTool.exe, MSI installers, WinGet, PowerShell commands). There are no equivalent instructions or examples for Linux/macOS users, nor is it clarified whether SignTool or the Artifact Signing Client Tools can be used outside Windows. Other integrations (GitHub Actions, Azure DevOps, SDK) are mentioned but not detailed, and the primary walkthrough is Windows-centric.
Recommendations
- Explicitly state if SignTool integration is Windows-only, and clarify platform support for Artifact Signing Client Tools.
- Provide parity examples for Linux/macOS users where possible (e.g., SDK usage, CLI commands, or alternative signing tools).
- Add setup instructions for Artifact Signing via GitHub Actions, Azure DevOps, and SDK directly in this documentation, including platform-agnostic steps.
- If certain integrations are Windows-only, clearly label those sections and provide alternative guidance for non-Windows users.
- Include a comparison table of supported platforms for each integration.
Azure Functions
Azure Functions Core Tools reference
...cles/azure-functions/functions-core-tools-reference.md
Medium Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
Summary
The documentation is generally cross-platform, but there are several areas where Windows and Windows-specific tools or patterns are mentioned first or exclusively. PowerShell is called out as a supported worker runtime, and some options (such as --managed-dependencies) are only available for PowerShell. There are warnings and guidance about Python packaging on Windows, and some instructions (such as certificate creation for --useHttps) imply Windows-centric workflows. In some cases, Windows behaviors or issues are described before Linux equivalents, and Docker usage is sometimes described in a way that assumes Windows as the local environment.
Recommendations
- Ensure that examples and guidance for Linux/macOS environments are provided alongside Windows-specific notes, especially for areas like Docker usage, certificate creation, and Python packaging.
- When describing platform-specific issues (e.g., Python packaging on Windows), offer equivalent Linux/macOS instructions and troubleshooting steps.
- Where PowerShell or Windows-specific options are mentioned, clarify their applicability and provide parity for Bash/zsh or other shells if relevant.
- Avoid presenting Windows tools or workflows before Linux/macOS equivalents unless there is a technical reason.
- Explicitly note cross-platform support in introductory sections and command explanations.
Backup
Quick start - Back up Azure Database for PostgreSQL server
...cles/backup/quick-backup-postgresql-database-portal.md
Medium Priority
View Details →
Detected Bias Types
powershell_heavy
windows_first
Summary
The documentation references PowerShell scripts multiple times as the primary method for granting privileges to database users, with alternatives like PG Admin or PSQL mentioned only as secondary options. The explicit callout to PowerShell in both the prerequisites and configuration steps, and the phrasing that prioritizes PowerShell, create a Windows-first impression. Linux-native tools are not given equal prominence or example coverage.
Recommendations
- Provide explicit, step-by-step examples for granting privileges using psql (command-line) and/or PG Admin, not just mention them as alternatives.
- Where PowerShell scripts are referenced, include equivalent bash/psql commands or scripts for Linux/macOS users.
- In prerequisites and main steps, list Linux/macOS-friendly methods (e.g., psql, bash scripts) alongside or before PowerShell, to avoid the impression that PowerShell is the default or only supported method.
- Clarify that all steps can be performed on Linux/macOS as well as Windows, and link to relevant cross-platform tooling documentation.
Event Grid
Quickstart: Publish on an MQTT topic by using the CLI
.../articles/event-grid/mqtt-publish-and-subscribe-cli.md
Medium Priority
View Details →
Detected Bias Types
powershell_heavy
missing_linux_example
windows_tools
Summary
The documentation provides certificate generation instructions exclusively using PowerShell commands and Windows-centric guidance (e.g., opening Command Prompt via Win+R), without offering equivalent Linux/macOS shell commands or workflows. The .NET sample code is cross-platform, but the certificate generation steps are Windows-focused, which may hinder Linux/macOS users.
Recommendations
- Provide Linux/macOS shell (bash) equivalents for certificate generation using the step CLI, including commands for common Linux/macOS environments.
- Avoid referencing Windows-specific UI actions (such as 'Win+R') without offering alternatives for other platforms.
- Clarify that the step CLI is cross-platform and provide installation and usage notes for Linux/macOS.
- If possible, include a table or section showing certificate generation commands for Windows (PowerShell), Linux (bash), and macOS (zsh/bash).
Medium Priority
View Details →
Detected Bias Types
powershell_heavy
windows_tools
Summary
The documentation is generally cross-platform and focuses on Azure portal and Kusto queries, which are platform-agnostic. However, there is a notable bias in the section about enabling the Azure Firewall Fat Flow Log (Top flow log), which states that configuration must be done through Azure PowerShell, with no mention of Azure CLI or Bash alternatives. Additionally, the tip about log converter tools references Visual Studio and C#, which are traditionally Windows-centric, without suggesting Linux/macOS alternatives.
Recommendations
- Provide Azure CLI or REST API instructions for enabling Fat Flow Log, or clarify if PowerShell is the only supported method.
- Mention cross-platform code editors (such as VS Code) and .NET Core for log converter tools, or provide equivalent tools/scripts for Linux/macOS users.
- Where PowerShell is referenced, add notes about installation and usage on Linux/macOS, or link to relevant cross-platform documentation.
- Ensure that all example workflows (such as downloading and converting logs) include Linux/macOS-friendly tools (e.g., jq, csvkit, pandas) alongside Excel and Power BI.
Backup
Tutorial - Back up Azure Database for PostgreSQL server
...lob/main/articles/backup/tutorial-postgresql-backup.md
Medium Priority
View Details →
Detected Bias Types
powershell_heavy
windows_first
missing_linux_example
Summary
The documentation demonstrates a moderate Windows bias, primarily through the use of PowerShell scripts for privilege assignment and by referencing PowerShell before mentioning alternatives like PG admin or PSQL. There are no explicit Linux/macOS command-line examples, and the guidance for non-Windows users is less detailed, which may create friction for those users.
Recommendations
- Provide explicit Linux/macOS command-line examples using psql and/or bash scripts for privilege assignment and other database operations.
- When mentioning PowerShell scripts, always include equivalent steps using psql or PG admin, and present them side-by-side or in parallel sections.
- Clarify which steps are OS-agnostic (e.g., Azure portal actions) and which require OS-specific tooling, ensuring parity for Linux/macOS users.
- Add notes or links to official PostgreSQL documentation for privilege management via psql and PG admin.
Nat Gateway
Troubleshoot Azure NAT Gateway
...ocs/blob/main/articles/nat-gateway/troubleshoot-nat.md
Medium Priority
View Details →
Detected Bias Types
powershell_heavy
windows_tools
missing_linux_example
windows_first
Summary
The documentation provides troubleshooting steps and examples for both Windows and Linux in some areas (e.g., connectivity validation), but several sections show Windows bias. PowerShell and Windows-specific tools (PsPing, PowerShell cmdlets) are mentioned for critical troubleshooting tasks, while equivalent Linux commands or workflows are missing or less detailed. In some cases, Windows tools are listed before Linux alternatives, and Linux users are left to infer their own solutions.
Recommendations
- For sections that use PowerShell to resolve VM NIC failed states, provide equivalent Azure CLI commands or REST API steps for Linux/macOS users.
- Where Windows tools like PsPing and PowerShell Invoke-WebRequest are mentioned, add Linux equivalents (e.g., nc, curl, ss, telnet) with example usage.
- Ensure troubleshooting steps (such as resource state recovery) include platform-neutral or cross-platform instructions, not just PowerShell or GUI.
- When listing tools or commands, alternate the order or present both Linux and Windows options together to avoid Windows-first bias.
Sentinel
Anomalies detected by the Microsoft Sentinel machine learning engine
...ocs/blob/main/articles/sentinel/anomalies-reference.md
Medium Priority
View Details →
Detected Bias Types
windows_first
missing_linux_example
windows_tools
Summary
The documentation page describes anomaly detection features in Microsoft Sentinel, referencing a variety of data sources including Azure, AWS, GCP, Okta, and Office logs. However, there is a notable bias toward Windows environments: many anomaly types and detection algorithms are based exclusively on Windows Security logs (e.g., event IDs 4624 and 4625), with no mention of equivalent Linux/macOS log sources or examples. The documentation does not provide guidance or parity for Linux/macOS systems, nor does it mention how to enable similar anomaly detection for non-Windows hosts. Windows-specific tools and event patterns are referenced without Linux alternatives.
Recommendations
- Add sections or notes describing how Linux/macOS systems can be monitored for similar anomalies (e.g., using syslog, auditd, or other Linux-native logging sources).
- Provide equivalent Linux/macOS log event IDs or patterns for account creation, deletion, logon, and brute-force attempts.
- Clarify whether Sentinel supports anomaly detection for Linux/macOS hosts and, if so, document the required data connectors and log formats.
- Where Windows Security logs are referenced, add Linux/macOS examples or mention their absence if not supported.
- Consider including cross-platform examples or a table mapping Windows events to Linux/macOS equivalents.
Sentinel
The Advanced Security Information Model (ASIM) Process Event normalization schema reference | Microsoft Docs
...rticles/sentinel/normalization-schema-process-event.md
Medium Priority
View Details →
Detected Bias Types
windows_first
windows_examples
windows_terms
Summary
The documentation for the ASIM Process Event normalization schema is designed to be cross-platform and references support for both Windows and Linux systems. However, there is a noticeable Windows bias in the examples and terminology: most example process names and paths use Windows conventions (e.g., C:\Windows\explorer.exe), integrity levels are described only in terms of Windows, and links to further reading about process integrity reference Windows-specific documentation. Linux is mentioned as supported in some field notes, but Linux-specific examples, terminology, or links are absent.
Recommendations
- Add Linux/macOS process examples alongside Windows ones (e.g., /usr/bin/bash, /usr/bin/sshd).
- Describe process integrity and privilege concepts for Linux/macOS (e.g., user/group IDs, capabilities, SELinux contexts) or clarify that some fields are Windows-only.
- Include Linux/macOS-specific notes or links where relevant (e.g., for process creation, integrity, or privilege elevation).
- Balance example paths and process names between Windows and Linux/macOS.
- Clarify in field descriptions which concepts are OS-specific and provide cross-platform guidance.
Storage
Migrate to Azure Files using Azure Storage Mover
.../articles/storage/files/migrate-files-storage-mover.md
Medium Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
missing_linux_example
Summary
The documentation references Windows-centric migration tools (Robocopy) and mentions Azure PowerShell before Azure CLI, which may imply a Windows-first approach. There are no explicit Linux-specific migration examples, commands, or troubleshooting steps, despite Storage Mover supporting SMB shares from Linux and NAS sources. The agent deployment instructions mention Hyper-V and VMware but do not clarify Linux VM support or provide Linux-specific agent installation steps.
Recommendations
- Add explicit Linux agent deployment instructions, including supported Linux distributions and installation commands.
- Provide Linux-oriented examples for agent registration (e.g., SSH commands on Linux terminals).
- Mention Azure CLI and PowerShell equally, or provide CLI-first instructions for cross-platform parity.
- Include troubleshooting tips or FAQs for common Linux/NAS migration scenarios.
- Clarify if the agent can run on Linux VMs and provide guidance for those environments.
Storage
Configure a Site-to-Site VPN for Azure Files
...icles/storage/files/storage-files-configure-s2s-vpn.md
Medium Priority
View Details →
Detected Bias Types
windows_tools
windows_first
missing_linux_example
Summary
The documentation page provides a generally cross-platform approach for configuring a Site-to-Site VPN for Azure Files, with Azure Portal, PowerShell, and CLI instructions. However, there is a notable Windows bias in the 'Prerequisites' section, where Windows Server RRAS is mentioned as the only example of an on-premises VPN appliance, with no Linux alternatives suggested. Additionally, the example for retrieving the public IP address of the Azure VPN gateway is given only in PowerShell, with no CLI or Linux equivalent. While mounting instructions are linked for all major OSes, the initial guidance and examples tend to mention or prioritize Windows tools and patterns.
Recommendations
- In the 'Prerequisites' section, mention common Linux-based VPN appliances (e.g., strongSwan, OpenVPN, libreswan) as alternatives to Windows Server RRAS, and link to relevant configuration guides.
- When showing how to retrieve the public IP address of the Azure VPN gateway, provide both PowerShell and Azure CLI examples to ensure parity for Linux/macOS users.
- Where possible, avoid implying Windows Server is the default or only supported option for on-premises VPN appliances.
- Consider adding a brief note or table listing popular cross-platform VPN devices and linking to Azure's tested devices list, highlighting both Windows and Linux options.
Azure Functions
Azure Functions networking options
...ticles/azure-functions/functions-networking-options.md
Low Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
windows_tools
Summary
The documentation is generally cross-platform, but there are areas of Windows bias. In the 'Hybrid Connections' section, it is explicitly stated that this feature is only supported on Windows, which is a product limitation and not a documentation bias. However, in the 'Virtual network triggers (non-HTTP)' section, code examples are provided for Azure CLI, Azure PowerShell, and the Azure portal, with PowerShell (a Windows-centric tool) included alongside CLI. In the subnet sizing recommendations, Windows is mentioned before Linux, and the minimum subnet size for Windows is discussed first. There are no Linux/macOS-specific command-line examples or parity in automation tooling coverage. While Linux is supported and discussed, Windows patterns and tools are often mentioned first or more prominently.
Recommendations
- When providing automation examples, always include both Azure CLI and PowerShell, but consider showing Azure CLI (cross-platform) first, or explicitly noting parity.
- In subnet sizing and other recommendations, present Linux and Windows requirements side-by-side or in a neutral order.
- Where features are Windows-only (such as Hybrid Connections), clarify that this is a product limitation, not a documentation gap.
- Add Linux/macOS-specific notes or examples where relevant, especially in automation and troubleshooting sections.
- Ensure screenshots and UI walkthroughs are not Windows-specific unless the feature is Windows-only.
Backup
Use Azure Backup Server to back up workloads
...articles/backup/backup-azure-microsoft-azure-backup.md
Low Priority
View Details →
Detected Bias Types
windows_first
windows_tools
missing_linux_example
Summary
The documentation for Azure Backup Server (MABS) is heavily focused on Windows Server environments, with all installation, configuration, and operational instructions referencing Windows-only tools, paths, and procedures. There are no examples or guidance for Linux or macOS environments, nor is there any mention of cross-platform support. The documentation assumes the use of Windows Server, Windows-specific features (such as registry edits, Windows Server Deduplication, and PowerShell cmdlets), and Windows-based SQL Server instances.
Recommendations
- Explicitly state early in the documentation that Azure Backup Server (MABS) is a Windows-only product, if that is the case, to set expectations for non-Windows users.
- If any components or features are cross-platform or have Linux/macOS support (e.g., agent-based backup for Linux workloads), provide clear sections or links to those instructions.
- For any generic Azure Backup features that support Linux, provide parity examples or references.
- If MABS is strictly Windows-only, consider adding a note or table comparing it to other Azure Backup solutions that support Linux workloads, guiding users to the appropriate documentation.
Sentinel
The Advanced Security Information Model (ASIM) Authentication normalization schema reference | Microsoft Docs
...ticles/sentinel/normalization-schema-authentication.md
Low Priority
View Details →
Detected Bias Types
windows_first
Summary
The documentation references Windows as an example OS in several places (e.g., 'Windows sends several authentication events'), and Windows-style values (such as domain\hostname formats and SIDs) are used in example field values. However, the schema itself is designed to be cross-platform, supporting Linux, macOS, cloud, and third-party sources. No examples or patterns are exclusively Windows, and Linux/macOS equivalents are not omitted, but Windows is often mentioned first or as the primary example.
Recommendations
- Include Linux/macOS examples alongside Windows in field value examples (e.g., show a Linux hostname, a Linux user, or a Linux authentication protocol such as SSH).
- When describing formats (e.g., FQDN), clarify support for Linux/macOS conventions, not just Windows domain\hostname.
- In introductory text, mention that authentication events can come from Linux, macOS, and network devices, not just Windows.
- Balance examples so that Windows is not always the first or only example given.
Sentinel
The Advanced Security Information Model (ASIM) DHCP normalization schema reference | Microsoft Docs
...ob/main/articles/sentinel/normalization-schema-dhcp.md
Low Priority
View Details →
Detected Bias Types
windows_first
windows_tools
Summary
The documentation for the ASIM DHCP normalization schema is generally platform-neutral, but there are minor signs of Windows bias. Windows-specific terminology and examples (such as referencing the Windows DHCP server and its logging format, and using Windows domain/hostname formats) are mentioned before or more prominently than Linux equivalents. There are no Linux-specific examples or clarifications about non-Windows DHCP servers, and the only concrete example of a hostname uses a Windows-style name.
Recommendations
- Add examples or notes for Linux-based DHCP servers (e.g., ISC DHCP, Kea) and their log formats.
- Clarify how the schema applies to non-Windows DHCP implementations, especially regarding MAC address formatting and session identifiers.
- Provide sample hostnames and domain formats from Linux/Unix environments alongside Windows examples.
- Explicitly state that the schema is designed to be source-agnostic and mention common Linux DHCP server fields where relevant.
Sentinel
The Advanced Security Information Model (ASIM) File Event normalization schema reference| Microsoft Docs
...n/articles/sentinel/normalization-schema-file-event.md
Low Priority
View Details →
Detected Bias Types
windows_first
Summary
The documentation presents Windows examples before Linux equivalents in several places, such as in the 'Schema overview' and 'Path structure' sections. For instance, the example for file renaming uses 'Windows File Explorer' and Windows-style paths are shown first in tables. However, Linux/Unix paths and concepts are also included, and there are no sections that are Windows-only or missing Linux examples entirely.
Recommendations
- Alternate the order of examples so that Linux/Unix paths and tools are shown first in some sections.
- Provide parallel examples for both Windows and Linux/Unix when demonstrating concepts (e.g., file operations, process names).
- Explicitly mention Linux/Unix tools or processes in narrative examples, not just in tables.
- Clarify that the schema is designed to support both Windows and Linux/Unix systems equally.
Sentinel
Microsoft Sentinel user management normalization schema reference | Microsoft Docs
...icles/sentinel/normalization-schema-user-management.md
Low Priority
View Details →
Detected Bias Types
windows_first
Summary
The documentation provides normalization schema details for user management activities in Microsoft Sentinel, supporting both Windows and Linux systems. However, there is a minor bias in the ordering and example formats: Windows identifiers (SID, domain\username) are consistently listed before Linux equivalents (UID, simple username), and Windows formats are shown first in field priority lists. No Windows-only tools, commands, or PowerShell examples are present, and Linux is included in all relevant places.
Recommendations
- Alternate the order of Windows and Linux examples in field format lists to avoid implicit prioritization.
- Explicitly state that all formats (Windows, Linux, cloud) are equally supported.
- Provide example values for Linux (e.g., UID, simple username) alongside Windows examples in tables and descriptions.
- Where field priorities are listed, consider rotating which format is shown first or clarify that order does not imply preference.
Storage
Use Azure Files for Azure Kubernetes Workloads
...es/storage/files/azure-kubernetes-service-workloads.md
Low Priority
View Details →
Detected Bias Types
windows_first
powershell_heavy
missing_linux_example
windows_tools
Summary
The documentation provides examples and guidance for both Linux and Windows node pools, but there is a slight tendency to mention Windows support and SMB protocol before Linux/NFS equivalents. Most YAML and CLI examples are generic and work for both platforms, but NFS (Linux-only) is less emphasized and lacks dedicated YAML examples. Windows-specific tools or PowerShell are not directly referenced, but SMB (Windows-centric) is often the default protocol shown. Linux mount options are documented in detail, but Windows mount options are not, which may be a minor friction for Windows users, but the overall impact is low for Linux users.
Recommendations
- Add explicit YAML examples for NFS protocol and Linux-only scenarios, especially for dynamic and static provisioning.
- Where protocols are discussed, present Linux/NFS and Windows/SMB options equally, or start with Linux/NFS when describing Linux node pool scenarios.
- Include a brief section or link for Windows-specific mount options or troubleshooting for parity.
- Clarify in each example which platforms (Linux/Windows) are supported, and provide guidance for Linux-first deployments where appropriate.