none
PoSh: Setting IIS AppPool username/password credentials works through the shell but through when the exact same commands are passed through GUI?

    Question

  • Code in question:

    $username = 'testuser'
    $password = 'somepassword'
    $iisActionUpdateCmd = {
    			param($username,$password)
    								
    			Import-Module WebAdministration
    		
    			$apppools = (Get-Item iis:\apppools).Children.Keys
    			
    			$apppools | % {
    				$apppool = Get-Item iis:\apppools\$_
    				if (($apppool.processModel.username) -match $username) {
    					$apppool.processModel.password = $password
    					$apppool | Set-Item
    					"$($apppool.Name)"
    				}
    			}
    		}

    - Running it directly from my workstation's shell using Invoke-Command to execute on the IIS server works without error
    - Using Enter-PSSession and pasting the code interactively into the IIS server's shell works without error
    - RDPing into the IIS server and pasting the code directly into the shell on the server works without error

    - Running this exact code from my GUI does properly set the password but throws this error:

    I can prevent it by commenting out the Set-Item line but then the password doesn't get set.  Does anyone have any idea why this might be happening or be able to offer any insight as to how I could lock down the cause of this error?  TIA.

    Wednesday, February 29, 2012 9:11 PM

Answers

  • I got a chance to jump in and run some tests.

    On IIS 7 on WIndows 7 remote I cannot remotely set the password.  I get a 'READ-PNLY' violations with a warning that only IIS Service Manager can set the password.

    Some items are not remote able and some require extra steps.

    help wsman - pay attention to the extra switches for standard commands like get-item when used with remoting.

    I think the issue is more related to remoting than to threading.


    ¯\_(ツ)_/¯

    Thursday, March 01, 2012 5:27 PM

All replies

  • Some modules and CmdLets are not compatible with teh GUI if you refering to the PowerShell ISE.  Yhis has to do with threading models.

    Have you tried using Set-WebConfigurationProperty?


    ¯\_(ツ)_/¯

    Wednesday, February 29, 2012 10:50 PM
  • no jrv -- I apologize for not being more clear.  the gui to which i was referring was a windows forms gui i am creating.  i just meant that on the press of a button, this script block is executed by invoke-command on a remote machine; theoretically the exact same way i'm doing it manually.  i'm just trying to figure out why the error is occurring through my GUI and not from the shell even though I can literally copy/paste the code from one to the other and get different results.  and yes, i did look at Set-WebConfigurationProperty but did not see a way to set the apppool username and/or password through it which is why i was attempting to use the IIS drive.  are you saying that you know that the apppool username and password can be configured using that cmdlet?
    Thursday, March 01, 2012 1:37 AM
  • If in a GUI you are likely in a different threading model.

    Try saving the script on the remote machine and executing the script with the invoke.  This might provide new information.

    When you are in a Form you are in a new thread and it may have issues with access to some  functions. 

    I don't know that this is the case but it is a question worth considering.


    ¯\_(ツ)_/¯

    Thursday, March 01, 2012 1:46 AM
  • It doesn't appaear to be the threading model.  I switched it from MTA to STA and get the same results.  Sorry about the large picture.

    Thursday, March 01, 2012 12:48 PM
  • You said you were launching your remote session from teh GUI?  The GUI cannot change its threading model. 

    No one can read the iimage as it is way to compresssed amd hard to read even at 200% magnification.


    ¯\_(ツ)_/¯

    Thursday, March 01, 2012 3:43 PM
  • So I was simply executing a powershell environment using the -STA switch to specify single-thread apartment (I'm assuming you were talking about threading in the context of MTA vs. STA).  And then executing my powershell file from that STA shell and retried the process. 

    and i was able to work around the gui changing it's threading model by using:

    if ([threading.thread]::CurrentThread.GetApartmentState() -eq "MTA") {
    		& $env:SystemRoot\system32\WindowsPowerShell\v1.0\powershell.exe -sta $MyInvocation.ScriptName
    		exit
    	}

    ...which has appeared to work for me in previous projects.

    and yes, in my previous post, all i see is a red X where the image used to be.  I'll try to reupload it but not sure if that will help.

    Thursday, March 01, 2012 3:52 PM
  • You are running from a local version of PowerShell and connecting to a remote shell?  Is that correct?

    You cannot easily connect and control the threading model of the remote shell.

    I would test this but the test system that has the setup for WebAdministration is in use for somtething else until tomorrow so I cannot run WebAdministration remotely.


    ¯\_(ツ)_/¯

    Thursday, March 01, 2012 4:24 PM
  • yea -- you are absolutely right jrv.  i wasn't thinking about the shell that gets invoked on the remote server.  and i executed powershell with -sta and then enter-pssession to the remote machine in question and ran the query of the apartmentstate and it is still MTA so this would agree with what you were saying.  I will try executing the script locally on the machine and see what happens.
    Thursday, March 01, 2012 4:36 PM
  • I got a chance to jump in and run some tests.

    On IIS 7 on WIndows 7 remote I cannot remotely set the password.  I get a 'READ-PNLY' violations with a warning that only IIS Service Manager can set the password.

    Some items are not remote able and some require extra steps.

    help wsman - pay attention to the extra switches for standard commands like get-item when used with remoting.

    I think the issue is more related to remoting than to threading.


    ¯\_(ツ)_/¯

    Thursday, March 01, 2012 5:27 PM
  • thanks for the help jrv.  i'll post back any new information.
    Thursday, March 01, 2012 6:11 PM