Internal IIS site rollout checklist

Good For

• New internal IIS site launches
• Change-ticket implementation evidence
• Single-host rollout validation
• Handoff notes for support and operations

How to Use It

1. Record the launch ticket, intended FQDN, expected protocol/port, and rollback owner before changing IIS.
2. Confirm required IIS features are present and that the expected content path, site name, and app pool are documented.
3. Capture site, binding, app-pool, and certificate evidence before rollout so rollback does not depend on memory.
4. Validate DNS and the intended HTTP or HTTPS path from the relevant client network.
5. Attach command output, screenshots where useful, and support handoff notes to the change record.

Execution Modes

• local
• remote-single-host

Inputs and Outputs

Inputs

• Target server
• Site name
• Site FQDN
• Site path
• App pool identity
• Change ticket / rollout ID

Outputs

• verbose-console
• csv
• operator-notes

Command Starter

Safe to run: read-only

# Confirm the IIS role is present before relying on site-level checks.
Get-WindowsFeature Web-Server

# Capture existing website, binding, and app-pool evidence.
Import-Module WebAdministration
Get-Website | Select-Object Name, State, PhysicalPath, ApplicationPool
Get-WebBinding | Select-Object protocol, bindingInformation, certificateHash, certificateStoreName

# Validate name resolution for the intended internal site.
Resolve-DnsName portal.contoso.internal

# HTTP validation example.
Invoke-WebRequest -Uri 'http://portal.contoso.internal' -UseBasicParsing

# HTTPS validation example for TLS-enabled launches.
Invoke-WebRequest -Uri 'https://portal.contoso.internal' -UseBasicParsing

Validation

• Web-Server role is installed and required IIS subfeatures for the application are present.
• Site appears in IIS with the expected state, physical path, host header, port, and application pool.
• DNS resolution for the site FQDN returns the expected target during the launch window.
• HTTP/HTTPS request returns the expected status and known validation content from the internal site.

Reporting

• Record a one-line launch summary: Server, SiteName, FQDN, Binding, AppPool, Identity, Result.
• Attach command output for IIS role, website listing, app pool identity, DNS resolution, and web request status.
• Export evidence to CSV for the change record with date/time and operator name.
• Include explicit pass/fail notes for DNS, bindings, authentication, and test page validation.

Safety Notes

• Use read-only validation commands before making any IIS or DNS changes.
• Do not reuse an existing host header or port without checking for binding conflicts first.
• If HTTPS is required, validate certificate subject and expiry before assigning production client traffic.
• For service or gMSA identities, confirm the exact account format and access requirements; do not guess or substitute credentials during rollout.