Testing firewall rules on Windows for TCP ports with Telnet

Often times we need to test connectivity on environments to prove that firewall rules have been implemented correctly and it often has to happen before software is installed and configured on the servers.
Firewall rules are implemented by network engineers to let network traffic go through between different computers. The rules have a direction, which means that a rule is setup to allow traffic originating from a computer A (client) to a destination computer B (server) on a certain port of the destination machine. To allow traffic originating from the computer B to computer A, another rule would need to be created.

We will be testing firewall rules to prove that there is TCP connectivity across two machines separated by a firewall. To do that on a Windows OS for the TCP protocol, we can use the Telnet client tool. From the Windows Command Prompt, the command is the following:
telnet <DestinationIpAddress> <DestinationPortNumber>
The Telnet Client tool is not installed by default on Windows and if the command is not recognized on the computer you are on, you can install the Telnet Client tool following the steps defined in the following Technet article: Install Telnet Client. Telnet Client is a Server Feature on Server OS and a Windows Feature on Client OS (Windows 7, 8, 10…).

The problem is that if we use the Telnet command to a port on which no process runs, the Telnet command will fail and we won’t know if Telnet failed due to either:

  • The firewall blocking the connection.
  • The firewall letting the traffic through but there is no process listening on the specified port at the destination server.

The error message is the same in both case and looks like the following:
Connecting To x.x.x.x...Could not open connection to the host, on port xxx: Connect failed
Telnet command failing Telnet command failing

So the obvious resolution is to have a process listening on the specified port and it is where a tool like the Port Listener tool comes in handy. This tool can be configured to listen to TCP or UDP network traffic on any port.
All we need to do is to run Port Listener on the destination computer we want to test connectivity to, configure it to listen on a particular port and then run Telnet from the client server machine.

In the example hereunder we want to test if the TCP port 636 (used for LDAPS protocol) is open.

1. Start Port Listener to listen on TCP port 636 on the destination server:
The screenshot hereunder is an old version of Port Listener which supports only TCP, so make sure to download the latest version which also supports listening for UDP traffic.
Start Port Listener
Port Listener v 1.02 offers the choice to listen to either TCP or UDP traffic:
Start Port Listener

2. Execute the Telnet command from the client server:
Telnet Client Tool

… which now succeeds as Port Listener is running on the server:
Telnet Client Tool succeeds

Cloning (getting) code from Git repository to Visual Studio.

Cloning (getting) code from Git repository to Visual Studio.

There are lots of open source projects hosted on Git repositories as well as bloggers and authors publishing demos, patterns and code samples on web-hosted Git repositories such as GitHub, Bitbucket, Codeplex (Note: Codeplex has several source control options and Git is just one of them)….
It is a very convenient way to distribute code samples so that developers can browse the code through Visual Studio and eventually run it and toy with it.

Nevertheless, I often see people getting code from Git repositories by downloading a zip file, unzipping it and then opening it up in Visual Studio. This is fine but there is actually a better way to grab code from Git repositories through Visual Studio.
The technical term to get code from a Git repository for the first time is to clone the repository. I will here under demonstrate how to get code hosted on a Git repository for the first time (aka clone the repository).
If you have never used Git repositories, you can check previous articles I wrote on the topic and notably where I detail Git support for various versions of Visual Studio: Git TFS Visual Studio Integration.

The sample hereunder shows how to clone a Git repository from GitHub but the principle is the same for every Git repositories:

1. Getting the clone link from the Git repository:

GitHub Clone Link

2. Cloning the repository from Visual Studio:

In Visual Studio 2012 or above, open Team Explorer and click on the Connection button:
VisualStudio Team Explorer Connect
Under the Local Git Repositories section, click the Clone link and paste the link copied in the previous step. Choose a folder on your local machine to copy the code to. Finally, click the Clone button located under.
VisualStudio Clone Git Repositories

3. Opening the Visual studio solution from the cloned repository:

Once the Git repository is cloned, it means it has been downloaded on the local machine and Visual Studio’s Team Explorer window will display the message “The repository was cloned successfully”.
In Visual Studio 2012, there is no direct way to open the cloned Visual Studio solution so we have to right-click the cloned repository and click the option Open in File Explorer to find the Visual Studio solution from the file system:
Visual Studio 2012 Open File Explorer
In Visual Studio 2013, Visual Studio integration with Git is better and we can open the solution directly from Visual Studio. To do so, first open the cloned repository by double clicking on it:
VisualStudio 2013 Open Git Repository
Once in the local Git repository, Visual Studio’s Team Explorer will display the Visual Studio solution and we can double click on it to open it:
VisualStudio 2013 Open VS Solution from Local Repository

Getting started with Azure BizTalk Services

In this article I will explain on getting started with Azure BizTalk Services.
There are quite a few tutorials on the internet but many are outdated since the February 2014 release of Azure BizTalk Services. Moreover, many are not detailed enough for the beginner or do not cover all the necessary aspects to have a complete system ready for development. My aim is to fill this gap and provide a complete, beginner-friendly guide to getting started with Azure BizTalk Services.
Consequently, this tutorial will cover both:
– How to provision a BizTalk Service in the Azure Portal.
– How to install and configure the necessary bits for the development machine so that we can develop Azure BizTalk Services.

