Breeze metadata returns 504 error - asp.net-web-api

Question

I've run into an issue with Breeze such that when I try to call the Metadata action on my controllers, they fail with a 504 error.
The approximate call is
//servername/breeze/controller/metadata
Environment
Web Api running via IIS7 on load balanced Win 2k8 Azure Virtual Machines
Versions (installed via NuGet)
Breeze Client 1.4.2
Breeze Client and Server 1.4.2
Breeze Server - for ASP.NET Web Api (Core) 1.4.2
Breeze Server - for ASP.NET Web Api and Entity Framework 1.4.2
Update: Upgrading to Breeze 1.4.5 makes no difference
Previously it worked fine and the only recent change is the introduction of load balancing.
Of note, I also have multiple controllers, each with their own metadata.
Cases where it runs sucessfully
Running via localhost.
Removing the [BreezeController] attribute from my controller
Renaming the metadata function
Cases where it fails
When deployed
When running a simple test to return a string, eg:
[HttpGet]
public string Metadata()
{
return "This was a test";
}
For some reason Breeze does not seem to like the Metadata function in my controller.
Updates:
It doesn't look like its specifically related to using a load balanced endpoint as I tried setting it up running directly on port 8080 with a non load balanced endpoint and had the same issue.
IIS failed request tracing doesn't seem to log anything for the failed request, though the request does appear in the IIS logs.

Answer 1

I had the same problem after updating from 0.72 to 1.41 and changing the route from api/{controller}/{action} to breeze/{controller}/{action}. I did not get an answer from the breeze folks so I withdrew the question.
However, I now think the problem was permissions. Localhost:50033 in VS ran as me and I have a SQL Server account, so I though it would be cool. After deployment to my local IIS and to a test server IIS, I was getting a 500 error.
I finally got way into the jquery code and determined from the jqXHR, that the error was SQL not handling the credentials for the anonymous user; a Doh! moment if there ever was one. I changed my connection string in web.config and that did it.
<!--<add name="PilotPlant" connectionString="Data Source=dataweb;Database=PilotPlant;Integrated Security=SSPI;" providerName="System.Data.SqlClient" />-->
<add name="PilotPlant" connectionString="Data Source=dataweb;Database=PilotPlant;Trusted_Connection=no;User Id=sa;Password=sapassword" providerName="System.Data.SqlClient"/>
This is less secure, but I am running inside the firewall, so it is not a problem for me.
So my answer is check your permissions on the cluster. I hope this helps.