IIS 7 Administration via PowerShell
I have been experimenting off and on with PowerShell and IIS 7 and have blogged a number of times about over the last 6 months. I was thinking about the demos I want to run in the talks I'm giving in October - http://richardsiddaway.spaces.live.com/default.aspx?_c01_BlogPart=blogentry&_c=BlogPart&handle=cns!43CFA46A74CF3E96!1575 - and IIS 7 has a number of useful features for demos.
I want to do as much of the demos as possible remotely - as if it were true data centre environment and that made me realise just how many ways you can interact with IIS 7 through PowerShell.
.NET managed code - Using the Microsoft.Web.Administration namespace you can work locally with existing objects and create new objects. It does not appear to have the capability to work remotely.
WMI - working locally can work with existing objects and create new objects in PowerShell version 1 and 2. If you want to work remotely through WMI with existing objects you need to use PowerShell V2 because the IIS 7 WMI Provider has implemented packet privacy which get-wmiobject in V1 can't handle. (This point is glossed over in the Windows PowerShell Scripting Guide where it is stated that you can work remotely.)
Creating new objects remotely via WMI is a bit awkward in that [WMIClass] doesn't work with the packet privacy of the provider and Set-WMIInstance in PowerShell V2 CTP2 does not seem to work with the IIS WMI provider. It is possible to use the .NET classes directly instead of [WMIClass] and that seems to work OK remotely.
IIS Provider works with existing and new objects locally. Does not have a remote capability.
IIS cmdlets works with existing and new objects locally. Does not have a remote capability.
In summary - working locally you have four (4) ways to work with IIS 7 in PowerShell but if you want to work remotely then WMI with some assistance from .NET seems to be the way you have to go. If you are using PowerShell V2 CTP 2 you can use the remoting features to access IIS 7 as if it was local (or /n software's remote features).
This makes the need for admins to at least understand a bit of .NET even stronger.