I will also focus on some specific aspects related with a playground or development environment and thus considering cost aspects, which are also important for a personal playground environment. We indeed do want to optimize the spending of our hard-earned cash!

Azure BizTalk Services dependencies

First of all it is important to know that BizTalk Services has dependencies on other Azure Services, some of which also have a cost:

  • Azure SQL Database: This is where the Tracking data is stored. See SQL Database Pricing Details
  • Azure Storage: Archived messages are stored in Azure Blobs and Monitoring data is stored in Azure Tables. See Storage Pricing Details
  • Azure Access Control Namespace: The Access Control Namespace is automatically created when provisioning a BizTalk Service instance (deployment). This namespace is used by Visual Studio to deploy a BizTalk Service project to the BizTalk Service deployment.

Cost considerations

Update: there is now a Free Edition of Azure BizTalk Services in Preview!
This tutorial can nevertheless still be used for all editions. The only consequence of the Free Edition on this tutorial is that the actual provisioning of the BizTalk Service is simplified. I cover Azure provisioning in paragraphs 1.1, 1.2 and 1.3 in this article and so only these 3 paragraphs are affected (and simplified). For playground environment it is obviously advisable to first use the Free Edition and go for a Developer Edition when you need some features not covered in the Free Edition. Indeed, at time of writing, the Free Edition is still missing many features. See the BizTalk Services Editions Chart.

Azure BizTalk Services is a PaaS service and as with all cloud services, the pricing is on a per-usage basis.

Azure BizTalk Services comes in several editions (Developer, Basic, Standard, and Premium), see BizTalk Services Editions Chart. Each edition has a different pricing, see BizTalk Services Pricing Details.

Azure BizTalk Services is pricey for a playground environment as, at time of writing, the cheapest subscription (the Developer edition) costs 0.097 EUR / hour, which is about 2.328 EUR / day and amounts to close to 73 EUR / month. So, once we are done with the playground it is advisable to take the BizTalk Service down.
A Backup and Restore functionality exist for BizTalk Services but it is not available for BizTalk Service Developer Edition, it is only available for other editions. This feature would come in handy to avoid paying for the BizTalk Service when we don’t use it so I wish it would also be available for the Developer edition.
Update: A Backup/Restore feature is now available for the Developer edition!
At this time, only the free Edition does not cover Backup and Restore. Moreover, a lot of the MSDN documentation still mentions that the Developer edition cannot do backup/restore but I have had a look and it seems to work.

On top of the cost of the BizTalk Service, 2 other dependencies incur cost as well: Azure SQL Databases and Azure Storage.
While, at time of writing, the smallest SQL Azure Database edition is quite cheap (3,72 EUR / month for a 100 Mb Web Edition SQL Database), it is possible to have an Azure SQL Database for free which is even better for people who neither have their own MSDN account (which comes with free Azure credit) nor have access to one at the office.
So, if all you want to do is to experiment a little with BizTalk Services, the free database will be enough. It is unfortunately not possible to create a free SQL Database from the SQL Database section of the Azure Portal. At time of writing, the only way I know of is to create it from the from the Web Sites section of the Azure Portal.

The SQL Database section of the Azure Portal does not allow for free Database creation:
SQL Database section of Azure portal does not allow for free Database creationThe Web Sites section of the Azure Portal allows for free SQL Database creation:
Web Sites section of Azure portal allows for free SQL Database creation

With this information in hand, you can choose to either go for the free (but extra small) SQL database or go for a paid one.

I will now explain how to provision a BizTalk Service instance through the Azure management portal and how to get the development environment ready. Note that a BizTalk Service instance is also referenced to as a BizTalk Service deployment in the documentation.

1. Provisioning an Azure BizTalk Service Deployment

1.1. Create a SQL Database.

The first step is to create a SQL Database, especially if we choose to go for a free SQL Database. This is because as I have explained earlier, at time of writing, the only way to create one through the portal is by creating a free Web Site.

1.2. Create a Storage.

The second step is to create an Azure Storage. We can also optionally choose to create it later as the BizTalk Service creation wizard offers the possibility to create one with default settings (notably, the replication model is “geo redundant” but that can be changed afterwards). The level of redundancy drives the price, the cheapest being “locally redundant”.

For obvious cost and performance reasons, we should create SQL Database and Storage deployments in the same region as the BizTalk Service.

Note that on a production environment, we would want to create Storage and SQL Database exclusively to be used by BizTalk Services. Nevertheless, for a playground environment, we can re-use existing SQL Database and Storage so that we lower cost to as little as possible.

1.3. Create a BizTalk Service deployment.

