283
Total Pages
234
Linux-Friendly Pages
49
Pages with Bias
17.3%
Bias Rate

Bias Trend Over Time

Pages with Bias Issues (127)

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a mild Windows bias, particularly in the certificate creation section, where only PowerShell is mentioned as a method for creating self-signed certificates. There are no Linux or cross-platform command-line examples (such as OpenSSL) provided for certificate generation. The rest of the documentation is largely platform-agnostic, focusing on Azure portal steps and XML configuration, but the omission of Linux tooling in certificate management is notable.
Recommendations:
  • Add Linux and cross-platform examples for creating self-signed certificates, such as using OpenSSL, alongside the existing PowerShell instructions.
  • Explicitly mention that certificate creation can be performed on any OS, and provide equivalent command-line instructions for macOS and Linux users.
  • Wherever PowerShell or Windows-specific tooling is referenced, ensure a Linux alternative is also provided or linked.
  • Consider including a table or section comparing certificate creation methods across Windows (PowerShell), Linux (OpenSSL), and macOS.

Page-Level Analysis

Missing Linux Example Windows Tools Windows First
Summary:
The documentation page demonstrates a Windows bias by referencing Windows-specific tools (Visual Studio, Azure Storage Explorer) and workflows without providing Linux equivalents or alternatives. There are no command-line examples or instructions for Linux users, and the only publishing workflow mentioned is via Visual Studio, which is primarily a Windows application. The documentation also references Azure Storage Explorer, which, while cross-platform, is often associated with Windows, and does not mention alternative CLI tools or methods for Linux users.
Recommendations:
  • Provide alternative instructions for deploying the API using cross-platform tools such as the Azure CLI, Azure DevOps, or VS Code, including command-line examples.
  • Explicitly mention and provide examples for Linux and macOS users, such as using the 'az storage' CLI for blob uploads and CORS configuration.
  • When referencing tools like Visual Studio or Azure Storage Explorer, clarify their cross-platform availability or suggest alternatives (e.g., VS Code, azcopy, Azure CLI).
  • Include shell (bash) command examples for common tasks like uploading files to Azure Blob Storage, setting CORS, and managing app settings.
  • Ensure that all steps that can be performed via the Azure Portal are also described for CLI/automation scenarios, which are common on Linux.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing Windows tools (Server Manager, AD FS Management), providing only GUI-based instructions for AD FS configuration, and omitting any Linux-based or cross-platform alternatives. There are no PowerShell or command-line examples, but all setup steps assume a Windows Server environment with AD FS, and no mention is made of how to achieve similar outcomes on Linux or with non-Windows identity providers. The documentation also introduces Windows-specific concepts and tools before any platform-agnostic configuration steps.
Recommendations:
  • Add command-line (PowerShell and, if possible, cross-platform CLI) instructions for AD FS configuration to supplement or replace GUI steps.
  • Explicitly state that AD FS is a Windows Server feature, and provide guidance or links for integrating with non-Windows OpenID Connect providers (e.g., Keycloak, IdentityServer, or cloud-based IdPs) for Linux users.
  • Where possible, generalize the instructions to apply to any OpenID Connect provider, and provide a parallel example using a popular Linux-compatible IdP.
  • Include a section or note for Linux administrators explaining the lack of AD FS support on Linux and suggesting alternatives for similar integration.
  • Reorder or supplement examples so that platform-agnostic or Linux-friendly options are presented alongside or before Windows-specific instructions.

Page-Level Analysis

Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation demonstrates a strong Windows bias: all administrative steps for configuring AD FS are described using Windows-only tools such as Server Manager, AD FS Management snap-in, Event Viewer, and PowerShell cmdlets. There are no Linux or cross-platform alternatives or notes, and Windows-specific patterns are always presented first and exclusively. Troubleshooting and configuration guidance assumes a Windows environment throughout.
Recommendations:
  • Explicitly note that AD FS is a Windows Server technology and clarify platform requirements early in the documentation.
  • Where possible, provide equivalent SAML identity provider configuration steps for common Linux-based SAML providers (e.g., Shibboleth, SimpleSAMLphp) or link to relevant guides.
  • For certificate creation and management, include Linux/OpenSSL command-line examples alongside any Windows-specific instructions.
  • For troubleshooting, suggest generic SAML troubleshooting tools (such as SAML-tracer browser extension, or logs from Linux SAML IdPs) in addition to Windows Event Viewer.
  • If PowerShell is required, clarify that these steps are only for AD FS on Windows, and suggest alternative approaches for non-Windows environments where feasible.
  • Consider adding a section or links for users who wish to integrate with non-Windows SAML providers, outlining the differences and additional considerations.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not provide any OS-specific examples or tooling, but it also does not include any command-line or scripting examples at all. This omission means there is no explicit Windows bias, but there is a lack of parity in that neither Windows (e.g., PowerShell) nor Linux (e.g., Bash/cURL) approaches are demonstrated. Readers are left without practical, platform-agnostic examples for interacting with the Microsoft Graph API.
Recommendations:
  • Add practical examples for deleting and exporting user data using both PowerShell (for Windows users) and Bash/cURL (for Linux/macOS users).
  • Ensure that any command-line examples are provided in both Windows and Linux formats, or use platform-agnostic tools where possible.
  • Explicitly mention that the Microsoft Graph API can be accessed from any OS, and link to relevant SDKs or CLI tools for different platforms.
  • If using screenshots or UI walkthroughs, ensure they are not Windows-specific or provide Linux/macOS equivalents.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation exclusively references the Azure portal web UI for configuration and does not provide any command-line examples. There are no explicit references to Windows-only tools like PowerShell, but the workflow assumes a graphical interface that is most familiar to Windows users. There is no mention of Linux command-line tools (such as Azure CLI), nor are there any CLI-based instructions or examples for Linux or cross-platform users.
Recommendations:
  • Add Azure CLI examples for all major steps, such as registering applications, creating secrets, and configuring identity providers. Ensure these examples are cross-platform.
  • Explicitly mention that all portal steps can be performed from any OS with a web browser, to clarify that the instructions are not Windows-specific.
  • Where possible, provide REST API or scripting alternatives for automation and parity with non-Windows environments.
  • Include a section or callout for Linux/macOS users, highlighting any differences or additional steps if applicable.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on WPF, a Windows-only technology, and all code samples are in C# using Windows-specific APIs (e.g., WindowInteropHelper). There are no examples or mentions of Linux or cross-platform desktop application frameworks, nor any guidance for developers targeting non-Windows environments. The documentation assumes a Windows development environment and does not provide parity for Linux users.
Recommendations:
  • Add equivalent guidance and code samples for cross-platform desktop frameworks such as .NET MAUI, Avalonia, or Electron, which can run on Linux.
  • Include instructions and examples for configuring authentication in Linux desktop applications using Azure AD B2C.
  • Clarify in the introduction that the guidance is specific to WPF/Windows, and provide links or references to cross-platform alternatives.
  • If possible, provide MSAL usage examples in a cross-platform context (e.g., .NET Core/MAUI) that work on Linux.
  • Mention any platform-specific limitations or requirements explicitly, and suggest alternatives for non-Windows developers.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation page focuses exclusively on ASP.NET Core and C# code, referencing project structures and files (e.g., Startup.cs, appsettings.json) that are typical of Windows/.NET development environments. There are no examples or guidance for Linux or cross-platform development environments, nor are there any mentions of command-line tools or workflows outside the Windows/.NET ecosystem.
Recommendations:
  • Include explicit notes or examples for developers working on Linux or macOS, such as how to locate and edit configuration files, or how to run and debug ASP.NET Core applications using the dotnet CLI.
  • Mention that ASP.NET Core is cross-platform and provide links or references to official guidance for developing and deploying on Linux and macOS.
  • If relevant, provide bash or shell command equivalents for any setup or configuration steps that might otherwise be performed in Windows-specific tools.
  • Clarify that the instructions and code samples apply to any platform where .NET Core is supported, not just Windows.
  • Consider including a section or callout box highlighting any platform-specific considerations (e.g., file paths, environment variables) for Linux users.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily oriented towards Windows development environments. It exclusively references Visual Studio (a Windows-centric IDE), .sln solution files, and Web.config XML configuration, all of which are typical of Windows/.NET development. There are no instructions or examples for Linux-based development environments, editors, or deployment scenarios. No mention is made of cross-platform .NET Core/ASP.NET Core, nor are there any Linux command-line or editor alternatives provided.
Recommendations:
  • Include instructions for opening and editing the project using cross-platform editors such as VS Code or JetBrains Rider, and clarify that .NET projects can be developed on Linux and macOS as well as Windows.
  • Provide examples for updating configuration using appsettings.json (used in .NET Core/ASP.NET Core) in addition to Web.config, or clarify the applicability to .NET Framework vs .NET Core.
  • Offer command-line instructions using the dotnet CLI (e.g., 'dotnet build', 'dotnet run') for building and running the sample, rather than assuming Visual Studio usage.
  • Explicitly mention that the sample and approach are applicable to Linux and macOS environments, and provide any necessary caveats or adjustments.
  • If any steps are specific to Windows (such as using Visual Studio), provide equivalent steps for Linux (e.g., using VS Code, nano, or vim to edit files).

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates a subtle Windows bias by referencing Windows-specific guidance first in at least one key area, and by omitting explicit Linux or cross-platform examples or instructions. Specifically, the link to securing REST APIs for technical profiles points to a documentation page with a 'tabs=windows' parameter, indicating Windows-first or Windows-only instructions. There are no PowerShell scripts or Windows tools directly shown, but the lack of Linux or cross-platform parity in referenced links and examples may hinder non-Windows users.
Recommendations:
  • Ensure that all referenced documentation links (such as those for securing REST APIs) either default to a cross-platform view or provide clear tabs for both Windows and Linux, with neither prioritized by default.
  • Explicitly mention that the steps and examples are platform-agnostic where possible, or provide parallel instructions for Linux/macOS environments if any step is platform-dependent.
  • Audit all external documentation links to confirm that Linux and macOS users are equally supported and not directed to Windows-specific instructions by default.
  • If any scripts or command-line examples are added in the future, provide both PowerShell (Windows) and Bash (Linux/macOS) versions.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not display overt Windows bias in terms of command-line examples, tools, or patterns. However, it assumes the use of Visual Studio Code (VS Code) as a prerequisite without mentioning Linux-specific alternatives or considerations. There are no OS-specific instructions, scripts, or screenshots, and no mention of PowerShell or Windows-only tools. The documentation is largely platform-neutral but lacks explicit Linux parity guidance or examples.
Recommendations:
  • Explicitly state that Visual Studio Code is cross-platform and provide installation links or instructions for Linux and macOS users.
  • Mention that all XML editing and Azure portal steps can be performed on Linux, macOS, or Windows.
  • If any command-line or scripting steps are added in the future, provide both Windows (PowerShell/CMD) and Linux/macOS (Bash) examples.
  • Include a note clarifying that the process is OS-agnostic and does not require Windows.
  • If screenshots are used, consider including examples from both Windows and Linux environments, or use neutral browser-based screenshots.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not display overt Windows bias in terms of command-line examples or tool references (such as PowerShell or Windows-specific tools). However, it is biased toward GUI-based instructions via the Azure Portal and does not provide any CLI-based examples (such as Azure CLI, Bash, or scripting), which are commonly used on Linux and cross-platform environments. There are no instructions or examples for performing these tasks using command-line tools that are available and popular on Linux.
Recommendations:
  • Add equivalent instructions for registering applications, granting permissions, and creating client secrets using the Azure CLI (az commands), which is cross-platform and widely used on Linux.
  • Provide sample scripts or command-line snippets for automating these tasks in Bash or shell environments.
  • Explicitly mention that all steps can be performed via CLI and link to relevant CLI documentation.
  • Ensure parity by including both portal (GUI) and CLI/script-based workflows in all sections where management actions are described.

Page-Level Analysis

Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation page primarily uses generic command shell instructions for most steps, but in the final 'Run your SPA application' section, it provides a PowerShell-specific command example (npm ./index.js), which is not valid on Linux/macOS shells. There are no explicit Linux/macOS instructions or clarifications, and no mention of platform differences, leading to a subtle Windows/PowerShell bias.
Recommendations:
  • Provide both Windows (PowerShell/cmd) and Linux/macOS (bash/sh) command examples, especially for running Node.js applications (e.g., 'node index.js' instead of 'npm ./index.js').
  • Clarify that the instructions are cross-platform and specify any platform-specific differences where relevant.
  • Avoid using PowerShell-specific syntax unless necessary, or always accompany it with the equivalent bash command.
  • Explicitly mention that the steps work on Windows, Linux, and macOS, and provide troubleshooting tips for each platform if needed.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias in the section on revoking a consumer user's session. It exclusively provides instructions and examples for using Microsoft Graph PowerShell in 'Windows PowerShell', without mentioning cross-platform alternatives or providing equivalent Linux/macOS command-line guidance. The use of 'Windows PowerShell' and lack of Bash/CLI/Cloud Shell examples may hinder Linux and macOS users.
Recommendations:
  • Clarify that Microsoft Graph PowerShell is cross-platform and can be used in PowerShell Core on Linux and macOS, not just 'Windows PowerShell'.
  • Provide explicit instructions and examples for running Microsoft Graph PowerShell on Linux/macOS (e.g., using pwsh).
  • Offer alternative examples using Azure CLI or direct Microsoft Graph API calls with curl or httpie, which are platform-agnostic.
  • Avoid language that implies Windows is required (e.g., 'In your Windows PowerShell'), and instead use neutral phrasing such as 'In your terminal' or 'In PowerShell'.
  • Add a note or section for Linux/macOS users, highlighting any platform-specific considerations or prerequisites.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by referencing Windows-specific tools and patterns (such as ASP.NET MVC, OWIN middleware, and .NET code samples) without providing equivalent Linux or cross-platform alternatives. Certificate management and application examples are oriented toward Windows environments, and there is a lack of explicit Linux-based instructions or examples for key steps such as application development, certificate creation, and configuration.
Recommendations:
  • Provide Linux-based examples for certificate creation and management (e.g., using OpenSSL commands) alongside or instead of Windows-centric instructions.
  • Include sample applications and code snippets that use cross-platform frameworks (such as Node.js, Python Flask/Django, or Java Spring) in addition to or instead of ASP.NET MVC/OWIN.
  • Reference Linux-compatible tools and workflows for application deployment and configuration, such as using Docker containers, shell scripts, or Linux-native editors.
  • Ensure that all steps (especially those involving file manipulation, certificate handling, and application configuration) have clear instructions for both Windows and Linux users.
  • Where possible, use platform-agnostic language and avoid assuming the reader is using Windows.

Page-Level Analysis

Windows First
Summary:
The documentation demonstrates a mild 'windows_first' bias in the section on generating a development signature hash for the redirect URI. The Windows command is presented first, followed by the iOS (Unix-like) version, with no explicit mention of Linux. No other sections show Windows-specific tools, PowerShell, or missing Linux examples.
Recommendations:
  • Explicitly mention Linux alongside iOS/macOS for Unix-like environments in the signature hash generation step (e.g., 'For Linux/macOS:').
  • Consider presenting cross-platform or Linux instructions before or alongside Windows instructions to avoid the impression of Windows primacy.
  • Where possible, clarify that the non-Windows command works for both Linux and macOS, not just iOS.
  • Review other documentation pages linked from this one to ensure Linux parity in all prerequisite and follow-up steps.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a Windows bias by specifically mentioning Windows Hello as the primary example of biometric authentication, both in the introduction and in the scenario walkthrough. Windows Hello is referenced before any mention of biometric options on other platforms, and there are no explicit examples or tool references for Linux or macOS biometric authentication. The documentation does not provide parity in naming or describing Linux (or other OS) equivalents, nor does it offer platform-agnostic guidance.
