BTDF support for BizTalk 2016 - ItemDefinitionGroup Error

You get the error " The element <ItemDefinitionGroup> beneath element <Project> is unrecognized."
when trying to use the sample scripts to set up automated deployment for a BizTalk 2016 application using BTDF. In one way this is a good thing as you're probably one step away from success.

It's an easy fix. the issue is in the BTDF suggested script in the line "%windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe"... The sample script by default targets MSBuild for the .Net 2.0 framework and BTS 2016 needs MSBuild targeting the .Net 4 framework.

Change the line to "%windir%\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" to target MSBuild from the .Net 4 framework and the problem dissolves.

BRE not working

Problem: You're trying to use the BizTalk BRE and it is simply not working. No visible errors found in event logs

Solution: Have you checked that the 'Rule Engine Update Service' is started? Sometimes account changes may affect the service logon. Make sure the service is started and that the username and password under which it is configured are correct.

A correlation set may be initialized only once

Haven't posted in a while, but I just thought this might really save someone some time one day.

Ever had this error and wondered, after lots of head scratching, why you're getting it? I googled in vain and every one kept stating the obvious. Which of course didn't solve my problem (as the obvious hardly ever does).

In my case, I wasn't initializing the correlation set in more than one send shape, there was no other correlation set being initialized in the whole orchestration, and I just couldn't get the error to go away no matter how much I fiddled with things.

In the end I almost slapped myself :). It turns out my correlation scope was in a loop which had been initialized in a parent scope. Technically, this would keep initializing the correlation set, even though in reality, my design would not.

I moved the correlation set into the child scope (where it belonged) and voila! error gone.

Hope this helps some BizTalker out there

Null reference exception when trying to open the BTS admin console

BizTalk Administration Console applications node throws the error 'object reference not set to an instance of an object' and refuses to open

I have been having issues with WMI on my dev VM. It literally feels like the VM is a living thing! I come in in the morning and it presents me with a brand new issue to resolve each day. Being on a time-starined project and therefore not having the time to rebuild the entire VM, I keep 'patching' the VM just to cross the finish line. It must be noted that none of the issues affect the actual code I am developing, just the environment in which I have to unit test things before handing over to test.

So the latest one this grey monday morning was this: I started up the VM, opened BizTalk server admin console and presto! I get an error when trying to expand the applications node. The error is basically that dreaded 'object reference not set to an instance of an object' error that every developer using Microsoft / .Net products dreads. The schpiel is a litany of the sort 'microsoft.biztalk.exceptionmessagebox.btsexceptionmessagebox' blah blah blah... but I had no doubt whatsoever (and still have none) that it wouldn't lead me any closer to the real problem.

As it turns out, it is due to the BizTalk WMI namespace being corrupted. I was not surprised to find that out since WMI had been trying to be my nemesis on this project for a few days now, and I have (even surprising myself) somehow managed to limit the time damages and soldier on with the deliveries nonetheless, fixing each new problem it threw at me on a daily basis.

The fix is simple.

Open a command prompt window and browse to the WMI folder (C:\windows\system32\wbem).
Type in the following command (I am using BizTalk 2013, but this problem could happen with any versiobn of BTS, so use the correct folder path)... mofcomp "D:\Program Files (x86)\Microsoft BizTalk Server 2013\Bins32\BTSWMISchema.mof"

That should rebuild your namespaces nicely.

Now try to re-open the BTS admin console and you should be able to see the applications.

Fixing the WMI Connect error when configuring BizTalk Server 2013

Fix: Error occured in CWMI::Connect error during BizTalk Server 2013 configuration

I came across this error randomly whilst configuring a BizTalk server 2013 installation on my dev VM. It led to some head scratching, and ole' google wasn't quite clear with all the solution sposted on there.

After trawling through the suggestions and solving the problme on my VM, I though I'd point out the two step process that worked for me, with references to the relevant posts.

So, my specific problem manifested in a very ugly configuration summary window with only SSO and Rules Engine deployed, and when I clicked on the logfile link in the summary and scrolled through the huge log file (I basically did Ctrl-F and serached for the word 'error'), I found the following error. Error occured in CWMI::Connect
Now, I should mention that this is the second time I got this error on this same VM, and it took me ages to fix the problem the first time. May I also point out that this error seemed to occur both times after a BizTalk server uninstallaion and subsequent re-installation. Apparently, one colleague suggested that stopping the WMI service (Windows Instrumentation Service) before uninstalling BizTalk would avoid this problem. I wish I'd know that earlier, and I am definitely not intending to test the VM now to prove that theory. I decided that this time, I would try to remember the steps that worked the last time and pen them down.

