AnsweredAssumed Answered

FQDN Lookup & Thus Stream Services and Other Features Not Working in Azure

Question asked by skehoesci on Mar 17, 2015
Latest reply on Apr 9, 2015 by skehoesci

It's been a long couple of days trying to set up an ArcGis for Server development environment up in Azure.  I've been able to get most things to work, however the primary nagging issue I'm still unable to resolve is that of the quirky FQDN resolution of Azure VMs (and ArcGis' dependence on them).

 

A prior thread here Invalid redirect when logging in to Portal for ArcGIS 10.3 detailed the issue in the context of the Portal WebAdaptor.  In this case, there was a work a round, as you can go in and edit the Web Adaptor setting manually to use the correct externally facing VM.

 

The issue stems from the fact that Azure uses local FQDN's within each Cloud Service network, which all have the format of  machinename.xx.internal.cloudapp.net.  The real external FQDN is machinename.cloudapp.net - however this is hidden from the perspective of the local machine and is taken care of at some higher level in the network architecture (I am not a network expert unfortunately).

 

After two attempts of trying to solve this issue with my own manual deployments - I decided to try the ArcGIS Server for Azure Technical Preview 

Unfortunately the issue remains.  Below is a screenshow for the rest API call located at http://d-arcgis.cloudapp.net/arcgis/rest/services/TestStream/StreamServer (which is available over the net)  but the websocket addresses at the bottom are still using the local DNS naming.

 

 

If you were to click on ArcGis Javascript and look at the Javascript Console in Chrome, you would see my suspicions confirmed:

 

Any insights on workarounds or other options for hosting a stream service in Azure?

 

Thanks,

 

Steve Kehoe

Outcomes