RD Web Access broken: HTTP 500.100, HTTP 404.17 and Event ID 1309 explained

Fix it now

The request reached IIS and the managed pipeline that renders RD Web Access never ran, or ran and threw. The published cause of a 404.17 is an application pool that does not meet the handler’s preconditions, so start with the pool settings rather than with the files on disk.

Get-WindowsFeature Web-Asp-Net45, Web-Net-Ext45
Get-Website
Get-WebAppPoolState

1. In IIS Manager, select the RDWeb application and open Basic Settings to see which pool it uses. Then open Application Pools, select that pool, and check Advanced Settings: .NET Framework Version, Managed Pipeline Mode and Enable 32-Bit Applications are the three preconditions a handler can fail.
2. Turn on detailed errors for local requests in Error Pages, Edit Feature Settings, then browse to https://localhost/RDWeb/Pages from the server console and read the full substatus rather than the generic page.
3. At server level in IIS Manager, open ISAPI and CGI Restrictions and confirm the ASP.NET entries are Allowed. A 404.2 is that list refusing the handler outright.
4. Recycle the application pool, then retest both the page and the feed URL.

404 substatuses here are not missing files. Hunting for the page on disk is the single most common way to waste an hour on this.

If the logon page renders and the feed returns resources, stop here. If you are getting a 500 rather than a 404, the next section explains which 500 you have and which are not about RD Web Access at all.

Why it happens

RD Web Access is an ASP.NET application published under the RDWeb path of a site in IIS. It does two jobs: it draws the logon and application pages users see, and it serves the feed that RemoteApp and Desktop Connections subscribes to. Both are managed code, so both depend on ASP.NET being installed, permitted to run, and reachable through a handler whose preconditions the application pool satisfies.

The 404 substatuses describe a broken pipeline rather than a missing file. Microsoft publishes 404.17 as dynamic content mapped to the static file handler, and the documented cause is specific: the handler that should take the request has preconditions, the application pool does not meet some or all of them, so the static file handler takes it instead and refuses because the request is for a dynamic resource. The preconditions are pipeline mode, bitness and .NET Framework version. Missing ASP.NET is one way to land there; it is not the definition. 404.2 is different again and simpler, and Microsoft publishes it as an ISAPI or CGI restriction: the list at server level refuses the handler.

The 500 substatuses split into two groups. 500.22 and 500.23 are published as an ASP.NET configuration that does not apply in Managed Pipeline mode, one for modules and one for handlers. Those are real and they point straight at a pool running Integrated mode against configuration written for Classic. 500.100 is a different animal entirely: Microsoft publishes it as an internal ASP error, meaning an error while processing a classic Active Server Pages page. RD Web Access is not classic ASP, so a 500.100 there is not the RDWeb application failing. If a managed page throws, you get a plain 500 and the detail lands in an ASP.NET entry in the Application log.

Full reference

What each substatus is published as

That last row is worth reading twice, because it is a common misdirection. 500.100 is the classic ASP substatus. RD Web Access is a managed application, so when its code throws you get a plain 500 and the useful detail is in the ASP.NET entry in the Application log, not in a substatus. A genuine 500.100 on that server points at a different application, or at something in front of IIS relabelling the response.

Seeing the substatus at all

1. In IIS Manager, select the site or the RDWeb application, open Error Pages, then Edit Feature Settings.
2. Set detailed errors for local requests and detailed errors, so the console shows the substatus and remote browsers keep the generic page.
3. Browse from the server console rather than from your desk, or you will get the generic page and learn nothing.
4. Read the IIS log for the site as well. Status and substatus are separate fields there, so a 404.17 is visible as 404 and 17 without turning detailed errors on at all.

The 404.17 detail page, and what to take from it

When detailed errors are on, the 404.17 page names the module as StaticFileModule and the handler as StaticFile. That is the diagnosis in two lines: the request that should have gone to a managed handler was taken by the static file handler instead. The handler it should have reached has preconditions, and the pool failed at least one of them. A handler with preconditions such as classic mode, a particular runtime version or 32-bit will return 404.17 whenever the pool is not in classic mode, is not 32-bit, or is not on that runtime version, so all three are worth checking rather than only the one you suspect.

When the page loads and the feed does not

• An empty feed on a working page is not an IIS problem. Look at the collection, the published RemoteApp programmes, and the user’s group membership.
• A feed that throws rather than returning an empty list usually means the Connection Broker behind it is unreachable. Check the broker before the web server.
• Subscribe a test machine to the feed URL rather than trusting the page, because the two paths do not fail identically.
• Check the IIS log for the subscription request specifically. A feed request that never reaches the server is a name or certificate problem, not a pipeline one.

What not to do

Do not remove and re-add the RD Web Access role service to clear this. That resets the site configuration, the published feed settings and any customisation of the logon pages, and it fixes a pool setting by demolition. Do not reinstall IIS either: it takes the whole deployment offline and almost never fixes anything that correcting the pool, allowing the handler and reverting the handler mappings would not. Take a copy of the RD Web folder and export the site configuration before you consider either.

None of this is a licensing problem and none of it costs anything. RD Web Access is a role service of Windows Server you have already licensed. Licence faults in Remote Desktop Services surface as licensing events on the session hosts, naming licensing explicitly, not as IIS substatus codes.

Every code this article covers

Confirm the fix worked

1. The RDWeb logon page renders completely from a client, images included.
2. Signing in lists the published desktops or applications.
3. A test machine subscribed to the feed URL retrieves the resources.
4. The IIS log records those requests with status 200 and no substatus.
5. The application pool’s runtime version, pipeline mode and bitness match what the handler requires, and the pool is started.

Questions people ask about this