Windows Server 2008 R2 and COM Objects

So we just went through a huge ordeal while trying to decommission an old server and move a legacy website onto a new one. The old server was a 32 bit Windows Server 2003 machine, the new one is 64 bit Windows Server 2008 R2. The website is classic ASP that uses Dimac's JMail control and SoftArtisan's FileUp control, which are both 32 bit.

The result was several HTTP 500 errors and a relatively generic set of log messages. Actually we weren't always seeing anything in the logs. It was fairly perplexing. When we did get error messages they were like this:

800a01ad|ActiveX_component_can't_create_object

8000ffff|Enque:_Error__no_pickupdirectory_found.

80004005|[Microsoft][ODBC_Driver_Manager]_Data_source_name_not_found_and_no_default_driver_specified

The first part of the solution was to set the application pool for that website to 32 bit. You do this by opening IIS Manager, select Application Pools, select the application pool you're modifying, in the Actions pane click Advanced Settings..., then set Enable 32-Bit Applications to True. After you've done that, reset IIS and try your site. If the site still isn't working, reboot your machine. Apparently Windows isn't all that keen on switching between 64 and 32 bit, so sometimes a reboot is in order. [We had to.]

Maybe that will fix your problems, it didn't for us. In fact, the ODBC error seems to stem from this action. Apparently when you create an ODBC DSN it's only available to 64 bit processes. You have to create the DSN in the 32 bit space by using the 32 bit Data Source Administrator from the SysWOW64 directory [odbcad32.exe].

We still had those pesky JMail errors. The object was created successfully but we were getting File I/O errors. We followed advice that suggested we should copy the DLL to the SysWOW64 directory and register it there. No change. We modified the permissions on the DLL to allow everyone to read and execute it. No change.

What we hadn't thought of yet was to modify permissions on the SMTP pickup folder. We didn't think of this because the test page we'd created had everything but the instantiation commented. Still, this simple change made all the difference. For whatever reason, giving write permission to the IUSR didn't fix this. We tried a few other users before we gave up and just gave all local users write permission to the pickup folder. This did the trick.

Overall this was a royal pain. That's why I stopped to do this quick write up. I hope it helps.