The third step is to create the BizTalk Service deployment (instance).

  • In the Azure Management portal, click on BizTalk Services on the left panel and then click either on the New or Create a Biztalk Service link. This will prompt the Create BizTalk Service wizard to pop up.Azure Portal BizTalk Services section
  • In the Create BizTalk Service wizard first page we define:
      • A (unique) Name for the BizTalk Service deployment.
      • The BizTalk Service edition. At time of writing, there are 4 editions: Developer, Basic, Standard and Premium. In the scenario of a playground deployment, the Developer edition will be enough.
      • The region we want to create the BizTalk Service in.
      • Create or re-use and existing SQL Database instance to hold the Tracking database. If we use an existing SQL Database instance, make sure that it is in the same region as the BizTalk Service we are currently creating. In my playground deployment, I have chosen to use an existing SQL Database instance (a free 20 Mb SQL Database instance).

    Create BizTalk Service wizard first page

  • In the second page of the wizard, Database Settings, we set the necessary credentials to connect to the SQL Database instance which will hold the Tracking Database.Create BizTalk Service wizard Database Settings
  • In the third and last page of the wizard, we set the storage account used to store monitoring data and archived messages. We can either choose and existing storage account (which should be in the same region as the BizTalk Service instance we are creating) or create a new one.Create BizTalk Service wizard Archiving Storage Settings

Once we click the final button, the deployment takes about 30 minutes to complete.

1.4. Get BizTalk Service credentials (ACS).

Once the BizTalk Service is provisioned, we want to write down the ACS ( Access Control Service) credentials. To do so, when the BizTalk Service is selected, click on the Connection Information button at the bottom of the Azure Portal:
BizTalk Service Connection Information
The Access Connection Information panel opens, take note of the Default Issuer and Default Key values. We will use them later to configure the BizTalk Service portal.BizTalk Service Access Connection Information

1.5. Registration of the BizTalk Service to the Azure BizTalk Services portal.

The Azure BizTalk Services Portal is a specific management portal for BizTalk Services where we can:
– Manage the various artifacts deployed to the BizTalk Service subscription (schemas, transforms,…).
– Manage B2B operations (EDI and X12): Manage Partners (called Party in BizTalk Server) and Agreement (also called Agreement in BizTalk Server).
See Using the BizTalk Services Portal for more information on the Azure BizTalk Services portal.

To register the BizTalk Service deployment to the portal:

  • In the Azure Portal, select the concerned BizTalk Service and click on the Manage link at the bottom of the screen.BizTalk Service Manage
  • The Azure BizTalk Services Management portal opens where we will put in the ACS Issuer name and ACS Issuer secret. These are the values we copied from the Connection Information screen the previous step 1.4 (there, the fields are called Default Issuer and Default Key). Once issuer and key values are copied, click Register.BizTalk Services Portal Registration

Once we have registered The BizTalk Service Deployment, we have access to the Azure BizTalk Services portal for BizTalk Service we have just created:BizTalk Services Portal

2. Setting up the Development environment: installing the Azure BizTalk Services SDK.

In this section I will cover the procedure to do a complete installation of the Azure BizTalk Services SDK on a development environment.

2.1. Download the SSL certificate of the BizTalk Service Depoyment.

Once you have created a BizTalk Service, the endpoint of the BizTalk Service is a URL in the following format: <BiztalkServiceName>.biztalk.windows.net. For clients to be able to connect to the BizTalk Service deployment, a secure SSL connection must be established. As for playground/development environments, we can use the self-signed certificate which is automatically generated when creating an Azure BizTalk Service, we need to install it in the trusted Trusted Root Certification Authorities Store on every client/developer machine that needs connectivity to the BizTalk Service deployment. That way, the local machine(s) will accept the server certificate of the BizTalk Service deployment and the SSL connection will be possible. For production environment, we should request a certificate provided by a certificate authority (CA).

  • Download the self-signed public certificate (.cer) from the dashboard of the BizTalk Service. This certificate was automatically created when we provisioned the BizTalk Service deployment in the first part of this tutorial. In the BizTalk Service Dashboard, click on Download SSL Certificate:Azure Portal BizTalk Services Dashboard Certificate
  • Once the certificate is saved on disk, run the mmc command and add the Certificates snap-in for the Computer account:MMC Add Certificates Snap-In
  • We select the Local computer as this is the computer that will run the SDK and will need a secured connection (SSL) with the BizTalk Services deployment running in Azure Cloud:MMC Add Certificates Snap-In Select Local Computer
  • The final step is to add the certificate in the Trusted Root Certification Authorities certificate store:BizTalk Service Certificate Trusted Root Certification Authorities

2.2 Create a self-signed certificate for securing the BizTalk Adapter Service Runtime.

On the development machine, when installing the Runtime part of the Azure BizTalk Services SDK, an on-premise web service running in IIS is installed. It is called the BizTalk Adapter Service. The BizTalk Adapter Service is sometimes reference to by its acronym (BAS). Note that it is the same acronym as the retired BizTalk Server Business Activity Services (BAS) but of course not related.
The BAS web service needs to be secured and for that we need a self-signed certificate for which we have a private key (by contrast, the certificate downloaded from the portal is the certificate belonging to the BizTalk Service deployment and so contains only the public key). On a production environment we would want to use a certificate issued by a certificate authority to secure the BAS on-premise web service.

