Well, I finally had some time to delve into the source code. I searched the source code for JbossAS, Jboss-Messaging, and Jboss-Remoting. I did not find the root cause (EXACTLY), but I did find a solution. POSSIBLE ROOT CAUSE: InetAddress.getLocalHost().getHostName() - contains my full server name InetAddress.getLocalHost().getHostAddress() - contains 127.0.0.1 As already described in the last posts, it seems that Jboss on my Test server seems to be using the first method, and my QA server seems to be using the second method. There are many areas in the source code where a choice is being made about which one to use. However, I could not isolate the one that was causing the problem. Given that I have a solution, I am not sure that it really matters. SOLUTION: In searching through the Jboss-Messaging code, I found the code that parses the remoting-*-service.xml files. The class is org.jboss.remoting.transport.Connector. There is a method inside that class that parses the xml: private void getInvokerConfig(Map invokerConfig) There is some logic in that method that lets you (sort-of) override the "serverBindAddress" default. If I add an attribute to the XML file of "clientConnectAddress" and use my server name as the value, I can get the desired behavior. The jboss.bind.address will still be 0.0.0.0 and the ports will be open to remote clients. Also, my clients WILL NOW receive my.server.name in the serverLocatorURI. In summary, my commandline will open the ports for remote clients like so: run.sh -b 0.0.0.0 -c messaging And my (2) new lines added to my remoting-bisocket.xml will ensure that the serverLocatorURI will be correct for the remote clients: ... balin.flpi.com 4457 ... Rich View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157452#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...