Troubleshoot message flow for Windows Azure Pack

While developing WAP custom resource providers, I have seen myself and others running into the issue of getting 404, resource not found when developing a new API controller.

Typically if we have atleast one API call working against the custom RP, it means that custom resource provider registration is working fine and WAP framework is routing the messages correctly. It is most likely a mismatch between how API client construct the URL or how route configuration is done in Web API. Attaching debugger, doesn’t really help in this scenario, as ASP .NET is not able to find the route to the controller class (yea, that is why it is sending 404). So how do we find out how is the messages get routed.

First and foremost, we need to understand how messages are flowing. Below diagram shows how it will typically be routed in a development boxes (I have marked the default ports in there).


We can use Fiddler tool to capture the traffic and understand the exact messages that are going between various Sites. Since fiddler is a proxy tool, we need to enable proxy at the origin of the message. So if you are interested in finding the messages that Resource Provider API receive, you should set the proxy at Admin API or Tenant API, depending on what specific messages you are trying to look at.

This is what I have done on my test environment (Windows Server 2012 R2), to troubleshoot messages coming to the tenant endpoint on my custom RP.

  • Logged on to server as Administrator
  • Install Fiddler tool (I used the downloads from Telerik)
  • Changed the Identity of ‘Tenant API’ application pool to Administrator


  • Opened a new instance of IE and launched Fiddler from Tools > Fiddler
  • Configure Fiddler to capture HTTPS traffic (Fiddler : Tools > Fiddler Options)


  • Accept the Fiddler Proxy Certificate installation
  • From IE, accessed tenant portal and invoked custom resource provider tabs
  • Now, messages that goes from Tenant API to custom RP starts showing up in Fiddler. Smile

Note: Fiddler captures all traffic that originate from browser as well. To filter the requests that shows up in Fiddler UI, you can update the ‘Rules’ in Fiddler (Rules > Customize Rules). I have used the following rule to see only the messages that land on my custom resource provider.

static function OnBeforeRequest(oSession: Session) {
   if ( != “twe-wap01:30032”){
     oSession[“ui-hide”] = “true”;

Thanks to Manish for helping me with the approach.

About Manesh

Manesh is a software consultant and solutions architect specializing in cloud, data, Linux and devops in the azure realm with key focus on hybrid workloads. He has been working on Azure technologies since its inception and has helped many enterprises to onboard and adapt to Azure cloud, build solutions for datacenter scale / high consumer applications and services. Currently, he is Microsoft certified for Developing Microsoft Azure Solutions (70-532), Implementing Microsoft Azure Infrastructure Solutions(70-533) and Architecting Microsoft Azure Solutions (70-534).

Posted on 2014/10/07, in Cloud-OS, Troubleshooting and tagged . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

My views on technology

Virtualization and some coffee

My views on technology

Thomas Maurer

Cloud and Datacenter Blog focusing on Microsoft Azure

Cloud Administrator in Azure World

Begin Your Azure Management Journey with the Cloud Administrator

%d bloggers like this: