Configuring a Remote WAS-hosted Queue

  • Article

Creating a reliable service for MSMQ has been made simpler with the introduction of Windows Process Activation Service (WAS). Your deployment scenario may make it easier to have WAS running on a separate machine from where the MSMQ queue of interest is located. This post will go through the steps to get a simple sample running under these circumstances. We will be assuming setup through the IIS manager GUI for the instructions.

 

Here are the steps:

1. Create a queue on the ‘remote’ machine.

2. Create (or edit) a site in WAS to use for your application on the ‘server’ machine. Each site can only read queues from one logical machine.

3. Bring up the ‘Edit Bindings’ dialog for the site. Add (or edit) the net.msmq or msmq.formatname entry, setting the ‘Binding Information’ field to the name of the computer that will host the queue. For locally hosted queues, this field is usually set to ‘localhost’.

4. Create your application as you normally would – add your code, service file etc. Ensure that the NetMsmqBinding or MsmqIntegrationBinding that is being used for your service has the address of the remote queue (e.g. “net.msmq://remote-machine/private/myapplication/myservice.svc”).

5. Go to the Advanced Settings of your application. Under ‘Behavior’, edit the Enabled Protocols field to add in your MSMQ protocol of choice (comma separated, e.g. “http,net.msmq”).

6. Ensure that MSMQ is allowed through your firewall on both machines. If you’re using transactions, ensure that Distributed Transaction Coordinator (MSDTC) is also allowed through the firewall.

6a. If you’re using transactions, you’ll need to allow network access for MSDTC on both machines. If you run the command ‘dcomcnfg’, then go ‘Component Services’ -> ‘Computers’ -> ‘My Computer’ -> ‘Distributed Transaction Controller’ -> ‘Local DTC’ -> ‘Properties’ -> ‘Security’ tab, there are appropriate settings there.

7. By default, both the application pools and the listener service (called “Net.Msmq Listener Adapter” in the services pane) run under the ‘Network Service’ account. Both of these applications require access to the queue, so ensure that the appropriate users are given access to read from the queue.

 

This should be enough to get your application running. If you’re anything like me, sometimes it doesn’t ‘just work’. So here’s some simple troubleshooting steps to point you in the right direction:

 

· From an elevated command prompt, restart the listener adapter by using the commands ‘net stop netmsmqactivator’ and ‘net start netmsmqactivator’. It can take up to ten minutes for WAS to detect changes in queues, so this should force WAS to recheck the queues.

· Enable metadata exchange for your service. This involves enabling HTTP in the ‘Enabled Protocols’ of your site, and adding the following text to your config file (merging with existing sections, where necessary):

<system.serviceModel>

    <behaviors>

      <serviceBehaviors>

        <behavior name="MyBehavior">

          <serviceDebug includeExceptionDetailInFaults="true" />

          <serviceMetadata httpGetEnabled="true" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

</system.serviceModel>

 

                Ensure that the behavior “MyBehavior” gets added to the <service> tag as ‘behaviorConfiguration=”MyBehavior”’. Now browse to your service file. This can be done by finding the service file in the IIS manager view and clicking ‘Browse’. If the metadata doesn’t come up successfully (so you get a HTTP error or an exception), there is a problem with your service that you’ll need to resolve first.

· Try to give the accounts ‘Everyone’ and ‘Anonymous’ full control of your queue. If the service begins working, it is probably a security issue.

· Try to disable your firewall on both machines. If it begins working at this point, the exceptions in your firewall are not correctly configured.

 

--Nathan Healey