Application Request Routing (ARR) feature allows creating a reverse proxy front-end for your on-premises deployment. Web Application Proxy (WAP) is another (newer) kid on the block allowing DMZ deployments of CRM.

We’ve been successfully using both for quite some time and they are way down on the list of suspects when things go wrong. And go wrong things did for one of the customers – some of the reports were coming back blank. No message, nothing, the progress message disappears but the report window stays blank. Since smaller reports were coming back fine, it did smell like a timeout issue but we couldn’t figure out where.

Turns out, report viewer control does not handle some of the errors very well – server was sending back error “502 – Bad gateway” and it was simply ignored by the report viewer.

502? Bad gateway? Why reports? Luckily, IIS has a nifty Failed Request Tracing feature. Enabling that did show up the 502 but it also showed a timeout error. Doh! We were hitting a known “misinterpretation” of the 502 error.

Go to your Server Farms > Farm name > Proxy and increase the timeout. Reports are back and customer happy.

Important lesson: there are multiple components in CRM deployments and each one can generate a timeout error:

• Reporting Server
• SQL Server
• CRM Server
• ARR/WAP/Reverse proxy (if you dare)
• Firewall? (never seen one of this timing out but they do have a software component so I wouldn’t be surprised)

Request tracing & logging on both client and server(s) are usually your best friends when troubleshooting timeout issues.