Corrupt BizTalk orchestrations

Every now and then, when dealing with BizTalk orchestrations, you might encounter issues you can’t explain. Things like the following, infamous error, may occur without any valid reason:

#error: Errors exist for one or more children

Even after fixing every error, you rebuild the project and/or solution, and the error is still not fixed…

Continue reading


BizTalk orchestration keeps opening in Visual Studio text editor

You may know the issue when opening a BizTalk orchestration and it opens like this:

Note: I blurred the code to protect the name of my client.

Not much you can do about it, except right-clicking the orchestration and clicking ‘Open With…’ and choosing the BizTalk Orchestration Designer.


However, if you close the BizTalk Orchestration Designer again, and double-click the odx file, it once again opens in the first, yet useless, view.

Continue reading

A CrazyBizTalk confession



(This blog post was co-written by Pieter VandenheedeGlenn Colpaert, both colleagues at Codit)

We finally admit it… we both were the brains behind the CrazyBizTalk account. There… it’s in the open. After Integrate 2017, day 3, we were no longer able to keep it a secret, so there is no use of denying it anymore…

It was a fun ride, which started in 2013 already. We’ve written this post to give you some insights on how it all got started, the fun we had through the years and what the next steps are.

Continue reading

Azure API Management: subscription key invalid


Azure API Management is awesome! The thought of API virtualization and the power, flexibility and ease-of-use it can bring, is impressive to say the least.

I have the chance to ‘play’ with the technology with a project I’m working on for one particular client. Starting to play with things you often miss the simplest details or take things for granted. This is such a story…

Continue reading

Saving time via Logic Apps: a real world example


At Codit, I manage the blog. We have some very passionate people on board who like to invest their time to get to the bottom of things and – also very important – share it with the world!
That small part of my job means I get to review blog posts before publishing on a technical level. It’s always good to have one extra pair of eyes reading the post before publishing it to the public, so this definitely pays off!

An even smaller part of publishing blog posts is making sure they get enough coverage. Sharing them on Twitter, LinkedIn or even Facebook is part of the job for our devoted marketing department! And analytics around these shares on social media definitely come in handy! For that specific reason we use Bitly to shorten our URLs.
Every time a blog post gets published, someone needed to add them manually to out Bitly account and send out an e-mail. This takes a small amount of time, but as you can imagine it accumulates quickly with the amount of posts we generate lately!

Continue reading

Fixing DistributedCOM launch issues

Recently, when checking some event logs on a clustered SQL environment, I encountered the following error in the System event log:

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID
to the user DOMAIN\user SID (<SID>) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.

2017-05-18 17_58_02-mRemoteNG - mgRemoteNG.xml - SQL PRD 1

This happened twice … at the beginning of every minute.

Unaware what the Application ID listed was, I was able to retrieve the list of DCOM applications with the following PowerShell script:

$strComputer = “.”

$colItems = get-wmiobject -class “Win32_DCOMApplication” -namespace “root\CIMV2” -computername $strComputer

foreach ($objItem in $colItems) {
write-host “Application ID: ” $objItem.AppID
write-host “Caption: ” $objItem.Caption
write-host “Description: ” $objItem.Description
write-host “Installation Date: ” $objItem.InstallDate
write-host “Name: ” $objItem.Name
write-host “Status: ” $objItem.Status

With this, it was easy to track the application ID listed back to Microsoft SQL Server Integration Services. The user mentioned in the error was also a user only used for the SQL Server Agent jobs.

This led me to a SQL Server Job which ran every minute which uses SSIS in some of it’s steps. Strangely, the SQL Server job did not fail and kept working as expected.

After some Googling, I managed to fix the issue as so:

  • Start “Component Services”
  • Choose Computers
  • Choose “My Computer”
  • Choose “DCOM Config”
  • Choose the service matching the APPID. In this case Microsoft SQL Server Integration Services 12.0
    2017-05-18 18_05_32-mRemoteNG - mgRemoteNG.xml - SQL PRD 1
  • Click the Security tab
  • Go to Launch and Activation Permissions, Customize, Edit and add the account mentioned. Check the check boxes as below:
    2017-05-18 18_07_13-mRemoteNG - mgRemoteNG.xml - SQL PRD 1
  • Don’t forget to restart the application service (here: Microsoft SQL Server Integration Services 12.0) in order to be sure that the service applied the changes.

Once done, the errors stopped occurring and the event log was kept nice and tidy.

Hope this helps at least someone.


Troubleshooting VSTS Build Agent configuration

While figuring out the BizTalk 2016 Feature Pack 1 ALM feature, the setup & configuration of the Visual Studio Team Services (VSTS) build agent gave me some issues while configuring:

2017-05-01 13_29_31-mRemoteNG - mgRemoteNG.xml - BizTalk 2016 - Demo

The error reads:

Exception of type ‘Microsoft.VisualStudio.Services.OAuth.VssOAuthTokenRequestException’ was thrown.

After searching for quite some time, I noticed the clock on my Virtual Machine was off. Strange, since Hyper-V will synchronized it quite fast after a resumed save.

Funny enough, after retrying, this seemed to do the trick. Long story short: if you have the above error, make sure the clock of your machine is synchronized.