Recommendations:
  • Include explicit references to biometric authentication methods available on Linux (such as fprintd, or biometric support in GNOME/KDE environments) and macOS (Touch ID, Face ID).
  • When describing scenarios, alternate or parallelize examples so that Windows, Linux, and macOS users see their platforms represented equally (e.g., 'After logging in with a Windows computer using Windows Hello, a Linux computer using fprintd, or a Mac using Touch ID...').
  • Avoid listing Windows tools or features (like Windows Hello) before mentioning cross-platform or other OS equivalents.
  • Add a section or table summarizing supported biometric authentication methods across different operating systems, with links to relevant setup guides for each.
  • Ensure screenshots or UI walkthroughs are not exclusively Windows-centric, or provide equivalents for other platforms.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily Windows-centric, focusing exclusively on a WPF (Windows Presentation Foundation) desktop application and requiring Visual Studio 2019, which is only available on Windows. There are no instructions, examples, or mentions of Linux or cross-platform alternatives for building or running the sample application. The tooling and workflow described (Visual Studio, WPF, F5 debugging) are all Windows-specific, and there is no guidance for Linux users.
Recommendations:
  • Provide equivalent instructions for Linux users, such as using .NET Core cross-platform desktop frameworks (e.g., Avalonia or MAUI) if possible.
  • Include examples for building and running the sample application using the .NET CLI, which is available on Linux and macOS.
  • Mention and link to cross-platform IDEs or editors (e.g., VS Code, JetBrains Rider) and provide steps for using them.
  • If the sample is inherently Windows-only (WPF), clearly state this limitation at the top and suggest alternatives or similar samples for Linux users.
  • Consider providing a cross-platform sample application alongside the WPF sample to ensure parity for non-Windows developers.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a Windows bias by providing only PowerShell-based instructions for enabling Saviynt to delete users, explicitly requiring installation of the Microsoft Graph PowerShell module on a Windows workstation or server. There are no equivalent instructions or examples for Linux or cross-platform environments, and no mention of alternative tools (such as Azure CLI or Microsoft Graph CLI) that are available on Linux and macOS. This may limit accessibility for users operating in non-Windows environments.
Recommendations:
  • Provide equivalent instructions using cross-platform tools such as Azure CLI or Microsoft Graph CLI, which are supported on Linux and macOS.
  • Explicitly state that the PowerShell module can be used on PowerShell Core, which is available on Linux and macOS, if applicable.
  • Include Linux/macOS-specific setup steps or command-line examples where relevant.
  • Avoid language that restricts steps to 'Windows workstation or server' unless strictly necessary; instead, use 'workstation' or 'machine' and clarify OS compatibility.
  • Add a note or table summarizing tool availability and compatibility across operating systems.

Page-Level Analysis

Missing Linux Example Windows Tools Windows First
Summary:
The documentation demonstrates a Windows bias by referencing Visual Studio (a primarily Windows tool) as the publishing method for the API, without mentioning cross-platform alternatives or providing Linux/macOS deployment instructions. There are no examples or guidance for deploying the API from non-Windows environments, and the only linked deployment instructions are for Visual Studio. This may hinder Linux or macOS users from following the tutorial seamlessly.
Recommendations:
  • Include alternative deployment instructions for the API using cross-platform tools such as the Azure CLI, GitHub Actions, or command-line dotnet publish and az webapp deploy commands.
  • Provide explicit Linux/macOS deployment steps or reference documentation that covers these platforms.
  • When referencing tools like Visual Studio, also mention Visual Studio Code and/or command-line methods that work on all major operating systems.
  • Ensure that all steps that involve tooling or commands have parity between Windows and Linux/macOS environments.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation demonstrates a Windows bias by exclusively providing PowerShell scripts for critical steps such as creating self-signed certificates and generating random keys, without offering equivalent Linux/macOS commands or guidance. The use of PowerShell and references to Visual Studio (a Windows-centric tool) further reinforce this bias, making it less accessible for users on Linux or macOS platforms.
Recommendations:
  • Provide equivalent Bash/OpenSSL commands for creating self-signed certificates and generating random strings, ensuring Linux and macOS users can follow the tutorial.
  • Include explicit notes or sections for cross-platform compatibility, clarifying how each step can be performed on Windows, Linux, and macOS.
  • Mention and demonstrate the use of cross-platform tools (such as VS Code, Azure CLI, or OpenSSL) alongside Windows-specific tools like PowerShell and Visual Studio.
  • Where PowerShell is used, offer alternative scripts or command-line instructions for Bash/zsh.
  • Review all steps for hidden Windows assumptions (e.g., file paths, certificate stores) and document Linux/macOS equivalents.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page exhibits mild Windows bias, most notably in the SAML application registration link, which includes a '?tabs=windows' query parameter, suggesting that Windows-specific instructions or tabs are prioritized or shown by default. There are no explicit Linux or cross-platform examples or tabs mentioned, and no Linux-specific tools or instructions are referenced.
Recommendations:
  • Ensure that all platform-specific instructions (Windows, Linux, macOS) are equally represented in relevant sections and tabs.
  • Where tabs or pivots are used (e.g., '?tabs=windows'), provide equivalent Linux and macOS tabs, and consider making the default tab platform-neutral or based on user agent detection.
  • Explicitly mention cross-platform tools and workflows (such as using the Azure CLI or REST API) alongside any platform-specific instructions.
  • Review all linked tutorials to ensure Linux users are not disadvantaged or required to adapt Windows-specific steps.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation provides only a PowerShell script to monitor directory quota usage, with no equivalent example for Linux or cross-platform shells. The script uses Windows-specific cmdlets (Invoke-RestMethod, New-Object), and there is no mention of alternatives (such as Bash with curl or Python). This presents a clear Windows/Powershell bias and may hinder Linux or macOS users.
Recommendations:
  • Provide a Bash (curl) or Python example for Linux/macOS users to call the Microsoft Graph API and retrieve the directory quota.
  • Explicitly mention that the PowerShell script is for Windows, and offer equivalent instructions for other platforms.
  • Use cross-platform tools or note any platform-specific requirements.
  • Consider using the Microsoft Graph CLI or Azure CLI, which are cross-platform, as alternative examples.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation page mentions Microsoft PowerShell as an example HTTP client for testing the POST request, but does not mention any Linux or cross-platform alternatives (such as curl or HTTPie). No command-line examples are provided, and the only tool explicitly referenced is Windows-centric. This may make Linux or macOS users feel unsupported or unclear about how to proceed.
Recommendations:
  • Mention cross-platform HTTP clients such as curl or HTTPie alongside PowerShell.
  • Provide example commands for both PowerShell and curl to demonstrate how to make the POST request on different platforms.
  • Explicitly state that any HTTP client can be used, and provide at least one example for a non-Windows environment.
  • Consider including a table or section listing common tools for Windows, Linux, and macOS to ensure parity.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a subtle Windows bias by referencing Visual Studio as the first development environment and not providing explicit Linux-specific instructions or examples. While Visual Studio Code is mentioned (which is cross-platform), there are no explicit Linux or macOS setup or run instructions, nor are there any terminal commands or troubleshooting tips specific to non-Windows environments. All examples and guidance assume a Windows-like environment, especially in terms of file paths and tool usage.
Recommendations:
  • Explicitly mention Linux and macOS as supported platforms in the prerequisites and throughout the guide.
  • Provide Linux/macOS-specific instructions for installing .NET SDK, running the sample, and handling file paths.
  • Include terminal commands for building and running the application using the dotnet CLI, not just via Visual Studio or Visual Studio Code GUIs.
  • Add troubleshooting tips for common Linux/macOS issues (e.g., permissions, HTTPS certificates, path length differences).
  • Ensure screenshots and file path examples are not Windows-specific, or provide alternatives for other platforms.

Page-Level Analysis

Windows Tools
Summary:
The documentation is largely platform-neutral, focusing on HTTP requests and OAuth 2.0 protocol details. However, there is a subtle Windows bias in the suggestion to use 'Microsoft PowerShell' as an example HTTP client for testing POST requests, without mentioning Linux or cross-platform alternatives such as curl or HTTPie. No PowerShell-specific scripts or Windows-only tools are shown, but the only tool recommendation is Windows-centric.
Recommendations:
  • When suggesting HTTP clients for testing, mention cross-platform tools such as 'curl' or 'HTTPie' alongside or before 'Microsoft PowerShell'. For example: 'If you're testing this POST HTTP request, you can use any HTTP client such as curl, HTTPie, or Microsoft PowerShell.'
  • If providing example command-line invocations, include both Windows (PowerShell) and Linux/macOS (bash/curl) examples where appropriate.
  • Ensure that any tool recommendations or example commands are either cross-platform or that platform-specific alternatives are provided in parity.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation references Microsoft-specific tools and APIs (Azure portal, Microsoft Graph PowerShell SDK) without mentioning or providing parity for Linux or cross-platform alternatives. There are no Linux-specific instructions or examples, and the only programmatic example references PowerShell, which is traditionally associated with Windows, though it is now cross-platform. There is no mention of Linux command-line tools or workflows.
Recommendations:
  • Explicitly mention that Microsoft Graph PowerShell SDK is cross-platform and provide installation/use instructions for Linux/macOS.
  • Include examples using Microsoft Graph API with curl or other command-line tools available on Linux.
  • Clarify that the Azure portal is web-based and accessible from any OS.
  • Provide parity in programmatic examples by including both PowerShell and bash/curl (or Python) snippets.
  • Avoid implying that PowerShell is the only or primary automation method; highlight REST API usage as a first-class option.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation provides a PowerShell example for configuring password expiry duration using the Microsoft Graph PowerShell module, but does not offer equivalent command-line examples for Linux/macOS users (e.g., using Azure CLI, Bash, or REST with curl). The documentation also references PowerShell cmdlets and modules without mentioning cross-platform alternatives, which may disadvantage users on non-Windows systems.
Recommendations:
  • Provide equivalent examples using Azure CLI or direct REST API calls with curl, which are cross-platform and accessible to Linux/macOS users.
  • Explicitly mention that the Microsoft Graph PowerShell module is available cross-platform (if true), or clarify any OS limitations.
  • Where PowerShell is used, add a parallel example using Bash/curl for REST API operations.
  • Review all step-by-step instructions to ensure they do not assume use of Windows-specific tools or interfaces.
  • Add a note or section on how to perform these tasks from Linux/macOS environments, including installation instructions for any required tools.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation page mentions Microsoft PowerShell as an example HTTP client for testing the POST request, but does not mention any Linux or cross-platform alternatives (such as curl or HTTPie). There are no command-line examples provided, and the only tool referenced is Windows-centric. This may make Linux or macOS users feel unsupported or require them to infer how to perform the same actions on their platforms.
Recommendations:
  • When suggesting HTTP clients for testing, include cross-platform tools such as curl or HTTPie alongside PowerShell.
  • Provide explicit command-line examples using curl for making the POST request to obtain an access token.
  • If referencing PowerShell, clarify that it is available cross-platform, or provide both Windows and Linux/macOS instructions/examples.
  • Ensure that any tool recommendations or examples are inclusive of all major operating systems, not just Windows.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a subtle Windows bias by referencing Visual Studio as the primary IDE and not providing explicit Linux instructions or examples for running the sample application. While Visual Studio Code is mentioned (which is cross-platform), there are no Linux-specific setup or troubleshooting notes, and the workflow assumes a Windows-like environment (e.g., path length limitations, default use of localhost ports, and Visual Studio usage). There are no PowerShell or Windows command-line examples, but the absence of Linux-specific guidance or parity in tooling is notable.
Recommendations:
  • Explicitly mention Linux as a supported development environment in the prerequisites.
  • Provide Linux-specific instructions for installing .NET SDK, running the sample app, and handling common issues (such as port binding or file permissions).
  • Include example commands for running the application from the terminal (e.g., using `dotnet run`) in addition to or instead of relying on Visual Studio/VS Code UI.
  • Clarify any platform-specific considerations (such as path length limits, which may differ on Linux).
  • If screenshots are included, provide examples from both Windows and Linux environments where relevant.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First
