Microsoft OLE DB Provider for ODBC Drivers error ’80004005′
[Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application
/path/to/dsn.asp, line 6

Well that’s interesting.  It’s mostly interesting because of what was actually on line 6 of this file:

Conn.Open “dsn=dsnName;uid=user;pwd=pass;”

Googling kept pointing me to it being a 32bit application running in 64bit mode.  All the resolutions were mostly explaining that the application needs to be recompiled, yadda, yadda.  Obviously this .asp file isn’t a “32bit file”, and well what am I supposed to tell my customers, that they need to only use 64bit .mdb files?

The solution was actually simple and had been something I’d read a few days before at iis.net about 32bit mode worker processes.

To configure 32-bit mode for the server

• Open a command prompt and run the following:

%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.enable32BitAppOnWin64:true

Or you can just toggle this option in the Advanced Settings for the Application Pool for which the site is running. Either way works just fine.

I suppose on a shared web server for which I have no daily knowledge or control over what my customers are doing, it would be a best practice to turn 32bit mode for all sites by default and if an opportunity or need arises to switch back to native 64bit mode, then all the better.

I would have expected there to be no problems with most of them. I started out with a dinky little site that uses a small Microsoft Access Database.  This site uses a standard DSN to access the .mdb. I proceed to go to the Administrative Tools and open the ODBC Data Source Administrator window and add a new DSN for the .mdb and lo and behold I see the following nearly empty window:

<– This of course is no good! Where are all the other data drivers? Apparently all the regular ones we are used to seeing in 32bit Windows no longer exist as 64bit drivers.  The trick is to execute %windir%\SysWOW64\odbcad32.exe.

<– This will give you the ability to add the rest of the 32bit Data Sources such as Microsoft Access (.mdb).

Luckily I run everything within VMware ESX Environment, so no data needed to be copied from one machine to another. I simply provisioned a new Windows Server 2003 guest and added the old server’s VMDK disk to the new machine.

• The first thing you need to do is backup your old IIS configuration. In IIS Manager, right click in IIS Manager > All Tasks > Backup/Restore Configuration.

• Probably the most imporant part of the whole process is to make sure you “Encrypt the backup using password”. This makes th e IIS config “portable”. If you don’t encrypt it, you won’t be able to import it on a different system as there are sessions keys stored withing the IIS metabase.

• By default the configuration backup goes to C:\WINDOWS\system32\inetsrv\MetaBack. So you will need to grab both files it has created and move them on over to the new server. Place them in the same location on the new server because IIS doesn’t give you a choice to browse for a backup – it looks in that directory each time.

• Now you’ll restore that configuration from within IIS Manager, right click in IIS Manager > All Tasks > Backup/Restore Configuration. Choose the one you want to restore and restore. It will ask for the encryptin password.
• Now we need to restart IIS. This will actually re-create the IUSR account in the Local User Manager, which kind of impressed me. The password will be wrong for this account so you need to set it to something manually by the normal Reset Password function.
• Now you need to need to tell the metabase about that new password. Microsoft has a nice article outlining how this is done.
  http://support.microsoft.com/kb/297989
• Restart IIS and for the most part you should be good to go.

I opted to simply reset the password for the IUSR account that the metabase created automatically for me. The name was wrong (hence IUSR_computer), however this meant I wouldnt need to change all of the special IUSR permissions set for special files such as MDB and other special case files. You can easily tell the metabase to use a new user account as the IUSR account using the metabase explorer, but I’m not going to go into that right now.