Troubleshooting administration problems

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Troubleshooting administration problems

This topic provides guidelines for solving problems associated with viewing or setting properties, accessing objects in Active Directory, or using the snap-ins for Message Queuing.

What problem are you having?

You cannot find Message Queuing under Services and Applications in Computer Management.
You cannot find any objects for Message Queuing in Active Directory.
You cannot access any objects for Message Queuing in Active Directory.
You are unable to establish a connection with Active Directory.
Changes you made do not show up in Active Directory.
Windows NT 4.0 clients and local users cannot access Active Directory.
You cannot access the contents of a particular queue.
You cannot create queues.
You cannot send messages to another site.
You cannot send or receive authenticated messages.
Messages sent to a queue are rejected.
You cannot retrieve messages from a queue.
Messages can no longer be delivered to a particular computer or queue.
Express messages are missing or lost.
Transactional messaging does not function for dependent clients.
A test message cannot be sent to a particular queue.
You cannot access messaging files stored locally on disk.
You cannot locate the audit messages for a particular operation.
There are problems communicating with IPX computers.
Dependent clients cannot run Message Queuing applications.
Resources for Message Queuing have timed out in a server cluster.
A foreign site to which a Windows Server 2003 Message Queuing server with a connector application belongs does not appear in the list of sites for that server.
You cannot register a user certificate for Message Queuing.

You cannot find Message Queuing under Services and Applications in Computer Management.

Cause: The Message Queuing service is not running.

Solution: In the Computer Management console tree, under Services and Applications, click Services. In the details pane, under Name, right-click Message Queuing, and then click Start. Restart Computer Management.

You cannot find any objects for Message Queuing in Active Directory.

Cause: You have not selected the necessary view options for these snap-ins.

Solution: In Active Directory Users and Computers, on the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features. Message Queuing objects are typically located under the Computers container or the Domain Controllers container.

When Message Queuing is running in offline mode, you can see public queues, but not messages, queue properties, private queues, system queues, and triggers.

Solution: In Active Directory Sites and Services, on the View menu, click Show Services Node. Message Queuing objects are under the Servers object and under the Services object.

So that these views are always enabled by default, you can save these changes by creating your own .msc file for these snap-ins. In such a case, the first time you open a .msc file that you previously created, on the File menu, click Options, and then select one of the three user mode entries in Console mode. Now the console will subsequently open in a user mode with the correct views enabled. Opening a snap-in console in one of the user modes (rather than in author mode) is safer from an administrative standpoint, because no one else can potentially change the behavior or the look of the console.

You cannot access any objects for Message Queuing in Active Directory.

Cause: The Message Queuing service may have been changed to run under a specific user account. To provide access to objects in Active Directory for earlier Windows MSMQ clients, this service must run under the Local System account on Windows Server 2003 or Windows 2000 domain controllers.

Solution: Verify that the Message Queuing service is running under the Local System account on the applicable Message Queuing server.

You are unable to establish a connection with Active Directory.

Cause: The Message Queuing server with which you are communicating may be offline, or the Message Queuing service may be stopped.

Solution: Verify that the Message Queuing server with which you are communicating is online and that the Message Queuing service is running.

Cause: Your computer may be offline, your network adapter may be malfunctioning, or your computer may not have an IP address assigned (or may have an IP address of 0.0.0.0.).

Solution: Verify that your computer is online, your network adapter is functioning properly, and TCP/IP is properly configured.

Cause: The DNS server is offline, is not configured properly, or the Message Queuing server's IP address has recently changed and has not been replicated yet to the DNS server.

Solution: Verify that the DNS server is online and properly configured.

Cause: The site that you are in does not contain a Message Queuing server running on a Windows Server 2003 or Windows 2000 domain controller that is configured as a global catalog server. This affects MSMQ 1.0 users running Windows NT 4.0 and all users running under a local user account.

Solution: Verify the Message Queuing server you communicate with is properly configured.

Cause: You may have insufficient permissions to access Active Directory.

Solution: Grant yourself the proper permissions to perform this operation.

Changes you made do not show up in Active Directory.

Cause: Replication can delay information updates displayed in the snap-ins, so that changes you make using the snap-ins do not appear until after replication takes place.

