Connect to Azure Service Bus from a Worker Role using AMQP - azure

I am trying to connect to my Azure Service Bus from my Worker Role using AMQP. However, I get a time-out exception. When I use a network sniffer I see that it is trying to communicate to the Azure Service Bus using port 5671. But it's not sending an ACK message, it just times-out. I try this from Visual Studio 2015 with the Azure Emulator.
When I try exactly the same, from the same computer and network interface, but then from a normal command prompt application (so no Azure Worker Role and/or Emulator), it works. My application is able to send an ACK package to Azure and receives a Server Hello from Azure.
Is the Azure Emulator or the Worker Role blocking some ports by default? Why is it working from my command prompt application but not from my Azure Worker Role? I use the same connectionstring and the following code:
TopicClient client = TopicClient.CreateFromConnectionString(_connectionstring, _queueName);
client.Send(new BrokeredMessage(msg));

I finally found the issue. In the solution which uses the Azure Emulator, I included the following package:
<package id="WindowsAzure.ServiceBus" version="2.5.1.0" targetFramework="net451" />
In my console application I used the following package:
<package id="WindowsAzure.ServiceBus" version="3.0.9" targetFramework="net46" />
So changing my Azure solution to version 3.0.9 solved the problem. Seems like Microsoft introduced a breaking change in version 3.x.

In order of likelihood, I'd guess the issue is that:
_connectionstring has different values in VS vs. your Console application; perhaps due to the configuration files used at runtime and/or however you are loading the connection string. I'd recommend re-trying your test with hard-coded values in CreateFromConnectionString() to rule that out.
There is a firewall blocking the port (Windows Firewall, corporate network, etc.)
There is an antivirus interfering with the traffic

Related

Azure Data Factory Integration Runtime Going Into Limited State

My team have created an IR in an on-premises VM and we are trying to create a Linked Service to an on-prem DB using that IR
Whenever we click on Test Connection in the Linked Service, the connection fails and IR goes into a limited state
We also whitelisted the IPs provided by Microsoft for IR ADF and also checked the network traces and all seems fine there
Also, we stopped and restarted the IR, uninstalled and installed it again but still the problem resists
Have anyone faced a similar kind of issue?
As this has been a long time we are facing this issue which has now become a blocker for us
Thanks!
This is observed when nodes can't communicate with each other.
You can Log in to the node-hosted virtual machine (VM). Go to Applications and Services Logs > Integration Runtime, open Event Viewer, and filter the error logs. If you find the error System.ServiceModel.EndpointNotFoundException or Cannot connect to worker manager
Follow the official documentation with detailed steps for Troubleshooting Error message: Self-hosted integration runtime node/logical self-hosted IR is in Inactive/ "Running (Limited)" state
As it states:
try one or both of the following methods to fix:
- Put all the nodes in the same domain.
- Add the IP to host mapping in all the hosted VM's host files.
I ran into same issue. Our organization has firewall rules preventing specific ports or url's from outside network. We added Data factory services tags with internet facing in Route table, and IR then connected successfully.

WorkerRole in Azure Cloud Service net connection

This afternoon I have uploaded my WorkerRole in Cloud Service on Azure, this service run on VM with Windows Server 2012. I have realized that WorkerRole can't get query from Databases (BigQuery, TSQL). When I have read the service log in VM I have seen the following error:
The VM and host networking components failed to negotiate protocol version '5.0'
I think that Hyper-V-vsc has something to do. Anybody knows what happens?
Thanks,
Roger
First thing I could check is to make sure the databases you are trying to connect too have whitelisted the VIP for the cloud service you're connecting from. And if you haven't already, remote into an instance of the worker and try reaching the DB's using a thin a client UI as you can.
In my experience, these issues are usually on the db end. Azure doesn't do much with blocking outbound connections. Those that fail are usually more a matter of protocol (UDP multicast for example).

Does azure's simulator use real connection from config for service bus?

When I use service bus locally with azure simulator it requires real connection in config like this
<connectionStrings>
<add name="StorageConnection"
connectionString="DefaultEndpointsProtocol=http;AccountName=***;AccountKey=***" />
<add name="Microsoft.ServiceBus.ConnectionString"
connectionString="Endpoint=***;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=***" />
</connectionStrings>
Sometimes when I run it locally it seems that service bus tasks that I handle came from real connection described in config. But I'm not sure about this. And it is arbitrarily I cann't check it properly. So when service bus is started locally does it use real connection or not? If not why it requires for starting service bus with azure simulator?
The Azure emulator does not include a Service Bus emulator, only a Compute emulator (web/worker roles) and a Storage emulator (blob/table/queue).
You'll either need to use the Azure Service Bus directly or install Service Bus locally (you can install to Windows 7 sp1 and Windows 8 for dev purposes). Information about Service Bus for Windows Server is here.

Azure Connect won't connect

Just installed azure connect on my localhost, but it won't connect. I see my machine dbates-HP as a active endpoint in my vistual network/connect section on my azure portal and organized it into a group.
I can see in the azure connect portal that the machine endpoint is active, and that it refreshes since the last connected updates.
My local connect client lists the following diagnostics messages:
Policy Check: There is no connectivity policy on this machine.
IPsec certificate check: No IPsec certificate was found.
Also tried with firewall turned off.
Duncan
In some scenarios getting Windows Azure connect to working becomes very complex. I have worked on multiple such scenarios and found most common issues are related with network settings. To start investigate you need to collect the Azure Connect logs first from your machine and try to figure the problem out by yourself. I have described some info about collecting log here:
http://blogs.msdn.com/b/avkashchauhan/archive/2011/05/17/collecting-diagnostics-information-for-windows-azure-connect-related-issues.aspx
To open a free Windows Azure support incident please use link below:
https://support.microsoft.com/oas/default.aspx?gprid=14928&st=1&wfxredirect=1&sd=gn
Have you "linked" your Azure role with the machine group you created? The message "There is no connectivity policy on this machine" suggests that you haven't defined (in portal) to whom this machine should connect to.

Windows Azure Platform Ready Testing Tool

I am running the platform ready test tool to try and qualify for the Powered By Windows Azure Logo Program.
My application is in production and has been running in azure for 5 months now. The application consists of a windows forms and WPF Client application which connects to a set of WCF Services running in azure which in turn connects to SQL Azure. The application also uses blob storage in Azure and I have getting on for 1TB of documents up there.
The application uses basic http binding and is configured Like this
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
I successfully passed the test for SQL Azure but failed the test for windows azure with the following message
======================================================================
Test case/Verification: TC 1 -
Application must be a valid Azure
application designed to connect with
or work in the Windows Azure Environment
======================================================================
Status is ProtocolError
Fail
The only thing I can think of this is causing this is that the application connects over https and the test tool does not allow me to specify a https endpoint. However I don’t think I can easily expose a plain http endpoint just to pass the test as WCF wont allow me to do that when TransportWithMessageCredential is used.
Does anyone have any ideas?
Our service AzureWatch is in the same boat. I've been in touch with MS engineers at the Ready program and they don't appear to support our precise scenario. However, they do have a version of the tool that can use https channel. I suggest contacting them via support channel. They may supply you with a later version to try, and if that fails with forms to request "bypass" of the actual testing
HTH

Resources