Why does Set-ItemProperty have no effect for IIS applications under Windows 10?
Asked Answered
D

3

20

Most of our web applications include a Deploy.ps1 Powershell script. Octopus Deploy uses this to configure apps during production deployments, but we also use it to set up developers' local IIS settings. Works absolutely fine on Windows 7, Windows 8.1, and on all our Win2012 production servers.

It's not working on Windows 10, and this appears to be because the Set-ItemProperty cmdlet has no effect. No error message or anything, it just doesn't do anything.

The IIS site api.example.com already exists, and we're using Powershell to create the /myapp application and then change the application's physical path to D:\Projects\Demo

PS C:\> IIS:
PS IIS:\> cd Sites\api.example.com
PS IIS:\Sites\api.example.com> New-WebApplication myapp -site api.example.com -PhysicalPath C:\inetpub\wwwroot

Name             Application pool   Protocols    Physical Path
----             ----------------   ---------    -------------
myapp            DefaultAppPool     http         C:\inetpub\wwwroot

PS IIS:\Sites\api.example.com> set-itemproperty myapp -name PhysicalPath -value D:\Projects\Demo

PS IIS:\Sites\api.example.com> get-itemproperty myapp

Name             Application pool   Protocols    Physical Path
----             ----------------   ---------    -------------
demo             DefaultAppPool     http         C:\inetpub\wwwroot

                                                 ^ THIS IS WRONG!

Running the exact same set of commands on Windows 7, you get identical output but at the last step the PhysicalPath property has changed as expected:

PS IIS:\Sites\api.example.com> get-itemproperty myapp

Name             Application pool   Protocols    Physical Path
----             ----------------   ---------    -------------
demo             DefaultAppPool     http         D:\Projects\Demo

Any idea what's going on? Is there some new admin restriction on IIS10? Some sort of extra elevated permissions I need to modify settings on existing web applications or something?

UPDATE: It seems to work fine if the item is an IIS site, but fails if the item is a web application, which makes me wonder if this might just be a bug in the provider. Any ideas?

Discolor answered 8/4, 2016 at 17:40 Comment(1)
It's a bug, please vote up. windowsserver.uservoice.com/forums/301869-powershell/…Pede
L
25

I don't know why but the first letter of the property you want to set must be lowercase e. g. physicalPath

This will work:

set-itemproperty myapp -name physicalPath -value D:\Projects\Demo

Seems like a bug to me but this notation (first letter lowercase) also works for your other Windows environments thus should be a valid workaround.

Langer answered 26/4, 2016 at 8:17 Comment(1)
Related and answered by same person :) : #38186601Pede
F
4

I was able to replicate your problem. Set-ItemProperty worked for me if I was working on a site.

These cmdlets are from the WebAdministration module and I have checked the complete documentation. They seems to be using only websites in the relevant examples. You can also check the same, if you haven't already, here: Web Administration (IIS) Provider for Windows PowerShell

As you pointed, it maybe a bug. I would recommend to report this here: Microsoft Connect - PowerShell

Fugal answered 25/4, 2016 at 18:36 Comment(1)
Connect is replaced with windowsserver.uservoice.com/forums/301869-powershellZerelda
E
-1

This works for me (without Set-Location):

Set-ItemProperty IIS:\sites\$sitename\$appName -Name applicationPool -Value $appPoolName
Evidentiary answered 11/4, 2016 at 5:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.