We will create a self-signed certificate for the machine where we will install the BAS web service runtime, which, for a typical development environment, is the development machine where we install the Azure BizTalk Services SDK.
So, as the development machine will run the BAS runtime, we will create a self-signed certificate for that development machine name:

  • Create the self-signed certificate that will be used secure the BAS Web service that will be created in IIS when installing BizTalk Adapter Service (which is part of the Azure BizTalk Services SDK runtime feature). The following line creates a certificate in the Trusted Root Certification Authorities of the Local Computer certificate store (parameter -sr LocalMachine and -ss root). Note that with Visual Studio 2012, makecert is located at: C:\Program Files (x86)\Windows Kits\8.0\bin\x64
    makecert -pe -r -n "CN=yourlocalmachinenamehere" -e "10/05/2018" -sr LocalMachine -ss root
  • Export the private key of the self-signed certificate from the certificate store. In the sample hereunder, the password of the private key is “Password”:
    certutil -exportPFX -p "Password" root yourlocalmachinenamehere yourlocalmachinenamehere.pfx
  • Import the certificate in IIS:
    • Open IIS Manager and double click on the Server Certificates icon:IIS Manager Server Features View
    • Right-click on the screen and select Import. In the Import Certificate pop-up Windows, select the private key (.pfx file) we exported in the previous step and enter the password. Leave the other default options as they are (Certificate Store “Personal” and checkbox “Allow this certificate to exported” ticked):IIS Import Certificate
    • The certificate is now visible in the Server Certificates section of IIS and in the Local Computer Personal Certificate Store:IIS Server CertificateLocal Computer Personal Certificates Store

2.3. Installing the Azure BizTalk Services SDK.

The Azure BizTalk Services SDK contains the necessary bits to create BizTalk Services project in Visual Studio as well as other necessary binaries .
The SDK contains 3 main features:
– The developer SDK which is used to develop BizTalk Services applications. It contains Visual Studio BizTalk Services project template (bridges) and BizTalk Services Artifacts project template (transforms and schemas). This feature is installed on development machines only.
– The Runtime which manages connectivity between Azure BizTalk Services applications and the on-premise Line-Of-Business (LOB) application. If the Azure BizTalk Services application does not need to connect to an on-premise application, this component does not need to be installed. This feature is installed wherever we need the runtime, typically production and development machines.
– The Tools which includes Windows PowerShell cmdlets to manage both the BizTalk Adapter Service Runtime components and the deployed BizTalk Services applications. This feature is installed on both production and development machines.

The requirements to install the Azure BizTalk Services SDK are:

  • Windows 7 and up or Windows 2008 R2 and up.
  • The .Net Framework 3.5.1 and 4.5. To check if you are running .Net 4.0 or 4.5, which is not that straightforward as they both show up as runtime v4.0.30319 in IIS and in C:\Windows\Microsoft.NET\Framework (the reason being that 4.5 is an in-place upgrade from 4.0, not a side-by-side install with 4.0), we can either:
    • Look in the Registry:Framework .Net 4.5 Registry
    • Check Windows Server Roles and Features (or the Windows Features on client versions of Windows):Windows Features Framework 4.5Windows Client Features Framework 4.5
  • Windows PowerShell 3.0 or above(run the $PSVersionTable command in PowerShell to check which version you are running).
  • Visual Studio 2012. Visual Studio 2013 is not supported.
  • Make sure that Windows Authentication is Enabled in IIS (it was disabled by default on my machine)

