How to Manage IIS in PowerShell 7: Solutions for Get-IISAppPool and Get-IISSite Compatibility Issues

Managing IIS in PowerShell 7 can cause errors with Get-IISAppPool and Get-IISSite due to module incompatibility. This guide explains why these issues occur and offers two solutions: using Microsoft.Web.Administration .NET API in PowerShell 7 or switching to Windows PowerShell with the IISAdministration module for seamless IIS management. Unique :

Managing IIS in PowerShell 7: What You Need to Know

If you’re a sysadmin or developer managing Internet Information Services (IIS), you probably rely on PowerShell commands like Get-IISAppPool and Get-IISSite.

However, PowerShell 7 (PowerShell Core) introduces compatibility headaches with IIS modules. This causes errors and breaks your usual workflows.

The Compatibility Problem with PowerShell 7

PowerShell 7 uses .NET Core, while IIS modules like IISAdministration and WebAdministration depend on the older .NET Framework. This mismatch causes commands to fail.

For example, running Get-IISAppPool in PowerShell 7 might throw this error:

“Get-IISAppPool: The term ‘Get-IISAppPool’ is not recognized as a name of a cmdlet, function, script file, or executable program.”

Additionally, importing the WebAdministration module triggers warnings about deserialized objects, which can hurt performance and reliability.

How to Fix It: Two Practical Solutions

Use Microsoft.Web.Administration API in PowerShell 7

Instead of relying on incompatible modules, directly tap into the Microsoft.Web.Administration .NET API. This method works natively in PowerShell 7 without compatibility layers.

Simply load the assembly and use the ServerManager class to list application pools or websites. Here’s a snippet to list app pools:

Add-Type -Path "C:\Windows\System32\inetsrv\Microsoft.Web.Administration.dll"
$serverManager = New-Object Microsoft.Web.Administration.ServerManager
$appPools = $serverManager.ApplicationPools
$appPools | ForEach-Object { Write-Output "App Pool: $($_.Name), State: $($_.State)" }

This approach bypasses the old IIS modules and offers full PowerShell 7 compatibility.

Stick to Windows PowerShell 5.1 for Native Modules

If you prefer the classic IISAdministration module, run your scripts in Windows PowerShell 5.1 instead. It’s fully compatible and avoids the deserialization issues.

Make sure to:

Run PowerShell as Administrator
Enable IIS management features via DISM commands
Install and import the IISAdministration module

Then, commands like Get-IISAppPool and Get-IISSite will work as expected.

Best Practices for Production

Before applying these fixes in production, test in a staging environment. Enabling IIS features might require a server reboot.

Also, back up your IIS configuration using appcmd.exe to avoid surprises.

“Always test scripts in a staging environment before running them in production.”

Running PowerShell with admin rights is crucial for IIS management tasks. Schedule maintenance windows if reboots are necessary.

Wrapping Up

PowerShell 7 shakes up IIS management by breaking old module compatibility. But the good news is, you have solid options.

Use the Microsoft.Web.Administration API for a modern, PowerShell 7-friendly approach. Or, stick with Windows PowerShell 5.1 for native module support.

Either way, you’ll keep your IIS management scripts running smoothly without frustrating errors.

PowerShell 7 uses .NET Core, causing compatibility issues with IIS modules designed for .NET Framework.

Get-IISAppPool and Get-IISSite commands fail natively in PowerShell 7 due to deserialized objects in compatibility sessions.

Directly loading Microsoft.Web.Administration.dll enables IIS management in PowerShell 7 without module errors.

Windows PowerShell 5.1 fully supports IISAdministration module, offering native cmdlets for IIS management.

Best practices include testing scripts in staging, backing up IIS configs, running PowerShell as admin, and scheduling reboots if needed.

From the New blog articles in Microsoft Community Hub