Elevating permissions for BizTalk Server Operators Group

Elevating permissions for BizTalk Server Operators Group

December 1, 2016

Elevating permissions for BizTalk Server Operators Group

Filed under: BizTalk — mbrimble @ 4:54 pm

I found this blog article , https://www.codit.eu/blog/2012/07/02/elevating-permissions-for-biztalk-server-operators-group/ by Toon Vanhoutte   very useful today.  Adding this link to my blog so i don’t forget it.


No comments yet.

RSS feed for comments on this post. TrackBack URI

Failed to stop service WINMGMT while trying to apply BizTalk Server Cumulative Update

Failed to stop service WINMGMT while trying to apply BizTalk Server Cumulative Update

Being in The Netherland for the first time and provably inspired by the cold outside my hotel room, that discourages any "reasonable person" to walk in streets of Arnhem at night, let’s talk about another familiar problem that can occur in BizTalk Server. The error that I will address today is quite normal to appear […]
Blog Post by: Sandro Pereira

Using Concourse to continuously deliver a Service Bus-powered Java app to Pivotal Cloud Foundry on Azure

Using Concourse to continuously deliver a Service Bus-powered Java app to Pivotal Cloud Foundry on Azure

Guess what? Deep down, cloud providers know you’re not moving your whole tech portfolio to their public cloud any time soon. Oh, your transition is probably underway, but you’ve got a whole stash of apps, data stores, and services that may not move for a while. That’s cool. There are more and more patterns and services available to squeeze value out of existing apps by extending them with more modern, scalable, cloudy tech. For instance, how might you take an existing payment transfer system that did B2B transactions and open it up to consumers without requiring your team to do a complete rewrite? One option might be to add a load-leveling queue in front of it, and take in requests via a scalable, cloud-based front-end app. In this post, I’ll show you how to implement that pattern by writing a Spring Boot app that uses Azure Service Bus Queues. Then, I’ll build a Concourse deployment pipeline to ship the app to Pivotal Cloud Foundry running atop Microsoft Azure.


Ok, but why use a platform on top of Azure?

That’s a fair question. Why not just use native Azure (or AWS, or Google Cloud Platform) services instead of putting a platform overlay like Pivotal Cloud Foundry atop it? Two reasons: app-centric workflow for developers, and “day 2” operations at scale.

Most every cloud platform started off by automating infrastructure. That’s their view of the world, and it still seeps into most of their cloud app services. There’s no fundamental problem with that, except that many developers (“full stack” or otherwise) aren’t infrastructure pros. They want to build and ship great apps for customers. Everything else is a distraction. A platform such as Pivotal Cloud Foundry is entirely application-focused. Instead of the developer finding an app host, packaging the app, deploying the app, setting up a load balancer, configuring DNS, hooking up log collection, and configuring monitoring, the Cloud Foundry dev just cranks out an app and does a single action to get everything correctly configured in the cloud. And it’s an identical experience whether Pivotal Cloud Foundry is deployed to Azure, AWS, OpenStack, or whatever. The smartest companies realized that their developers should be exceptional at writing customer-facing software, not configuring firewall rules and container orchestration.

Secondly, it’s about “day 2” operations. You know, all the stuff that happens to actually maintain apps in production. I have no doubt that any of you can build an app and quickly get it to cloud platforms like Azure Web Sites or Heroku with zero trouble. But what about when there are a dozen apps, or thousands? How about when it’s not just you, but a hundred of your fellow devs? Most existing app-centric platforms just aren’t set up to be org-wide, and you end up with costly inconsistencies between teams. With something like Pivotal Cloud Foundry, you have a resilient, distributed system that supports every major programing language, and provides a set of consistent patterns for app deployment, logging, scaling, monitoring, and more. Some of the biggest companies in the world deploy thousands of apps to their respective environments today, and we just proved that the platform can handle 250,000 containers with no problem. It’s about operations at scale.

With that out of the way, let’s see what I built.

Step 1 – Prerequisites

