Domain: SSRS / PBIRS · Risk: Read-only · Runs on: Windows, PowerShell 5.1 or 7

Audience Lens

Manager Practitioner Learner

A configuration can look correct and the website still be broken — a certificate bound to the wrong name, a service that wasn’t restarted, a stale reservation. This command does what a user would do: it opens the site over HTTPS and confirms it genuinely works, with the right certificate. It’s the difference between “we configured it” and “it works.” Free to run.

Discovers the real URL (GetReportServerUrls), issues an HTTPS GET, and inspects the served certificate. Healthy = TLS handshake succeeds and HTTP status is 200 or 401 (401 is the normal RSWindowsNegotiate challenge — the site is alive). Confirms the served cert’s SAN covers the host and, with -ExpectedThumbprint, that the served cert is the one you bound. Never throws.

Recipe 01 — Confirm PBIRS serves at its vanity name

Test-RsHttpsEndpoint -RsInstance 'PBIRS' -VanityHost 'reports.example.com'

GETs the discovered path under the vanity host and confirms 200/401 with a SAN that covers it.

Recipe 02 — Assert the served cert is exactly the one you bound

Test-RsHttpsEndpoint -RsInstance 'SSRS' -Url 'https://reports.example.com/Reports' -ExpectedThumbprint $tp

Fails if the wire certificate’s thumbprint doesn’t match $tp.

Recipe 03 — Test a remote node

Test-RsHttpsEndpoint -RsInstance 'SSRS' -VanityHost 'reports.example.com' `
    -ComputerName RS02 -Credential $cred

Note — -VanityHost is required with a wildcard reservation. A strong-wildcard (+) reservation can’t tell you the vanity name, and testing localhost wouldn’t validate the certificate’s SAN — so name the host you want proven.

Everything up to now was configuration. This is the test drive: the command actually visits the report server’s web address over HTTPS and checks it responds, with the correct certificate.

A friendly detail: report servers answer a valid request with a “401 — who are you?” challenge before you sign in. This command treats that 401 as “the site is alive and encrypted,” because it is — a dead site wouldn’t get that far. It can also confirm the certificate on the wire is exactly the one you meant to bind.

Software Approval Dependencies Compliance

Question	Answer
Outbound calls?	An HTTPS request to your own report server, to confirm it serves. Nothing to the vendor.
What it changes	Nothing — read-only.
Privileges	RS admin for URL discovery; WinRM/`-Credential` for remote.
Licence	Free. The functional check needs no licence.

Dependency	Why	Required?
SSRS 2016+ or PBIRS	The service being tested.	Yes
Network path to the endpoint	It makes a real HTTPS request.	Yes
WinRM to remote nodes	Only for remote URL discovery.	No (local)

Proves encryption end to end — a real TLS handshake and HTTP response, not just a configuration value — which is the evidence a control like “reporting is served over TLS” actually needs.
Confirms the served certificate’s SAN covers the host, catching the common “bound the wrong-name cert” mistake.
With -ExpectedThumbprint, asserts the exact certificate on the wire — a precise, reproducible check for an audit.