This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- How to set IIS App Pool Identity and password
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 29, 2008
10:34 AM
How to set IIS App Pool Identity and password
I have an InstallScript MSI project that is setting up a web site. We need it to set up a run as identity for the App Pool. This is almost working, but the password is not getting set properly when I try to use a Property instead of a hard-coded entry. In the IDE, I specified [ComputerName]\[RUNASUSER] for the username - that works fine. I typed in [RUNASPWD] in the password field, but since that field shows only dots, I checked the UserPassword column in the ISIISAppPool table using the direct editor just to make sure. When I run the install I get no errors, but I find that I have to go into the IIS manager and reset the password in order for the site to run properly. If I build the install and type the password directly into the IDE, it works.
Can I use a Property for the password on the App Pool identity, and if so, how?
thanks,
Mike
Can I use a Property for the password on the App Pool identity, and if so, how?
thanks,
Mike
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 29, 2008
12:11 PM
I've not tested this ( I'm currently off site with only XP available which doesn't support app pools this way ) but if you find that the built-in InstallShield custom actions aren't formatting the UserPassword column of the ISIISAppPool table you can always use a custom action to read the value into the CA, call the format API and then use a temporary view to write it back out so that when the built-in deferred caCreateVRoots fired it'll process your data instead of the property name.
Still, I personally try to design my applications to run with one of the built-in service accounts. It generally makes the whole system more stable by removing points of fragility from the design.
Still, I personally try to design my applications to run with one of the built-in service accounts. It generally makes the whole system more stable by removing points of fragility from the design.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 31, 2008
10:33 AM
For what it's worth, the User and UserPassword fields in the ISIISAppPool table are resolved at runtime. As long as your property values are set prior to the caExtractIISSuppFiles action running, the properties should be resolved.
Does the username show up in the IIS manager when you view the application pool properties, or does the raw value you entered for the username in the IDE appear?
Does the username show up in the IIS manager when you view the application pool properties, or does the raw value you entered for the username in the IDE appear?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 31, 2008
11:09 AM
I'm not 100% sure that this is the answer, but I was having problems getting the install to run on a 2008 server (it choked on the app pool setup and rolled back) and found this thread. I copied the 'unofficial' iishelper.dll to my build machine - the resulting install ran OK on 2008, plus appears to have been the fix for my password problem on the 2003 server as that issue has also 'gone away'.
Is there an 'official' fix that includes the iishelper.dll?
Mike
Is there an 'official' fix that includes the iishelper.dll?
Mike
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 31, 2008
05:38 PM
An official fix was provided in KB Q200236.
One note about the fix for Windows Server 2008 is the code changes were isolated to the portion of the custom action code that is specific to IIS7, so I'm not sure how that would change the behavior you are seeing with application pools on IIS6.
One note about the fix for Windows Server 2008 is the code changes were isolated to the portion of the custom action code that is specific to IIS7, so I'm not sure how that would change the behavior you are seeing with application pools on IIS6.