Is there a way to see MSMQ in Workgroup mode... 1

[MrSatan]

Hi All,

I would like to know if there is a way to push message from Server B into Server A (or a confirmation that is impossible).

Server A is running windows 2003, has a private queue in workgroup mode under Domain A. Server B is running windows NT 4 under Domain B, no message queue, but with all the message queue components in option pack registered, such as mqoa.dll, etc...

An application is built in Server B which try to use the queue components to push message to Server A, will that be possible since the Servers are located under different domain and the queue is set in workgroup mode?

Thanks in advance.

Cheers.

 

[dilettante]

Programming Best Practices with Microsoft Message Queuing Services (MSMQ)

Security
Many security problems occur when users log on locally and try to use MSMQ across nontrusting domains. (See Understand What Security Context to Use for more information.)

The easiest test to verify proper security is to connect to the default admin share on the other computer:

\\Machine_Name\C$

If credentials are requested to make this connection, MSMQ will not connect. Unlike SQL Server, MSMQ will not use the credentials supplied to establish that connection. Note that making this connection by itself is not a valid connectivity test, since a share may be accessed by some protocol other than TCP/IP.

I think the last part means even if you can connect to the share, it may have been via (shudder) NetBIOS or IPX instead of TCP/IP. That means that you've proven nothing necessarily about MSMQ being able to connect.

Of course, that said, I was under the impression that a private direct machine queue can indeed locally receive information sent to it remotely from another computer via TCP port 1801.

Same source:

Understand What Security Context to Use
MSMQ validates permissions based on the security context where the work is being done. This typically affects the following: services, Microsoft Transaction Server (MTS) objects, ASP scripts, and users who inadvertently log onto their computer as a local user rather than an authenticated user account.

By default, all services run in the context of a local system. The local system is only a valid account on the computer hosting the service. With the default, MSMQ permissions will fail all receive operations to remote computers. Unfortunately, sends will work because the default for send access is "Everyone." The overhead inherent in attempting to validate an invalid user on the domain shows up as huge delays in sends reaching the destination queue. The classic symptom of this problem has sends immediately succeeding but leaving the sending computer in 30-second intervals (viewable in the performance monitor).

See my underlining above. I'm not sure what's so unfortunate about this, remote receives are discouraged anyway. To me it sounds a bit encouraging for you, since you said you only want to push messages to Server A in your scenario.

I assume you could use a Direct Format Name of the form used in the example:

[tt]"DIRECT=TCP:157.18.3.1\PRIVATE$\MyQueue"[/tt]

See: Format Names

The only glitch is that when using the TCP transport you can't use DNS names, you have to find the IP address and plug it in yourself.

That example would be used at your Server B as the value for the QueueInfo.FormatName property. Server A would set its QueueInfo.PathName to:

[tt]".\Private$\MyQueue"[/tt]


I don't have any of this in use right now, though I could almost swear I have tried it before between two distict workgroups. Been awhile, but I know I was after a solution that permitted what you are after. Turned out I never needed it though, so I can't point to a working example here and it was almost 2 years ago.

Maybe somebody who is more conversant with MSMQ will chime in.

 

[MrSatan]

Thank you very much for the response, I definitely will give the DIRECT:TCP a try. Currently I have been using PATHNAME, DIRECT:OS and DIRECT:HTTP to try on different scenario, and the results are:

Same Domain, Same Machine
- PATHNAME ... work
- DIRECT:OS ... work
- DIRECT:HTTP ... work

Same Domain, Different Machine
- PATHNAME ... not work
- DIRECT:OS ... work
- DIRECT:HTTP ... not test yet.

Different Domain, Different Machine
- PATHNAME ... not work
- DIRECT:OS ... not work
- DIRECT:HTTP ... currently testing on this

And my goal is required a working solution in Different Domain, Different Machine scenario, with one machine with queue in workgroup mode, and the other machine without queue.

Thank you.

 

[dilettante]

One other tip I've seen (but not tried) is:

Nine Tips to Enterprise-proof MSMQ (cont'd)

MSMQ uses the standard Windows security model. You can configure queues to permit only senders and receivers with appropriate security privileges. Security is an ever-increasing issue at most companies. I have found that the tradeoff for including Windows security in messaging is that it takes about 2.5 times as long to send the same messages. By configuring MSMQ not to send the security descriptors associated with the sending application, you can obtain significant performance gains. To configure MSMQ not to send a security descriptor with the message, set the message property AttachSenderID to False (the default is True), for example:

[tt] msmqMessage.AttachSenderId = False[/tt]