Recently, we wanted to create multiple WCF services that should communicate with each other through the netMsmqBinding binding and we wanted to use a clustered MSMQ service.
However we encountered some problems and wanted to share them with you.

Situation: We run MSMQ as a part of resource group on a cluster. The service is hosted in WAS and the application pool runs under a functional user.

1. Without Windows Integration

Note: In our WCF service the security mode is set to "None".

When our services ran and started to communicate with each other we did not get any messages  in the queue as we expected, actually we did not find any message on the clustered MSMQ but we saw in our tracing that the WCF service did not report any error to place a message on the queue.

After some investigation we found all test messages in the local System queue “Transactional dead-letter messages” with the report “Access denied”.

So our first thought was to check the MSMQ security on that particular queue: we started up mmc, connected to the clustered resource e.g. “MyclusteredResource” to check on the MSMQ security:

There we wanted to check the security on a queue (by right clicking on the queue) we noticed we did not have a properties option.

It seems that you cannot configure MSMQ security when connecting through the mmc console.
Microsoft pointed out that we should use an other tool to configure the security (mmcv.exe).

You can download mmcv.exe : http://www.microsoft.com/download/en/details.aspx?id=18189

You use it as follows on the active node (Where the MSMQ resource is running):  
"<drive>:\<directory>\mmcv -s <Network Name of the clustered MSMQ resource>"  

When you drill down to the MSMQ queues we finally got the properties option. So we went on to check the security.

Note: If you are running the mmcv.exe tool on the non-active node you will not find the Message Queueing option.

It seemed that Everyone had full control and yet we got the error message “Access denied”

After a bit of searching we found the following KB article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;952570 and following blog http://blogs.msdn.com/b/tomholl/archive/2008/07/13/msmq-wcf-and-iis-getting-them-to-play-nice-part-2.aspx

This explained why we got the error message “ the message does not include the security header. Therefore, the message does not contain the user ID of the sender "

So we added the “ANONYMOUS LOGON “ to the users and gave him the appropriate rights to read / write on the queue.

After that we ran a test and all messages were delivered on the clustered MSMQ! 

In the next step I’ll show you how you can check and enable the Windows Integration on your server...

2. With Windows Integration

Through the Features option in the server manager (Server 2008) you need to check if Directory Service Integration is enabled. Be aware that you need to do this for each node.

Once this feature is installed and your resources went online, an MSMQ object should be created in the active directory record of your network resource hosting your MSMQ e.g. “MyclusterresourceYou” can check it by the following steps:

Open the Active directory Users and Computers.

Through the View otpion select "Users, groups and computers as containers"

Finally search for your network resource and check if it has a MSMQ object.

