I spent last week playing around with IIS 7 PowerShell provider (and cmdlets) and feel like it’s time to share my experience and provide feedback to the IIS team.
Overall my experience was pretty bad. I found the provider and cmdlets not really making administration any easier, being hard to understand and use, error prone and sometimes even dangerous. The PowerShell provider is currently Technology Preview 1, so I hope my feedback is timely and things can still be changed.
In a nutshell, similar to SQL, IIS 7 PowerShell provider has the provider: exposing sites and application pools - and 16 cmdlets.
I am not sure what is the value of the provider because the structure of the namespace is actually not dynamic (like for example AD or file system) but fixed to this hierarchy:
IIS:\
Sites
Site Collection
Applications and Virtual Directories
AppPools
WorkerProcesses
In my opinion, in that case, provider has no real value, because cd iis:\\sites is not any easier than get-site. Actually it is worse, because get-site could have additional parameters for filtering like for example get-site -running -author Dmitry.
Working with object properties is even more painful. Just getting them is a weird process of traversing an unknown XML structure. For example, let’s say you would like to know which ports are your site listening, or various connection limits, or log file information - these are all hidden as elements of child collections inside the objects.
You cannot use: get-site | format-table Name, Port, *limit*.
Instead you have to use something like:
$site = get-item SiteName
$site.bindings.Collection[0].bindingInformation
$site.limits.maxBandwidth
$site.limits.maxConnections
$site.limits.connectionTimeout
Getting this into a table for multiple sites is sure possible using the ability of format-table to accept custom columns with expression - but that’s not the syntax I find myself comfortable to use.
However, that is nothing compared to trying to change any settings. For my demo I wanted to change all my sites with int* prefix currently listening to port 80 to use 8080 instead. Well, first of all I had to just use dir int* because adding filtering by bindings would have made my code too hard to follow for the demo, but then I had to do something like:
dir int* | Set-ItemProperty -Name bindings -Value @{protocol="http"; bindingInformation="8080"}
Not only typing this is a pain (why not have: Set-Binding -Protocol Http -Port 8080 ?) the code actually damaged my lab because it turned out that the sites also had custom URLs they were using and these got deleted, so the sites got assigned to localsystem and were stopped due to a conflict.
Because most of the properties are organized that way - as various property hash tables and hierarchical structures - changing anything is a pain.
And these are basic scenarios. Even creating a site requires you to use this awful hash-table syntax:
PS IIS:\Sites> New-Item iis:\Sites\TestSite -bindings @{protocol="http";bindingInformation=":80:TestSite"} -physicalPath c:\test
Changing any configuration properties again requires you to use some weird filter path specifying how to get to that property. Can someone really type this?
PS IIS:\Sites\DemoSite\DemoApp> Set-WebConfigurationProperty -filter /system.webServer/security/authentication/windowsAuthentication -name enabled -value true
Bulk operation require using XPaths and are completely beyond my comprehension:
PS IIS:\Sites\DemoSite\DemoApp> set-webconfiguration "/system.webServer/handlers/add[@path='*.aspx']/@path” -value “*.mspx”
I am not a web admin - so there is a chance that I am just wrong in my assumptions, and all the examples above are absolutely intuitive for any web guy. However, I find them all magnitudes more complex than Exchange or AD cmdlets, and I have a suspicion that for some reason the IIS team simply decided not to spend time looking at these examples or documenting the use case and designing for them, but instead simply looked for the easiest way to expose their xml config files via PowerShell.
To me the goal of PowerShell is making IT automation easy. And to me this does not look easy at all. In fact I think all these @{} scared a lot of folks watching my demo at the ReMIX last Friday.
In the documentation, Thomas Deml is saying that the reason for this hash-table approach is that IIS configuration is flexible and fully extensible. I am not sure this is an excuse. AD is also extensible and its objects can have any elements you add when extending the schema. However, there are ways to handle that. For example for AD cmdlets, we are exposing all frequently used and standard elements as properties and cmdlet parameters and have additional parameters such as -ObjectAttributes for those extended ones.
I really hope that it is not too late to redesign the IIS snapin with real use cases in mind and make it more Exchange/AD/DPM-like. Thomas does mention a couple of times that they “are thinking about wrapping some typical tasks like creating sites with additional functions or scripts in a later Tech Preview.” however, I am afraid that just adding a few scripts will not solve the issue - scripts are second-class citizens compared to cmdlets and just adding a few of them will not solve the overall complexity problem.
Guys, please re-use the expertise from other teams. Talk to Vivek Sharma or Evan Dodds, talk to the PowerShell team, or PowerShell community folks (like QAD cmdlets guys). Many people have been on similar tasks before and will be happy to share their experience.
On the positive side, Thomas has actually done a fantastic job documenting the current state of the provider in his series of step-by-step tutorials at iis.net - I highly recommend these walkthoughs if you want to get started.
The current status of the snapin is Technical Preview, so hopefully this all is out to collect our feedback and I hope others chime in and give the IIS team good feedback from their side. IIS 7 is overall a great step forward compared to IIS 6. The team is clearly listening to community feedback so let us be vocal here as well.
Tags: IIS, PowerShell
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |
and 
Subscribe by email
