Why / How is ManagedPipelineMode different from when you install?

While trying to write some scripts to manage our IIS sites, I came across some weird behavior with ManagedPipelineMode in IIS. My code is pretty general and uses Get-ItemProperty to read the old value, and then Set-ItemProperty to update it if that is not the value we want.

However, if I ran this:

Get-ItemProperty "IIS:\AppPools\MyAppPool" "managedPipelineMode" 

I am returning the string Classic . However, if I ran this:

 Set-ItemProperty "IIS:\AppPools\MyAppPool" "managedPipelineMode" "Classic" 

I am returning the Classic is not a valid value for Int32 error.

So, I know that I can set the value using ([int][Microsoft.Web.Administration.ManagedPipelineMode]::Classic) , but I don’t understand why the type seems different when using Get-ItemProperty vs Set-ItemProperty , or how I can request this to behave consistently.

Note. I really don't want to put a special case for ManagedPipelineMode, since every other property seems to behave as expected. So, two questions:

  • What kind of strange behavior is this that allows you to assign the string property when reading, but int when setting? Does this apply to all transfers?
  • Is there a way to read / write this property using the same type, so I can write code that can read the value, check if we want it, and if not, update it?
+4
source share
2 answers

Use the following values: 0 = Integrated; 1 = Classic

 Set-ItemProperty "IIS:\AppPools\MyAppPool" "managedPipelineMode" "1" 
+2
source

Try using

 Set-ItemProperty -Path:'IIS\AppPools\MyAppPool' -Name:'managedPipelineMode' -Value:Classic 

Note the absence of quotes in Classic

Notes: I prefer to call argument names specifically so that later there is no confusion, and if they update / modify the command, nothing strange happens

I also use the colon anchor operator. It is absolutely clear that the meaning belongs to the argument of this name.

0
source

Source: https://habr.com/ru/post/1442098/


All Articles