Domain: SSRS / PBIRS · Risk: Changes state · Runs on: Windows, PowerShell 5.1 or 7

Audience Lens

Manager Practitioner Learner

Getting HTTPS working on Reporting Services (or Power BI Report Server) by hand is fiddly and easy to leave half-done — a certificate can be bound while the site still returns an error, and nobody notices until a user complains. This command does the whole job on each server and then checks the website actually loads over HTTPS with the right certificate. A node is only “done” when that check passes.

It handles the multi-server case directly: point it at every node in a scale-out or cluster and each one is configured and verified independently.

For each node it: reserves the vanity HTTPS URL (RS applies the service-account ACL automatically — no netsh, no SID), binds the certificate (replacing a conflicting binding with -Force), restarts the RS service, then runs the functional check (Test-RsHttpsEndpoint). The final Verify result per node is authoritative — a node passes only when its site actually serves. Never throws.

The certificate must already be in LocalMachine\My on each node and valid for the vanity name (use Import-SqlCert to place it).

Recipe 01 — A three-node PBIRS scale-out behind one vanity name

Install-RsConnectionCertificate -Thumbprint $tp -VanityUrl 'reports.example.com' `
    -RsInstance 'PBIRS' -Node n1,n2,n3

Reserves the vanity URL, binds the SAN cert, restarts RS, and confirms the site serves on every node.

Recipe 02 — A single SSRS 2019 server, default port

Install-RsConnectionCertificate -Thumbprint $tp -VanityUrl 'reports.example.com' -RsInstance 'SSRS'

Recipe 03 — Configure only the web portal, on a non-default port

Install-RsConnectionCertificate -Thumbprint $tp -VanityUrl 'reports.example.com' `
    -RsInstance 'SSRS' -Application ReportServerWebApp -Port 8443

Recipe 04 — Bind now, restart in your own maintenance window

Install-RsConnectionCertificate -Thumbprint $tp -VanityUrl 'reports.example.com' `
    -RsInstance 'PBIRS' -SkipRestart

Everything is configured; you own the restart. The functional check will only pass after RS restarts.

Reporting Services and Power BI Report Server are websites that serve your reports. To make them use HTTPS you have to do three things on each server: reserve the web address, attach the certificate, and restart the service. Then — the step people forget — actually open the site and confirm it works.

This command does all four, in order, and treats the last one as the real test. If the website doesn’t load over HTTPS with the right certificate, the node is reported as not done, even if the earlier steps “succeeded.”

Software Approval Dependencies Compliance

Question	Answer
Outbound calls?	None to the vendor. It configures the RS servers you name and makes a local HTTPS request to confirm each serves.
What it changes	A URL reservation, an SSL binding, and (unless skipped) an RS service restart, per node.
Privileges	RS admin + local admin on each node; WinRM for remote nodes.
Manual-netsh avoided	Uses the RS-native configuration API, so HTTP.sys and RS config stay in sync — no `netsh` drift.

Dependency	Why	Required?
SSRS 2016+ or Power BI Report Server	The service being configured.	Yes
The certificate in `LocalMachine\My` on each node, valid for the vanity name	The cert to bind.	Yes
WinRM to remote nodes	For multi-node fan-out.	No (local only)
An RS service restart	The binding takes effect on restart.	Yes (unless `-SkipRestart`)

The functional check is the gate — a node passes only when the site genuinely serves over HTTPS with the expected certificate, so “configured but broken” can’t be recorded as success.
Uses the RS-native configuration API, keeping HTTP.sys and rsreportserver.config consistent — no out-of-band netsh changes for an auditor to reconcile.
Emits one SqlCert.Result per node-stage, with the authoritative per-node Verify result — a clean, per-server evidence trail for a scale-out deployment.