Summary:
The documentation demonstrates some Windows bias, particularly in the instructions for generating GUIDs (recommending PowerShell's 'new-guid' command first) and in scripting examples (PowerShell script is presented before cURL). Windows/PowerShell tools and patterns are mentioned or shown before their Linux/Unix equivalents, and there is no explicit mention of Linux-native methods for certain tasks.
Recommendations:
  • When instructing users to generate a GUID, provide both PowerShell (Windows) and Linux/macOS (e.g., 'uuidgen' command) options side by side.
  • Present scripting examples (PowerShell and cURL) in parallel or clarify that cURL is cross-platform and may be preferred on Linux/macOS.
  • Avoid listing Windows/PowerShell tools or commands before cross-platform or Linux-native equivalents; instead, present them together or in a platform-neutral order.
  • Explicitly mention that all steps can be performed on Linux/macOS, and provide any necessary command-line alternatives.
  • Consider including bash or shell script examples for common automation tasks, not just PowerShell.

Page-Level Analysis

Windows First
Summary:
The documentation contains a subtle Windows bias by linking to API protection instructions that default to Windows-specific guidance. Specifically, the link to 'secure-rest-api.md?tabs=windows&pivots=b2c-custom-policy#using-oauth2-bearer' uses the 'windows' tab by default, potentially leading users to Windows-centric instructions before Linux equivalents. However, the main content, code samples, and configuration steps are platform-agnostic and do not reference Windows-only tools or PowerShell.
Recommendations:
  • Update documentation links to use a neutral or platform-agnostic tab (e.g., 'tabs=linux' or omit the tab parameter) when referencing external guides, or explicitly mention that Linux and macOS instructions are available.
  • Wherever platform-specific instructions are referenced, provide clear navigation or callouts for both Windows and Linux/macOS users.
  • Review linked documentation to ensure Linux and macOS parity, and consider including direct links to Linux/macOS instructions alongside Windows links.
  • Add a short note in the prerequisites or relevant sections stating that all steps can be performed on Windows, Linux, or macOS, and provide links to platform-specific setup guides if needed.

Page-Level Analysis

Windows Tools Windows First
Summary:
The documentation is generally platform-neutral, focusing on HTTP requests and OAuth 2.0 protocol details. However, there is a subtle Windows bias where Microsoft PowerShell is mentioned as an example HTTP client for testing POST requests, with no mention of Linux or cross-platform alternatives. Additionally, the only specific tool mentioned for making HTTP requests is PowerShell, which is primarily associated with Windows, and it is mentioned before any Linux or cross-platform equivalents.
Recommendations:
  • When suggesting HTTP clients for testing, mention cross-platform and Linux tools such as curl, HTTPie, or Postman alongside or before PowerShell.
  • Provide example commands using curl or HTTPie to demonstrate how to perform the HTTP requests on Linux and macOS systems.
  • Explicitly state that any HTTP client can be used, and provide at least one example for both Windows (PowerShell) and Linux/macOS (curl).
  • Avoid implying that PowerShell is the default or only tool for these tasks, and ensure parity in tool recommendations across platforms.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias by referencing Visual Studio (a Windows-centric IDE) before Visual Studio Code, and by using a sample configuration (e.g., redirect URI to https://localhost:44316) that aligns with default Windows/IIS Express ports. There are no explicit Linux or cross-platform instructions, nor are there terminal or deployment examples for Linux environments. The documentation does not mention Linux-specific tools, commands, or troubleshooting steps, and does not address potential differences in file paths or environment setup for Linux users.
Recommendations:
  • Explicitly mention Linux and macOS as supported platforms in the prerequisites, and provide guidance for installing .NET SDK and running ASP.NET Core apps on those systems.
  • Include Linux/macOS-specific instructions for extracting the sample, running the app (e.g., using the dotnet CLI), and troubleshooting common issues (such as port conflicts or permissions).
  • Provide examples of configuring the redirect URI for common Linux development environments (e.g., using ports commonly available on Linux, or referencing Kestrel rather than IIS Express).
  • Add notes about differences in file paths, environment variables, and permissions between Windows and Linux/macOS.
  • Where Visual Studio is mentioned, clarify that Visual Studio Code and the dotnet CLI are fully supported on Linux/macOS, and provide parity in example steps.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation generally provides cross-platform instructions, with separate command examples for Linux, macOS, and Windows. However, there is evidence of subtle Windows bias: (1) The instruction to extract the sample to a folder with a path length of 260 or fewer characters references a Windows-specific limitation without clarifying that this is not relevant on Linux/macOS; (2) The Windows command examples use 'py' instead of 'python', which is a Windows launcher, and this is presented after Linux/macOS, but the path length warning is not platform-scoped.
Recommendations:
  • Clarify that the 260-character path length limitation applies only to Windows, and is not relevant for Linux/macOS users.
  • Consider providing a brief note about the 'py' launcher being specific to Windows, and that 'python' is the standard command on Linux/macOS.
  • Where platform-specific limitations or tools are mentioned, explicitly scope them to the relevant OS to avoid confusion.
  • Continue to provide parity in command examples for all major platforms, and ensure that any warnings or notes are clearly attributed to the appropriate OS.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a bias towards Windows by providing only PowerShell examples for testing the REST API, referencing Microsoft PowerShell as the HTTP client, and omitting equivalent Linux/macOS command-line examples (such as curl or HTTPie). The documentation does not mention or show how to perform the same steps on non-Windows platforms, and Windows tools are referenced before any cross-platform alternatives.
Recommendations:
  • Provide equivalent Linux/macOS command-line examples using curl or HTTPie for testing the REST API.
  • When referencing PowerShell, clarify that it is available cross-platform, or provide both Windows (PowerShell) and Linux/macOS (bash/curl) examples side by side.
  • Mention and demonstrate the use of cross-platform tools (e.g., curl, wget, HTTPie) for making HTTP requests.
  • Avoid referencing Microsoft-specific tools exclusively or first; instead, present cross-platform options or alternate between platforms in examples.
  • Add a note that all steps can be performed on Linux/macOS, and specify any platform-specific considerations.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows development, specifically using WPF and Visual Studio. It assumes the use of Windows-only technologies and tools, such as WPF, Visual Studio, and .NET desktop development, without mentioning or providing alternatives for Linux or cross-platform scenarios. There are no instructions or examples for Linux users, nor any mention of equivalent Linux tools or frameworks.
Recommendations:
  • Add a section or note clarifying that WPF is Windows-only, and suggest cross-platform alternatives (e.g., Avalonia, MAUI) for Linux or macOS users.
  • Provide guidance or links for setting up and running the sample on Linux using cross-platform .NET and compatible UI frameworks.
  • Include instructions for using cross-platform IDEs (e.g., VS Code, JetBrains Rider) and command-line tools (e.g., dotnet CLI) instead of only Visual Studio.
  • Explicitly state the platform limitations and, where possible, provide parity examples or references for Linux environments.
  • Consider providing a separate Linux-focused sample or documentation page for desktop authentication with Azure AD B2C.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on ASP.NET Core and C# code, which are most commonly associated with Windows development environments. There are no examples or instructions for Linux or cross-platform development environments, nor are there mentions of Linux-specific tools or deployment patterns. The documentation assumes the use of Visual Studio project structures and .NET conventions, which may not be as familiar or accessible to Linux-first developers.
Recommendations:
  • Add explicit notes or sections on how to perform the same configuration and development steps on Linux, including using .NET Core/ASP.NET Core on Linux.
  • Provide command-line examples (e.g., using dotnet CLI) for project setup, configuration, and running the application, which are platform-agnostic.
  • Mention and link to cross-platform development tools (such as VS Code, JetBrains Rider, or the dotnet CLI) alongside or instead of Windows-centric tools.
  • Clarify that the instructions and code samples are applicable on both Windows and Linux, and highlight any platform-specific considerations.
  • Include troubleshooting tips or environment setup instructions for Linux users, such as installing the .NET SDK on Ubuntu or other distributions.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation exclusively uses PowerShell scripts and tasks for deploying Azure AD B2C custom policies, with no mention or examples of Bash, shell, or cross-platform scripting alternatives. All automation and pipeline steps assume the use of PowerShell, which is traditionally associated with Windows environments, and there is no guidance for users on Linux or macOS. The instructions and examples are Windows-centric, potentially excluding or confusing users working in non-Windows environments.
Recommendations:
  • Provide equivalent Bash or shell script examples for deploying policies, suitable for Linux/macOS agents.
  • Explicitly mention that PowerShell Core (pwsh) is cross-platform and provide instructions for using it on Linux/macOS, or clarify if Windows PowerShell is required.
  • Add a section or notes on how to adapt the deployment process for Linux-based Azure Pipeline agents, including any prerequisites or differences.
  • Where possible, use platform-agnostic tools (e.g., Azure CLI, REST API calls via curl) in examples, or at least mention them as alternatives.
  • Ensure that all steps, including script creation and pipeline task configuration, include Linux/macOS-compatible instructions and screenshots where relevant.

Page-Level Analysis

Windows First
Summary:
The documentation demonstrates a mild Windows bias in the section on generating a development signature hash for the redirect URI. The Windows command is presented first, followed by the iOS (Unix-like) equivalent. There are no explicit Linux examples, but the iOS command uses Unix-style paths and syntax, which is applicable to Linux/macOS. No PowerShell-specific commands, Windows-only tools, or missing Linux examples are found elsewhere in the document.
Recommendations:
  • Explicitly mention Linux alongside iOS when providing Unix-like command examples, or provide a separate 'For Linux/macOS' heading.
  • Present Windows and Linux/macOS commands together, or alternate which platform is shown first to avoid the appearance of prioritizing Windows.
  • Where possible, clarify that the Unix-style command works for both Linux and macOS, not just iOS.
  • Consider adding a short note or table summarizing the equivalent commands for Windows, Linux, and macOS to improve clarity and parity.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a Windows bias by exclusively referencing Windows tools (e.g., Server Manager, AD FS Management), using only GUI-based instructions specific to Windows Server, and omitting any Linux or cross-platform alternatives for AD FS setup or management. There are no PowerShell or command-line examples, but all setup steps assume a Windows Server environment and do not mention or provide guidance for Linux-based AD FS alternatives or management approaches.
Recommendations:
  • Provide equivalent command-line (PowerShell and, where possible, cross-platform CLI) instructions for AD FS configuration, so that users can automate or script the process.
  • Acknowledge that AD FS is a Windows Server technology, but mention and link to any open source or cross-platform alternatives for federated identity (e.g., Keycloak, IdentityServer) and how they could be integrated with Azure AD B2C.
  • If possible, include a note or section for Linux users, clarifying that AD FS is not available on Linux, and suggest supported alternatives for similar scenarios.
  • Where GUI steps are described, offer PowerShell or REST API equivalents to improve automation and accessibility for non-Windows environments.
  • Reorder or supplement instructions to clarify platform dependencies early in the prerequisites section.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a bias toward Windows environments by providing only PowerShell examples for scripting and automation, referencing the Microsoft Graph PowerShell module exclusively, and omitting equivalent Linux or cross-platform command-line instructions. There are no CLI, Bash, or REST API examples tailored for Linux users, and no mention of how to perform these tasks outside of the Azure portal or PowerShell context.
Recommendations:
  • Provide equivalent examples using Azure CLI and Bash scripts for Linux/macOS users, especially for tasks currently demonstrated with PowerShell.
  • Include REST API examples with curl commands to show how to interact with Microsoft Graph from any platform.
  • Mention cross-platform tools (such as Azure CLI or Microsoft Graph CLI) alongside PowerShell, and clarify that PowerShell Core is available cross-platform if relevant.
  • Reorder sections or add notes to ensure Linux/macOS options are presented equally and not as an afterthought.
  • Explicitly state when a step or tool is Windows-specific, and offer alternatives for other operating systems.

Page-Level Analysis

Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation demonstrates a strong Windows bias by exclusively referencing Windows tools (Server Manager, AD FS Management snap-in, Event Viewer), providing only PowerShell command examples for configuration, and omitting any mention of Linux or cross-platform alternatives for AD FS management or troubleshooting. All step-by-step instructions assume a Windows environment, with no guidance for Linux administrators.
Recommendations:
  • Provide equivalent instructions or notes for environments where AD FS is accessed remotely or managed via non-Windows systems (e.g., via REST APIs, if available, or using cross-platform tools).
  • Include references to any available cross-platform AD FS management tools or clarify that AD FS is a Windows-only technology, but highlight how Linux administrators can interact with it (e.g., via browser-based management, remote PowerShell from Linux, or REST endpoints).
  • Where PowerShell is used, mention if and how PowerShell Core (pwsh) on Linux/macOS can be used, or provide alternative command-line examples if possible.
  • For certificate creation and management, include Linux-based commands (e.g., using OpenSSL) alongside Windows-centric instructions.
  • Explicitly state the Windows-only nature of certain steps, and provide guidance for mixed-environment teams (e.g., how a Linux admin can coordinate with a Windows admin for AD FS configuration).

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation page demonstrates a mild Windows bias by presenting command-line instructions and examples in a way that implicitly assumes a Windows environment. Specifically, the use of 'powershell' syntax in the 'Run your SPA application' step, and the lack of explicit Linux/macOS terminal instructions or parity, may disadvantage non-Windows users. There are no references to Windows-specific tools, but the command shell instructions and examples are not cross-platform neutral.
Recommendations:
  • Provide explicit Linux/macOS equivalents for all command-line instructions, especially for running Node.js applications (e.g., 'node index.js' instead of 'npm ./index.js').
  • Use cross-platform neutral terminology such as 'terminal' or 'command line' instead of 'command shell', and avoid referencing 'powershell' unless necessary.
  • Where code blocks are labeled as 'powershell', ensure that equivalent 'bash' or 'sh' code blocks are also provided, or use unlabeled code blocks for commands that are identical across platforms.
  • Add a note or section clarifying that the instructions apply to Windows, Linux, and macOS, and highlight any platform-specific differences.
  • Consider including a table or sidebar with common command-line differences for Windows vs. Linux/macOS for Node.js app development.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias by referencing Visual Studio Code and its Azure Functions extension as the primary development environment, and by using terminology like 'command prompt' and 'Visual Studio Marketplace'. There are no explicit Linux or cross-platform CLI examples, nor are alternative Linux development tools or workflows mentioned. The instructions for running and deploying the API assume a Windows-centric workflow, with no mention of Linux-specific steps or considerations.
Recommendations:
  • Include explicit instructions for Linux users, such as using the terminal and cross-platform CLI tools (e.g., Azure CLI, Bash).
  • Mention and provide examples for deploying Azure Functions using the Azure CLI or from a Linux environment.
  • Reference cross-platform editors (such as VS Code) in a way that highlights their availability on Linux, and avoid assuming Visual Studio Code is used in a Windows context.
  • Replace or supplement references to 'command prompt' with 'terminal' or 'shell', and clarify that all steps work on both Windows and Linux.
  • Add notes or sections for Linux/macOS users, especially for environment variable management and local development.
  • Ensure screenshots and terminology are not Windows-specific where possible, or provide Linux equivalents.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by referencing IIS (a Windows-only web server) as the example application for testing, and providing a link to IIS setup instructions. There are no equivalent examples or guidance for Linux-based web applications or servers (such as Apache or Nginx). The documentation does not mention or provide steps for Linux environments, nor does it reference Linux tools or patterns, which may limit accessibility for users deploying on non-Windows platforms.
Recommendations:
  • Provide parallel examples for Linux-based web applications (e.g., Apache, Nginx) alongside IIS.
  • Include setup instructions or references for deploying and testing with a Linux web server.
  • Mention Linux as a supported environment where applicable, and clarify any platform-specific steps.
  • Ensure that all prerequisite and configuration steps are platform-agnostic or have clear alternatives for both Windows and Linux users.
  • Reference Linux tools and commands where relevant, not just Windows-specific technologies.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a moderate Windows bias, primarily in the section on creating self-signed certificates, where only a PowerShell-based approach is referenced (via an include), and no Linux/macOS alternatives (such as OpenSSL) are mentioned. The rest of the documentation is largely platform-neutral, focusing on Azure Portal UI and XML configuration, but the lack of cross-platform command-line examples for certificate creation may disadvantage Linux/macOS users.
Recommendations:
  • Add explicit instructions or examples for creating self-signed certificates on Linux/macOS using OpenSSL, alongside the existing PowerShell/Windows approach.
  • Wherever PowerShell or Windows-specific tools are referenced, provide equivalent bash/OpenSSL or cross-platform alternatives.
  • In sections that reference uploading or generating certificates, clarify that certificates can be created on any OS and provide links or steps for common Linux/macOS workflows.
  • Review all included snippets (such as the referenced PowerShell module include) to ensure Linux parity or add a note directing users to alternative methods if only Windows is covered.
  • Consider a short table or callout summarizing certificate creation options for Windows (PowerShell), Linux (OpenSSL), and macOS (OpenSSL/Keychain), with links to official documentation.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a Windows bias, particularly in the 'How-to guide' sections for generating cryptographic keys and certificates. All code examples for key and certificate generation use PowerShell and reference Windows-specific tools (e.g., New-SelfSignedCertificate). There are no equivalent examples or instructions for performing these tasks on Linux or macOS, and Windows tooling is mentioned exclusively and first. This may hinder Linux/macOS users from following the guide without additional research.
Recommendations:
  • Provide equivalent command-line examples for Linux (e.g., using openssl for key and certificate generation).
  • Explicitly mention cross-platform alternatives (e.g., bash scripts, openssl, or other widely available tools) alongside PowerShell/Windows examples.
  • Structure instructions so that Windows and Linux/macOS approaches are presented in parallel, or at least mention non-Windows options before or alongside Windows-specific tools.
  • Link to external resources or official documentation for Linux/macOS users on generating keys and certificates.
  • Clarify in each step if a tool or command is Windows-specific, and suggest alternatives where possible.

Page-Level Analysis

Windows Tools Windows First
Summary:
The documentation is largely platform-neutral, focusing on XML configuration and SAML protocol details. However, in the 'Debug SAML protocol' section, the recommended tools for debugging SAML flows include browser extensions for Chrome and Firefox, but the only OS-specific developer tools mentioned are 'Microsoft Edge or Internet Explorer developer tools', with a link to a Microsoft blog. There is no mention of Linux-native tools or command-line utilities for SAML debugging, and the order of mention puts Microsoft/Windows tools last but still includes them exclusively as the only OS-specific developer tool. No PowerShell or Windows command-line examples are present, but the lack of Linux-specific tool recommendations is a subtle form of Windows bias.
Recommendations:
  • Add recommendations for Linux-native SAML debugging tools, such as 'SAMLtool' (https://www.samltool.com/) or command-line utilities like 'curl' and 'xmlsec1' for inspecting and signing SAML messages.
  • Mention that browser-based tools (Chrome/Firefox extensions) are cross-platform and highlight this fact for Linux and macOS users.
  • If referencing developer tools, include instructions or links for using browser developer tools on Linux and macOS, not just Microsoft Edge/IE.
  • Consider including a note that all XML configuration steps are OS-agnostic and can be performed on any platform.
  • If any scripts or automation are added in the future, provide both Windows (PowerShell) and Linux (bash/shell) examples.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation page demonstrates a Windows bias by providing only a PowerShell script for programmatic access to audit logs, with no equivalent example for Linux or cross-platform environments (such as Bash/cURL or Python). The script assumes use of PowerShell and Windows-centric tooling, and the Azure Cloud Shell reference implicitly favors PowerShell. There is no mention of Linux-native tools or cross-platform scripting approaches, nor are Linux examples provided alongside the Windows/PowerShell example.
Recommendations:
  • Provide a Bash/cURL example for accessing the Microsoft Graph API to retrieve audit logs, suitable for Linux and macOS users.
  • Include a Python script example, which is cross-platform and widely used for automation.
  • Explicitly mention that the API can be accessed from any OS, and link to relevant SDKs or CLI tools (e.g., Microsoft Graph CLI, Azure CLI) that work on Linux.
  • When presenting scripts, offer both Windows (PowerShell) and Linux (Bash/cURL or Python) versions side by side.
  • Avoid language that implies PowerShell is the only or primary way to automate these tasks.

Page-Level Analysis

Powershell Heavy Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates a bias toward Windows by providing only PowerShell scripts for testing the REST API, mentioning Microsoft PowerShell as the example HTTP client, and omitting equivalent Linux/macOS command-line examples (e.g., curl). Additionally, the documentation references Windows-centric tools (PowerShell) without mentioning or prioritizing cross-platform or Linux-native alternatives.
Recommendations:
  • Provide equivalent Linux/macOS examples using common tools such as curl or httpie alongside PowerShell scripts.
  • When referencing PowerShell, clarify that it is available cross-platform, or provide Bash/zsh alternatives.
  • List cross-platform or Linux-native tools (curl, wget, httpie) before or alongside Windows tools in all example sections.
  • Explicitly mention that all steps can be performed on Linux/macOS, and note any OS-specific differences.
  • Consider including screenshots or terminal output from both Windows and Linux environments to reinforce parity.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation is generally platform-neutral, focusing on HTTP requests and OAuth 2.0 protocol details. However, there is a subtle Windows bias in the section suggesting 'Microsoft PowerShell' as an example HTTP client for testing POST requests, without mentioning Linux or cross-platform alternatives. No Linux-specific tools (such as curl or httpie) are referenced, and no Linux command-line examples are provided.
Recommendations:
  • When suggesting tools for testing HTTP requests, mention cross-platform and Linux-native tools such as 'curl' or 'httpie' alongside PowerShell.
  • Provide example commands using 'curl' or 'httpie' for Linux/macOS users in addition to any PowerShell examples.
  • Explicitly state that any HTTP client can be used, and offer at least one example for both Windows and Linux environments.
  • Review other documentation pages for similar subtle tool recommendations and ensure Linux parity throughout.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows, specifically targeting WPF (Windows Presentation Foundation) desktop applications and requiring Visual Studio 2019. There are no examples or guidance for developing or running equivalent applications on Linux or macOS, nor are cross-platform .NET or authentication approaches discussed. All tooling and code samples assume a Windows environment.
Recommendations:
  • Provide equivalent instructions and code samples for cross-platform .NET desktop applications (e.g., using .NET MAUI or Avalonia UI) that can run on Linux and macOS.
  • Include guidance for setting up the development environment and running the sample on Linux (e.g., using VS Code, JetBrains Rider, or the .NET CLI).
  • Mention and demonstrate how to use the Microsoft Authentication Library (MSAL) in a cross-platform context.
  • Clarify which steps are Windows-specific and offer alternatives or notes for non-Windows users.
  • If WPF is required, explicitly state that the sample is Windows-only and link to cross-platform alternatives where possible.

Page-Level Analysis

Windows First
Summary:
The documentation contains a subtle Windows bias by linking to further instructions for securing REST APIs with a URL that explicitly includes a 'tabs=windows' query parameter. This suggests that the default or primary guidance is for Windows environments, with no mention or example for Linux or cross-platform scenarios. No PowerShell-specific commands or Windows-only tools are present, but the reference to Windows-first documentation may disadvantage Linux users.
Recommendations:
  • Provide explicit Linux (and macOS) instructions or links alongside Windows instructions for securing REST APIs and obtaining tokens.
  • Use neutral or cross-platform documentation links (e.g., avoid hardcoding 'tabs=windows' in URLs) or clearly indicate how to switch to Linux/macOS tabs.
  • Wherever platform-specific steps are referenced, include a note or table summarizing differences and parity between Windows and Linux environments.
  • Audit linked documentation to ensure Linux users are not left without equivalent guidance.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates a Windows-first bias by focusing exclusively on ASP.NET (a Microsoft technology) and development environments like Visual Studio and Visual Studio Code, but does not provide explicit instructions or examples for Linux users. There are no references to Linux-specific tools, shell commands, or deployment considerations, and the prerequisites and steps assume a Windows-centric workflow.
Recommendations:
  • Include explicit instructions for running the sample on Linux, such as using the .NET CLI (dotnet run) in a terminal.
  • Provide Linux-specific prerequisites, such as installation steps for .NET SDK on Ubuntu or other distributions.
  • Mention and show examples of using editors and tools common on Linux (e.g., JetBrains Rider, Vim, or Emacs) in addition to Visual Studio and VS Code.
  • Clarify that Visual Studio Code and the .NET SDK are cross-platform, and provide any necessary Linux-specific configuration notes (e.g., HTTPS development certificates).
  • Add troubleshooting tips for common Linux issues, such as file permissions or path length differences.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates mild Windows bias. While it provides separate command examples for Linux, macOS, and Windows when running the sample app, there are subtle indications of Windows-first thinking. Notably, the instruction to 'Extract the sample file to a folder where the total length of the path is 260 or fewer characters' references the Windows MAX_PATH limitation, which is not relevant to Linux/macOS. Additionally, the Windows example uses 'py' instead of 'python', which is a Windows-specific launcher. However, the documentation does provide parity in command examples for all platforms and does not omit Linux/macOS instructions.
Recommendations:
  • Clarify that the 260-character path length limitation applies only to Windows, and that Linux/macOS users are not affected.
  • Consider listing Linux/macOS examples before Windows, or in parallel, to avoid a Windows-first impression.
  • Where possible, use cross-platform commands (e.g., 'python' instead of 'py') in generic instructions, and explain platform-specific differences in a note.
  • Review the documentation for any other implicit Windows assumptions (such as file path separators, environment variable syntax, etc.) and clarify or provide Linux/macOS equivalents as needed.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation demonstrates a mild Windows bias by providing command-line instructions and examples that implicitly or explicitly target Windows users. The only explicit shell example for running the application is labeled as 'powershell', and there is no mention of Linux or macOS-specific shell commands, nor any guidance for non-Windows environments. There are no references to Windows-only tools, but the use of 'powershell' and lack of Linux parity in command-line instructions may confuse or exclude Linux/macOS users.
Recommendations:
  • Provide both Windows (PowerShell/cmd) and Linux/macOS (bash/sh) command examples for all shell instructions, especially for installing dependencies and running the app.
  • Use neutral shell syntax (e.g., $ npm install, $ node index.js) or provide tabs for different OSes.
  • Avoid labeling generic npm or node commands as 'powershell' unless there are actual PowerShell-specific commands.
  • Explicitly state that the instructions work on Windows, Linux, and macOS, and mention any OS-specific considerations if applicable.
  • Add a note or section for Linux/macOS users, clarifying any differences (such as using 'node index.js' instead of 'npm ./index.js', which is not standard npm usage).

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation demonstrates a strong Windows bias by exclusively providing PowerShell scripts and instructions, with no mention of Bash, shell scripts, or cross-platform alternatives. All automation and deployment steps are described using PowerShell, which is traditionally associated with Windows environments, and there are no Linux-specific or cross-platform examples. The use of PowerShell as the only scripting language and the absence of any reference to Linux-native tools or commands may hinder users working in Linux-based CI/CD environments.
Recommendations:
  • Provide equivalent Bash or shell script examples for deploying policies, ensuring Linux users can follow along without needing PowerShell.
  • Explicitly mention that PowerShell Core is cross-platform and provide guidance for installing and running scripts on Linux/macOS, if PowerShell must be used.
  • Include notes or sections on how to adapt the deployment process for Linux agents in Azure Pipelines, such as using Bash tasks or alternative scripting languages.
  • List both Windows and Linux prerequisites, including any required tools or dependencies for each platform.
  • Where possible, use platform-agnostic language and tools, or clearly indicate when a step is specific to Windows or PowerShell.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on ASP.NET Core and C# development patterns, which are traditionally associated with Windows environments. There are no explicit instructions, examples, or notes for Linux or cross-platform development, and all file references and code samples (e.g., Startup.cs, appsettings.json) assume a .NET/Windows-centric workflow. There is no mention of Linux-specific tools, deployment, or configuration steps.
Recommendations:
  • Add explicit notes or sections clarifying that ASP.NET Core is cross-platform and can be developed and deployed on Linux and macOS, not just Windows.
  • Include Linux/macOS equivalents for file paths, command-line instructions, and environment setup (e.g., using bash instead of PowerShell, using environment variables in Linux).
  • Provide examples or links for deploying and running ASP.NET Core applications on Linux (e.g., using systemd, Nginx/Apache reverse proxy).
  • Mention cross-platform development tools (e.g., Visual Studio Code, JetBrains Rider) in addition to Visual Studio.
  • If referencing Windows-specific tools or patterns, ensure Linux alternatives are mentioned with equal prominence.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a Windows bias by providing only PowerShell examples for cryptographic key and certificate generation, referencing Windows-specific tools (e.g., New-SelfSignedCertificate), and omitting equivalent Linux/macOS commands or guidance. All code snippets for key/certificate generation assume a Windows environment, and there is no mention of cross-platform alternatives or ordering that gives Linux parity.
Recommendations:
  • For every PowerShell example (e.g., generating a symmetric key or self-signed certificate), provide equivalent commands for Linux/macOS, such as using OpenSSL or relevant shell commands.
  • Explicitly mention that the steps can be performed on non-Windows platforms, and provide links or references to cross-platform tooling.
  • When introducing tooling or code snippets, present both Windows and Linux/macOS options together, or alternate the order to avoid always listing Windows first.
  • Add a section or note on cross-platform considerations, including any differences in file paths, certificate stores, or command-line utilities.
  • Where possible, use language-neutral or platform-neutral pseudocode for generic steps, and only provide platform-specific details as needed.

Page-Level Analysis

Windows First
Summary:
The documentation demonstrates a mild 'windows_first' bias in the section on generating a development signature hash for the redirect URI. The Windows command is presented first, followed by the iOS (Unix-like) equivalent, but there is no explicit mention of Linux or macOS. The rest of the documentation is platform-agnostic, focusing on Android Studio and Java/Kotlin code, with no other Windows-specific tools or patterns.
Recommendations:
  • Explicitly mention Linux/macOS alongside iOS in the signature hash generation step, as the command is the same for all Unix-like systems.
  • Label the command as 'For Linux/macOS' instead of 'For iOS', or use 'For Linux/macOS/iOS' to be inclusive.
  • Consider presenting both Windows and Linux/macOS commands together, or in parallel tabs, to avoid implying Windows is the primary or default environment.
  • Review other documentation pages for similar patterns and ensure parity in platform instructions.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing Windows-specific tools (such as Server Manager and AD FS Management MMC), and does not provide any Linux-based alternatives or command-line instructions for managing AD FS. All configuration steps for AD FS are described using GUI tools available only on Windows Server, with no mention of PowerShell, CLI, or cross-platform approaches. There are no Linux or non-Windows examples for AD FS setup, and the documentation implicitly assumes the administrator is operating in a Windows environment.
Recommendations:
  • Provide PowerShell command-line equivalents for all AD FS configuration steps, as PowerShell can be run on Windows Server Core and remotely.
  • Explicitly mention that AD FS is a Windows Server feature, but clarify what steps (if any) can be performed from non-Windows environments (e.g., via remote PowerShell, REST APIs, or Azure CLI).
  • If possible, reference or link to any open-source or third-party tools that allow AD FS management from Linux or macOS, or clarify that such options are not available.
  • Add a note early in the prerequisites section stating that AD FS management is only supported on Windows Server, and suggest alternatives for Linux-based identity providers if relevant.
  • Where possible, provide parity by showing how to configure a generic OpenID Connect provider using Linux-based identity solutions (such as Keycloak or IdentityServer) as a comparative example.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation focuses exclusively on ASP.NET Core development, which is cross-platform, but the examples and instructions implicitly assume a Windows development environment. There are no explicit Linux or macOS instructions, and the tooling references (such as Visual Studio and Visual Studio Code) are presented in a way that prioritizes Windows workflows. Package installation commands for Visual Studio Code use Install-Package, which is a PowerShell/NuGet Package Manager Console command, not a cross-platform dotnet CLI command. There are no mentions of Linux-specific considerations, file paths, or development environments.
Recommendations:
  • Provide explicit instructions and examples for Linux and macOS environments, including terminal commands and any OS-specific prerequisites.
  • Use cross-platform commands (such as 'dotnet add package') consistently in all tooling sections, especially for Visual Studio Code, which is widely used on Linux/macOS.
  • Mention and show file paths in both Windows (\) and Unix (/) formats where relevant.
  • Include a note or section on running and debugging the application on Linux/macOS, including any differences in launching the development server or accessing localhost.
  • Clarify that ASP.NET Core and the Microsoft Identity Web libraries are fully supported on Linux and macOS, and provide links to relevant cross-platform documentation.

Page-Level Analysis

Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation page primarily focuses on using the Azure portal, which is cross-platform, but in the section on revoking a user's session, it exclusively provides instructions and examples for Microsoft Graph PowerShell, specifically referencing 'Windows PowerShell' and omitting any Linux or cross-platform alternatives. There are no CLI, Bash, or platform-neutral examples for this task, and the language implies a Windows-first approach.
Recommendations:
  • Provide equivalent instructions and examples for revoking user sessions using the Microsoft Graph CLI, Azure CLI, or Bash scripts, which are cross-platform and work on Linux and macOS.
  • Replace references to 'Windows PowerShell' with 'PowerShell', and clarify that PowerShell Core is available on Linux and macOS, or provide explicit instructions for those platforms.
  • Wherever PowerShell is mentioned, add a note or section for Linux/macOS users, including any prerequisites or differences in command usage.
  • Consider including REST API examples (e.g., using curl) for tasks currently only shown with PowerShell, to ensure platform neutrality.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation is focused exclusively on ASP.NET Core web apps, which are cross-platform, but the only development environments mentioned are Visual Studio and Visual Studio Code. The package installation instructions are split between 'Visual Studio' (using dotnet CLI) and 'Visual Studio Code' (using Install-Package), but both are available cross-platform. However, there are no explicit instructions or examples for Linux or macOS users, such as using terminal/bash, nor is there any mention of Linux-specific tooling or considerations. The documentation implicitly assumes a Windows-centric development environment by referencing Visual Studio and Windows-style file paths (e.g., Views\Shared\_Layout.cshtml).
Recommendations:
  • Add explicit instructions or notes for Linux and macOS users, including any differences in file paths, commands, or environment setup.
  • Include examples using bash or terminal commands for package installation and project creation, not just Visual Studio/Visual Studio Code.
  • Mention cross-platform compatibility of ASP.NET Core and clarify that all steps can be performed on Linux/macOS as well as Windows.
  • Use platform-neutral file path notation (e.g., Views/Shared/_Layout.cshtml) throughout the documentation.
  • If referencing IDEs, include cross-platform options such as JetBrains Rider or command-line editors (vim, nano) alongside Visual Studio and Visual Studio Code.

Page-Level Analysis

Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation is heavily oriented towards Windows environments, specifically referencing Windows-only tools (AD FS Management snap-in, Event Viewer, Server Manager) and PowerShell cmdlets for configuration and troubleshooting. There are no Linux or cross-platform alternatives or examples provided for key steps such as certificate creation, AD FS management, or log inspection. All procedural instructions assume a Windows server environment and do not mention or address Linux-based AD FS alternatives or how to interact with AD FS from non-Windows systems.
Recommendations:
  • Provide equivalent command-line or UI instructions for managing AD FS from non-Windows environments, if possible (e.g., via REST APIs, if available).
  • Include examples for certificate creation and management using cross-platform tools such as OpenSSL.
  • Document how to interact with AD FS from Linux or macOS clients, or clarify that AD FS is a Windows-only technology if that is the case.
  • For PowerShell commands, suggest alternatives using cross-platform scripting or remote management tools, or note the requirement for Windows.
  • Where troubleshooting steps reference Windows Event Viewer, suggest how to access logs remotely or via command-line tools that may be available on other platforms.
  • Clearly state any platform limitations early in the documentation, and provide guidance for users on non-Windows platforms.

Page-Level Analysis

Missing Linux Example Windows First
Summary:
The documentation exclusively describes steps using the Azure portal web interface and does not provide any command-line examples. There is no mention of platform-specific tools, but where command-line or automation might be relevant (e.g., scripting registration or configuration), no examples are given for either Windows (PowerShell) or Linux (CLI). However, the overall workflow and terminology (e.g., 'click', 'select', 'portal') are more familiar to users of Windows environments and Azure's web UI, which is often associated with Windows-centric workflows. There is no mention of Azure CLI or cross-platform automation, and no Linux-specific guidance or parity.
Recommendations:
  • Provide Azure CLI examples for all steps that can be automated, including application registration, client secret creation, and identity provider configuration.
  • Explicitly mention that the Azure portal is web-based and accessible from any OS, to avoid the impression of Windows exclusivity.
  • Where possible, include both GUI and CLI instructions side-by-side, so Linux and automation-focused users are equally supported.
  • Reference documentation for scripting or automating these tasks on Linux/macOS as well as Windows.
  • If PowerShell or Windows tools are ever referenced, ensure equivalent Bash/Azure CLI examples are provided.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by exclusively referencing Windows-centric tools and workflows (e.g., Visual Studio, .sln files, Web.config), omitting any mention of Linux-compatible editors, build tools, or configuration patterns. There are no Linux-specific instructions or examples, and the guidance assumes a Windows development environment.
Recommendations:
  • Include instructions for opening and editing the project using cross-platform editors such as VS Code or JetBrains Rider, and mention how to build and run the project using .NET CLI commands (dotnet build/run) instead of only referencing Visual Studio.
  • Provide examples for editing configuration files on Linux (e.g., using nano, vim, or gedit) and clarify file path differences (forward slashes vs. backslashes).
  • Mention how to run and debug the sample application on Linux and macOS, including any prerequisites (e.g., installing the .NET SDK on Linux).
  • If the sample is Windows-specific (e.g., uses Windows-only libraries), clearly state this and, if possible, provide or reference a cross-platform alternative.
  • Ensure that all code snippets and instructions are platform-agnostic where possible, or provide parallel instructions for both Windows and Linux environments.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation page does not exhibit explicit Windows bias in terms of mentioning Windows tools, PowerShell, or Windows-first patterns. However, it exclusively describes GUI-based steps using the Azure portal and does not provide any command-line examples (such as Azure CLI, Bash, or PowerShell) for registering applications or granting permissions. This omission results in a lack of parity for Linux or cross-platform users who may prefer or require CLI-based automation.
Recommendations:
  • Add Azure CLI examples for all major steps (registering the application, granting permissions, assigning roles, creating client secrets) alongside the portal instructions.
  • Explicitly mention that all operations can be performed via CLI and provide links to relevant Azure CLI documentation.
  • If PowerShell examples are added, ensure equivalent Azure CLI (Bash-friendly) examples are also present and given equal prominence.
  • Consider including a table or section comparing portal, Azure CLI, and PowerShell approaches for each task to support all user environments.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation demonstrates a Windows bias by providing only PowerShell scripts for critical steps (such as creating self-signed certificates and random keys), referencing Visual Studio for deployment, and omitting equivalent Linux/macOS commands or tooling. There are no Bash, OpenSSL, or cross-platform alternatives, which may hinder users on non-Windows systems.
Recommendations:
  • Provide equivalent Bash/OpenSSL commands for creating self-signed certificates and random strings, suitable for Linux/macOS users.
  • Include deployment instructions using cross-platform tools such as Azure CLI, GitHub Actions, or VS Code, not just Visual Studio.
  • Explicitly mention that PowerShell examples are for Windows and offer alternatives for other platforms.
  • Reorder or parallelize instructions so that Windows and Linux/macOS approaches are presented equally, rather than Windows-first.
  • Add notes or links to official Microsoft documentation for cross-platform certificate and key management.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a Windows bias by specifically mentioning Windows Hello as the primary example of biometric authentication, both in the introduction and in the scenario walkthrough. Windows Hello is referenced before any mention of Android or other platforms, and no Linux or cross-platform biometric solutions are discussed. There are no Linux-specific examples or references to Linux-compatible biometric tools.
Recommendations:
  • Include explicit references to biometric authentication options available on Linux (e.g., fprintd, libfprint, or desktop environment integrations) alongside Windows Hello and Android.
  • Provide example scenarios or walkthroughs for enrolling and using biometrics on Linux devices, not just Windows and Android.
  • Use neutral, platform-agnostic language when describing biometric authentication, mentioning Windows Hello, Android biometrics, and Linux solutions together.
  • If possible, add troubleshooting or support notes for Linux users to ensure parity with Windows and Android guidance.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page is largely platform-neutral in its technical content, focusing on XML configuration and SAML protocol details. However, in the 'Debug SAML protocol' section, it lists Windows-specific tools (Microsoft Edge or Internet Explorer developer tools) alongside browser extensions, and provides a link to a Microsoft blog post about using Edge/IE developer tools. There are no explicit Linux or cross-platform debugging tool examples given, nor is there mention of command-line tools or approaches common on Linux (such as curl, openssl, or SAML-specific CLI utilities). The order of tool presentation also puts Microsoft/Windows tools last, but their inclusion without Linux equivalents suggests a mild Windows bias.
Recommendations:
  • Add examples or references to Linux-compatible SAML debugging tools, such as using curl, openssl, or SAML-specific CLI tools (e.g., saml2aws, xmlsec1) for inspecting SAML messages.
  • Mention browser extensions as cross-platform tools more prominently, emphasizing their availability on Linux, macOS, and Windows.
  • If referencing developer tools for browsers, clarify that Chrome and Firefox DevTools are available on Linux and macOS as well.
  • Consider adding a section or note on how to capture and inspect SAML traffic using command-line tools or network analyzers (e.g., tcpdump, Wireshark) on Linux.
  • Avoid linking exclusively to Microsoft/Windows-specific resources for debugging; provide equivalent Linux/macOS guidance or links where possible.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation page demonstrates a Windows bias by exclusively referencing Visual Studio (a primarily Windows IDE) and providing instructions that assume the use of Windows-specific tools and workflows (such as Solution Explorer, right-click context menus, and F5 debugging). There are no examples or guidance for running or developing the sample application on Linux or using cross-platform tools like VS Code or the .NET CLI.
Recommendations:
  • Add instructions for running the sample using the .NET CLI (dotnet build/run) to support Linux and macOS users.
  • Include examples for setting up and debugging the application in Visual Studio Code, which is cross-platform.
  • Mention alternative editors and workflows for non-Windows environments, such as JetBrains Rider or command-line tools.
  • Clarify which steps are specific to Visual Studio on Windows and provide equivalent steps for Linux/macOS where possible.
  • Explicitly state the platform requirements and provide links to cross-platform .NET documentation.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias by referencing Visual Studio Code and its Azure Functions extension as the primary development environment, and by mentioning the use of the Azure portal, terminal, or command prompt without explicitly referencing Linux or cross-platform alternatives. There are no explicit Linux-specific instructions, examples, or screenshots, and no mention of Linux-native tools or shell environments. All environment variable and deployment steps are described generically or with a Windows-centric perspective, omitting Linux-specific guidance.
Recommendations:
  • Explicitly mention that Visual Studio Code and Azure Functions Core Tools are cross-platform and provide installation links for Linux and macOS.
  • Include Linux-specific instructions or examples for running and deploying Azure Functions, such as using bash/zsh shells and common Linux package managers.
  • Show how to set environment variables in Linux (e.g., export commands or .env files) in addition to the local.settings.json approach.
  • Add screenshots or terminal snippets from Linux environments to demonstrate parity.
  • Clarify that the Azure portal and related tools are accessible from any OS, and provide links to CLI-based alternatives (e.g., Azure CLI) with Linux usage examples.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by referencing IIS as the example application for testing, providing a link to IIS setup instructions, and omitting any mention of Linux-based web servers (such as Apache or Nginx) as alternatives. No Linux-specific tools, commands, or deployment patterns are discussed, and all example application guidance assumes a Windows environment. There are no PowerShell commands, but the only concrete application example is Windows-centric.
Recommendations:
  • Include Linux-based web application examples (e.g., Apache, Nginx, or Tomcat) alongside or in place of IIS.
  • Provide links to documentation for setting up test applications on Linux, such as guides for deploying Apache or Nginx.
  • Mention that the solution is platform-agnostic and can be used with both Windows and Linux back-end applications.
  • Where application setup is referenced, offer both Windows and Linux instructions or note any differences.
  • Explicitly state that the configuration steps for F5 BIG-IP and Azure AD B2C are not limited to Windows environments.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a Windows bias by exclusively referencing Visual Studio (a Windows-centric tool) for publishing the API, without mentioning cross-platform alternatives or providing Linux/macOS instructions. There are no command-line or non-Windows deployment examples, and the workflow assumes the user is operating in a Windows environment.
Recommendations:
  • Provide alternative instructions for deploying the API using cross-platform tools such as the .NET CLI (dotnet publish) and Azure CLI, which work on Linux and macOS.
  • Include examples or references for uploading certificates and configuring App Service settings using Azure CLI, PowerShell, and the Azure Portal, making clear which methods are cross-platform.
  • Explicitly state that Visual Studio is optional and provide equivalent steps for Linux/macOS users.
  • Review all steps for hidden Windows dependencies and ensure parity in documentation for Linux and macOS environments.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates a Windows bias by exclusively providing PowerShell-based instructions for enabling Saviynt to delete users in Azure AD B2C. It explicitly instructs users to install the Microsoft Graph PowerShell module on a Windows workstation or server, with no mention of Linux or cross-platform alternatives. There are no CLI, Bash, or cross-platform examples, and the use of Windows tools and terminology is prioritized.
Recommendations:
  • Provide equivalent instructions using Microsoft Graph CLI (az cli or msgraph-cli), which are cross-platform and work on Linux, macOS, and Windows.
  • Include Bash or shell script examples for Linux users, especially for authentication and role assignment steps.
  • Clarify that the Microsoft Graph PowerShell module is available on non-Windows platforms via PowerShell Core, and provide installation instructions for Linux/macOS.
  • Avoid language that implies Windows is required (e.g., 'on a Windows workstation or server'); instead, use 'on your workstation' and specify cross-platform compatibility.
  • Add a section or note explicitly addressing Linux/macOS users, ensuring parity in setup and troubleshooting guidance.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a mild Windows bias by referencing Visual Studio as the publishing tool for the API and suggesting Azure Storage Explorer for managing Azure storage, both of which are traditionally Windows-centric tools. No Linux-specific tools or cross-platform alternatives are mentioned, and there are no command-line examples (e.g., Azure CLI, PowerShell, Bash) for Linux users. The documentation does not provide explicit instructions or examples for Linux environments.
Recommendations:
  • Include instructions for deploying the API using cross-platform tools such as the Azure CLI, .NET CLI, or GitHub Actions, in addition to Visual Studio.
  • Mention and provide examples for using Azure Storage Explorer on Linux, or suggest alternative methods such as the Azure CLI or azcopy for uploading files to blob storage.
  • Add command-line examples for common tasks (e.g., uploading files, configuring CORS) using tools available on Linux.
  • Explicitly state that the steps can be performed on Linux, macOS, or Windows, and highlight any platform-specific considerations.
  • Where GUI tools are referenced, provide equivalent command-line or cross-platform alternatives.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page shows mild Windows bias by referencing 'windows' explicitly in the SAML application registration link (saml-service-provider.md?tabs=windows), suggesting that Windows is the default or primary environment. There are no explicit Linux or cross-platform examples or tabs mentioned, and no Linux-specific tools or instructions are provided.
Recommendations:
  • Wherever platform-specific instructions or tabs are provided (such as for SAML apps), ensure that Linux (and macOS, if relevant) tabs/examples are available and mentioned equally.
  • Avoid using Windows as the default or only tab in links; instead, provide a neutral or cross-platform default, or mention all supported platforms.
  • Explicitly state when instructions are cross-platform, or provide clear guidance for both Windows and Linux users.
  • Review linked tutorials to ensure parity in examples, screenshots, and command-line instructions for both Windows and Linux environments.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows bias primarily in the certificate creation section, where it explicitly recommends using Azure Key Vault or a PowerShell module for creating self-signed certificates. There are no Linux or cross-platform command-line examples (such as OpenSSL) for certificate generation. The only scripting tool mentioned for local certificate creation is PowerShell, which is Windows-centric. No Linux or macOS equivalents are referenced, and no cross-platform CLI instructions are provided for key tasks like certificate generation.
Recommendations:
  • Add Linux/macOS-friendly instructions for generating self-signed certificates, such as using OpenSSL, alongside or before PowerShell examples.
  • Explicitly mention that certificate generation can be performed on any OS and provide cross-platform command-line examples.
  • Where PowerShell is referenced, offer equivalent bash or shell commands for Linux/macOS users.
  • Review other sections for any implicit Windows-first assumptions and ensure parity in tool recommendations and example commands.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows, specifically using a WPF (Windows Presentation Foundation) desktop application and Visual Studio. All instructions, screenshots, and tooling references are Windows-centric, with no mention of Linux or cross-platform alternatives. There are no Linux or macOS instructions, nor are there any examples using cross-platform frameworks or tools.
Recommendations:
  • Provide equivalent instructions for running the sample on Linux and macOS, such as using .NET Core/MAUI or other cross-platform UI frameworks.
  • Include examples for building and running the application using command-line tools (dotnet CLI) instead of only Visual Studio.
  • Mention and provide guidance for alternative editors (e.g., VS Code) and package management approaches that work on Linux.
  • Add screenshots and workflow steps for Linux/macOS environments.
  • Clarify in the prerequisites and introduction whether the sample is Windows-only, and if so, provide or link to cross-platform alternatives.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation exclusively describes management tasks using the Azure Portal web interface, with no mention of command-line tools or automation. However, where command-line or scripting might be relevant (e.g., bulk user creation, role assignment, or auditing), there are no examples for PowerShell, CLI, or any platform-specific tools. The only interface described is the Azure Portal, which is cross-platform via browser, but the documentation implicitly assumes a GUI-first, Windows-centric workflow by not mentioning or providing parity for Linux or cross-platform automation tools (such as Azure CLI or REST API). There are no explicit Windows-only tools, but the lack of CLI or automation examples can disadvantage Linux users who may prefer or require non-GUI workflows.
Recommendations:
  • Add examples using Azure CLI (az), which is cross-platform and works on Linux, macOS, and Windows.
  • Where appropriate, provide PowerShell examples alongside Azure CLI, but do not make PowerShell the only automation example.
  • Include REST API references or examples for tasks that can be automated, to support users on any platform.
  • Explicitly mention that all tasks can be performed via browser on any OS, but also provide links or examples for automation and scripting.
  • For bulk operations (e.g., user creation), provide sample scripts or commands for both Azure CLI and PowerShell.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation provides only a PowerShell script for monitoring directory quota, with no equivalent example or guidance for Linux or cross-platform environments. It assumes the use of Windows tools and patterns (PowerShell, Invoke-RestMethod), and does not mention or prioritize Linux-compatible alternatives such as Bash, curl, or Python. This creates a Windows-first experience and excludes users on Linux or macOS.
Recommendations:
  • Provide a Bash or shell script example using curl or httpie to demonstrate how to perform the same API calls on Linux/macOS.
  • Include a cross-platform example using a language like Python, which is available on both Windows and Linux.
  • Explicitly mention that the PowerShell script is for Windows, and direct Linux/macOS users to equivalent instructions.
  • Consider reordering the examples or providing both Windows and Linux/macOS options side-by-side to ensure parity.
  • Reference platform-agnostic tools (e.g., Azure CLI, Microsoft Graph CLI) if available, or provide links to relevant documentation for non-Windows users.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation provides only a PowerShell script example for programmatically accessing audit logs, with no equivalent example for Linux users (e.g., Bash/cURL). The script assumes use of PowerShell, which is traditionally a Windows tool, and there is no mention of Linux-native tools or cross-platform alternatives. This may disadvantage users on Linux or macOS platforms.
Recommendations:
  • Add a Bash/cURL example for querying the Microsoft Graph API to retrieve audit logs, demonstrating how to authenticate and paginate results.
  • Explicitly mention that PowerShell Core is cross-platform and can be used on Linux/macOS, or provide installation instructions for non-Windows users.
  • Where possible, provide both Windows (PowerShell) and Linux (Bash/cURL or Python) script examples side by side.
  • Reference Linux-native tools (e.g., jq for JSON processing) in the context of handling API responses.
  • Clarify in the documentation that the API can be accessed from any platform, not just Windows, and provide guidance for Linux users.

Page-Level Analysis

Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation provides code and tooling examples exclusively for Windows environments, specifically using PowerShell for key and certificate generation. There are no equivalent instructions or examples for Linux or cross-platform environments, and Windows tools are mentioned first and exclusively.
Recommendations:
  • Provide equivalent Linux and cross-platform examples for generating symmetric keys (e.g., using OpenSSL, /dev/urandom, or Python scripts).
  • Include instructions for generating self-signed certificates on Linux/macOS (e.g., using OpenSSL) alongside the PowerShell example.
  • Explicitly mention that the provided PowerShell commands are for Windows, and offer alternatives for other operating systems.
  • Reference cross-platform tools (such as OpenSSL) before or alongside Windows-specific tools to avoid the impression of Windows being the default or only supported environment.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation mentions Microsoft PowerShell as an example HTTP client for testing the POST request, but does not mention any Linux or cross-platform alternatives such as curl or HTTPie. No command-line examples are provided for Linux or macOS users, and the only tool explicitly referenced is Windows-centric.
Recommendations:
  • Provide equivalent command-line examples using curl or HTTPie, which are available on Linux, macOS, and Windows.
  • Mention cross-platform tools (e.g., curl, Postman) alongside PowerShell when suggesting ways to test HTTP requests.
  • If including PowerShell examples, also include Bash/curl examples to ensure parity for Linux/macOS users.
  • Consider rephrasing to say 'any HTTP client such as curl, HTTPie, Postman, or PowerShell' to avoid implying a Windows-only approach.

Page-Level Analysis

Windows Tools Missing Linux Example
Summary:
The documentation is largely platform-neutral, focusing on HTTP requests and protocol details. However, in the section on testing POST HTTP requests, only Microsoft PowerShell is mentioned as an example HTTP client, with no mention of Linux or cross-platform alternatives such as curl or HTTPie. No Linux-specific tools or shell examples are provided.
Recommendations:
  • When suggesting tools for testing HTTP requests, mention cross-platform and Linux-native tools such as curl and HTTPie alongside PowerShell.
  • Provide example command lines for both Windows (PowerShell) and Linux/macOS (bash/curl) when demonstrating how to make HTTP requests.
  • Explicitly state that the HTTP requests can be tested using any HTTP client, and provide at least one example for each major platform.
  • Avoid implying that PowerShell is the default or only option for testing HTTP requests.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation contains a subtle Windows bias by linking to instructions for securing REST APIs that default to a 'windows' tab (e.g., 'secure-rest-api.md?tabs=windows'), without mentioning or providing equivalent Linux/macOS guidance. There are no explicit PowerShell or Windows command-line examples, but the referenced documentation may prioritize Windows tooling or workflows. No Linux-specific tools, commands, or parity notes are present.
Recommendations:
  • Wherever documentation links reference platform-specific instructions (such as 'secure-rest-api.md?tabs=windows'), ensure that Linux/macOS tabs are equally visible and referenced. Consider linking to a neutral or multi-platform version of the page.
  • Explicitly mention that the guidance applies to all platforms, and provide Linux/macOS equivalents or note when steps are platform-agnostic.
  • If any referenced workflows (such as API protection or token acquisition) have platform-specific steps, include both Windows and Linux/macOS examples inline or as expandable sections.
  • Review all linked documentation to ensure Linux users are not disadvantaged or forced to adapt Windows-centric instructions.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First
Summary:
The documentation demonstrates a moderate Windows bias. It references Microsoft PowerShell as the primary method for generating GUIDs and provides a PowerShell script as the first scripting example for obtaining an access token. While a cURL example is also provided, the ordering and explicit mention of PowerShell tools and commands suggest a Windows-first approach. There is no explicit Linux shell or cross-platform alternative for GUID generation, and the PowerShell script is presented before the cURL example.
Recommendations:
  • When suggesting GUID generation, provide both PowerShell (Windows) and Linux/macOS (e.g., `uuidgen` or `cat /proc/sys/kernel/random/uuid`) command examples, or mention cross-platform tools first.
  • Present scripting examples in parallel (PowerShell and cURL/bash) or lead with a cross-platform tool like cURL, to avoid the impression of Windows-first bias.
  • Explicitly mention that all steps and scripts are cross-platform where possible, and provide Linux/macOS equivalents for any Windows-specific instructions.
  • Where referencing online tools, clarify that they are platform-agnostic.
  • Consider including bash or Python script examples alongside PowerShell for parity.

Page-Level Analysis

Missing Linux Example Windows First
Summary:
The documentation page does not provide any OS-specific command-line examples, but it references the Azure portal and Azure CLI for configuration. However, there is a subtle Windows-first bias: the documentation does not explicitly mention Linux or provide Linux-specific guidance or examples, and the Azure CLI (which is cross-platform) is only mentioned in passing, with no concrete CLI commands or shell examples. The instructions and screenshots are oriented toward the Azure portal, which is platform-agnostic, but there is no effort to ensure Linux parity or to highlight cross-platform workflows.
Recommendations:
  • Add explicit Azure CLI command examples for all configuration steps, including app registration and setting application secrets, and show these commands in both Windows (cmd/PowerShell) and Linux (bash) syntax where relevant.
  • Include a note or section confirming that all steps can be performed from Linux, macOS, or Windows, and provide links to cross-platform CLI documentation.
  • If screenshots are provided, clarify that the Azure portal is accessible from any OS.
  • Where file paths or environment variables are referenced, show both Windows and Linux conventions.
  • Consider adding a troubleshooting section for common Linux-specific issues (e.g., file permissions, line endings, CLI installation).

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a mild Windows bias. While it provides Linux, macOS, and Windows command examples for running the sample app, there are subtle indications of Windows-centric assumptions: the warning about path length ("Extract the sample file to a folder where the total length of the path is 260 or fewer characters") is a Windows-specific limitation, and the Windows example is listed last but uses the Windows-specific 'py' launcher. However, all platforms are represented in the run instructions, and there are no PowerShell-only commands or exclusive references to Windows tools.
Recommendations:
  • Clarify that the 260-character path length limitation applies only to Windows, and that Linux/macOS users are not affected.
  • Consider listing Linux or macOS instructions first, or randomizing the order, to avoid implicit prioritization of Windows.
  • Provide a note explaining the difference between 'python' and 'py' launchers, and suggest using 'python' on all platforms if possible for consistency.
  • Ensure any screenshots or UI references are cross-platform or clarify when they are Windows-specific.
  • Continue to provide explicit, parallel instructions for all major platforms (Linux, macOS, Windows) in future updates.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates a bias toward Windows development environments by focusing exclusively on Visual Studio and Visual Studio Code as prerequisites and editors, with no mention of Linux-specific tools, distributions, or command-line instructions. All examples and instructions are editor-agnostic but implicitly assume a Windows or cross-platform environment without addressing Linux-specific setup, such as package installation, path length limitations, or running .NET applications on Linux. There are no PowerShell-specific commands, but the lack of explicit Linux parity (e.g., mentioning Linux package managers, terminal commands, or troubleshooting) constitutes a subtle bias.
Recommendations:
  • Explicitly mention that Visual Studio Code and .NET SDK are cross-platform and provide links or instructions for Linux installation (e.g., using apt, yum, or snap).
  • Include a Linux-specific section in the prerequisites, listing supported distributions and any additional dependencies (such as libssl-dev for .NET on Linux).
  • Address path length limitations as they relate to both Windows and Linux, clarifying if the 260-character limit is a Windows-specific constraint.
  • Provide example terminal commands for building and running the .NET projects on Linux (e.g., using dotnet CLI in Bash).
  • Mention any known issues or differences when running the sample on Linux (such as file permissions, HTTPS development certificates, or case sensitivity in file paths).

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows-first bias by referencing Visual Studio (a Windows-centric IDE) before Visual Studio Code, and by using a sample path and port (https://localhost:44316) that are typical defaults for Visual Studio on Windows. There are no explicit instructions or examples for running the sample on Linux (e.g., using the dotnet CLI, configuring HTTPS certificates, or handling path length limitations on Linux filesystems). No Linux-specific tools, commands, or troubleshooting tips are provided.
Recommendations:
  • Provide explicit instructions for running the sample on Linux, including using the dotnet CLI (e.g., 'dotnet run') and handling HTTPS development certificates.
  • Mention any Linux-specific prerequisites, such as installing .NET SDK on Ubuntu or other distributions.
  • Clarify that Visual Studio Code is cross-platform and provide example commands for both Windows and Linux environments.
  • Address path length limitations as they relate to both Windows and Linux, or clarify if this is only a Windows concern.
  • Include troubleshooting tips for common Linux issues, such as permissions or certificate trust.
  • When listing prerequisites, present cross-platform tools (like Visual Studio Code and dotnet CLI) before or alongside Windows-specific tools.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows development, specifically targeting WPF (Windows Presentation Foundation) desktop applications and requiring Visual Studio 2019. There are no examples or guidance for Linux or cross-platform desktop development, nor are alternative tools or frameworks mentioned. All code and instructions assume a Windows environment, and there is no mention of Linux equivalents or how to adapt the process for non-Windows platforms.
Recommendations:
  • Provide parallel instructions and examples for cross-platform desktop frameworks such as .NET MAUI, Avalonia, or Electron, which can run on Linux.
  • Include guidance for setting up the development environment on Linux (e.g., using VS Code, JetBrains Rider, or the .NET CLI).
  • Offer Linux-specific steps for cloning the repository, building, and running the sample application using the .NET CLI.
  • Mention any platform-specific limitations or considerations for Azure AD B2C authentication in non-Windows environments.
  • If WPF is inherently Windows-only, clarify this early and provide links or references to cross-platform alternatives for developers targeting Linux.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example Windows First
Summary:
The documentation page demonstrates a bias toward Windows by exclusively providing PowerShell scripts and referencing Microsoft PowerShell as the HTTP client for testing the Node.js app, without offering equivalent Linux/macOS command-line examples (such as curl or HTTPie). The only terminal-based example is PowerShell, and no mention is made of common cross-platform or Linux-native tools. This may hinder Linux/macOS users from following the testing steps directly.
Recommendations:
  • Provide equivalent Linux/macOS command-line examples using curl or HTTPie for making HTTP POST requests to the Node.js app, alongside the PowerShell example.
  • Mention cross-platform tools (curl, HTTPie, Postman) as alternatives to PowerShell for testing HTTP endpoints.
  • When referencing tools, avoid listing Microsoft/Windows tools first or exclusively; instead, present options for both Windows and Linux/macOS users.
  • Explicitly state that the instructions are platform-agnostic where possible, and clarify any steps that are specific to Windows or require adaptation for other operating systems.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation exclusively uses PowerShell scripts and tasks for deploying Azure AD B2C custom policies, with no mention of Bash, shell, or cross-platform scripting alternatives. All code examples, instructions, and pipeline tasks are centered around PowerShell, which is traditionally associated with Windows environments. There is no guidance for Linux or macOS users, nor are there examples using platform-agnostic tools or scripts.
Recommendations:
  • Provide equivalent Bash or shell script examples for deploying policies, suitable for Linux/macOS agents.
  • Include instructions for running the deployment on non-Windows agents in Azure Pipelines.
  • Mention and demonstrate the use of cross-platform tools (e.g., Azure CLI, curl, or REST API calls via Bash) as alternatives to PowerShell.
  • Clarify any platform requirements or limitations for the provided scripts, and suggest how users on Linux/macOS can adapt the process.
  • When listing steps or tools, avoid assuming PowerShell as the default and present cross-platform options side-by-side.

Page-Level Analysis

Windows First
Summary:
The documentation provides platform-specific instructions for generating a development signature hash, listing the Windows command first and labeling the next as 'For iOS' (though it is actually the Unix/Linux equivalent). No explicit Linux example is given, and the Windows command is prioritized, which may imply a Windows-first bias.
Recommendations:
  • Label the Unix command as 'For Linux/macOS' instead of 'For iOS', since the command is for the shell and applies to both Linux and macOS environments.
  • Present both Windows and Linux/macOS commands together, or list Linux/macOS first or equally, to avoid implying Windows is the default or primary environment.
  • Explicitly mention Linux as a supported development environment in the relevant sections.
  • Consider providing a table or side-by-side code blocks for Windows and Linux/macOS commands for parity and clarity.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows, specifically WPF desktop applications, with all code samples and guidance tailored to the Windows ecosystem. There are no Linux or cross-platform examples, and Windows-specific patterns (such as WindowInteropHelper and WPF APIs) are used exclusively. The documentation does not mention or provide alternatives for Linux or other platforms.
Recommendations:
  • Include equivalent examples for cross-platform desktop frameworks (such as .NET MAUI, Avalonia, or GTK#) that run on Linux.
  • Provide guidance or links for configuring Azure AD B2C authentication in Linux desktop applications.
  • Clarify in the introduction that the guidance is specific to WPF/Windows, and link to cross-platform or Linux-specific documentation if available.
  • When discussing redirect URIs and MSAL usage, note any platform-specific considerations for Linux or macOS.
  • If possible, provide PowerShell and Bash/terminal command equivalents for any setup or configuration steps.

Page-Level Analysis

Windows First Powershell Heavy Missing Linux Example
Summary:
The documentation page demonstrates a mild Windows bias, primarily in the 'Run your SPA application' section, where only PowerShell commands are shown for running the app. There is no mention of Linux or macOS command-line equivalents, nor any guidance for non-Windows users. Earlier steps use generic 'command shell' language, but the explicit use of PowerShell syntax and lack of cross-platform notes may confuse or exclude Linux/macOS developers.
Recommendations:
  • Provide both Windows (PowerShell/cmd) and Linux/macOS (bash/sh) command examples, especially in the 'Run your SPA application' section.
  • Use cross-platform command syntax where possible (e.g., 'node index.js' instead of 'npm ./index.js', which is not standard).
  • Add notes clarifying that all steps can be performed on Linux/macOS, and specify any OS-specific considerations.
  • Avoid using PowerShell-specific syntax unless necessary, or always pair it with bash equivalents.
  • Explicitly mention that the instructions are cross-platform and tested on Windows, Linux, and macOS.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation page is heavily focused on ASP.NET Core and C# code, which are most commonly associated with Windows development environments. There are no explicit instructions, examples, or notes for Linux or cross-platform users. The use of Windows-centric project structures (e.g., Startup.cs, appsettings.json) and references to Visual Studio conventions further reinforce a Windows-oriented approach. There are no command-line instructions, but if there were, they would likely be PowerShell or CMD by default given the context.
Recommendations:
  • Add explicit notes or sections clarifying that ASP.NET Core and related tools are cross-platform, and provide guidance for Linux and macOS users.
  • Include examples or references for setting up and running the sample projects on Linux (e.g., using the dotnet CLI, file paths, and environment variable configuration).
  • Mention common Linux editors (e.g., VS Code, Vim) and how to edit configuration files or run the application from the terminal.
  • If any scripts or commands are referenced, provide both Windows (PowerShell/CMD) and Linux (bash) equivalents.
  • Highlight any platform-specific considerations, such as file permissions or case sensitivity, that may affect Linux users.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation is heavily focused on ASP.NET Core and Visual Studio tooling, which are traditionally Windows-centric. While .NET Core is cross-platform, the instructions and examples assume a Windows development environment (e.g., Visual Studio, Visual Studio Code) and do not mention or provide explicit guidance for Linux or macOS users. There are no Linux-specific instructions, troubleshooting tips, or references to Linux development workflows.
Recommendations:
  • Explicitly mention that all .NET Core CLI commands work cross-platform (Windows, Linux, macOS) and provide assurance that Linux is supported.
  • Add a section or callout for Linux/macOS users, including any prerequisites (e.g., installing .NET SDK on Linux, using editors like VS Code or JetBrains Rider).
  • Include Linux/macOS-specific instructions for running the app (e.g., using 'dotnet run' in a terminal), and clarify any differences in file paths or environment variables.
  • If referencing Visual Studio, also reference cross-platform editors (e.g., VS Code, Rider) and provide equivalent steps.
  • Add troubleshooting tips for common Linux/macOS issues (e.g., HTTPS certificate trust, file permissions).

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation demonstrates a Windows bias by focusing exclusively on ASP.NET web applications (a Microsoft-centric technology), referencing Visual Studio and Visual Studio Code as development environments, and omitting any Linux-specific instructions or examples. There are no mentions of Linux tools, shell environments, or cross-platform considerations for running or deploying the application. All command-line instructions are generic or Windows-centric, and there is no guidance for users developing on Linux or macOS.
Recommendations:
  • Explicitly mention that .NET Core and ASP.NET Core are cross-platform and can be developed and run on Linux, macOS, and Windows.
  • Provide Linux/macOS equivalents for any command-line instructions, including package installation and project creation.
  • Include instructions for using popular Linux editors (e.g., VS Code on Linux, JetBrains Rider) and terminal environments.
  • Add troubleshooting notes or links for common Linux/macOS issues (e.g., HTTPS certificate trust, file permissions).
  • Clarify that the dotnet CLI commands work on all platforms, and avoid implying that Visual Studio (Windows) is required.
  • If referencing Visual Studio, also mention Visual Studio for Mac or cross-platform alternatives.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation provides PowerShell-based examples (specifically using the Microsoft Graph PowerShell module) for configuring password expiry, but does not offer equivalent CLI or scripting examples for Linux/macOS users. There is an implicit assumption that administrators will use PowerShell, which is more common on Windows. No mention is made of cross-platform alternatives such as Azure CLI, Bash, or REST API usage via curl, and there are no Linux/macOS-specific instructions or examples.
Recommendations:
  • Provide equivalent examples using Azure CLI and/or Bash scripts (e.g., using curl to call Microsoft Graph API), which are natively available on Linux/macOS.
  • Explicitly mention that PowerShell Core is cross-platform and provide installation instructions for non-Windows systems, if PowerShell must be used.
  • Where possible, present REST API calls with both PowerShell and curl/Bash examples, so users on any OS can follow along.
  • Reorder or parallelize examples so that Windows and Linux/macOS approaches are given equal prominence.
  • Add a note clarifying that all operations can be performed from any OS, and link to relevant cross-platform tool documentation.

Page-Level Analysis

Windows Tools Powershell Heavy Windows First Missing Linux Example
Summary:
The documentation page demonstrates a strong Windows bias throughout. All AD FS configuration steps are described using Windows-specific tools such as Server Manager, AD FS Management snap-in, and PowerShell cmdlets. There are no Linux or cross-platform alternatives provided for any step, and all troubleshooting instructions reference Windows event logs and tools. The documentation assumes the administrator is operating in a Windows environment and does not mention or provide guidance for Linux-based AD FS alternatives or SAML identity providers.
Recommendations:
  • Provide equivalent instructions for configuring SAML identity providers using non-Windows AD FS alternatives (e.g., Shibboleth, SimpleSAMLphp) commonly used on Linux.
  • Include examples of how to generate and manage certificates using Linux tools (e.g., OpenSSL) alongside any Windows-specific instructions.
  • Offer guidance on how to view and troubleshoot SAML logs and events using Linux-based tools or generic SAML debugging tools.
  • Clearly state at the beginning of the document that the instructions are Windows/AD FS-specific, and link to separate guides for Linux-based SAML providers if available.
  • Where PowerShell or Windows GUI steps are given, provide equivalent CLI or configuration file examples for Linux-based SAML providers.

Page-Level Analysis

Windows First Windows Tools Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias by referencing Windows-specific tools and documentation (such as Schannel and enabling TLS 1.2 in Windows environments) and omitting Linux-specific guidance or examples. No Linux or cross-platform configuration instructions are provided, and the linked resources are primarily Windows-focused.
Recommendations:
  • Include examples or references for configuring TLS 1.2 and cipher suites on common Linux web servers (e.g., Apache, Nginx) and platforms.
  • Add links to official Linux/OpenSSL documentation for managing cipher suites and TLS versions.
  • Balance the 'Next steps' section with resources relevant to both Windows and Linux environments.
  • Mention cross-platform tools (such as OpenSSL's s_client) for endpoint testing, in addition to SSL Labs.
  • Explicitly state that the requirements apply to all platforms and provide parity in troubleshooting guidance for non-Windows systems.

Page-Level Analysis

Windows Tools Missing Linux Example Windows First
Summary:
The documentation demonstrates Windows bias by exclusively referencing Windows-specific tools (such as Server Manager and AD FS Management), providing only GUI-based instructions for AD FS setup, and omitting any Linux or cross-platform alternatives. There are no command-line or Linux-based examples for configuring AD FS or equivalent identity providers, and all instructions assume a Windows Server environment.
Recommendations:
  • Provide equivalent command-line instructions using PowerShell and, if possible, cross-platform tools or APIs.
  • Acknowledge that AD FS is a Windows-only technology, but suggest or link to Linux-compatible alternatives (such as Shibboleth, Keycloak, or other OpenID Connect providers) for non-Windows environments.
  • Include a section or appendix outlining how to integrate Azure AD B2C with OpenID Connect providers running on Linux, with example configurations.
  • Clarify early in the documentation that the steps are specific to Windows Server and AD FS, and offer guidance for users on other platforms.
  • Where possible, reference REST APIs or scripting approaches that could be used from non-Windows systems to automate or replicate the configuration.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation is heavily focused on using the Azure portal web UI for configuration, which is cross-platform, but where command-line or automation is implied, there are no examples for Linux (e.g., Azure CLI, Bash) or PowerShell. There is a subtle 'Windows-first' bias in that all UI instructions and terminology are oriented toward the Azure portal experience, which is identical on all platforms but is often associated with Windows-centric workflows. There are no explicit references to Windows-only tools, but there is also a lack of parity for Linux users who may prefer CLI or scripting approaches.
Recommendations:
  • Provide Azure CLI examples for key steps (e.g., app registration, secret creation, identity provider configuration) alongside portal instructions.
  • Explicitly mention that all portal steps can be performed from any OS/browser to reinforce cross-platform compatibility.
  • Where relevant, include Bash and PowerShell script snippets for automation, and clarify that both are supported.
  • Add a section or links to documentation for automating these tasks using CLI tools, which are popular in Linux environments.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page lists a broad set of code samples for Azure AD B2C integration across platforms and languages. However, for desktop and console/daemon app scenarios, only .NET/Windows-specific samples are provided (e.g., WPF desktop app, .NET Core console app), with no equivalent Linux or cross-platform desktop/CLI examples. The only desktop sample is explicitly for Windows, and there are no Linux-native or cross-platform GUI/CLI samples. Additionally, the .NET samples are consistently listed before Node.js, Python, or other language samples, indicating a subtle 'windows_first' ordering bias.
Recommendations:
  • Add Linux-native or cross-platform desktop application samples (e.g., using Electron, Qt, or Java) to demonstrate Azure AD B2C integration outside of Windows.
  • Provide CLI/daemon application samples in languages commonly used on Linux (e.g., Python, Node.js, Go) and clarify their cross-platform compatibility.
  • Where possible, clarify if .NET Core samples are cross-platform and provide explicit instructions or notes for running them on Linux/macOS.
  • Balance the ordering of sample listings so that Windows/.NET samples are not always listed first; consider grouping by platform or language family.
  • For each sample, specify supported platforms (Windows, Linux, macOS) to help developers identify relevant examples.

Page-Level Analysis

Missing Linux Example Windows Tools
Summary:
The documentation page exclusively describes using the Azure Portal (a web-based GUI) for all steps and does not provide any command-line examples. There are no references to PowerShell, Windows-specific tools, or CLI commands, but there is also a complete absence of Linux-friendly alternatives such as Azure CLI or REST API examples. This omission can disadvantage Linux users or those who prefer automation and scripting over GUI-based workflows.
Recommendations:
  • Add Azure CLI examples for all major steps (e.g., app registration, permission assignment, role assignment, client secret creation), ensuring commands are cross-platform.
  • Include REST API examples (using curl or similar tools) for users who wish to automate the process or work on non-Windows platforms.
  • Explicitly mention that all steps can be performed using CLI or API, and provide links to relevant documentation.
  • If PowerShell or Windows-specific tools are ever referenced, ensure Linux equivalents are presented side-by-side or before the Windows examples.

Page-Level Analysis

Missing Linux Example
Summary:
The documentation does not provide any OS-specific examples, scripts, or tooling, but also does not mention or demonstrate how to perform the described operations (such as calling Microsoft Graph API) from any platform, including Windows or Linux. There is an implicit bias in that no cross-platform command-line or scripting examples (such as curl, bash, PowerShell, or CLI tools) are provided, which may leave Linux users without clear guidance.
Recommendations:
  • Add explicit examples for calling the Microsoft Graph API using cross-platform tools such as curl or HTTPie, which work on both Linux and Windows.
  • If scripting examples are provided in the future, ensure both PowerShell (Windows) and bash (Linux/macOS) examples are included.
  • Mention and link to platform-agnostic tools (e.g., Azure CLI, Microsoft Graph CLI) where possible.
  • Clarify that the described API operations can be performed from any OS, and provide sample commands for both Windows and Linux environments.

Page-Level Analysis

Powershell Heavy Windows Tools Windows First Missing Linux Example
Summary:
The documentation page demonstrates a Windows bias primarily in the 'Revoke a consumer user's session' section, where only Microsoft Graph PowerShell commands are provided and explicitly reference 'Windows PowerShell.' There are no equivalent examples for Linux or macOS users, nor is there mention of using cross-platform tools like the Microsoft Graph CLI or direct API calls via curl. The rest of the documentation focuses on portal-based actions, which are platform-agnostic, but the only programmatic example is Windows-centric.
Recommendations:
  • Provide equivalent instructions for Linux and macOS users, such as using Microsoft Graph PowerShell on those platforms (since it is cross-platform), or using the Microsoft Graph CLI or REST API via curl.
  • Avoid phrases like 'In your Windows PowerShell' and instead use 'In your terminal' or specify that the commands work on all supported platforms.
  • Include explicit Linux/macOS command-line examples where programmatic actions are shown, or at least mention that the tools are cross-platform.
  • Where possible, link to documentation for installing and using Microsoft Graph PowerShell on Linux/macOS, and/or provide REST API examples for users who prefer not to use PowerShell.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation assumes a Windows development environment throughout. It references Visual Studio (a Windows-centric IDE), .sln solution files, and Web.config XML configuration, all of which are typical of Windows/.NET workflows. There are no instructions or examples for Linux or cross-platform development environments, nor are alternative tools or editors mentioned. The guide does not address how to perform equivalent steps on Linux (e.g., using VS Code, JetBrains Rider, or command-line tools), nor does it mention .NET Core cross-platform capabilities.
Recommendations:
  • Include instructions for opening and editing the project using cross-platform tools such as VS Code or JetBrains Rider.
  • Mention how to run and test the sample application on Linux or macOS, including any prerequisites (e.g., .NET SDK installation, command-line build/run instructions).
  • Provide examples of editing configuration files using common Linux tools (nano, vim) or via the command line.
  • Clarify that the instructions are applicable to .NET Core/.NET 5+ projects, which are cross-platform, and note any differences for non-Windows environments.
  • Add a section or notes on how to deploy and test the application on Linux-based servers or containers.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation exhibits a Windows bias by referencing Windows-specific tools and workflows (such as ASP.NET MVC and OWIN middleware), providing links and instructions that default to Windows (e.g., certificate management), and omitting equivalent Linux-based examples or guidance. There are no Linux or cross-platform code samples for application integration, and the only application example for OIDC is a .NET/Windows stack. Certificate management and other operational steps reference Windows tabs or tools without Linux alternatives.
Recommendations:
  • Provide Linux-based examples for application integration, such as using a Python Flask or Node.js app for OIDC instead of only ASP.NET MVC.
  • Include instructions for obtaining and uploading certificates using Linux tools (e.g., OpenSSL) alongside or instead of Windows-centric instructions.
  • Ensure that all referenced documentation (such as certificate management) includes Linux tabs or sections, not just Windows.
  • When describing application configuration, offer both Windows and Linux deployment scenarios, especially for sample/demo apps.
  • Use cross-platform terminology and avoid assuming the reader is using Windows by default.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation demonstrates a Windows bias by providing only PowerShell scripts for critical steps such as generating self-signed certificates and random signing keys, with no equivalent Linux or cross-platform commands. The use of PowerShell and references to Visual Studio for deployment further reinforce a Windows-centric approach, while omitting guidance for Linux or macOS users.
Recommendations:
  • Provide equivalent Bash/OpenSSL commands for generating self-signed certificates and random strings for Linux/macOS users.
  • Include deployment instructions using cross-platform tools such as Azure CLI, GitHub Actions, or VS Code instead of only referencing Visual Studio.
  • Explicitly mention that the PowerShell examples are for Windows and offer alternatives for other operating systems.
  • Review all steps to ensure that Linux and macOS users can follow the tutorial without needing to switch to a Windows environment.

Page-Level Analysis

Windows First Windows Tools
Summary:
The documentation demonstrates a Windows-first bias by specifically mentioning Windows Hello as the primary example of biometric authentication, both in the introduction and in the scenario walkthrough. Windows Hello is referenced before any mention of biometric options on other platforms, and there are no explicit examples or instructions for Linux or macOS users. The documentation does not provide parity in examples or guidance for non-Windows environments, and focuses on Windows-specific tools and terminology.
Recommendations:
  • Include explicit examples and instructions for enabling biometric authentication on Linux (e.g., using fprintd, libfprint, or other Linux-compatible biometric solutions) and macOS (e.g., Touch ID).
  • When describing scenarios, mention Linux and macOS biometric capabilities alongside Windows Hello, rather than focusing on Windows first.
  • Provide troubleshooting or compatibility notes for users on Linux and macOS, including any limitations or required setup steps.
  • Use platform-neutral language where possible (e.g., 'your device's biometric authentication' instead of 'Windows Hello'), and only reference Windows Hello as one of several options.
  • Add a table or section comparing biometric authentication support across Windows, Linux, and macOS, with links to relevant setup guides.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by referencing IIS as the example application for testing, linking to Microsoft IIS setup guides, and omitting any mention of Linux-based web servers (such as Apache or Nginx) or their configuration. All application testing and setup guidance is Windows-centric, with no Linux alternatives or parity in examples or instructions.
Recommendations:
  • Add parallel instructions and examples for deploying and testing with a Linux-based web application (e.g., Apache, Nginx, or a generic Python/Node.js app).
  • Include links to official documentation for setting up a test web application on Linux.
  • When referencing IIS, also mention Linux alternatives and provide equivalent configuration steps.
  • Ensure troubleshooting and SSL certificate management sections include Linux-relevant guidance (e.g., using OpenSSL, configuring certificates on Apache/Nginx).
  • Use neutral language when referring to test applications, e.g., 'a web application (such as IIS on Windows or Apache on Linux)' instead of only mentioning IIS.

Page-Level Analysis

Missing Linux Example Windows First
Summary:
The documentation page demonstrates a Windows bias primarily through the exclusive use of Azure Portal GUI instructions and the absence of any Linux-specific or cross-platform command-line examples. All step-by-step instructions assume use of the Azure Portal, which is platform-agnostic but often more familiar to Windows users. There are no references to Linux tools, shell commands, or PowerShell/CMD scripts, but also no mention of Bash or Linux CLI alternatives. The only code snippets are XML/PowerShell-like configuration blocks, which are not OS-specific, but the overall workflow and tooling references implicitly favor Windows users by not acknowledging or providing parity for Linux environments.
Recommendations:
  • Add CLI-based instructions using Azure CLI or Azure PowerShell, and specify cross-platform compatibility.
  • Include examples or notes for performing key steps (such as uploading policy files or managing secrets) using Bash or Linux shell environments.
  • Explicitly mention that the Azure Portal is accessible from any OS, and provide links to documentation for Linux users where relevant.
  • Where configuration files are edited or uploaded, provide command-line alternatives (e.g., using az ad b2c policy commands if available) and note any OS-specific considerations.
  • Review and update the documentation to ensure that Linux administrators can follow all steps without needing to switch to a Windows environment.

Page-Level Analysis

Missing Linux Example Windows Tools Windows First
Summary:
The documentation page demonstrates a Windows bias by referencing Visual Studio and linking to Windows-centric deployment instructions, without mentioning or providing equivalent guidance for Linux-based development environments or deployment tools. There are no examples or instructions for deploying the API from Linux or using cross-platform tools, and the only deployment path described is via Visual Studio, which is primarily a Windows tool.
Recommendations:
  • Add instructions for deploying the API using cross-platform tools such as the Azure CLI, Azure DevOps, or GitHub Actions, which can be used from Linux, macOS, or Windows.
  • Provide examples for deploying the API using the dotnet CLI (dotnet publish) and Azure CLI (az webapp up), which are available on Linux.
  • Include a note or section highlighting that Visual Studio is not required and that developers can use VS Code or other editors on Linux.
  • Where deployment instructions are given, offer both Windows (Visual Studio) and Linux (CLI-based) alternatives, and avoid assuming the user is on Windows.
  • Review all linked documentation to ensure Linux users are not excluded or left without guidance.

Page-Level Analysis

Missing Linux Example Windows Tools Windows First
Summary:
The documentation demonstrates a mild Windows bias. It references Windows-specific tools (Visual Studio, Azure Storage Explorer) without mentioning cross-platform or Linux alternatives, and omits command-line or deployment examples for Linux users. There are no explicit Linux or macOS instructions, and the only tool mentioned for code publishing is Visual Studio, which is primarily a Windows application.
Recommendations:
  • Provide alternative instructions for deploying the API using cross-platform tools such as the Azure CLI, Azure DevOps, or GitHub Actions, including Linux/macOS command-line examples.
  • Mention and link to cross-platform editors (e.g., VS Code) and deployment methods (e.g., dotnet CLI, az webapp deploy) alongside Visual Studio.
  • For managing Azure Storage, suggest cross-platform tools such as the Azure CLI (az storage blob upload), AzCopy, or the Azure Portal, not just Azure Storage Explorer.
  • Explicitly state that all steps can be performed from Linux/macOS as well as Windows, and provide any necessary shell or command-line examples.
  • Review all tool and workflow mentions to ensure parity for Linux and macOS users, not just Windows.

Page-Level Analysis

Powershell Heavy Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by exclusively providing PowerShell-based instructions for enabling Saviynt to delete users in Azure AD B2C. It explicitly instructs users to install the Microsoft Graph PowerShell module on a Windows workstation or server, with no mention of Linux or cross-platform alternatives. No CLI, Bash, or platform-agnostic examples are provided, and the use of PowerShell is assumed throughout the configuration steps.
Recommendations:
  • Provide equivalent instructions using the Microsoft Graph CLI or REST API with curl, which are cross-platform and work on Linux, macOS, and Windows.
  • Explicitly mention that the Microsoft Graph PowerShell module is available for Linux and macOS via PowerShell Core, and provide installation steps for those platforms.
  • Include Bash or shell script examples alongside PowerShell commands, or at least reference how to perform the same operations on Linux.
  • Avoid language that assumes a Windows environment (e.g., 'on a Windows workstation or server') unless absolutely necessary, and clarify when steps are platform-specific.
  • Add a section or note about platform compatibility and alternative tooling for non-Windows users.

Page-Level Analysis

Missing Linux Example Windows Tools Windows First
Summary:
The documentation page demonstrates a bias toward Windows environments by referencing .NET and web.config (Windows-centric technologies), omitting Linux-specific deployment or configuration guidance, and providing hosting instructions only for Azure App Service (commonly used with Windows). There are no examples or instructions for Linux-based hosting, configuration (such as environment variables or appsettings.json), or cross-platform .NET Core usage.
Recommendations:
  • Provide Linux-specific deployment instructions, such as hosting the .NET app on Linux-based services (e.g., Azure App Service for Linux, Docker, or on-premises Linux servers).
  • Include configuration examples using appsettings.json and environment variables, which are cross-platform and preferred for .NET Core/5+/6+ applications.
  • Offer guidance for running the sample app using the dotnet CLI, including Linux/macOS terminal commands.
  • Mention cross-platform certificate creation and management tools (e.g., OpenSSL) alongside or instead of Windows certificate tools.
  • Clarify that the sample app and instructions are compatible with both Windows and Linux, and highlight any platform-specific considerations.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation is heavily focused on Windows, specifically using a WPF (Windows Presentation Foundation) desktop application and Visual Studio as the development environment. There are no examples or instructions for running the sample on Linux or macOS, nor are any cross-platform frameworks or tools mentioned. All screenshots and workflow steps are tailored to Windows users, and the use of Visual Studio (Windows-only for WPF) further excludes Linux users.
Recommendations:
  • Provide equivalent instructions and sample applications for Linux (and macOS), such as using .NET MAUI or Avalonia for cross-platform desktop apps.
  • Include steps for running the sample using Visual Studio Code or JetBrains Rider, which are available on Linux.
  • Offer command-line instructions for building and running the application using the .NET CLI, which is cross-platform.
  • Add Linux-specific prerequisites and troubleshooting sections.
  • Include screenshots and workflow descriptions for non-Windows environments.

Page-Level Analysis

Windows First Missing Linux Example Windows Tools
Summary:
The documentation demonstrates a Windows bias by exclusively referencing Visual Studio (a primarily Windows IDE) for running the sample application, and all instructions assume the use of Windows tooling and workflows. There are no examples or guidance for running the sample on Linux or using cross-platform tools such as VS Code, .NET CLI, or alternative editors. Linux users are left without instructions on how to set up, run, or debug the sample application.
Recommendations:
  • Add a section with instructions for running the sample on Linux using the .NET CLI (e.g., dotnet build, dotnet run) and editors like VS Code.
  • Mention cross-platform prerequisites, such as installing the .NET SDK, and provide download links for Linux and macOS.
  • Include Linux/macOS-specific steps for cloning the repository, restoring dependencies, and running both the web app and API.
  • Provide screenshots or terminal output examples for Linux environments where appropriate.
  • Clarify that Visual Studio is optional and that the sample can be run on any platform supporting .NET Core/ASP.NET Core.

Page-Level Analysis

Windows First Missing Linux Example
Summary:
The documentation page demonstrates subtle Windows bias by referencing a SAML application guide with a URL parameter '?tabs=windows', suggesting that Windows-specific instructions or tabs are prioritized or default. There are no explicit Linux or cross-platform examples or tabs mentioned, and no indication that Linux users are equally supported in the SAML app registration flow. No PowerShell or Windows-only tools are directly mentioned, but the lack of Linux parity in tabbing and examples is notable.
Recommendations:
  • Ensure that all platform-specific instructions (such as for SAML apps) provide both Windows and Linux (and possibly macOS) tabs or examples.
  • Default to a neutral or cross-platform tab (e.g., '?tabs=linux' or '?tabs=cli') in documentation URLs, or provide a platform selector.
  • Explicitly mention Linux and other non-Windows platforms in relevant sections to assure users of parity.
  • Review all linked tutorials to confirm that Linux instructions are present and equally prominent.
  • Where applicable, provide CLI-based (e.g., Azure CLI, Bash) examples alongside any Windows/Powershell instructions.

Page-Level Analysis

Powershell Heavy Windows Tools Missing Linux Example
Summary:
The documentation demonstrates a Windows bias primarily in the certificate creation section, where only PowerShell is mentioned as a method for creating self-signed certificates. There are no equivalent Linux or cross-platform command-line examples (such as OpenSSL) provided for certificate generation. The rest of the documentation is largely platform-agnostic, focusing on Azure portal UI and XML configuration, but the lack of Linux guidance in key operational steps may hinder non-Windows users.
Recommendations:
  • Provide Linux and cross-platform examples for creating self-signed certificates, such as using OpenSSL, alongside the existing PowerShell instructions.
  • When referencing command-line tools or scripts, ensure both Windows (PowerShell) and Linux (Bash/OpenSSL) options are presented, or link to platform-agnostic Azure CLI documentation where possible.
  • Explicitly state that certificate creation can be performed on any OS, and provide step-by-step instructions for at least the two major platforms (Windows and Linux).
  • Review any included scripts or downloadable resources to ensure they are not Windows-only, or provide equivalents for Linux/macOS users.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools Windows First
Summary:
The documentation provides only a PowerShell script for monitoring directory quota, with no equivalent example for Linux or cross-platform environments. It assumes the use of Windows tools and patterns (PowerShell, Invoke-RestMethod, New-Object), and does not mention or prioritize Linux-compatible alternatives. This may hinder users on Linux or macOS from following the guide easily.
Recommendations:
  • Provide a cross-platform example using curl and jq (or similar tools) for Linux/macOS users.
  • Include a note that the PowerShell script can be run on PowerShell Core, which is available on Linux and macOS, if applicable.
  • List both Windows (PowerShell) and Linux/macOS (bash/curl) examples side by side, or at least mention Linux alternatives.
  • Avoid assuming the user is on Windows; use more neutral language and tool recommendations.
  • Add a section or callout for Linux users, explaining how to achieve the same result with native tools.

Page-Level Analysis

Powershell Heavy Missing Linux Example Windows Tools
Summary:
The documentation provides only a PowerShell script example for programmatically accessing audit logs via the Microsoft Entra reporting API. There are no equivalent examples using Linux-native tools (such as curl, wget, or Python), nor are there references to Bash or shell scripting. The script assumes familiarity with PowerShell, which is primarily a Windows tool, and suggests using Azure Cloud Shell (which does support PowerShell, but Bash is also available). This creates a bias toward Windows users and may hinder Linux users or those preferring cross-platform scripting.
Recommendations:
  • Provide equivalent examples using Bash shell scripting with curl or wget to demonstrate how to access the API and process results on Linux or macOS.
  • Include a Python example for querying the Microsoft Graph API, as Python is cross-platform and widely used.
  • Explicitly mention that the API can be accessed from any platform and that PowerShell is just one option.
  • Add a note or section on using Azure CLI or other cross-platform tools where applicable.
  • Reorder or parallelize examples so that Windows and Linux approaches are presented together, or alternate which comes first.