Once we are sure we have all prerequisites, we can go ahead and install the Azure BizTalk Services SDK with the following procedure:

  • Download the Azure BizTalk Services SDK here. In the pop-up window. choose either WindowsAzureBizTalkServicesSetup-x64.exe or WindowsAzureBizTalkServicesSetup-x86.exe depending on the version of Windows installed (64 or 32 bit).
  • After having downloaded the adequate executable, run it as Administrator.
  • In the License Term screen, tick the checkbox “I accept the terms in the License Agreement” and click Next:Azure BizTalk Services Setup License Term
  • In the Features screen we choose which features we want to install. On a development machine we want all of them: The Developer SDK, the Runtime and the Tools. On a Production environment we would typically install only Tools and Runtime. Once the necessary features are selected, click Next.Azure BizTalk Services Setup Features
  • The Summary screen displays the components to install for the features selected in the previous screen. We can see that the components that are already installed on the machine have their Action set to None and the ones that still need to be installed have their Action set to Install. As I am installing the SDK on a machine where I have already installed BizTalk Server 2013 and the Adapter Pack, these components do not need to be installed anymore. Click Install:Azure BizTalk Services Summary
  • At some point, the BizTalk Adapter Service (BAS) setup procedure will start. This is a separate msi which is launched as part of the overall BizTalk Adapter Services Setup. The BizTalk Adapter Service is part of the on-premise Runtime feature of Azure BizTalk Services and is used for communication between Azure BizTalk Services and on-premise Line-Of-Business (LOB) applications. On the welcome screen, click Next:BizTalk Adapter Service Setup Welcome
  • In the End-User License Agreement screen, tick the checkbox “I accept the terms in the License Agreement” and click Next:BizTalk Adapter Service Setup License Agreement
  • In the Management Service Application Pool screen, we need to provide a service account which will run the Biztalk Adapter Service (BAS) IIS application pool (named BizTalk Adapter AppPool). The service account needs to have the Administrator role on the local machine and have access to the Internet. On my lab machine, I am using my own local account. A better practice is to create a service account and add it to the local Administrators Group instead of using a user account. Leave the Domain field blank if using a local account. After having entered the service account and password, click Next:BizTalk Adapter Service Setup Management Service Application Pool
  • In the Azure BizTalk Services Deployment Details screen, we need to input the URL of the BizTalk Services deployment instance we have created through the Azure Portal in the first part of this tutorial. The URL is in the form of: https://<deployment name>.biztalk.windows.net. The reason we need to give the BizTalk Service deployment URL is that the BizTalk Service solutions created in Visual Studio will use the BizTalk Service artifact store to keep the configuration settings of the BizTalk Adapter Service components (LOB Relays, LOB Targets,…). Click Next after having input the BizTalk Services deployment URL:BizTalk Adapter Service Setup BizTalk Services Deployment URL
  • In the Management Service Site Binding screen:
      • Tick the Use SSL to secure the management service checkbox to encrypt HTTP communication with the on-premise BAS Management Web Service with SSL.
      • Specify the SSL certificate that we created and imported in IIS in the previous step: Create a self-signed certificate for securing the BizTalk Adapter Service Runtime. Remember that for production environment we should use a certificate provided by a trusted certificate authority.
      • Specify the port number the BizTalk Adapter Service web service will be running on (this web service is installed in the local machine’s IIS). The default value is 8080. I chose a different port as I already had an IIS Website running on port 8080.
      • Click Next.

    BizTalk Adapter Service Setup Management Service

  • In the final screen, click Install:BizTalk Adapter Service Setup Install Ready
  • Once the BizTalk Adapter Service installation has completed, click Finish:BizTalk Adapter Service Setup Install Finish
  • We are now back on the Windows Azure BizTalk Services Setup screen, click Finish:Azure BizTalk Services Setup Finish

Note on BAS:
We can see that a Web site called BizTalk Adapter Service has been created in IIS and that it contains a single web service application called BASService, itself containing a single web service which is the Management Service of BAS (BizTalk Adapter Service) which is used for runtime connectivity with the Azure cloud. See BizTalk Adapter Service on MSDN for more information.
BizTalk Adapter Service IIS Web AppWe can also see the BizTalk Adapter AppPool application pool created to run BAS management service.BizTalk Adapter Service IIS AppPool

2.4 Configuring the BizTalk Adapter Service.

As creating LOB Targets to access from the cloud is done through Server Explorer in Visual Studio and as Visual Studio is doing this task through the BAS Management Service installed in IIS, we must configure Visual Studio with the management service accordingly.

  • Launch Visual Studio 2012 and open Server Explorer.
  • Expend the BizTalk Adapter Services node and see the BAS management service installed in the previous step. It was automatically added for me but if it is not, you can add it manually.Visual Studio Server Explorer BizTalk Adapter Services
  • Click on the service and you will be prompted for the ACS credentials of the Azure BizTalk Services deployment instance. We get these from the Azure Portal as I explained in the previous step (1.4). Once the ACS credentials are copied, click Ok.Visual Studio Server Explorer BizTalk Adapter Services ACS
  • Once the credentials are set, we can expend the BAS management service node to see the various LOB Types:Visual Studio Server Explorer BizTalk Adapter Services LOB Types

3. Final Notes.

3.1. Installing BizTalk Adapter Service failure.

Installing BAS fails with the following error when the BAS certificate is not created or installed properly as explained in the installation step Create a self-signed certificate for securing the BizTalk Adapter Service Runtime.

The Windows Application Event Log shows the following message:

Windows Installer installed the product. Product Name: Microsoft BizTalk Adapter Service. Product Version: 2.0.40214.0. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.

Note that the event is not written in the Application Event Log as an Error but as an Information level event.

In the log file created by the Azure BizTalk Services setup, the following error is written:

SBConnectCA: ERROR: System.Runtime.InteropServices.COMException (0x80070520): A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520)
at Microsoft.Web.Administration.Interop.IAppHostMethodInstance.Execute()
at Microsoft.Web.Administration.Binding.AddSslCertificate(Byte certificateHash, String certificateStoreName)
at Microsoft.Web.Administration.BindingManager.Save()
at Microsoft.Web.Administration.ServerManager.CommitChanges()
at Microsoft.ApplicationServer.Integration.AFConnect.IISHelper.CreateWebsite(String websiteName, String physicalPath, String appPoolName, String certificateThumbprint, Int32 port)
at Microsoft.ApplicationServer.Integration.AFConnect.Program.Configure(Session session)

