IIS 7 PowerShell Rant

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:

                Site Collection
                       Applications and Virtual Directories

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

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: ,

9 Responses to “IIS 7 PowerShell Rant”

  1. 1 Hmm May 26, 2008 at 4:13 pm

    Way to go, dude!

  2. 2 halr9000 May 27, 2008 at 12:24 pm

    I think this is a great rant, Dmitry. They need to hear it! The point here is one encapsulated by Snover’s “semantic gap” post from several weeks ago. I think the IIS team should not be afraid to break their existing admin model a bit in order to introduce new functionality, but more importantly, to erase the complexity. Cmdlets can be so powerful–they should be doing all of the work required to make that interface work smoothly like in your format-table examples.

  3. 3 Don Jones June 23, 2008 at 6:36 pm

    Most importantly, WMI is an extensible and dynamically-defined schema, yet we get nicely-adapter, static-looking objects from Get-WmiObject. “Erase the complexity” is definitely the lesson! Make the inner workings of the cmdlet as complex as necessary to create completely intuitive and easy-to-use output. Administrators are not programmers!! http://concentratedtech.com/content/index.php/2008/06/23/powershell-iis-7-oh-no/

  4. 4 Sergei Antonov July 3, 2008 at 6:12 am

    Well, speaking about complexity… Here is an example from Quest:

    get-QADUser -SearchRoot ‘company.com/UsersOU’ -Name ‘A*’ –ObjectAttributes @{name=’B*’;title=’*manager’}

    somehow Dmitry likes hashtables in his own commands, but sooo dislikes in other people commands. This get-qaduser command has 60+ optional parameters, some has veryveryvery long names. Looking at THAT desing I am reading this rant from different perspective.

    What you saw in TP1 of IIS provider is base level functionality, platform. Goal for that was to provide 100% coverage of configuration data and methods. Today we released TP2 with number of “pedestrian” level commands build on top of this platform. You are welcome to try it. And I am always opened to suggestions, rants, etc.

    To Don Jones: WMI — extensible and dynamically-defined? Man, where did you get it from? IMHO it is very static system. Try to extend some object of schematized type, you will see it yourself.

    Take care,

  5. 5 dmitrysotnikov July 4, 2008 at 9:10 am


    Hashtables in QAD cmdlets are for non-frequently used attributes. All the frequently used ones (Name, City, Title – and so on – dozens of them) are exposed as cmdlet parameters – everything else (including custom ones added as schema extensions) can be addressed using hash-tables. So the -objectattributes parameter and hashtables provides extensibility but is not required in 90%+ of cases.

    I will definitely download your TP2 and give it a try. I hope it uses a similar approach: easy cmdlets for most frequently used stuff and some extensibility mechanisms for everything else.

    Thanks for the news!


  6. 6 Thomas Deml July 14, 2008 at 5:57 pm


    Did you have a chance to look at Technical Preview 2?

    TechPreview 1 only had the most basic Cmdlets. They allowed you to configure all IIS settings but were not very task-focused. In Tech Preview 2 we added about 40 new Cmdlets and we are planning for more in our “GoLive” release. Your feedback would be appreciated.

    Thomas Deml
    Senior Program Manager
    Internet Information Services

  7. 7 dmitrysotnikov July 15, 2008 at 3:28 pm

    Thomas, Tech Preview 2 is definitely on my To Do list. I was on vacation when it got out and hope to get back to the IIS provider/cmdlets within the next couple of weeks. What you and Sergei are saying is very encouraging!

    I will post my feedback once I have a look at the latest bits.

  8. 8 Jason April 11, 2014 at 4:50 pm

    This hasn’t changed yet, has it? I am doing Server 2012 / IIS 8.5 automation, and all I find are examples full of hash tables, including in the latest documentation of the cmdlets. It’s been what, six years since you posted this and nothing has changed? I sure wish they would have taken your advice. I’m a web guy and I’ve been doing advanced administration and setting up web farms (hosting over 2000 sites) in IIS for four years, and I do not find this syntax easy at all. It doesn’t feel much better than just using XML cmdlets with XPath and modifying the config directly… their cmdlets don’t feel like they have much functionality beyond that.

  1. 1 PowerShell + IIS 7 = Oh, no… | Concentrated Technology Trackback on June 23, 2008 at 6:33 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

My Recent Tweets


The posts on this blog are provided “as is” with no warranties and confer no rights. The opinions expressed on this site are mine and mine alone, and do not necessarily represent those of my employer - WSO2 or anyone else for that matter. All trademarks acknowledged.

© 2007-2014 Dmitry Sotnikov

May 2008

%d bloggers like this: