ColdFusion WebSocket Proxy and IIS 8+ - 500 Error

Today I ran into an issue in my development environment that was one of those "Duh" moments. If you are using the WebSocket Proxy with IIS we already know the following is required.

1. IIS 8+ with WebSockets Installed
   • Windows 8+ : Can be found in Control Panel > Programs and Features > Turn Windows Features on or Off > Internet Information Services > World Wide Web Services > Application Development Features > WebSocket Protocol (check it)
   • Windows Server 2012+ : Same as above but the steps are a few more screens. You may also start from the Server Manager (Top Right: Manage > Add Roles and Features)
2. Run wsconfigproxy.exe (as administrator) which can be found in {{ColdFusionInstallDir}}/cfusion/bin/wsconfigproxy.exe
3. Set "Use Proxy" in ColdFusion Administrator (restart may be required if not already set)

At this point everything should work without a problem and most of the times it does. I have ran into permission issues, especially when you go thru the lock down guide and you did not set the required permissions on the config/wsproxy directory. If all the above is correct and you still have an issue, like I did today, check one last thing.

Last time I configured the app pool on this app I was testing I had set the .NET CLR Version to "No Managed Code" and when the cfws directory was created it used the parent App Pool. The fix is simple, set the .NET CLR version back to a valid version or create another App Pool with a CLR assigned and bind it to the cfws folder since it is created as a virtual application. Below are some images that show the error I was receiving (after I allowed errors to show on localhost) and how to assign the fix. An easy way to test that they can be connected to is by browsing to the /cfws/ path of your domain. In an http call you should receive a good 200 response.

UPDATE
Do not use a different app pool, just ran into an issue that when I sent a call to WsPublish on the server side it messed with my Session scope. The only fix is to make sure they both use the same App Pool and that it is set to use a .NET CLR. (duh moment #2 of the day)

Bad Request

Causes Error

Works Again

Good Request