Queue Components over the network
Ramesh Jonnala
Active Directory, but it does not work. Am I required to setup a Active
Directory to do this?
I get the following message:
An unexpected error was returned by the MSMQ API function indicated. The
following error message was retrieved from MSMQ.
MQPathNameToFormatName : Unable to establish a connection with Active
Directory. Verify there are sufficient permissions to perform this operation
steve
regarding direct format names in MSMQ.
we are trying to connect one PEC to another PEC across the internet...a few
questions, if you dont mind answering
1. can someone provide some code snippet on exactly that the code to send
directly to the remote que is? i was using the SEND (broker) example that MS
on their site and found it tough to get it right.
1. Would you consider MSMQ PEC to PEC across internet with Direct Format
Name to be fast? anyone test the throughput, assuming some decent t1, frame
connection?
Any other recommendations on connecting many (200) PEC domains to a central
PEC? is Direct Format name bestway to do it.? would trusted domains be
reasonable as well?
Regards,
Steven Goldman
Chief Executive Officer
Trade Manage LLC
33-00 Broadway
Fair Lawn, New Jersey 07410
(201) 791-6475
(201) 475-9370 fax
This message is intended for the recipient designated above. It is not a
solicitation, confirmation, recommendation or endorsement of any
securitites, commodities or other financial products. The accuracy and
completeness of the information is not guaranteed and no Trade Manage LLC
member, or any employee or agent thereof, shall be liable for any loss or
damage arising therefrom.
Ramesh Jonnala <ramesh...@hotmail.com> wrote in message
news:OjEotU8f$GA....@cppssbbsa02.microsoft.com...
steve
Frank Boyne
news:OnyIMZur$GA.261@cppssbbsa05...
> 1. can someone provide some code snippet on exactly that the code to send
> directly to the remote que is? i was using the SEND (broker) example that
MS
> on their site and found it tough to get it right.
A simple VB program can be found at
http://support.microsoft.com/support/kb/articles/Q172/6/88.ASP?LN=EN-US&SD=g
n&FR=0
This program opens a queue called 'wiley' at IP address 157.57.12.62. If it
was opening a private queue then the first line of actual code would be
changed to read
txtDirectFormatName = "DIRECT=TCP:157.57.12.62\PRIVATE$\wiley"
A C++ example of opening a queue using a direct format name can be found at
http://msdn.microsoft.com/library/psdk/msmq/msmq_examples_api_2011.htm
This program opens a queue called testqueue at a system identified by the
name 'stevenell'. Again, if the program were to open a private queue the
code would have to change to
LPWSTR FormatName=L"DIRECT=OS:stevenel1\\PRIVATE$\\testqueue";
Note that the string literal uses two slashes (i.e., \\) to represent each
slash in the final format name. That's because otherwise \t would be
interpreted by the compiler as the tab character.
> 1. Would you consider MSMQ PEC to PEC across internet with Direct Format
> Name to be fast? anyone test the throughput, assuming some decent t1,
frame
> connection?
Performance is a pretty subjective topic, what I consider fast, you might
consider slow. Microsoft did publish some performance data a while back,
you should be able to find it at
http://www.microsoft.com/ntserver/appservice/deployment/planguide/msmqperfor
mance.asp
> Any other recommendations on connecting many (200) PEC domains to a
central
> PEC? is Direct Format name bestway to do it.?
If you have separate PECs then DIRECT format names is the only way to do it.
An MSMQ Enterprise is basically a group of MSMQ servers sharing a common
configuration database (the MQIS) which is stored at the PEC and replicated
(somewhat) at the PSCs and BSCs. Within a given enterprise, non DIRECT
format names can be used to identify a queue because the PEC or PSC can be
used to look those names up in the MQIS.
In your case you have two PECs, which means they don't share any
configuration data, they have independent MQIS databases. Thus, a queue on
one PEC cannot be looked up in the other PEC's MQIS. Only DIRECT format
names will work when going from one PEC to another, or from any MSMQ system
in one MSMQ Enterprise to a queue on an MSMQ system within another MSMQ
Enterprise.
> would trusted domains be reasonable as well?
Setting up a trust relationship between two NT Domains only affects security
and authentication, not MSMQ itself. If you have two PECs in two NT
Security domains and set up trust relationships between the two NT Security
Domains, you still have two separate PECs with two separate MQIS. You'd
still have to use DIRECT format names.
That said, if you were able to set up trust relationships between the NT
Security Domains, you might also be able to set up a single MSMQ Enterprise
with a single PEC and 200 MSMQ servers (or even 200 MSMQ independent
clients). If you did that, then all 200 systems would share a single
configuration store and so you could use other format name types, path
names, and even search for queues using Lookup. That however is probably
more of a political problem than a technical one ;-)
steve
was able to get it running over the internet. Infact, we then implemented
MS's RRAS VPN so that a great number of sites can 'tunnel' into the VPN
server (PEC).
each of the remote offices hasa PEC of their own.
i am running into an issue as it relates to understanding CN's.....there is
little documentation on how or best way to define a CN. what exactly is it?
sure i know its a connected network, but what should it ideally represent?
in my scenario with a large number of remote offices and single central
offices, connectingover the VPN solution (by the way, when youtunnel out and
then into the vpn server, the vpn server asisgns a IP local tot he VPN
server as though you were right on the server's network.;...
my problem is that I would assume that each office would hav a connected
netowrk, actually 2. one connecting the remote PEC to the REMOTE offices'
machines (local lan) andone connected the remote office to the CENTRAL PEC
via. VPN.
do you ahve to right clikc/properties on the machine and add both Networks?
when i did, i get an error on startup.
basically the net of is, I can definately send tons of messages from remote
office to the central que. i properly receive themessages, but if i reverse
the flow, using same app and using , nothing shows on que. messages
definately cming over linkage since I can the dialup netowrk linkage with
lots of bytes moving...
i think it has to do with properly defining connected netowrks.
lets say my central server with PEC on it (also is a VPN server) has an IP
of 192.168.250.54. i made a CN on that machine of TMANBACKUP.
i then have remote offices which have PEC's on them, and each has a CN for
each remote office iee.
REMOTE1for office one
REMOTE2 for office two.
on the PEC i have one CN, the tmanbackup.
on each remote, i create two cn's in the 'rightclick' site, Create New
CN...i have the REMOTE1 and then the central CN of tmanbackup.
i know its a lotof detail and perhaps not too clear, but if it helps, i've
love a little more guidance.
i've got my system running 100% one way, but can seem to getmessages back,.
must be permissioning,etc.
thanks a million
-steve
Frank Boyne <Frank...@Upstanding.com> wrote in message
news:#z7zXKjt$GA.279@cppssbbsa05...
Frank Boyne
> i am running into an issue as it relates to understanding CN's.....there
is
> little documentation on how or best way to define a CN. what exactly is
it?
> sure i know its a connected network, but what should it ideally represent?
An MSMQ Connected Network is a hint to the MSMQ routing capability about
your MSMQ topology. Two MSMQ systems which share a common CN are assumed to
be able to communicate directly with each other. That means that those two
systems don't need MSMQ routing to handle delivering messages from one to
the other through one or more intermediate nodes.
Like many things in MSMQ, a CN is configuration data which is really only
significant within the context of a single MSMQ Enterprise. That is, if you
configure a CN called MYCN1 in one MSMQ enterprise and a CN called MYCN1 in
a second MSMQ enterprise, those are really two completely seperate Connected
Networks.
Most likely, an MSMQ system will have one CN per protocol supported (IPX and
or TCP/IP) per network interface card. So for example, an MSMQ server with
three NIC cards supporting NETBIOS and TCPIP on each card might be
configured in MSMQ as being connected to six Connected networks. This
number could be reduced if you knew that a protocol was supported by the NIC
but not used by MSMQ - so for example you might not need an IPX CN on
interface card 1 (even though that interface card supported IPX) if you
knoew there were no other MSMQ systems using IPX to communicate via that NIC
card.
The number of CNs can also be reduced when two NIC cards are attached to the
same physical network
> in my scenario with a large number of remote offices and single central
> offices, connectingover the VPN solution (by the way, when youtunnel out
and
> then into the vpn server, the vpn server asisgns a IP local tot he VPN
> server as though you were right on the server's network.;...
> my problem is that I would assume that each office would hav a connected
> netowrk, actually 2. one connecting the remote PEC to the REMOTE offices'
> machines (local lan) andone connected the remote office to the CENTRAL PEC
> via. VPN.
I've never used VPN, so I'm not sure of the answer to this question, sorry.
> basically the net of is, I can definately send tons of messages from
remote
> office to the central que. i properly receive themessages, but if i
reverse
> the flow, using same app and using , nothing shows on que. messages
> definately cming over linkage since I can the dialup netowrk linkage with
> lots of bytes moving...
If the traffic is flowing over the dial-up, then I'd guess that CN
configuration isn't your problem. If you had the CNs wrong, then I wouldn't
expect the MSMQ Queue Manager to even try delivering data, so I wouldn't
expect to see much traffic. It sounds as if the message is travelling to
the remote office, and *then* is failing to be placed into the queue. You
might want to check that the queue does exist and is configured with the
appropriate permissions to allow the message to be inserted into the queue.
One thing you could try to diagnose this problem is to set the property
PROPID_M_ACNOWLEDGE to MQMSG_ACKNOWLEDGMENT_FULL_REACH_QUEUE in the message
being sent from the central server and set the property PROPID_M_ADMIN_QUEUE
to specify the DIRECT format name of a queue on the central server. That
way, when the message reaches the remote office an acknowledgement message
will be sent back to the queue identified by PROPID_M_ADMIN_QUEUE. You can
use the MSMQ Explorer to view that acknowledgement message. If it is a
negative acknowledgement, it will have some indication as to why the message
failed to be inserted into the queue.