PowerShell gives Windows Server administrators precise control over IIS without relying on the graphical console. Scripts reduce configuration drift and allow rapid deployment of sites that use Active Directory for authentication.

The WebAdministration module remains the primary interface for managing application pools, sites, and bindings. Recent Windows Server releases continue to support the same core cmdlets while adding improved logging and certificate handling.

This post demonstrates practical commands for common tasks that hosting teams perform daily.

#Loading the WebAdministration Module

Every script begins by importing the module. The command works on both full GUI and Server Core installations.

powershell 
Import-Module WebAdministration
Get-Command -Module WebAdministration | Select-Object -First 10

#Creating Sites and Application Pools

Use New-WebAppPool and New-Website to create isolated environments. The following snippet creates a pool with .NET hosting and a site bound to port 443.

powershell 
$pool = @{Name='SitePool'; ManagedRuntimeVersion=''; ManagedPipelineMode='Integrated'}
New-WebAppPool @pool

$site = @{Name='CustomerSite'; PhysicalPath='C:\sites\customer'; ApplicationPool='SitePool'}
New-Website @site -Port 443 -Ssl

#Active Directory Authentication

Windows Authentication integrates directly with Active Directory. Enable the provider and disable anonymous access with these commands.

  • Set the authentication provider to Windows
  • Disable anonymous authentication at site and application level
  • Grant the application pool identity read access to the required AD groups
powershell 
Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/windowsAuthentication' -Name 'enabled' -Value $true -PSPath 'IIS:\Sites\CustomerSite'
Set-WebConfigurationProperty -Filter '/system.webServer/security/authentication/anonymousAuthentication' -Name 'enabled' -Value $false -PSPath 'IIS:\Sites\CustomerSite'

#Security Hardening Steps

Apply request filtering, disable unused modules, and enforce TLS 1.3 where supported. These changes are applied through configuration sections rather than registry edits.

Test each change in a staging environment before applying to production hosts.

Store the final configuration in source control so changes can be reviewed and rolled back.

Run these scripts on a schedule or through desired-state configuration tools to maintain compliance.