3.2. SQL Server dependency removed.

Some of the documentation / internet resources still mention about a dependency on SQL Server:
– A software requirement to have SQL Server installed on-premise.
– The service account running the BizTalk Adapter AppPool IIS application pool to have sysadmin role on the on-premise SQL Server.
Since the release of Azure BizTalk Services February 2014 Update, LOB artifacts are not stored on an on-premise instance of SQL Server anymore but on Azure SQL Databases instead. Consequently, the SQL Server dependency has disappeared.

3.3. Error when browsing to the BAS Management Service.

If you try to browse to the BAS Management web service and there is a certificate error, that is because either:
– You browse through localhost instead of the machine name.
– The certificate you created does not correspond to the machine name. When creating the certificate in step Create a self-signed certificate for securing the BizTalk Adapter Service Runtime, makecert.exe takes the parameter -n “CN=yourlocalmachinenamehere”, CN is the acronym for Common Name. The CN for a website is the host + the domain name (such as www.microsoft.com). For a single machine on an internal network, the CN can just be the machine name.
Azure BizTalk Services Management Service Certificate Error
When browsing through to the machine name which corresponds to the CN of the certificate, there is no certificate error:
Azure BizTalk Services Management Service Request Error
The Request Error is normal as the BAS management service is not browsable, it can only be accessed when presenting the ACS credentials which is not possible through a browser.

Further documentation and references:

Provisioning BizTalk Service
Install Azure BizTalk Services SDK
BizTalk Adapter Service Installation
Azure BizTalk Services Resources on the TechNet Wiki (Lots of resources here!)
Official MSDN BizTalk Services documentation
BizTalk Services on the Microsoft Azure Site: BizTalk Services

Failure Importing WCF Extension configuration to BizTalk WCF-Custom Handler

One of the BizTalk application that I am working on has to access web services from a third-party which does not play nicely with WCF. Nothing too uncommon if the third-party is a little exotic.
The solution was that a Custom Message Encoder was written to be able to read the messages coming from the third-party. To configure the WCF runtime stack, a Custom Message Encoding Binding Element was also created. As we want this custom encoder to only be used by that BizTalk application, we created a specific WCF-Custom Adapter Handler for the application and only that handler is configured with the binding extension configuration (instead of doing a change in machine.config or maybe the BTSNTSvc.exe.config).

As I was recreating a new development environment, I tried to import the WCF binding extension configuration file (a .config file containing a bindingElementExtensions element) to the WCF-Custom Adapter handler and got the following error: “Unable to import configuration from file “xxx.config”. (System.UnauthorizedAccessException) Access to path ‘xxx’ is denied.

WCF Extension configuration fails BizTalk Handler

I found out that this was simply because the configuration file was read-only (as it was coming from TFS source control) and that the BizTalk Admin Console first copies the config file to a temp folder and then tries to delete it. As the file is read-only, it cannot be deleted and importing the binding configuration fails!

The solution was simple, I just had to make the file writeable.
I chose to check-out the file temporarily, import the WCF binding extension configuration file and undo the check-out once the configuration was imported through the BizTalk Admin Console.


If you are unfamiliar with WCF extensibility, a sample of a Custom Message Encoder sample is available on MSDN at Custom Message Encoder: Custom Text Encoder and the source code of the sample (and other samples) can be downloaded at Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4.

To import WCF Extension to a WCF-Custom Adapter Handler, open the BizTalk Admin Console, navigate to BizTalk Group\Platforms Settings\Adapters\WCF-Custom and right click the Handler of choice. Click Properties and then click Import.

Import WCF Extension bindings for BizTalk WCF-Custom Adapter Handler

Visual Studio GitHub integration tutorial

Visual Studio GitHub integration tutorial – Getting Started with Git.

This article is aimed at beginners who are new to GitHub and so also probably new to Git repositories. For those, the first thing to say is that GitHub (www.github.com) is a web-hosted Git repository. A Git repository is an implementation of a Distributed Version Control System. A subscription to GitHub is free for public repositories and several paid plans exist for private repositories.

I chose GitHub as Git repository because GitHub is becoming the leader repository for people to share code and collaborate. This is why it is important to know about Git and more importantly to know how to use it.
In this post, I will explain how to create a GitHub repository and how to use it with Visual Studio.
Note that while this tutorial is about GitHub, the Visual Studio integration part is identical regardless of the actual Git repository used. Consequently all the instructions are also valid for other Git repositories whether they are web-hosted (such as Bitbucket – another popular code sharing platform) or on premise (such as Git installed on a rerver or a TFS 2013 Git repository).

