I cannot connect to either my SQL Server instance hosted on an Azure VM or my Azure SQL Server Database using on-premise Power Query or Power BI Desktop. I CAN connect using the Excel DATA ribbon or PowerPivot but, using the same server name and credentials, cannot connect using Power Query.
I have tried the following, none of which solved my problem:
Added Inbound TCP rule for port 1433 to Azure VM
Added Outbound TCP rule for port 1433 to local machine
Ensured that my Azure SQL Server Database allows Windows Azure
Services
Ensured that my Azure SQL Server Database allows all relevant IP
addresses
Tried both DNS and IP address as server names
Used IP address, Port as server name
Ensured that the Azure SQL Server VM SQL credentials have full admin
rights
Connect to SQL Server VM from Power BI Desktop downloaded onto the
same VM
Not sure what else to try. How is it that I am able to connect through PowerPivot but not Power Query or Power BI?
I get the following error after I enter server name and credentials and hit connect: "The user was not authorised"
What am I missing?
It sounds you are actually logging in OK, but on connection Power Query / Power BI is doing something your user is not allowed to do. Most likely it is when Power Query scans the schema of the target server for tables, views and TVFs.
From my understanding the main difference/improvement with PQ over PP & Excel Get Data is being able to call TVFs, so I would look at your permissions in that area.
Test #1 would be to make the PQ connection as a SQL sysadmin user to confirm my suspicion (i.e. PQ will work OK).
Related
I deployed a web app on Azure App Services. When web app tries to connect to the Azure SQL Database connection failed.
I downloaded the event log from Kudu, I found the following error message:
Cannot open server 'servername' requested by the login. Client with IP
address '**************' is not allowed to access the server. To
enable access, use the Windows Azure Management Portal or run
sp_set_firewall_rule on the master database to create a firewall rule
for this IP address or address range. It may take up to five minutes
for this change to take effect..
On Azure portal I found how to set server firewall by adding a range of client IP addresses (with lower bound and upper bound) according your client IP address. For instance, if client IP address is 00.000.000.09 the range of IP addresses is: low bound (00.000.000.0) and upper bound (00.000.000.255).
I set the server firewall for the IP address assigned to my Azure App Services account and also for my local machine to connect to Azure SQL Database from SQL Server Management Studio. After setting firewall, I can connect to Azure SQL Database with SQL Server Management Studio. Unfortunately unable to connect from web app. When I download event log from Kudu I find the same message error.
Someone could help to solve that issue.
Thanks.
Go to your SQL Server in Azure Portal.
Go to "Firewall and Virtual Network".
Turn on "Allow Azure Service and resources to access this server".
Allowing Azure Service and resources to access this server may not be the correct approach. This may be a security issue in many cases. We have to create managed identity and assign to webapp or sql server where required.
How do I make connection to an AWS hosted database, and pull or query data into a local or Azure hosted SQL server DB? Can I be directed to the right place or resource?
Thanks.
There's nothing special about the fact that they're in AWS or Azure VMs. For this to work, you need TCP/IP connectivity from your client to the server, and you need port 1433 to not be blocked along the way.
The VM in AWS or Azure needs to have an externally visible IP address, or you need to be connecting via a VPN to the internal network of the cloud-hosted system. The operating system on that VM that's hosting SQL Server needs to have a firewall rule that allows port 1433 inbound.
Once you can do that, you can then just set up a Linked Server on your end, that refers to the SQL Server at the other end. That will allow you to query the tables on the server via 4 part names i.e. linkedservername.databasename.schemaname.tablename.
If you have SQL Server with the same collation at both ends, also ensure you set "collation compatible" on the linked server configuration. (It can make a huge performance difference)
Problem:
When connecting to an OLAP cube via Excel by using Windows authentication we receive this error: "An error was encountered in the transport layer"
When connecting to Analysis Services via SQL Server Management Studio 2008 R2 by using Windows authentication we receive this error: "Cannot connect to Lake. A connection cannot be made. Ensure that the server is running."
The thing is that a connection with a proxy user via an automated SQL Server job in which the cube is deployed and processed worked. Using the credentials of that user when trying to connect to Analysis Services via SQL Server Management Studio however, does not work.
The server, on which the cube is deployed, is named Lake and is definitely running. Also, the connection to the database engine on Lake is possible.
What could cause this issue? Why is it possible that a proxy user can update the cube in a SQL Server Job but the very same credentials cannot be used to manually log in to the Analysis Services server?
It is possible that the SQL Job uses credentials of a Service Account - most likely SQL Server Agent (NT Service\SQLServerAgent) or Analysis Services (NT Service\MSSQLServerOlapService) to connect to the SSAS database and this account has access to the cube but the end-user running this job doesn't have an explicit access, hence the error.
Probably, you try to connect from another domain, than MS SSAS service works. You may check it by connecting with login from domain of MS SSAS server.
I have an SQL Server 2012 instance installed on a Windows Server 2008 R2.
I configured SQL Server for remote access.
I need to access the SQL Server from a machine which is not on the same domain as the SQL Server instance using JDBC. I get the following error
Login failed. The login is from an untrusted domain and cannot be used
with Windows authentication.
I simply need the ability to access the SQL Server from various machines which will not (and never) be part of the same domain as the sql server instance.
Solutions appreciated.
This is a broad question since there are so many factors that can prevent access to your SQL Server. Here are some general tips:
Enable access to certain protocols (TCP/IP, Named Pipes, etc.) via SQL Server Configuration Manager on the db server.
Enable access to port 1433 (the port used by SQL Server) on the db server via Windows Firewall and any network-level firewalls.
If using a Windows user to log in to the SQL Server then make sure this user (or one of the groups to which it belongs) is mapped to a SQL Server login.
So I have a server, being hosted by an external hosting provider. To work on the server, I just need to remote connect with an IP address, a username, and password. When I remote connect, I can open SQL Server Management Studio and work on the databases. I use:
Server Name: (local)
Authentication: Windows Authentication
Username: SERVER\Administrator (Administrator is the username to remote connect)
I would like to connect to the server databases from SQL Server on my local machine. I obviously can't use (local) as the Server Name, and I can't use Windows Authentication.
I'm terrible with configuring things like this, and I really don't even know what to search for. Do I need to set up something in SQL Server on my server? Or can I use the credentials for the server to connect?
You probably won't be able to do this as the firewall will block the port that SQL Server communicates over. The hosting provider probably won't allow this traffic over their firewall as it's a big security risk.
Essentially you're stuck with the remote desktop.
The other possibility is a VPN arrangement or SSH tunneling. See if your provider can support an IPSEC VPN. If you can set up a VPN then you should be able to connect to the server that way.
There are going to be two issues.
The ports will need to be open on the remote server to connect from your machine to the server
When using Windows Authentication, there will need to be a trust relationship between SERVER and the authentication domain for the account running SSMS on the local machine
You can get around 2 by making a SQL Server account in the server (if you have rights to do that) and logging in as a SQL Server user instead of relying on a domain controller for authentication.
1 is not as easy to get around without some kind of VPN or other tunnel. Once you set up a SQL Server user, just try to connect to the machine by IP address instead of (local).