64-bit Editions of IIS
IIS in SySWoW Mode
ASP & Jet Provider
Last post Dec 17, 2011 04:15 PM by HCamper
Jan 23, 2007 03:35 AM|jmiko|LINK
I try windows vista on my box and discover that I can't use my ASP application due to error:
My connection string is
ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Test\test.mdb;Persist Security Info=False"
I found several articles about differences between 32-bit and 64-bit environments but it is too strange that microsoft doesn't provide compatibility for ASP applications with MSAccess databases under vista.
Is there a way to connect to mdb-file with 64-bit IIS7?
Jan 29, 2007 11:56 AM|thomad|LINK
There is not 64-Bit Jet Provider as far as I know. Your best bet is to run your applicaiton in a 32-Bit Application Pool.
How to do it:
1) Create a new Application Pool in the UI or via command-line, e.g.
%windir%\system32\inetsrv\appcmd add AppPool My32BitAppPool
2) Set it to run in 32-Bit Mode by setting "Enable 32-Bit Applications" in the AppPool's "Advanced Settings" or via command-line:
%windir%\system32\inetsrv\appcmd set AppPool My32BitAppPool -enable32BitAppOnWin64:true
3) Run your application in this AppPool by changing it in the UI (Application: Basic Settings) or via command-line:
%windir%\system32\inetsrv\appcmd set app "Default Web Site/test" -applicationPool:My32BitAppPool
Hope this helps.
Jan 31, 2007 01:33 AM|jmiko|LINK
thank you. It works perfectly!
Apr 12, 2007 12:48 AM|craiger316|LINK
Thomas, thanks so much for that tip it got me one step closer to migrating a classic ASP site over to IIS 7 on 64bit vista. I still have a missing piece to my puzzle though, I cannot for the life of me get a connection to my Access database when running
the code under IIS. I get the dreaded when attempting to connect:
Microsoft JET Database Engine : Unspecified error : -2147467259
However, if I take the offending code out and place it into a .vbs file (changing Response.write to MsgBox and Server.CreateObject to CreateObject), everything works just fine. I run the .vbs file from the command line using wscript from the sysWOW64 directory
(otherwise you get Provider not Found).
Just to make sure it wasn't permissions, I moved the .mdb to a new folder and gave full perms to "Everyone".
Here is the code:
Private Sub Initialize()
Set mobjConnection = Server.CreateObject("ADODB.Connection")
mobjConnection.Provider = "Microsoft.Jet.OLEDB.4.0"
On Error Resume Next
If Err.number <> 0 then
Response.write("<h1>" & Err.source & ":" & Err.description & ":" & Err.number & "</h1>")
I saw an article which stated that Windows\Temp folder needed to be permed right as well, I did that, still no luck. In my .vbs version I do infact see a temp file being created in my user account's Temp folder (Jet apparently uses the %TEMP% var from System
env settings when running under IIS, but uses %TEMP% from the user's env settings when running under a user's account).
Any help would be greatly appreciated. It has to be some configuration I missed.
Thanks in advance.
Apr 12, 2007 01:14 AM|thomad|LINK
try this and I bet it works:
%windir%\system32\inetsrv\appcmd set AppPool -appPool.name:My32BitAppPool -processModel.loadUserProfile:false
Assuming this is the problem, here is the reason:
We are now loading the user profile when we start a worker process. This means that every worker process gets its own %temp% directory that is ACLed (I like 'permed' :)) so that only the worker process identity has access to it. For the default IIS worker
process identity the %temp% directory is %windir%\ServiceProfiles\NetworkService\AppData\Local\Temp. Problem is however that ASP impersonates the authenticated user, e.g. the anonymous user IUSR. This user doesn't have access to the worker process's temp directory.
Access is heavily using the temp directory though.
If you don't load the user profile every worker process parties in the %windir%\temp directory instead having its own %temp% directory. For security reasons we rather not do this but the errors Access and other applications throw are extremely hard to troubleshoot.
Ideally we find a solution that is both secure and doesn't break existing apps. We didn't find it yet however :(.
Another way to fix the problem is to perm the %temp% directory in a way that allows authenticated users. If you use anonymous authentication for example you should be able to fix the problem by allowing IUSR access to %windir%\ServiceProfiles\NetworkService\AppData\Local\Temp,
ICACLS %windir%\ServiceProfiles\NetworkService\AppData\Local\Temp /grant IUSR:(IO)(OI)(CI)F
ICACLS %windir%\ServiceProfiles\NetworkService\AppData\Local\Temp /grant IUSR:F
Hope this helps.
Apr 12, 2007 07:37 AM|craiger316|LINK
Thomas you have made my morning, actually my week! That worked like a charm (I tried option 1). Is that option part of the gui or only accessible via the command line?
After making that setting change what I did was I started systematically reverting all the permissions I had set for IUSR/IIS_USRS on the folder where the mdb existed. I was wondering if you could give me a little IIS 7 "101" and tell me why I don't have
to perm my Access database (or it's folder) so conn.open can open it? I was pretty sure with my experience in previous versions of IIS/ASP/Windows that was always a must? But now it seems the default perms for the folder (i.e. the ones Windows sets up for
you when you create a new folder through explorer) work just fine.
Thank you once again for you help I can't tell you how much I appreciate a quick (and correct) response!
Apr 12, 2007 11:22 AM|thomad|LINK
Nice to hear that it works.
I'm not sure I understand your questions but here are some thoughts.
Folder permissions are usually inherited from the root of your drive. The root permissions are set when you format the drive. Permissions after a format on W2K are probably different from a format on W2K3 from a format on Vista. That's my guess. On Vista
(what I'm running right now) "Authenticated Users" have "modify" rights on the root of my drive - this means they can create/read/write/change files.
The ACL on the INETPUB\WWWROOT directory is different though.
We ACL it so that Users/Authenticated Users only have read access. Administrators are the only ones who have write access. This is a problem if you have your Access database underneath INETPUB\WWWROOT because if you want to add a row you have to write to
it as a standard user and it will fail.
For security reasons we think it is better though to only give Administrators write access by default. Ideally you put your MDB in a different directory outside the URL namespace, i.e. \inetpub\wwwroot. This is a good security practice anyway.
Does this help?
Apr 12, 2007 11:35 AM|craiger316|LINK
Does this help?
Very much so, thank you. I guess I completely disregarded the fact that on my other system we were running the app out of the directory IIS had setup as wwwroot. In the new system, I created my own root specifically for this application and just had IIS
use it. That would probably explain things.
Again, thank you for you time and effort helping me with this problem.
Apr 22, 2008 09:42 AM|Regneva|LINK
I was having this trouble and found your post by Google! Thank you very much! You solved a problem I've been trying to figure out for months!
Aug 21, 2008 04:44 AM|NiteFly|LINK
i have the same problem as described on post #1
i run under XP 64bit with IIS 6
But i can't execute the scripts as suggested by Micheal in post #2, simply it seems my XP 64 doesn't have the requested file '%windir%\system32\inetsrv\appcmd' thjat i suppose to exist in Vista only.
I know how to create a new Application Pool, but i don't know hot set it to run in 32-Bit Mode.
Any hints ?
Aug 21, 2008 08:47 AM|Regneva|LINK
Hmm, that is interesting. Prior to my upgrade to Vista, I was running XP 64bit, and it ran my website with the database just fine.
I'm not sure how to change it, outside of Vista... Sorry. You could check the different dialogs within the application pool settings.
Aug 21, 2008 09:36 AM|ma_khan|LINK
Appcmd is a utility that comes only with IIS 7 ... that is the reason it will run on Vista but not on XP 64 which is IIS 6
Jan 19, 2009 05:19 PM|DavidRose123|LINK
I am configuring Windows2008 Server in 64 bit. When I try t set the Application Pool to 32-bit mode it kiils the web server: "HTTP Error 503. The service is unavailable."
In 64 bit mode I get error message "ADODB.Connection error '800a0e7a'
Provider cannot be found. It may not be properly installed.
Any thoughts on how to run 32 bit without killing the server?
FYI The Event Error logs report these errors:
Application pool 'FPSAppPool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.
A listener channel for protocol 'http' in worker process '3960' serving application pool 'FPSAppPool' reported a listener channel failure. The data field contains the error number.<br.
Mar 05, 2009 05:57 PM|CathyM|LINK
After ages serching trying to find an answer to my probs thinking it was a bug in windows 7 it was as simple as this.
Thankyou so much.
Aug 02, 2009 12:57 PM|dcgmbh|LINK
Classic ASP+64bit works
Classic ASP+32bit --> ENABLE 32 Mode --> does not work --> no chance (I guess) to get 32 bit ODBC to Access mdb file
Nov 27, 2009 09:59 PM|Coredumpcr|LINK
Has anybody solved how to DSN-less connect to an ACCESS DATABASE successfully?
When enabling 32-bit mode of Application pool will kill the IIS.
No msjetoledb40.dll registered in Windows Server 2008.
Error still is: "Provider cannot be found. It may not be properly installed."
Provider cannot be found. It may not be properly installed.
Jun 09, 2010 06:06 PM|rowlig|LINK
You can workaround by using ACE OLEDB, which is available for 64bit windows
Microsoft Access Database Engine 2010 Redistributable Found at
Jun 17, 2010 11:14 PM|slightstk|LINK
thomad, that was the solution.
Jul 19, 2010 05:14 PM|janderson215|LINK
Jul 19, 2010 05:23 PM|craiger316|LINK
Wow. I need to say a prayer for google and for you tonight. I am very grateful for your help!
Surely you mean to thank God for Bing :)
Dec 17, 2011 03:54 PM|Ramjee|LINK
I hope Thomas or senior member will able to help me.
I am trying to be concise here.
I moved ASP application from Windows 2003 to Windows 2008. I get HTTP 500 error on Asp pages which has UDL connection to "Microsoft.Jet.OLEDB.4.0"/ MS Access.
I get this error upon opening UDL file which has above provider "Ms access Provider cannot be found. Ensure that the provider has been installed properly"
I don't find "Microsoft.Jet.OLEDB.4.0" provider when I add test.udl file (provider tab)
I am stuck how I can repair "Microsoft.Jet.OLEDB.4.0" as this is already installed with Windows 2008. (WHY I DON'T SEE IT UNDER PROVIDER TAB UPON CREATING A NEW TEST.UDL FILE)
your help is appreciated.
Dec 17, 2011 04:15 PM|HCamper|LINK
FYI: Sorry "Thomas" left the IIS Team.
If the following information and this thread do not resolve the issues
create a new Forum post.
Have you looked at IIS Net Classic ASP Guides
For problems with Classic ASP and Databases
You need the Access Runtime Distribution
MS KB942976 http://support.microsoft.com/kb/942976 ODBC Manager information.