Solution: Press F5 after making the change, or wait at least 15 minutes.

Windows NT 4.0 clients and local users cannot access Active Directory.

Cause: Weakened security was not selected during an installation of Message Queuing with Downlevel Client Support on a Windows Server 2003 domain controller or an installation of a Message Queuing server on a Windows 2000 domain controller in your forest. To effectively support MSMQ 1.0 clients running Windows NT 4.0 and users running under a local user account, security for Active Directory must be weakened. (Dependent clients cannot run under a local user account. Any computer that sends queries about Message Queuing objects to Active Directory on a domain controller directly, rather than through the Message Queuing directory service (Downlevel Client Support), will not be able to access Active Directory when it logs on with a local user account, even if the security for Active Directory is weakened.)

Solution: Use the ADSI Editor provided with the Windows Server 2003 family Resource Kit to weaken security.

You cannot access the contents of a particular queue.

Cause: You may not have the proper permissions for viewing the queue. Message Queuing displays all queues that are viewable by default. However, you can view the contents of only those queues that you have proper permissions to open. Therefore, there may be public queues whose contents are not viewable in the snap-ins.

Solution: Ensure that the Peek Message or Receive Message permissions for the queue are granted to you. To view the contents of a queue journal, you must have the Peek Journal permission granted for the queue.

See also: Managing queues

You cannot create queues.

Cause: You may have insufficient permissions to perform this operation.

Solution: Grant yourself the proper permissions to perform this operation.

You cannot send messages to another site.

Cause: A routing link may not be defined between the two sites, or a designated site gate may be unavailable. As a result, messages can be sent by an application, but they cannot leave the outgoing queue.

Solution: Create a routing link between the two sites and define site gates for the routing link. It is recommended that you create multiple routing links between all sites for redundancy.

See also: Routing links

You cannot send or receive authenticated messages.

Cause: The user certificate for the computer may have been removed, expired, or not registered in Active Directory. The user certificate is required for sending authenticated messages. The user certificate is installed for you during Message Queuing Setup and is registered in Active Directory the first time you log on.

Solution: Use the Message Queuing Properties dialog box, which can be opened from Computer Management, to renew the certificate and then register it.

Cause: The Microsoft Base cryptographic service provider (CSP) provided with Windows Server 2003 family is not being used by Message Queuing applications. The Microsoft Base CSP is required for all Message Queuing applications that send or receive authenticated messages.

Solution: Verify that Message Queuing applications use the Microsoft Base (or Enhanced) CSP when sending or receiving messages.

Messages sent to a queue are rejected.

Cause: The queue may restrict access.

Solution: Make sure that the queue is located in the same domain as the computer that sent the message or is in a trusted domain.

Cause: The default permission is that everyone can send messages to a queue. However if this default setting is changed, the Message Queuing service on the receiving computer performs an access check to check the sender's SID (security ID) context against the SD (security descriptor) of the destination queue. If the access check is carried out and the sender has permissions to send to the queue, the message is accepted. If the access check is carried out and the sender does not have permissions, it is rejected. If the access check itself cannot be carried out and fails, the message is also rejected.

Solution: Check that the permissions settings for the queue. If the default setting to allow everyone to send messages to a queue has been modified, check that the message sender has permissions to send to the queue. If the access check itself cannot be completed (this might be indicated in Event Viewer), ensure that Message Queuing has access to the TokenGroupsGlobalAndUniversal attribute of the sender's user object. To provide this access, add the Message Queuing service account to the Windows Authorization Access Group, which has access to this attribute. Note that only users with domain administration permissions can add members to this group. You can add the Message Queuing service account to the group in one of two ways. You can manually add the relevant accounts to the Windows Authorization Access Group, repeating the operation for each Message Queuing computer requiring this permission. Alternatively, as a less secure practice, you can add the Authenticated Users group to the Windows Authorization Access Group. This grants every authenticated user, including the Message Queuing service on any computer, access to the TokenGroupsGlobalAndUniversal attribute for all users, and requires no further manual administration.

You cannot retrieve messages from a queue.

Cause: To retrieve messages from a queue, you must be granted the Receive Messages permission for the queue. It is not sufficient to have the Read permission granted for the queue.

Solution: Grant yourself the Receive Messages permission for the queue.

