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. 1. Record rollout scope and ownership: Capture change ticket, hostname, site name, site FQDN, expected port/protocol, environment, business owner, technical owner, and support contact. Record whether the launch is HTTP only or requires HTTPS and certificate binding. Note the approved maintenance window, rollback decision point, and outage/impact expectations.
2. 2. Verify IIS role and required components are present: Confirm the Web-Server role is installed on the target host. Record any required IIS features for the application such as Static Content, ASP.NET, Windows Authentication, Request Filtering, or Management Tools. If missing components are found, stop and return to the approved build/install step before launch.
3. 3. Confirm site content path and permissions: Record the full physical path for the site content and confirm the expected files exist, including a test page or default document. Verify the folder is not a temporary operator path and matches the approved application layout standard. Capture the intended application pool identity and verify that identity has read access to the content path and any required upstream shares or local folders.
4. 4. Validate IIS site, bindings, and app pool settings: Record the IIS site name, state, physical path, application pool name, and application pool identity. Validate the binding host header, port, and protocol match the approved DNS name and rollout plan. For HTTPS launches, record certificate subject, thumbprint, expiration date, and binding assignment. Check that the site does not conflict with existing bindings on the host.
5. 5. Validate DNS and perform functional test: Resolve the site FQDN and record returned IP addresses. Confirm the resolved address maps to the intended IIS host or load balancer path for the maintenance window. Browse to the internal URL or use Invoke-WebRequest and capture HTTP status, page title, or known test string from the validation page. If the site depends on integrated authentication, test from a permitted workstation or service context and record the outcome.
6. 6. Capture rollback and handoff notes: Document the previous state if replacing an existing site: prior bindings, prior content path, prior app pool identity, and original DNS target. Record rollback trigger conditions such as failed health check, authentication failure, wrong content, or binding conflict. Add post-launch support notes: log path, app pool name, owner contacts, and next validation checkpoint.

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
• operator-notes

Command Starter

Safe to run: read-only

Get-WindowsFeature Web-Server | Select-Object DisplayName, InstallState
Import-Module WebAdministration; Get-Website | Select-Object Name, State, PhysicalPath, Bindings
Import-Module WebAdministration; Get-ChildItem IIS:\AppPools | Select-Object Name, State, @{n='IdentityType';e={$_.processModel.identityType}}, @{n='UserName';e={$_.processModel.userName}}
Get-ChildItem -Path '<SitePath>' | Select-Object Name, Length, LastWriteTime
Resolve-DnsName <SiteFQDN> | Select-Object Name, Type, IPAddress
Invoke-WebRequest -Uri 'http://<SiteFQDN>' -UseBasicParsing | Select-Object StatusCode, Headers

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.