none
Power BI OData Power Query WAS: timed out IS NOW: 502 Bad Gateway RRS feed

  • Question

  • Hi

    Can anyone suggest a resolution to this:

    DataSource.Error: OData: Request failed: The operation has timed out
    Details:
        https://mydomain.hybridproxy.powerbi.com/ODataService/v1.0/mydatasource

    Situation is 3 machines on a small local LAN.  One domain controller, one W7 running SQL 2012 and Data Management Gateway, one running Excel 2013.   SQL database exposed as OData HTTP feed.  Test Connection gives a green light from Power BI Admin Center on both W7 computers ("Connection successful").  

    Been though hoops.  First, could not resolve.  Then, could not trust.  Now, timed out.

    There is some local handshaking.  I Wiresharked both machines, and here's a small sample of what I got

    Excel Box:

    259	48.782114	192.168.0.9	192.168.0.4	TCP	55132 > 8051 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
    262	48.784420	192.168.0.4	192.168.0.9	TCP	8051 > 55132 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=8

    SQL/DMG box:

    5577	136.642121	192.168.0.9	192.168.0.4	TCP	55132 > 8051 [FIN, ACK] Seq=3141 Ack=1 Win=65700 Len=0
    5581	136.843600	192.168.0.4	192.168.0.9	TCP	8051 > 55132 [ACK] Seq=1 Ack=3142 Win=65280 Len=0

    Note that we're getting traffic on port 8051 . . . that's the port that the Data Management Gateway reports as having opened for OData access (The gateway supports HTTP or HTTPS protocol) and is in fact HTTP.

    I suppose I should mention that this follows on from this discussion : The remote name could not be resolved                                 

    http://social.technet.microsoft.com/Forums/en-US/ae5e8ead-7d26-42be-b490-0680a29bdf43/the-remote-name-could-not-be-resolved?forum=powerbiforoffice365

    but I thought it was time to start a new thread on these connectivity problems as I seem to have broken new ground :-(

    BTW, I have a hosts file on the Excel box with an entry that points to the SQL/DMG box. 

    However, if I comment out the hosts file entry, then we're back to the remote name could not be resolved.  That doesn't really help matters.  I feel like I'm going in circles . . .

    All help gratefully received, Donna


    Donna Kelly


    • Edited by Lady Donna Saturday, August 16, 2014 2:07 PM
    Monday, August 11, 2014 9:38 PM

Answers

All replies

  • I'm not sure if this is the right place to get help for DMG issues; there may be a better one.

    That said, I know that people have had issues with timeouts and DMG before. So we added an option to the OData.Feed function to let you increase the timeout. To set it to (e.g.) five minutes, you need to manually edit the formula for the function and add the Timeout option like this:

    = OData.Feed("http://some.url/service.svc/", null, [Timeout=#duration(0, 0, 5, 0)])

    Tuesday, August 12, 2014 3:30 PM
  • Hi Curt,

    this might not be the right forum for DMG, but I believe it is the right one for my query because I'm getting the timeout when I issue a Power Query in Excel 2013, and this is the Power Query forum.

    I believe that the DMG is working OK because I see Connection successful when issuing a TEST CONNECTION in the admin center on both the DMG/SQL box and the client box.  Therefore I believe this is a Power Query problem.

    I'd add that I doubt timeout really is the problem, as the Domain/LAN in question has three machines counting the domain controller, and the total cable length is less than 20 feet.  Having said that, please tell me where the OData.Feed function you mention actually is, because I cannot see such a thing ion the setting as shown after the timeout error.  Where should this manual edit take place?

    BTW, I provided packet level diagnostics for both machines because I think it useful to know how the computers are trying to talk with each other.  I note the traffic between 55132 and 8051, which I'm guessing is NAT>DMG traffic . . . and it looks like the two machines are talking . . . I don't know Power Query internals so I'm not sure of this, and I really could do with some help.

    I'm guessing that the data handshake is directly between the machines and not via the cloud (which would account for the limitation I noted in the previous thread):

    I found this page "Access OData Feeds from Power Query"

    http://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/access-odata-feeds-from-power-query-HA104079175.aspx which said "The Power Query client must be located in the same corpnet with

    the machine hosting the Data Management Gateway; otherwise, the Power Query client

    cannot gain access to the data included in the OData feed."


    But given that the machines can see each other, why would they timeout?

    And can you confirm that they talk directly?  And if that is the case, then what is the purpose of hybridproxy.powerbi.com?

    More generally, do you know of any documentation on the architecture and internals of Power Query and Data Management Gateway?  It would be extremely helpful!

    Cheers, Donna



    Donna Kelly

    Tuesday, August 12, 2014 10:52 PM
  • So, does that mean you tried increasing the timeout and it didn't work?

    Power Query doesn't do anything special for the Data Management Gateway; it just looks like a regular OData feed to us. If I recall correctly, the DMG works by issuing HTTP redirects from the cloud endpoint (i.e. powerbi.com) to the local source for every HTTP request made. That's why the local name needs to resolve on the client computer. I don't know what "test connection" does in the admin center, but I do know that people have reported timeouts before when accessing the OData feed via Power Query.

    I know that the last thing people want to see from us is a silent finger pointing at some other team, so I'll see if I can find an appropriate contact on the Data Movement team.

    Wednesday, August 13, 2014 3:21 AM
  • Curt,

    thank you for this.

    As it happens, I did not increase the timeout parameter, as I did not know "Where should this manual edit take place?".  (I eventually found it in the Query Editor>View>Advanced Editor).

    The reason why I did not do that is because as I mentioned in the parent thread . . .

    social.technet.microsoft.com the-remote-name-could-not-be-resolved

    . . . the original problem was to do "the remote name could not be resolved".  I had returned to this problem by removing the hosts kludge since that wouldn't be practical in a real installation anyway.

    This time, I used Fiddler to capture cloud traffic as well as Wireshark for intra-domain packets.

    What I found was that although the failure originated from initiating Power Query, it looks like it actually came from hybridproxy.powerbi.com.

    Here's the Fiddler results:

    CONNECT mydomain.hybridproxy.powerbi.com:443 HTTP/1.1 200 Blind-Connection Established () Fiddler: This is a CONNECT tunnel, through which encrypted HTTPS traffic flows. GET http://myDMGcomputer.ad.mydomain.com:8051/Redirection.OData/mydatasource?token=... 502 Fiddler - DNS Lookup Failed (text/html) Fiddler: DNS Lookup for myDMGcomputer.ad.mydomain.com failed. The requested name is valid,

    but no data of the requested type was found

    Oh dear.  There's actually no local intra-domain traffic before the attempted client->cloud tunnel connection returns a 502 Bad Gateway.

    At least we're now resolving the remote name! :-) 

    The problem lies at the OData endpoint, myODatasource


    By the way, can you (or perhaps you could ask someone else) to help address the architectural questions I posed at the end of my last post?  I'd really like to understand more about the internal architecture of the authentication handshake and the data transfer. 

    In particular, from everything I've read, it seems that although both DMG and the client Power Query must be on the same corpnet and domain, the intention is that data is to be transferred not directly, but via the cloud.  Is this true?

    Cheers, Donna


    Donna Kelly


    • Edited by Lady Donna Wednesday, August 13, 2014 5:54 PM
    Wednesday, August 13, 2014 5:52 PM
  • By the way, I tried with both signed in and signed out (with my ONMICROSOFT ID) and got 502 in both cases.

    Donna Kelly

    Wednesday, August 13, 2014 6:03 PM
  • Curt,

    just for fun, I tried running Power Query from the DMG box.

    It timed out, so I did your trick with #duration, and it timed out again. :-(

    Interestingly, on this box, I've been getting a 307 - Temporary Redirect.  The traffic looked like:

    	
    919	307	HTTPS	mydomain.hybridproxy.powerbi.com	/ODataService/v1.0/OWLdatasource/	0	no-cache; Expires: -1		microsoft.mashup.container.netfx40:8620	
    
    #	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	Comments	Custom	
    922	 - 	HTTP	myDMGcomputer.ad.mydomain.com:8051	/Redirection.OData/OWLdatasource/?token=...	microsoft.mashup.container.netfx40:8620			
    		
    

    which is a GET followed by a redirected GET (as you would expect) 

    GET /ODataService/v1.0/OWLdatasource/ HTTP/1.1 GET /Redirection.OData/OWLdatasource/?token=...<big token>...

    ...Host: myDMGcomputer.ad.mydomain.com:8051

    I find it interesting that this time, I didn't get a 302 Bad Gateway.  Dunno what happened at the hybridproxy end between then and now . . .

    Cheers, Donna


    Donna Kelly

    Wednesday, August 13, 2014 8:41 PM
  • Hi Donna,

    Please keep me updated on your findings! I'm having the same errors without the remote host being unresolved. From everything I've read, it would seem that you could access the OData feed directly through Power BI, regardless of location, since the refresh works after all...very odd.

    I'll keep looking and post what I find. Anyone from Microsoft have any input? They need to add this functionality for sure.

    Mark

    Friday, August 15, 2014 3:02 AM
  • Hi, Donna

          To help me further understanding your issue, would you please 

    1. prepare(revert) your environment as you described in the initial thread.

    2. make sure you still repro the timeout.

    3. check the windows event log of Data Management Gateway.

        Event Viewer -> Applications and Services Logs -> Data Management Gateway

    4. share the detail with me if you think it is appropriate.

    Btw, may I know how large is your database?

    If you do have a huge amount of tables/views, timeout issue could be much easier to repro.

    And Curt's suggestion to increase the timeout threshold is helpful in common cases. 

    Thanks & Best Regards

    Tiancong

    Friday, August 15, 2014 9:30 AM
  • Thanks for the comment, Tiancong but please don't forget that the issue has now metamorphosed.  The timing issue has gone away, and I've found that I'm really dealing with a bad gateway.

    Hi, Donna

          To help me further understanding your issue, would you please 

    1. prepare(revert) your environment as you described in the initial thread.

    Sorry . . . dunno what you mean by this

    2. make sure you still repro the timeout.

    I can confirm that without a hostsentry, a timeout is the result

    3. check the windows event log of Data Management Gateway.

        Event Viewer -> Applications and Services Logs -> Data Management Gateway

    4. share the detail with me if you think it is appropriate.

    Zip on the log . . . like no entries at all.

    Btw, may I know how large is your database?

    Miniscule . . . it's a tiny 400 row demo system with 15 tables

    If you do have a huge amount of tables/views, timeout issue could be much easier to repro.

    According to Fiddler, the 502 Bad Gateway happens straight away (less than a  second).  The timeout happens a minute later.  Clearly, it's not actually a timeout problem!

    And Curt's suggestion to increase the timeout threshold is helpful in common cases. 

    As I noted above in the post timed Wednesday, August 13, 2014 8:41 PM, I did try Curt's suggestion, and there was no change in the result.

    Thanks & Best Regards

    Tiancong

     What I'm going to do next is buy a new computer (so it is absolutely clean), install a fresh copy of Office 2013 from the Microsoft Partner Website, and try this again.  I will do that on Sunday (I've asked for expedited delivery on Sunday).

    If that fails, then I will build a new clean server, put a fresh copy of SQL Server 2012 on it, install an new DMG, and see how that flies. Thinking about it,  I'll do that tomorrow anyway.

    I've got a client meeting on Tuesday, and I'm fast running out of ideas :-(

    Cheers, Donna


    Donna Kelly



    • Edited by Lady Donna Friday, August 15, 2014 9:59 PM
    Friday, August 15, 2014 9:54 PM
  • OK, here 's the results of the latest test, with the same kit / environment.

    After verifying the DMG box as best I can, I looked at the client box.  First, I fired up Fiddler on both boxes.  Then I went to the Power BI admin center on the client machine.  I went to data sources, tested the connection, and got a green light. I clicked on the data source, and went to data settings.  I was able to enumerate the database tables from the client machine. :-)   The DMG event log acquired these entries:

    Successfully connected to the database:OWL on the server: VALENTINA
    Activity ID: 860f42d6-d7b8-487d-824e-ca8daa7a6fe5
    Succeeded to enumerate tables and views from database:OWL on the server: VALENTINA
    Activity ID: 9afddaea-39f8-43a2-87f4-4cff5cc21e99

    and Fiddler reported good traffic.   Thus, all is good regarding the communication channels, DMG box to cloud access from client!

    So, I fire up Excel, and attempt to use Power Query (not signed in).

    Surprise, surprise, I get a 502 bad gateway.

    I click sign in on the Excel 2013 ribbon, and get an automatic sign in with my organizational account.

    Lo and behold, another 502 Bad Gateway.  I go back to the DMG box, and there are no more entries in the DMG log.  

    Clearly, the fail is on the initial attempt to handshake from Client machine Excel 2013 Power Query to the hybridproxy.powerbi.com website.  

    (BTW, checking/not checking the Enable Cloud Access checkbox makes no difference.)

    I will try the additional tests I outlined above . . . but I fear they are not going to help.  The resolution of a 502 Bad Gateway lies in those who created the gateway.  That's Microsoft, and there's zero I can do about that.


    Cheers, Donna




    Donna Kelly

    Friday, August 15, 2014 10:55 PM
  • Hi Folks . . . so I built another server, and put SQL 2010 on it.  I went to the Power BI website, created a new gateway, an new gateway instance, and a new data source.  I downloaded DMG, regenerated a key, and got the DMG started and registered, and the connection is green and it says 'running' in the Power BI admin center.

    So far so good.

    This time, I thought, I will not do credentials in the cloud.   I will edit the data source to set the local credentials. 

    Again, the problems are at the hybridproxy.powerbi.com end.

    Here's what happened . . . it is all bad :-((

    I'm on the web page Datasource - connection info

    I hit the Set Credentials button

    I go a 'data source settings' pop-up

    which generated this message:

    Failed to verify gateway 'OWLGatewayinstance2' status.
    The remote name could not be resolved: 'trafalgar.ad.redwingbi.com'
    - You can click "Cancel" to skip editing credential.

    SCREAM! PULLS HAIR OUT. I'M BACK TO REMOTE NAME COULD NOT BE RESOLVED!

    I create a new client.  In Excel on client, I am signed in.
    I enter the 'access an OData feed' pop-up and it says I am not currently signed in.

    It asks for which URL do you want.  I chose the hybridproxy.powerbi.com, and I get a popup.
    I sign in with my organizational account (onmicrosoft.com) and THE REMOTE NAME COULD NO|T BE RESOLVED.

    I try different providers on the website, accessed via the client machine, and I get different errors such as failed to verify and our old friend 502 Bad Gateway.

    I go back to my new server, and repeat the credentials process.  I'm being ultra-methodical, trying every possible combination in turn, running Fiddler and Wireshark on both machines and carefully examining both the web traffic and the local intranet packets, line-by-painstaking-line as I'm going along.  I intend to point the finger of doom at Microsoft for putting out such a crappy product that has already cost me over a hundred hours of pain!!!

    I'm on the new server.  I go to the 'connection info' page.  I've selected SQL Server Native CLient 11.0 as my connection provider, and I hit the 'set credentials' button.

    What's this?  Something new!   Do you want to run the data source manager - it's a downloader message . .  . and I say OK.  I get the data source settings pop-up with a new message at the bottom:  a green check mark and "Data Source Manager initialized successfully".    What can this mean?

    I now have two new data entry boxes!  It's like getting to a new level in Doom (showing my age, now!) .choose between Windows and Database credential type.  I can enter a username and password.  I do so, and the choose Organizational as the Privacy Level.  I chose not to check the Encrypt connection box.

    I can now press the 'test connection button'.  With bated breath, I do so . . . and test connection was successful.   I click ok.  It tells me it is 'Saving credential...".  I go to Fiddler, and see a 200 on a tunnel to my server, over port 8050 (which is kinda odd, because I told DMG to use HTTP which means 8051).  Anybody got any ideas?  Fiddler said the protocol was HTTP, so why not 8051?

    Back at the data sources page, it tells me that 'Credentials not set' for the data source.  I refresh the page, and nothing changes.  I go and test the connection, and it tells me that credentials are not set.

    I run through the same shenanigans again, and Holy Smoke!, I get a running gateway.  I go to data settings, and I see all my tables!  At this point, I'm just about wetting my pants!!!  I select 'em all, and save, and ny data source is 'ready'!  The breath is bated, I fire up Excel 2013 on the DMG box, and do a Power Query from OData feed, enter the URL of my new data source, and hit OK.  Goodness!  I get the Navigator panel, and Fiddler is showing a bunch of tunnels and a 200 redirect.  I remember to breath . . .and it's still loading . . . and it's still loading . . .(gee, it's slow) . . . and I get a bunch of tables.  WOW!

    I try a tiny one with eight rows, and it says 'loading data' . . . 'loading data' . . . gee, this is really slow . . and a minute later, it's loaded the 8 tables.  They are there!

    Now for the client machine!

    AND IT BLOWS UP! From Excel, we get the famous 502 Bad Gateway! 

    My new computer should be available tomorrow, and I will set up a brand-new, fresh client on it.  We shall see what we shall see.


    Donna Kelly


    • Edited by Lady Donna Saturday, August 16, 2014 8:56 PM
    Saturday, August 16, 2014 8:55 PM
  • Hi Microsoft people,

    is there anyone around who can answer the questions that have been posed?

    ---------------------------------------------------------------------------------------------------------

    Hi Ed,

    umm . . . I would appreciate it if you could expand on your answer.

    You say "the OData feed requires the client is in under the same domain with gateway". 

    But surely that defeats the purpose of OData?  I thought the idea of OData was that it's accessible anywhere, from any device, as long as you could authenticate your access rights.

    Specifically, I thought that if I used the organisational account I used to set up the Data Management Gateway, then that account would be able to access the OData datasource.  Indeed, testing the connection in IE11 from the client computer indicates Ready and connection successful . . . which means that the client computer can indeed see the remote database.

    I guess I just don't understand the limitations of Power Query very well.  Are you saying that if someone is trying to use their personal tablet for work (which is obviously not on the corporate domain) then it's not going to fly?

    It would be a kindness if you would expand your answer, and perhaps provide some URLs to further in-depth technical discussions.

    ---------------------------------------------------------------------------------------------------------

    Hi Ed

    umm #2 . . . :-)

    I found this page "Access OData Feeds from Power Query" http://office.microsoft.com/en-us/office365-sharepoint-online-enterprise-help/access-odata-feeds-from-power-query-HA104079175.aspx

    which said "The Power Query client must be located in the same corpnet with the machine hosting the Data Management Gateway; otherwise, the Power Query client cannot gain access to the data included in the OData feed."

    And it occurred to me that a small business which wants to get rid of their desktops and go to Office 365 cannot do that if the business also wants to use Power BI.

    I must be wrong about this, surely, but it would seem that Office 365 Excel cannot use Power Query

    a) because you cannot add an add-in to Office 365, and

    b) regardless, it's not on the corp domain anyway.

    The way I'm reading this stuff so far is that Power BI requires a desktop running Excel 2013 with the downloaded Power Query add-in and the desktop must be on the same domain as the machine running the Data Management Gateway.  Is that true?

    ---------------------------------------------------------------------------------------------------------

    . . . what is the purpose of hybridproxy.powerbi.com?

    More generally, do you know of any documentation on the architecture and internals of Power Query and Data Management Gateway?  It would be extremely helpful!

    ---------------------------------------------------------------------------------------------------------

    By the way, can you (or perhaps you could ask someone else) to help address the architectural questions I posed at the end of my last post?  I'd really like to understand more about the internal architecture of the authentication handshake and the data transfer

    In particular, from everything I've read, it seems that although both DMG and the client Power Query must be on the same corpnet and domain, the intention is that data is to be transferred not directly, but via the cloud.  Is this true?

    ---------------------------------------------------------------------------------------------------------

    Help, please

    Donna


    Donna Kelly



    • Edited by Lady Donna Saturday, August 16, 2014 9:11 PM
    Saturday, August 16, 2014 9:09 PM
  • Hi, Donna

          Your thread really has a lot of questions and issues and I don't know how to get started.

          My suggestions are

    1. please make your environment clean, NO host entry, NO fiddler.

    2. I assume you install the Database and DMG within the same box, go to Power BI admin center from the DMG box, and try "Test connection" and “list Tables/Views”

    3. From your domain controller box, go to Power BI admin center and try "Test connection" and “list Tables/Views”

    4. From your Excel box, check whether you can reach the DMG box,then still go to Power BI admin center and try "Test connection" and “list Tables/Views”

          In ideal cases, all of these steps should success. If so,

    5. In power query, paste the Odata feed URL from admin center, and see whether you still got timeout or 502 bad gateway.

          Considering possible privacy concerns in details sharing, you may also contact me directly via tche@microsoft.com. Or you may leave yours.

    Thanks & Best Regards

    Tiancong

    Monday, August 18, 2014 4:22 AM
  • Tiancongchen, 

    Are you saying then that it is possible to access the OData feed from a computer outside of the corpNet? I also tried to access it at home and I could not (remote name could not be resolved). I was able to refresh my reports in Office 365 from my home computer - so the gateway is working and connected to the corporate SQL database. If they can see each other and transmit this data, why won' the OData feed work in Power Query?

    Tuesday, August 19, 2014 2:21 PM
  • Dear All,

    sorry I've seemed to drop the ball on this, but I'm only just now recovering from Chicken Pox (Yuk!).

    First of all, thank you all for your helpful comments.  

    Now, turning to Tiancong, I'd offer these thoughts to each of your points:

    Point 1.  

    Regarding Hosts entries, what did you think of this thread The remote name could not be resolved?   In this thread, I show that this not an appropriate strategy, and when the Hosts entry is removed the errors that result are such that the old thread was inappropriate and theis new one started.

    Further,  I posed many questions to your colleague, Ed Price.  Perhaps you could get him to address some of the questions?

    You say "no fiddler".  Why?  Wireshark and Fiddler are standard tools to intercept and display HTTP traffic and IP packets.  What possible effect could these sniffers have?  I'm baffled as to why you say "no fiddler".

    You say "make your environment clean".  I don't think I can make things any cleaner than building a new server and buying a brand-new client! :-)

    Point 2.

    You say "I assume you install the Database and DMG within the same box".  I did say that I built a new server, and I did buy a new client, after trying two clients and one server.  In short, I did say that I have triedsix different combinations of three clients and two servers.  Your assumption is not correct.

    Points 3 and 4.

    I did say that Test Connection was showing green in all cases, and I did say that I was able to List Tables.  That applies to all servers, all clients, and the domain controller.

    Points 5

    DataSource.Error: OData: Request failed: The remote name could not be resolved 'mycomputer.ad.mydomain.com' 

    It is still broke.  Worse, we're back to where we started.  It is all very Sysiphean. :-(

    The only common thing between all failure modes is the hybridproxy cloud service.  I wonder if I could destroy the Power BI site and re-create it . . . anyone got any thoughts on that?

    Donna



    Donna Kelly

    Thursday, August 28, 2014 10:42 AM
  • PoeticMadness,

    I'd like to offer you some thoughts on the way I think this ought to work (not that is necessarily does, you understand, just what I think it ought to do!).

    Seems to me that it's dead easy to make SQL Server expose an OData endpoint directly, with no need for a cloud service.

    Seems to me that the purpose of the cloud service is therefore to dis-integrate the feeds, and act as a centralized broker . . . and manager of credentials.

    I have a domain account, which with I access domain resources like my databases.

    I have a Microsoft Online account (onmicrosoft.com), with which I access my cloud resources, like Power BI.

    I can store my domain credentials in the Power BI admin center - datasource, connection info, set credentials, data source manager, data source settings- and this allows the cloud service to see my on-prem data (hence I can Test Connection, List Tables, and so on).  I have selected options so that '...credentials to access the database are stored securely in the cloud credential store'.

    At this point, the cloud service is allowed to get hold of data from the on-prem database.

    I then set data source usage for the datasource to 'Enable OData Feed'.  This ought to mean that the datasource is exposed to cloud users, who can then access an OData feed with an endpoint as defined in the URL  

    OData Feed URL: https://mycompany.hybridproxy.powerbi.com/ODataService/v1.0/mydatasource

    I then ought to be able to bring up Excel on a client box, fire up Power Query, point it at the URL, using my onmicrosoft.com credentials, and see the tables in the data source.  Of course, I get the famous not resolved error :-(

    But I think, that if all this works as |I think it ought to do, then it implies that - as you say - it should be "possible to access the OData feed from a computer outside of the corpNet".

    Two points:

    (a) OData feeds in general - by definition - do not require a domain logon.

    (b) Power BI gateway management allows for credential management for access by the cloud to the on-prem; Power Query first asks for a sign in with an organizational account (not the domain account) and then From Other Sources, From OData Feed asks for a URL to get the right cloud datasource.   

    The implication is that the cloud service ought to be acting as an intermediary . . . and as long as you have an onmicrosoft.com organizational account, you should be able to access hybridproxy.powerbi.com intermediated OData from anywhere.

    Cheers, Donna


    Donna Kelly

    Thursday, August 28, 2014 11:18 AM
  • PoeticMadness,

    please see my new thread Data Management Gateway Architecture, Authentication, Resolution and Configuration

    I have an answer for you . . . 

    Cheers, Donna


    Donna Kelly

    • Marked as answer by Lady Donna Saturday, October 18, 2014 11:48 AM
    Thursday, August 28, 2014 1:04 PM
  • Hi Donna/Mark,

    We'll publish a whitepaper to introduce what's going on with the gateway. If you'd like, please ping me such that I can share with you a deck presented at PASS BAC with detailed info about the OData. Please reach out to me with qizh at microsoft.com. Looking forward to talk to you.

    Samuel

    Tuesday, September 16, 2014 2:17 PM