La Reescritura de URL de IIS7 devuelve 404 para solicitudes WCF (proxy inverso)

Estoy utilizando IIS7.5, .net 4.0. Estoy trabajando localmente.

He instalado Application Request Routing, Web Farm Framework, WebDeploy y UrlRewrite para configurar un proxy inverso. Esto funciona bien en su mayor parte

Tengo dos sitios web:

DefaultWebSite (puerto 80, grupo de aplicaciones: Grupo de aplicaciones predeterminado (.net 4)) yTarget (puerto 8085, grupo de aplicaciones: TargetAppPool (mi identidad, .net 4)).

Tengo una regla de reescritura en DefaultWebSite (creada como se indica enIIS.net) que redirige todo el tráfico localhost (puerto 80) alocalhost: 8085 Justo como se detalla en el enlace de arriba. Esto funciona bien para la mayoría de los tipos de documentos (.aspx, .xap, .htm, .ico) pero falla la solicitud a MyService.svc. Devuelve un 404.

Para ser claro:

Cuando pegolocalhost: 8085 / MyService.svc en un navegador me sale la página WCF solicitada.

Cuando pegolocalhost / MyService.svc en un navegador me sale un 404.

Cuando pegolocalhost: 8085 / MyIcon.ico en un navegador obtengo el recurso solicitado.

Cuando pegolocalhost / MyIcon.ico en un navegador obtengo el recurso solicitado.

.svc es el único tipo de documento que he encontrado que devuelve un 404.

Tengo dos piezas de información que pueden ser relevantes.

App Pools. Cuando cambio el grupo de aplicaciones de DefaultWebSite a TargetAppPool, el 404 se convierte en un 500 ("No se pudo asignar la ruta '/'"). Todas las demás solicitudes tienen éxito cuando se realiza este cambio. No estoy seguro si esto es relevante o no.

Registro de FREB (seguimiento de solicitud fallida). Encontré una página (http://blogs.msdn.com/b/asiatech/archive/2011/08/25/return-404-4-not-found-when-url-rewrite.aspx) que detalla los pasos en un registro de FREB cuando una reescritura de URL es más exitosa que la mía (falla más adelante). No he podido averiguar cómo generar un registro de FREB para una reescritura exitosa (si es posible), así que solo puedo comparar mi registro de FREB con el de ese blog. Puedo ver su paso 21 (URL_CHANGED) en mi registro de FREB pero no 22 (URL_REWRITE_END). No tengo suficiente experiencia con estos registros para notar algo más significativo que eso (sugerencias bienvenidas).

Mi pregunta principal es: ¿alguien sabe por qué las URL que solicitan recursos .svc no se están reescribiendo?

Una pregunta secundaria es: ¿alguien sabe cómo generar un registro de FREB para una solicitud exitosa (si es posible)?

Gracias

Actualizar:

He cambiado la arquitectura para intentar obtener más información.

He movido el sitio web de Target a una PC diferente en la que he instalado Microsoft Network Monitor para capturar el tráfico entrante.

Antes de cambiar la regla de reescritura de URL para apuntar a este nuevo sitio web, recibí la respuesta correcta cuando hice una solicitud a MyService.svc en la nueva PC. Multa.

Tan pronto como cambié la regla de reescritura para enrutar la solicitud al nuevo sitio web de Target, responde como antes (404). He hecho tanto las solicitudes POST y GET. No hay signos de ninguna de las solicitudes en el registro del Monitor de red (todas las demás llamadas -200, 404 o de lo contrario, aparecen en este registro).

Esto me lleva a pensar que hay algo incompatible con url-rewrites y las solicitudes * .svc. Intenté realizar una solicitud a MyService.asmx (habiendo creado este archivo) y devolví correctamente una página, por lo que está limitado a * .svc. ¿Algunas ideas?

Respuestas a la pregunta(3)

Su respuesta a la pregunta