OmadaSqlTroubleshooter is a PowerShell Module that contains an interactive desktop application that is used to manage and execute SQL queries stored in the SQL Troubleshooting section in Omada Identity Suite.
- Create, update, save and execute SQL queries
- Save queries without executing
- Query history
- Browse history
- Restore a query from history
- Compare changes for each updated query
- Export historic queries (JSON, CSV, TXT)
- Name the database in the SQL itself instead of changing the Data connection dropdown first:
SELECT * FROM [DatabaseA].[Schema].[Table]runs againstDatabaseAwhatever the dropdown has selected.Db.Schema.Tableand the two-dot[Db]..[Table]form work too, in any mix of bracketed and bare identifiers, matched case-insensitively- An explicit database governs the whole statement, so unqualified names in that same statement resolve inside it as well
- The database is resolved per statement, so one script may span databases — each statement runs against its own connection and gets its own result grid.
SELECT … FROM [DatabaseA]…followed bySELECT … FROM [DatabaseB]…is two queries against two databases, not an error USE [DatabaseA]switches the dropdown, the status bar and the loaded schema, and sticks for later executions — exactly as in SSMS. It applies to its own statement and every statement after it, so statements above it still use whatever was selected before.USEon its own switches and executes nothing- An inline prefix wins over a
USEin force, for that one statement, and is not sticky: it leaves the dropdown alone - Everything above behaves identically when you execute a selection
- The database name is matched against the data connection's name in the dropdown. Omada exposes only the connection's name and id, never the physical database name, so a tenant whose connections are named differently from its databases writes the connection name
- Connections that address no deployed database are not offered. Omada publishes a data connection whether or not its database exists: with ODW ingestion enabled,
ODWMD,Source System Data DBandODWSare published and unused, and selecting one — or naming it in a query — could only fail. They are therefore absent from the dropdown, from the schema view and from cross-database completion alike. The match is exact on the connection's name and case-insensitive, never a substring, so a connection merely containing one of those names is kept; and if the tenant's ingestion setting cannot be read, nothing is filtered at all - The query stored on the Omada data object is always the original text you wrote, prefixes included. The rewritten, unqualified text goes to a temporary object that is deleted again after the run
- Checks that happen before anything is sent to Omada — the query is not posted at all when one fails:
- An unknown database name is rejected, naming the statement it is in, the database, and the connections that do exist
- A single statement addressing two different databases is rejected: Omada executes a statement against one data connection, so a cross-database join cannot work. Split it into one statement per database — which, since each statement runs on its own connection, you can now do in the same script
- A four-part (linked server) name is rejected for the same reason
- Limitations worth knowing:
- A database prefix inside a string literal or a comment is left untouched, by design — so a query building dynamic SQL is not rewritten for you
- A query saved with a database prefix will not run from Omada's own UI, because what is stored is what you wrote
- Resolving a name proves the connection exists, not that your account may read from it — per-connection permissions still apply
- A query with no database prefix costs nothing: no extra request, no extra data object
- Context-aware SQL IntelliSense (T-SQL):
- Tables (schema-qualified) are suggested after
FROM/JOIN - Columns are suggested in
SELECT/WHERE/ON/GROUP BY/ORDER BY, scoped to the tables referenced in the statement - Table aliases resolve to their columns (e.g.
FROM dbo.Person p→p.completes Person's columns), and column suggestions show their data type - Keyword, built-in function and snippet suggestions (e.g.
SELECT … FROM,JOIN … ON,CASE WHEN) for SQL syntax - The schema is retrieved automatically on connect and when you switch database — no need to open the schema view first
- Across databases: after
[DatabaseA].the schemas of that data connection are suggested, and after[DatabaseA].[Schema].its tables. Every database's schema is fetched on connect, so these suggestions are normally there immediately, served from the cache with no request at all. If a database has not been loaded yet — the preload is skipped when background requests are unavailable — naming it fetches it in the background and the suggestions appear a moment later
- Tables (schema-qualified) are suggested after
- Schema view — one collapsible node per data connection, with the one you are connected to expanded. Every database's schema is requested on connect, in the background and one request per connection, so a node is normally already filled by the time you open it and expanding it costs nothing. The filter works across all four levels. If background requests are unavailable the preload is skipped and a database falls back to loading on first expand — the only case where a node is still empty, and where the filter matches on its own name only because there is nothing else loaded to match against
- Schema view — press Shift + click on a table or column to insert it into the editor, and Refresh schema to discard the cached schema and fetch it again
- Filter queries while typing in the editor
- Client-side validation while you type — errors are shown in the editor before a query is ever sent to Omada:
- T-SQL syntax, parsed locally with the same parser SQL Server's own tooling uses, so the message is the one the server would have returned
- Tables and columns, resolved against the schema already fetched for IntelliSense — a warning, never a blocker, because the cached schema can be older than the database. A
[DatabaseA].[Schema].[Table]name is checked too, but only once that database's schema has been loaded — normally on connect, otherwise by expanding it in the schema view or naming it in the editor; until then it is left alone, because the validation pass never makes a request of its own. Four-part linked-server names are never checked - Omada compatibility, for queries that are valid T-SQL and still cannot work here (see What the SQL Troubleshooter can run below)
- Nothing leaves your machine for this: the query text is parsed and resolved locally, and nothing blocks execution — you are asked once and can always execute anyway
- Each check can be switched off independently, and individual compatibility rules can be re-levelled or suppressed, in the application configuration
The tool has read access only. That is its security posture, not a limitation to be worked around: a troubleshooting client that can read identity data is already sensitive, and one that could write to the Omada database would be a different risk class entirely. Enforcement is the tenant's permission set; the client-side checks exist to explain the boundary at the moment you meet it.
| Not supported | Supported |
|---|---|
Data manipulation — INSERT, UPDATE, DELETE, MERGE, TRUNCATE |
SELECT, in all its forms |
Data definition — CREATE, ALTER, DROP |
Reads from tables and views |
Stored procedures and dynamic SQL — EXEC, sp_executesql |
Common table expressions, including multiple and nested |
Temporary tables — #t, ##t, SELECT … INTO #t |
Derived tables, JOIN, APPLY, set operators |
Window functions, PIVOT/UNPIVOT, CASE, built-in functions |
One rule is worth knowing before you write a query rather than after: every column in the result must have a name. Results come back as JSON objects keyed by column name, so a column with no key cannot survive that representation — the query runs and the grid arrives empty, reported as Query did not return any results!. Alias the column and it works:
SELECT uid, COUNT(*) FROM dbo.SomeTable GROUP BY uid -- returns nothing
SELECT uid, COUNT(*) AS [Count] FROM dbo.SomeTable GROUP BY uid -- returns rowsTemporary tables are the other common surprise. Use a common table expression instead — CTEs are
supported and are the sanctioned replacement. (SELECT … INTO writes a table, so it belongs with the
data-definition row above whatever the target is called; only the #t form is flagged as a temporary
table.)
- View results in a PowerShell GridView
- Context menu for quick copy, select all and save
- Select cells, columns, rows and copy to clipboard
- Export results to JSON, CSV, PowerShell CliXml or plain text
- WebView2 — browser-based via WebView2 (default)
- Browser — browser-based via Selenium
- OAuth — OAuth2 / Entra ID
The password is only needed for password based authentication. For WebView2 (and Browser started
with -UseWebView2Auth) you can enter just a username and leave the password empty: the sign-in then
uses that account and waits in the sign-in window for you to complete it with a passwordless method
(Windows Hello, a FIDO2 security key, Microsoft Authenticator) or by typing the password there. OAuth always needs the client secret, and Browser
on Selenium needs the password, because it would otherwise submit an empty one.
- Work with multiple queries and connections side by side, each in its own tab
- Every tab is an independent workspace with its own connection settings, query editor and results
- Add a tab — click the + button next to the tabs, or use the tab New Tab context menu
- Duplicate a tab — copy a tab's connection and query into a new, unsaved tab (Duplicate Tab), or copy only the connection without the query (Duplicate Tab without Query)
- Close tabs — close a single tab (its ✕ button or context menu), Close All But This, or Close All
- Reorder tabs — drag a tab to a new position
- Tabs shrink to fit on a single row; long names are truncated with an ellipsis (…)
- New and duplicated tabs are auto-named
Query{#}, kept unique against your saved queries; the name is pre-filled into the Display name field so a duplicate can be saved with a single click - A query Display name cannot be empty when saving
Tabs that share the same connection form a connection pool, identified by the combination of tenant URL + authentication method + credentials:
- When a tab connects, every tab in the same pool shares that active connection — no repeated sign-in
- Disconnecting one tab disconnects only that tab; the others in the pool stay connected
- A new tab whose connection settings match an already-connected pool reuses that pool's connection
- A new tab whose settings match no connected pool creates a new pool of its own
- Auto-complete connection URL (e.g.
tenantname→https://tenantname.omada.cloud) - Select query or connection from a dropdown while typing
- Automatic persistence of connections, queries, tabs and layout between sessions
- Option to store credentials; WebView2/Browser with Entra ID can auto-fill them
- Detailed logging to log window and console
- Optional session log file (off by default; tick Write log file in the log window, which starts
and stops it immediately and is remembered for the next start), written continuously and flushed
as it goes, so a crashed session still has a log — in
%APPDATA%\OmadaSqlTroubleshooter\logs, shown in the log window, redacted exactly as the window is, split into 5 MB parts, and pruned to the 10 most recent sessions. It follows the application's log level — a line is in the file exactly when the log window is showing it, and changing the level applies to the file from the next line on — so raise the level before reproducing something you intend to send in. A file started mid-session holds only what is logged from that moment on; Export Log File still saves everything the window is showing
| Shortcut | Action |
|---|---|
F5 |
Execute query |
Enter (in connection field) |
Initiate connection |
Ctrl + S |
Save current query in Omada |
Ctrl + Shift + K |
Duplicate the current tab (connection and query) |
Ctrl + T |
Duplicate the current tab without the query editor contents |
Ctrl + W / Ctrl + F4 |
Close the current tab |
Ctrl + Tab |
Switch to the next tab (wraps from the last tab to the first) |
Ctrl + Shift + Tab |
Switch to the previous tab (wraps from the first tab to the last) |
Ctrl + C (result pane) |
Copy selected cell(s) to clipboard |
Ctrl + Shift + C (result pane) |
Copy selected cell(s) including headers to clipboard |
Ctrl + Shift + S (result pane) |
Copy selected cell(s) formatted as array for direct use in a Sql query to clipboard |
Ctrl + Shift + P (result pane) |
Copy selected cell(s) formatted as array for direct use in a PowerShell query to clipboard |
This application leverages the permissions of the user that is logged in. The application uses the built-in OData endpoint (C_P_SQLTROUBLESHOOTING) for the SQL Troubleshooter and the Omada Enterprise Server API.
Important
The C_P_SQLTROUBLESHOOTING OData endpoint is disabled by default. Enabled it in the Data Object Type configuration in Omada in order to use this application. Also make sure that you have the correct user permissions to Create, Read and Modify objects via OData.
Important
Authentication is handled by the OmadaWeb.PS PowerShell module. This module must be installed before running the application. OmadaWeb.PS can simply be installed using this command:
Install-Module -Name OmadaWeb.PSTo install the module from the PowerShell Gallery, you can use the following command:
Install-Module -Name OmadaSqlTroubleshooterThis module requires:
- Windows operating system;
- PowerShell 7;
- OmadaWeb.PS PowerShell Module (Version 2026.09.23.47 or higher);
- Microsoft Edge WebView2;
- Omada Identity Cloud with OData enabled for the C_P_SQLTROUBLESHOOTING data object type;
- Create, Read and Modify user permissions for OData.
Note
If you are not able to install Microsoft Edge Webview2 you can download the Fixed Version x64 bit from here. Extract the Cab file using e.g. 7-Zip, copy the contents from folder 'Microsoft.WebView2.FixedVersionRuntime.xxxx.x64' to %LOCALAPPDATA%\OmadaSqlTroubleshooter\bin\Webview2Runtime. The contents of the target folder should now like as shown in the image below.
To import the module, use the following command:
Import-Module OmadaSqlTroubleshooterInvoke-OmadaSqlTroubleshooter [[-LogLevel] <string>] [-Reset] [-LogToConsole] [<CommonParameters>]Here are some example commands you can use with the OmadaSqlTroubleshooter module:
Invoke-OmadaSqlTroubleshooterInvoke-OmadaSqlTroubleshooter -LogLevel DEBUG -LogToConsoleInvoke-OmadaSqlTroubleshooter -ResetSet the loglevel. Default is INFO
Type: String
Parameter Sets: (All)
Aliases:
Accepted values: INFO, DEBUG, VERBOSE, WARNING, ERROR, FATAL, VERBOSE2
Required: False
Position: 0
Default value: None
Accept pipeline input: False
Accept wildcard characters: FalseOutputs logging to the console.
Type: SwitchParameter
Parameter Sets: (All)
Aliases:
Required: False
Position: Named
Default value: None
Accept pipeline input: False
Accept wildcard characters: FalseUses the WebView2 for browser-based authentication instead of Selenium.
Important
This parameter is deprecated, select the WebView2 authentication option from the UI instead.
Type: SwitchParameter
Parameter Sets: (All)
Aliases:
Required: False
Position: Named
Default value: None
Accept pipeline input: False
Accept wildcard characters: FalsePrevents the application from attempting to reconnect to the Omada Identity Suite using the stored connection information.
Type: SwitchParameter
Parameter Sets: (All)
Aliases:
Required: False
Position: Named
Default value: None
Accept pipeline input: False
Accept wildcard characters: FalseResets the stored configuration to default.
Type: SwitchParameter
Parameter Sets: (All)
Aliases:
Required: False
Position: Named
Default value: None
Accept pipeline input: False
Accept wildcard characters: FalseType: ActionPreference
Parameter Sets: (All)
Aliases: proga
Required: False
Position: Named
Default value: None
Accept pipeline input: False
Accept wildcard characters: FalseThis cmdlet supports the common parameters: -Debug, -ErrorAction, -ErrorVariable, -InformationAction, -InformationVariable, -OutVariable, -OutBuffer, -PipelineVariable, -Verbose, -WarningAction, and -WarningVariable. For more information, see about_CommonParameters.
Note
Queries that return no rows and queries that fail show the same warning. The message "Warning: Query did not return any results!" is displayed in both cases. This is a limitation of the SQL Troubleshooter component in Omada Identity Suite, which does not distinguish between an empty result set and a query execution failure.
OmadaSqlTroubleshooter is used by identity professionals against production IGA data, so it is worth stating plainly — and checkably — what the application does with that data.
In short: the application sends no telemetry, all identity data flows only between your machine and your own Omada tenant, and everything it keeps is kept locally in your own Windows user profile.
The module contains no analytics, telemetry, usage-tracking or crash-reporting code, and no such SDK is bundled. Nothing about you, your tenant, your queries or your results is sent to Fortigi or to any third party.
Every destination the module can contact is hard-coded in the source and listed below; there
are no others. You can verify this for yourself in two ways: search the module source for
http, or start the application with Invoke-OmadaSqlTroubleshooter -LogLevel VERBOSE -LogToConsole and watch every request it makes.
| Destination | When | What is sent | Why |
|---|---|---|---|
Your Omada tenant (https://<tenant>.omada.cloud or the URL you enter) |
While connected | Your SQL query text, saved query metadata and OData requests; the session credential or token for the tenant | This is the application's actual work: the SQL Troubleshooter OData endpoint (C_P_SQLTROUBLESHOOTING) and the Omada Enterprise Server API |
| Your identity provider (Entra ID or the tenant's own sign-in page) | On sign-in only | Your credentials, handled by the browser/WebView2 sign-in flow of OmadaWeb.PS | Authentication |
api.nuget.org |
Not on a normal import. Only when the WebView2 assemblies shipped inside the module are missing or fail their hash check, or on a 32-bit process | Nothing but the package request itself | Fall back to downloading the Microsoft WebView2 .NET SDK at the exact version pinned in src/DependencyLock.psd1, then verify it against the SHA-256 pinned there — see SECURITY.md and THIRD-PARTY-NOTICES.md |
www.powershellgallery.com |
On module import, and only when the module was installed from the PowerShell Gallery | The module name, in a public package-lookup request | Warn you when a newer version is available |
The last two are ordinary package requests to Microsoft-operated services. They carry no tenant name, no user name and no query data. No other host is contacted by this module.
A normal import contacts nuget.org not at all. The four WebView2 assemblies are fetched
and hash-verified when the module is built, and ship inside the package in
Bin\WebView2Dlls\win-x64 (0.97 MB). They are loaded from there, and each one is re-checked
against its pinned SHA-256 immediately before it is loaded. The application therefore starts on
a machine with no route to nuget.org at all.
api.nuget.org is contacted only if that bundle is unusable — deleted, corrupted, or a version
that no longer matches the pin — or on a 32-bit process, for which no bundle is built. The
module then downloads the same pinned package to
%LOCALAPPDATA%\OmadaSqlTroubleshooter\Bin\win-x64\ and verifies it there. Nothing about the
version is resolved over the network in either case: it comes from the lock file that ships
inside the module.
All of it lives in your own Windows user profile. Nothing is written to a shared or roaming
location beyond %APPDATA%, and nothing is written outside your profile.
| Path | Contents | Protection | Lifetime | How to clear |
|---|---|---|---|---|
%APPDATA%\OmadaSqlTroubleshooter\config\OmadaSqlTroubleshooter.json |
Application settings only: log level, window positions and sizes, last-used export folder and file type, tab capacity, and InstanceGuid (see below). No credentials, no query text, no results. |
NTFS permissions on your profile | Until deleted | Invoke-OmadaSqlTroubleshooter -Reset restores defaults, or delete the file |
%APPDATA%\OmadaSqlTroubleshooter\config\tabs.clixml |
Per-tab session state written when the application closes: tenant URL, user name, Entra application ID URI and tenant ID, the selected data connection, the name of the selected saved query, and — only if you ticked Save password — your password. The SQL text itself is not stored here; it lives in your Omada tenant. | The password field is encrypted with Windows DPAPI, bound to your Windows user account on that machine. The remaining fields are stored as plain CliXml. | Overwritten at each close; kept until deleted | Invoke-OmadaSqlTroubleshooter -Reset deletes the file, or delete it yourself |
%APPDATA%\OmadaSqlTroubleshooter\logs\OmadaSqlTroubleshooter.log and OmadaSqlTroubleshooter_<start>_<part>.log |
Only when you tick "Write log file" in the log window, which starts and stops it immediately and is remembered for the next start (the EnableSessionLogFile setting); off by default. A session log, written continuously for the lifetime of the application and flushed line by line so it survives a crash. The running session writes OmadaSqlTroubleshooter.log; past 5 MB, and at the next start, it is renamed to a numbered part named for the session's start time. It contains exactly what the log window contains — the same text, through the same redaction layer, so credentials, tokens, session cookies and result values are masked before anything is written. Query text is masked too, unless you tick Show request body or start with -SkipBodyRedaction, in which case the query reaches this file just as it reaches the window. |
NTFS permissions on your profile | Pruned on start-up to the 10 most recent sessions, all parts of a session counting as one; no size or age limit | Delete the folder, or untick "Write log file" in the log window to stop writing it immediately |
%LOCALAPPDATA%\OmadaSqlTroubleshooter\Bin\... |
Only used as a fallback. The Microsoft WebView2 .NET SDK assemblies normally ship inside the module and this folder stays empty. It is populated only when that bundle is unusable, or on a 32-bit process: the assemblies are then downloaded from NuGet at the pinned version and hash-verified before use, plus a WebView2.pin stamp recording which pin they came from. No user data. |
NTFS permissions on your profile | Until deleted; refreshed when the pinned version changes | Clear-OmadaSqlTroubleshooterCache -Scope Binaries, or delete the folder. It is re-downloaded and re-verified on the next import that needs it |
%LOCALAPPDATA%\OmadaSqlTroubleshooter\Edge User Data\OmadaWebView2Profile |
A WebView2 browser-profile folder created when the first tab's editor starts. It is created but not currently used as a profile location — the editor's WebView2 uses the %TEMP% folder below — so it stays empty. |
NTFS permissions on your profile | Until deleted | Clear-OmadaSqlTroubleshooterCache -Scope BrowserProfiles, or delete the folder |
%TEMP%\OmadaSqlTroubleshooter |
The WebView2 user-data folder (browser cache and local storage) for the editor. This WebView2 instance only ever loads the local Monaco editor page — it never loads Omada or a sign-in page, so it holds no session cookies and no tenant data. | NTFS permissions on your profile | Until deleted; %TEMP% is not cleared automatically by the application |
Delete the folder while the application is closed |
%LOCALAPPDATA%\OmadaSqlTroubleShooter\Run.ps1, plus Start Menu and Desktop shortcuts |
A small launcher script and shortcuts. No user data. | NTFS permissions on your profile | Until deleted | Delete the file and the shortcuts |
| Files you export | Query results, query history, or the application log — see the next section | Whatever you choose; the application applies no encryption | Until you delete them | Delete them |
Two details worth knowing:
InstanceGuidis a random GUID generated on first run and stored in the settings file. It is never transmitted to Fortigi or to any third party. Its only use is to give the temporary query object that the application creates inside your own tenant a stable name (TMP_<InstanceGuid>), so repeated runs reuse one object instead of leaving new ones behind.- On the very first run, before
%APPDATA%\OmadaSqlTroubleshooterexists, the settings file is written next to the installed module instead. From the next run onwards it is read and written under%APPDATA%.
Authentication cookies, tokens and browser profiles used for signing in are managed by the OmadaWeb.PS module, not by this one; see that module's documentation for where it caches them and how to clear them.
To see and remove what this module caches, without touching your settings:
# Report only - changes nothing
Clear-OmadaSqlTroubleshooterCache -ListOnly | Format-Table Scope, Artefact, Path, ItemCount, SizeBytes
# Force a fresh, hash-verified download of the WebView2 assemblies on the next import
Clear-OmadaSqlTroubleshooterCache -Scope Binaries
# Remove everything the module caches, without being asked to confirm
Clear-OmadaSqlTroubleshooterCache -Force-WhatIf previews without removing. Your configuration under %APPDATA% is never touched by
this command — use Invoke-OmadaSqlTroubleshooter -Reset for that. An assembly already loaded
into the running PowerShell session is locked by Windows: the command reports which files it
could not remove and carries on, so close that session and run it again.
Query results are production identity data. Treat them accordingly.
-
Exported result files (JSON, CSV, CliXml, plain text) and clipboard copies contain the full rows your query returned. Depending on the query, that can include personal data such as names, e-mail addresses, employee identifiers, manager relationships and account details. Files are written unencrypted, to a location you choose.
-
Exported query history contains the SQL text, its change history and the names of the users who created or modified each query.
-
The application log records connection URLs, user names and application events. It is designed to be shareable: every request, response and result set reaches it through a single redaction layer, so an exported log should never need scrubbing before you attach it to a support ticket. At every log level, including
VERBOSEandVERBOSE2:Authorizationheaders, session cookies and tokens are masked.- Passwords are held as
SecureString/PSCredentialand are never written in readable form. The account's user name is recorded, because knowing which account authenticated is what makes a permission failure diagnosable. - Request bodies are recorded as their field names and value shapes, not their values.
- Result sets are recorded as row and column counts plus column names — never cell values.
Result data therefore does not reach the log at any level. This applies to the log only; the export and clipboard paths above are unaffected and still contain full rows by design.
Once you export a result set or copy rows to the clipboard, that data leaves the application's control and becomes your organisation's responsibility to handle under its own data-protection obligations — the GDPR included, where it applies. In practice:
- Export only the columns and rows you actually need, and prefer filtering in the query.
- Store exports on encrypted, access-controlled storage — not in a personal downloads folder, a shared drive, a ticket attachment or a chat message.
- Delete exports as soon as the troubleshooting task is finished; there is no automatic cleanup.
- Remember that a query and its results are visible in Omada under your account, and that the application acts only with the permissions of the signed-in user.
This statement covers the OmadaSqlTroubleshooter module. Authentication is performed by the separate OmadaWeb.PS module, and the Microsoft Edge WebView2 Runtime is a Microsoft component installed on your machine; both are governed by their own documentation and terms. Third-party components are inventoried in THIRD-PARTY-NOTICES.md.
If you find a statement here that does not match what the code does, please open an issue — an inaccurate privacy statement is a bug.
Contributions are welcome! If you have ideas for improvements or bug fixes, feel free to open a pull request on GitHub.
Please read CONTRIBUTING.md first — it covers where the tests live, how to run them, how a pull request gets validated, and the one rule we ask every change to follow: every bug fix ships with the test that would have caught it.
This project is licensed under the MIT License. See the LICENSE file for details.
OmadaSqlTroubleshooter bundles the Monaco editor and the Microsoft WebView2 .NET SDK — the latter fetched and hash-verified at build time rather than committed to the repository — and requires the Microsoft Edge WebView2 Runtime and the OmadaWeb.PS module. Every such component, its version, its licence and where it comes from is listed in THIRD-PARTY-NOTICES.md, which also records the review confirming that this project does not redistribute the WebView2 Runtime.