Before building my app, I had to set up a few things.

  • Azure account. This is kind of important for a demo of things running on Azure. Microsoft provides a free trial, so take it for a spin if you haven’t already. I’ve had my account for quite a while, so all my things for this demo hang out there.
  • GitHub account. The Concourse continuous integration software knows how to talk to a few things, and git is one of them. So, I stored my app code in GitHub and had Concourse monitoring it for changes.
  • Amazon account. I know, I know, an Azure demo shouldn’t use AWS. But, Amazon S3 is a ubiquitous object store, and Concourse made it easy to drop my binaries there after running my continuous integration process.
  • Pivotal Cloud Foundry (PCF). You can find this in the Azure marketplace, and technically, this demo works with PCF running anywhere. I’ve got a full PCF on Azure environment available, and used that here.
  • Azure Service Broker. One fundamental concept in Cloud Foundry is a “service broker.” Service brokers advertise a catalog of services to app developers, and provide a consistent way to provision and de-provision the service. They also “bind” services to an app, which puts things like service credentials into that app’s environment variables for easy access. Microsoft built a service broker for Azure, and it works for DocumentDB, Azure Storage, Redis Cache, SQL Database, and the Service Bus. I installed this into my PCF-on-Azure environment, but you can technically run it on any PCF installation.

Step 2 – Build Spring Boot App

In my fictitious example, I wanted a Java front-end app that mobile clients interact with. That microservice drops messages into an Azure Service Bus Queue so that the existing on-premises app can pull messages from at their convenience, and thus avoid getting swamped by all this new internet traffic.

Why Java? Java continues to be very popular in enterprises, and Spring Boot along with Spring Cloud (both maintained by Pivotal) have completely modernized the Java experience. Microsoft believes that PCF helps companies get a first-class Java experience on Azure.

I used Spring Tool Suite to build a new Spring Boot MVC app with “web” and “thymeleaf” dependencies. Note that you can find all my code in GitHub if you’d like to reproduce this.

To start with, I created a model class for the web app. This “web payment” class represents the data I connected from the user and passed on to the Service Bus Queue.

package seroter.demo;

public class WebPayment {
        private String fromAccount;
        private String toAccount;
        private long transferAmount;

