Script icon
Process icon
If icon
Commands icon
SlackIncomingWebhook icon

IIS Site Provisioning with SSL Binding and Health Check

Orchestrate IIS website provisioning with Kestra and PowerShell. Create the app pool and site, bind an SSL certificate, health-check the result, and roll back on failure.

Categories
Infrastructure

Standing up a new IIS site by hand means repeating the same handful of PowerShell commands on every Windows Server host: create the application pool, create the site, bind the port, bind a certificate if the site needs HTTPS, then poke it with a browser to confirm it actually came up. This blueprint turns that checklist into a parameterized Kestra flow. It creates the application pool under a dedicated identity, creates the website and binds it to a port, optionally binds an already-installed SSL certificate by thumbprint, then runs an HTTP health check. If the health check or any step before it fails, an errors handler stops the site and alerts Slack, so a half-configured site never sits there quietly accepting traffic.

How it works

  1. provision_iis_site (io.kestra.plugin.scripts.powershell.Script) imports the WebAdministration module, creates the physical path if it is missing, creates the application pool under app_pool_identity if it does not already exist, creates or updates the website with New-Website or Set-ItemProperty, and starts it with Start-Website. It runs on io.kestra.plugin.core.runner.Process because IIS and the WebAdministration module only exist on the target Windows Server itself, not inside the plugin's default Linux-based Docker image.
  2. bind_ssl_certificate (io.kestra.plugin.core.flow.If) checks whether certificate_thumbprint was supplied. When it was, apply_ssl_binding (io.kestra.plugin.scripts.powershell.Commands) stages a bind-ssl.ps1 file via inputFiles, creates the HTTPS binding if needed, then binds the certificate from Cert:\LocalMachine\My using the IIS:\SslBindings provider path.
  3. health_check (io.kestra.plugin.scripts.powershell.Commands) sends an Invoke-WebRequest to localhost on the configured port and scheme, and exits non-zero if the request fails or times out.
  4. If any task fails, the errors block runs rollback_site (io.kestra.plugin.scripts.powershell.Commands) to stop the site via Stop-Website, then alert_on_failure (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) notifies the team.

What you get

  • A single parameterized flow for provisioning IIS sites, instead of a PowerShell script pasted between engineers.
  • A built-in health check that catches a bad binding or a missing certificate before the ticket gets closed.
  • Automatic rollback that stops a broken site rather than leaving it half-configured and reachable.
  • Idempotent reruns: the flow reuses an existing app pool or site instead of failing on a second run.

Who it's for

  • Windows infrastructure and ops teams who provision IIS sites for internal tools or customer-facing apps.
  • Platform engineers standardizing site provisioning across many Windows Server hosts or a hybrid worker group.
  • Teams migrating IIS setup out of tribal-knowledge runbooks and into version-controlled automation.

Why orchestrate this with Kestra

A PowerShell script triggered from Task Scheduler or a CI runner can create an IIS site, but it typically has no built-in rollback path, no separation between a scraped success and a health check that actually verifies the site works, and no structured audit trail per run. Kestra adds typed inputs so the same flow provisions any site by name, an errors block that stops a broken site instead of leaving it running, and full execution history showing exactly which step failed and why, all from a single declarative YAML file kept in Git alongside everything else.

Prerequisites

  • A Windows Server host with IIS and the IIS Management Scripts and Tools feature (which provides the WebAdministration module) installed.
  • A Kestra worker running directly on that Windows host, or in a Windows-based worker group, since io.kestra.plugin.core.runner.Process executes pwsh on the worker's own OS rather than in a container.
  • If binding HTTPS, an SSL certificate already imported into Cert:\LocalMachine\My on that host.
  • A Slack incoming webhook for failure notifications.

Secrets

  • SLACK_WEBHOOK_URL: Slack incoming webhook URL used for failure alerts.

Quick start

  1. Add the SLACK_WEBHOOK_URL secret to your Kestra namespace.
  2. Set site_name, physical_path, port, and app_pool_identity for your site, and certificate_thumbprint if it needs HTTPS.
  3. Deploy the flow to a Windows worker group and run it once manually.
  4. Confirm the health check passes, then browse to the site to verify it end to end.

How to extend

  • Add a io.kestra.plugin.core.http.Request task to register the new site with a load balancer or reverse proxy once it passes the health check.
  • Loop provision_iis_site over a io.kestra.plugin.core.flow.ForEach list of sites to provision an entire environment in one run.
  • Add a deployment step before provisioning that copies application files into physical_path from a build artifact.
  • Extend the health check to assert on response body content, not just status code, for a deeper smoke test.
  • Swap the Slack alert for a ServiceNow or PagerDuty call if IIS provisioning is part of a formal change process.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.