IIS 7 and Above
Need an ASP+ODBC Recipe, Please
Last post Nov 01, 2006 04:00 AM by shayivista
Oct 09, 2006 12:51 PM|swazal|LINK
Reposted from another Forum:
Okay, I'm on RC1 and trying to convert my barebones ASP+Access ODBC application to IIS7. What works today is on WinXPSP1 and the personal web service. An Access-base system DSN defined for read accesses, no security in Access. The MDB file sits at \inetpub\data
and the I_USR has read-write access to this directory so it can create the LDB file. All my ASP links basically drive GETs to drill into the database, with an initial post page. I can secure access (and do) to different views by adding domain group access
to an ASP page. This drives pass-through network authentication and is the only security. 98% of the use is unsecured anonymous access on a secure corporate desktop network.
On IIS7 and Vista, nothing. I continually get a 500 error. I've changed the perms for both the I_USRS group and the I_USR to modify on both the \inetpub\data and the MDB file, then moved the data directory to wwwroot\data in frustration.
Now, this is my only test Vista platform and the IIS application is quasi-production ... I have to run it under Vista in order to keep that desktop (don't ask about VirtPC or VMWare ... I don't have the memory for that). IS wants the old system back (I'm
running Vista on the replacement) and so I either need to replace it with the XP config I know works, or find another way to make IIS7 work (including an install on XP with an upgrade to Vista). I've tried poking into the app.config file and I'm frankly lost
-- where are the definitions for all those lines?
Bottom line: I need a recipe to make my application work, not an attempt at troubleshooting what's already there ... tell me what is supposed to work and I'll set it up that way. No upgrades to SQL Server, please. That's already an option elsewhere. I
want the desktop to remain available for Vista play. TIA -
Oct 11, 2006 01:58 PM|ApurvaJoshi|LINK
It looks like that the issue is that IIS7 loads the process's user profile (HKEY_CURRENT_USER reg hive) now by default. MS JET creates temporary cache database to a temp directory which now gets resolved to a different location than before. So if your application
pool is running under default NETWORK SERVICE identity it will be %windir%\ServiceProfiles\NetworkService\AppData\Local\Temp.
Now when ADO is attemoting to access the temp directory for the process, the user would not necessarily have rights to the same directory. By adding appropriate ACL for the user to %windir%\ServiceProfiles\NetworkService\AppData\Local\Temp should resolve
You can also turn off the 'loadUserProfile' IIS7 property which will give you the same result as your ASP/Access application in IIS6, by setting loadUserProfile to false under <applicationPoolDefaults> for your ApplicationHost.Config
<processModel identityType="NetworkService" loadUserProfile="false" />
Oct 17, 2006 10:32 AM|swazal|LINK
Outstanding ... I used your second approach instead of the first since it seemed easier and because I'm working with a system behind corporate firewalls. Changing the loadUserProfile to "false" did work as advertised. Awesome!
I'm certain there are security reasons for such changes, reducing the possibility of IIS7 to be exploited, etc. (I'm guessing the first approach, changing the ACL, is the safer of the two.) What would be very helpful is for team to document what has changed
from the generic IIS6 to IIS7 installs ... with some common sense language explaining why each change was made and what kind of impact each change might have on legacy applications.
Oct 19, 2006 05:53 PM|bills|LINK
fyi - I blogged more about this here:
Nov 01, 2006 04:00 AM|shayivista|LINK
First of all,Thanks a lot.
In fact,I didn't understand what your mean in way 1.
way 2 seems easy,but i do not like it.
add the "Authenticated User" to allow to write/read the "temp" directory,the asp+access works.
I'm a Chinese.My English is poor.Wish you understand what I write.