The first bit was this link, obviously written by someone who knows what he's talking about: http://blogs.technet.com/b/configmgrteam/archive/2009/05/08/wmi-troubleshooting-tips.aspx

I basically opened a command window as administrator, copied this bit below and pasted it after relocating thwe prompt to C:\Windows\Syswow64\wbem

FOR /f %s in ('dir /b /s *.dll') do regsvr32 /s %s

Net stop /y winmgmt

FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s

Net start winmgmt

The next bit was testing my system32 wbem repository. Using information from this link: http://blogs.technet.com/b/askperf/archive/2012/03/09/unable-to-connect-to-wmi-locally-win32-the-system-cannot-find-the-path-specified.aspx

I moved the command prompt location to C:\Windows\System32\wbem\ and typed the following command:
winmgmt /verifyrepository

This returned the results
wmi repository verification failed
error code 0X8007007E
 
I then used the post by Joson Zhou on this thread: http://social.technet.microsoft.com/forums/windows/en-us/b5f0abba-8a36-457f-912d-81533b6750d4/wmidiag-report-errors

I basically stopped the WMI service, then browsed to C:|Windows\System32\wbem\Repository and copied all the files in there to a safe location, then deleted all the files in the folder.

I then re-started the VM.

I tried to re-configure BizTalk Server 2013 after those steps and voila! It worked.

Fixing the "Session "BizTalkDefaultTrace" failed to start with the..." error

Annoying "Session "BizTalkDefaultTrace" failed to start with the following error: 0xC0000022" error on BizTalk Server machine.

I have just finished a very grey-hair inducing multi-server, high-availability installation of BizTalk server 2013with BAM and ESB on a clustered SQL server infrastructure. (I intend to fully document the process by the way, including all the problems you can potentially face and the solutions to those probmes, as there aren't really any clear documents describing the process from beginning to end out there

As you can imagine, after soldiering my way through the myriad of problems encountered especially with the 'gotchas' of the new ESb toolkit 2.2 installation and configuring procedure keen to make sure that everything (and I mean everything) worked perfectly, and then I re-started all host instances and got the annoying error above. funny thing is, we see this error a lot in Biztalk server installations, but because it is not critica;l, noone fixes it. appraently, the fix is dead easy according to this thread:

It would appear that when you try to start a host instacne that has tracking enabled, BizTalk Server wants to start up a ETW trace session called "BizTalkDefaultTrace". This hangs because the service account user running the host instance does not have the required permissions to create the trace session, and voila, your error appears.

Simply adding your problematic service account users to the windows local group 'Performance Log Users' fixes the problem. I have shown this below in Windows server 2012 R2

Open 'Administrative Tools' from the desktop

Open 'Computer Management'

Open 'Local Users and Groups'

Find the 'Performance Log Users' group

Right-click on it and click on 'Properties'

Add each of the service account users running the problematic host instances

This should fix the issue.

ESB Portal Error Could not load type 'System.ServiceModel.Activation.HttpModule' ...

Fixing the “Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'’ error for a new installation of the ESB portal on BizTalk 2013:

Open IIS Manager

Open the ‘Default Website’ node
Click on the ESB.Portal application
Go the right hand pane and click on ‘Browse *:80 (http)’

If you get an error page with the message “Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'’ then use the following steps to fix it.

1. Click on the IIS root node
2. Click on ‘Modules’ in the middle pane
3. In the middle pane, under the ‘Name’ column, find the ‘ServiceModel’ entry (not the ‘ServiceModel-4.0’ entry)
4. Click on ‘Remove’ in the right pane to remove it
5. Click on the ‘Default Website’ node
6. In the middle pane, double-click on ‘Handler Mappings’
7. Remove current the Managed Handler for svc-integrated (might be called svc-integrated 2.0)
8. In the right pane, click on ‘Add Managed Handler’
9. Enter the following parameters:

• Request Path: *.svc
• Type: System.ServiceModel.Activation.ServiceHttpHandlerFactory, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
• Name: svc-integrated-4.0

Click on ‘OK’

Try to browse the ESB Portal again. It should be fine now.