IIS / ODBC / user permission

it is EXTREAMLY unlikely that that Access user level security is being used here, and ULS is ONLY supported for mdb files, not accDB ones. As to the original poster here, I would NOT use a DSN based connection, but ALWAYS use a DSN-less connection, since then the web site does not require elevated rights to read the file(s) in the DNS location. In fact, I OFTEN find that if I don't launch Access with admin rights, then I can't use FILE nor SYSTEM DSN's, since they reside in protected folders, and they don't work for me. So, don't include nor use nor have "DSN" at all in your connection strings. Use a DSN-less format.

I hear ya, but since we didn't set up his environment, we have to follow the evidence that's presented to us. He says that he tried a DSN less connection. He said that he traced the process with procmon which should show an "access denied' error if the account cannot access some file or registry. For all we know, some other analyst could have built the mdb file and set up user level security. It's just another check on the list of "have you looked at...". I'm hoping that running cscript as a plain old user will spit out some error message that is being suppressed when run under IIS. The ultimate solution (recommendation) is to migrate the DB to SQL server.

Is this a accDB file, or a mdb file? That could well matter. However, as noted, I doubt much ULS security is being used, else when you logged in as admin, and it works fine, then that again suggests this is not ULS. As noted, not practical to re-write the software, but if there is only 1-3 pages that use the database, then as noted, you can continue to use Access, but replace the create object ado, with .net ado. If one is familiar with both object models, then the efforts to do this change is minor (depending on how much code).. As noted, this is simply the environment and deck of cards you been dealt with - so narratives around changing this or that code is not a whole lot of help to you. As suggest, you might want to try creating a local user on the server, and specify that for the app pool, and not a domain user. And since the site runs with you as admin, then again, this does not look to be a bit size miss-match. As noted, using create object is much the same as using a COM object, or so called ActiveX, and out of the box, that option is locked down on a server. So, try a quick test with a local non domain user on the server -- that would be my best idea to try, and it only takes a few minutes at most. So, create that local user on the server. Logout, and then logon using that user, and see if you code runs on the server. If yes, then a good chance that external uses to the server will also now work.