AppPool ISIISCosting bug.

[NassereB]

Hello,

I am having problems during upgrading an IIS AppPool that is previously installed with a SpecificUser identity (see below)

[CODE]Identity = SpecificUser
SpecificUser User Name = [_UG_BRO_IISAPPPOOL_USERNAME]
SpecificUser User Password = [_UG_BRO_IISAPPPOOL_USERPASSWORD]
[/CODE]

During upgrade the ISIISCosting custom action changes the _UG_BRO_IISAPPPOOL_USERPASSWORD property value with a wrong value and stores the data into a temp file for later use (CustomActionData)
Probably queried from IIS and encrypted (see below)

[CODE]MSI (s) (B8:18) [14:30:40:111]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIC867.tmp, Entrypoint: ISIISCosting
Action start 14:30:40: ISIISCosting.
MSI (s) (B8!DC) [14:30:40:158]: PROPERTY CHANGE: Adding _UG_BRO_IISAPPPOOL_USERNAME property. Its value is 'UltraGenda\TeamCity'.
MSI (s) (B8!DC) [14:30:40:158]: PROPERTY CHANGE: Adding _UG_BRO_IISAPPPOOL_USERPASSWORD property. Its value is 'Æë%ÞÏ'.
MSI (s) (B8:DC) [14:30:40:658]: PROPERTY CHANGE: Adding ISIISInstall property. Its value is 'C:\Windows\TEMP\IISCA4C.tmp'.
MSI (s) (B8:DC) [14:30:40:658]: PROPERTY CHANGE: Adding ISIISUninstall property. Its value is 'C:\Windows\TEMP\IISCA4C.tmp'.
MSI (s) (B8:DC) [14:30:40:658]: PROPERTY CHANGE: Adding ISIISRollback property. Its value is 'C:\Windows\TEMP\IISCA4C.tmp'.
MSI (s) (B8:DC) [14:30:40:658]: PROPERTY CHANGE: Adding IS_TEMP_PROP_IIS_CONFIG property. Its value is 'C:\Windows\TEMP\IISCA4C.tmp'.
Action ended 14:30:40: ISIISCosting. Return value 1.[/CODE]

After upgrade the AppPool is installed with the retrieved username an WRONG password.

I have tried a lot of workarounds. None of them working.

Does someone know how I can fix the problem?
Is this a ISIISCosting bug?

Many thanks,

NasB

[joshstechnij]

By default, the InstallShield IIS support stores property values for referenced properties in the registry. This is done to avoid issues during maintenance or uninstall when properties would normally not have their original first-time install values, which can cause the installation to abort due to errors when trying to configure IIS items that reference these properties.

To prevent the IIS support from using the registry to resolved property values, you should be able to set the IS_IIS_DO_NOT_USE_REG property in your project (to any non-empty value). Note, though, that you will need to manually maintain the values of properties used in website port numbers, IP addresses, or site numbers, and website, virtual directory, and application names. If any of these items references a property during first-time install and the property is not set on a maintenance install, an error when trying to configure that item can occur.

Please see the help topic "Using Windows Installer Properties to Dynamically Modify IIS Settings" for more information.

[Branedal]

Hi

I reported this password bug during this spring and got a job number IOB-000060489. Have requested an update of the status today.

As a workaround you can call appcmd right after ISIISInstall to set the password your self, but then you have to know the password or detect it in some way...
You also have to stop the app pool before the upgrade as the faulty password might cause the app pool to get in a faulted state if IIS detects it is not working...

Exampe of deferred custom action command:
inetsrv\AppCmd.exe set apppool /apppool.name:"[APP_APPPOOL_MENU]" -processModel.identityType:SpecificUser -processModel.userName:"[APP_WU_COMMON_DOMAIN]\[APP_WU_COMMON_USER]" -processModel.password:"[APP_WU_COMMON_PWD]"

Regarding IIS properties, ISIISInstall should only affect what it is told in InstallShield to set. Other settings must be left as is.

Regards
Pär Brånedal

[manomatt]

I had the same issue, then i got to know from the IS help that says:
Using Windows Installer Properties to Dynamically Modify IIS Settings
Windows Installer uses MsiFormatRecord to resolve the property at run time. The installation writes the property and its value to the following registry key so that the value is available during uninstallation and repair:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield Uninstall Information\{ProductCode}

Therefore, if your Web site is installed to an end user–specified site number, the Web site, its applications, and its virtual directories can be successfully uninstalled from that site number.

so before iiscosting try to get to this location , decrypt the right password and putting that in the password location.

[Christopher_Pai]

I experienced some behavior today that brought me to this thread. I think there is still a bug here.

In my case I wanted to do a change operation and I have a UI that prompts for username and password. I would think I should be able to do that.

But it seems ISIISCosting is only scheduled for the execute and not the UI sequence so nothing pulls the data back. Also if I enter new data in the UI when ISIISCosting executes in the execute sequence it doesn't respect this new information rather it just blasts it with the data that was persisted.

I would say that it should only set the property if the property is null. Otherwise it should be assumed that the property is updated correct information and should be used to reconfigure and recache the persisted data.