10

I was trying to set IIS properties for my DefaultAppPool via PowerShell and I end up with a really curious case:

  • Get-ItemProperty is case insensitive.
  • Set-ItemProperty is case sensitive.

Does someone know why we have this curious behaviour?

PS C:\Windows\system32> Import-Module WebAdministration    
PS C:\Windows\system32> Get-ItemProperty -Path "IIS:\AppPools\DefaultAppPool" -Name Recycling.periodicRestart.privateMemory

...
Value                       : 27

PS C:\Windows\system32> Set-ItemProperty -Path "IIS:\AppPools\DefaultAppPool" -Name Recycling.periodicRestart.privateMemory -Value 10

PS C:\Windows\system32> Get-ItemProperty -Path "IIS:\AppPools\DefaultAppPool" -Name Recycling.periodicRestart.PrIVATeMemory

...
Value                       : 10

PS C:\Windows\system32> Set-ItemProperty -Path "IIS:\AppPools\DefaultAppPool" -Name Recycling.periodicRestart.PRIvateMemory -Value 15

PS C:\Windows\system32> Get-ItemProperty -Path "IIS:\AppPools\DefaultAppPool" -Name Recycling.periodicRestart.PrivateMemory

...
Value                       : 10 #should be 15 if case insensitive...
Richard Neish
  • 8,414
  • 4
  • 39
  • 69
LeBaptiste
  • 1,156
  • 14
  • 20
  • 6
    As far as I'm aware, `Get-ItemProperty` and `Set-ItemProperty` use the *provider's* methods. The registry provider, for example, is case-insensitive for both cmdlets. You'd have to contact the IIS team about the issue, or log it in MS Connect. After hell freezes over, you might get a response... but it will probably be WONTFIX. [You're not the only one](http://johan.andersson.net/2009/08/20/note-to-self-windows-is-getting-sensitive-with-the-iis-powershell-provider/) to notice the issue, however. – Bacon Bits May 11 '15 at 15:28
  • More than to be case sensitive/case insensitive, I was really surprised by the lack of consistency between Get/Set for a same property. I spotted this issue at the end of a quite long test process because I would not have expected this scenario possible... I will raise a support ticket to know more about it. – LeBaptiste May 12 '15 at 10:07
  • My guess is that since the destination is really an XML file, it is case sensitive. – Eris Jul 10 '16 at 20:23
  • Me too faced this issue. Weird – Samselvaprabu May 18 '17 at 05:12
  • `filter left, format right`... **Get-Blah** will always deliberately throws a broad net, and then you add the filters (such as in your case, it's actually sayng `name like xxx`). **Set-Blah** is usually the opposite, where even wildcards might not work by default. Maybe your last `set-xyz -v 15` is actually error'ing due to *property not exist*, and we just think it should be using a vague filter such as your get-statement – Hicsy Dec 04 '17 at 01:54
  • Our expectation of "normal" is backed up by the likes of Regedit, where `set-itemproperty -n xxxx -v yyy` will perform an update case-insensitively... and if you put in a totally wrong name for that property it will error saying `no such property`. I would start by seeing if you CAN make 2 properties with different case `new-itemproperty -p xx -n yy -v jj; new-itemproperty -p xx -n YY -v kk`. If this worked, then the **set** command is probably correct. If it fails due to *already exists* (or overwrites the other capitalisation) then change filter, like `get/set-xxx -filter "name -cmatch XX"` – Hicsy Dec 04 '17 at 02:08
  • .ToLower() is your friend :) – Lord Helmet Aug 19 '21 at 17:21

4 Answers4

1

Cmdlets G(S)et-ItemProperty delegate the work to the methods from PSProvider (IIS in this case) from the WebAdministration module. This case discrepancy is a bug IIS method implementation.

The IIS PSProvider is full these surprises.

An alternative to the WebAdministration is the IISAdministration module, but this module doesn't have 100 % feature coverage of the WebAdministration module.

KUTlime
  • 5,889
  • 1
  • 18
  • 29
  • 2
    That's exactly why everyone should move to IISAdministration whenever possible, https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/iisadministration-powershell-cmdlets – Lex Li Nov 13 '21 at 21:10
1

Adding a bit more context to this fairly old question:

In PowerShell, you can implement a provider so that users can browse to and alter any hierarchical structure. Each provider is slightly different.

The IIS provider essentially abstracts the XML file(s) used by IIS to configure a server. Because such a large ecosystem exists/existed around IIS configuration XML, it made a lot of sense to implement the provider to work directly with this system, rather than create a slightly divergent form of it that would require additional maintenance over time.

PowerShell, as a language, is case-insensitive. Not all of the systems PowerShell communicates with are so forgiving. Because IIS's configuration is XML, it is case-sensitive. While Get-ItemProperty can work around this fairly easily, Set-ItemProperty has to set the XML in the exact case that it was passed in.

There are a few other spots you might run into this sort of "error":

  1. On Linux, file names are case-sensitive (thus you run into this when trying to get/set a file by name with the wrong case)
  2. JSON is case-sensitive. You can easily convert any object in PowerShell to JSON, but if the system it works with was case-sensitive, the JSON will not work as expected.
  3. The same is true for YAML.
  4. The same is true for XML.
  5. When dealing with a C# api that accepts strings, one has no clue if the underlying calls will care about the case sensitivity of those strings.

So you'll run into this category / class of bug a few places. They are likely to present when PowerShell (a case-insensitive language) works with technology that is likely to be case-sensitive (like: JSON, YAML, or XML).

Start-Automating
  • 8,067
  • 2
  • 28
  • 47
0

Have you ever noticed that, in Windows, if you rename a file by only changing the case that the file does not actually change the name (the case does not change)? Likely there is a similar design choice going on. Unlike Linux, who treats myFile.txt and MyFile.txt as two separate file, Windows will treat them as a name conflict. Similarly, Linux will only autocomplete names if their casing matches, Windows will autocomplete regardless of casing.

What Windows is likely converting to all lowercase or all uppercase for the comparisons, but then using the original value when writing (and does not write the name unless the name changes for a performance benefit). So you can have whatever casing you want when you first create the name, but then that casing sticks unless the name is more radically changed; but then any casing works for retrieval. It is, essentially, case-insensitive all the time, but without forcing the names to always show as one case so they can be more user-friendly.

carrvo
  • 511
  • 5
  • 11
-5

"Get" statements in POSH are for data gathering and object building/logic orchestration. In other words, a "Get" X command is never going to alter a configuration file that has a service counting on case sensitivity (with all the snap-ins out there, who knows what service has a POSH abstraction). "Set" commands are almost holistically used to alter the system or configuration of the system they are run on (or remote with WMI/WinRM).

Charliecamelcase
  • 1
  • 1
  • 1
    Use formatting tools to make your post more readable. Code block should look like `code block`. Use **bold** *italics* if needed. – Morse Jun 06 '18 at 01:00
  • 1
    This is a technically correct statement as a matter of convention but does nothing to explain case-sensitivity issues for provider-flexible cmdlets. – codewario Oct 27 '21 at 20:05