question

Hello @MiKeZZa

I believe that you are planning to use the web activity in ADF to make a API call to AAS . Once you do that and the as client IP ( in this is case the ADF ) is not whitelist , AAS will reject the call . I am assuming that the you are trying to do something when you try to connect to Azure SQL . But I don;t think it will help you much , the IP which comes from the rejected call is the client and not the server IP ,

One other think you you try is to run a fiddler trace and audit the trace once you have connected to the AAS locally . I beleve it will give you the remote IP .

Do let me know how it goes .

---

Thanks
Himanshu

Please do consider to click on "Accept Answer" and "Up-vote" on the post that helps you, as it can be beneficial to other community members

I think this won't work. I can only integrate it all in a VNet but that's not a nice practice because that AAS requests a gateway.

Hi @MiKeZZa ,

What concerns do you have using AAS with a gateway?

If you use an On-Premises Gateway, you can lock the refresh of the cube to that gateway only.
In advanced settings, there is an option ASPaaS \ AlwaysUseGateway which will ensure the gateway is always used when connecting the sources.

Then you just need to connect the subnet the Gateway VM is associated too, to the logical SQL server hosting the Synapse SQL pool.

If you wish to go with the option of using a Self Hosted Integration Runtime to find the IP address of Analysis Services, I was unable to make a web call with MSI authentication using Self Hosted integration runtime, the error was
"Could not load file or assembly 'Microsoft.DataTransfer.TransferServiceLib, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified"

This appears to be a problem with the Integration runtime, because if I run the same call with an Authorization header, it works as expected. I suggest raising a case with Microsoft if you decide to go down this path so they can fix it.

Using this method, you would firstly initiate a POST with /refreshes on your model with the refresh details in the body.
You would then GET /refreshes , which will return a list of the refreshes (unfortunately the initial call doesn't return the refresh id) and find the last refresh id.
You would then GET /refreshes and the ID you picked from the previous step.
And then parse the output for the IP address

After whitelisting the IP address, you can run a POST on /refreshes again with the original body, or use other methods to process the cube.

-Rob

But then we must use VM's and that's a way we don't want to go...

It can still work using the the REST API without a self hosted integration runtime or an on-premises gateway.

You just need to whitelist the Data Factory IP address range on the SSAS firewall (you didn't mention if you were using this), and then whitelist the SSAS public IP on the SQL Server firewall, which can be identified using the API as described above.

-Rob