Cannot create IIS application pool from powershell script

rklingelheber

I'm trying to create a deploy.ps1 script that will create an IIS application pool and configure it. The script works as expected when run from a powershell prompt, but fails with the following error when executed from a DM deployment:

2013-01-08 19:27:27 DEBUG ERROR: Test-Path : Cannot retrieve the dynamic parameters for the cmdlet. Retrieving the COM class factory for component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
ERROR: At C:\ProgramData\Red Gate\DeploymentAgent\Applications\Test\MyPackage\1.0.3_1\deploy.ps1:15 char:16
ERROR: + if ( (test-path <<<< -path $virtual) -eq $True )
ERROR: + CategoryInfo : InvalidArgument: (:) [Test-Path], ParameterBindingException
ERROR: + FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.PowerShell.Commands.TestPathCommand

Here is the script:

import-module WebAdministration

$apppool = "iis:\apppools\Sample"
if ( (test-path -path $apppool) -eq $False )
{
	write-host "creating apppool"
	new-item $apppool
}

Also note that I have changed the DM agent to run as an administrator on the machine.

Thanks!

chirayu

Hi

My initial thought is that this is due to the difference in bitness i.e. the bitness (64 bit/32 bit) of powershell prompt is different to the bitness of the agent.

The deployment agent used to be 64 bit, it has now become 32 bit. So the bitness of the agent depends on which version of the agent you have installed. (It can be checked by running Task Manager).

I should also mention that someone on StackOverflow dealt with a similar problem: http://stackoverflow.com/questions/6866 ... pplication.

In order to help you further, would you please confirm if the bitness is in fact different for the two places that you are running the script? If that is the case, what is the bitness of your agent and the platform where you run it on powershell prompt?

Thanks!

rklingelheber

I believe you are correct about the Powershell bitness. If I run the script in a 32 bit PS prompt it fails. If I run the script in a 64 bit PS prompt it succeeds. I was unknowingly launching a 64 bit prompt when I selected "Import system modules" from the PS shortcut context menu.

I verified that the DM agent is running as a 32 bit app. DM server is 64 bit.

I would like to be able to manipulate IIS from Powershell deployment scripts if possible. Is there a way to tell the agent to host Powershell as a 64 bit host? If not, is there a work-around for this issue?

Thank you.

Brian Donahue

I found this...
http://www.mattwrock.com/post/2011/01/0 ... ssues.aspx

Basically it says to ditch the WebAdministration module and use Microsoft.Web.Administration.

chirayu

@rklingelheber: How are you getting on with Deployment Manager? Did you manage to solve the problem using Microsoft.Web.Administration module?

rklingelheber

I tried to use the Microsoft.Web.Administration module, but it was modifying IIS Express instead of IIS on my development box.

There may be a way to get that to work, but I gave up on it for now and am exe-ing out to our old NAnt scripts just to prove automated deployment concept to folks in the office.

I think that if Powershell is the core scripting mechanism for DM, that it should support the Powershell IIS commandlets without work arounds. For folks that are deploying web apps and services, they are going to want a lot of control around this area - and it shouldn't be hard.

ashars

Hey rklingelheber,

I can certainly empathize with the frustration you're experiencing while trying to create an IIS application pool from a PowerShell script. The error message you're encountering, related to COM class registration, can be quite perplexing.

From what I gather, it seems that the issue might be related to the execution context of your script within the DM deployment environment. You mentioned changing the DM agent to run as an administrator, which is a step in the right direction.

Here's a suggestion: Ensure that your DM deployment environment has the necessary permissions and configurations to access the IIS components. You might want to check if the required COM components are registered correctly on the deployment machine. Try running the script with elevated privileges to see if that resolves the issue.

As for your use of NAnt scripts as a workaround, it's a pragmatic choice when facing time constraints. However, it's ideal to have PowerShell seamlessly interact with IIS for smoother automation.

I agree that PowerShell should indeed offer better support for IIS operations without workarounds. It's essential for efficient web application deployment. Keep digging into the DM deployment environment settings, and you might just uncover the root cause of this hiccup.