I have an Azure VM with SSAS Tabular Model.
I understand that using Virtual Network it can be accessed from On-Premise.
But is it possible to access it using DAX queries without creating Virtual Network?
Short answer: No - you need a Virtual Network in this scenario (link)
Long answer: Maybe. It might be possible to use HTTP Access to SSAS via IIS but I've never tried it nor have I come across any blogs/whitepapers where it has been tried.
Is there a specific reason why you want to avoid setting one up? It really does make things much easier in Azure.
we use an HTTP proxy
Just set up as normal but remember to configure an endpoint on the TCP and SSAS ports in AZURE
Related
I have an Azure SQL Managed instance with public endpoint disabled (we store sensitive data and do not want an exposed endpoint on the DB). We have a VNET and when we need to access our SQL managed instance from an administrator's machine, we use a VPN. How do I connect Power BI to my SQL Managed instance for reporting? I've been digging and am surprised that the only way I can see is to either:
Create a virtual machine and host a data gateway
Expose the public endpoint on the SQL Managed instance.
I may accept 2 if I can limit access to Power BI itself but I'm not convinced that's possible.
Any suggestions are welcome!
You can also secure the public endpoint allowing access to powerBI only using Azure Service Tags. Documentation can be found here https://learn.microsoft.com/en-us/power-bi/admin/service-premium-service-tags
I'm confused with some of these supposed solutions since I'm looking at PowerBI.com and it only has 4 options and managed instance is not one of them....
See: Create Dataset - Databases & More option and there's only 4 options for connecting to a database... That's it folks.
Sure you can connect from desktop but that won't do you any good once you publish it to powerbi.com unless that site supports connecting to the source.
Yes you can create a gateway which I believe is currently the only solution. Why oh why isn't Managed Instance one of the options for databases when you create a dataset on powerbi.com? That tells me they do not support it, regardless of whether you've enabled public endpoint. As far as I know you still would have to use a gateway to access it if it's not one of these options. Or...something silly like create Azure REST services just to talk to your database.
I have a Web App (Azure App Service) and I have an Azure SQL Database that this Web App talks to. I have two questions regarding communication between the two.
When connecting from the Web App to the Database (using the connection string), does the communication go out to the internet and then back into Azure or does Azure know to keep the traffic locally in Azure?
I have been looking into V-Net Service Endpoints as a possible way to improve speed of communication between the two. It is said that when connecting from a VM on V-Net with Service Endpoints enabled to a SQL Database, that Azure knows to keep the traffic internal to the Azure network and not go out to the internet, is this the same for Azure App Services?
Is it possible to keep traffic between an App Service and SQL Database internal to Azure? If so, how do I go about doing this? Any guidance on this is greatly appreciated.
It knows to keep it local on the "Azure backbone" (as per Azure doco). It doesn't go out to the public internet
Yes
Yes. It is already internal to the "Azure Backbone"
Having said that.... networks are really complicated.
As I understand it the main benefit of V-Net is that you can define your own network and add things to it like firewalls, security groups, subnets, peering between networks. Also it helps when setting up a hybrid network - i.e. connecting Azure resources to an on-premises network. When you can set up the same kind of structures as on premise, it's easier to 'transparently' make it part of the on-premises network. Lastly (rereading the doco), you can remove any incoming public IP firewall rules. These are "Azure backbone" IP addresses but they are also "public internet" addresses
There may be a performance improvement if the App Service and Azure SQL are on the same V-Net.
Azure SQL service endpoints are a bit mysterious. They "connect" to the VNET but you still need to connect to a public address. They don't actually take a up a local IP adress.
Depending on what you are really doing, you might want to look into private endpoint, which actually assigns a private IP to your Azure SQL.
Yes, communication between Azure App Service and Azure SQL Database is "local" within the Azure Virtual Network and does not go out to the public internet.
Scenario :: we want to enable communication between on-premise SQL Server and Azure SQL MI which should be super secure and fast.
After researching a lot, we have found two solutions::
Public endpoint
Site to Site (VPN)
Question :: now we are confused about which way we should go-ahead and Why?
Requirement :: have connectivity between on-prem SQL server and Azure MI so that we can push data to Azure SQL MI via a custom-built application.
The VPN option is difficult to configure if you are not a network expert. You need to have good knowledge of VNet, ExpressRoute and VPN P2S and understand new notions of Azure networking. The VPN option does not provide separation of duties. The VPN option has also some known issues in terms of throughput so the endpoint gives you better performance.
The public endpoint option is easier to configure and allows for separation of duties. Your database administrator will enable the endpoint and the network administrator will make accesible the endpoint by opening port 3342 and provide a UDR route. Your DBA will need RBAC permissions on scope Microsoft.Sql/managedInstances/* while your administrator will need permissions on Microsoft.Network/*.
The problem I have is that we're trying to use our WebApp in Microsoft Azure to connect to an external SQL-database (not our own) through a VPN. The SQL-database is only allowing connections from our local IP-addresses that we put up as a Network (for example 176.0.0.0/24).
We are now connected to the same virtual private network, and through our Azure-VM we can now connect to the SQL-Server through SQL Server Management Studio.
Now we want to do the same with a WebApp, but we're not getting through to the server. It gets "Not authenticated" before reaching the SQL-Server (probably the server isn't accepting our IP from the WebApp).
The different problems I have tried to look through is:
Do we only try to connect through our Outbound IPs?
Is the WebApp not connected to the VPN?
I have unfortunatley not found any real answers, and neither any solutions to my problem. If you have any ideas of how to solve our problem, or maybe know how I could tunnel all of the SQL-calls through the VM, the help would be very much appreciated!
Hybrid connection is one option. What you can also do is enable point-to-site in your VPN. Once you do that, you can directly integrate your web app to the vnet and your connections will work. (Go to your web app -> Settings -> Networking -> VNet Integration)
If your Vnet is V1(older way of creating VNs) then enabling point to site is very straightforward. You can do it through portal. For V2 Vnets you have to do it through powershell commands.
Here is a link for the documentation which explains both the options.
https://azure.microsoft.com/en-in/documentation/articles/web-sites-integrate-with-vnet/
There's a way to "tunnel all of the SQL-calls through the VM". You may want to use hybrid connections (cf https://azure.microsoft.com/en-us/documentation/articles/integration-hybrid-connection-overview/).
The principle is to have an agent installed on the VM that can access the database with the correct IP address.
Suppose you can access the SQL DB as mysqldbsrv from the VM. You add an hybrid connection associated to your web app, you install the agent on the VM. Then, when you connect to mysqldbsrv from the Web App, you go through the VM.
So I'm building a pretty simple application in Access 2013, and our company recommended using Azure SQL Database for the backend (due to the cost and simplicity of setting up/maintenance). However, their recommendation left us with a massive problem. Port 1433 is blocked on our company's network, and it's such a big company, I can't get it unblocked.
I don't know too much about having a middle-tier, but what are my options here? Is there a simple way to connect to the database without accessing this port?
Thanks
You could fire up a Azure VM with SQL Server already installed. Then you should be able to change the ports to your liking.
Check out this post...
http://roberteichenseer.wordpress.com/2012/07/06/nderung-default-port-sql-server-innerhalb-einer-azure-vm/
You only need to open up 1433 outbound in your works firewall not the 1433 inbound.
Most security teams are ok to open the outbound port. Opening the outbound will give you the access to connect and access the data inside Azure.