See also: Managing messages

Messages can no longer be delivered to a particular computer or queue.

Cause: The computer quota or the queue quota for the particular computer may have been exceeded.

You can verify this in the following two ways:

By requesting negative acknowledgment messages and checking their class. (This technique is applicable to the quotas of destination queues, not to computer quotas.)
By using performance counters to compare the queue or computer quota to the actual volume of messages.

Solution: Process and remove messages from the applicable queues or increase the appropriate quota value.

See also: Setting message quotas

Express messages are missing or lost.

Cause: Undelivered express messages are lost whenever the Message Queuing service is stopped on the computer where they reside in volatile memory, or the computer shuts down or fails.

Solution: Use recoverable or transactional messages. (Note that only transactional messages provide a complete guarantee against data loss.)

Transactional messaging does not function for dependent clients.

Cause: MSMQ 1.0 dependent clients running Windows NT 4.0 whose supporting server is running Windows Server 2003 family or Windows 2000 may not have Windows NT 4.0 Service Pack 4 (SP4) installed. SP4 or later is required for transactional messaging.

Solution: Install Windows NT 4.0 SP4 or later on the applicable dependent clients.

Cause: The Microsoft Distributed Transaction Coordinator (DTC) may not be running. The DTC is required for external transactions.

Solution: Start the DTC.

A test message cannot be sent to a particular queue.

Cause: Test messages can be sent from the MMC snap-in only to test queues, which have a queue type ID of {55EE8F33-CCE9-11CF-B108-0020AFD61CE9}.

Solution: Verify that the queue to which you want to send the test message has the correct queue type ID. Do not change a transactional queue or a queue requiring authentication to a test queue, because any test messages sent will not be delivered to such a queue. Note that you can send test messages programmatically to queues with any queue type ID.

See also: Sending test messages

You cannot access messaging files stored locally on disk.

Cause: By default, only members of the Administrators group for the local computer have full access to all locally stored message files, log files, and local queue storage (LQS) files.

Solution: Grant yourself administrative permissions for the computer, or add yourself to the local Administrators group.

You cannot locate the audit messages for a particular operation.

Cause: Audit messages are stored in the security log on the Message Queuing server that performs the operation, which may not be the server that owns the object. In addition, audit messages are created in the security log only when a queue is opened, not each time a message is received or sent.

Solution: Use Event Viewer to view information in the security log of the appropriate computer.

See also: Auditing Message Queuing objects

There are problems communicating with IPX computers.

Cause: The Message Queuing service no longer supports the IPX protocol.

Solution: Add the IP protocol to any computers that use only the IPX protocol.

Dependent clients cannot run Message Queuing applications.

Cause: You may be logged on using a local user account or other unauthenticated account. Message Queuing applications cannot run under unauthenticated accounts.

Solution: Log on using a domain user account, which is authenticated.

Resources for Message Queuing have timed out in a server cluster.

Cause: Cluster resources have a default time-out setting of three minutes for coming online. Message Queuing may take longer than three minutes, depending on recovery scenarios and the number of messages stored.

Solution: Increase the default time-out setting for Message Queuing resources.

A foreign site to which a Windows Server 2003 Message Queuing server with a connector application belongs does not appear in the list of sites for that server.

Cause: Adding a foreign site to the list of sites to which the Windows Server 2003 Message Queuing server with a connector application belongs does not ensure that the foreign site appears in the server's site list.

Solution: For a Windows Server 2003 Message Queuing server running connector applications, after adding the foreign site to the list of sites for the server, restart the Message Queuing service on the domain controller of the domain to which the Message Queuing server running the connector application belongs.

You cannot register a user certificate for Message Queuing.

Cause: By default, users have permission to register certificates for Message Queuing. However, if default user permissions are changed, this might affect your ability to register certificates.

Solution: Check that the user object is granted Write Personal Information permissions in the Active Directory schema.

Cause: Active Directory sets a multi-valued attribute limit of approximately 800 user certificates for a specific user account. This limit is usually exceeded when obsolete user certificates have not been deleted from Active Directory. If multiple certificates exist for a user account, only the latest is used.

Solution: Manually delete obsolete user certificates. For instructions, see Remove certificates for Message Queuing.

Troubleshooting administration problems