Windows Server 2025 / How IIS Bindings and Application Pools Work

An IIS binding selects a site using protocol, IP address, port, and host name. An application pool provides the process and identity boundary for its applications. DNS, bindings, content folders, and pools must each be configured correctly.

Distinguish the four configuration layers

A DNS record does not create an IIS binding, and a binding does not register DNS. Check conflicts against the IP, port, and host combination in the IIS binding reference.

Start with the working WEB1 LabSite at 172.24.50.30:8080. Record existing bindings before changes. This exercise adds two private lab names without changing public DNS or a production website.

Add and verify the DNS names

1. On DC1, open the existing lab.example.test forward lookup zone in DNS Manager.
2. Create host A record web pointing to 172.24.50.30.
3. Create status pointing to the same address.
4. Confirm CLIENT1 uses DC1 for internal DNS.
5. Query both names and verify the returned address.

Resolve-DnsName web.lab.example.test -Server 172.24.50.10
Resolve-DnsName status.lab.example.test -Server 172.24.50.10

lab.example.test is the separate course DNS zone, not the AD domain ad.example.test. A file-based zone does not automatically replicate to DC2. If the zone is missing, verify the intended server and earlier zone configuration before adding records.

Give the first site its host-name binding

1. In IIS Manager → LabSite → Bindings, select http / .30 / 8080 with the empty host name.
2. Edit its host name to web.lab.example.test.
3. Check that no duplicate binding remains.
4. On CLIENT1, open http://web.lab.example.test:8080/.

An HTTP Host header is not user authentication. Knowing the configured name does not establish a user’s identity. Direct IP access may behave differently after this change, so test the site using its intended name.

For failure, check that DNS returns .30, then compare the requested port and host name with the binding. Do not replace internal DNS with public DNS or broadly disable the firewall.

Create the second site with its own identity

1. Create a new C:\Sites\StatusSite folder and an index.html page with a distinct StatusSite message.
2. Create StatusSitePool with No Managed Code and ApplicationPoolIdentity.
3. Grant IIS AppPool\StatusSitePool Read & execute on its folder, retaining SYSTEM and administrator access.
4. Create StatusSite using that folder and pool.
5. Bind http / 172.24.50.30 / 8080 / status.lab.example.test.
6. Set its anonymous authentication to Application pool identity.
7. Browse to both names from CLIENT1 and compare their distinct page contents.

Two sites can share an IP and port when host names distinguish them. Do not duplicate the complete binding combination. Review any remaining empty-name binding and the requests it can receive.

Separate pools make identity, stopping, and recycling easier to control. They still share the OS, kernel, storage, and host resources; they do not provide the same boundary as separate VMs. Apply the minimum resource access described in application pool identity guidance.

Compare stopping and recycling

1. Record both sites’ successful responses and pool states.
2. Stop only the lab StatusSitePool.
3. Send fresh requests to both names and record the difference.
4. Restart StatusSitePool and confirm recovery.

The stopped pool’s site can return 503 while LabSite in its separate pool should still be checked for normal operation. Shared resource exhaustion remains possible. Verify whether you are stopping a site or a pool before choosing the action.

Recycling creates a replacement worker process and can affect in-memory sessions and ongoing work. A static-page observation does not guarantee an application’s uninterrupted service. Cleanup should target only the added site, pool, and DNS records; retain LabSite’s name binding if continuing with HTTPS.