FWIW – I have now been able to get the RDS.Dataspace stuff working on both the x86 and x64 versions of Windows 2008 + IIS 7. I will attempt to list the steps I followed to get it enabled on my servers in hopes that it might reduce the amount of frustration folks have been having trying to find information on how to get this working (based on my own futile efforts to find similar content on the interweb thing).
Note: I think the biggest tip I can suggest is to attempt this on a fresh W2K8 server install with the Application Server and Web Server roles enabled (get RDS working first prior to attempting to add websites or applications that rely on it). Hopefully you all have access to a snapshot of a baseline virtual server image that you can easily revert to in the event something goes haywire (I have to say that Hyper-v has saved my butt a number of times in my efforts to get this working – it simply ROCKS!). There are a couple of tricks involved here – this is especially true in 64-bit land. If you do not have this luxury, I’m afraid that YMMV with regard to the steps outlined in this guide.
Steps to provide MSADC /RDS Dataspace support in IIS 7:
1. Login with credentials that provide local admin permissions
2. Open IIS Manager and connect to the local computer
3. Double-click the “ISAPI and CGI Restrictions” icon in the IIS section of the “Home” pane
4. Select “Add” from the Actions pane
5. Set the “ISAPI or CGI path” by navigating to the location of msadcs.dll
a. On 32-bit machines the default location is found at “C:\Program Files\Common Files\System\msadc\msadcs.dll”
b. On 64-bit machines, you will also want to be using the 32-bit version of msadcs.dll (this is the only version I could get to work at any rate), so make sure you direct the path to point at the proper bits found in “C:\Program Files (x86)\Common Files\System\msadc\msadcs.dll”
6. Provide any description you like – I chose “RDS ISAPI Library”
7. Check “Allow extension path to execute” and click the OK button to dismiss the dialog
8. Highlight the newly created entry in the ISAPI and CGI Restrictions pane and click “Edit Feature Settings…” link in the Actions pane. Check the “Allow unspecified ISAPI modules” checkbox. Click the OK button to dismiss the dialog
9. Click on the local computer name in the “Connections” pane again and then double click the “Handler Mappings” icon found in the “Home” pane
10. Double-click “ISAPI-Dll” in the Features View pane (don’t worry that it appears grayed out, you will enable it in a later step)
11. Accept the defaults for the “Request Path” and “Module.” Use the “…” button to browse to the msadcs.dll (don’t forget that you want the 32-bit version if you are configuring a 64-bit server)and set the “Executable” value. Click the “Request Restrictions” button.
12. On the “Mapping” tab, check that “Invoke handler only if request is mapped to: File” is selected
13. On the “Access” tab, check that “Execute” is selected, then click the OK button to dismiss the dialog
14. You will then receive a prompt asking if you want to allow this ISAPI extension – well duh, click the Yes button.
15. Highlight the “ISAPI-dll” entry from the “Handler Mappings” pane and click the “Edit Feature Permissions” link in the “Action” pane. Enable all 3 permissions (Read, Script, and Execute). Click the OK button – the ISAPI-dll handler should now move to the “Enabled” category.
16. 64-bit users only – Since RDS is now configured to run in 32-bit address space, you will need to either create a new 32-bit enabled application pool or modify the existing default app pool (I’d recommend creating a new one unless you don’t mind forcing all of your default web apps to run in the 32-bit mode).
a. Click on Application Pools in the Connections pane and click the Add Application Pool link in the Actions pane.
b. Give your new App pool a descriptive name (i.e. “32 bit App Pool”), set it to use the .NET 2.0 Framework, and run in Integrated managed Pipeline Mode. Click OK.
c. Highlight the new 32 bit App Pool and click the Advanced Settings link from the Actions pane
d. Set the General->Enable 32-bit Applications value to True. Click OK
17. So far so good – about all we need to do in order to complete the IIS 7 RDS configuration tasks is add an MSADC application to the default web site. Expand the “Sites” under the local computer name in the “Connections” pane and select the “Default Web Site” Icon. Click the “View Applications” link in the “Actions” pane
18. Click the “Add Application…” link in the “Actions” pane. Enter “MSADC” as the “Alias”, select an appropriate Application pool (the Default App Pool for x86 machines or the new 32 bit App Pool created for x64 servers), and navigate to the appropriate 32-bit version of the “msadc” folder to set the “Physical path” value.
19. In order for RDS to be used to invoke COM+ Business Objects, the MSADC Application needs to impersonate the same identity used by the COM+ applications servicing the targeted business objects. Before dismissing the “Add Application” dialog, click on the “Connect as…” button
20. Under “Path Credentials” select the “Specific user” and click the “Set” button
21. Supply the appropriate service account credentials that match the COM+ Application Identity in the spaces provided. Note: The “User name” field needs to be entered in the domain_name\user_name format (i.e. “MyDomain\MyCOMServiceAccount”). Click the OK buttons until you’ve dismissed all dialogs.
22. Restart IIS by clicking on the local computer name in the “Connections” pane and clicking on the “Restart” link in the “Actions” pane
23. If all went according to plan, IIS 7 is now configured to support RDS.Dataspace object creation from remote clients or ASP pages. But you are not quite ready to use it yet – you still need to create the appropriate ADCLaunch registry entries to expose your COM+ business objects for consumption by RDS clients.
a. Open regedit.exe
b. Navigate to: HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch
(where “HKLM” = HKEY_LOCAL_MACHINE)
c. Right click on the ADCLaunch key and select New + Key
d. Enter the Prog ID for the COM+ object you are wishing to expose (i.e. “MyServer.TestObject”)
e. Lather, rinse, and repeat for each additional COM+ object you wish to serve from RDS (each object gets its own key).
24. Congratulations! You have just stepped back in time about 10 years and have enabled RDS to provide IIS 7 web access to COM+ business objects hosted on a Windows Server 2008 machine.
25. [Optional] - While you have the registry editor open you might want to make some additional changes in the interest of better securing your server from the known vulnerabilities that exist in the RDSServer.DataFactory components of the MDAC stack (if you are not using them, that is). The simplest way to prevent malicious users from hijacking these components is to delete the “AdvancedDataFactory” and “RDSServer.DataFactory” keys from the registry. You will probably encounter errors when you try this because for some unknown reason, Microsoft has not granted full control permissions to these keys to the local administrators group. The fix is pretty simple though.
a. Right click on the AdvancedDataFactory key and select Permissions
b. Click the Advanced button and select the Owner tab
c. Highlight the Administrators group and click the OK button
d. Assign full control permissions to the Administrators group and Click OK
e. Delete the key
f. Repeat for the RDSServer.DataFactory key
g. Inform your network Gestapo that you have sealed this security hole so they can sleep better at night despite the knowledge that RDS is now enabled on their web farm
That’s really all there is to it… ;-P
If everything worked as anticipated you should be good to go – if not, well, I hope you followed my advice to have some manner of backup baseline image handy that you can revert to and retry (some of these changes can be difficult to undo). Although my efforts have been limited to Windows 2008 Server, these same instructions should work for developers using Vista workstations with IIS 7 installed.
Hope this helps.