This article explains how to run 32-bit IIS 6.0 on 64-bit Server 2003: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis/13f991a5-45eb-496c-8618-2179c3753bb0.mspx.
How can the same be accomplished with IIS 7.0 on 64-bit Server 2008?
Given the brief question, I don't know if this is exactly what you want to do, but you can run 32-bit ISAPI extensions (such as PHP, Rewrite, custom extensions, etc) in an AppPool in IIS 7 and 7.5.
For the full rundown, see this article here, the important part being:
Or see this. There's no need to run aspnet_regiis anymore, and you can switch between 32-bit and 64-bit per application pool instead of globally. It's a big improvement.
For those of you who still cannot find a proper way to use a 32-bit DLL under a native 64-bit IIS Application Pool, either by tweaking the registry, or by trying how to deal with the "COM+ Components Services", and if you absolutely need to run the IIS Application Pool in 64-bit" (so turning "Enable 32-bit Applications OFF") : I have found a perfectly working solution : "Encapsulating" the 32-bit component into a new COM object as described on this page did the job perfectly, and I think that a lot of you will be interested to solve the problem this way ;) http://www.chestysoft.com/component-services.asp
In my case, that allowed me to use the "XStandard.Zip" free Component from XStandard, which is sadly only available as a 32-bit ASP component, and that have an "InProcServer32" Key in the registry apparently preventing it to work by tweaking the registry, as described here : https://techtalk.gfi.com/32bit-object-64bit-environment/
In this post, a lot of comments reported that "InProcServer32-IDs are not reflected because Microsoft assumes that these are only InProc-Calls and not Out-Of-Proc-Calls". And that was my case too, leading me to the situation where the registry tweaking solution described in the previous post was not working in my case, as other users.
Hoping having saved some days... or nights !