Hello World MSMQ! ...from Windows Containers
Published Mar 21 2019 05:16 PM 5,907 Views
Brass Contributor
First published on TECHNET on Jul 25, 2018


Hello from Microsoft Hackathon!!!

What are we hacking? Containerizing MSMQ! Let me tell you more…

MSMQ (Microsoft Message Queuing) is one of the top asks from Enterprise customers who are lifting and shifting traditional apps with Windows Containers. We are hearing that in our conversations with customers directly, especially with major financial institutions. It is a blocker in their containerization journey. We are also seeing the same ask in online communities like the following on User Voice and MSDN Forum:

Back in January, I blogged that we fixed the issue that MSMQ didn’t install at all in Windows Server Core containers. With Windows Server version 1803 release, MSMQ now installs. As the old saying, devils are in the details. In our effort to make the end-to-end scenarios work with MSMQ in containers, we learned that there is a long list of components, features, technologies and teams involved to make it fully working end-to-end for typical Enterprise customer scenarios. To name a few: Container Networking , Active Directory , Group Managed Service Accounts . And it also brings another top customer ask supporting MSDTC in Windows containers to the spot light. So, I decided to take this challenge to our internal Hackathon!

In the first a few hours when we started the Hackathon, we identified a prioritized scenario list we’ll target to hack on. I will share the details of the scenarios in future blogs. But first I am happy to share that today we validated the first scenario working. It’s a very “Hello World” alike scenario that sends messages from a Window container using MSMQ. Here is the basics of the scenario:





  • Set-up

    • Container Host: Windows Server v1803 or higher, OR, Windows 10 April 2018 Updates or higher

      • A quick note: In today’s Hackathon, my teammate who validated the scenario was actually on the most recent build of Windows 10 which is not even out for Insiders yet but we did test on Windows Server version 1803 and version 1809 pre-release builds before :smiling_face_with_smiling_eyes:



    • Container Image: Windows Server v1803 Server Core container



  • MSMQ Configurations

    • Queue Scope: Private

    • Message Type: Transactional

    • 2 Simple apps using MSMQ to simulate the most basic send/receive operations:

      • MSMQSenderTest.exe

      • MSMQReceiveTest.exe



    • Queue Location: on the same container as the Sender/Receiver.

    • Where the sender and receive sit: to simplify things, both the sender and receiver testing apps run directly inside the above mentioned Container Image. This is far away from a real-world scenario but remember we are starting with baby steps.




And Voila… we can send and receive messages in a Windows container!



Is it too basic? Yes it is. We know. As mentioned early on, we have worked on this on and off, and have tested a few other scenarios. Here is a quick glimpse of what we have tested or are still testing on. We will share more details in future blogs.
Scope Transactional Container OS Container Host OS Queue Location Send Works Receive Works
Private Yes Windows Server version 1803 Windows Server version 1803 On the container Yes. Yes.
Public Yes Windows Server version 1803 Windows Server version 1803 On the Domain Controller (DC) Yes.  There are some security caveats we'd like to address. Haven't tested
Public No Windows Server version 1803 Windows Server version 1803 Not on the container, or the container host, or the DC, but another box Yes.  There are some security caveats we'd like to address. Haven't tested
Public Yes Windows Server version 1803 Windows Server version 1803 Not on the container, or the container host, or the DC, but another box No. Haven't tested



The top 2 rows are more basic scenarios for us to get started and troubleshoot. The last 2 rows in our view are most close to what Enterprise customers might be using. Is it true? We’d love to hear your validation.

We didn’t test the scenario where the queue is a Private one and the messages are non-transactional. We believe as the scenario of a private queue with transactional messages works, a private queue with non-transactional one should work too as it’s less complex.

As we peel the onions layers by layers, it’s becoming more and more obvious that we can use all the help inside and outside Microsoft to get this going, as MSMQ is a technology out for a long time, and there are lots of you who are experts on this. We’ll look into to ways we can sort of “crowdsource” or “group-think” to get the community involved. We will share more details on that in future blogs.

OK, this is for now and I need to get back to the Hackathon! Wish me and my teammates (Andy, Jane, and Ross) good luck!



Weijuan

P.S. I am building up my Twitter presence which seems a popular place to keep people updated. I'll share updates more frequently there. Follow me @WeijuanLand
2 Comments
Copper Contributor

@Virtualization-Team Thanks for the hard work!

 

I've been working on determining whether or not I can containerize an application using MSMQ as the message transport for an SOA application.  (Why MSMQ? Many businesses are still using MSMQ and are not in a position to quickly migrate off of this technology. So knowing that MSMQ works in Docker Windows containers for legacy applications should be good news for those who would like to reap the benefits of containerization while they make their plans to transition to some other message transport.) To do this, I'm making use of Windows Server 2019 LTSC, and Particular Software's NServiceBus suite of software.

 

Today, I was able to spin up 3 containers, one hosting a Microsoft SQL Server 2017 CU14 database server, another hosting Particular Software ServiceControl (it's a management application that lets you see what's happening on the service bus) and an NServiceBus endpoint. Furthermore, I was able to open Particular Software's ServiceInsight and connect it to the ServiceControl instance running in the container. I was able to see that ServiceControl was aware of the existence of the NServiceBus endpoint (i.e. the endpoint was displayed in the Endpoint Explorer queue). This means that messages are flowing between the two containers via MSMQ.

Copper Contributor

Hi, I hope this is a good place to post my situation with MSMQ and containers

I've tried to get MSMQ working for our use case but can't seem to do so. Basically,we are trying to use private queues in a server core container which are accessed through WCF (need the net msmq binding and msmq integration binding to work) from another container sharing the same NAT network.

Has anyone gotten this use case to work? If so, how?

I've tried setting the bind ip for MSMQ to the network adapter used by the container, exposing all the MSMQ ports through the Docker Build file, added the Everyone and Anoynmous Logon permissions to the queues, set the MSMQ security registry values inside the containers, and tried direct=os and direct=tcp using the container hostname and IP.

When trying to open the queue, I am always getting "The queue does not exist or you do not have sufficient permissions to perform the operation. (-1072824317, 0xc00e0003). The message cannot be sent or received from the queue. Ensure that MSMQ is installed and running. Also ensure that the queue is available to open with the required access mode and authorization. "

Accessing the queue from the same container that is hosting the queue works with WCF, but not from a different container (both running the same windows core image).

Version history
Last update:
‎Mar 21 2019 05:16 PM
Updated by: