0
Fixed

IIS exception on create AD agent: The request filtering module is configured to deny the file extension

Bob Bradley 6 years ago • updated by anonymous 3 years ago 11

Henry reported that he got the above exception when clicking on the Create Agent (http://<EvB server>:8081/Agents page) due to IIS' "request filtering module" which I can only guess has been activated as a result of a recent Windows Update (???). When Henry reported the problem I tried for myself in my own lab environment and sure enough the same page (http://127.0.0.1:8081/Agents/Create/Unify.EventBroker.Agent.AD) was dispayed with the following error summary:

HTTP Error 404.7 - Not Found
The request filtering module is configured to deny the file extension.

Henry explained that he was able to selectively remove the filter, but I can only presume that this will be affecting EVERYONE now that this feature appears to have been activated in my lab without me even realizing it. We probably need to (a) add some extra doco in the troubleshooting section, (b) add something in the prerequisites section to ensure people avoid this in the first place, and (c) look at a way of automating the removal of this filter as part of the installation???

We have two options:

  1. Document that the filtered extension should be removed from %WinDir%/System32/inetsvr/config/applicationHost.config
  2. Change the uri to not appear as a filtered extension.

Option two is the easiest and will have the least impact on users.

I'd go with option 2, but you might need to talk to Tony on the best way to do this (and also to see if this might happen elsewhere, especially since custom plugins names may have similar extensions?)

Tony, can you please comment on the above comments?

Thanks.

The URI is based on the agent factory name, so option 2 will require the agent name be changed, or the uri be encapsulated with something along the lines of AgentFactoryName.Agents or AgentFactoryName/Create.

I'd side with the latter as we'd have to update the factories to support multiple names, and we'd have to check each created factory against this issue.

Assigned for comment.

Tony, I like the latter option of adding a new part to the url. eg:
Agents/AgentFactoryName/Create

Unfortunately I can't have

/Operation/

{plugInName}

/CreateOperation

because it will always resolve to

/Controller/Action/Id.

I can add a fourth value that will force the routes to evaluate respectively, e.g.:

/New/Operation/Unify.EventBroker.PlugIn.PowerShellScript/CreateOperation

Double check whether Controller/Action/id/create would be able to be matched.

Reassigned for confirmation of completion.

Confirmed with latest installation, .ad was allowed=false.

The alert for the failed agent test still links to the old link style.

On review the url was failing because it had concatenated a "Framework" area to the front of the route data, this has been fixed and confirmed in multiple builds.