For more information about Git, you can read my previous post: Git TFS Visual Studio Integration where I compare different type of repositories (Centralized vs Distributed), introduce Git and explain how Git integrates with Visual Studio and TFS. If you don’t have time to read it, here is short summary: The post explains that Git is a Distributed Version Control System in which all nodes of the distributed system run a full copy of the Git repository. It is therefore comparable to peer-to-peer technology in which there is technically no server – when compared to traditional client/server architecture. However, in practice, a central server is used as integration point for the various members of a team to collaborate. In short, all members upload their changes to the central server and get changes from other members through that central server. In this tutorial, github.com is this central server which has the particularity of being web-hosted. I will refer to it as the remote repository or simply as GitHub. The local repository is the instance of the Git repository running on the user local machine.

The tutorial focuses on creating a GitHub repository and a new Visual Studio solution which will use the GitHub repository as Version Control System.

1. Create a new repository in Github.

  1. Create an account on GitHub at www.github.com. Alternatively, sign-in if you already have an account.
  2. Create a new repository by clicking on the + sign next to your account on the right top corner of the page or by navigating to https://github.com/new.
    GitHub Homepage
  3. On the screen to create the new repository, choose a Repository name and if the repository is Public (free) or Private (available with paid subscription only). Do not tick the checkbox Initialize this repository with a README so that GitHub does not create a default master branch. It would conflict with Visual Studio Team Explorer which will want to create the master branch when publishing a solution for the first time. We can create a README as well as add any other files later on.
    Finally, click on the Create repository button.
    GitHub Create New Repository
  4. We now have an empty repository. Take note of the git repository URL (which ends in .git) as it will be needed later on. As a reminder, refrain from the temptation of adding a README file or any other file right now as it would create a master branch which will conflict with Visual Studio when we sync Visual Studio’s local Git repository to the remote Git repository hosted on github.com.
    GitHub New Empty Repository

2. Create a new Visual Studio Project.

In this simple tutorial I will create a “Hello World” Console Application:

  1. Open Visual Studio and on the start page, choose “New Project…“. Alternatively, on the main menu, click FILE -> NEW -> Project…
    Visual Studio New Project
  2. In the New Project page:
    1. Choose Console Application as project type.
    2. Write the project name in the Name text box. In this example it is HelloWorld.
    3. Choose a Location which is the local folder that will be the root of the local Git repository. In this example it is C:\CodeSCM\Git\.
    4. Make sure to tick the “Create directory for solution” and “Add to source control” check boxes.
    5. Click the OK button.

    Visual Studio New Project Pop Up

  3. Choose Git in the pop-up window asking which source control system to use for the project and click the OK button.
    Visual Studio Choose Source Control Type

3. Adding the solution to the local Git repository.

With Git repositories we first commit changes to the local repository and can do so multiple times before pushing the changes to the remote repository (GitHub in this tutorial). This can be useful when we want to check-in changes only locally so that change history is available but we are not yet ready to publish the code to the shared repository for collaborators to use or for people of the general public to consume (in the case you use GitHub to publish your open source work to the general public).
Once we have created the Visual Studio solution and ready to commit the code for the first time, we can see in Solution Explorer that all the files of the solution are marked as new.
Visual Studio Solution Explorer New Project
To commit the solution to the local (Git) repository, follow the instructions hereunder:

  1. Open Team Explorer (Menu VIEW -> Team Explorer). Make sure you are on the Home page and click on the Changes link:
    Visual Studio Team Explorer Changes Link
  2. In the Changes screen, we will be prompted to configure Git settings to be able to commit to the local Git Repository. Click on the Configure link.
    Visual Studio Team Explorer Changes Prompt To Configure Git
  3. In the next screen we configure the local repository Git Settings by:
    1. Filling in a User Name.
    2. Filling in an Email Address.
    3. Setting the Default Repository Location. The default location is C:\Users\WindowsAccountName\Source\Repos but can be changed as preferred. Here I set it to the same folder I created my Visual Studio Solution in (C:\CodeSCM\Git) as I prefer to put all my solutions there.
    4. If you want, tick the check box Enable download of author images from 3rd party source. When connected to TFS, it will use the TFS user profile image. If no image is set, an image from Gravatar will be used.
    5. Ignore File. Git repositories can have a .gitignore file to avoid committing non-source files that do not belong to the repository; such as temporary files or binaries that are not part of the published product (such as .pdb files). See Git reference Ignoring files for more information.
    6. Attributes File. Git repositories can have a .gitattributes file which defines things such as automatic indentation on commit, instruction on doing diff on binary files, … See Git reference Git Attributes for more information.

    Finally, click the Update button to save the Git settings.
    Visual Studio Team Explorer Git Settings
    Note that the local Git settings are also directly available from the Settings link in the Home page of Team Explorer and that we could have configured them before starting the commit process. It is also how we would modify the Git Settings if we wanted to:
    Visual Studio Team Explorer Home Git Settings

  4. Once the Git Settings are set, we can commit the code. The default policy being that commit messages are mandatory, enter a commit message and click the Commit button.
    Visual Studio Team Explorer Changes Local Commit
  5. Once the commit is completed, we have a commit success message. The message offers to Sync the changes to the remote repository but in this tutorial we will do this at a later stage. We can dismiss the message for now.
    Visual Studio Team Explorer Changes Local Commit Success
  6. The code is now committed to the local Git repository and Visual Studio’s Solution Explorer displays a little padlock icon for committed files.
    Visual Studio Solution Explorer First Commit Complete