        public String getFromAccount() {
                return fromAccount;

        public void setFromAccount(String fromAccount) {
                this.fromAccount = fromAccount;

        public String getToAccount() {
                return toAccount;

        public void setToAccount(String toAccount) {
                this.toAccount = toAccount;

        public long getTransferAmount() {
                return transferAmount;

        public void setTransferAmount(long transferAmount) {
                this.transferAmount = transferAmount;

Next up, I built a bean that my web controller used to talk to the Azure Service Bus. Microsoft has an official Java SDK in the Maven repository, so I added this to my project.


Within this object, I referred to the VCAP_SERVICES environment variable that I would soon get by binding my app to the Azure service. I used that environment variable to yank out the credentials for the Service Bus namespace, and then created the queue if it didn’t exist already.

public class SbConfig {

 ServiceBusContract serviceBusContract() {

   //grab env variable that comes from binding CF app to the Azure service
   String vcap = System.getenv("VCAP_SERVICES");

   //parse the JSON in the environment variable
   JsonParser jsonParser = JsonParserFactory.getJsonParser();
   Map<String, Object> jsonMap = jsonParser.parseMap(vcap);

   //create map of values for service bus creds
   Map<String,Object> creds = (Map<String,Object>)((List<Map<String, Object>>)jsonMap.get("seroter-azureservicebus")).get(0).get("credentials");

   //create service bus config object
   com.microsoft.windowsazure.Configuration config =

   //create object used for interacting with service bus
   ServiceBusContract svc = ServiceBusService.create(config);
   System.out.println("created service bus contract ...");

   //check if queue exists
   try {
        ListQueuesResult r = svc.listQueues();
        List<QueueInfo> qi = r.getItems();
        boolean hasQueue = false;

        for (QueueInfo queueInfo : qi) {
          System.out.println("queue is " + queueInfo.getPath());

          //queue exist already?
          if(queueInfo.getPath().equals("demoqueue"))  {
                System.out.println("Queue already exists");
                hasQueue = true;

        if(!hasQueue) {
        //create queue because we didn't find it
          try {
            QueueInfo q = new QueueInfo("demoqueue");
            CreateQueueResult result = svc.createQueue(q);
            System.out.println("queue created");
          catch(ServiceException createException) {
            System.out.println("Error: " + createException.getMessage());
    catch (ServiceException findException) {
       System.out.println("Error: " + findException.getMessage());
    return svc;

Cool. Now I could connect to the Service Bus. All that was left was my actual web controller that returned views, and sent messages to the Service Bus. One of my operations returned the data collection view, and the other handled form submissions and sent messages to the queue via the @autowired ServiceBusContract object.

public class SpringbootAzureConcourseApplication {

   public static void main(String[] args) {
     SpringApplication.run(SpringbootAzureConcourseApplication.class, args);

   //pull in autowired bean with service bus connection
   ServiceBusContract serviceBusContract;

   public String showPaymentForm(Model m) {

      //add webpayment object to view
      m.addAttribute("webpayment", new WebPayment());

      //return view name
      return "webpayment";

   public String paymentSubmit(@ModelAttribute WebPayment webpayment) {

      try {
         //convert webpayment object to JSON to send to queue
         ObjectMapper om = new ObjectMapper();
         String jsonPayload = om.writeValueAsString(webpayment);

         //create brokered message wrapper used by service bus
         BrokeredMessage m = new BrokeredMessage(jsonPayload);
         //send to queue
         serviceBusContract.sendMessage("demoqueue", m);
         System.out.println("message sent");

      catch (ServiceException e) {
         System.out.println("error sending to queue - " + e.getMessage());
      catch (JsonProcessingException e) {
         System.out.println("error converting payload - " + e.getMessage());

      return "paymentconfirm";

With that, my microservice was done. Spring Boot makes it silly easy to crank out apps, and the Azure SDK was pretty straightforward to use.

Step 3 – Deploy and Test App

Developers use the “cf” command line interface to interact with Cloud Foundry environments. Running a “cf marketplace” command shows all the services advertised by registered service brokers. Since I added the Azure Service Broker to my environment, I instantiated an instance of the Service Bus service to my Cloud Foundry org. To tell the Azure Service Broker what to actually create, I built a simple JSON document that outlined the Azure resource group. region, and service.

  "resource_group_name": "pivotaldemorg",
  "namespace_name": "seroter-boot",
  "location": "westus",
  "type": "Messaging",
  "messaging_tier": "Standard"

By using the Azure Service Broker, I didn’t have to go into the Azure Portal for any reason. I could automate the entire lifecycle of a native Azure service. The command below created a new Service Bus namespace, and made the credentials available to any app that binds to it.

cf create-service seroter-azureservicebus default seroterservicebus -c sb.json

After running this, my PCF environment had a service instance (seroterservicebus) ready to be bound to an app. I also confirmed that the Azure Portal showed a new namespace, and no queues (yet).


Awesome. Next, I added a “manifest” that described my Cloud Foundry app. This manifest specified the app name, how many instances (containers) to spin up, where to get the binary (jar) to deploy, and which service instance (seroterservicebus) to bind to.

- name: seroter-boot-azure
  memory: 256M
  instances: 2
  path: target/springboot-azure-concourse-0.0.1-SNAPSHOT.jar
  buildpack: https://github.com/cloudfoundry/java-buildpack.git
    - seroterservicebus

By doing a “cf push” to my PCF-on-Azure environment, the platform took care of all the app packaging, container creation, firewall updates, DNS changes, log setup, and more. After a few seconds, I had a highly-available front end app bound to the Service Bus. Below that you can see I had an app started with two instances, and the service was bound to my new app.


All that was left was to test it. I fired up the app’s default view, and filled in a few values to initiate a money transfer.


After submitting, I saw that there was a new message in my queue. I built another Spring Boot app (to simulate an extension of my legacy “payments” system) that pulled from the queue. This app ran on my desktop and logged the message from the Azure Service Bus.


That’s great. I added a mature, highly-available queue in between my cloud-native Java web app, and my existing line-of-business system. With this pattern, I could accept all kinds of new traffic without overloading the backend system.

Step 4 – Build Concourse Pipeline

We’re not done yet! I promised continuous delivery, and I deliver on my promises, dammit.

To build my deployment process, I used Concourse, a pipeline-oriented continuous integration and delivery tool that’s easy to use and amazingly portable. Instead of wizard-based tools that use fixed environments, Concourse uses pipelines defined in configuration files and executed in ephemeral containers. No conflicts with previous builds, no snowflake servers that are hard to recreate. And, it has a great UI that makes it obvious when there are build issues.

I downloaded a Vagrant virtual machine image with Concourse pre-configured. Then I downloaded the lightweight command line interface (called Fly) for interacting with pipelines.

My “build and deploy” process consisted of four files: bootpipeline.yml that contained the core pipeline, build.yml which set up the Java build process, build.sh which actually performs the build, and secure.yml which holds my credentials (and isn’t checked into GitHub).

The build.sh file clones my GitHub repo (defined as a resource in the main pipeline) and does a maven install.

#!/usr/bin/env bash

set -e -x

git clone resource-seroter-repo resource-app

cd resource-app

mvn clean

mvn install

The build.yml file showed that I’m using the Maven Docker image to build my code, and points to the build.sh file to actually build the app.

platform: linux

  type: docker-image
    repository: maven
    tag: latest

  - name: resource-seroter-repo

  - name: resource-app

  path: resource-seroter-repo/ci/build.sh

Finally, let’s look at my build pipeline. Here, I defined a handful of “resources” that my pipeline interacts with. I’ve got my GitHub repo, an Amazon S3 bucket to store the JAR file, and my PCF-on-Azure environment. Then, I have two jobs: one that builds my code and puts the result into S3, and another that takes the JAR from S3 (and manifest from GitHub) and pushes to PCF on Azure.

# resource for my GitHub repo
- name: resource-seroter-repo
  type: git
    uri: https://github.com/rseroter/springboot-azure-concourse.git
    branch: master
#resource for my S3 bucket to store the binary
- name: resource-s3
  type: s3
    bucket: spring-demo
    region_name: us-west-2
    regexp: springboot-azure-concourse-(.*).jar
    access_key_id: {{s3-key-id}}
    secret_access_key: {{s3-access-key}}
# resource for my Cloud Foundry target
- name: resource-azure
  type: cf
    api: {{cf-api}}
    username: {{cf-username}}
    password: {{cf-password}}
    organization: {{cf-org}}
    space: {{cf-space}}

- name: build-binary
    - get: resource-seroter-repo
      trigger: true
    - task: build-task
      privileged: true
      file: resource-seroter-repo/ci/build.yml
    - put: resource-s3
        file: resource-app/target/springboot-azure-concourse-0.0.1-SNAPSHOT.jar

- name: deploy-to-prod
    - get: resource-s3
      trigger: true
      passed: [build-binary]
    - get: resource-seroter-repo
    - put: resource-azure
        manifest: resource-seroter-repo/manifest-ci.yml

I was now ready to deploy my pipeline and see the magic.

After spinning up the Concourse Vagrant box, I hit the default URL and saw that I didn’t have any pipelines. NOT SURPRISING.


From my Terminal, I used Fly CLI commands to deploy a pipeline. Note that I referred again to the “secure.yml” file containing credentials that get injected into the pipeline definition at deploy time.

fly -t lite set-pipeline --pipeline azure-pipeline --config bootpipeline.yml --load-vars-from secure.yml

In a second or two, a new (paused) pipeline popped up in Concourse. As you can see below, this tool is VERY visual. It’s easy to see how Concourse interpreted my pipeline definition and connected resources to jobs.


I then un-paused the pipeline with this command:

fly -t lite unpause-pipeline --pipeline azure-pipeline

Immediately, the pipeline started up, retrieved my code from GitHub, built the app within a Docker container, dropped the result into S3, and deployed to PCF on Azure.


After Concourse finished running the pipeline, I checked the PCF Application Manager UI and saw my new app up and running. Think about what just happened: I didn’t have to muck with any infrastructure or open any tickets to get an app from dev to production. Wonderful.


The way I built this pipeline, I didn’t version the JAR when I built my app. In reality, you’d want to use the semantic versioning resource to bump the version on each build. Because of the way I designed this, the second job (“deploy to PCF”) won’t fire automatically after the first build, since there technically isn’t a new artifact in the S3 bucket. A cool side effect of this is that I could constantly do continuous integration, and then choose to manually deploy (clicking the “+” button below) when the company was ready for the new version to go to production. Continuous delivery, not deployment.


Wrap Up

Whew. That was a big demo. But in the scheme of things, it was pretty straightforward. I used some best-of-breed services from Azure within my Java app, and then pushed that app to Pivotal Cloud Foundry entirely through automation. Now, every time I check in a code change to GitHub, Concourse will automatically build the app. When I choose to, I take the latest build and tell Concourse to send it to production.


A platform like PCF helps companies solve their #1 problem with becoming software-driven: improving their deployment pipeline. Try to keep your focus on apps not infrastructure, and make sure that whatever platform you use, you focus on sustainable operations at scale!


Categories: Cloud, Cloud Foundry, DevOps, General Architecture, Messaging, Microservices, Microsoft Azure, Pivotal, Windows Azure Service Bus

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) while trying to deploy a BizTalk Solution from Visual Studio

Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) while trying to deploy a BizTalk Solution from Visual Studio

Continuing with “Errors and Warnings, Causes and Solutions”, let’s talk today about a classic (and annoying) one: “Error 87 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Error 88 at Microsoft.BizTalk.Gac.Fusion.IAssemblyCache.InstallAssembly(AssemblyCacheInstallFlag flags, String manifestFilePath, IntPtr referenceData) at Microsoft.BizTalk.Gac.Gac.InstallAssembly(String assemblyPathname, Boolean force) at Microsoft.BizTalk.Deployment.BizTalkAssembly.GacInstall(String assemblyLocation) at Microsoft.BizTalk.Deployment.BizTalkAssembly.PrivateDeploy(String server, String database, String assemblyPathname, String applicationName) at Microsoft.BizTalk.Deployment.BizTalkAssembly.Deploy(Boolean […]
Blog Post by: Sandro Pereira

An error occurred while attempting to connect to a remove SQL Server database: The local MS DTC detected that the MS DTC on  has the same unique identity as the local MS DTC

An error occurred while attempting to connect to a remove SQL Server database: The local MS DTC detected that the MS DTC on has the same unique identity as the local MS DTC

Today I’m returning to one of my favorites topics no not transformations, this time is all about “Errors and Warnings, Causes and Solutions”. Today I encountered the following issue when I was trying to connect to a remove SQL Server database: “The local MS DTC detected that the MS DTC on <server name> has […]
Blog Post by: Sandro Pereira

Assigning an Integration Account to an Azure Logic App inside Visual Studio

Assigning an Integration Account to an Azure Logic App inside Visual Studio

I have been working heads down for a few weeks now with Windows Azure Logic Apps.  While I have worked with them off and on for over a year now, it is amazing how far things have evolved in such a small amount of time.  You can put together a rather complex EDI scenario in just a few hours with no up front hardware and licensing costs. 

I have been creating Logic Apps both using the web designer and using Visual Studios 2015. 

Recently I was trying to use the Transform Shape that is part of Azure Integration Accounts (still in Technical Preview).  I was able to set all the properties and manually enter a map name  Then I ran into issues. 

I found if I switched to code view I was not able to get back to the Designer without manually removing the Transform Shape.  I kept getting the following error:  The ‘inputs’ of workflow run action ‘Transform_XML’ of type ‘Xslt’ is not valid. The workflow must be associated with an integration account to use the property ‘integrationAccount’.

What I was missing was setting the Integration Account for this Logic App.  Using the web interface, it’s very easy to set the Integration Account.  But I looked all over the JSON file and Visual Studios for how to set the Integration Account for a Logic App inside Visual Studios.

With the help of Jon Fancy, it turns out it is super simple.  It is just like an Orchestration property.

To set the Integration Account for a Logic App inside Visual Studios do the following:

1. Ensure you have an Integration Account already created inside the subscription and Azure Location.

2. Make sure you set the Integration Account BEFORE trying to use any shaped that depend on it, like the Transform Shape.

3. Click anyplace in the white space of the Visual Studio Logic App.

4. Look inside the Property Windows for the Integration Account selection windows.

5. Select the Integration Account you want to use and save your Logic App.

It’s that simple! 


Installing (and Configure) BizTalk Server 2016 in a Standalone Machine (whitepaper)

Installing (and Configure) BizTalk Server 2016 in a Standalone Machine (whitepaper)

Microsoft announced on October 27, 2016 the release of Microsoft BizTalk Server 2016 – the 10th major release of BizTalk Server -and, as usual with previous versions, I updated my installation and configuration manual for BizTalk Server 2016. This whitepaper will explain in detail – a step-by-step guideline – how to install and configure Microsoft […]
Blog Post by: Sandro Pereira

Delivery Notification and the HTTP 500 Status Code

Delivery Notification and the HTTP 500 Status Code

At one of our customers I had implemented the ReturnAddress messaging pattern (http://www.enterpriseintegrationpatterns.com/patterns/messaging/ReturnAddress.html), by using a generic BizTalk application which sends an asynchronous response message to a client application. The solution had been running successfully for some time, when we encountered a strange situation.

The BizTalk application uses a one-way WCF-Custom send port, using a wsHttpBinding, to send a message to the client application. Also, I had added the Delivery Notification functionality to make sure messages are delivered successfully.

It is important to realize that one-way send ports that use SOAP will receive a technical response containing an HTTP status code. If and when the send ports receive a HTTP status code in the 200 range, the Delivery Notification generates an ACK and BizTalk knows the message was successfully delivered.

So far, so good. The application had been through testing on the Test and Acceptance environments, had been deployed to the Production environment and had been running for several months without any problems. Until it appeared that some of the messages that were being sent using the generic BizTalk application were ‘not arriving’ at the client application. This would happen at random and, what was really strange, the logging in BizTalk showed that the message was successfully sent and BizTalk had received an ACK response as part of the Delivery Notification. Also there was no mention of an error in the event log of the BizTalk servers.

After some debugging we found the source of the problem. The message sent by BizTalk was successfully received by the client application, however the client application encountered an error processing the message and returned the HTTP 500 status code. So now the question was, why is the Delivery Notification not generating a NACK response when a HTTP 500 status code is received? I had expected that any status code in the HTTP 400 and 500 range would result in a NACK.

This turned out not to be the case. While status codes in the HTTP 400 range will result in a NACK, the status codes in the HTTP 500 range will result in an ACK and BizTalk will view this message as successfully delivered at the client application. The logic behind this seems to be that the status codes in the HTTP 400 range indicate that the message was not received by the client application (hence the NACK) and the status codes in the HTTP 500 range indicate that the message was received by the client application, but that the client application encountered an exception. Since the message was delivered at the client application, BizTalk views this as a successful delivery and will generate an ACK as part of the Delivery Notification.

Unfortunately, there isn’t any documentation on MSDN on which status codes will return an ACK or NACK.

The documentation on the SOAP HTTP response states that “In case of a SOAP error while processing the request, the SOAP HTTP server MUST issue an HTTP 500 “Internal Server Error” response and include a SOAP message in the response containing a SOAP Fault element indicating the SOAP processing error”. For reference, see https://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529.

Some discussion followed on the validity of catching the HTTP 500 error in BizTalk, since the message was successfully delivered and accepted by the client application. That means that, from a technical perspective, the responsibility would now lie at the client application to handle the error. From a functional responsibility perspective however, it was decided to find a way to catch the HTTP 500 error in BizTalk, as this would enable the customer’s administrators to use the same resubmit functionality we had created by using a generic BizTalk error handling framework.

So I had to make sure the HTTP 500 status code was somehow caught, so that BizTalk would return a NACK which would result in the error handling catching the error. Fortunately, this can be achieved quite easily by implementing a WCF behavior on the one-way send port. The WCF behavior checks in the AfterReceiveReply message inspector if the reply is a fault message, and if so it will throw an exception using the fault description.

By implementing this WCF behavior on a one-way send port BizTalk will generate a NACK when a response is received with an HTTP status code in the 400 or 500 range. Sometimes the default behavior surrounding technical responsibility doesn’t align with the requirements and responsibilities from a functional point a view, and this may just offer a solution for you as well.

Announcing the private preview out of the new SAP Connector for Logic Apps

We are happy to announce the private preview of the new SAP Connector for Logic Apps. If you have an installation of SAP and want to utilize Logic Apps to create integration scenarios using RFC, TRFC, BAPI or IDOCs, this is your opportunity. The nominations for the private preview are currently open via this survey….
Blog Post by: BizTalk Team