BizTalk Services deployment

Integration Icon

I finally have some hands-on time with the recently re-released, in preview, Windows Azure BizTalk Services. It didn’t take long before I hit the first hurdle – it took a bit of time to get my BizTalk services account set-up, but lots have been written about this already, so I won’t repeat that, but beyond that – I created my first test project and wanted to deploy it, which didn’t work first time.


What was easily missed is that the deployment from Visual Studio to your BizTalk account uses SSL, established using the certificate you upload during the account creation. This certificate needs to be installed in your certificate store but if, like me and most others, you use a self-signed certificate, you must ensure you also install it in the “Trusted Root Certificate Authorities” store.


Without that the deployment from Visual Studio will fail with the error


The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Continuing with my exploration of BizTalk services I thought I’d start with a simple end-to-end scenario, although it is something that roughly maps to a real customer requirement we have right now -

I wanted a bridge to pick up a file from an FTP location and drop it onto a Service Bus Queue (from which BizTalk 2013 would pick it up, but that’s another story…)


I create a simple pass-through bridge configuration to begin with, with my topic details on the one side and the ftp details on the other -


For the FTP server I deployed a small IaaS instance on Azure and configured an FTP server on it, I then entered all the details for the topic and configured the FTP endpoint.

That done I deployed the solution only to see an error stating -

Failed to connect to the FTP server using specified configuration. Error message - 'The remote certificate is invalid according to the validation procedure.'

It was nice to see such a detailed error an indeed I quickly realised that the Use SSL property on the FTP source is on by default, but I had not configured SSL for my FTP site so I promptly changed that to False and re-deployed.

Unfortunately, this one didn’t work either, and now the error wasn’t that useful - “The underlying connection was closed: An unexpected error occurred on a receive.” – but it was useful to be able to get more details on the BizTalk Services (silverlight based) portal, accessible through the Windows Azure Portal -


In the BizTalk Services Portal there’s a tracking tab, and in that I found the details of this particular issue -


Failed to connect to the FTP server using specified configuration. Error message - 'The remote server returned an error: 227 Entering Passive Mode (100,84,86,13,192,39)..'



As far as I understand this is an issue with my FTP setup more than anything else – it is fair to expect to need to use passive mode for FTP (BizTalk services will block incoming FTP connections required for active mode) and my Azure based FTP server configuration will struggle accepting incoming connection on semi-random ports, which I believe is what’s happening here (and if you want to read more, I found this very useful)

I’ve decided to ignore this self-introduced issue and use another public FTP server I have access to, but it was good to see the level of detailed errors one can get from the BizTalk portal with ease.

With this ‘proper’ FTP server and after a bit more fiddling with settings and re-deploying, it worked and I could see my ‘messages’ being picked up from my FTP location and placed on the Service Bus Queue

Written by Yossi Dahan at 00:00

Categories :



Comments closed