Microsoft services (Windows)¶

Agent 1.5.0 and later include bundled templates that install a renewed certificate in the Windows machine store and bind it to a Microsoft server role: Exchange, Remote Desktop, Routing and Remote Access, DirectAccess, SQL Server, Reporting Services, AD FS, Web Application Proxy, NPS and WinRM. In the desktop app they are listed under Microsoft services in Workflows → + New certificate workflow; they can also be assigned from the dashboard.

How the templates work¶

Every template has the same shape:

1. Obtain certificate - the certificate the Agent issued or renewed.
2. Install in LocalMachine\My - the certificate and its key go into the machine Personal store, not exportable. Where a service runs as its own account, the step also grants that account read access to the private key (see Service accounts).
3. Bind to - the new windows_service.bind step runs a fixed PowerShell script that is bundled with the Agent for that service.
4. Inspect the TLS endpoint and Confirm new certificate - only for the templates with a verification port, and only when Verification hostname (optional) is set: the Agent connects to the endpoint and checks that it serves the new certificate. A mismatch rolls the binding back.

The bind step runs elevated as the Agent service. The scripts are part of the signed Agent; there is no way to change them or add your own. The settings of a workflow are passed to the script as data on standard input, never pasted into the script or the command line, so a value cannot change what the script runs. The script reports the previous certificate it replaced; when a later step fails, rollback binds that previous certificate again. The script may run for 120 seconds (600 seconds for Exchange), and the bind step allows 60 seconds more.

A template description in the desktop app and in the dashboard says what it changes, what it restarts and how rollback works, and ends with Not verified on a live server: the role commands were tested only against a mocked PowerShell boundary.

Templates¶

Microsoft has deprecated DirectAccess; plan a move to Always On VPN. The DirectAccess template is there for existing deployments.

Setup fields¶

Templates with an endpoint check (Exchange, RD Gateway, RDS deployment, RRAS SSTP, DirectAccess, SSRS, AD FS, Web Application Proxy: port 443; WinRM HTTPS: port 5986) also have Verification hostname (optional) - a hostname the service presents on TLS and the certificate covers; leave it empty to skip the check - and Verification port (for SSRS HTTPS port, the port of the existing HTTPS binding, which the check uses too). A Restart … after a change switch restarts the service at once (connections drop briefly); off means the service uses the certificate after its next restart.

Service accounts and private key access¶

Some services read the private key under their own account rather than as LocalSystem. Their templates fill the store installation step's new read_principals input from Account that reads the private key, so the account gets read access to that one key. Nothing is guessed: enter a Windows account name such as DOMAIN\name, NT SERVICE\name or NT AUTHORITY\NETWORK SERVICE. The desktop app checks the value as a Windows account name when you save, and the Agent checks it again when the step runs.

In your own workflows, windows_cert_store.install accepts read_principals (up to 16 account names; see step action inputs).

Prerequisites¶

• Exchange: run the Agent on the Exchange server; the script loads the Exchange Management Shell snap-in.
• Remote Desktop Services deployment: run it on the RD Connection Broker, or name the broker.
• RRAS and DirectAccess: the role must already be installed and configured (The Routing and Remote Access VPN role is not installed and configured. / DirectAccess is not installed and configured on this server.). For IKEv2, clients must trust the issuing CA and match the server name, and the certificate needs the Server Authentication EKU.
• SSRS: the HTTPS URL must already exist (add it in Report Server Configuration Manager first); otherwise the step fails with Reporting Services has no SSL binding on IP:PORT.
• WinRM: an existing HTTPS listener whose Hostname matches the certificate; the template does not create one (There is no WinRM HTTPS listener at address X.).
• AD FS: run a workflow on every AD FS server of the farm.

Known limits¶

• RDS deployment restores a single previous thumbprint, and only when all selected roles shared it.
• SQL Server without a previous certificate is not restored to "no certificate" by rollback.
• Exchange rollback timing: the Agent allows a rollback step 2 minutes, less than the 600 seconds an Exchange binding may take.
• NPS: the policy export also holds the RADIUS shared secrets. It is kept in a folder only SYSTEM and Administrators can open and deleted afterwards.
• RRAS IKEv2 binds nothing and has no rollback.

Finding the right template¶

In the desktop app, Detect servers on this computer… in the new-workflow template dialog lists the Remote Desktop, RD Gateway, Remote Access and WinRM bindings it finds and pre-fills the matching template (read-only, no administrator prompt). See Server detection.

Related pages¶

• Workflow studio & usage
• Modular workflows
• Certificate stores & files
• Dashboard-assigned workflows
• Windows Agent