role discovery data is unavailable with Worker Role front end

When working with the current state of the Azure platform the only thing that I can say is that creativity is king and assumptions are many.

I have spent more time working around default behavior than I like to mention.  And, mind you, I am working with a lot of ‘beta’ features.

I recently ran into a problem with a script that I found simply baffling.  seems it is just a blocked / hidden setting.

For months now I have been tuning PowerShell scripts that interact with the Azure Service Runtime to enumerate internal endpoints and settings of other roles in the Azure environment.  The cmdlet Get-RoleInstance has been highly useful to me.

In my current environment I am using a Worker Role as my front end for the Service (oh, gosh, not a Web Role!?).  Here is where stuff gets weird.  It has an https input endpoint.  (gasp!)

First I have to make this a TCP endpoint since the rules of Visual Studio won’t let me use an input endpoint of https with a Worker Role.  Fair enough.  I can still have my certificated injected.

Now, I set it all up, I add my script, and my .CMD startup task (just as I have with other roles) and my script fails with this strange error:  Get-RoleInstance : role discovery data is unavailable 

All I can wonder is; what the heck?!  I RDP to the instance and try the cmdlet interactively and I get the same.  This makes no sense. This works in my Wen Role and my VM Role, why the problem here?

A bit of searching and I run across some WCF mentions and the local emulator and other things.  Okay, change the search string and try again.  After an hour or so I ran across a hidden property:      <Runtime executionContext="elevated" /> 

I added this to my Worker Role settings in the ServiceDefinition.csdef file and re-published.  And, hey, it works.

I can only speculate that this somehow affects the firewall and fencing set-up of the instance with the fabric.  Allowing both the input endpoint and the internal instance to fabric communication to share the same port.  A few articles that I found mentioned communication to the load balancers, however I don’t think this is really it as the Service Runtime should be querying the Fabric, however I am sure that a load balancer fencing rule was involved.

on to the next script bug.