Error Message: Error 0xc00e0013, No Connection with the Sites Controller

ID: Q191989

The information in this article applies to:

Microsoft Message Queue Server version 1.0

REFERENCES

Microsoft Windows NT Resource Kit

MSMQ Administrator's Guide

MSMQ Release Notes

SYMPTOMS

"Error 0xc00e0013" is a very general MSMQ-generated error which indicates that a connection could not be made between a client and a Primary Site Controller (PSC).

CAUSE

The most common causes of this error are related to security or name resolution. The error commonly occurs when you are installing an MSMQ Client (either independent or dependent) to a Primary Enterprise Controller (PEC) or to a PSC. It may also occur when installing to a stand-alone PEC.

In this article we will refer to the server as a PSC, although it can also be a PEC. Both PEC and PSC serve the same purpose. The only difference is that you can have only one PEC in your MSMQ Enterprise, and it has an MQIS database with read/write permissions. A PSC has an MQIS database that is read-only. If none of the solutions listed here solve your problem, you may need to contact Microsoft Product Support for additional assistance.

RESOLUTION

Microsoft Message Queue Server is a client/server-based network communications platform that custom applications can be written to using the MSMQ API. For MSMQ to provide fast and reliable network communications for your application, MSMQ servers and clients must be configured to very strong thresholds during installation and deployment. Because of this, certain facets of domain, local, and workgroup security may affect setup. In addition, networking and Windows NT-related services such as WINS and SQL must also be fully functional at time of setup.

The error message

Error 0xc00e0013, No connection with the Sites controller.

is generated by the MSMQ setup process and is a very generic, but not critical error. If you receive this error message when you install an MSMQ component, it is important to evaluate what the MSMQ setup process is trying to accomplish at the time the error occurs.

Security

First we will look at security issues, which are the most common cause of the error. Confirm the following information in your environment.

If both the client and PSC are in a single Windows NT domain be sure you are logged on with a valid domain user account and password. This account must have local administrative privileges on the client computer.

If the client is in a different domain than the PSC, make sure there are appropriate trust relationships between the domains or that mirrored accounts are used. For example, If User1 is logged on in domain A and there is an identical account in domain B named User1 which has identical passwords, then User1 can install a client in domain A to a PSC in domain B, without any trust relationships between the two domains. This is normal Windows NT-level security. If you would like to learn more about using mirrored accounts between non-trusting Windows NT domains, refer to your Windows NT documentation.

If the client exists in a workgroup or standalone environment, and the PSC exists in a domain, the same use of mirrored accounts as stated in the previous example applies.

If both client and server exist in a standalone or workgroup environment, the Guest account on the PEC/PSC computer must be enabled. When the client logs on to the server, it uses the guest account to write the addition of the client to the PEC's MQIS database. The Guest account can be disabled again after the client setup is complete, unless other operations will require that data be written to the hard disk drive of the server from the client.

Change Login Security Mode

If none of the above apply, change the Login Security Mode using the following steps:

On the PEC/PSC open SQL Enterprise Manager. (You may need to register the server if you have not already done so.)

Right-click the name of the server that contains the MQIS database, click Configure, and click the Security Options tab.

Change the Login Security Mode to Windows NT Integrated.

Stop and restart the SQL service.

Try to reinstall the MSMQ client.

Verify Communication

If none of the previous solutions apply, you must verify that the client can communicate with the PSC. MSMQ communicates between clients and servers by NetBIOS host names.

Try pinging the PSC computer from the client computer. First try Ping by name and then Ping by IP address. Both should return quickly (time less than 10 ms). If you can Ping by IP normally but Ping by name is slow, the name resolution is being resolved by an ARP broadcast, not by WINS or LMHOSTS. Name resolution by ARP broadcast is too slow for use with MSMQ. It will also cause unnecessary use of the segment bandwidth. You must have a valid WINS or LMHOSTS and HOSTS entry for each computer. Refer to your Windows NT documentation for help in configuring a WINS service or LMHOSTS and HOSTS files. Keep in mind that if the clients on your network are getting a dynamic IP address assigned by a DHCP server, you must use WINS or DNS for name to IP address resolution. The use of an LMHOSTS and HOSTS files, requires that both the client and PSC IP addresses be static.

Security and Network Settings

If none of the preceding solutions work, carefully review your security and networking settings. MSMQ is meant to run on a typical Windows NT network with either domain or workgroup security, and use WINS, DHCP, and DNS services for IP address and name resolution. Review your Windows NT documentation for further assistance in these areas. If no solution is achieved, you should contact Microsoft Product Support for further assistance in troubleshooting.

Additional query words:

Keywords : MQDeploy MQSecurity
Version : winnt:1.0
Platform : winnt
Issue type : kbprb