See examples of innovation from successful companies of all sizes and from all industries
Microsoft Azure Data Manager for Agriculture
Azure Data Manager for Agriculture extends the Microsoft Intelligent Data Platform with industry-specific data connectors and capabilities to bring together farm data from disparate sources, enabling organizations to leverage high quality datasets and accelerate the development of digital agriculture solutions
Build, manage, and continuously deliver cloud apps—with any platform or language
Analyze images, comprehend speech, and make predictions using data
Simplify and accelerate your migration and modernization with guidance, tools, and resources
Gather, store, process, analyze, and visualize data of any variety, volume, or velocity
Bring the agility and innovation of the cloud to your on-premises workloads
Connect, monitor, and control devices with secure, scalable, and open edge-to-cloud solutions
Help protect data, apps, and infrastructure with trusted security services
Reach more customers—sell directly to over 4M users a month in the commercial marketplace
[This article was contributed by the SQL Azure team.]
This post was put together by one of our incredible support engineers, Abi Iyer, to help you to troubleshoot some of the common connectivity error messages that you would see while connecting to SQL Azure as listed below:
A transport-level error has occurred when receiving results from the server. (Provider: TCP Provider, error: 0 – An existing connection was forcibly closed by the remote host.)
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. The statement has been terminated.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections
Error: Microsoft SQL Native Client: Unable to complete login process due to delay in opening server connection.
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Section 1: Verify Azure Firewall Settings and Service Availability
1. Login to your SQL Azure portal, Select your project and then switch to the Firewall setting tab. Verify that the SQL Azure firewall is configured to allow remote connections from the IP address(es) that you will be connecting from:
When a computer attempts to connect to your SQL Azure server from the Internet, the SQL Azure firewall checks the originating IP address of the request against the full set of firewall settings. If the IP address of the request is not within one of the ranges specified the connection attempt is blocked and does not reach the SQL Azure server. Blocking by the SQL Azure firewall is usually self evident because the service returns a specific error message similar to the one below:
Cannot open server ‘ljvt54v9zo’ requested by the login. Client with IP address ‘131.107.0.111’ is not allowed to access the server. To enable access, use the SQL Azure 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.
2. On the Databases tab of your portal, select the database that you are trying to access and click the Test Connectivity button. This will prompt for your username and password to use when connecting.
Note: If the Microsoft Services firewall isn’t enabled you must enable it and wait up to 5 minutes for the firewall setting to take effect. If you get a failure sooner than 5 minutes then it isn’t a valid test of whether the service is available.
a. If the connection succeeds the backend SQL Azure services are available and your server and database is online. Proceed to Section 2.
b. If the connection fails, note the Location listed for your server and check the SQL Azure service status for this location in the Azure Services Dashboard. In the event of a known outage you will be able to find more information there. If the dashboard does not reflect an outage you may call Microsoft at 1-800- 642-7676 to report the issue and obtain assistance.
Section 2: Verify that you can reach our Virtual IP
1. Open a command prompt window and use the PING command to confirm that name resolution successfully translates your logical server name to an IP address. The “Request timed out” message shown below is expected because SQL Azure will never respond to ping requests.
C:>ping <myserver>.database.windows.net
Pinging data.sn1-1.database.windows.net [65.55.74.144] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 65.55.74.144:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
a. If the server name resolves to an IP address, note the value and proceed with step 2.
b. If this step fails, contact your network administrator or Internet service provider for assistance with fixing your name resolution problem.
2. From your command prompt window, try to telnet to port 1433 using the IP address returned in the prior step. This will test whether there are any firewalls/routers blocking traffic to port 1433.
C:>telnet 65.55.74.144 1433
Connecting To 65.55.74.144…
a. If Telnet is successful, the window will change to a completely blank screen. Exit and proceed to the next step.
b. If it is not successful, capture the output and move to step 4.
3. From your command prompt window, repeat the test trying to telnet to the DNS name instead of the IP address.
C:>telnet <myserver>.database.windows.net 1433
Note: If Telnet is not part of your default windows installation, you may enable it from Add/Remove Windows Components.
4. Use the tracert utility and capture the output showing the intermediate steps taken while trying to reach the server. This information will be useful if a network engineer is needed to troubleshoot the issue.
C:>tracert 65.55.74.144
Tracing route to 65.55.74.144 over a maximum of 30 hops
1 2 ms 1 ms 1 ms 192.168.0.1
2 6 ms 5 ms 5 ms 10.33.34.50
3 5 ms 4 ms 5 ms 4-1-753.DLLSTX-LCR-07.verizon-gni.net [130.81.107.26]
4 8 ms 5 ms 5 ms so-6-2-0-0.DFW01-BB-RTR1.verizon-gni.net [130.81.28.208]
5 44 ms 43 ms 44 ms so-11-0-0-0.LCC1-RES-BB-RTR1-RE1.verizon-gni.net [130.81.17.40]
6 49 ms 44 ms 44 ms so-6-0-0-0.ASH-PEER-RTR1-re1.verizon-gni.net [130.81.10.90]
If you encountered difficulties in Section 2 then you are not reaching the VIP and are instead being blocked between your client and the VIP. The below steps may be helpful, but at this point a network investigation by your ISP or network engineer is required
Many firewall products allow individual users and domain administrators to block or restrict outbound access on a specific port and or destination IP address. Therefore it is necessary to check the outbound rules that are defined on the local machine as well as any routers or proxies that are in the network path. Rules must allow outbound access on port 1433 to destination IP address range 65.55.*.*. Most firewalls also allow the specification of DNS names to allow. Network products that might block access include:
Firewall rules can also be configured as part of domain policies and hence please work with your domain policies to check if there are any such rules that can block the connection.
2. Other Firewall products
3. Proxy and Routers and other components in your network: Proxies can act as firewall as well and hence please work with your network admin to make sure port 1433 is open for outbound access.
Note that both software (including windows firewall) and hardware must be checked.
Please confirm the external IP address as this may be required to apply the correct firewall rule. You may use this website to find your IP Address
Review the trace by adding a filter TCP.port==1433 which would show conversations on TCP port 1433. If you do not see an ACK back from the server, it is highly likely that the connection is blocked on your network or over the internet.
A network snippet from a connection that was not successful:
Here we can see that the client is trying to establish a connection to SQL Azure and keeps retransmitting three times and fails. This trace indicates that the connection did not even reach our VIP and hence the connection is likely blocked in the client’s network or over the Internet.
The above snippet represents a successful three-way handshake.
6.
SQL Azure Denial of Service (DOS) Guard
:
SQL Azure utilizes techniques to prevent denial of service attacks. If your connection is getting reset by our service due to a potential DOS attack you would be able to see a three way handshake established and then a RESET in your network trace.
Section 4: Accessing Resources
1. Provide complete output (Screenshot) from the following SQLCMD :