4. Code change and local commit in Git – The Edit/Commit model.

In an Edit/Commit model, files are not read-only and we don’t have to do a check-out before editing a file, we can edit files straight away and when we do so, the local Git repository will realize that the file has been modified. Visual Studio’s Solution Explorer and Team Explorer will clearly mark the solution files that have been changed (see screenshots hereunder). It is the case even if we modify the files from outside Visual Studio. This is because Git looks at the content of each file and mark the file as edited only if the content is different. This process is executed efficiently by using metadata about the files, not through full text comparison. Consequently, if we edit again an already modified file and revert it back to its original content, Git will know that the file is now identical to its last committed version. The file will not be considered modified any more and in Solution Explorer, the file will revert back to the unmodified status with a little padlock icon next to it.
Visual Studio Explorer Edited File
Visual Studio Team Explorer Edited File

As with TFVC repositories, we can commit the code from the Solution Explorer (which will take us to Team Explorer) or directly from Team Explorer:
Visual Studio Solution Explorer Commit
Visual Studio Team Explorer Commit

5. Viewing History.

As with TFVC repositories, we can see version history for individual files or the commit history at the repository level for a particular branch.

  • Individual file version history.
    We can see the commit history for each file from the Solution Explorer.
    Visual Studio Solution Explorer File History
  • Repository branch commit history.
    We can see the commit history at the repository level from Team Explorer. On the Team Explorer home screen, click Branches to take you to the Branches screen. In that screen hover the mouse on the branch you want to get the history for (here the master branch), do a right-click on it to bring up the branch contextual menu and select View History. You will notice in the contextual menu of the branch that it is also the place where you can create and merge branches.
    Visual Studio Team Explorer Home Click Branch
    Visual Studio Team Explorer Branches View History
    The History gives a list of the past commits and it is possible to right-click on each commit to see the details of a specific commit. The commit details will show all the files that were committed for that particular commit.
    Visual Studio Master Branch Commit History

6. Publishing the Visual Studio solution for the first time to the remote Git repository.

  1. Once we want to publish the project for the first time to the remote Git repository (GitHub), go to Team Explorer Home and click the Branches link to access the Branches screen. Once there, click the Unsynced Commits link.
    Visual Studio Team Explorer Unsynced Commits link
  2. As we did not configure the remote Git repository yet, we are now prompted to do so. The configuration just consists of the URL of the Git repository. The URL of the repository ends in .git and is available to copy from the GitHub repository homepage. I showed it in the first part of this tutorial on the empty repository home page screenshot. Once you have put the URL, paste ot in the text box and click the Publish button.
    Visual Studio Team Explorer Unsynced Commits Page
  3. We are then prompted with a window to put in our github.com login information:
    Visual Studio GitHub Credentials Prompt
  4. We have now published our solution for the first time to the remote git repository for the master branch.
    Visual Studio Team Explorer Solution Published
  5. On github.com, the repository will now display the files published. We can see the Visual Studio solution file (.sln) as well as the folder for the HelloWorld project. Visual Studio also automatically included the 2 files .gitattributes and .gitignore. Those files did not come out of nowhere, they were visible in the Team Explorer Changes screen when we did the Commit to the local repository (see screenshot). They are out of scope of this tutorial so I won’t go more in details about them.
    GitHub Solution Published

7. Fetch / Pull / Push: Modifying code locally, committing to local Git and publishing to remote Git.

When working in a team we should get updates of the code from the remote repository on a regular basis to make sure that the code we are developing integrates well with the work done by other members of the team. Moreover, it is not possible to commit our changes to the remote repository without having received the latest version of the code first (doing a Pull).

  • Pull
    A Pull is the operation of getting the latest changes from the remote Git repository. It is good practice to Pull the code regularly so that we make sure the code we develop integrates well with the changes made by the team.
  • Fetch
    A Fetch is the operation of getting the list of changes since the last time we Pulled the code. It is useful to Fetch before Pulling so that we can see what are the incoming changes.
    Hereunder is an example of the result of a Fetch, which shows the upcoming changes for the next Pull:
    Visual Studio Team Explorer Fetch Link
    Visual Studio Team Explorer Fetch Result
  • Push
    A Push is the operation of pushing the changes committed on the local Git repository to the remote Git repository.
    Before doing a Push we first need to make sure that everything we want to Push is Committed locally:
    Visual Studio Team Explorer Changes Commit
    Once all the files we want to push are committed locally, we can Push the changes to the remote Git repository:
    Visual Studio Team Explorer Unsynced Commit Push

This ends the step-by-step tutorial of using with Visual Studio with GitHub repositories (or any other Git repository for that matter).