If you don’t find any MSMQ object it is possible that when Directory Service Integration is installed afterwards no MSMQ object is created (more info: http://support.microsoft.com/default.aspx?scid=kb;EN-US;935498)

Once that is fixed, for Windows Integrated security you only need to add your user in the MSMQ security with mmcv.exe

Change your WCF security mode to "Transport" and enable the msmqAuthentication mode so your WCF service is ready to use Windows Authentication.

When you get the following error while starting your WCF service: "Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled. The channel factory or service host cannot be opened" then you need to check the MSMQ object in the active directory (see previous steps).

Jonathan Maes

This is a post, describing an issue we recently had on the Azure Service Bus. 

Situation description

When a single appdomain is opening two (or more) service bus relay endpoints that have the same path (what is added after the servicebus.windows.net), but have a different namespace, the following exception is raised:

System.InvalidOperationException: The ChannelDispatcher at 'sb://repro2.servicebus.windows.net/ordersvc' with contract(s) 'ICustomerService' is unable to open its IChannelListener. ---> System.InvalidOperationException: A registration already exists for URI 'sb://repro2.servicebus.windows.net/ordersvc'.

The following is the configuration of my endpoints (not including the TokenProvider, etc, just the endpoints.

        <endpoint address="http://repro1.servicebus.windows.net/ordersvc"
            binding="basicHttpRelayBinding"
            bindingConfiguration="httpRelayBinding"
            contract="Demo1.Relay.ICustomerService"
            behaviorConfiguration="repro1Behavior" />
        <endpoint address="http://repro2.servicebus.windows.net/ordersvc"
            binding="basicHttpRelayBinding"
            bindingConfiguration="httpRelayBinding"
            contract="Demo1.Relay.ICustomerService"
            behaviorConfiguration="repro2Behavior" />

Why do we need the same services exposed on different namespaces?

Environment seperation

For Codit Integration Cloud, our azure-based integration platform, we are consuming some on-premises web services, exposed over the Azure Service Bus relay binding.  We do this for different services that make part of our runtime.  We also have a deployment cycle where we have different environments (a development, a test, a demo and off course the production environment(s)).

To isolate services, we make sure that every environment has a specific service bus namespace.  This allows for security segregation and to move services on premises, without touching other environments.  So this means that for our EdiFactParser service, we have the following endpoints (different names are being used here):

• sb://intcloud-dev.servicebus.windows.net/onprem/parse
• sb://intcloud-test.servicebus.windows.net/onprem/parse
• sb://intcloud-demo.servicebus.windows.net/onprem/parse
• sb://intcloud-prod.servicebus.windows.net/onprem/parse

As you can see the only difference in the above mentioned endpoints are the service bus namespaces.  As mentioned, these services are hosted on different servers on premises, but in some cases, we host them together.  (for example: dev & test are sharing the same local server).  In our cases, these services are hosted in BizTalk Server receive locations.

Disaster recovery

In the rare case where an Azure center would be out of the air, all service bus namespaces (hosted in that data center) are unavailable.  (There might be something like service bus federation in the future, but that’s not there yet).  To make sure that our on premises services are still available, we could expose these services on multiple service bus namespaces.  (hosted in different data centers).

In the case of a namespace being unavailable, the client that consumes the service could failover and try to consume the service over the second namespace.

How to work around this

This seems to be a bug in the Service Bus dll implementation, but we didn’t got a confirmation of this by product team yet.  (there might be a good reason for this, allthough I don’t see it).  Anyway, to workaround this, you need to open the different endpoints in separate service hosts.  The following describes how to do this.

In BizTalk Server

We initially had the issue on BizTalk Server, where we expose these services over the service bus.  Both receive locations were hosted in the same BizTalk host.  Just moving both locations to a different BizTalk host, solved the problem. 

In regular .NET applications

If you open the service host yourself, it as easy as creating two instances of the ServiceHost class and have them opening the endpoints seperately.

Just wanted to share this one

Sam Vanhoutte

SCOM (System Center Operations Manager) 2007 R2 comes with a very handy utility to create reports.
In this blogpost I will explain how you can create a detailed report concerning the CPU usage for a particular BizTalk Host Instance.

So let's get started!

The first thing you need to do is open the Operations Console.
Navigate to "Reporting > Microsoft Generic Report Library" in the left navigation bar. There you can double-click the report "Performance":

A new window will appear where you can enter some criteria. Here you can enter the timespan of the performance details you want to have. Let's say we want the stats starting from a week ago. To do this you need to modify the "From" date.

The next step you need to do is select the objects you want to visualize in your chart. You will notice a button named "Change" in the upper right corner. If you click on that button a window will appear where you can modify the settings of the chart.

To create a new chart, simply hit the button "New Chart". You can give the chart a meaningful name by setting this in the details pane.
After that you need to set the different series (these are the different objects inside your chart). Click on the button "New Series".

In the series, you can add a group/object. In our case this would be the particular server for which we want to see the CPU usage. Click on "Add Group.." and another window will appear. In the search pane, type a part of the computername and hit the search button. Select the computer you want to add.

Once that object is added, you still need to define the performance counter. You can define this in the "Rule" section. Click the browse button.
In the search pane type "CPU" and select the counter "BizTalk: CPU Usage Server Processes".

In the rule section you will see that you can choose a specific host instance (or all host instances) to which the rule will be applied. 

Now here's the tricky part. The UI only shows the Process name, not the actual host instance name. To know the actual host instance name you need to execute the steps below:

Go to the server that you have added in the object menu (so the server of which you want to see the performance details).
In the server, press start > Run > perfmon, this will open the built-in performance monitor of that server.
Navigate to "Monitoring Tools  > Performance Monitor" and right click in the window > "Add Counters".

Search for the counter "Process > ID Process" and select the process name of which you want to know the actual host instance name (in our case "BTSNTSvc").
Switch the current view to the "Report" view. In this view you can see the current "Process ID" of that host instance.

To link the Process ID to the host instance name, you have to execute following command in the cmd utility of windows:

TASKLIST /SVC /FI "IMAGENAME eq btsnt*"

This will give you a list of all the BizTalk host instances and their Process ID. Be aware that whenever you restart a host instance, the Process ID will change!
Now simply search for the Process ID that you retrieved from the performance monitor and you know which host instance you selected in the SCOM rule (in our case the host instance "CIPGW_ReceiveHost").

When everything is configured simply press the "Run" button at the top left of the window and SCOM will generate a nice chart. You can export the chart as pdf, excel,.. If you like to run this performance report again, you can save all your settings by clicking "File > Publish". This will allow you to save all the settings and run the report at a later time. The report will be available in the section "Authored Reports".

Here is a screenshot of such a report:

I had some trouble with linking the host instance name with the process name, so that's the main reason why I wrote this blog item.

I hope this saves you a lot of trouble :)

Many of us at Codit already installed the WCF LOB SDK multiple times. And in the process we have learned to know the caveats that come with the installation:
- 32 bit vs 64 bit
- Adapter Pack installation (again, 32 bit vs 64 bit)
- Enterprise application installation

Now since BizTalk 2010, there is a great wizard added to the installation screen if you click “Install Microsoft BizTalk Adapters”:

The screen shows up like this once you go through the entire installation:

Please note that the above screenshot is from a production server where I don’t have Visual Studio installed, so I could not install the developer tools (hence the warning)

It is a very welcome change, because before BizTalk 2010, people did not know exactly what they needed to install and in which order.
Now the screen gives you a very handy wizard-style interface.

Now recently I had a strange error: on a 64-bit machine I went through the installation.
I was sure that everything was installed correctly and in the right order!

I checked all machine.config files (for framework 2.0 and 4.0, both 32-bit and 64-bit) and all had the necessary entries added.
However, there was no way I could see/add the WCF LOB Adapters in the BizTalk console:

I went through a lot of online searching until I accidently stumbled upon the BizTalk modify wizard:

It happens that the WCF Adapter components in BizTalk were not installed, so the WCF adapters were not showing up for a good reason!

When I checked both checkboxes (WCF for BizTalk Runtime and Administration Tools And Monitoring), installed it on both nodes and re-opened the BizTalk consoles, I could add the WCF adapters I needed.

I hope this helps at least someone!