Message Queuing

Message Queuing (also known as MSMQ) is a messaging infrastructure and a development tool for creating distributed messaging applications for Microsoft® Windows® operating systems.

Message Queuing is of interest to both system administrators (for installing and managing the infrastructure) and software developers (for creating messaging applications). This documentation is written for system administrators and discusses management of the infrastructure provided by Message Queuing. This documentation does not discuss application development.

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed on it. The term Message Queuing client can refer to either an independent client or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed. Such computers are referred to as having independent client functionality or dependent client functionality. The following links provide detailed information:

  • Before installing or upgrading Message Queuing, see Checklists.
  • To find features that have been moved in Windows Server 2003 family operating systems, see New ways to do familiar tasks.
  • For instructions on specific administration tasks, see How to....
  • To learn more about Message Queuing features, planning, installing, and upgrading Message Queuing, and background information to help you understand Message Queuing, see Concepts.
  • For troubleshooting help and links to other Message Queuing resources, see Troubleshooting and Additional Resources.

© 1997-2003 Microsoft Corporation.
All rights reserved.


Checklists

This section provides checklists for installing Message Queuing client and server software on new computers. For details, see the following links:

  • Checklist: Installation for Message Queuing clients
  • Checklist: Installation for Message Queuing servers


Checklist: Installation for Message Queuing clients

Use this checklist when installing Message Queuing clients on Windows Server 2003 family computers that do not have previous versions of Message Queuing installed. Message Queuing is not installed by default during Windows Server 2003 family operating system setup.

Step | Reference
Review key concepts and determine the client functionality needed. | Message Queuing features
Review the installation requirements. | Installation overview
Review the problems that may arise during installation and their solutions. | Troubleshooting installation problems
Log on with local administrative permissions (as a member of the local Administrators group). For best security practice, log off as administrator after installation is complete. | Installation permissions
For a dependent client, verify that a Message Queuing computer with at least independent client functionality is available, preferably in the same site in which you are installing. Any such computer operating in domain mode can serve as a supporting server. Following installation, Message Queuing computers are not configured to support dependent clients, and this feature must be enabled. Note that a computer in workgroup mode cannot act as a supporting server for a dependent client. | Enable a supporting server; Installing dependent clients
Run the Windows Components Wizard and select the subcomponents that provide the applicable client functionality. | Install independent clients; Install dependent clients
Verify that the Message Queuing service has started. | Start or stop services for Message Queuing
Send a test message. Note that this feature must be enabled following Message Queuing installation. | Enable route tracking and test messages; Send test messages

Notes

  • New Message Queuing 3.0 features, such as HTTP transport, Message Queuing Triggers, and sending messages to multiple destinations, are not available to dependent clients. Thus, distribution lists, multiple-element format names, and multicast messaging are not supported for dependent clients.
  • Dependent clients will no longer be supported in future versions of Message Queuing.


Checklist: Installation for Message Queuing servers

Use this checklist when installing Message Queuing servers on computers running on Windows Server 2003 family computers that do not have previous versions of Message Queuing installed. Message Queuing is not installed by default during Windows Server 2003 family operating system setup.

Step | Reference
Review key concepts and determine the server functionality needed. | Message Queuing features
Review installation requirements. | Installation overview
Review the problems that may arise during installation and their solutions. | Troubleshooting installation problems
Log on with the appropriate administrative permissions. | Installation permissions
Before installing a Message Queuing server on a computer in a particular site, verify that there is at least one available domain controller in that site or in a nearby site. | Installation overview
For each Windows Server 2003 or Windows 2000 domain controller, verify that the computer is trusted for delegation. | Make a domain controller trusted for delegation
To reduce replication traffic, consider configuring at least one computer from the Windows Server 2003 or Windows 2000 domain controller in each site as a global catalog server. | Configure a domain controller as a global catalog server
If this server will be installed in domain mode and act as a supporting server for dependent clients, enable this feature. | Enable a supporting server
If this server will support Windows 2000 Message Queuing clients in the same site, verify that there is a domain controller running the Message Queuing directory service (Downlevel Client Support) or Message Queuing 2.0 in the site, or promote this computer to a domain controller and select the Downlevel Client Support subcomponent during installation. | Installing Message Queuing servers
If this server will support MSMQ 1.0 clients in the same site, verify that there is a domain controller running the Message Queuing directory service (Downlevel Client Support) or Message Queuing 2.0 and configured as a global catalog server from the domain of each such client in the site. Or, if applicable, promote this computer to a domain controller, configure it as a global catalog server, and select the Downlevel Client Support subcomponent during installation. | Installing Message Queuing servers
Run the Windows Components Wizard and select the subcomponents that provide the services needed. | Install Message Queuing servers
When prompted during the first or a subsequent installation of a Message Queuing server with Downlevel Client Support on a domain controller in your organization, weaken security if you want to support MSMQ 1.0 clients or clients logged on with local user accounts. For best security practice, only weaken security if necessary. | Enabling weakened security
If this server will be deployed for Internet messaging, configure HTTPS authentication. | HTTPS authentication
Verify that the Message Queuing service has started. | Start or stop services for Message Queuing
If this server has been enabled for routing, create a routing link for this computer to serve as a site gate to route messages to another site. | Create routing links
Send a test message. Note that this feature must be enabled following Message Queuing installation. | Enable route tracking and test messages; Send test messages


New ways to do familiar tasks

These tables compare different user interfaces used for common tasks in Message Queuing in:

  • Windows Server 2003 family operating systems and Windows NT 4.0.
  • Windows Server 2003 family operating systems and Windows 2000.

For a table that lists terminology and architectural differences between previous versions and the current version of Message Queuing, see Upgrade overview.

Windows Server 2003 family operating systems and Windows NT 4.0

If you want to | In Windows NT 4.0 use | In Windows Server 2003 family
Set access control, set access auditing, or change ownership for Message Queuing | MSMQ Explorer | Open Active Directory Users and Computers. For more information, see Security overview.
Change the Message Queuing service account | Services in Control Panel | Open Computer Management. For more information, see Change the Message Queuing service account.
Configure routing links | MSMQ Explorer | Open Active Directory Sites and Services. For more information, see Routing links.
For cross-platform messaging, create foreign sites or add foreign computers | MSMQ Explorer | Open Active Directory Sites and Services. For more information, see Foreign computers and sites.
Configure Message Queuing computers and properties, or set computer quotas or properties | MSMQ Explorer | Open Active Directory Users and Computers. For more information, see Administration overview.
Set DNS properties for Message Queuing computers | Network in Control Panel | Open Network Connections in Control Panel. For more information, see Set DNS properties for Message Queuing.
Create, delete, or configure queues, or set queue quotas or properties | MSMQ Explorer | Open Computer Management or open Active Directory Users and Computers. For more information, see Administering Queues.
View or delete messages, or view message properties | MSMQ Explorer | Open Computer Management or open Active Directory Users and Computers. For more information, see Managing messages.

Windows Server 2003 family operating systems and Windows 2000

If you want to | In Windows 2000 use | In Windows Server 2003 family
Specify a new site for mobile computers. | Message Queuing in Control Panel | Open Computer Management. For more information, see Specify a new site for mobile computers.
Change the supporting server for a dependent client. Note that Message Queuing computers are not enabled by default to support dependent clients. | Message Queuing in Control Panel | Open Computer Management. For more information, see Enable a supporting server and Change the supporting server for a dependent client.
Specify the drives and folders for storing message files, message logs, and transaction logs. | Message Queuing in Control Panel | Open Computer Management. For more information, see Store messages on multiple disk drives.
Change, register, view, and remove certificates. | Message Queuing in Control Panel | Open Computer Management. For more information, see Authentication for Message Queuing.
To renew cryptographic keys for Message Queuing. | Message Queuing in Control Panel | Open Computer Management. For more information, see Renew cryptographic keys for Message Queuing.

Notes

  • Message Queuing 3.0 does not support a mixed-mode domain environment. That is, an environment where MSMQ 1.0 controller servers running on a Windows NT 4.0 computer exist in a Windows Server 2003 domain, together with Windows Server 2003 domain controllers. After you upgrade Windows NT 4.0 controller servers to the Windows Server 2003 family operating system, and follow the Message Queuing upgrade procedures, the result is a Windows Server 2003 domain environment, with no MQIS servers remaining, and no replication service.
  • Until this process is completed, and as long as the domain environment is in mixed-mode, Message Queuing directory service functionality (Downlevel Client Support component) cannot be added to Windows Server 2003 domain controllers. In Message Queuing 3.0, directory service functionality is only required to provide directory services for Message Queuing objects to Message Queuing client computers running MSMQ 1.0 and 2.0. Message Queuing 3.0 servers and independent clients running on Windows Server 2003 family computers can access Active Directory directly.
  • The Message Queuing directory service is not installed by default. To install it, you must select the Downlevel Client Support check box during Message Queuing 3.0 installation. You cannot add this functionality in a mixed-mode environment.
  • A mixed-mode Windows 2000 domain environment comprised of MSMQ 1.0 controller servers and Windows 2000 domain controllers can still exist. In such an environment, Windows Server 2003 domain controllers can exist, but the Downlevel Client Support component cannot be installed on them.
  • MSMQ Explorer does not run on Windows Server 2003 family or Windows 2000 computers.
  • There are no tools that allow you to manage an MSMQ 1.0 enterprise from a Windows Server 2003 family or Windows 2000 computer.


How to...

This section provides instructions on completing Message Queuing administration tasks:

  • For information on how to install and uninstall Message Queuing, configure independent and dependent clients, and configure Message Queuing in clusters, see Install Message Queuing.
  • For instructions on managing routing links, and site gates, see Administer a Message Queuing Network.
  • For information on Message Queuing in Active Directory, see Administer Message Queuing in Active Directory.
  • For information on administering tasks on Message Queuing computers, see Administer Message Queuing Computers.
  • To learn about security tasks, including managing Message Queuing object security, authentication, and encryption, see Administer Security for Message Queuing.
  • For instructions on managing and configuring queues and queue aliases, see Administer Queues for Message Queuing.
  • For information on distribution list tasks, see Administer Distribution Lists for Message Queuing.
  • To learn about message properties, including setting default message lifetime, and purging messages, see Administer Messages for Message Queuing.
  • For information on creating and managing triggers and rules, modifying default trigger values, and configuring Message Queuing trigger resources for clusters, see Administer Triggers for Message Queuing.
  • For instructions on viewing Message Queuing events, external transactions, and performance counters, and to learn to enable message route tracking and test messages, see Monitor and Test Message Queuing.


Install Message Queuing

This section shows you how to:

  • Configure a domain controller as a global catalog server
  • Make a domain controller trusted for delegation
  • Set installation permissions to enable upgrade from MSMQ 1.0
  • Install Message Queuing servers
  • Install independent clients
  • Enable network DTC access
  • Enable a supporting server
  • Install dependent clients
  • Configure Message Queuing resources for server clusters
  • Configure Message Queuing with HTTP for server clusters
  • Uninstall Message Queuing


Configure a domain controller as a global catalog server

Microsoft Windows Graphic

To configure a domain controller as a global catalog server

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click NTDS Settings.

    Where?

    • Active Directory Sites and Services
    • Sites
    • YourApplicableSite
    • Servers
    • YourApplicableServer
    • NTDS Settings
  3. Click Properties.
  4. On the General page, select the global catalog check box.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • Each Windows Server 2003 family site or Windows 2000 site containing MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers must contain at least one Windows Server 2003 domain controller that is running the Message Queuing directory service (Downlevel Client Support) and is configured as a global catalog server or at least one Windows 2000 domain controller that is running a Message Queuing server and is configured as a global catalog server from the domain of each such client. This is required to enable such clients to send queries programmatically to Message Queuing servers.
  • When a Windows NT 4.0 primary enterprise controller (PEC) is migrated, it is automatically promoted to a domain controller configured as a global catalog server.
  • The first domain controller in a Windows Server 2003 family forest is automatically configured as a global catalog server.

Related Topics


Make a domain controller trusted for delegation

Microsoft Windows Graphic

To make a domain controller trusted for delegation

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click the applicable domain controller.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • Domain Controllers
    • YourDomainController
  4. Click Properties.
  5. On the General page, select the Trust computer for delegation check box (if needed).

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • If this property is disabled for a domain controller, the Message Queuing service cannot run.

Related Topics


Set installation permissions to enable upgrade from MSMQ 1.0

Microsoft Windows Graphic

To set installation permissions to enable upgrade from MSMQ 1.0

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Computers (or applicable organizational unit).

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • Computers (or applicable organizational unit)
  3. Click Delegate control to start the Delegation of Control Wizard, and then click Next.
  4. On the Users or Groups page, click Add.
  5. In the Select Users, Computers, or Groups dialog box, ensure that Users, Groups, or Build-in Security Principals appears in Select this object type. If it does not, click Object Types, and select these objects, clearing any other check boxes that are selected. Then click OK.
  6. In Enter the object name to select, do the following:
    • To allow authenticated users permission to install Message Queuing, under Name, type Authenticated Users, and then click OK.
    • To allow everyone permission to install Message Queuing, under Name, type Everyone, and then click OK.
  7. On the Users or Groups page, click Next.
  8. Select Create a custom task to delegate, and then click Next.
  9. On the Active Directory Object Type page, click Only the following objects in the folder, select the Computer objects check box, and then click Next.
  10. On the Permissions page, under Show these permissions, clear the General check box, and then select the Creation/deletion of specific child objects check box.
  11. Under Permissions, ensure that the Create MSMQ Configuration objects check box and the Delete MSMQ Configuration objects check box are selected, and that the other check boxes are cleared. Click Next, and then click Finish.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Use the Delegation of Control Wizard to grant the proper permissions to users that want to install MSMQ 1.0 on a computer that is part of a domain that runs Windows Server 2003 family or Windows 2000.
  • On the Security page of the Properties dialog box, the check boxes for permissions granted using the Delegation of Control Wizard or using inherited permissions are dimmed.
  • The Delete MSMQ Configuration Objects permission is required to uninstall Message Queuing.
  • When Message Queuing is installed on computers running Windows 95, Windows 98, and some versions of Windows NT 4.0 (without QFE) or Windows 2000 (prior to Service Pack 4), or when these computers join a Windows Server 2003 domain, they require a given GUID when creating MSMQ configuration objects. By default a Windows Server 2003 forest does not support the addition of objects with a given GUID. To overcome this problem, it is recommended that you upgrade the client computer to an operating system that does not require creating an object with a given GUID. These include Windows NT 4.0 (with QFE), and Windows 2000 (with Service Pack 4). For instructions on downloading the QFE, see Knowledge Base article KB324338.

Related Topics


Install Message Queuing servers

Microsoft Windows Graphic

To install Message Queuing servers

  1. Open Add or Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components Wizard, select the Application Server check box, click Details, select the Message Queuing check box, and then click Details.
  4. On the Message Queuing page, you can select the following subcomponents for your Message Queuing server:
    • To provide message routing services, select the Routing Support check box.
    • To install the Message Queuing directory service, which provides access to Message Queuing objects in Active Directory for MSMQ 1.0 clients running on Windows 98, Windows 95, Windows Millennium Edition and Windows NT 4.0 computers, and for MSMQ 2.0 clients running on Windows 2000 computers, select the Downlevel Client Support check box.
    • If the computer belongs to a domain and you want it to operate in workgroup mode, clear the Active Directory Integration check box. In this case, you cannot install Routing Support.
    • If you want to install Message Queuing Triggers, select the Triggers check box.
    • If you intend to send messages by HTTP transport, select the MSMQ HTTP Support check box.
  5. Click OK, and then click Next.
  6. If prompted, type the DNS or NetBIOS name of an MSMQ 1.0 PEC or PSC (in a Windows NT 4.0 enterprise) in the local site, and then click Next.
  7. Follow the remaining instructions in the wizard.

Notes

  • To open Add or Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.
  • Message Queuing 3.0 servers can be installed only on computers running on platforms from the Windows Server 2003 family.
  • Only Message Queuing 3.0 clients, not servers, can be installed in a Windows NT 4.0 enterprise.
  • During setup, an attempt is made to automatically detect the nearest Windows Server 2003 or Windows 2000 domain controller in the local site or in a nearby site. If a suitable domain controller cannot be found, Setup assumes that you are installing a Message Queuing client in a Windows NT 4.0 environment and prompts you for the name of a controller server (PEC or PSC) before Setup can continue.
  • The following subcomponents are selected by default for 32-bit servers: Active Directory Integration and Common (consisting of Core functionality and Local Storage).
  • In a Windows Server 2003 site, to provide access to Message Queuing objects in Active Directory for Message Queuing 1.0 clients on Windows 95, Windows 98, Windows Millennium Edition, Windows NT 4.0 computers, or Message Queuing 2.0 clients running on Windows 2000 computers, you must install a Message Queuing server with the Downlevel Client Support check box selected on a Windows Server 2003 domain controller in that site, or you must install a Message Queuing server on a Windows 2000 domain controller in that site. For MSMQ 1.0 clients, you must also configure the applicable domain controller as a global catalog server, and each MSMQ 1.0 client must have such a domain controller from its own domain in the site.
  • Although the Downlevel Client Support component can be installed on all Message Queuing servers, it is relevant only for domain controllers. If it is installed on a computer that is not a domain controller, it only becomes active if the server is converted to a domain controller.
  • You can install a Message Queuing server without Routing Support in workgroup mode if the computer is part of a Windows Server 2003 family workgroup. In this case, only private queues can be accessed and direct connectivity is required to send messages. For more information, see Related Topics.
  • If you are installing a Message Queuing server with Downlevel Client Support on a domain controller and security has not been weakened in your organization to support MSMQ 1.0 clients or clients logged on with local user accounts, you will be prompted during installation about whether or not to weaken security. Weaken security only if you want to support such clients.
  • Do not attempt to use Message Queuing 3.0 files to create a Message Queuing server on a computer that does not belong to the Windows Server 2003 family.

Related Topics


Install independent clients

Microsoft Windows Graphic

To install independent clients

  1. Open Add or Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components Wizard, select the Application Server check box, click Details, select the Message Queuing check box, and then click Details.
  4. On the Message Queuing page, you can select the following subcomponents for the independent client computer:
    • If the computer belongs to a domain and you want it to operate in workgroup mode, clear the Active Directory Integration check box. In this case, you cannot install Routing Support.
    • If you want to install Message Queuing Triggers, select the Triggers check box.
    • If you intend to send messages by HTTP transport, select the MSMQ HTTP Support check box.
  5. Click Next.
  6. Follow the remaining instructions in the wizard.
  7. If prompted to restart your computer, click Yes to allow Setup to complete.

Notes

  • To open Add or Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.
  • The following subcomponents are selected by default for 32-bit servers: Active Directory Integration and Common (consisting of Core functionality and Local Storage).
  • If a domain controller cannot be found automatically in the local site or in a nearby site, the installation will continue, and Message Queuing will be installed in workgroup mode. In the context of Message Queuing, any mode of operation that does not allow access to a directory service is called workgroup mode, even if the applicable computer belongs to a domain.
  • You can also install an independent client in workgroup mode if the computer is part of a Windows Server 2003 family workgroup. In this case, direct connectivity is required to send messages. For more information, see Related Topics.
  • Do not attempt to use Message Queuing 3.0 files to create an independent client on a computer that does not belong to the Windows Server 2003 family.

Related Topics


Enable network DTC access

Microsoft Windows Graphic

To enable network DTC access

  1. Open Add or Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components Wizard, select the Application Server check box, and then click Details.
  4. Select Enable network DTC access, and then click OK.

Notes

  • To open Add or Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.

Related Topics


Enable a supporting server

Microsoft Windows Graphic

To enable a supporting server

  1. Open Computer Management.
  2. In the console tree, click Services and Applications.

    Where?

    • Computer Management
    • Services and Applications
  3. In the details pane, right-click Message Queuing, and then click Properties.
  4. On the Server Security tab, clear the selection Disable dependent client support to prevent this computer acting as a supporting server for dependent clients, and then click OK.

Important

  • Before enabling a supporting server, you must enable network access for Microsoft Distributed Transaction Coordinator (DTC). For instructions, see Enable network DTC access.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • For best security practice, only turn on this feature if it is required.
  • Following installation, dependent client support is disabled by default for Message Queuing computers.
  • To reset server security settings on this tab to the default settings following installation, click Restore Defaults.
  • Dependent clients cannot be installed on computers in workgroup mode or on 64-bit computers.
  • New Windows Server 2003 family Message Queuing features, such as HTTP transport, Message Queuing Triggers, and sending messages to multiple destinations, are not available to dependent clients. Thus, distribution lists, multiple-element format names, and multicast messaging are not supported for dependent clients.
  • Dependent clients will no longer be supported in future versions of Message Queuing.

Related Topics


Install dependent clients

Microsoft Windows Graphic

To install dependent clients

  1. Open Add or Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components Wizard, select the Application Server check box, click Details, select the Message Queuing check box, and then click Details.
  4. On the Message Queuing page, clear the Active Directory Integration, Triggers, and MSMQ HTTP Support check boxes, select the Common check box, and then click Details.
  5. Clear the Local Storage check box, click OK, click OK, and then click Next.
  6. If prompted, type the DNS or NetBIOS name of a supporting server in the local site. If the specified supporting server cannot be found:
    • Click Yes to complete setup. Note that the dependent client cannot send or receive messages until a connection with a Message Queuing server is established.
    • Click No to specify a different Message Queuing server.

Notes

  • To open Add or Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.
  • The following subcomponents are selected by default for 32-bit servers: Active Directory Integration and Common (consisting of Core functionality and Local Storage).
  • By default, following installation, Message Queuing servers are not enabled to support dependent clients. For instructions on enabling a Message Queuing computer to act as a supporting server, see Enable a supporting server.
  • Any Message Queuing server operating in domain mode with at least independent client functionality can serve as the supporting server for a dependent client. Setup automatically attempts to locate such a Message Queuing server in the same site or in a nearby site. If one cannot be located, Setup prompts you for the name of such a server. If the server specified is not available, Setup displays a message stating that the server is not reachable. You can choose to complete setup without a specified server, allowing you to install a dependent client before you install its supporting Message Queuing server. For best security practice, do not configure servers as supporting servers unless this functionality is required.
  • Dependent clients cannot be installed on computers in workgroup mode or on 64-bit computers.
  • New Windows Server 2003 family Message Queuing features, such as HTTP transport, Message Queuing Triggers, and sending messages to multiple destinations, are not available to dependent clients. Thus, distribution lists, multiple-element format names, and multicast messaging are not supported for dependent clients.
  • Dependent clients will no longer be supported in future versions of Message Queuing.

Related Topics


Configure Message Queuing resources for server clusters

Microsoft Windows Graphic

To configure Message Queuing resources for server clusters

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.
  2. To create a Message Queuing resource:
    • When the Open Connection to Cluster dialog box appears, in the Cluster or server name list box, select the applicable cluster or server. If you select a server, the name of the cluster to which it belongs will appear in the console tree.
    • In the console tree, right-click the cluster group to which you want the Message Queuing resource to belong.

      Where?

      • ClusterName
      • Groups
      • YourGroup
    • On the File menu, point to New, and then click Resource.
    • In the New Resource Wizard, type the applicable information in Name and Description, select Message Queuing in the Resource type list box, and then click Next.
    • On the Possible Owners page, if you want to add nodes to the automatically chosen list under Possible owners, select them from the list under Available nodes, and then click Add. If you want to remove nodes from the automatically chosen list under Possible owners, select them in this list, click Remove, and then click Next.
    • On the Dependencies page, under Available resources, select the name of the Network Name resource in the group and click Add, and then select the name of the Physical Disk resource in the group and click Add. Then click Finish.
  3. If Message Queuing has the Active Directory Integration component installed, enable Kerberos authentication for the Network Name resource on which the Message Queuing resources depends. This is not enabled by default. To enable, do the following:
    • To bring the Network Name resource offline, in the console tree for the cluster group, right-click the Network Name resource selected as a dependency in the details pane, and then click Take Offline.
    • Right-click the Network Name resource again, and then click Properties.
    • On the Parameters tab, select the Enable Kerberos Authentication check box, to enable authentication.
    • To bring the Network Name resource online, in the console tree for the cluster group, right-click the Network Name resources in the details pane, and then click Bring Online.

    Caution

    • Other resources in the group may also depend on the Network Name resource. These will be taken offline automatically when the Network Name resource goes offline. When you bring the Network Name resource online, bring these other resources online too.
  4. To bring the Message Queuing resource online, in the console tree, click the Resources folder. In the details pane, click the Message Queuing resource. On the File menu, click Bring Online.
  5. To manage the Message Queuing resource from Computer Management, create a Generic Application resource in the same cluster group and configure it to launch the Computer Management MMC snap-in:
    • In the Cluster Administrator console tree, click the cluster group to which the Message Queuing resource belongs.
    • On the File menu, point to New, and then click Resource. The New Resource Wizard launches.
    • In the New Resource Wizard, type Computer Management in the Name text box and select Generic Application in the Resource type list box. Then click Next.
    • On the Possible Owners page, select possible owners to match those selected for the Message Queuing resource. Then click Next.
    • On the Dependencies page, under Available resources, select the name of the Network Name resource in the group and click Add, and then select the Message Queuing resource previously created and click Add. Then click Next.
    • On the Generic Application Parameters page, in Command line, type mmc compmgmt.msc.
    • In Current directory, type %windir%/system32.
    • Select the Allow application to interact with desktop check box, select the Use Network Name for computer name check box, click Next, and then click Finish.
    • Bring the resource online using the procedure above. The Computer Management snap-in will appear on the desktop of the computer node that owns the resource.

Notes

  • This task is performed on a computer that is running XOX or XOX as part of a server cluster, and has the Message Queuing service already installed.
  • If you want to use triggers, HTTP messaging, or external transactions in your cluster, before creating a Message Queuing resource in any cluster group hosted on a node of a server cluster, you must configure a Microsoft Distributed Transaction Coordinator (DTC) resource in the cluster. For instructions on creating a cluster, see Create a cluster, in Server Clusters Help.
  • Errors occurring during the performance of this task are recorded in a Windows event log. For example, a "device not ready" error indicates that Message Queuing was not installed on the node.
  • All Message Queuing applications that run in the context of a cluster group (whether cluster-aware or not) must depend on the Message Queuing resource in that group, and use the Network Name resource in that group. Repeat the steps stated above for the Computer Management MMC snap-in to properly configure Generic Application resources for "cluster-unaware" applications.
  • Once created, do not rename resources for Message Queuing.
  • If the virtual Message Queuing service managed by the Network Name resource will access Active Directory, you must enable Kerberos authentication on the Network Name resource on which the Message Queuing resource depends. Note that this feature is not enabled by default.
  • You can also enable Kerberos authentication from the command line by typing the following command cluster res "Network_Name_resource_name" /priv RequireKerberos=1:DWORD
  • When you select the Physical Disk resource in the group, Message Queuing allocates its storage in the MSMQ\STORAGE folder on the shared disk. After storage has been allocated, you cannot modify the folder location.
  • To uninstall Message Queuing on a computer that is part of a server cluster, the Message Queuing virtual server must be deleted from the node before uninstalling Message Queuing on the physical node. For example, if Message Queuing is installed on NodeA of a server cluster, you need to identify all Message Queuing resources on this cluster, ensure that NodeA does not own any cluster groups containing Message Queuing resources, and remove NodeA from the list of possible owners of each Message Queuing resource. Then you uninstall Message Queuing from NodeA.

Related Topics


Configure Message Queuing with HTTP for server clusters

Microsoft Windows Graphic

To configure Message Queuing with HTTP for server clusters

  1. Open Computer Management.
  2. In the console tree, click to expand Services and Applications.

    Where?

    • Computer Management
    • Services and Applications
  3. Click Internet Information Services (IIS) Manager, click to expand Web Sites, right-click Default Web Site, and then click Properties.
  4. To assign to the site all IP addresses that are not assigned to other sites, on the Web Site tab, in Web site identification, select Default Web Site, and in IP Address select All Unassigned.
  5. To assign the explicit IP address of the virtual server as the default Web site, on the Web Site tab, in Web Site Identification, click Advanced, and then in Advanced Multiple Web Site Configuration, click Add to add the IP address of the virtual server.

Notes

  • This task is performed on a computer that is running XOX or XOX as part of a server cluster, and has the Message Queuing service already installed.

Related Topics


Uninstall Message Queuing

Microsoft Windows Graphic

To uninstall Message Queuing

  1. Open Add or Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components Wizard, select the Application Server check box, click Details, clear the Message Queuing check box, and then click Next.
  4. When asked if you want to permanently delete the queues and messages created by Message Queuing, click Yes.

Notes

  • To open Add or Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.
  • When uninstalling Message Queuing in a multi-domain environment, wait for Active Directory replication to occur and check that the msmq object for the applicable computer was removed before attempting to reinstall Message Queuing on the same computer.
  • Uninstalling Message Queuing does not remove Message Queuing files from the \Windows\System32 and \Windows\System32\Drivers folders.
  • To uninstall Message Queuing on a computer that is part of a server cluster, the Message Queuing virtual server must be deleted from the node before uninstalling Message Queuing on the physical node.

Related Topics


Administer a Message Queuing Network

This section shows you how to:

  • Create routing links
  • Change the cost for a routing link
  • Change the site gates for a routing link
  • Administer Cross-Platform Messaging


Create routing links

Microsoft Windows Graphic

To create routing links

  1. Open Active Directory Sites and Services.
  2. On the View menu, click Show Services Node.
  3. In the console tree, right-click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. Point to New, and then click MSMQ Routing Link.
  5. On the New Object - Routing Link dialog box, in Site 1 and in Site 2, click the arrows that open the lists and select the two sites between which you want to route messages.
  6. In Routing Link Cost, enter a cost.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • A routing link defines the route for connectivity between two sites. For more information on routing links, how they are used to route messages, and routing-link costs, see Related Topics.
  • Costs can range from 1 to 999999.
  • By default, users in the Enterprise Admins group and Domain Admins group can create or modify routing links. For information on how to set permissions for routing links, see Related Topics.

Related Topics


Change the cost for a routing link

Microsoft Windows Graphic

To change the cost for a routing link

  1. Open Active Directory Sites and Services.
  2. On the View menu, click Show Services Node.
  3. In the console tree, click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. In the details pane, right-click the applicable routing link, and then click Properties.
  5. On the General page, in Routing Link Cost, specify a new cost.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • A routing link defines the route for connectivity between two sites. For more information on routing links, how they are used to route messages, and routing-link costs, see Related Topics.
  • All routing links are assigned a default cost of 1. Change routing-link costs only in the case where alternative routes are possible and you want to enforce one route over another route using link costs. In that case, you can assign costs that reflect the differences in the communications costs.
  • Costs can range from 1 to 999999.
  • By default, only users in the Enterprise Admins group can create or modify routing links if there are multiple domains in your organization. For users in the Domain Admins group to be able to create or modify routing links, they will need to be granted the Create All Child Objects permission for the MsmqServices object. For information on how to set permissions for routing links, see Related Topics.

Related Topics


Change the site gates for a routing link

Microsoft Windows Graphic

To change the site gates for a routing link

  1. Open Active Directory Sites and Services.
  2. On the View menu, click Show Services Node.
  3. In the console tree, click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. In the details pane, right-click the applicable routing link, and then click Properties.
  5. On the Site Gates page, do one of the following:
    • To add a Message Queuing routing server as a site gate to the routing link, in Available servers, select a server from the list, and then click Add.
    • To remove a Message Queuing routing server from the routing link, in Site gates, select the applicable server from the list, and then click Remove.
  6. Repeat step 5 as needed.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • A routing link defines the route for connectivity between two sites, and a site gate is a Message Queuing routing server or one of several such servers through which the message traffic between two sites is configured to pass. For more information on routing links, site gates, and how they are used to route messages, see Related Topics.
  • A site gate can belong to either or both of the sites connected by a routing link. A routing link can have any number of site gates or no site gate.
  • By default, only users in the Enterprise Admins group can create or modify routing links if there are multiple domains in your organization. For users in the Domain Admins group to be able to create or modify routing links, they will need to be granted the Create All Child Objects permission for the MsmqServices object. For information on how to set permissions for routing links, see Related Topics.

Related Topics


Administer Cross-Platform Messaging

This section shows you how to:

  • Create foreign sites
  • Add foreign computers to a site


Create foreign sites

Microsoft Windows Graphic

To create foreign sites

  1. Open Active Directory Sites and Services.
  2. On the View menu, click Show Services Node.
  3. In the console tree, right-click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. Click New Foreign Site.
  5. In the New Object – Foreign Site dialog box, type a name for the new site under Foreign site name.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • A routing link defines the route for connectivity between any two sites, including a foreign site and a non-foreign site. A site gate is a Message Queuing routing server or one of several such servers through which the message traffic between two sites is configured to pass. For more information, see Related Topics. To provide connectivity to a foreign site, you must perform the following task:
    1. Create a routing link between the foreign site and a Windows Server 2003 family or Windows 2000 Message Queuing (non-foreign) site that contains a Message Queuing server running a connector application. For more information, see Related Topics.
    2. Define this Message Queuing server as a site gate for the routing link. For more information, see Related Topics.
    3. Open Active Directory Users and Computers.
    4. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
    5. In the console tree, right-click the msmq object of the computer running the connector application.
    6. Click Properties.
    7. On the Sites page, select the foreign site under All sites, and then click Add to add this site to the list of sites where this server resides and to add it to the foreign site.
  • To delete a foreign site, in the Active Directory Sites and Services console tree, right-click the name of the foreign site under Sites, and then click Delete. Before deleting a foreign site, you may need to refresh the list of sites. To do this, right-click Sites, and then click Refresh.

Related Topics


Add foreign computers to a site

Microsoft Windows Graphic

To add foreign computers to a site

  1. Open Active Directory Sites and Services.
  2. On the View menu, click Show Services Node.
  3. In the console tree, right-click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. Click New Foreign Computer to open the New Object – Foreign Computer dialog box.
  5. In the Computer name text box, type the name of the foreign computer.
  6. In the Foreign site list box, select the name of the foreign site to which the computer will be added from the list of available foreign sites.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • This procedure creates two objects in Active Directory for the foreign computer. One is a computer object in the Computers container. This object is similar to an ordinary computer object. The other is an msmq (MSMQ Configuration) object, which is created under the computer object and contains a pointer to the foreign site in the MSMQ-Sites attribute.
  • You must create a foreign site before you can add a foreign computer to the site. For information on how to create a foreign site, see Related Topics.
  • Typing the name of a foreign computer in the New Foreign Computer dialog box does not guarantee that messages can be sent to it.
  • A routing link defines the route for connectivity between two sites. A site gate is a Message Queuing routing server or one of several such servers through which the message traffic between two sites is configured to pass. For more information on routing links, site gates, and how they are used to route messages, see Related Topics.
  • A Message Queuing routing server that is running a connector application and has been configured as a site gate for a routing link between its site and the foreign site must also be added to the foreign site. To do this, perform the following task:
    1. Open Active Directory Users and Computers.
    2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
    3. In the console tree, right-click msmq.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • Domain Controllers
      • ApplicableServer
      • msmq
    4. Click Properties.
    5. On the Sites page, select the foreign site under All sites, and then click Add to add this site to the list of sites where this server resides and to add it to the foreign site.
  • For Windows 2000 computers running a connector application, after adding the foreign site to the list of sites, the foreign site will not appear in the list until you restart the Message Queuing service on the domain controller of the domain to which the Message Queuing server running the connector application belongs.
  • Messages cannot be sent over HTTP transport to foreign computers.

Related Topics


Administer Message Queuing in Active Directory

This section shows you how to:

  • Remove Message Queuing objects from Active Directory


Remove Message Queuing objects from Active Directory

Microsoft Windows Graphic

To remove Message Queuing objects from Active Directory

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Delete. When prompted, click Yes.
  5. Open Active Directory Sites and Services.
  6. In the details pane, right-click Msmq Settings.

    Where?

    • Active Directory Sites and Services
    • Sites
    • YourSite
    • Servers
    • YourServer
    • MSMQ Settings
  7. Click Delete. When prompted, click Yes.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • It is best to remove Message Queuing objects from Active Directory by uninstalling Message Queuing software from the actual computer. It is recommended that you perform the procedure above only if you cannot uninstall Message Queuing software from a computer, such as during a hardware malfunction, if you no longer have physical access to the computer, or if Message Queuing Setup has failed. For information on how to uninstall Message Queuing software from a computer, see Related Topics.
  • When you remove Message Queuing objects from Active Directory, all queues and messages are also removed. However, actual Message Queuing software, including registry values and storage files, remains on the computer.
  • If you remove objects for an in-routing or out-routing server, the server is also removed from the routing lists of all clients using that server.
  • If you remove objects for a site gate, the server is also removed from the associated routing link.

Related Topics


Administer Message Queuing Computers

This section shows you how to:

  • Join a domain from a workgroup
  • Add sites to a Message Queuing server's list of sites
  • Remove sites from a Message Queuing server's list of sites
  • Specify a new site for mobile computers
  • Change in-routing or out-routing servers
  • Change the supporting server for a dependent client
  • View the dependent client list for a server
  • Set the message storage size for computers
  • Set the journal storage size for computers
  • Store messages on multiple disk drives
  • Set DNS properties for Message Queuing
  • Start or stop services for Message Queuing


Join a domain from a workgroup

Microsoft Windows Graphic

To join a domain from a workgroup

  1. Open System in Control Panel.
  2. On the Computer Name page, click Change.
  3. Under Member of, click Domain, type the domain name, and then click OK.
  4. When prompted, provide a valid user name and password.
  5. When prompted, restart your computer to apply the changes.

Caution

  • When you join a Message Queuing computer in workgroup mode to a domain, or move a Message Queuing computer to a different forest, all messages in outgoing transactional queues on the computer will be discarded, or placed in the dead-letter queue if negative source journaling is enabled.

Notes

  • To open System, click Start, point to Settings, and then click Control Panel.
  • Use this procedure if you are running Message Queuing in a workgroup environment and want to join (or rejoin) a domain. When you join a domain, the computer can access public queues listed in Active Directory.
  • For more information on this procedure, see Join a domain in the System online Help file.
  • To perform this procedure, the Active Directory Integration subcomponent must be selected during setup. If the Active Directory Integration subcomponent is not installed, Message Queuing can run only in workgroup mode.
  • You can use this procedure to join a workgroup from a domain. In that case, click Workgroup under Member of and type the name of the workgroup. You will be disjoined from the domain.
  • You can use this procedure to move a computer from one domain to another domain within your forest. In this case, if you leave the msmq (MSMQ Configuration) object in the old domain, the computer will continue to use the old object. Otherwise, it will create a new msmq object in the new domain.
  • After joining a domain from a workgroup or another domain, some time (as much as 20-30 minutes) is required for replication of the changes in Active Directory.
  • When a computer running Message Queuing in workgroup mode joins a Windows NT 4.0 domain, the installation subcomponent for Active Directory Integration is removed. After the computer has been joined to the domain and rebooted, open Add or Remove Programs in Control Panel, and add the Active Directory Integration subcomponent.

Related Topics


Add sites to a Message Queuing server's list of sites

Microsoft Windows Graphic

To add sites to a Message Queuing server's list of sites

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. Click the Sites tab, and in All Sites, select a site to add to the list of sites where the server resides, and then click Add.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • In most cases, Message Queuing automatically determines the sites in which servers reside. This procedure is needed to add sites manually to the list of sites where a server resides. The applicable servers are Message Queuing servers with routing enabled, which are also called routing servers. Any routing server that resides in a specific site can be configured as an in-routing or out-routing server for computers that reside in that site. Such routing servers can be configured as site gates in routing links to that site. A routing server can reside in multiple sites, and it can be configured as an in-routing server, an out-routing server, or a site gate, independently in each site in which it resides.

Related Topics


Remove sites from a Message Queuing server's list of sites

Microsoft Windows Graphic

To remove sites from a Message Queuing server's list of sites

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. Click the Sites tab, and in ComputerName Sites, select a site to remove from the list of sites where the server resides, and then click Remove.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • In most cases, Message Queuing automatically determines the sites in which servers reside. This procedure is needed to remove sites manually from the list of sites where a server resides. The applicable servers are Message Queuing servers with routing enabled, which are also called routing servers. Any routing server that resides in a specific site can be configured as an in-routing or out-routing server for computers that reside in that site. Such routing servers can be also configured as site gates in routing links to that site. A routing server can reside in multiple sites, and it can be configured as an in-routing server, an out-routing server, or a site gate, independently in each site in which it resides.

Related Topics


Specify a new site for mobile computers

Microsoft Windows Graphic

To specify a new site for mobile computers

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the Mobile tab, and in New site, click the arrow that opens the list and select the site to which the mobile computer will move.
  5. When prompted to restart Windows, click Restart Now.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.

Related Topics


Change in-routing or out-routing servers

Microsoft Windows Graphic

To change in-routing or out-routing servers

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. Click the Routing tab.
  6. To change an in-routing server used, under In-routing servers, click the arrow that opens the list. Select a new Message Queuing server or select none to remove a particular Message Queuing server used as an in-routing server.
  7. To change an out-routing server used, under Out-routing servers, click the arrow that opens the list. Select a new Message Queuing server or select none to remove the Message Queuing server used as an out-routing server.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • This task is applicable only to independent clients and Message Queuing servers without routing enabled that are installed on a nondomain controller, but can be performed from any computer with suitable permissions.
  • You can install a Message Queuing server with routing enabled on a domain controller, but it may impair performance.
  • When a client is moved to another site, these routing settings are disabled until the client returns to its original site.
  • Message Queuing servers used as in-routing or out-routing servers must be in the same site as the client. The same computer can be used as both the in-routing server and the out-routing server for a client.
  • If used, it is recommended that you assign more than one in-routing or out-routing server per client. This provides load balancing and failure recovery.

Related Topics


Change the supporting server for a dependent client

Microsoft Windows Graphic

To change the supporting server for a dependent client

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. On the Message Queuing Client page in the Message Queuing Properties dialog box, type the name of the supporting Message Queuing server.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • This task is performed from the dependent client.
  • Message Queuing 3.0 dependent clients cannot be installed with a Windows NT Server 4.0 computer as a supporting server.
  • Any Message Queuing server operating in domain mode with at least independent client functionality, preferably in the local site, but also in a nearby site, can serve as the supporting server for a dependent client.
  • By default, following installation, Message Queuing servers are not enabled to support dependent clients. For instructions on enabling a Message Queuing server to act as a supporting server, see Enable a supporting server.
  • To enable a Message Queuing server to act as a supporting server for a dependent client, you must change the security configuration of the Microsoft Distributed Transaction Coordinator (DTC) to support network transactions. For details, see Enable network DTC access.
  • If you have the early version of a dependent client running on Windows NT 4.0 and you want to change its supporting server to a Message Queuing server running on Windows 2000, the dependent client must first have Windows NT 4.0 Service Pack 4 or higher installed or transactional messaging will not function.
  • New Message Queuing 3.0 features, such as HTTP transport, Message Queuing Triggers, and sending messages to multiple destinations, are not available to dependent clients. Thus, distribution lists, multiple-element format names, and multicast messaging are not supported for dependent clients.
  • Dependent clients will no longer be supported in future versions of Message Queuing.

Related Topics


View the dependent client list for a server

Microsoft Windows Graphic

To view the dependent client list for a server

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. Click the Dependent Clients tab, and then click Refresh to ensure that the list is current.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • You can only view those dependent clients that are currently active (such as currently sending messages), which may not be the total number of dependent clients in your organization.
  • By default, following installation, Message Queuing servers are not enabled to support dependent clients. For instructions on enabling a Message Queuing server to act as a supporting server, see Enable a supporting server.
  • For information on how to change the supporting Message Queuing server for a dependent client, see Related Topics.

Related Topics


Set the message storage size for computers

Microsoft Windows Graphic

To set the message storage size for computers

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. On the General tab, in Storage limits, select the Limit message storage to (KB) check box, and then type a maximum total size (in kilobytes) for messages stored in all queues on the selected computer.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • This procedure is not applicable to computers operating in workgroup mode or virtual servers in clusters. You can set the computer quota of a workgroup computer using the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\MachineQuota registry key. To change the quota for a virtual server, you need to change the analogous registry key for clustered servers. After setting the registry, restart the Message Queuing service for the changes to take effect.

    • Caution

    • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.
  • Following a new installation of Message Queuing, or an upgrade from Windows 2000, the default limit for these storage sizes is 8 gigabytes (GB).
  • When the computer quota is reached, no messages can be delivered to any queue or journal on the computer. No negative acknowledgment message is generated, and an error is returned for messages sent locally, while a remote computer tries to resend until the cumulative size of all messages in the queues drops below the specified limit.
  • For information on how to set the journal storage size limit (or quota) for a computer, see Related Topics.

Related Topics


Set the journal storage size for computers

Microsoft Windows Graphic

To set the journal storage size for computers

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. On the General page, in Storage Limits, select the Limit journal storage to (KB) check box, and then type the total size (in kilobytes) of all journal messages that can be stored in the computer journal on the selected computer.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • This procedure is not applicable to computers operating in workgroup mode or virtual servers in clusters. You can set the computer quota of a workgroup computer using the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\MachineJournalQuota registry key. To change the quota for a virtual server, you need to change the analogous registry key for clustered servers. After setting the registry, restart the Message Queuing service for the changes to take effect.

    • Caution

    • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.
  • Following a new installation of Message Queuing, or an upgrade from Windows 2000, the default limit for these storage sizes is 8 gigabytes (GB).
  • Automatically created folders used to store copies of messages are called journals. Messages stored in journals are called journal messages. When the journal storage limit (or quota) is reached, additional messages cannot be placed in the computer journal on the computer until the cumulative size of the journal messages in all journals on that computer drops below the specified limit.
  • When you set the journal storage size limit for a computer, you automatically set equal quotas for the computer journal (the Journal messages queue), the dead-letter queue, and the transactional dead-letter queue.
  • The journal messages stored in source or computer journals can include any outgoing nontransactional message. The journal messages stored in target or queue journals can include any incoming message, including transactional messages.
  • For information on how to set the message storage limit (or quota) for a computer, see Related Topics.

Related Topics


Store messages on multiple disk drives

Microsoft Windows Graphic

To store messages on multiple disk drives

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. On the Storage page, type a different drive letter and path as applicable in Message files folder, Message logger folder, or Transaction logger folder.
  5. If prompted to stop the Message Queuing service, click Yes.
  6. If prompted to restart Windows, click Restart Now.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • By default, Message Queuing stores all message files, log files, and transaction log files in the \Windows\System32\Msmq\Storage folder on the drive on which Message Queuing is installed.

Related Topics


Set DNS properties for Message Queuing

Microsoft Windows Graphic

To set DNS properties for Message Queuing

  1. Open Network Connections in Control Panel.
  2. Right-click Local Area Connection, and then click Properties.
  3. In the Local Area Connection Properties dialog box, in the components list, click Internet Protocol (TCP/IP).
  4. Click Properties.
  5. On the General page, do any of the following:
    • To specify that the DNS server will be located automatically, on the General page, select Obtain DNS server address automatically.
    • To specify one or two DNS servers, on the General page, select Use the following DNS server addresses. Then, in Preferred DNS server, type the IP address of the preferred DNS server, and in Alternate DNS server, type the IP address of an optional alternate DNS server.
    • To specify more than two DNS servers, on the General page, click Advanced. On the Advanced TCP/IP Settings page, click the DNS tab. Under DNS server addresses, in order of use, click Add; in DNS server, type the address of a DNS server and click Add. Repeat this step for each DNS server that you want to specify. You can use the Up and Down buttons to change the order of the DNS servers in the list. You can also click Edit to change the address of the selected DNS server in the list, or you can click Remove to delete it from the list.

Notes

  • To open Network Connections, click Start, point to Settings, click Control Panel, and then double-click Network Connections.
  • This task is performed only if you are operating in a DNS-only environment (an environment that has no WINS server). Message Queuing requires DNS to be configured to correctly resolve computer names.

Related Topics


Start or stop services for Message Queuing

Microsoft Windows Graphic

To start or stop services for Message Queuing

  1. Open Computer Management.
  2. In the console tree, click Services.

    Where?

    • Computer Management
    • Services and Applications
    • Services
  3. In the details pane, right-click the applicable service, and then do one of the following, if applicable (options that are not applicable are dimmed):
    • To start a service, click Start.
    • To stop a service, click Stop.
    • To pause a service, click Pause.
    • To resume a service that has been paused, click Resume.
    • To restart a service, click Restart.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You can view the status of a service by looking in the Status column in the details pane.
  • This procedure is applicable to the Message Queuing service, and the Message Queuing Triggers service.
Related Topics


Administer Security for Message Queuing

This section shows you how to:

  • Set permissions for computer and queue objects
  • Set permissions for routing link objects
  • Set permissions for MSMQ Settings objects
  • Set permissions for Message Queuing files
  • Set permissions for distribution lists
  • Change ownership of computer and queue objects
  • Change the Message Queuing service account
  • Audit access to computer and queue objects
  • Enable Message Queuing to access SACL information
  • Audit access to routing link objects
  • Enable hardened MSMQ mode
  • Enable secured remote read
  • Weaken security using ADSI Edit
  • Change the security settings for Internet Information Services
  • Administer Authentication and Encryption for Message Queuing


Set permissions for computer and queue objects

Microsoft Windows Graphic

To set permissions for computer and queue objects

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. To grant Message Queuing-specific permissions for a computer (an msmq object), in the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq

    Or, to grant Message Queuing-specific permissions for a queue, right-click the applicable queue.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
    • YourQueueFolder (Private Queues for a private queue)
    • YourQueue
  4. Click Properties.
  5. On the Security page, set permissions for the object specified in Step 3, as needed:
    • To grant permissions for this object to a group or user appearing under Group or user names, select the applicable group or user, and then in Permissions for GroupOrUser, select the check boxes in the Allow column following the names of the applicable permissions.
    • To deny a group or user permissions for this object, select the applicable group or user in Group or user names, and then in Permissions for GroupOrUser, select the check boxes in the Deny column following the names of the applicable permissions.
    • To add a new group or user for access, click Add. In the Select Users, Computers, or Groups dialog box, click Object Types, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Enter the object name to select, type the name of a group or user or the names of several groups or users separated by semicolons, and click OK. Or, click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, and then click OK again. Then, select the group or user you just added and select the applicable check boxes as needed.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The queue objects for the queues residing on a particular computer are child objects of the msmq object of the applicable computer. For example, to create a queue, a user must have the Create All Child Objects permission for the msmq object under which the queue will be created.
  • You can grant or deny permissions for an object even to the Administrators group.
  • This procedure cannot be used to set permissions for a private queue on a remote computer.

Security

  • The default permission is that everyone can send messages to a queue. For tighter security, you can change the default security permissions for the queue. You can also specify properties for greater security when you create a queue, for example, to accept authenticated messages only. For instructions, see Allow only authenticated messages on queues.

Related Topics


Set permissions for routing link objects

Microsoft Windows Graphic

To set permissions for routing link objects

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  3. On the View menu, click Show Services Node.
  4. Right-click MsmqServices, and then click Properties.
  5. On the Security page, set permissions as needed:
    • To grant permissions for this object to a group or user appearing under Group or user names, select the applicable group or user, and then in Permissions for GroupOrUser, select the check boxes in the Allow column following Create All Child Objects and Delete All Child Objects.
    • To deny a group or user permissions for this object, select the applicable group or user in Group or user names, and then select the check boxes in the Deny column following Create All Child Objects and Delete All Child Objects.
    • To add a new group or user for access, click Add. In the Select Users, Computers, or Groups dialog box, click Object Types, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Enter the object name to select, type the name of a group or user or the names of several groups or users separated by semicolons, and then click OK. Or, click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, and then click OK again. Then select the group or user you just added and select the applicable check boxes as needed.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • Each routing link object is a child object of the MsmqServices object. Thus, the Create All Child Objects and Delete All Child Objects permissions for the MsmqServices object are needed to create, modify, and delete routing links. By default, only the Enterprise Admins group has both of these permissions.

Related Topics


Set permissions for MSMQ Settings objects

Microsoft Windows Graphic

To set permissions for MSMQ Settings objects

  1. Open Active Directory Sites and Services.
  2. In the console tree, select the applicable server object.

    Where?

    • Active Directory Sites and Services
    • Sites
    • YourSiteObject
    • Servers
    • YourServerObject
  3. Right-click the MSMQ Settings object in the details pane, and then click Properties.
  4. On the Security page, set permissions as needed:
    • To grant permissions for this object to a group or user appearing under Group or user names, select the applicable group or user, and then in Permissions for GroupOrUser, select the check boxes in the Allow column following Create All Child Objects and Delete All Child Objects.
    • To deny a group or user permissions for this object, select the applicable group or user in Group or user names, and then select the check boxes in the Deny column following Create All Child Objects and Delete All Child Objects.
    • To add a new group or user for access, click Add. In the Select Users, Computers, or Groups dialog box, click Object Types, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Enter the object names to select, type the name of a group or user or the names of several groups or users separated by semicolons, and then click OK. Or, click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, and then click OK again. Then select the group or user that you just added and select the applicable check boxes as needed.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.

Related Topics


Set permissions for Message Queuing files

Microsoft Windows Graphic

To set permissions for Message Queuing files

  1. On the desktop, right-click My Computer, and then click Explore.
  2. Locate and right-click the folder used to store the message files, log files, and transaction log files (usually Storage under \Windows\System32\Msmq), and then click Properties.
  3. On the Security page, in Group or user names, click Administrators.
  4. In Permissions for Administrators, under Allow, select the Full Control check box.
  5. In Group or user names, select any group or user, including the Administrators group, that you do not want to access the Message Queuing storage files directly, and click Remove. Repeat this step as needed.

Notes

  • You can set both file-level and folder-level permissions only on NTFS-formatted drives. You cannot set folder-level permissions on FAT-formatted drives. (The Security tab is not available for folders on FAT-formatted drives.)

Security

  • By default, only members of the Administrators group of the local computer have permissions for the folder used to store message files, log files, and transaction log files. For best security practice, it is not recommended that you widen these default permissions, or you may open Message Queuing for access by unauthorized persons.

Related Topics


Set permissions for distribution lists

Microsoft Windows Graphic

To set permissions for distribution lists

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. To grant permissions for a distribution list, in the console tree, right-click the applicable distribution list (group).

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • Users
    • YourDistributionList(Group)
  4. On the Security page, set permissions for the object specified in Step 3, as needed:
    • To grant permissions for this object to a group or user appearing under Group or user names, select the applicable group or user, and then in Permissions for GroupOrUser, select the check boxes in the Allow column following the names of the applicable permissions.
    • To deny a group or user permissions for this object, select the applicable group or user in Group or user names, and then select the check boxes in the Deny column following the names of the applicable permissions.
    • To add a new group or user for access, click Add. In the Select Users, Computers, or Groups dialog box, click Object Types, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Enter the object name to select, type the name of a group or user or the names of several groups or users separated by semicolons, and then click OK. Or, click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, and then click OK again. Then, select the group or user you just added and select the applicable check boxes as needed.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Message Queuing distribution lists are distribution group objects in Active Directory.

Security

  • Distribution lists are not created or managed with Message Queuing tools or APIs. For best security practice, consider carefully the permissions granted to distribution list objects.

Related Topics


Change ownership of computer and queue objects

Microsoft Windows Graphic

To change ownership of computer and queue objects

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. To change the ownership of a computer (an msmq object), in the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq

    Or, to change the ownership of a queue, right-click the applicable queue.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
    • YourQueueFolder (Private Queues for a private queue)
    • YourQueue
  4. Click Properties.
  5. On the Security page, click Advanced.
  6. On the Owner page, in Change Owner to, click a new user or group, and then click OK.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • By default, the computer account is the owner of the msmq object, unless routing or the Downlevel Client Support component is enabled on the server. In that case, the creator is the owner. For the queue object, the creator is the owner by default.
  • When a local user (a user not logged on to a Windows Server 2003 family domain) creates an object, the Everyone group is granted Full Control permissions for the object.
  • There can be only one owner per Message Queuing computer or queue.
  • This procedure cannot be used to change the ownership of a private queue on a remote computer.

Related Topics


Change the Message Queuing service account

Microsoft Windows Graphic

To change the Message Queuing service account

  1. Open Computer Management.
  2. In the console tree, click Services.

    Where?

    • Computer Management
    • Services and Applications
    • Services
  3. In the details pane, double-click Message Queuing.
  4. On the Log On page, click This account, and then click Browse. In Name, type the name of the user account, and then click OK.
  5. In Password, type the account password.
  6. In Confirm Password, type the account password again.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • This procedure is also applicable to the Message Queuing Triggers service. In this case, in Step 3, double-click Message Queuing Triggers in the details pane.
  • Running the Message Queuing service under user accounts is not supported on domain controllers. Thus, the Message Queuing Downlevel Client Support service, which enables pre-Windows Server 2003 family clients to access objects in Active Directory, must run under the Local System account on domain controllers.

Related Topics


Audit access to computer and queue objects

Microsoft Windows Graphic

To audit access to computer and queue objects

  1. Open Active Directory Users and Computers.
  2. Highlight Active Directory Users and Computers, and on the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. To audit access to a computer (an msmq object), in the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq

    Or, to audit access to a queue, right-click the applicable queue.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
    • YourQueueFolder (Private Queues for a private queue)
    • YourQueue
  4. Click Properties
    5. .
  5. On the Security page, click Advanced.
  6. On the Auditing page of the Advanced Security Settings dialog box, click Add.
  7. In the Select Users, Computers, or Groups dialog box, click Object Types, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Enter the object name to select, type the name of a group or user whose access you want to audit or the names of several such groups or users separated by semicolons and click OK. Or, click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, and then click OK again.
  8. In the Auditing Entry dialog box, in Apply onto, select the applicable objects for which user access will be audited. Then, under Access, select the appropriate check boxes next to the applicable entries and click OK. Or, to clear all audit entries, click Clear All, and then click OK.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • This procedure cannot be used to audit access to a private queue on a remote computer.
  • In addition to auditing access to computer and queue objects, you must also establish an audit policy for the local computer.

Related Topics


Enable Message Queuing to access SACL information

Microsoft Windows Graphic

To enable Message Queuing to access SACL information

  1. Open Active Directory Users and Computers.
  2. In the console tree, right-click Domain Controllers.

    Where?

    • Active Directory Users and Computers
    • Domain Controllers
  3. Click Properties.
  4. Click the Group Policy tab.
  5. Click the default Group Policy, and then click Edit.
  6. In the Group Policy object snap-in, open Computer Configuration, open Windows Settings, open Security Settings, open Local Policies, right-click User Rights Assignment, and then click Open.
  7. Double-click Manage Auditing and Security Log, and then click Add User or Group.
  8. Add the computer account name of the computer running the Message Queuing service, and then click OK.
  9. Wait for about 5 minutes to allow changes to take effect in Active Directory, and then restart the computer.

Notes

  • After the Message Queuing service is enabled to access SACL information, you need to establish an auditing policy. For information, see Define or modify auditing policy settings for an event category.

Related Topics


Audit access to routing link objects

Microsoft Windows Graphic

To audit access to routing link objects

  1. Open Active Directory Sites and Services.
  2. Highlight Active Directory Sites and Services, and on the View menu, click Show Services Node.
  3. In the console tree, click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. In the details pane, right-click the applicable routing link, and then click Properties.
  5. On the Security page, click Advanced.
  6. On the Auditing page of the Advanced Security Settings dialog box, click Add.
  7. In the Select Users, Computers, or Groups dialog box, click Object Types, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Enter the object name to select, type the name of a group or user whose access you want to audit or the names of several such groups or users separated by semicolons and click OK. Or, click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, and click OK again.
  8. In the Auditing Entry dialog box, in Apply onto, select the applicable objects for which user access will be audited. Then, under Access, select the appropriate check boxes next to the applicable entries and click OK. Or, to clear all audit entries, click Clear All, and then click OK.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • The information generated by an audit is stored in the security log. For information on how to use Event Viewer to view information in the security log, see Related Topics.
  • This procedure can be used to audit access to any Message Queuing object under, and including, the MsmqServices object.
  • In addition to auditing access to computer and queue objects, you must also establish an audit policy for the local computer.

Related Topics


Enable hardened MSMQ mode

Microsoft Windows Graphic

To enable hardened MSMQ mode

  1. Open Computer Management.
  2. In the console tree, click Services and Applications.

    Where?

    • Computer Management
    • Services and Applications
  3. In the details pane, right-click Message Queuing, and then click Properties.
  4. On the Server Security tab, select Enable Hardened MSMQ mode to secure this computer on the Internet, and then click OK.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Following installation, hardened MSMQ mode is not enabled by default.
  • To reset server security settings on this tab to the default settings following installation, click Restore Defaults.

Related Topics


Enable secured remote read

Microsoft Windows Graphic

To enable secured remote read

  1. Open Computer Management.
  2. In the console tree, click Services and Applications.

    Where?

    • Computer Management
    • Services and Applications
  3. In the details pane, right-click Message Queuing, and then click Properties.
  4. On the Server Security tab, select Enable secured remote receiving. In this mode, only servers running Windows Server 2003 can receive messages remotely from queues on this computer, and then click OK.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • To reset server security settings on this tab to the default settings following installation, click Restore Defaults.

Related Topics


Weaken security using ADSI Edit

Microsoft Windows Graphic

To weaken security using ADSI Edit

  1. Click Start, click Run, type adsiedit.msc, and then press Enter.
  2. In the console tree, right-click CN=MsmqServices.

    Where?

    • Configuration Container
    • CN=Configuration,...
    • CN=Services
    • CN=MsmqServices
  3. Click Properties.
  4. On the Attribute Editor page, in Attributes, select mSMQNameStyle, and then click Edit.
  5. In Boolean Attribute Editor, select True to weaken security, or False to tighten security.
  6. Click OK.

Notes

  • Windows Server 2003 family Support Tools, which is provided on the Windows Server 2003 family compact disc, must be installed before you can use ADSI Edit. To install these tools, perform the following steps:
    1. Insert the Windows Server 2003 family CD in your CD-ROM drive.
    2. Open the Support folder, and then open the Tools folder.
    3. Double-click Suptools to start the install program.
    4. Follow the instructions in the Windows Support Tools Setup Wizard, and select Complete on the Select An Installation Type page.
  • This procedure is used to weaken Active Directory security to support MSMQ 1.0 users, Message Queuing 2.0 clients logged on with local user accounts, and certain operating configurations.
  • Only users with the Write permission for the MsmqServices object can perform this procedure. By default, only members of the Domain Admins or Enterprise Admins groups of the root domain and members of the SYSTEM group (local system services running on a domain controller) have the Write permissions for this object.
  • Dependent clients cannot run under a local user account. Also, 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, will not be able to access Active Directory when it logs on using a local user account even if weakened security for Active Directory is enabled.
  • After performing this procedure, for the change to take effect, you must restart all instances of the Message Queuing Downlevel Client Support service running on Windows Server 2003 domain controllers and Message Queuing servers running on Windows 2000 domain controllers.
  • For best security practice, it is recommended that Active Directory security not be weakened unless necessary.

Related Topics


Change the security settings for Internet Information Services

Microsoft Windows Graphic

To change the security settings for Internet Information Services

  1. Click Start, click Run, type mmc, and then click OK.
  2. On the File menu, click Add/Remove Snap-in.
  3. In the Add/Remove Snap-in dialog box, click Add, select Internet Information Services, click Add, click Close, and then click OK.
  4. In the console tree, right-click MSMQ virtual directory.

    Where?

    • Console Root
    • Internet Information Services
    • YourInternet Information ServicesComputer
    • Web Sites
    • Default Web Site
    • MSMQ
  5. Click Properties, and then click the Directory Security tab.
  6. Under Authentication and access control, click Edit.
  7. To use a domain user account instead of the Internet Information Services local user for Anonymous Access, do the following:
    • In the User Name edit box, type the name of a domain user with the required permissions for the Message Queuing operation.
    • Type the user password, and then click OK.
    • Retype the password in the Confirm Password dialog, and then click OK.
  8. To disable anonymous access and trust the Internet Information Services computer for delegation, do the following:
    • In the Enable Anonymous Access group, clear the Enable anonymous access check box, and click OK.
    • Open Active Directory Users and Computers.
    • On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
    • In the console tree, right-click the name of your Internet Information Services computer.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • Computers
      • YourInternet Information ServicesComputer
    • Click Properties.
    • On the General page, select the Trust computer for delegation check box, and then click OK
  9. In the Internet Information Services snap-in, right-click YourInternet Information ServicesComputer.

    Where?

    • Console Root
    • Internet Information Services
    • YourInternet Information ServicesComputer
  10. Restart Internet Information Services by selecting All Tasks \ Restart Internet Information Services..., and then click OK.

Notes

  • By default, Internet Information Services (IIS) impersonates a special Internet Information Services local user account. This account is local to the IIS computer (unless it is a domain controller). It cannot be authenticated by other computers in the network, and is treated as an anonymous user. Active Server Page (ASP) applications and scripts run under IIS and, by default, impersonate the IIS local user for any Message Queuing operations, including queries to Active Directory. Since anonymous users no longer belong to the Everyone group in Windows Server 2003 family operating systems, these queries fail. ASP applications and scripts cannot locate, create, and delete queues by default. In addition anonymous users cannot open a queue for remote read, and you cannot read messages from queues not belonging to the IIS computer using ASP by default.
  • For the changes to take effect, you must stop and start the World Wide Web Publishing service.
  • Trusting the computer for delegation allows multiple hops to communicate with a domain controller, assuming that the user account is trusted for delegation.

Related Topics


Administer Authentication and Encryption for Message Queuing

This section shows you how to:

  • Obtain client certificates
  • Enable client certificates
  • Register certificates for Message Queuing
  • Remove certificates for Message Queuing
  • View certificates for Message Queuing
  • Renew certificates for Message Queuing
  • Renew cryptographic keys for Message Queuing
  • Obtain server certificates for HTTPS messaging
  • Administer Server Authentication


Obtain client certificates

Microsoft Windows Graphic

To obtain client certificates

  1. In your Web browser, open the form at http://servername/certsrv for requesting a certificate from your CA, where servername is the name of the Web server where the CA that you want to access is located.
  2. Click Request a certificate, click Advanced certificate requests, and then click Create and submit a request to this CA.
  3. Type the information requested and any other options required, including:
    • Under Type of certificate needed, select Client Authentication Certificate.
    • Select the Use local machine store.
    • Select Mark keys as exportable.
  4. Click Submit, and then do one of the following:
    • If you see the Certificate Pending Web page, check on the pending certificate request.
    • If you see the Certificate Issued Web page, click Install this certificate.
  5. If you are finished using the Certificate Services Web pages, close Internet Explorer.

Once you have obtained the client certificate, verify that it is in your Personal store and is valid. To do this:

  1. Open the Certificates MMC snap-in.
  2. Locate the installed client certificate in the Personal store under Certificates (Local Computer), and then double-click the certificate to verify it.

Once you have ensured that the client certificate is valid, copy it to the MSMQ certificates store, as follows:

  1. Open the Certificates MMC snap-in.
  2. Locate the installed client certificate in the Personal store under Certificates (Local Computer).

    Where?

    • Console Root
    • Certificates (Local Computer)
    • Personal
    • Certificates
  3. Drag the certificate with your mouse to move it to the MSMQ\Personal store under Certificates - Service (Message Queuing) on Local Computer in the Certificates snap-in.

    Where?

    • Console Root
    • Certificates - Service (Message Queuing) on Local Computer
    • MSMQ\Personal
    • Certificates

Notes

  • To open the Certificates snap-in, click Start, click Run, type mmc, and then click OK. On the File menu, click Add/Remove Snap-in, and then click Add. Select Certificates, and then click Add. Select Service account, click Next, select Local Computer (the computer this console is running on), and then click Next. In Service Account, select Message Queuing, and then click Finish. When you finish working in the MMC console, you can save the settings so that the custom MMC is available next time you open the console.
  • To check on a pending certificate request, in the CA Web page, click View the status of a pending certificate request. If you see pending certificates, select the certificate request you want to check, and then click Next. If the status is Still pending, you must wait for the administrator of the CA to issue the certificate. If the status is Issued, to install the certificate, click Install this certificate. If the status is Denied, contact the CA administrator for more information.
  • Note that before requesting a client certificate, you might need to make the CA Web page a trusted site for Internet Explorer. To do this, on the Tools menu in Internet Explorer, click Internet Options. On the Security tab, click Trusted Sites, and then click Sites. Uncheck Require server verification (https:) for all sites in the zone. Type http://servername, and then click Add.
  • It is not necessary to have the client certificate locally on the receiving computer, but the receiving computer must be able to access the client certificate.
  • This task can be performed only from a Message Queuing server installed on a Windows Server 2003 family domain controller.

Related Topics


Enable client certificates

Microsoft Windows Graphic

To enable client certificates

  1. On the receiving computer, open the Internet Information Services snap-in as follows: click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS).
  2. In the console tree, right-click MSMQ.

    Where?

    • Console Root
    • Internet Information Services
    • YourComputer
    • Web Sites
    • Default Web Site
    • MSMQ
  3. Click Properties.
  4. Select the Directory Security tab, and then under Secure Communications, click Edit.
  5. To require that a secure link be used for a site resource, click Require secure channel (SSL).
  6. Under Client certificates, select one of the following to enable client certificate authentication:
    • To enable clients to access a resource with a client certificate, click Accept client certificates. Note that a client certificate is not required.
    • To ensure that users without a valid client certificate will be denied access to the site resource, click Require client certificates.
    • To grant access to users with or without a client certificate, click Ignore client certificates.
  7. To enable client certificate mapping, in the Secure Communications dialog box, select Enable client certificate mapping if not already selected, and then click Edit. For instructions on creating a mapping, see the IIS online Help file.

Notes

  • By default, anonymous access is enabled for the MSMQ virtual directory using the account IUSR_computername. To prevent both authenticated and unauthenticated HTTP messages from being sent, disable anonymous access. For instructions, see To change the security settings for Internet Information Services.
  • By default, IUSR_computername user has write permission for the physical MSMQ directory (default is %SystemDrive%\Inetpub\wwwroot\msmq), and Ignore client certificates is selected, thus allowing everyone to send HTTPS messages. You can control access to MSMQ virtual directory by configuring security settings for the physical Message Queuing directory.
  • Requiring a secure channel means that a user cannot connect to a site resource without using a secure link (that is, the link's URL must begin with https://).

Related Topics


Register certificates for Message Queuing

Microsoft Windows Graphic

To register certificates for Message Queuing

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the User Certificate tab, and then under User certificates, click Register.
  5. In the Personal Certificates dialog box, click a certificate, and then click Register.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Your computer must have access to Active Directory to perform this task.
  • During setup, an internal user certificate is automatically created for you on the local computer and is registered in Active Directory the first time you log on to the local computer in a domain provided your computer can communicate with a domain controller when you log on.
  • If no internal certificate exists, such as when the internal certificate is removed, this procedure creates a new internal certificate, which you can register. You can also use this procedure to register an external certificate after you import it.
  • If a certificate registered on the local computer is removed from a remote computer, the record of the certificate is removed from Active Directory, but the certificate will still exist on the local computer.
  • 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. For registering certificates, the user object requires the Write Personal Information permission in the Active Directory.
  • 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, and obsolete certificates can be deleted. For instructions, see Remove certificates for Message Queuing.

Related Topics


Remove certificates for Message Queuing

Microsoft Windows Graphic

To remove certificates for Message Queuing

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the User Certificate tab, and then under User certificates, click Remove.
  5. In the Personal Certificates dialog box, click the applicable user certificate, and then click Remove.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • A list of all certificates registered for the user in Active Directory is displayed in the Personal Certificates dialog box. There might be a certificate for the same user on more than one computer, including the computer from which you are currently running the MMC snap-in. The list will take the form of domain\user, computer name.
  • You can remove any user certificate that is listed. However, if a registered certificate for a computer is removed using another computer, the certificate is removed from Active Directory, but will still exist on the local computer.
  • 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 (user account, computer_name), indicating obsolete entries, then only the latest certificate is used, and the others can be deleted. For example:
    • DOMAINA\user1, computer3
    • DOMAINA\user1, computer3
    • DOMAINA\user1, computer3
  • You can check which is the latest entry for DOMAINA\user1, computer3, and delete the other computer3 entries. To check the latest entry, click the required certificate, and then click View Certificate. On the Details tab, look at the Valid from field. Note that only the certificate with the most recent Valid from date is in use. The others are obsolete.

Related Topics


View certificates for Message Queuing

Microsoft Windows Graphic

To view certificates for Message Queuing

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the User Certificate tab, and then under User certificates, click View.
  5. In the Personal Certificates dialog box, click a certificate, and then click View Certificate.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • A list of all certificates registered for the user in Active Directory is displayed in the Personal Certificates dialog box. There might be a certificate for the same user on more than one computer (including the computer from which you are currently running the MMC snap-in. The list will take the form of domain\user, computer name.

Related Topics


Renew certificates for Message Queuing

Microsoft Windows Graphic

To renew certificates for Message Queuing

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the User Certificate tab, and then under Internal certificate, click Renew.

    A warning appears stating that authenticated messages that you have already sent using the current internal certificate may be rejected as not authenticated.

  5. If rejecting those messages is acceptable, click Yes. Or, if it is not acceptable, click No and renew your internal certificate some other time.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • When the certificate is successfully renewed, a message appears stating that the internal certificate was successfully renewed and registered in Active Directory.
  • This task is not relevant for Message Queuing computers installed in workgroup mode.

Related Topics


Renew cryptographic keys for Message Queuing

Microsoft Windows Graphic

To renew cryptographic keys for Message Queuing

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the Service Security tab, and under Cryptographic keys, click Renew.

    5. A warning appears stating that received messages may be encrypted with a cryptographic key different from the one that your computer currently has. You will not be able to read those messages. You will be asked whether you want to continue.

  5. If not being able to read those messages is acceptable, click Yes. Or, if it is not acceptable, click No and renew your cryptographic key at some other time.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Only the user who installed Message Queuing has the permissions needed to renew the cryptographic keys. If Message Queuing is installed in workgroup mode, and then the computer joins a domain, only domain administrators are allowed to renew the cryptographic keys.
  • This task does not apply to dependent clients and Message Queuing computers installed in workgroup mode.

Related Topics


Obtain server certificates for HTTPS messaging

Microsoft Windows Graphic

To obtain server certificates for HTTPS messaging

  1. On the server requiring a certificate, to request a certificate, open Internet Explorer.
  2. In Internet Explorer, connect to http://servername/certsrv, where servername is the name of the server where the certification authority (CA) you want to access is located.
  3. Click Request a certificate, and then click Advanced certificate request.
  4. To submit a request using a form, click Create and submit a certificate request to this CA, and then click Next.
  5. Fill in any identifying information requested and any other options you require, including:
    • In Name, enter the name of the computer that requires the certificate.
    • In Type of Certificate Needed, choose Server Authentication Certificate.
    • In Key Options, select Use the local machine store.
    • In Key Options, select Marks keys as exportable if you want to export the private key at a later time.
    • Leave other options at default values.
  6. Click Submit.
  7. When you see the Certificate Service Web Page, click Install this certificate to add the certificate to your certificate store.
  8. If you are finished using the Certificate Services Web pages, close Internet Explorer.
  9. After you have the certificate, open Computer Management.
  10. In the console tree, click Default Web Site.

    Where?

    • Computer Management
    • Services and Applications
    • Internet Information Services (IIS)
    • Web Sites
  11. Right-click Default Web Site, and then click Properties.
  12. On the Directory Security tab, click Server Certificate.
  13. In the Web Server Certificate Wizard, do the following:
    • On the Server Certificate page, select Assign an existing certificate.
    • In Available Certificates, select the required certificate, and then click Next.
    • In the SSL Port page, click Next.
    • In Certificate Summary, click Next, and then click Finish.

Notes

  • After this procedure is complete, you can view the certificate. To do this, right-click Default Web Site, and then click Properties. On the Directory Security tab, click View Certificate.

Related Topics


Administer Server Authentication

This section shows you how to:

  • Export key certificates from Windows NT 4.0
  • Create server certificates for Message Queuing
  • Import server certificates for Message Queuing
  • Change server certificates for Message Queuing
  • Import a CA certificate from Microsoft Certificate Services


Export key certificates from Windows NT 4.0

Microsoft Windows Graphic

To export key certificates from Windows NT 4.0

  1. On your MSMQ 1.0 controller server with Windows NT 4.0 Option Pack installed, click Start, point to Programs, point to Windows NT 4.0 Option Pack, point to Microsoft Information Server, and then click Internet Services Manager.
  2. In the console tree, right-click Default Web Site.

    Where?

    • Console Root
    • Internet Information Services
    • YourComputer
    • Default Web Site
  3. Click Properties.
  4. Click the Directory Security tab, and then under Secure Communications, click Key Manager.
  5. In the Key Manager console, click Certificate.

    Where?

    • Local Computer
    • MSMQ
    • Certificate
  6. On the Key menu, point to Export Key and click Backup File.
  7. Follow the instructions in the wizard and type a name for the backup file.

Notes

  • For more information about using Internet Services Manager, click the Action menu after the console appears, and then click Help.
  • This task applies only if you are upgrading an MSMQ 1.0 controller server to a Message Queuing server.
  • You must export the key certificate before you upgrade the MSMQ 1.0 controller server. Then you can import the certificate to the upgraded server. You need to import a server (key) certificate only for each Message Queuing server that will reply to Active Directory queries from MSMQ clients running on Windows NT 4.0, Windows 98, or Windows 95.

Related Topics


Create server certificates for Message Queuing

Microsoft Windows Graphic

To create server certificates for Message Queuing

  1. Click Start, click Run, type mmc, and then click OK.
  2. On the File menu, click Add/Remove Snap-in.
  3. In the Add/Remove Snap-in dialog box, click Add, select Certificates, and then click Add.
  4. In the Certificates snap-in dialog box, click Computer account, click Next, click Finish, click Close, and then click OK.
  5. In the console tree, double-click Certificates, right-click Personal, point to All Tasks, and then click Request New Certificate.
  6. Follow the instructions that appear in the Certificate Request Wizard. When prompted to type a friendly name for the certificate, type the name of the local Message Queuing server.
  7. After you have obtained the certificate, open Computer Management.
  8. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  9. Click Properties.
  10. In the Message Queuing Properties dialog box, click the Service Security tab, and then in the Server certificates group box, click Select a Certificate.
  11. Under Issued to, select the certificate with the name of the applicable Message Queuing server, and then click OK.
  12. When prompted to restart Windows, click Restart Now.

Notes

  • You can open the Certificates snap-in after you have added it to a console and saved the console settings in an .msc file as follows: click Start, point to All Programs, point to Administrative Tools, and then click the name of the saved .msc file.
  • To open Computer Management, right-click My Computer, and then click Manage.
  • This task can be performed only from a Message Queuing server installed on a Windows Server 2003 family domain controller.
  • You need to create a server certificate only for each Message Queuing server that replies to Active Directory queries from MSMQ clients running on Windows NT 4.0, Windows 95, or Windows 98.

Related Topics


Import server certificates for Message Queuing

Microsoft Windows Graphic

To import server certificates for Message Queuing

  1. Click Start, click Run, type mmc, and then click OK.
  2. On the File menu, click Add/Remove Snap-in.
  3. In the Add/Remove Snap-in dialog box, click Add, select Internet Information Services, click Add, click Close, and then click OK.
  4. In the console tree, right-click MSMQ.

    Where?

    • Console Root
    • Internet Information Services
    • YourComputer
    • Web Sites
    • Default Web Site
    • MSMQ
  5. Click Properties.
  6. Click the Directory Security tab, and then click Server Certificate. In the Web Server Certificate Wizard, click Next.
  7. Click Import a certificate from a Key Manager backup file, and then click Next.
  8. Enter the path and file name for the backup file you previously created when you exported the certificate from Windows NT 4.0, and then click Next.
  9. Type the proper password, click Next, and then click Finish.
  10. After you have obtained the certificate, open Computer Management.
  11. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  12. Click Properties.
  13. In the Message Queuing Properties dialog box, click the Service Security tab, and then in the Server certificates group box, click Select a Certificate.
  14. Under Issued to, select the certificate with the name of the Message Queuing server to which you imported the certificate, and then click OK.

Notes

  • You can also open the Internet Information Services snap-in as follows: click Start, point to All Programs, point to Administrative Tools, and then click Internet Services Manager. Or, you can open this snap-in after you have added it to a console and saved the console settings in an .msc file as follows: click Start, point to All Programs, point to Administrative Tools, and then click the name of the saved .msc file.
  • To open Computer Management, right-click My Computer, and then click Manage.
  • This task applies only if you are upgrading an MSMQ 1.0 controller server to a Message Queuing server installed on a Windows Server 2003 family domain controller.
  • You must first export the key certificate before you upgrade the computer to Windows Server 2003 family. Then you can import the server certificate. You need to import a server (key) certificate only for each Message Queuing server that will reply to Active Directory queries from MSMQ clients running on Windows NT 4.0, Windows 98, or Windows 95.

Related Topics


Change server certificates for Message Queuing

Microsoft Windows Graphic

To change server certificates for Message Queuing

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Click Properties.
  4. In the Message Queuing Properties dialog box, click the Service Security tab, and then in the Server certificate group box, click Select a Certificate.
  5. In the Choose MSMQ Server Certificate dialog box, select the applicable certificate, and then click OK.
  6. When prompted to restart Windows, click Restart Now.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • This task can be performed only from a Message Queuing server installed on a Windows Server 2003 family domain controller.

Related Topics


Import a CA certificate from Microsoft Certificate Services

Microsoft Windows Graphic

To import a CA certificate from Microsoft Certificate Services

  1. On the sender computer requiring a CA certificate, open Internet Explorer.
  2. In Internet Explorer, connect to http://servername/certsrv, where servername is the name of the server where the certification authority (CA) you want to access is located.
  3. Click Download a CA certificate, certificate chain, or CRL.
  4. Do one of the following:
    • If you want to trust all the certificates issued by this certification authority (CA), click Install this CA certificate chain.
    • If the certification authority has been renewed, you will have the choice of which version of the CA certificate you want to download:
    • Select the encoding method you want for the CRL: DER or Base 64.
    • Under CA Certificate, click the CA certificate you want to download, and then click Download CA certificate or click Download CA certificate chain.
    • In File Download, click Open this file from its current location, and then click OK.
    • When the Certificate dialog box appears, click Install this certificate.
    • In the Certificate Import wizard, click Automatically select the certificate store based on the type of certificate. This places the CA certificate in your Trusted Root store.
  5. If you are finished using the Certificate Services Web pages, close Internet Explorer.

Related Topics


Administer Queues for Message Queuing

This section shows you how to:

  • Create queues
  • Allow only authenticated messages on queues
  • Change the privacy level for queues
  • Find queues
  • Delete queues
  • Purge all messages in a queue
  • Take outgoing queues offline
  • Pause or resume an outgoing queue
  • Change queue labels
  • Change queue type IDs
  • Change the base priority of queues
  • Specify or view queue multicast addresses and ports
  • Set the message storage size for queues
  • Manage queues on other computers
  • Manage queues using Active Directory Users and Computers
  • Administer Journals for Message Queuing
  • Administer Queue Aliases for Message Queuing


Create queues

Microsoft Windows Graphic

To create queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue folder.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
  3. Point to New, and then click Public Queue (or Private Queue) to open the New Object – Public Queue dialog box (or the New Private Queue dialog box).
  4. Under Queue name, type a name for the new queue. Or, if you want to create a queue to accept transactional messages, type a name and select the Transactional check box.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
  • You cannot create queues in the Outgoing Queues or System Queues folder. These queues are created automatically.
  • The queue objects for the queues residing on a particular computer are child objects of the msmq object of the applicable computer. Thus, to create a queue, a user must have the Create All Child Objects permission for the msmq object under which the queue will be created.
  • You can create public queues on remote computers using the Active Directory Users and Computers snap-in provided you have domain administrative permissions and are logged on using a domain user account.
  • When you create a queue, you are prompted to specify the minimal information needed. Each queue has many more properties (attributes) that can be set. After a queue is created, the values of many additional attributes can be viewed and modified. For information on how to do this, see Related Topics.
  • When you create a queue, the default permission is that everyone can send to this queue. For tighter security, you can change the default security permissions for the queue. You can also specify properties for the queue when you create it. For example, you can specify to accept authenticated messages only. For instructions, see Allow only authenticated messages on queues.

Related Topics


Allow only authenticated messages on queues

Microsoft Windows Graphic

To allow only authenticated messages on queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. On the General page, select the Authenticated check box. Or, to accept any messages on the queue, clear the Authenticated check box.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • If you select the Authenticated check box, the queue accepts only authenticated messages.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Change the privacy level for queues

Microsoft Windows Graphic

To change the privacy level for queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. On the General page, in Privacy Level, do one of the following:
    • To have the queue accept both encrypted and unencrypted messages, click Optional (the default).
    • To have the queue accept only encrypted messages, click Body.
    • To have the queue accept only unencrypted messages, click None.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
  • Privacy levels are used to specify whether a queue accepts encrypted messages, unencrypted messages, or both by selecting the privacy level for the queue. If the queue privacy level is set to None, the queue accepts only unencrypted messages. If the queue privacy level is set to Body, the queue accepts only encrypted messages. If the queue privacy level is set to Optional, the queue accepts both unencrypted and encrypted messages. You can check whether a message sent to the queue was encrypted or unencrypted by using Active Directory Users and Computers (or programmatically by checking the PROPID_M_PRIV_LEVEL message property).

Related Topics


Find queues

Microsoft Windows Graphic

To find queues

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click any folder or object shown.
  4. Click Find.
  5. In Find, click the arrow that opens the list, and then click Message Queuing Queue.
  6. On the Find Message Queuing Queue page, in Label or Type ID, type the appropriate queue information, and then click Find Now.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • If you leave Label and Type ID empty, a list of all queues will be displayed. If you enter information in both Label and Type ID, only those queues that satisfy both criteria will be displayed.

Related Topics


Delete queues

Microsoft Windows Graphic

To delete queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
  3. Click Delete.
  4. When prompted, click Yes to delete the queue.

Important

  • When you delete a queue, all messages within the queue are also deleted.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You cannot delete queues in the Outgoing Queues or System Queues folder.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
  • When you delete a queue, the triggers associated with that queue are not deleted. If you later re-create a queue of the same name, any existing triggers will be used by this queue. However, this re-created queue will not be monitored by the Message Queuing Triggers service until the computer is restarted, or the associated triggers disabled, and then enabled again. For instructions on setting the enabled or disabled property for a trigger, see View or change properties of triggers and rules for triggers.

Related Topics


Purge all messages in a queue

Microsoft Windows Graphic

To purge all messages in a queue

  1. Open Computer Management.
  2. In the console tree, right-click Queue messages (or Journal messages).

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
    • Queue messages
      Journal messages
  3. Point to All Tasks, and then click Purge.
  4. When prompted, click Yes.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You cannot purge individual messages from a queue.
  • To increase performance, messages in journals and dead-letter queues must be purged on a regular basis.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Take outgoing queues offline

Microsoft Windows Graphic

To take outgoing queues offline

  1. Open Computer Management.
  2. In the console tree, right-click Message Queuing.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Point to All Tasks, and do one of the following:
    • To take Message Queuing offline from the network, click Take Message Queuing Offline.
    • To bring Message Queuing back online, click Bring Message Queuing Online.
  4. When prompted, click Yes.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • When you take Message Queuing offline from the network, you pause the operation of all outgoing queues on the local computer. This is useful when you communicate over a slow, expensive connection and want to defer sending messages in all outgoing queues on the computer to a later time.
  • You can also pause the operation of a single outgoing queue. For more information, see Related Topics.
  • This task can be performed only by using the Computer Management snap-in.

Related Topics


Pause or resume an outgoing queue

Microsoft Windows Graphic

To pause or resume an outgoing queue

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Outgoing Queues
    • YourOutgoingQueue
  3. Point to All Tasks.
  4. Click Pause. Or, to resume the operation of the queue, click Resume.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • When you pause the operation of an outgoing queue, you postpone the sending of messages from that queue to the corresponding destination queue. This way, you can send all pending messages to a destination queue at a later time.
  • You can also pause the operation of all outgoing queues by taking Message Queuing offline from the network. For more information, see Related Topics.
  • The icons of outgoing queues that are offline are marked by an X on a circular red background in the Computer Management console tree.
  • This task can be performed only by using the Computer Management snap-in.

Related Topics


Change queue labels

Microsoft Windows Graphic

To change queue labels

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. On the General page, in Label, type the new label for the queue.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • A queue label is a string with a maximum length of 124 Unicode characters that can be used to identify the queue. For example, queues that accept messages sent by a specific application may all have the label "Messages from my application."
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Change queue type IDs

Microsoft Windows Graphic

To change queue type IDs

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. On the General page, in Type ID, type the new queue type ID.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • The queue type ID specifies the function or type of service provided by the queue. The queue type ID must be a valid GUID in the form {dddddddd-dddd-dddd-dddd-dddddddddddd}, where d is a hexadecimal text digit. The use of the queue type ID is optional and depends on the requirements of the Message Queuing application.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Change the base priority of queues

Microsoft Windows Graphic

To change the base priority of queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable public queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Public Queues
    • YourQueue
  3. Click Properties.
  4. On the General page, in Base Priority, type a new value or use the UP ARROW or DOWN ARROW keys to enter a new value.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • The base priority can be set from -32768 to 32767. The default priority setting is 0.
  • The base priority (also known as queue priority) can be set only for public queues. Private queues do not support base priority.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Specify or view queue multicast addresses and ports

Microsoft Windows Graphic

To specify or view queue multicast addresses and ports

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
  3. Click Properties, and then click Multicast.
  4. Under Multicast address, type the multicast address and port number in the IP_Address:PortNumber syntax.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • A multicast address and a port number can be associated with any public or private queue. However, in workgroup mode, multicast addresses can be associated only with private queues, and in domain mode, a Windows Server 2003 family domain controller must be available to associate multicast addresses with public queues.
  • No spaces or leading zeros are allowed in the multicast address that you type.
  • IP multicast addresses must consist of four bytes and must lie in the class D range from 224.0.0.0 to 239.255.255.255. However, only certain ranges of addresses in this range are available for sending multicast messages. For more information, see Related Topics.
  • You can also specify or view the multicast addresses and port numbers of queues using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
  • After setting the multicast properties of a remote queue, it may take up to 15 minutes for the change to take effect.
  • On a computer with multiple NICs, a problem will arise when the computer tries to send multicast messages by means of these multiple NICs. In effect, Message Queuing will randomly choose a NIC for sending multicast messages. If the private NIC is chosen, multicast recipients will not receive the message. To work around this issue, you can specify the source IP address to be used for sending multicast messages. To do this, create the DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MulticastBindIP, in the usual IP address format. After setting the registry, restart the Message Queuing service for the changes to take effect. For more information, see IP multicasting.

    • Caution

    • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.
  • Be aware of the security implications of multicasting. Messages cannot be encrypted, and messages could be read or used by unauthorized persons. Ensure that the address specified is used only for Message Queuing multicasting.

Related Topics


Set the message storage size for queues

Microsoft Windows Graphic

To set the message storage size for queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. Select the Limit message storage to (KB) check box, and then type the total size, in kilobytes, of all queue messages that can be stored in the queue.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Any changes made will not take effect until the Message Queuing service is stopped and restarted.
  • The message storage size limit, or quota, for a queue specifies the maximum cumulative size of all messages contained in the applicable queue. This quota can be any integer between 0 and 4,294,967,294.
  • When the message storage size limit for a destination queue is reached, new incoming messages are discarded, and a negative acknowledgment message indicating that the destination queue is full is generated. Messages can be placed in the queue only after one or more messages are removed from the queue.
  • If you clear the Limit message storage to (KB) check box, the message size will be limited only by the available disk space on the local computer.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Manage queues on other computers

Microsoft Windows Graphic

To manage queues on other computers

  1. Open Computer Management.
  2. Right-click Computer Management, and then click Connect to another computer.
  3. In the Select Computer dialog box, select the computer on which you want to manage queues, and then click OK.
  4. Perform the desired task as you would for the local computer.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • To manage public queues, you must have access to Active Directory.
  • You cannot manage private queues located in a remote computer.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
Related Topics


Manage queues using Active Directory Users and Computers

Microsoft Windows Graphic

To manage queues using Active Directory Users and Computers

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click the applicable queue.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
    • YourQueueFolder (such as Private Queues for a private queue)
    • YourQueue
    • YourMessage
  4. Complete the desired task as you would using Computer Management.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • This method can be used only if the local computer belongs to a Windows Server 2003 family or Windows 2000 domain and can contact a domain controller.
  • You can create, delete, and change the properties of public queues on remote computers using the Active Directory Users and Computers snap-in only if you have domain administrative permissions and are logged on using a domain user account.
Related Topics


Administer Journals for Message Queuing

This section shows you how to:

  • Enable or disable target journaling
  • Set the journal storage size for queues


Enable or disable target journaling

Microsoft Windows Graphic

To enable or disable target journaling

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. On the General page, in Journal, select the Enabled check box. Or, to disable target journaling for the queue, clear the Enabled check box.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Target journaling is enabled or disabled on a queue basis.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Set the journal storage size for queues

Microsoft Windows Graphic

To set the journal storage size for queues

  1. Open Computer Management.
  2. In the console tree, right-click the applicable queue.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (Public Queues or Private Queues)
    • YourQueue
  3. Click Properties.
  4. On the General page, in Journal, select the Limit journal storage to (KB) check box, and then type the total size (in kilobytes) of all journal messages that can be stored in the queue journal.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • The journal storage size limit, or quota, for a queue specifies the maximum cumulative size of all journal messages contained in the applicable queue journal. This quota can be any integer between 0 and 4,294,967,294.
  • The journal storage size limit is applicable only when target journaling is enabled.
  • When the journal storage size limit is reached, additional messages can no longer be placed in the queue journal until the cumulative size of the journal messages in the queue journal drops below the specified limit.
  • If you clear the Limit journal storage to (KB) check box, the journal size will be limited by the computer quota of the local computer.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Administer Queue Aliases for Message Queuing

This section shows you how to:

  • Create queue aliases
  • Add descriptions to queue aliases
  • View or change properties of queue aliases
  • Delete queue aliases


Create queue aliases

Microsoft Windows Graphic

To create queue aliases

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then on the View menu, click Advanced Features.
  3. In the console tree, right-click the applicable container.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourContainer (such as Computers or Domain Controllers)
  4. Point to New, and then click Message Queuing Queue Alias to open the New Object - Message Queuing Queue Alias dialog box.
  5. Under Queue alias name, type the alias.
  6. Under Format name, type the applicable format name.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The format name typed can be any public, private, or direct single-element format name. The validity of the format name typed and the existence of the queues to which the queue alias points are not tested during this procedure. For examples of valid format names, see Queue Names in Related Topics.
  • Multiple aliases can be created for the same physical queue.
  • When you create a queue alias in Active Directory, you are prompted to specify the minimal information needed to establish the object in Active Directory. Each queue alias has many more properties (attributes) that can be set. After a queue alias is created, the values of many additional attributes can be viewed and modified. For information on how to do this, see Related Topics.
  • A queue alias can be used to point to a private queue and publish a private queue. For best security practice, create a queue alias with the narrowest security permissions possible.

Related Topics


Add descriptions to queue aliases

Microsoft Windows Graphic

To add descriptions to queue aliases

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then on the View menu, click Advanced Features.
  3. In the console tree, click the applicable container.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourContainer (such as Computers or Domain Controllers)
  4. In the details pane, double-click the applicable queue alias or right-click the queue alias, and then click Properties.
  5. Under Description, type a description for the alias queue.

Notes

  • To see the new queue alias description, press F5 to refresh the pane.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

Related Topics


View or change properties of queue aliases

Microsoft Windows Graphic

To view or change properties of queue aliases

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then on the View menu, click Advanced Features.
  3. In the console tree, click the applicable container.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourContainer (such as Computers or Domain Controllers)
  4. In the details pane, double-click the applicable queue alias or right-click the queue alias, and then click Properties.
  5. View or change the queue alias properties as needed.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • The format name typed can be any public, private, or direct single-element format name. The validity of the format name typed and the existence of the queues to which the queue alias points are not tested during this procedure.

Related Topics


Delete queue aliases

Microsoft Windows Graphic

To delete queue aliases

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then on the View menu, click Advanced Features.
  3. In the console tree, click the applicable container.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourContainer (such as Computers or Domain Controllers)
  4. In the details pane, click the applicable queue alias, and then press the DELETE key.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.

Related Topics


Administer Distribution Lists for Message Queuing

This section shows you how to:

  • Create distribution lists
  • View, add, or delete elements in a distribution list
  • View or change properties of distribution lists
  • Get a list of distribution lists containing a given element
  • Delete distribution lists


Create distribution lists

Microsoft Windows Graphic

To create distribution lists

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.

    Where?

    • Active Directory Users and Computers
    • YourDomain
  3. Right-click the folder in which you want to add the group, point to New, and then click Group.
  4. In the New Object – Group dialog box, type the name of the distribution list under Group Name, select the group scope that you want to use, and then select the group type Distribution.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • You can choose to give your distribution list universal, global, or domain local scope, as follows:
    • Universal. Members of universal groups can include other groups and accounts from any domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest.
    • Global. Members of global groups can include other groups and accounts only from the domain in which the group is defined and can be granted permissions in any domain in the forest.
    • Domain local. Members of domain local groups can include other groups and accounts from Windows Server 2003, Windows 2000, or Windows NT domains and can be granted permissions only within a domain.
  • Message Queuing distribution lists are distribution group objects in Active Directory.
  • When you create a distribution list (group) in Active Directory, you are prompted to specify the minimal information needed to establish the object in Active Directory. Each distribution list (group) has many more properties (attributes) that can be set. After a distribution list (group) is created, the values of many additional attributes can be viewed and modified. For information on how to do this, see Related Topics.
  • For information on how to add and remove members from distribution lists (groups), see Related Topics.
  • With distribution lists, a single operation sends the same message to multiple destinations, and does so by duplicating packets from senders to receivers. For best security practice, consider security permissions for the distribution list object in Active Directory — who is authorized to manage it and use it.

Related Topics


View, add, or delete elements in a distribution list

Microsoft Windows Graphic

To view, add, or delete elements in a distribution list

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the distribution group.
  4. In the console tree, right-click the applicable distribution list (group).

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • Folder
    • YourDistributionList(Group)
  5. Click Properties.
  6. On the Members page, you can view the list of members in the distribution list (group) selected. The explicit members of a distribution list can be public queues, queue aliases, and other distribution lists. You can also delete elements (members) from the distribution list (group) as follows: click the applicable element (member), click Remove, and then click OK.
  7. To add a public queue to a distribution list (group), do the following:
    • In the console tree, right-click the applicable queue.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • YourOrganizationalUnit (such as Computers or Domain Controllers)
      • YourComputer
      • msmq
      • YourPublicQueue
    • Click Properties.
    • On the Member of page, click Add.
    • On the Select Groups dialog box, in Name, type the name of a distribution list (group) or the names of several distribution lists (groups) separated by semicolons, click OK, and then click OK again. Or click Advanced to search for distribution lists (groups), enter the applicable parameters, click Find Now, select the applicable distribution lists (groups), click OK, click OK again, and then click OK a third time.
  8. To add private queues or URL-named queues to a distribution list (group), do the following:
    • Create an alias for each private queue or URL-named queue that you want to add to the distribution list (group). For information on how to create an alias for a private queue or a URL-named queue, see Related Topics.
    • In the console tree, right-click the distribution list (group) to which you want to add a queue alias or queue aliases.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • Users
      • YourDistributionList(Group)
    • Click Properties.
    • On the Members page, click Add. In the Select Groups dialog box, click Look For, select the Other objects check box, clear the remaining check boxes, and click OK. In Name, type the name of a queue alias or the names of several queue aliases separated by semicolons, click OK, and then click OK again. Or click Advanced to search for queue aliases, enter the applicable parameters, click Find Now, select the queue alias, click OK, click OK again, and then click OK a third time.
  9. To add a queue alias to one or several distribution lists (groups), do the following:
    • In the console tree, right-click the applicable queue alias.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • YourContainer (such as Computers or Domain Controllers)
      • YourAlias
    • Click Properties.
    • On the Member of page, click Add.
    • On the Select Groups dialog box, in Name, type the name of a distribution list (group) or the names of several distribution lists (groups) separated by semicolons, click OK, and then click OK again. Or click Advanced to search for distribution lists (groups), enter the applicable parameters, click Find Now, select the applicable distribution lists (groups), click OK, click OK again, and then click OK a third time.
  10. To add a distribution list (group) as a member of another distribution list (group), do the following:
    • In the console tree, right-click the distribution list (group) that you want to be a new member of another distribution list (group).

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • Users
      • YourDistributionList(Group)
    • Click Properties.
    • On the Member of page, click Add.
    • On the Select Groups dialog box, in Name, type the name of a distribution list (group) or the names of several distribution lists (groups) separated by semicolons, click OK, and then click OK again. Or click Advanced to search for distribution lists (groups), enter the applicable parameters, click Find Now, select the applicable distribution lists (groups), click OK, click OK again, and then click OK a third time.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Message Queuing distribution lists are distribution group objects in Active Directory.
  • The explicit members of distribution lists can be public queues, queue aliases, and other distribution lists, but not private queues or URL-named queues. Private queues and URL-named queues can be included in a distribution list by using queue aliases. For information on how to create an alias for a private queue or a URL-named queue, see Related Topics.

Related Topics


View or change properties of distribution lists

Microsoft Windows Graphic

To view or change properties of distribution lists

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the distribution group.
  4. In the console tree, right-click the applicable distribution list (group).

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • Folder
    • YourDistributionList(Group)
  5. Click Properties.
  6. View or change the distribution list (group) properties as needed.
    7. Property | Tab
Group name | General
Description | General
Group scope | General
Group type | General
Distribution list (group) elements (members) | Members
Folders containing the members in Active Directory | Members
Distribution lists (groups) of which the applicable distribution list (group) is a member | Member of
Administrative permissions | Security

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Message Queuing distribution lists are distribution group objects in Active Directory.
  • The explicit members of distribution lists can be public queues, queue aliases, and other distribution lists, but not private queues or URL-named queues. Private queues and URL-named queues can be included in a distribution list by using queue aliases.

Related Topics


Get a list of distribution lists containing a given element

Microsoft Windows Graphic

To get a list of distribution lists containing a given element

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the distribution group.
  4. In the console tree, do one of the following:
    • Right-click the applicable distribution list (group).

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • Folder
      • YourDistributionList(Group)
    • Right-click the applicable public queue.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • YourOrganizationalUnit (such as Computers or Domain Controllers)
      • YourComputer
      • msmq
      • YourPublicQueue
    • Right-click the applicable queue alias.

      Where?

      • Active Directory Users and Computers
      • YourDomain
      • ContainerForAliases
      • YourAlias
  5. Click Properties.
  6. On the Member of page, you can view the list of distribution lists (groups) of which the applicable object is a member. For information on how to add the object selected to another distribution list (group), see Related Topics. You can remove the applicable object from a distribution list (group) of which it is a member as follows: click the name of the host distribution list (group), and then click Remove.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Message Queuing distribution lists are distribution group objects in Active Directory.
  • The explicit members of distribution lists can be public queues, queue aliases, and other distribution lists, but not private queues or URL-named queues. Private queues and URL-named queues can be included in a distribution list by using queue aliases.

Related Topics


Delete distribution lists

Microsoft Windows Graphic

To delete distribution lists

  1. Open Active Directory Users and Computers.
  2. In the console tree, double-click the domain node.
  3. Click the folder that contains the distribution group.

    4. Where?

    • Active Directory Users and Computers
    • YourDomain
    • Folder
  4. In the details pane, right-click the applicable distribution list (group), and then click Delete on the menu. Alternatively, you can click the applicable distribution list (group), and then press Delete.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • Message Queuing distribution lists are distribution group objects in Active Directory.
  • When a distribution list is deleted, it is automatically removed from all the distribution lists of which it is a member.

Related Topics


Administer Messages for Message Queuing

This section shows you how to:

  • View message properties
  • Set the default lifetime for messages
  • Manage messages on other computers
  • Manage messages using Active Directory Users and Computers


View message properties

Microsoft Windows Graphic

To view message properties

  1. Open Computer Management.
  2. In the console tree, right-click Queue messages (or Journal messages).

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • YourQueueFolder (such as Public Queues or Private Queues)
    • YourQueue
    • Queue messages
      Journal messages
  3. In the details pane, right-click a message, and then click Properties.
  4. Click each tab to view the various message properties and other relevant information.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Set the default lifetime for messages

Microsoft Windows Graphic

To set the default lifetime for messages

  1. Open Active Directory Sites and Services.
  2. On the View menu, click Show Services Node.
  3. In the console tree, right-click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  4. Click Properties.
  5. On the General page, type a new value and select new units as needed.

Notes

  • To open Active Directory Sites and Services, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Sites and Services.
  • Note that the default lifetime for transactional messages is 4 days.
  • The default lifetime of a message is also known as the time-to-reach-queue (TTRQ).

Security

  • For best security practice, it is recommended that messages not be set with an infinite lifetime to ensure tighter control over messages that are traveling through the network. Also, MSMQ can request that a negative acknowledgment message is returned if a timer expires, and Message Queuing sends the appropriate negative acknowledgment message to the administration queue specified by the message.

Related Topics


Manage messages on other computers

Microsoft Windows Graphic

To manage messages on other computers

  1. Open Computer Management.
  2. Right-click Computer Management, and then click Connect to another computer.
  3. In the Select Computer dialog box, select the computer on which you want to manage messages, and then click OK.
  4. Perform the desired task as you would for the local computer.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
Related Topics


Manage messages using Active Directory Users and Computers

Microsoft Windows Graphic

To manage messages using Active Directory Users and Computers

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click the applicable message.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
    • YourQueueFolder (such as Private Queues for a private queue)
    • YourQueue
    • YourMessage
  4. Complete the desired task as you would using Computer Management.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • This method can be used only if the local computer belongs a Windows Server 2003 family or Windows 2000 domain and can contact a domain controller.
Related Topics


Administer Triggers for Message Queuing

This section provides instructions for creating and managing triggers:

  • Create triggers
  • Create and attach rules to triggers
  • View or change properties of triggers and rules for triggers
  • Delete triggers and rules for triggers
  • Change default configuration values for triggers
  • Configure trigger resources for server clusters


Create triggers

Microsoft Windows Graphic

To create triggers

  1. Open Computer Management.
  2. In the console tree, right-click Triggers.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Triggers
  3. Point to New, and then click Trigger.
  4. In Trigger name on the first page of the New Trigger dialog box, type a name for the new trigger.
  5. If you want to specify a user-defined queue as the monitored queue, in Queue path name, type the path name of the queue with which the trigger will be associated in the ComputerName\QueueName syntax, or the .\QueueName syntax for the local computer. (Do not use format names.) Otherwise, click the name of an automatically created queue on your computer.
  6. Click Peeking, Retrieval, or Transactional retrieval to specify the type of message processing.
  7. Click the applicable check box to configure the trigger as enabled or disabled.
  8. Click the applicable check box to configure the trigger as serialized or not serialized, and then click Next.
  9. On the second page of the New Trigger dialog box, to attach an existing rule to the trigger, select a rule in the Rules list, and then click Attach
  10. To remove a rule from a trigger, select a rule in the Attached Rules list, and then click Detach.
  11. To change the order in which rules are tested for the triggers, click the Up and Down buttons.
  12. When you have the list of attached rules that you want, click Finish.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Triggers are not installed by default during Message Queuing installation. For information on installing triggers, see Installing Message Queuing triggers.
  • This procedure can also be performed by opening the New Trigger dialog box from the Triggers folder under any monitored queue in the console tree as follows: right-click Triggers, point to New, and then click Trigger. In this case, the queue automatically becomes the monitored queue.
  • Regardless of where the creation of a trigger is initiated, all the triggers created on the local computer, which is called the trigger set, are listed in the details pane of the Computer Management snap-in when Triggers is selected in the console tree under the Triggers folder. By default, for each trigger, the following is displayed in the details pane:
    • Trigger name
    • Name of the monitored queue
    • Number of rules attached to the trigger
    • Whether the trigger is enabled
    • Whether the trigger is serialized
    • Message processing type
  • Before creating a trigger, verify that the account under which the Message Queuing Triggers service is running has been granted the Peek Message permission and the Receive Message permission for all existing queues that will be associated with triggers having the retrieval or transactional-retrieval processing type. For more information, see Related Topics.
  • After you type the name of a user queue to which the trigger will be associated in Queue path name, the existence of the queue is verified. If a queue with the name typed cannot be found, an error message appears.
  • Triggers can be serialized or nonserialized. A serialized trigger tests the conditions of all the rules associated with it on each message and performs all the applicable actions before moving on to the next message in the order in which the messages arrive. However, the throughput is lower than for nonserialized triggers because the messages are processed one at a time. Nonserialized triggers permit higher throughput but may fail to perform a given operation on the messages in the order in which they arrive. This occurs, for example, when multiple messages are processed simultaneously. If you create multiple triggers for a particular queue and at least one of them is serialized, all the triggers will behave as serialized triggers, even if they are not defined as serialized. Triggers with the transactional-retrieval processing type can only be serialized. If message processing order is significant, it is recommended that you use only a single trigger per queue and enable the serialized option, because the order of trigger firing is random with respect to their GUIDs.
  • By default, the Message Queuing Triggers service runs under the Network Service account. Note that when the Triggers service is running under the Network Service account, it does not interact with the desktop. If this functionality is required, you can configure the Triggers service to run under the Local System account and enable interaction with the desktop in Computer Management. For best security practice, do not change the default account to a less secure account unless absolutely necessary. The Triggers service must run under an account with administrator permissions.
  • Executable files that are invoked by triggers are invoked with the same security privileges as those assigned to the Triggers service.
  • After a trigger has been created, rules can be attached to it. For more information, see Related Topics.
  • When you delete a queue, the triggers associated with that queue are not deleted. If you later re-create a queue of the same name, any existing triggers will be used by this queue. However, this re-created queue will not be monitored by the Message Queuing Triggers service until the computer is restarted, or the associated triggers disabled, and then enabled again. For instructions on setting the enabled or disabled property for a trigger, see View or change properties of triggers and rules for triggers.

Related Topics


Create and attach rules to triggers

Microsoft Windows Graphic

To create and attach rules to triggers

  1. Open Computer Management.
  2. In the console tree, right-click Rules.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Triggers
    • Rules
  3. Point to New, and then click Rule.
  4. On the first page of the New Rule dialog box, in Rule name, type a name for the new rule, and in Rule description, type an optional description.
  5. Click Next.
  6. In New condition, enter a condition by selecting the initial string in the list box, typing the applicable final string in the Filter value/string text box below, and clicking Add. The complete condition then appears in Condition list. You can create additional conditions by repeating this operation.
  7. When you finish creating the conditions that you want to create, click Next.
  8. To specify whether the trigger will invoke a stand-alone executable or a COM component (the default), click the applicable button.
  9. To specify that the trigger invoke a COM component, in COM component invocation, select Invoke COM component. In Component ProgID, type the ID of the COM component, and in Method name, type the name of the method.
  10. To specify that the trigger invoke a stand-alone executable, in Standalone executable invocation, select Invoke standalone executable(EXE). In Executable path, type the full path of the executable file.
  11. To add parameters for either a COM component or a stand-alone executable, click Parameters. Select a parameter in the Parameter list box. If the parameter is a numeric literal or a string literal, type its value in Literal value. Click Add to add the parameter to the Invocation parameters list. Repeat this operation for each parameter that you want to add, and use the Up and Down buttons to change the order in which the parameters are transferred to the program. Click OK, and then click Finish.
  12. To attach existing rules to a trigger, do the following:
    • In the console tree, click Triggers.

      Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • Triggers

      Or, click Triggers under the applicable monitored queue.

      Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • YourQueueFolder (Public Queues, Private Queues, or System Queues
      • YourMonitoredQueue
      • Triggers
    • In the details pane, right-click the applicable trigger, click Properties, and then click the Attached Rules tab. Select the rule you want to attach to the trigger from the Rules list, and then click Attach to move it to the Attached Rules list. Then click OK.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • All the rules created on the local computer, which is called the rule set, are listed in the details pane of the Computer Management snap-in when Rules is selected in the console tree.
  • A rule is composed of one or more conditions and an action that is executed when the conditions are true. Each condition is applied to a message when it arrives at the monitored queue, and the result is either true or false. After being created, the conditions applied to a particular rule are listed in Condition list on the second page of the New Rule dialog box as well as on the Conditions page of the Properties dialog box for that rule. A condition can be eliminated from this list by selecting it and clicking Remove. Multiple conditions must all be true for an action to be executed. If no condition is specified, a true value will always be returned. This is useful when you want a trigger to fire unconditionally every time a message arrives at the monitored queue.
  • The actions performed when a condition is true are expressed either in the form of an executable file and parameters (arguments) or in the form of a COM component, a method, and parameters. You can also invoke other types of files by making them parameters of an .exe file. For example, you can invoke an .msc file by specifying mmc.exe as the executable file and including the full path of the .msc file as an invocation parameter of the string literal type. You can specify one or more parameters to be passed per action. The supported parameters are listed in the list box on the Invocation Parameters dialog box.
  • If your trigger invokes an executable file with command-line arguments, these arguments can be included as parameters of the string literal type. However, you must add a separate parameter for each command-line argument.
  • You can attach multiple rules to a trigger. In this case, the rules are executed in the order in which they are displayed on the Attached Rules page of the Properties dialog box for that rule. You can change the priority (order of execution) of the rules in the list. To do so, use the Up and Down buttons on this page to change the order of priority of each rule as needed to give the rule a higher or lower priority, respectively. You can also detach rules on this page by selecting each rule that you want to detach and clicking Detach. For more information, see Related Topics.

Related Topics


View or change properties of triggers and rules for triggers

Microsoft Windows Graphic

To view or change properties of triggers and rules for triggers

  1. Open Computer Management.
  2. In the console tree, click Triggers or Rules, whichever is applicable.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Triggers
    • Triggers (or Rules)
  3. In the details pane, right-click the applicable trigger or rule, and then click Properties.
  4. View or change trigger properties as needed. Note that trigger names cannot be changed.
    5. Trigger Property | Tab
Trigger name (view only) | General
Monitored queue (path name for a user queue) | General
Message processing type | General
Enabled or disabled | General
Serialized or nonserialized | General
Rules attached to the trigger | Attached Rules
Rules available for the trigger | Attached Rules

    Or, view or change rule properties as needed. Note that rule names cannot be changed.

    Rule property | Tab
Rule name (view only) | General
Rule description | General
Conditions applied to the rule | Rule Condition
Whether the rule launches a stand-alone executable or a COM component | Rule Action
Path of a stand-alone executable | Rule Action
COM component ProgID | Rule Action
Method chosen for a COM component | Rule Action
Parameters used and their order. For types of parameters, see Trigger rules. | Invocation Parameters

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • Triggers are not installed by default during Message Queuing installation. For information on installing triggers, see Installing Message Queuing triggers.
  • The Properties dialog box for a specific trigger has General and Attached Rules tabs. The Properties dialog box for a specific rule has General, Rule Condition, and Rule Action tabs, and there is an Invocation Parameters dialog box, which can be accessed from the Rule Action page.
  • The monitored queue of an existing trigger cannot be changed.
  • When you delete a queue, the triggers associated with that queue are not deleted. If you later re-create a queue of the same name, any existing triggers will be used by this queue. However, this re-created queue will not be monitored by the Message Queuing Triggers service until the computer is restarted, or the associated triggers disabled, and then enabled again.
  • A rule consists of one or more conditions and an action that is executed when the conditions are true. Each condition is applied to a message when it arrives at the monitored queue, and the result is either true or false. The conditions applied to a particular rule are listed in Condition list on the Rule Condition page of the Properties dialog box for that rule. A condition can be eliminated from this list by selecting it and clicking Remove. New conditions are composed by selecting a supported initial string in the New condition list box and typing a concluding string in the text box below it. Multiple conditions must all be true for an action to be executed. If no condition is specified, a true value will always be returned. This is useful when you want a trigger to fire unconditionally every time a message arrives at the monitored queue.
  • The actions performed when the conditions are true are expressed either in the form of an executable file and parameters (arguments) or in the form of a COM component, method, and parameters. You can specify one or more arguments to be passed per action. The supported parameters are listed in the list box on the Invocation Parameters dialog box, which can be accessed by clicking Parameters on the Rule Action page of the Properties dialog box for the particular rule.
  • The rules displayed on the Attached Rules tab are disabled by default, and you must attach them to the trigger to enable them. You can attach multiple rules to a trigger. In this case, the rules are executed in the order in which they are displayed in the Attached Rules list. You can change the priority (order of execution) of the rules in the list. To do so, use the Up and Down buttons on this page to give the rule a higher or lower priority, respectively. You can also detach rules on this page by selecting each rule that you want to detach and clicking Detach. For more information, see Related Topics.
  • All triggers and rules for triggers created on the local computer are displayed in the details pane of the Computer Management snap-in when the applicable folder is selected in the console tree.

Related Topics


Delete triggers and rules for triggers

Microsoft Windows Graphic

To delete triggers and rules for triggers

  1. Open Computer Management.
  2. In the console tree, click Triggers or Rules, whichever is applicable.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Triggers
    • Triggers (or Rules)
  3. In the details pane, right-click the applicable trigger or rule, and then click Delete. Alternatively, you can click the applicable trigger or rule, and then press the DELETE key.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • All triggers and rules for triggers created on the local computer are displayed in the Computer Management snap-in.
  • To detach rules from a trigger without deleting them, right-click the applicable trigger in the details pane, and then click Properties. Click the Attached Rules tab, and then select each rule that you want to detach and click Detach. For more information, see Related Topics.

Related Topics


Change default configuration values for triggers

Microsoft Windows Graphic

To change default configuration values for triggers

  1. Open Computer Management.
  2. In the console tree, click to expand Message Queuing, and then right-click Triggers.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Triggers
  3. Click Properties, and then change the values in Initial number of threads, Max number of threads, and Default message body size as needed.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • All configuration information as well as trigger and rule definitions are stored in the local registry.
  • The Default message body value is the size of the buffer that the Message Queuing Triggers service will allocate for an incoming message. It is recommended that this value be set equal to a size that will accommodate 90% of all messages that are expected to arrive in monitored queues. If this value is set too small, it will force the service to reallocate these buffers for every message. If it is set too large, an excessive amount of memory will be allocated.

Related Topics


Configure trigger resources for server clusters

Microsoft Windows Graphic

To configure trigger resources for server clusters

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.
  2. To create a Message Queuing Triggers resource:
    • When the Open Connection to Cluster dialog box appears, in the Cluster or server name list box, select the applicable cluster or server. (If you select a server, the name of the cluster to which it belongs will appear in the console tree.)
    • In the console tree, right-click the cluster group to which you want the Message Queuing Triggers resource to belong.

      Where?

      • ClusterName
      • Groups
      • YourGroup
    • On the File menu, point to New, and then click Resource.
    • In the New Resource Wizard, type the applicable information in Name and Description, select Message Queuing Triggers in the Resource type list box, and then click Next.
    • On the Possible Owners page, select the set of possible owners to match that of the Message Queuing resource in the same group, and then click Next.
    • On the Dependencies page, in Available resources, select the name of the Message Queuing resource in the group, and then click Add.
    • Select the name of the Network Name resource in the group, click Add, and then click Finish.
  3. If Message Queuing has the Active Directory Integration component installed, enable Kerberos authentication for the Network Name resource on which the Message Queuing resources depend:
    • Bring the Network Name resource offline as follows: In the console tree for the cluster group, right-click the Network Name resource in the details pane, and then click Take Offline.
    • Right-click the Network Name resource again, and then click Properties.
    • On the Parameters tab, select the Enable Kerberos Authentication check box to enable authentication. The default setting is that Kerberos authentication is not enabled.
    • Bring the Network Name resource online as follows: In the console tree for the cluster group, right-click the Network Name resources in the details pane, and then click Bring Online.

    Caution

    • Other resources in the group may also depend on the Network Name resource. These will be taken offline automatically when the Network Name resource goes offline. When you bring the Network Name resource online, bring these other resources online too.
  4. To bring the Message Queuing Triggers resource online, in the console tree, click the Resources folder. In the details pane, click the Message Queuing Triggers resource. On the File menu, click Bring Online.
  5. To manage the Message Queuing Triggers resource from Computer Management, create a Generic Application resource in the same cluster group, and configure it to launch the Computer Management MMC snap-in:
    • In the Cluster Administrator console tree, click the cluster group to which the Message Queuing Triggers resource belongs.
    • On the File menu, point to New, and then click Resource. The New Resource Wizard launches.
    • In the New Resource Wizard, type Computer Management in the Name text box and select Generic Application in the Resource type list box. Then, click Next.
    • On the Possible Owners page, select possible owners to match those selected for the Message Queuing Triggers resource. Then, click Next.
    • On the Dependencies page, under Available resources, select the name of the Network Name resource in the group and click Add, and then select the Message Queuing Triggers resource previously created and click Add. Then, click Next.
    • On the Generic Application Parameters page, in Command line, type mmc compmgmt.msc
    • In Current directory, type %windir%/system32.
    • Select the Allow application to interact with desktop check box, select the Use Network Name for computer name check box, click Next, and then click Finish.
    • Bring the resource online using the procedure above. The Computer Management snap-in will appear on the desktop of the computer node that owns the resource.

Notes

  • This task is performed on a computer that is running XOX or XOX as part of a server cluster, has Message Queuing with Triggers already installed, and has a Message Queuing resource already configured.
  • Errors occurring during the performance of this task are recorded in a Windows event log. For example, a "device not ready" error indicates that Message Queuing was not installed on the node.
  • Once created, do not rename resources for Message Queuing Triggers.
  • The trigger and rule definitions for the cluster resource created are stored in subkeys in the local Windows registry under a special key. The Message Queuing Triggers resource is checkpointed with this registry key and the subkeys under it so that when the resource is moved to a new node (during failover, for example), the required keys are propagated to the local registry on the new node. After failover, the Triggers service can thus continue to process the incoming messages in each monitored queue and invoke the applicable stand-alone executable or COM component according to the rules defined.
  • You can use the Generic Application resource created with a dependency on the Message Queuing resource to manage Triggers in the applicable resource group from a local Computer Management snap-in. For more information on these resources, see Related Topics.

Related Topics


Monitor and Test Message Queuing

This section shows you how to:

  • View Message Queuing events
  • View external transactions
  • Track Message Queuing service counters
  • Track Message Queuing queue counters
  • Enable route tracking and test messages
  • Track message routing
  • Send test messages
  • Test connectivity using MQPing


View Message Queuing events

Microsoft Windows Graphic

To view Message Queuing events

  1. Open Event Viewer.
  2. In the console tree, click Application.
  3. In the details pane, click the Source column to gather the MSMQ and MSMQTriggers events together.
  4. Scroll until you see MSMQ and MSMQTriggers events listed in the column.

Notes

  • To open Event Viewer, click Start, point to All Programs, point to Administrative Tools, and then click Event Viewer.
  • When viewing events in Event Viewer, you can sort, filter, and search for events, based on event properties.
  • Message Queuing service events can be located with the same procedure, by clicking System in the console tree, instead of Application.

Related Topics


View external transactions

Microsoft Windows Graphic

To view external transactions

  1. Open Component Services.
  2. In the console tree, double-click Component Services, double-click Computers, double-click My Computer, and then double-click Distributed Transaction Coordinator.
  3. To view the status of external transactions, double-click Transaction List.
  4. To view the statistics of external transactions, double-click Transaction Statistics.

Notes

  • To open the Component Services snap-in, click Start, point to All Programs, point to Administrative Tools, and then click Component Services.
  • The Microsoft Distributed Transaction Coordinator (DTC) must be running to implement external transactions.

Related Topics


Track Message Queuing service counters

Microsoft Windows Graphic

To track Message Queuing service counters

  1. Open System Monitor.
  2. In the details pane, click the Add (+) button on the toolbar.
  3. In the Add Counters dialog box, click Use local computer counters to view counters on the computer that you are using. Or, to view counters for another computer, click Select counters from computer, and then click the applicable computer.
  4. In Performance object, click the arrow that opens the list, and then select MSMQ Service.
  5. Click All counters. Or, click Select counters from list, and then select the counters that you want to monitor.
  6. Click Add.
  7. To view the definition of a counter, select a counter name, and then click Explain.
  8. Click Close.

    The monitor graphs appear in the details pane.

Notes

  • To open System Monitor, click Start, point to All Programs, point to Administrative Tools, and then click Performance.
  • To delete a counter from those tracked, in System Monitor, choose the required counter in the details pane, and then click the Delete (X) button on the toolbar.
  • You can also use this procedure to track other categories of Message Queuing performance objects, including MSMQ Session, MSMQ Incoming HTTP Traffic, MSMQ Outgoing HTTP Session, MSMQ Outgoing Multicast Session, and MSMQ Incoming Multicast Session objects.
  • You can view performance data from System Monitor in Chart, Report, or Histogram views, and you can log the performance data to a file. For more information on System Monitor, see "System Monitor overview" in the Windows Help and Support Center.
  • For more information on monitoring Message Queuing, see Related Topics.

Related Topics


Track Message Queuing queue counters

Microsoft Windows Graphic

To track Message Queuing queue counters

  1. Open System Monitor.
  2. In the details pane, click the Add (+) button on the toolbar.
  3. In the Add Counters dialog box, click Use local computer counters to view counters on the computer that you are using. Or, to view counters for another computer, click Select counters from computer, and then click the applicable computer.
  4. In Performance object, click the arrow that opens the list, and then select MSMQ Queue.
  5. Click All counters. Or, click Select counters from list, and then select the counters that you want to monitor.
  6. Click All instances. Or, click Select instances from list, and then select the instances you want to monitor.
  7. Click Add.
  8. To view the definition of a counter, select a counter name, and then click Explain.
  9. Click Close.

    10. The monitor graph appears in the details pane.

Notes

  • To open System Monitor, click Start, point to All Programs, point to Administrative Tools, and then click Performance.
  • To delete a counter from those tracked, in System Monitor, choose the required counter in the details pane, and then click the Delete (X) button on the toolbar.
  • You can view performance data from System Monitor in Chart, Report, or Histogram views, and you can log the performance data to a file. For more information on System Monitor, see "System Monitor overview" in the Windows Help and Support Center.
  • For more information on monitoring Message Queuing, see Related Topics.

Related Topics


Enable route tracking and test messages

Microsoft Windows Graphic

To enable route tracking and test messages

  1. Click Start, click Run, type regedit, and then click OK.
  2. Click to expand My Computer, click to expand HKEY_LOCAL_MACHINE, click to expand SOFTWARE, and then click to expand Microsoft.
  3. Click to expand MSMQ, click to expand Parameters, click Security, and then add the EnableReportMessages key.
  4. To enable the sending of test messages, enter a value of 1 in Value data.
  5. To disable the sending of test messages, enter a value of 0 in Value data. This is the default value.
  6. Click OK to save the value. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Notes

  • For instructions on sending test messages after the feature is enabled, see Send test messages.
  • By enabling this feature, you also enable the message route tracking feature. For more details, see Track message routing.

Related Topics


Track message routing

Microsoft Windows Graphic

To track message routing

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Properties.
  5. Click the Diagnostics tab, and then click Define Tracking. The Message Route Tracking dialog box appears.
  6. In Path name of report queue, click the applicable report queue. Or, to create a new queue for report messages, click New and type the queue path name (such as MyComputer\MyQueue or .\MyQueue).
  7. Click Track all messages or click Track only test message.

Notes

  • The tracking message route feature is disabled by default after installing Message Queuing. For instructions on turning on this feature, see Enable route tracking and test messages.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • After sending test messages is enabled, you can also send a test message from the Computer Management snap-in. To do this, open Computer Management, click Services and Applications, right-click Message Queuing, and then click Properties. On the Diagnostics tab, click Define Tracking.
  • Any public queue can serve as a report queue. For information on how to create a new queue for report messages before performing this procedure, see Related Topics.
  • If you click Track all messages and if the sending application has set the message route tracking flag and the destination queue is located on another computer, all messages sent by such an application from the source computer have their routes tracked. All report messages sent along the route of each message are then sent to the report queue on the source computer. Tracking occurs both for messages sent by the source computer and for messages routed through a Message Queuing server with routing enabled.
  • If you click Track only test message, report messages are sent only for test messages. For information on how to send a test message, see Related Topics.
  • Messages sent locally to a queue on the same computer are not tracked.
  • Messages sent over HTTP/HTTPS transport and messages sent to multiple destinations using IP multicast, distribution lists, or multiple-element format names cannot be tracked in the current version of Message Queuing.

Related Topics


Send test messages

Microsoft Windows Graphic

To send test messages

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourSourceComputer
    • msmq
  4. Click Properties.
  5. On the Diagnostics page, click Send Test.
  6. In Destination queue, click the applicable test queue, and then click Send. Or, to create a new queue to send test messages to, click New Queue, type the full queue path (such as DestinationComputer\DestinationQueue), click OK, and then click Send.
  7. Click Close to close the dialog box.

Notes

  • The ability to send a test message is disabled by default after installing Message Queuing. For instructions on turning on this feature, see Enable route tracking and test messages.
  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • After sending test messages is enabled, you can also send a test message from the Computer Management snap-in. To do this, open Computer Management, click Services and Applications, right-click Message Queuing, and then click Properties. On the Diagnostics tab, click Send Test.
  • The computer whose msmq object you select is the source computer used to send a test message.
  • You can send test messages only to test queues. All test queues are public queues and have a queue type ID of {55EE8F33-CCE9-11CF-B108-0020AFD61CE9}.
  • You cannot use a transactional queue as a test queue. Only transactional messages can be sent to transactional queues, and test messages are not transactional. Similarly, you cannot change the type ID of a queue requiring authentication to that of a test queue and send test messages to the queue, because the messages will not be delivered (unless the queue is located on the source computer).
  • Because all test messages are sent with the message route tracking flag set, if the source computer has message route tracking enabled and if the test queue is located on another computer, the route of such test messages is tracked and report messages are sent to the report queue on the source computer. For information on how message route tracking is enabled, see Related Topics.
  • If you create a queue and immediately send a test message to it, the receiving computer may not receive the test message because of replication delays. In this case, wait several minutes and send the test message again.
  • You can verify that the sent test messages arrived at the destination queue by viewing the properties of the messages in the destination queue or by viewing the contents of the report queue on the source computer if message route tracking is enabled. For information on how to view the properties of messages in a particular queue, see Related Topics.

Related Topics


Test connectivity using MQPing

Microsoft Windows Graphic

To test connectivity using MQPing

  1. Open Active Directory Users and Computers.
  2. On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features.
  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • YourDomain
    • YourOrganizationalUnit (such as Computers or Domain Controllers)
    • YourComputer
    • msmq
  4. Click Send MQPing message.

Notes

  • To open Active Directory Users and Computers, click Start, point to All Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
  • You can also send an MQPing message as follows: right-click msmq, click Properties, click the Diagnostics tab, and then click MQPing.
  • When you send an MQPing message to a computer, Message Queuing waits 45 seconds to receive a response from the computer being tested. A message appears, notifying you whether MQPing succeeded or failed. You may need to send several MQPing messages to determine whether or not a computer is connected.
  • You can also send an MQPing message from the Computer Management snap-in. To do this, open Computer Management, click Services and Applications, right-click Message Queuing, and then click Properties. On the Diagnostics tab, click MQPing.

Related Topics


Concepts

This section is designed to help you understand Message Queuing concepts, and provide background information about installing and administering a Message Queuing network:

  • For an overview of Message Queuing features, Message Queuing servers and clients, and Message Queuing with Active Directory, see Introducing Message Queuing.
  • For background information about Message Queuing features, see Understanding Message Queuing.
  • For information on Message Queuing administration, see Administering Message Queuing.


Introducing Message Queuing

This section provides you with an overview of Message Queuing and a summary of Message Queuing features. Information about Message Queuing computers (servers and clients) and Message Queuing objects in Active Directory is also provided. For details, see the following links:

  • For a general introduction to Message Queuing, see Message Queuing overview.
  • For information about new and legacy features for Message Queuing 3.0, see Message Queuing features.
  • For information on Message Queuing and Active Directory, see Message Queuing and Active Directory.
  • For an overview of Message Queuing in clusters, see Distributing Message Queuing in a network.
  • To learn about the different ways that Message Queuing can be deployed on computers, including information about Message Queuing server, and independent and dependent clients, see Message Queuing Computers.


Message Queuing overview

Message Queuing (also known as MSMQ) is a messaging infrastructure and a development tool for creating distributed messaging applications for Microsoft Windows operating systems. Applications developed for Message Queuing send messages to queues, which are temporary storage locations, from which messages can proceed to their final destination as conditions permit. Such applications can communicate across heterogeneous networks and can send messages between computers that may be temporarily unable to connect to one another. Message Queuing provides guaranteed message delivery, efficient routing, security, support for sending messages within transactions, and priority-based messaging. Software products with these features are often referred to in the industry as message-queuing software, store and forward software, or message-oriented middleware.

Message Queuing is not a database and does not provide database functionality, but can be used together with a database, for example for message storage.

With Message Queuing, end users can communicate across networks and computers that may be offline, regardless of the current state of the network and computers. System administrators can use Message Queuing to efficiently manage large, complex networks of computers and message queues. Through Message Queuing, MIS decision makers get more reliable communication and more efficient use of network resources. Developers can focus on business logic instead of networking issues because Message Queuing effectively provides guaranteed network communication.

The current version of Message Queuing introduces a number of new features. For more details, see Message Queuing features. There are also a number of terminology and administrative changes from previous versions. If you are upgrading from a previous version, see the Upgrade overview for a list of changes.

Message Queuing naming

In its earliest versions (for Windows NT 4.0, Windows 95, and Windows 98), Message Queuing was called Microsoft Message Queuing Server, or MSMQ 1.0. Similarly, the version for Windows 2000 is officially called Message Queuing 2.0 and is often referred to as MSMQ 2.0 in external literature and other external sources.

The current version of Message Queuing, which is based on the original MSMQ technology and conceptions and is supplemented with numerous new features, is officially called Message Queuing 3.0. This documentation uses the current official name Message Queuing as a generic term for all the versions. This is not intended to discourage the use of the already familiar term MSMQ. The term MSMQ is used widely by veteran users and in external sources, and it is recommended that all users be familiar with both terms.


Message Queuing features

Following is a summary of the major features of Message Queuing 3.0:

  • Delivering messages over HTTP transport. New in Message Queuing 3.0, SRMP (SOAP Reliable Messaging Protocol), an XML-based messaging protocol, has been developed for delivering high Quality of Service (QoS) messages. The direct, public, and private format names of administration and response queues can be included in messages sent over HTTP transport. Similarly, the names of administration and response queues in HTTP format can be included in messages sent over ordinary (non-HTTP) transport. For more information about these features, see HTTP/HTTPS messages. For more information on format names, see Queue names.
  • Triggers. Now a component in Message Queuing 3.0, rather than an add-on module. Triggers provides a mechanism that associates the arrival of each incoming message at a queue with a response that depends on the contents of the message and may invoke either a COM component or a stand-alone executable program. Business rules can be defined and invoked in response to such messages without any additional programming. For more information about this feature, see Triggers.
  • Sending messages to multiple destinations. New in Message Queuing 3.0, clients are able to send the same message to multiple recipient queues. Lists of destination queues can be specified explicitly by means of distribution group objects (distribution lists) in Active Directory as well as in the form of multiple-element format names. Support for ensuring that messages sent to distribution lists and multiple-element format names will reach queues on downlevel computers is provided. In addition, message delivery to IP multicast destinations using the PGM protocol is supported. For more information about these features, see Multiple Destination Messaging.
  • Message lookup. Message Queuing 3.0 now provides a way to peek at or retrieve a specific message without using cursors to navigate through the queue until the message sought is located. This functionality is based on a 64-bit lookup identifier that is assigned to each message when it is placed in a destination queue. For more information, see Managing messages.
  • Active Directory Integration. Message Queuing 3.0 improves integration with, and extension of, the Active Directory service to store all configuration, security, and status information. Message Queuing clients now use the Lightweight Directory Access Protocol (LDAP) to access domain controllers and global catalog servers for Message Queuing-specific information in Active Directory directly without assistance from a Message Queuing server on a domain controller.
  • Microsoft Management Console (MMC) support. From Message Queuing 3.0, Message Queuing is now administered more completely using snap-ins hosted in an MMC console. Administrative tasks formerly performed in Control Panel are now performed in snap-ins. For more information, see New ways to do familiar tasks.
  • Workgroup support. Message Queuing can be installed in workgroup mode on computers belonging to a Windows Server 2003 workgroup, rather than to a domain. In addition, a computer on which Message Queuing is installed in a workgroup can later join a domain, and then separate from the domain. For more information about belonging to a workgroup or a domain, see Deploying in a domain environment and Deploying in workgroup mode.
  • Active/active cluster support. Message Queuing now fully supports the active/active paradigm in a server cluster, which means that Message Queuing can run on all nodes in a server cluster simultaneously. Message Queuing triggers are also integrated with active/active cluster support. For more information on the active/active model in server clusters, see Distributing Message Queuing in a network.
  • Windows CE support. A special version of a Message Queuing client is preinstalled on handheld and palm-sized computers running the Windows CE 3.0 (or later) operating system. Windows CE also now supports the Message Queuing SRMP protocol, for HTTP messaging.
  • Message backup and restore. Message storage files, log files, transaction log files, and registry settings can be backed up and restored in case of computer failure. For more information, see Backing up and restoring messages.
  • Message prioritization. Message prioritization allows urgent or important messages to be sent before less important messages, so you can guarantee adequate response time for critical applications at the expense of less important applications. For more information on sending messages with different priorities, see Message priority.
  • Guaranteed message delivery. Messages can be stored on a disk-based queue, and then later forwarded to provide guaranteed delivery.
  • Sending messages within transactions. Using transactional capabilities, you can couple several related actions in a single transaction, ensure messages are delivered in order, ensure messages are delivered only once, and confirm that messages were successfully retrieved from the destination queue. For more information on sending messages within transactions, see Transactional messaging.
  • Dynamic queue creation. You can create queues or change queue properties on the fly without affecting messaging applications.
  • Message routing. Message Queuing provides message routing based on the physical topology of the network, session concentration needs, and transport connectivity. Session concentration facilitates the efficient usage of slow communication links. For more information on this subject, see Routing with Message Queuing servers.
  • Cross-platform integration. Message Queuing can be used across a wide variety of hardware platforms using connectivity products provided by other vendors. For more information on messaging with different platforms, see Cross-Platform Messaging.

These features make Message Queuing ideal for the implementation of semi-independent client/server systems (such as order entry, accounting, and inventory applications), batch processing, queue-based client/server systems (first-come, first-served resource access), and for migration from legacy systems.


Message Queuing and Active Directory

In a domain environment, one or more Message Queuing objects are created in Active Directory during setup for all the types of Message Queuing computers except dependent clients. These objects store various information associated with Message Queuing. The access of users to Message Queuing objects is controlled by assigning security descriptors to the objects. A security descriptor lists the users and groups that are granted or denied access to an object and the specific permissions assigned to those users and groups. For more information on the control of access to Message Queuing objects, see Access control for Message Queuing.

Under certain conditions, the name of an object can be changed by the directory service. This can occur if multiple objects with the same name are created simultaneously on different domain controllers. For information on how Active Directory handles object naming and conflicts, see Object names, in the Active Directory online Help file.

The following table lists those objects that are created by Message Queuing by default for each type of Message Queuing computer and that are displayed in the MMC snap-ins. For general information about MMC and snap-ins, see Microsoft Management Console.

Message Queuing computer | Object name | Object class
Message Queuing server without directory service functionality or routing services on a domain controller | msmq | MSMQ-Configuration
Message Queuing server with directory service functionality on a domain controller | msmq; MSMQ-Settings | MSMQ-Configuration; MSMQ-Settings
Message Queuing server with routing services | msmq; MSMQ-Settings | MSMQ-Configuration; MSMQ-Settings
Message Queuing server on a nondomain controller | msmq | MSMQ-Configuration
Independent client | msmq | MSMQ-Configuration
Dependent client | none | not applicable

When you manually create an object in Active Directory, you are prompted to specify the minimal information needed to establish the object in Active Directory. Each object has many more properties (attributes) that can be set. After an object is created, the values of many of these additional attributes can be viewed and modified in the Properties dialog box.

In addition, some information for Message Queuing is also stored in Active Directory in non-Message Queuing objects. Specifically, the User object contains information on user certificates, the applicable computer object (above the msmq object) contains certificate information, information related to foreign sites (for cross-platform messaging) is contained in the Sites object, and distribution lists are defined as distribution group objects.

For advanced information on object attributes, see the Active Directory topic in the Microsoft Platform Software Development Kit (SDK). To access the Message Queuing SDK on the Web, refer to the MSDN Library Web site (http://msdn.microsoft.com/library/default.asp).


Distributing Message Queuing in a network

There are several techniques that you can employ to make a Message Queuing solution highly available to users in a network, and more scaleable.

Implementing Message Queuing in clusters

One solution might be to implement the Message Queuing service in clusters. Message Queuing triggers can also be implemented in a cluster. A cluster is a set of computers, known as nodes or hosts, that work together under a common identity to provide a service. All clusters provide load balancing, increased availability, and scalability, but it is important to distinguish the two main cluster solutions. The first, Network Load Balancing, is intended primarily to load balance incoming TCP/IP traffic. Network Load Balancing clusters distribute client connections over multiple servers, providing scalability and high availability for client requests for services and applications, but they do not have failover capabilities. For more information, see Message Queuing in Network Load Balancing clusters.

The second cluster type, a server cluster, is intended primarily to provide failover service from one computer to another. The computers participating in this solution form a different type of cluster. The Network Load Balancing cluster would most commonly be running Web server applications. In contrast, a server cluster would most commonly be running database applications (when used in conjunction with Network Load Balancing). A server cluster appears to network clients as a single, highly available system. For more information, see Message Queuing in Server Clusters.

Network Load Balancing and the Cluster service can not both be active on the same computer, but by joining the two cluster solutions together to function in a complementary fashion, an overall clustering scheme can be created.

Web farms

To increase the availability and scalability of Web server resources, a Web farm is often deployed as a collection of independent servers, to which all HTTP incoming requests are directed. Network Load Balancing clusters, network address translation (NAT), and DNS round robin are some of the methods typically used to deploy Web farm capability.

DNS round-robin distribution

Microsoft DNS server supports a process referred to as round-robin distribution, a common session-based load balancing technique that balances the number of clients connecting to an Internet site supported by multiple servers. Round-robin distribution is specified by RFC 1794. With DNS round-robin, a single logical DNS name (such as www.microsoft.com) maps to several IP addresses. When a request is made to resolve the DNS name, the DNS server sends back one of the addresses from the list. Each time a request is made for this DNS name, the DNS server rotates the addresses in round-robin fashion to distribute the set of users across a set of servers. Thus, different users requesting the same DNS name are given different IP addresses to balance the load.

This technique distributes incoming requests evenly among the available IP addresses but does not fully balance the load because it is not interactive. This is because the DNS server does not monitor the loading of each IP address nor does it check whether a particular server is currently running. Round-robin distribution can be a useful starting point for small groups of servers. If you are using round-robin distribution, closely monitor your servers so that you can quickly remove any failed machines from the distribution list.

Network address translation

Network address translation (NAT) is a protocol that allows a network with private addresses to access information on the Internet through an IP translation process. NAT can be used to configure a small network to share a single connection to the Internet.


Message Queuing Computers

This section provides information about different ways in which Message Queuing can be configured on a computer. For details, see the following links:

  • For information on the functionality provided by configuring a computer as a Message Queuing server, see Message Queuing servers.
  • For information on the functionality and advantages of deploying independent clients, see Independent clients.
  • For information on dependent client requirements and considerations, see Dependent clients.

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed on it. The term Message Queuing client can refer to either an independent client, or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed. Such computers are referred to as having independent client functionality or dependent client functionality.


Message Queuing servers

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed on it. The term Message Queuing client can refer to either an independent client, or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality, or dependent client functionality.

Message Queuing servers also provide the following features:

  • Directory access for all client computers in the Windows Server 2003 family domain or Windows 2000 domain that are running Message Queuing on Windows NT 4.0, Windows 98, or Windows 95 computers.
  • Support for dependent clients.
  • Routing capabilities.

Directory access

Message Queuing servers enable client computers running MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers, and Message Queuing 2.0 clients running on Windows 2000 computers, to view and change information listed in the Active Directory directory service. To do this, the Message Queuing directory service (Downlevel Client Support) must be installed on a Windows Server 2003 family domain controller. For more information, see Installation requirements and restrictions.

Message Queuing independent clients running on Windows Server 2003 family computers can access Active Directory directly without the aid of a Message Queuing server.

Routing capability

Message Queuing servers installed with routing services enabled provide message routing and intermediate store-and-forward message queuing. Such Message Queuing servers can route messages within a site or between different sites when there is no direct connectivity between client computers. Message Queuing servers that provide message routing functions within the same site are called in-routing servers (InRS) or out-routing servers (OutRS). Intersite connectivity is defined by a routing link. A server through which the message traffic from one site to another can be configured to pass in a routing link is called a site gate. A site gate can belong to either or both of the sites connected by a routing link. A routing link can be configured with any number of site gates or no site gate. For more information, see Routing with Message Queuing servers.

For information on sites, see Sites.

Dependent client support

Every dependent client in your network needs a supporting server, which can be any Message Queuing server with or without routing enabled. By default, following installation, Message Queuing servers are not enabled to support dependent clients. For instructions on enabling a Message Queuing server to act as a supporting server, see Enable a supporting server.


Independent clients

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed. The term Message Queuing client can refer to either an independent client, or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality, or dependent client functionality.

Computers defined as running with independent client functionality do not have the following features:

  • They do not have the Routing component enabled, and thus do not have the message routing capabilities of a Message Queuing server with this component.
  • They do not have the Downlevel Client Support component enabled, and thus cannot provide Active Directory access for MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers, or MSMQ 2.0 clients running on Windows 2000.

Message Queuing computers configured with independent client functionality run the Message Queuing service, host queues, send and receive messages, and can operate while disconnected from the network. They do not require synchronous access to a Message Queuing server to send or receive messages, or to query Active Directory. However, if you choose to install an independent client in a workgroup environment or any other environment that does not provide a directory service, such as Active Directory, direct connectivity is required to send messages. Any Windows Server 2003 family computer running Message Queuing and operating in domain mode, including independent clients, can act as a supporting server for dependent clients.

If an independent client is disconnected from the network, it can continue to generate messages destined for other computers. The independent client stores these messages locally and automatically sends them as soon as the network connection is reestablished.

Independent client advantages

The advantages of deploying independent clients in your organization are as follows:

  • They are not dependent on a Message Queuing server to send or receive messages, and synchronous communications with a Message Queuing server are not required.
  • The messaging load can be distributed across several Message Queuing servers by configuring independent clients to use specific Message Queuing servers (in-routing servers and out-routing servers).
  • They support mobility; independent clients can move from site to site.

Mobile usage

Mobile independent clients, such as those installed on laptop computers, can send and receive messages when they move around. When an independent client connects to a new Windows Server 2003 family site, it automatically detects the domain controllers in its new domain and queries the directory service to determine the new site in which it resides. After the new site is established, all messages that were sent to the client while it was disconnected from the network are automatically rerouted from the previous site to the new site. Note that mobile users that run Message Queuing applications while disconnected from the network can place an additional load on the network. This happens when they attempt to send or receive a large number of messages when they reconnect to the network. This temporary load can be transferred to additional Message Queuing servers to prevent reduced performance.

A Message Queuing 3.0 computer that belongs to a Windows NT 4.0 enterprise and is capable of connecting to MSMQ 1.0 controller servers is not capable of automatically revealing its new site. In this case, you can provide the name of the new site either before disconnecting the computer from the network or after reconnecting to the network. Selecting a new site enables your computer to connect to the closest controller server and thus optimizes access to the MQIS database. If you specify the new site before disconnecting from the network, messages sent to the computer while it is disconnected are routed directly to the new site while the computer is en route.

As stated previously, clients can be configured to use Message Queuing servers (in-routing and out-routing servers) for intrasite routing. When such a client moves to a different site, those in-routing or out-routing servers are not used for routing messages in the new site. When the independent client returns to its original site, those same Message Queuing servers are again used for routing messages.

Windows CE usage

A special version of the independent client is also available on handheld and palm-sized computers that are running Windows CE 3.0 or later. Because of capacity requirements and lack of RPC support, the following limitations apply to the Windows CE version of the independent client:

  • No Active Directory support. Windows CE independent clients cannot query Message Queuing servers running on Windows Server 2003 family domain controllers.
  • Limited message routing support.
  • Limited public queue support.
  • No message authentication or encryption. All messages sent to or received by other Message Queuing computers travel as plaintext.
  • No remote retrieval of messages. Messages stored on another Message Queuing computer cannot be retrieved from the Windows CE independent client.
  • No multi-message transactions.
  • No cross-platform support. Messages cannot be sent to computers running other messaging systems.


Dependent clients

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed. The term Message Queuing client can refer to either an independent client, or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality, or dependent client functionality.

Message Queuing servers with dependent client functionality require synchronous access to a Message Queuing server, called a supporting server, for all messaging functions. The supporting server can be any Message Queuing computer operating in domain mode with at least independent client functionality, preferably in the local site, but also in a nearby site. Note that computers configured as independent clients cannot provide Active Directory access for MSMQ 1.0 clients. These clients require Message Queuing servers running on a domain controller.

A dependent client relies on its supporting server to perform all messaging functions on its behalf, such as hosting queues, storing messages, sending messages, and receiving messages. If the supporting server goes offline, the dependent client will be unable to send and receive messages. By default, following installation, Message Queuing computers are not enabled to support dependent clients. For instructions on enabling a Message Queuing server to act as a supporting server, see Enable a supporting server. If you want to specify a Message Queuing server to act as a supporting server for a dependent client, you must also change the security configuration of the Microsoft Distributed Transaction Coordinator (DTC) on the Windows Server 2003 family computer to enable network transactions. The DTC is automatically installed on each computer during Windows Server 2003 family operating system installation for local transactions, and you need to enable network DTC. For instructions, see Enable network DTC access.

When you install a dependent client, you designate its supporting server. You can also later change the supporting server. Note that if you have the early version of a dependent client running on Windows NT 4.0 and you want to change its supporting server to a Message Queuing server running on Windows 2000 or Windows Server 2003 family, the dependent client must have Windows NT 4.0 Service Pack 4 or higher installed or else transactional messaging will not function. For instructions on changing the supporting server for a dependent client, see Change the supporting server for a dependent client.

For information on how to view the list of dependent clients currently supported by a Message Queuing server, see View the dependent client list for a server.

Dependent client considerations

Decide whether or not you want to deploy dependent clients in your organization. The advantages of using dependent clients are as follows:

  • Server disk space is used to store messages. When necessary, you upgrade only the server resources (such as memory and hard disk space) to improve Message Queuing performance, instead of upgrading all the client computers.
  • With fewer points of administration, you have fewer computers to back up and fewer journals and dead-letter queues to monitor.
  • Fewer resources are used if the dependent client is frequently offline and the server is not.

Dependent clients also have the following disadvantages:

  • Because the Message Queuing service runs on the supporting server, encrypted messages sent to or received by dependent clients travel between the dependent client and supporting server as plaintext.
  • Queue access time is slower for a dependent client than it is for an independent client. This is because queue access is through an RPC-based connection.
  • There may be performance issues if multiple dependent clients connect to their supporting server at the same time to send or receive messages.
  • Dependent client queues are located on their supporting server, and it is not obvious which queues belong to which dependent clients.
  • When dependent client software is uninstalled, the associated queues are not automatically deleted from the supporting server.
  • Because communication from a dependent client goes through the supporting server, if the communication to the supporting server is slow or expensive (such as between two sites), all dependent client communications are also slow or expensive.
  • Dependent clients cannot run under a local user account.
  • New Windows Server 2003 family Message Queuing features, such as HTTP transport, Message Queuing Triggers, and sending messages to multiple destinations, are not available to dependent clients. Thus, distribution lists, multiple-element format names, and multicast messaging are not supported for dependent clients.
  • Dependent clients cannot be installed on computers in workgroup mode or on 64-bit computers.
  • Transactional messaging is not supported for dependent clients running on Windows NT 4.0, Windows Milleninum Edition (ME), and Windows 98, Windows 95 computers that use a supporting Message Queuing server running on XOX or Windows Server 2003 family operating systems.


Understanding Message Queuing

This section provides detailed information that you will need to understand before administering a Message Queuing network. For details, see the following links:

  • To learn about message routing within and between sites, and deploying routing on Message Queuing servers, see Routing.
  • For information on security concepts that you must understand when administering a Message Queuing network, see Security.
  • To learn about different queue types, queue format names, and queue aliases, see Queues.
  • For information about message types and properties, see Messages.
  • For information about Message Queuing triggers, and trigger rules and conditions, see Triggers.
  • For information about one-to-many messaging, see Multiple Destination Messaging.
  • For an overview of using Message Queuing over the Internet and through firewalls, see Internet Messaging.
  • For information on implementing Message Queuing in clusters, see Message Queuing in Clusters.
  • For details of messaging between systems running Message Queuing and systems running different messaging applications, see Cross-Platform Messaging.


Routing

This section provides information about routing, and how you can deploy routing-enabled Message Queuing servers in your messaging network. For details, see the following links:

  • For an overview of message routing, see Routing overview.
  • For information about routing messages within a site, see Intrasite routing.
  • For information about routing messages between sites, see Intersite routing.
  • To learn about routing links and routing-link costs, see Routing links.
  • For information on deploying routing on Message Queuing servers, see Routing with Message Queuing servers.


Routing overview

A Message Queuing client always tries to establish a direct connection, or session, with the destination computer using the underlying IP network protocol. If a direct connection is not possible or not allowed, Message Queuing servers with routing enabled (routing servers) can temporarily store messages and subsequently forward them to the destination computer or to another routing server. In this way, they establish the route taken by messages as they proceed from the source computer to the destination computer. Specifically, message routing can occur when one or both of the following conditions exist:

  • A session cannot be established between the source computer and the destination computer (for example, if the destination computer is offline).
  • Specific Message Queuing routing servers are designated to store and forward messages on behalf of the source or destination computer.

Message routing between networks

Message Queuing can be used to send messages to and receive messages from external networks, such as other organizations or other Windows Server 2003 family forests. Message Queuing computers can use various service ports to communicate with external networks through properly configured firewalls that allow communication over those ports. For more information, see Internet messaging overview.

Although clients within a site that use the same network protocol are assumed to have direct connectivity, using in-routing and out-routing servers to route messages within a site may reduce the bandwidth requirements in your network. Clients can be configured to use in-routing and out-routing servers to provide message routing on their behalf. In that case, all messages sent or received by a client are routed first through such a Message Queuing server. The term client here refers to any Message Queuing computer that cannot route messages on its own, such as independent clients and Message Queuing servers without routing enabled. This feature is not applicable to dependent clients. Dependent clients require a supporting server to send and receive messages on their behalf. A supporting server without routing enabled, rather than its dependent clients, can be configured to use in-routing and out-routing servers.

If site gates are used to route messages between sites, only those assigned Message Queuing servers can route messages between the sites.

Notes

  • Message routing is not applicable in a workgroup environment. Thus, in-routing servers, out-routing servers, and site gates cannot be used, and direct connectivity between the source and destination computers is required.


Intrasite routing

Message routing within a site is called intrasite routing. In the simplest case, the source and destination computers are not configured to use in-routing or out-routing servers. In this case, as a first choice, Message Queuing tries to deliver a message to the destination computer directly (one hop), and as a second choice, it delivers the message to one randomly chosen Message Queuing routing server that resides in the site (two hops).

Figure showing message routing within a site

This diagram shows one possibility for routing a message from one computer to another computer within a site. Although the number of hops can vary, here, a message sent from one computer in the site to another computer in the same site makes two hops: one hop to get to the Message Queuing routing server and one hop to get to the destination computer. Because each hop is within a site, the performance overhead of each hop is minimal.

In-routing and out-routing servers

In the context of intrasite routing, independent clients and Message Queuing servers without routing enabled are functionally equivalent. These computers can be configured to use in-routing servers (InRS) or out-routing servers (OutRS) to store and forward messages on their behalf. Dependent clients cannot be configured to use in-routing or out-routing servers because all messaging functions are performed by a supporting server.

If an independent client or a Message Queuing server without routing enabled is configured to use an out-routing server, every outgoing message sent by that computer is routed through that server. Likewise, if such a computer is configured to use an in-routing server, every message sent to it is routed through that server. Such a computer can use the same Message Queuing routing server as both its in-routing and out-routing server.

All in-routing and out-routing servers must be in the original site of the computer that they serve. When a mobile client moves to another site, these servers are not used for message routing until the client returns to its original site.

Network bandwidth

Intrasite routing can reduce the usage of network bandwidth by providing session concentration. For example, if you use a star topology within a site and each independent client usually communicates directly with all other independent clients, you can reduce your bandwidth usage through session concentration by configuring each client to use in-routing and out-routing servers.

Figure showing session concentration within a site

In this figure, the same Message Queuing routing server is configured as both an in-routing server and an out-routing server for each client.


Intersite routing

Message routing between different sites, called intersite routing, requires connectivity between those sites. Connectivity between different sites can be defined by logical communications links, called routing links. If the message traffic between two specific sites can be configured to pass through a specific Message Queuing routing server or one of several such servers, that routing server is called a site gate. Routing links can use site gates to route messages between two sites.

If your organization has more than one Windows Server 2003 family site, you must create routing links to guarantee that messages can be routed between different Windows Server 2003 family sites. The route taken by messages between sites can be determined by the routing-link costs. All routing links are assigned a default cost of 1.

Link costs can be used to select the best intersite message route and may be based on the speed or the monetary cost of the underlying physical communication link. After you determine the number of Windows Server 2003 family sites in your forest, decide if you need to specify different costs for routing links. For information on how to change routing-link costs, see Change the cost for a routing link.

For information on sites, see Sites.

In a domain environment with more than one Windows Server 2003 family site, you must create routing links to guarantee that messages can be routed between different sites. In the absence of a routing link, Message Queuing will usually attempt to establish a direct connection with the destination computer in an unconnected site.

Each routing link is assigned a relative cost, which may reflect the speed or the monetary cost of the underlying physical communication link. The default value is 1, and costs can range from 1 to 999999. Change routing-link costs only in cases where alternative intersite routes are possible over the existing routing links and you want to enforce one route over another route using the costs of the individual links.

Notes

  • A site gate can belong to either or both of the sites connected by a routing link. A routing link can be configured with any number of site gates or no site gate.
  • Do not confuse routing links with site links. Routing links are used by Message Queuing servers to route messages between sites. Site links are used by domain controllers to replicate Active Directory information between sites.

When a message is sent from an independent client in one site to a computer in another site, the source computer first tries to connect directly to the destination computer, and only as a second choice, delivers the message to a routing server in its site, which delivers the message to a site gate. This process continues until the message reaches the destination computer.

Session reduction

Intersite routing typically reduces the number of sessions created by clients. In the following figure, the routing beyond the site is transparent to the computers within the site, with the exception of the site gate. This simplifies the message route and reduces site-to-site sessions. Only the designated Message Queuing server can establish a session between different sites.

Figure showing intersite session concentration


Routing links

If your organization has more than one Windows Server 2003 family site, you must create routing links to guarantee that messages can be routed between different Windows Server 2003 family sites. The route taken by messages between sites can be determined by the routing-link costs. All routing links are assigned a default cost of 1. Change routing-link costs only in the case where alternative routes are possible over the existing routing links and you want to enforce one route over another route using the costs of the individual links. For more information on configuring routing links, see Configuring routing links.

Link costs can be used to select the best intersite message route and may be based on the speed or the monetary cost of the underlying physical communication link. After you determine the number of Windows Server 2003 family sites in your forest, decide if you need to specify different costs for routing links. For information on how to change routing-link costs, see Change the cost for a routing link.

For information on sites, see Sites.

Routing link example

A routing link that connects sites A and B has four site gates (SG1-SG4). If SG1 and SG2 belong to site A, SG3 belongs to both sites A and B, and SG4 belongs to site B, messages can be routed through one of the site gates of site A (SG1, SG2 or SG3) and then through one of the site gates of site B (SG3 or SG4). However, if the messages are routed through SG3, which belongs to both sites, they will reach the destination computer in one less hop. Thus, messages are routed preferentially through SG3. In the general case, if a routing link is associated with only a pair of site gates, one in each site, only those servers can route messages between the designated sites in that routing link.

Multiple routing links can be used to route messages between sites in your network for load balancing or redundancy. In this case, if you want to enforce one route over another route using link costs (for example, to specify a default link), you can change the routing-link costs to determine the route that messages take.

For example, if the cost associated with the A-B routing link is set to 3 and the cost associated with the other three routing links (B-C, B-D, and C-D) is 1, messages routed from site A to C always travel from site A to site B and then to site C. However, if the cost associated with the A-B and B-C routing links is 3 and the cost associated to the C-D and B-D routing links is 1, messages routed from site A to C always travel from site A to site B, to site D, and then to site C.

Figure showing intersite routing

The route that a message takes to get from site A to site C depends on the costs of the routing links.

Routing link | Cost
A-B | 3
B-C | 1
B-D | 1
C-D | 1

In this situation, messages routed from site A to site C always travel from site A to site B and then to site C.

Routing link | Cost
A-B | 3
B-C | 3
B-D | 1
C-D | 1

In this situation, messages routed from site A to site C always travel from site A to site B, then to site D, and finally to site C.


Routing with Message Queuing servers

The number of Message Queuing servers with routing enabled (routing servers) that you deploy in your organization can depend on the following factors:

  • The number of sites among which you are routing messages.
  • How frequently client computers are offline. Message Queuing servers with routing services are needed for message store-and-forward capability when the source and destination computers may not be online at the same time.

It is recommended that at least one routing server be installed in each Windows Server 2003 site to ensure that messages are forwarded successfully. For performance and scalability reasons, it is recommended that multiple Message Queuing routing servers be installed in each site.

A source computer will successfully forward a message to a destination computer when a direct connection is established and when the destination site has no site gate. If the destination site has a site gate, the messages will not be forwarded and will accumulate at the source.

It is recommended that in-routing and out-routing servers be available for mobile clients that are mostly disconnected from the network or connect to the network through a remote access server.

There is no technical restriction or limitation on installing Message Queuing routing servers on domain controllers. However, because the main roles of domain controllers include authenticating users, handling queries to Active Directory, and maintaining domain security, it is recommended that you carefully consider how installing Message Queuing routing servers on domain controllers may influence their performance and security.

By providing session concentration, the use of Message Queuing routing servers may reduce operating costs. Such servers can reduce bandwidth needs within a site and reduce the number of sessions between different sites. Intrasite routing is considered relatively fast and inexpensive, while intersite routing is considered relatively slow and expensive.

In addition, when Message Queuing routing servers are available, messages do not accumulate in independent clients, which generally have a small storage capacity, but can be delivered to an out-routing server, which stores them until the destination computer becomes online.

Message Queuing routing servers that provide intrasite message routing are called in-routing servers (InRS) or out-routing servers (OutRS). Message Queuing servers providing message routing on a routing link, which defines connectivity between sites, are called site gates. For more information on intrasite routing, see Intrasite routing. For more information on intersite routing, see Intersite routing.

The relative cost of using a given route to reach a destination computer is commonly measured in hops, where each hop represents the delivery of a message from one computer to another. If there are multiple routes with the same destination, the route with the lowest hop count is the best.


Security

Message Queuing uses security features provided by Windows Server 2003 family operating systems, including access control and auditing for Message Queuing objects, message authentication, and encryption. For details, see the following links:

  • For a general overview of security features for Message Queuing, see Security overview.
  • For information on implementing authentication to check who sent messages, and message integrity, see Authentication for Message Queuing.
  • For information on encrypting private messages, see Encryption for Message Queuing.
  • For information on restricting operations of Message Queuing objects to specific groups or users, see Access control for Message Queuing .
  • For information on auditing access operations of Message Queuing objects, see Auditing Message Queuing objects.
  • Message Queuing can be deployed in hardened MSMQ mode to enhance the security of Message Queuing computers using HTTP messaging over the Internet. For more information, see Message Queuing in hardened MSMQ mode.


Security overview

Message Queuing takes advantage of the various built-in security features of the Windows Server 2003 family operating systems. Specifically, Message Queuing uses access control, message authentication, encryption, and auditing for security. In Message Queuing 3.0, 128-bit encryption is supported in addition to 40-bit encryption. By managing security properties for objects, you can set permissions, assign ownership, and monitor user access.

Access control is used to restrict user access to Message Queuing objects in Active Directory and is implemented by assigning security descriptors to objects. Message Queuing objects include the MsmqServices, msmq, Queue, routing link, and MSMQ Settings objects. The msmq object for the local computer is also known as the MSMQ configuration object, for example, in names of specific permissions for this object and in the Delegation of Control Wizard. A security descriptor lists the users and groups that are granted or denied access to an object as well as the specific permissions assigned to those users and groups. For more information, see Access control for Message Queuing.

Security queries to Active Directory and other directory services, in which the client and server are online and talk to one another, are implemented using the Kerberos V5 security protocol (between Windows Server 2003 computers) or server authentication (for compatibility with MSMQ 1.0 running on Windows NT 4.0).

Message authentication, which verifies the identity of the sender of a message to the receiver, is implemented using certificates. Messages are authenticated asynchronously without the sender and the receiver communicating with one another. For more information, see Authentication for Message Queuing.

Encryption is implemented using both public/private key (asymmetric) and secret key (symmetric) algorithms. Encryption is used by Message Queuing applications to encrypt messages sent between Message Queuing computers. For more information, see Encryption for Message Queuing.

Security auditing is used to record which users attempt to access Message Queuing objects in Active Directory. The security descriptor for an object specifies the various security events to be audited for the object. For more information, see Auditing Message Queuing objects.

Message security

Message Queuing ensures the security of messages sent from a source computer to a destination computer. Applications can perform a local read or a remote read when accessing queues. A local read is performed when the receiving application accesses a destination queue that resides on the same computer. In this case, message security can be guaranteed.

A remote read is performed when the contents of a queue are accessed from a computer other than the one on which the queue is located. For remote reading, Message Queuing 3.0 uses encrypted RPC by default. This feature is available when a Windows Server 2003 family client computer does a remote read against a Message Queuing computer running on Windows Server 2003 family computers, Windows 2000, or Windows NT 4.0. Note that in situations where encrypted RPC cannot be used, (for example, where a workgroup computer is part of the remote read process) the message will be passed to the remote computer as clear text and message security is not guaranteed. A clear text message that has reached its destination queue can be read only by users that have the necessary access rights to read messages from the queue.

Secured remote read

Message Queuing 3.0 on Windows Server 2003 family computers provides a new secure remote read interface that enhances the security of the old remote read interface used by Message Queuing running on earlier versions of Windows operating systems, and allows Message Queuing servers to expose remote-read functionality in a more secure way.

Following Message Queuing installation, Message Queuing 3.0 on Windows Server 2003 family computers listens for both the old remote read interface and the new secure remote read interface, and the following default settings are applied:

  • Message Queuing 3.0 clients on Windows Server 2003 family computers in the same forest as the Message Queuing 3.0 server will use the secure remote read interface with an encrypted channel.
  • Message Queuing 3.0 cross-forest clients on Windows Server 2003 family computers in non-trusted domains will use the secure remote read interface. By default, the Message Queuing 3.0 server requires domain clients to establish an encrypted channel, and such a channel cannot be established between non-trusted domains. Thus remote read requests from such clients will be rejected. To modify this default behavior and allow the Message Queuing server to accept domain clients that do not establish an encrypted channel, create a DWORD value Security\NewRemoteReadServerAllowNoneSecurityClient in the registry and set it to 1.
  • Message Queuing 3.0 workgroup clients on Windows Server 2003 family computers will use the secure remote read interface. Workgroup clients cannot establish an encrypted channel for remote reading, and by default, the Message Queuing server accepts workgroup clients on a non-encrypted channel. To modify this default behavior so that the Message Queuing 3.0 server rejects workgroup clients, create a DWORD value Security\NewRemoteReadServerDenyWorkgroupClient in the registry and set it to 1.
  • MSMQ 1.0 and MSMQ 2.0 clients, and Message Queuing 3.0 clients on XOX computers, will use the old remote read interface. If you enable your Message Queuing 3.0 server to use only the secure remote read interface, the computer does not listen on the old remote read interface, and remote reads from these clients are not supported.

You can enable your Message Queuing 3.0 server to use only secured remote reading mode in the Server Security tab of Message Queuing properties in Computer Management. In secured remote reading mode, your computer will only listen on the new secure remote read interface, and not on the old remote read interface. The effect of this is that only Message Queuing 3.0 servers on Windows Server 2003 family computers can remotely receive messages from queues on your computer, and remote reads from MSMQ 1.0 clients, MSMQ 2.0 clients, and Message Queuing 3.0 clients running on XOX computers are not supported. For instructions on enabling your server to use only the new secured mode, see Enable secured remote read.


Authentication for Message Queuing

The following sections describe the various types of authentication available for Message Queuing.

Server authentication

Server authentication is used by clients to authenticate queries sent to domain controllers and Message Queuing servers. A client can verify that the query results have not been tampered with and that the results were returned by the correct domain controller or Message Queuing server. Security queries to Active Directory and other directory services, in which the client and server are online and talk to one another, are implemented using the Kerberos V5 security protocol (between Windows Server 2003 family and/or Windows 2000 computers), or with server certificates (for compatibility with MSMQ 1.0 running on Windows NT 4.0). The method used depends on the version of Message Queuing (and hence the operating system) running on the server and the client. For more information on server authentication, see Managing server authentication.

Message authentication

Message authentication, which confirms that a message has not been tampered with and can be used to verify the identity of the sender of a message to the receiver, is implemented using certificates. Messages are authenticated asynchronously without the sender and the receiver communicating with one another. The use of message authentication is optional. Message Queuing applications are not required to use authentication when sending or receiving messages. Note that the use of message authentication slows the transfer of messages. When used, however, Message Queuing applications that send or receive authenticated messages must use the cryptographic service provider installed by default with Windows Server 2003 family, which is needed for both message authentication and encryption. For more information on message encryption, see Encryption for Message Queuing. For more information on message authentication, see Managing message authentication.

For more information on authentication for Windows Server 2003 family, see Authentication, in the Windows Help file.

For more information on certificates for Windows Server 2003 family, see Certificates overview in the Windows Help file.

HTTPS authentication

Using HTTPS to send messages ensures authentication of users requesting access to Message Queuing resources by means of a Web server, by establishing a Secure Sockets Layer (SSL) connection for secure communication between a sender and recipient. Authentication for an SSL connection is done using server and client certificates. For more information, see HTTPS authentication.


Encryption for Message Queuing

In the context of Message Queuing, encryption is the process for encoding and decoding messages, ensuring they cannot be read or used by unauthorized persons. Message Queuing implements message encryption through the use of symmetric and asymmetric (public/private) key encryption algorithms. The encryption implementation used is based on the CryptoAPI (Microsoft Cryptographic Application Program Interface), which in turn uses a cryptographic service provider (CSP) installed on the computer.

The use of message encryption is optional. Message Queuing applications are not required to use encryption when sending or receiving messages. Note that the use of message encryption slows the transfer of messages. When used, however, Message Queuing applications that send or receive encrypted messages must use the CSP installed by default with Windows Server 2003 family, which is needed for both message authentication and encryption. For more information on message authentication, see Authentication for Message Queuing.

Although other CSPs can be used for the encryption of data that does not involve Message Queuing, the CSP provided with Windows Server 2003 family must be used for any Message Queuing application that sends or receives encrypted messages. Non-Message Queuing applications can continue to use other CSPs for encryption.

How message encryption works

Messages are encrypted by the Message Queuing service on the source computer and decrypted by the Message Queuing service on the destination computer. Decrypted messages are stored in the destination queue as plaintext. Message encryption is designed to prevent unauthorized viewing of messages in transit.

When message encryption is used, performance is reduced, although typically not as much as when using message authentication. Performance losses due to encryption are most significant when you send encrypted messages to many different computers. However, when you send multiple messages to the same destination computer, only the first message sent takes significantly longer than usual to send.

To see why message throughput is reduced, it is important to understand the encryption mechanism that Message Queuing uses. On the source computer, Message Queuing does the following:

  1. Creates a secret key.
  2. Encrypts the message body by using the secret key.
  3. Encrypts the secret key by using the public key of the destination computer.
  4. Attaches the encrypted secret key to the encrypted message.

On the destination computer, Message Queuing does the following:

  1. Decrypts the secret key by using its private key (of the key pair).
  2. Decrypts the message body using the secret key.

Secret keys can be used for both encryption and decryption, hence they are called symmetric. Public keys can be used for encryption only, while private keys can be used for decryption only.

Asymmetric key encryption has more overhead than symmetric key encryption. Sending the first message incurs the most overhead because the secret key is encrypted with the public key of the destination computer. By default, Message Queuing stores the encrypted secret key on the source computer for 10 minutes. If you send additional messages to the same computer within 10 minutes after sending the first message, Message Queuing reuses the same secret key. Consequently, the overhead for each subsequent message will be just the overhead needed to encrypt the message body using the secret key. In this case, Message Queuing does not need to encrypt the secret key with the public key of the destination computer again. The same performance results are realized on the destination computer. Upon receiving the first message, Message Queuing decrypts the secret key by using its own private key. Message Queuing then stores the decrypted secret key and can reuse it later for subsequent messages without any additional overhead.

You can specify whether a queue accepts encrypted messages, unencrypted messages, or both by selecting the privacy level for the queue. If the queue privacy level is set to None, the queue accepts only unencrypted messages. If the queue privacy level is set to Body, the queue accepts only encrypted messages. If the queue privacy level is set to Optional, the queue accepts both unencrypted and encrypted messages. You can check whether a message sent to the queue was encrypted or unencrypted using Active Directory Users and Computers (or programmatically by checking the PROPID_M_PRIV_LEVEL message property).

For information on how to set the privacy level for a queue, see Change the privacy level for queues.

Notes

  • When messaging across different messaging platforms, encrypted messages sent to foreign computers stay encrypted on the intermediary Message Queuing server running the connector application. The connector application can forward the encrypted messages to the foreign computer or can decrypt the messages first before forwarding.
  • Because encryption requires queries to Active Directory, it cannot be used in workgroup or offline mode.

Cryptographic keys

Public/private cryptographic key pairs for a computer are created for you during Message Queuing Setup and can be renewed using the Message Queuing Properties dialog box, which can be opened from Computer Management. All Message Queuing computers except dependent clients use cryptographic keys.

For more information on encryption keys for Windows Server 2003 family, see Generating encryption keys and certificate requests.

Cryptographic key renewal is a security feature used by Message Queuing. It is a good idea to renew your cryptographic keys periodically, such as once a year. It is also recommended that you renew your cryptographic keys any time you suspect they have been compromised. In particular, this will reduce the chance that your private key has been compromised.

When you renew the cryptographic keys for a Message Queuing computer, any messages that were encrypted using the previous public keys cannot be decrypted. This occurs only until the new public keys are replicated in Active Directory to all Message Queuing servers and the source computers can start using the new public keys.

For information on how to renew your cryptographic keys, see Renew cryptographic keys for Message Queuing.


Access control for Message Queuing

Access control is used to restrict user access to Message Queuing objects in Active Directory and can be implemented by assigning security descriptors to objects. A security descriptor lists the users and groups that are granted or denied access to an object and the specific permissions assigned to those users and groups. This part of the security descriptor is known as a discretionary access control list (DACL). By setting the permissions on an object, the owner of the object controls which access is allowed. The Message Queuing objects include computer (msmq), queue, routing link, and MSMQ Settings objects. For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, see Message Queuing and Active Directory.

Permissions can also be used to restrict users from sending messages to, or retrieving messages from, a particular queue on a computer. Although messages are not objects in Active Directory, they are protected through the security descriptor of the queue object.

Because Message Queuing provides asynchronous messaging, the source and destination computers do not need to be online at the same time. In this case, Message Queuing can implement access control for offline users through the use of sender security IDs (SIDs). For example, because a queue can restrict access to itself, the sending application must attach the sender's SID to any message directed to that queue. The Message Queuing service on the destination computer then checks the SID to verify that the sender has the proper permissions to access the queue.

Notes

  • You must also be granted certain permissions to be able to install and uninstall Message Queuing. For more information, see Installation permissions.

For more information on access control for the Windows Server 2003 family, see Access control, in the Windows Help file.


Auditing Message Queuing objects

You can use auditing to record which users attempt to access Message Queuing objects, the type of operation attempted, and whether that access succeeded or failed. The security descriptor for an object specifies the various access events to be audited for the object. This part of the security descriptor is known as a system access control list (SACL). More specifically, a SACL specifies the following:

  • The users or groups to audit when accessing the object.
  • The access events to be audited for each group or user.
  • A Success or Failure attribute for each access event, based on the permissions granted to each group or user in the object's discretionary access control list (DACL).

For more information on auditing for Windows Server 2003 family, see Auditing overview, in the Windows Help file.

The security log records audited operations, called security events, which you can view using Event Viewer. For more information on Event Viewer, see Event Viewer, in the Windows Help file.

Configuring auditing

To implement auditing, you must establish an audit policy. An audit policy specifies categories of security-related events that you want to audit. For instructions, see Define or modify auditing policy settings for an event category, in the Windows Help file. To audit "object open" security events such as Peek Message, Receive Message, and Send Message, you grant the Message Queuing service of a specific computer security permissions to access SACL information for its public queue. For more information, see Enable Message Queuing to access SACL information.

Next, you select the access entries to be audited for success or failure for a user or group on a specific object or resource. For information on how to set auditing options for a Message Queuing computer or queue object, see Audit access to computer and queue objects. For information on how to set auditing options for a routing link object, see Audit access to routing link objects.

If auditing options are specified for a Message Queuing object but an audit policy has not been established on the Message Queuing server that carries out the operation, a security event is not created.

Security events

Security events are created in the security log on the computer that performs the operation, which is not necessarily the computer that is the owner of the object. Because of this, audit messages for a single Message Queuing object can be scattered across a network. For example, in this figure, if the public test queue located on client 1 in the San Francisco site is deleted by client 2 in the Seattle site, the audit message is created on server 2 of the Seattle site. The following diagram illustrates this:

Figure showing how security events are created


Message Queuing in hardened MSMQ mode

The purpose of Message Queuing in hardened MSMQ mode (a new feature in Message Queuing 3.0) is to enhance the security of Message Queuing computers running on the Internet. Hardened MSMQ mode is intended to support scenarios that employ only HTTP (SRMP) messages.

Message Queuing in hardened MSMQ mode imposes the following restrictions:

  • The Message Queuing service does not listen directly to any ports. Thus, only messages arriving from remote computers through IIS are accepted and placed in their destination queues. Remote RPC calls are ignored (remote reading is blocked), and dependent clients are not supported.
  • Attempts to open remote queues with non-HTTP format names and send messages to them succeed. However, all the outgoing queues created on the local computer that correspond to remote destination queues specified by non-HTTP format names are in the locked state. Messages, including acknowledgment and response messages, that reside in locked outgoing queues are not transmitted to their destinations.
  • Messages intended for remote destination queues with non-HTTP format names, including remote queues designated by non-HTTP elements of a multiple-element format name, remain in the locked outgoing queues until hardened MSMQ mode is canceled and the Message Queuing service is restarted.

In hardened MSMQ mode, messages can still be placed in local queues with non-HTTP format names and received from them.

Security considerations in hardened MSMQ mode

When deploying a domain controller with the Downlevel Client Support component in a perimeter network, be aware that this component listens to the RPC interface, and that it is not governed by hardened MSMQ mode. For reducing the attack surface, you may want to remove the Message Queuing Downlevel Client Support component from the domain controller.

For instructions on enabling or canceling hardened MSMQ mode on the local computer, see Enable hardened MSMQ mode.


Queues

In the context of Message Queuing, queues are temporary storage locations for different types of messages. The following sections provide information about different types of queues that can be deployed in a messaging infrastructure. Queues can be created by applications and by Message Queuing. Queues created by applications or by administrators are referred to as application queues. Queues created by Message Queuing are known as system queues. For details, see the following links:

  • For information on the different types of application-generated queues used by Message Queuing, see Application Queues.
  • For information on journal queues, outgoing queues, dead-letter queues, and other types of system queues created and used by Message Queuing, see System Queues.
  • For information on the names that can be used to designate Message Queuing queues, see Queue names.
  • For information on referencing queues by queue alias names, see Queue aliases.
  • For information on target journaling, see Target journaling.
  • For information on source journaling, see Source journaling.


Application Queues

Queues that are created by an application or by the Message Queuing administrator are referred to as application queues. For information on different types of application queues, see the following links:

  • Destination queues are any application queue that sending applications send messages to, or that receiving applications receive messages from. For more information, see:
    • Public and private queues
    • Transactional and nontransactional queues
  • Administration queues are application-generated queues used to store system-generated negative and positive acknowledgment messages that are created by Message Queuing or connector applications. Any available nontransactional queue can be used as an administration queue. For more information, see Administration queues.
  • Response queues are application-generated queues used to store application-generated response messages that are typically returned by an application that is reading messages from a queue. Any available queue can be specified as a response queue. For more information, see Response queues.
  • Report queues are application-generated queues used to store report messages generated by Message Queuing or connector applications when tracing is requested by the sending application. When a message is sent with tracing enabled, a report message is generated each time the message leaves or arrives at a Message Queuing computer. For more information, see Report queues.


Public and private queues

Private queues

Private queues are queues that are not published in Active Directory and are displayed only on the local computer that contains them. Private queues have the following features:

  • Message Queuing registers private queues locally by storing a description of the queue in the LQS (local queue storage) directory on the local computer. In MSMQ 2.0, and Message Queuing 3.0, the default location is %windir%\system32\msmq\storage\lqs. Note that a description of each public queue created on the local computer is also stored locally in a separate file in the LQS folder.
  • Private queues are registered on the local computer, not in the directory service, and typically cannot be located by other Message Queuing applications.
  • Private queues are accessible only by Message Queuing applications that know the full path name, the direct format name, or the private format name of the queue, as follows:
    • Path name: ComputerName\private$\QueueName.
    • Path name on local computer: \private$\QueueName.
    • Direct format name:: DIRECT=ComputerAddress\PRIVATE$\PrivateQueueName.
    • Private format name: PRIVATE=ComputerGUID\QueueNumber.

    For more information on path names and format names, see Queue names.

  • Private queues have the advantage of no directory service overhead, making them quicker to create, no latency in accessing them, and no replication overhead.
  • Private queues are not dependent on the directory service, and thus can be created and deleted when the directory service is not working. This is useful for offline operation.
  • One way that private queues can be exposed to other applications is by setting a message property. To distribute the location of a private queue, an application can send a format name of the private queue as the response queue property of a message.
  • In a workgroup environment, only private queues are available.
  • For a Message Queuing application on the local computer to access a private queue, the application only needs to know the path name of the queue. For a Message Queuing application on a remote computer, the application requires a direct or private format name to access such a queue. To read messages from the queue, the remote Message Queuing application requires the Receive Message permission for that queue. By default, everyone has permissions to send messages to public and private queues.

Public queues

In a domain environment, public queues are queues that are published in Active Directory and hence are replicated throughout your Windows Server 2003 family forest. Note that only the properties for these queues are replicated, not the actual queues themselves or their contents. Any computer within your forest can potentially access information regarding public queues provided the user has sufficient permissions to access the applicable queue objects. Generally speaking, any user in the forest with access to Active Directory and the Send To permission for a given public queue can send messages to it.

In an Active Directory environment, defining public queues ensures that queues are registered in the directory service, and that their registration is backed up. They are persistent and available to other applications.

Creating local public queues

By default, in Active Directory, the Create Child Object permission that is required to create local public queues is granted to:

  • The Domain Administrator account
  • The domain user account of the local administrator that installed Message Queuing
  • Local System and Network Service accounts

To permit all other users to create local public queues by default, Message Queuing uses Message Queuing service elevation of privilege. The effect of this is that if the user account does not have Active Directory permissions for this action, the user account privilege is elevated and the local public queue is created using Message Queuing service's Local System account. This is the default Message Queuing setting. If you want to disable this behavior, and restrict the creation of local public queues, set the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\ EnableCreateQueueThroughService. To disable the key, set the DWORD value to 0. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Default security access for public queues gives everyone permission to send messages to a public queue. Specific permissions must be granted for read access.

The advantage of public destination queues is that they are registered in the directory service, where they can be located by other Message Queuing applications. Public queues are persistent, and their registration information can be backed up on the enterprise, making them good for long-term use.


Transactional and nontransactional queues

A transactional queue is one that only contains transactional messages, which are messages sent within a transaction. The requirements for sending and retrieving messages are based on the type of queue used (transactional or nontransactional) and the queue's location (local or remote).

Sending messages

When using transactions to send messages, the messages can be sent to any transactional queue regardless of where the queue is located, but only transactional queues can accept messages sent in the context of a transaction. In a similar way, nontransactional queues can only accept messages sent outside the context of a transaction. Note that only transactional messages are delivered with Exactly-Once In-Order Delivery (EOD) guarantees. For more information on transactional messaging, see Transactional messaging.

Receiving messages

When using a transaction to retrieve messages, the queue must be a local transactional queue. You cannot retrieve a message from a remote transactional queue or from a local nontransactional queue within a transaction. Message Queuing does not provide support for transactional remote-read operations (accessing the contents of a queue from a computer other than the one on which the queue is located). However, this same functionality can be achieved by using a transactional read-response application.

Note that nontransactional receive operations are allowed from any queue (transactional or nontransactional, local or remote). In particular, a nontransactional receive operation from a transactional queue is essentially a transaction consisting of a single receive operation.

Transactional read-response applications

A transactional read-response application is used when you need to retrieve transactional messages from a remote transaction queue. It uses transactions to redirect the messages from the remote queues on the sending computer to local queues on the receiving computer.

A read-response application resides on a server that contains two transactional queues:

  • An input queue for collecting messages from sending applications.
  • A read-request queue for collecting read-requests from the receiving application.

The read-response application does the following in a single transaction:

  • Retrieves a request made by the receiving application from the read-request queue.
  • Retrieves a message sent by the sending application from the input queue.
  • Forwards the message from the input queue to the receiving application that made the request.

In this way, the receiving application gets its messages within a transaction, without needing to perform a transactional remote-read operation.

The receiving application sends a request message to the read-request queue on the server, specifying the response queue to which the input message will be sent. This request can be made within the context of its own transaction. Note that it is independent of the transaction used to send the message back to the receiving application.


Administration queues

Administration queues are application-generated queues used to store system-generated negative and positive acknowledgment messages that are created by Message Queuing or connector applications. They are specified programmatically in the original messages by the sending application. Any available nontransactional queue can be specified as an administration queue. Administration queues do not contain administrative messages, which are stored in internal private queues. For more information on acknowledgment messages, see Message types.

The system-generated acknowledgment messages returned to these queues can indicate whether a message arrived at its destination queue, whether it was retrieved from the destination queue, or both. Each acknowledgment message contains information that describes what triggered the acknowledgment and to which message the acknowledgment refers. When requesting acknowledgment messages, the sending application must specify the queue to be used as the administration queue and the acknowledgment level of the message. Typically, an administration queue is a local queue so that the sending application can read the acknowledgment messages locally.


Response queues

Response queues are application-generated queues used to store application-generated response messages that are typically returned by an application that is reading messages from a queue. Response queues are specified programmatically by the sending application when a message is sent. Any available queue can be specified as a response queue. Response messages are not the same as administrative response messages, which are stored in an internal private queue.

The response messages returned to these queues must be understood by the application returning the response messages and the application reading the response messages. Message Queuing has no control over what information is sent in response messages. When requesting response messages, the sending application must specify the queues that it wants to use as response queues. Typically, response queues are local queues so that the sending application can read the response messages locally.

When a response queue and an administration queue are both needed, their functionality can be combined into a single queue. However, because all administration queues must be nontransactional, this queue will accept only nontransactional messages. For more information on administration queues, see Administration queues.


Report queues

Report queues are application-generated queues used to store report messages generated by Message Queuing or connector applications when tracing is requested by the sending application. They indicate the route that a message took to its destination on a remote computer or the route that a test message took to a test queue on a remote computer. There can be only one report queue per computer.

All report queues must have the following label and queue type identifier:

  • Label: MQReport Queue
  • Queue type identifier (GUID):
    {55EE8F32-CCE9-11CF-B108-0020AFD61CE9}

Report queues are typically created by the Message Queuing administrator using Active Directory Users and Computers, but they can also be generated by an application as long as the correct label and queue type identifier is specified when the queue is created. Message Queuing uses the label and queue type identifier to locate and open the appropriate queue when sending report messages.

Report queues are not limited to report messages. Application-generated messages can be sent to report queues as well. When a message is sent with tracing enabled, a report message is generated each time the message leaves or arrives at a Message Queuing computer. Report messages are sent to a report queue only if message route tracking is enabled on the host computer and the message route tracking flag is set. Typically a single report queue is specified by the source computer where the message is sent. However, each Message Queuing computer can specify its own report queue.


System Queues

Queues that are created by Message Queuing are referred to as system queues. Applications can read the messages in system queues, but cannot address messages to them. For information on different types of system queues, see the following links:

  • Queue journals contain copies of all messages removed from a queue. Computer journals contain copies of all messages sent from a computer. For more information, see Journals.
  • Message Queuing uses internal private queues as interim queues for storing and forwarding messages in transit to a destination queue. These queues are not published in Active Directory. Outgoing queues are local internal queues, generated automatically to store messages sent to remote queues. For more information, see Internal private queues and outgoing queues.
  • Dead-letter queues contain messages that cannot be delivered. Message Queuing provides a transactional dead-letter queue and a nontransactional dead-letter queue. For more information, see Dead-letter queues.
  • Connector queues are used for cross-platform messaging. For more information, see Connector queues.


Journals

Queue and computer journals are system queues that are automatically created by Message Queuing. When a sending application sends a message, a copy of the message is optionally stored in the computer journal of each computer it passes through. When a receiving application removes the message from the destination queue, a copy of the message is optionally sent to the queue journal. Applications can only read the messages in queue and computer journals. They cannot send messages to queue or computer journals. In contrast, Message Queuing never removes messages from queue or computer journals. It is up to the application reading the messages to clear the messages from the queues. If an application uses journaling and no provisions are made to clean up the journals used, Message Queuing disk storage will quickly be consumed.

Computer journals

A computer journal is created whenever a Message Queuing computer is added to a Windows Server 2003 enterprise. It is used to store copies of all messages successfully sent from the computer. Message Queuing stores copies of the messages sent from the computer whenever positive source journaling is specified by the sending application. For more information, see Source journaling.

Computer journals can be referenced by a machine format name or a direct format name. The following lines show the syntax of these format names:

MACHINE=ComputerGUID;JOURNAL

DIRECT=AddressSpecification\SYSTEM$;JOURNAL (Introduced in MSMQ 2.0)

For instructions on setting the computer journal size, see Set the journal storage size for computers.

A computer journal is not created for computers operating in workgroup mode or virtual servers in clusters. You can set the computer quota of a workgroup computer using the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\MachineJournalQuota registry key. To change the quota for a virtual server, you need to change the analogous registry key for clustered servers. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Queue journals

Queue journals are created whenever an application queue is created. Message queuing creates the queue journal on the same computer where the messages for the application-generated queue are stored.

Message Queuing stores copies of the messages removed from the application queue whenever target journaling is enabled on the queue. This does not include messages removed from the queue when their time-to-be-received elapses or messages purged from the queue in the Message Queuing MMC snap-in. For more information, see Target journaling.

For instructions on setting the queue journal size, see Set the journal storage size for queues.


Internal private queues and outgoing queues

The following sections describe internal private queues and outgoing queues.

Internal private queues

Private queues are queues that are not published in Active Directory. Private queues are accessible only by Message Queuing applications that know the full path name or format name of the queue. Internal private queues are not listed in the Private Queues folder, and any information on these queues and their contents can be obtained only programmatically. You cannot delete internal private queues.

Outgoing queues

Outgoing queues are local internal queues that are used to store messages sent to remote queues. Messages can be stored in outgoing queues under offline conditions and then sent to target queues on remote computers when connectivity is re-established. Outgoing queues are listed in the Outgoing Queues folder. These queues are generated automatically and cannot be created or deleted manually. Outgoing queues can be in any of the following states:

  • Connected. The outgoing queue is connected to the queue manager on the computer. This state indicates the local queue manager is sending messages and that the messages will be going out immediately.
  • Disconnected. The outgoing queue is not connected nor is it in the process of being connected. This state indicates that the queue manager on the computer is not sending messages to the destination queue nor in the process of connecting the applicable outgoing queue.
  • Disconnecting. The queue manager is in the process of disconnecting the applicable outgoing queue, or the computer is in the process of disconnecting from the applicable session. The queue manager cannot send messages to the destination queue in this state.
  • Inactive. The applicable outgoing queue is in a state in which the queue manager does not attempt to connect it to any session.
  • Local connection. The queue is a local queue on the computer. This state indicates that sending messages to the queue does not require a network connection.
  • Locked. The outgoing queue is in the state defined by hardened MSMQ mode for outgoing queues that correspond to destination queues specified by non-HTTP format names. Messages in locked outgoing queues are not transmitted to their destinations.
  • Need Validation. The queue was opened when the queue manager was offline.
  • On hold. The outgoing queue is paused.
  • Waiting. The queue manager is in the process of connecting the outgoing queue.


Dead-letter queues

Undeliverable and expired nontransactional messages are stored in nontransactional dead-letter queues. Undeliverable and expired transactional messages are stored in transactional dead-letter queues. Such messages are stored in the applicable queues on the computer on which the message expired (or failed to be delivered or forwarded). This can be the source computer, the target computer, or an intermediate Message Queuing server.

There is one nontransactional dead-letter queue and one transactional dead-letter queue on each Message Queuing server and independent client. These queues are created automatically and are listed in the System Queues folder of the applicable computer in MMC snap-ins.

Messages are considered undeliverable when the following conditions apply:

  • The destination queue is unknown by the sender.
  • The message exceeds its maximum number of allowed hops.
  • The queue storage limit, or quota, is reached.
  • A nontransactional message is sent to a transactional queue or vice versa.
  • For transactional messages, the sending or receiving transaction failed. However, when the receiving transaction fails, these messages are not placed in the transactional dead-letter queue.

Messages are considered expired when:

  • The lifetime of messages on the network, called the time-to-reach-queue (TTRQ), elapses. This can be set programmatically by a Message Queuing application.
  • Their time-to-be-received (TTBR) elapses. This is always set programmatically by a Message Queuing application.

When a sending application is not allowed to send messages to a particular queue because of a lack of the necessary access rights, those messages are not stored in the nontransactional dead-letter or transactional dead-letter queues. However, negative acknowledgment messages may be generated if the original messages are so configured.

Messages in nontransactional dead-letter and transactional dead-letter queues are always written to disk and are therefore recoverable.

For more information on transactional messaging, see Transactional messaging.


Connector queues

Connector queues receive messages sent to destinations on foreign computers. Such queues reside on Message Queuing servers running a connector application, which enables the foreign computers to communicate with other Message Queuing computers in your network. Such servers typically have two connector queues: one used for transactional messages and one used for nontransactional messages. When a Message Queuing client sends a message to a foreign computer, the message is first routed to a connector queue. The connector application then retrieves, converts, and forwards the message to the foreign computer.

Connector queues are created implicitly. They are not published in Active Directory and are transparent to the Message Queuing applications sending messages to a foreign queue. From the standpoint of applications, sending a message to a foreign queue is identical to sending a message to a Message Queuing queue. A foreign queue is a part of the foreign messaging system but is exposed to the Message Queuing environment.

For more information on communicating with foreign computers, see Foreign computers and sites.


Queue names

The following sections describe the various ways to designate Message Queuing queues. Queues are specified using path names, format names, and queue aliases. For more information on the types of queues mentioned here, see Queues.

Path names

The path name of a queue consists of the name of the computer hosting the queue and the name of the queue separated by a slash in the form ComputerName\QueueName, except for a public queue located on the local computer where the path name is in the form .\QueueName. The names of private queues are prefixed by the string private$ separated by a slash. Thus, the path name of a private queue has the form ComputerName\private$\QueueName or .\private$\QueueName for a private queue located on the local computer.

Format names

Format names are used mostly by Message Queuing applications to perform tasks programmatically. However, they are also used in some administrative tasks (for example, in creating queue aliases and multiple-element format names), and administrators must have an understanding of format names to make correct decisions. The following sections describe most of the types of format names used in Message Queuing.

Direct format names

Direct format names are used to reference public or private queues without accessing the directory service. Message Queuing can use the information provided by direct format names to send messages directly to their destination. Thus, direct format names can be used to send and receive messages in workgroup mode, to send messages to computers on the Internet, and to send messages directly to a computer.

The following is the general format of direct format names. Note that public, private, and (for MSMQ 2.0 or later clients and servers) computer system queues can be accessed directly.

Direct format names contain the string DIRECT= followed by the location of the queue and its name. The following is the general format of direct format names for public, private, system, and URL-named queues (note that the format name string is a null-terminated Unicode string):

DIRECT=ComputerAddress\PublicQueueName
DIRECT=ComputerAddress\PRIVATE$\PrivateQueueName
DIRECT=ComputerAddress\SYSTEM$;SystemQueueName
DIRECT=HTTP://URL_Address/msmq/PublicQueueName
DIRECT=HTTPS://URL_Address/msmq/PublicQueueName
DIRECT=HTTPS://URL_Address/msmq/private$\PrivateQueueName

The computer address can be specified in two forms: as the network address of the target computer, which includes the network protocol TCP, or as any name for the target computer that is supported natively by the underlying operating system, where OS is used to indicate that the computer's native protocol will be used. The following examples illustrate these two forms:

DIRECT=TCP:157.18.3.1\MyPublicQueue
DIRECT=OS:elvisp.ms.com\MyPublicQueue

In the case of a URL-named queue, the queue name is preceded by the string msmq separated by a slash. For example, the following format name can be used to reference "MyPublicQueue"
DIRECT=HTTP://URL_Address/msmq/MyPublicQueue

Public format names

Public format names and direct format names are used to reference public queues. When a public format name is used, Message Queuing uses its internal routing algorithm to define the route to the destination queue. When a direct format name is used, the message is sent directly to the destination queue.

When Message Queuing detects a public format name, it queries the directory service to determine what computer is currently hosting the queue, what protocol the host computer uses, and any other information it needs to rout a message to the queue.

Public format names contain the string PUBLIC= followed by the identifier assigned to the queue when it was created. This identifier is the GUID listed for the queue object in Active Directory. The following is the general format used to reference a public queue and its associated queue journal:

PUBLIC=QueueGUID
PUBLIC=QueueGUID;JOURNAL

A public format name is strictly equivalent to the identifier of the queue except that a public format name is formatted as a string rather than as binary data. The following is an example of a public format name string (note that the format name string is a null-terminated Unicode string).

PUBLIC=308FB580-1EB2-11CA-923B-08002B1075A7

Note that the location of the public queue (the specific computer hosting the queue) is not part of its public format name. This allows message operations to succeed when using public format names regardless of the location of the queue; a public queue can be relocated to another computer and the format name remains valid. This is not true of direct format names that are bound to a specific location.

Private format names

Private format names and direct format names are used to reference private queues. When a private format name is used, Message Queuing uses its internal routing algorithm to define the route to the destination queue. When a direct format name is used, the message is sent directly to the destination queue.

When Message Queuing detects a private format name, it does not refer to the directory service for information about the queue. However, it does use the directory service to look up information about the computer for routing purposes.

Private format names contain the string PRIVATE= followed by the identifier of the computer where the queue is registered and a hexadecimal number that identifies the queue. The following is the general format used to reference a private queue and its associated journal:

PRIVATE=ComputerGUID\QueueNumber
PRIVATE=ComputerGUID\QueueNumber;JOURNAL

The following is an example of a private format name string (note that the format name string is a null-terminated Unicode string).

PRIVATE=ae0c5671-f190-12ce-ae10-00dd0114290f\0000000d

Distribution list format names

Distribution list format names are used to reference distribution lists (group objects) stored in Active Directory. The distribution list identifier is the GUID listed for the distribution list (group) object in Active Directory.

Distribution list format names contain the string DL= followed by the distribution list identifier. This identifier is the GUID listed for the distribution list (group) object in Active Directory. The following is the general format used to reference a distribution list with optional inclusion of the domain name:

DL=DistributionListGUID[@DomainName]

The following is an example of a distribution list format name string (note that the format name string is a null-terminated Unicode string).

DL=ae0c5671-f190-12ce-ae10-00dd0114290f

To retrieve information about a distribution list, Message Queuing tries to resolve the DL format name to the corresponding Active Directory object in three steps:

  1. If the domain name is included, it tries to bind to the Active Directory group object using this domain name.
  2. If this attempt fails or the domain name is not specified, it allows Active Directory to use serverless binding to find the best domain controller in the default domain.
  3. If this also fails, it tries to query the global catalog.

A distribution list format name can be an element of a multiple-element format name. In this respect, the analogy to a queue format name is preserved.

For more information on distribution lists, see Distribution lists.

Multiple-element format names

A multiple-element format name is formed as a concatenation of one or more public, private, direct, or distribution list format names separated by commas. Thus, different kinds of format names used in Message Queuing can be used together as elements of a multiple-element format name. The following example shows a multiple-element format name that contains a direct format name, a public format name, and a distribution list format name.

DIRECT=ComputerAddress\QueueName,PUBLIC=QueueGUID,DL=DL_GUID

Note that a multiple-element format name containing an element that points to a public queue or a distribution list cannot be used when there is no access to Active Directory.

Multiple-element format names cannot contain the format names of read-only queues, such as queue journals, computer journals, or dead-letter queues. An error is returned if the format name of a read-only queue is included in the multiple-element format name.

For more information on multiple-element format names, see Multiple-element format names.

For more information on these and other types of format names, such as machine and connector format names, refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.


Queue aliases

Message Queuing 3.0 provides support for referencing queues with an Active Directory object called a queue alias, which can be used to reference queues that might not be listed in Active Directory.

Queue aliases are published in Active Directory, and in this respect, they resemble public queues.

Using a queue alias provides the following benefits:

  • A queue alias can point to a public, private, or direct single-element format name used to reference a queue. Messages are sent to the queue or queues named in the corresponding format name. The validity of the format name and the existence of the queue to which a queue alias points are not tested when the alias is created. A queue alias thus points to a single queue, but it does not function as a queue because messages are not sent to it, but only to the queue or queues named in the corresponding format name. For more information on format names, see Queue names.
  • A queue alias can serve as a tool to reference a private queue and URL-named queues included in distribution lists. While queue aliases can point to any queue, including private and URL-named queues, distribution lists can only include explicit references to destinations published in Active Directory; that is, to public queues, queue aliases, and other distribution lists, but not to private and URL-named queues. Thus, a queue alias can serve as a tool for including private and URL-named queues in distribution lists.
  • When a queue alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias. A queue referenced by a queue alias can be changed without having to change a distribution list that references it.
  • A queue referenced by the queue alias can be changed without changing the alias reference. The alias can be used as a constant reference, as in a distribution list, even though the queue it represents may change.
  • Queue aliases can be used to reference a queue that is not listed in the directory service. This includes private queues or queues from another organization.
  • Queue aliases can be used to send HTTP messages by referencing the destination queue using a direct format name.
  • Multiple aliases can be created for a single physical queue.

User interfaces are provided in Active Directory Users and Computers for creating and deleting queue aliases as well as for viewing and changing their properties. For more information on performing these tasks, see Create queue aliases, View or change properties of queue aliases, and Delete queue aliases.

The queue alias is a new object in Windows Server 2003 family. Thus, it can be used only in Windows Server 2003 family domains and cannot be accessed by computers running earlier versions of Windows.


Target journaling

Target journaling is the process of storing copies of incoming messages on the computer hosting the applicable destination queue. Target journaling is configured on a per-queue basis. If you enable target journaling, Message Queuing sends a copy of any message you retrieve from a queue to the corresponding queue journal. Target journaling lets you keep track of messages even after they have been retrieved. Note that this does not include messages purged from the queue. For more information, see Purge all messages in a queue. Peeking at messages does not remove them from the queue. For more details, see Managing messages.

When enabling target journaling, consider the following:

  • Target journaling is enabled by setting the journaling level of the queue. This can be set both when the queue is created or later.
  • You must periodically clear messages from the queue journal to remove messages that are no longer needed. Message stored in the queue journal count against the quota of the journal and the quota of the computer where the queue journal resides (the computer quota is set by the administrator).
  • If the journal or computer quota is exceeded, Message Queuing will not send copies of the messages to the journal when the messages are received, and those messages will be lost.
  • A copy of each message retrieved from the applicable queue is transferred to the corresponding queue journal. This does not include messages removed from the queue when their time-to-reach-queue lifetime expires. For more information, see Message timers.

A queue journal is automatically created for each queue. It is listed as Journal messages under the applicable queue in Computer Management and Active Directory Users and Computers. Target journaling is disabled by default. For information on how to enable target journaling, see Enable or disable target journaling.


Source journaling

Source journaling is the process of storing copies of outgoing messages on the source computer. It is configured on a per-message basis and is a property that is set programmatically by a Message Queuing application. Source journaling allows you to track the messages sent by a computer, and can be used to track messages that were sent successfully, messages that could not be delivered, or both. Source journaling is disabled by default.

There are two types of sources journaling, positive source journaling and negative source journaling.

Positive source journaling

You can track messages that were successfully sent by the local computer, so that when you send the message to remote destination queues, a copy of the message is placed in the source computer's journal if the message is sent successfully. This is known as positive source journaling. Note that this does not mean the message has successfully reached its destination queues, only that the local computer was able to send the message.

When messages are sent to local destination queues, the message can be placed in one of two journal queues:

  • If the local destination queue has not enabled target journaling, a copy of the message is saved to the computer's journal queue only after the message has been removed from the local destination queue. This is the default setting.
  • If the local destination queue has enabled target journaling, a copy of the message is saved to the queue's journal after the message is removed from the queue. The message is not, in this case, stored in the computer's journal queue. Message Queuing never stores more than one copy of a message on a single computer at one time.

Negative source journaling

You can track messages that were not delivered. This type of journaling is known as negative source journaling. When you specify this type of source journaling, Message Queuing reacts differently depending on the type of message you send:

  • For nontransactional messages, a copy of the message is placed in the dead-letter queue of any computer that cannot deliver the message. This can be the source computer, or any routing server used to pass the message on to its destination. Failure indicates that the source queue manager on the computer cannot pass the message to the next hop.
  • For transactional messages, a copy of the message is placed in the transactional dead-letter queue of the source computer only if Message Queuing does not confirm that the message was retrieved from its destination queue.

Source journaling for transactional messages

For transactional messages sent to transactional queues, journaling can be applied by setting the journal property of a transactional message. The following property values can be set programmatically:

  • The default value. Source journaling is disabled. Message Queuing does not store copies of the message in the computer journal on success nor in the applicable dead-letter queue on failure.
  • Negative source journaling is requested. The message is stored in the applicable dead-letter queue on failure, but no copy is stored in the source computer journal on success.
  • Positive source journaling is requested. A copy of the message is stored in the source computer journal if the message was successfully delivered to the target computer, but no copy is stored in the applicable dead-letter queue on failure.
  • Both negative source journaling and positive source journaling are requested. Copies of the message are stored in the source computer journal on success and in the applicable dead-letter queue on failure. This is the recommended setting.

Differences in source journaling for transactional messages between MSMQ 1.0 and later versions

MSMQ 1.0 treated source journaling for transactional messaging differently than MSMQ 2.0 and Message Queuing 3.0. MSMQ 1.0 only allows you to specify positive source journaling to choose if you want to save copies of messages sent successfully. MSMQ 1.0 always uses negative source journaling, and places a copy of a non-confirmed transactional message in the transactional dead-letter queue.

MSMQ 2.0 and later versions allow complete control over source journaling. (If you are running MSMQ 1.0 applications on an MSMQ 2.0 computer, you can force the computer to use the MSMQ 1.0 semantics by setting the XactDeadLetterAlways registry entry to 1. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Managing source journals

When you store messages in a journal or dead-letter queue, clear these queues periodically to remove messages that are no longer needed. Messages stored in journal and dead-letter queues count against the quota for the computer where the queues reside (the computer quota is set by the administrator).

When source journaling is enabled, a copy of the outgoing message is placed in the single computer journal of the source computer, which is listed as the Journal messages queue in the System Queues folder in Computer Management and Active Directory Users and Computers. This occurs either when the message arrives at the computer hosting the destination queue or when the message reaches a Message Queuing routing server that is one hop closer to the target computer. A Message Queuing server that routes messages for clients does not store copies of those messages in its computer journal.

Outgoing messages sent by dependent clients are placed in the computer journal on the supporting Message Queuing server.


Messages

In the context of Message Queuing, messages consist of a body and a set of properties. Message bodies can contain text or any form of binary information, and can be encrypted. Most message properties are specified programmatically by Message Queuing applications. Some properties, such as the sender's security ID (SID) and the message ID, are specified by Message Queuing. Message properties cannot be encrypted. A message, including the body and all specified properties, can be no larger than 4 megabytes (MB) in size. For details, see the following links:

  • For information about different types of message classes, see Message types.
  • For information about message properties and the default lifetime of a message, see Message properties.
  • For information about setting default lifetimes for messages, see Message timers.
  • For information about how message priority is determined, see Message priority.
  • For information about express and recoverable message delivery, see Message delivery methods.
  • To learn about the characteristics of transactional messages, see Transactional messaging.
  • To learn about message storage and message storage quotas, see Message storage.


Message types

In the context of Message Queuing, messages can be of different types, and consist of a body and a set of properties. Message types, also called message classes, indicate the message function or disposition. The following message types are supported:

  • Normal messages. All messages created by Message Queuing applications are normal messages. Normal messages can be sent to public, private, and dead-letter queues of both the nontransactional and transactional types, and copies of normal messages, which are themselves normal messages, can be sent to journals when source or target journaling is enabled. Normal messages do not contain status information; such information is contained in acknowledgment, report, and response messages.
  • Acknowledgment messages. Acknowledgment messages report the status of normal messages. These messages are nontransactional messages that are sent to the administration queues specified in the original messages by the sending application. Acknowledgment messages can be either positive or negative. A positive acknowledgment message indicates that the original message arrived at the target queue and that it was received (removed by the receiving application). A negative acknowledgment message indicates that the original message did not reach the target queue before its time-to-reach-queue (TTRQ) elapsed, did not reach the target queue for a specified reason, that it was not received before its time-to-be-received (TTBR) elapsed, or was not received for a specified reason.
  • Report messages. Report messages indicate the route followed by a message as it proceeds from a source computer with tracking enabled to its destination on a remote computer. Report messages are sent to the report queue on a source computer for all messages sent from that computer with the message route tracking flag set or for only test messages sent from it.
  • Response messages. Response messages are messages sent by a receiving application to response queues specified by a sending application.

For more information on the various types of queues that these messages can be sent to, see Queues.

For more information on the various reasons why messages do not reach the target queue or are not received that can be specified in the message class, refer to the Message Queuing Software Development Kit (SDK). For more information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.


Message properties

In the context of Message Queuing, messages consist of a body and a set of properties, and can be of various types. Message bodies can contain text or any form of binary information, and can be encrypted.

Every message has properties. Some message properties are read-only, and the majority can only be modified programmatically. For more information, refer to the Message Queuing Software Development Kit (SDK). For more information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.

Default message lifetime

Through the Computer Management snap-in, you can set the default lifetime of messages in your network, also known as the time-to-reach-queue (TTRQ) value. Messages are considered expired when the TTRQ value is reached. If you do not specify a TTRQ value, the following default setting apply:

  • 4 days for messages sent from the following types of computers:
    • Computers running Message Queuing 3.0 in workgroup mode.
    • Clients running Message Queuing 3.0 that belong to a completely new Windows Server 2003 domain.
    • Clients running Message Queuing 3.0 that join an existing domain provided weakened security was not enabled for that forest.
  • 90 days for messages sent from the following types of computers:
    • Any computer in a migrated enterprise and computers running MSMQ 1.0 or MSMQ 2.0 in Windows 2000 and Windows NT 4.0.

For information on how to set the lifetime of messages on your network, see Set the default lifetime for messages.

You can view the properties of messages, and you can choose which message property columns appear by default in the details pane (usually the right pane) of the snap-in and in what order. For instructions on how to view message properties, see View message properties. You can choose the columns to be displayed by selecting a message in the Computer Management snap-in, and then clicking the View menu, and selecting Add/Remove Columns. The following message properties are available for selection.

Message property | Explanation
Admin Queue | Specifies the name of the administration queue used for system-generated acknowledgment messages.
Admin Queue Name Length | Indicates the length (in Unicode characters) of the format name buffer of the administration queue.
Application-specific | Specifies application-generated information such as single integer values or application-defined message classes.
Authenticated | Indicates whether the message was authenticated at the request of the sending application.
Correlation | Specifies an application-generated correlation identifier that the receiving application can use to sort messages.
Delivery Mode | Specifies how Message Queuing delivers the message to the queue, in either recoverable, or express mode. For more information, see Message delivery methods.
Destination Queue Format Name | Indicates the name of the destination queues to which the message was sent.
Destination Queue Format Name Length | Indicates the length of the format name buffer (in Unicode characters) allocated by the receiving application.
Encrypted | Specifies whether the message body of a private message was encrypted.
Encryption Algorithm | Specifies the encryption algorithm used to encrypt the message body of a private message.
Hash Algorithm | Identifies the hashing algorithm that Message Queuing uses when authenticating the message.
Label | Specifies the label of the message.
Label Length | Identifies the length (in Unicode characters) of the message label buffer.
Message ID | Indicates a unique identifier for each message in your enterprise. This includes application-generated and system-generated messages sent by Message Queuing.
Message Lookup ID | Indicates the lookup identifier of the message. The receiving application can use this identifier to peek at or retrieve the message from the queue without navigating the queue.
Priority | Indicates the message priority. A higher number indicates a higher priority message. The default value is 3.
Recipient Queue | Specifies the queue to which application-generated response messages are returned.
Recipient Queue Name Length | Indicates the length (in Unicode characters) of the response queue format name buffer. This is used by the receiving application to allocate a buffer for the response queue specified by the sending application.
Response Queue | Specifies the response queues used for returning application-generated response messages.
Response Queue Format Name | Specifies the response queues used for returning application-generated response messages.
Response Queue Format Name Length | Indicates the length (in Unicode characters) of the format name buffer allocated by the receiving application.
Response Queue Name Length | Indicates the length (in Unicode characters) of the format name buffer of the response queue format name buffer.
Sender ID | Identifies who sent the message, and used primarily by the receiving queue manager when authenticating a message.
Sender ID exists | Identifies who sent the message, and used primarily by the receiving queue manager when authenticating a message.
Sender ID Length | Indicates the length of the Sender ID.
Size | Indicates the size of the message body.
Source Computer | Provides the globally unique identifier (GUID) of the computer that sent the message.
Time Arrived | Indicates the date and time that the message was received.
Time Sent | Indicates the date and time that the message was sent by the source.
Tracked | Specifies whether Message Queuing traces the route of the message.


Message timers

Message Queuing provides two timers to help you maintain better control of your messages: a time-to-reach-queue and a time-to-be-received timer.

The time-to-reach-queue (TTRQ) timer determines how long a message has to reach the queue manager of the target queue. Typically, this timer is set to a value less than the time-to-be-received setting.

The time-to-be-received timer determines how long a message remains in the system, starting from the time the message is sent to the time it is removed from the target queue.

Through the Computer Management snap-in, you can set the TTRQ value. If you do not specify a TTRQ value, the following default settings apply:

  • 4 days for messages sent from the following types of computers:
    • Computers running Message Queuing 3.0 in workgroup mode.
    • Clients running Message Queuing 3.0 that belong to a completely new Windows Server 2003 domain.
    • Clients running Message Queuing 3.0 that join an existing domain provided weakened security was not enabled for that forest.
  • 90 days for messages sent from the following types of computers:
    • Any computer in a migrated enterprise and computers running MSMQ 1.0 or MSMQ 2.0 in Windows 2000 and Windows NT 4.0.

For information on how to set the lifetime of messages on your network, see Set the default lifetime for messages.

The default setting for the time-to-be-received timer is that no limit is set.

When both timers are used and the time-to-be-received timer is set to a smaller value than the TTRQ timer, the time-to-be-received timer takes precedence. For example, if the time-to-be-received timer is set to 3 minutes and the TTRQ timer is set to 10 minutes, Message Queuing will discard the message after 3 minutes. A message is not allowed to remain in the system longer than the time specified by the time-to-be-received timer.

When a timer expires, Message Queuing discards the message. However, Message Queuing can also send a copy of the discarded message to the applicable dead-letter queue or it can send a negative acknowledgment message to an administration queue.

Discarded messages can be sent to dead-letter queues if the journal property of the message specifies a dead-letter queue. Copies of nontransactional messages are sent to the dead-letter queue on the computer where the timer expired. Copies of transactional messages are sent to the transactional dead-letter queue on the source machine.

Acknowledgment messages are returned if a timer expires and the acknowledgment property of the message specifies full or negative acknowledgments. Message Queuing sends the appropriate negative acknowledgment message to the administration queue specified by the message.


Message priority

The order in which messages are sent to a queue on the destination computer, their priority, is determined first by the queue priority (also known as the base priority), and then by the message priority. The queue priority for public queues listed in Active Directory can be set to any number from -32768 to 32767. The default queue priority is 0.

Message priority affects how Message Queuing handles the message while it is in route, as well as where the message is placed in the queue. Higher priority messages are given preference during routing, and inserted toward the front of the queue. Message Queuing applications can set the message priority for nontransactional messages in the range from 0 to 7, where 7 represents the highest priority. The default value is 3. Messages with the same priority are placed in the queue according to their arrival time. Message Queuing automatically sets the priority level of transactional messages to 0.

Messages are sent to public queues based on the sum of the destination queue's priority and each message's priority. Messages with the highest resultant priority value are sent first.

Private queues do not support queue priority. Messages are sent to private queues based only on message priority.


Message delivery methods

Two basic message delivery methods are supported: express and recoverable. The choice between the two is essentially a choice between better performance with minimal resource use (express delivery), and reliability and recovery after a failure (recoverable delivery). The message delivery method is specified programmatically by the sending application. Recoverable messaging can also be further differentiated into transactional and nontransactional messaging.

Express messaging

Using express messaging means that messages are stored in RAM memory during routing and delivery, providing extremely fast performance but no recoverability if any computer that the message passes through fails. Notably, express messages are lost whenever the Message Queuing service is stopped.

Too many express messages accumulating in RAM may cause paging out to disk, leading to performance degradation. Thus, it is not recommended to store more express messages than physical memory can hold.

Express messages can, however, survive a network failure. For example, if a Message Queuing application sends express messages through a Message Queuing server and the network link between the Message Queuing server and the destination computer fails, the Message Queuing server continues to store the messages in memory. However, if the Message Queuing server fails before the network link is restored, the express messages are lost.

Caution

  • If you are running Message Queuing in a server cluster, express messages will be lost during a failover from one node to another.

Recoverable messaging

Using recoverable messaging means that messages are written to disk during routing and delivery, making delivery somewhat slower than the use of express messaging, but ideal when failures cannot be tolerated or when computers shut down while messages remain in queues (such as for mobile clients on laptop computers). If a computer fails or is shut down while sending a message, the message is stored on disk. When the computer is restarted and the Message Queuing service restarts, the sending process is automatically resumed.

All recoverable messages are stored on disks in memory-mapped files. Performance gains can be realized by employing several physical disks to store recoverable messages. For more information, see Disk considerations.


Transactional messaging

Sending and receiving applications can indicate that they want to send or retrieve messages within the context of a transaction, known as transactional messaging. Sending or retrieving messages outside the context of a transaction is referred to as nontransactional messaging. Transactional message is only used when you want to perform several tasks in such as way that all tasks, including non-Message Queuing operations, will all succeed or all fail.

Transactions are characterized by their ACID (atomicity, consistency, isolation, durability) properties:

  • Atomicity. Atomicity refers to the all-or-nothing behavior of a transaction. When a transaction consists of a series of actions, all the actions are treated as a single operation that is either completed successfully or not executed at all.
  • Consistency. Transactions transform a system from one valid state to another.
  • Isolation. Multiple transactions that are executed concurrently have no effect on one another during their execution. It appears to each transaction that the other transactions are executed either before or after it.
  • Durability. After transactions are executed, their effects are permanent despite system or network failures.

When transactional messaging is used, the sending or receiving application has the opportunity to commit to the transaction (all the operations have succeeded), or to abort the transaction (one of the operations failed) so all changes are rolled back. When a transaction is aborted all operations are rolled back to the state when the transaction was invoked.

When sending messages within a transaction, all the messages are sent together and in the order they were sent, or they are not sent at all. Message Queuing guarantees that all messages sent within the transaction will arrive exactly once if they can be delivered, and in the order that they were sent. When retrieving messages within a transaction, all the messages are removed from the queue or they are placed back in the queue in their original position in the queue. Note that transactional messages cannot be sent to a multicast address, and that peeking at messages make no sense in the context of a transaction.

In Message Queuing, a transaction can encompass multiple sending and receiving operations. However, the same message cannot be sent and received within a single transaction. In a case where a transaction consists of sending multiple messages, either all the messages are transmitted in the order in which they were sent (if the transaction is committed), or none of the messages are transmitted (if the transaction is aborted). If multiple messages are sent to the same queue, Message Queuing guarantees that they arrive in the destination queue exactly once and in the order in which they were sent within the transaction. For more information, see Sending transactional messages to multiple destinations.

Message order

Messages that are to be delivered in the order in which they were sent belong to the same message stream. Each message in a stream carries a sequence number, identifying the message in the stream, and a previous number, which equals the sequence number of a previous message in the stream. The message whose sequence number equals the previous number of a message must be present in the destination queue before the message can be delivered. The first message in a stream always carries a previous number equal to zero.

Likewise, a transaction can consist of removing multiple messages from a queue. The messages are removed from the queue only if and when the transaction is committed; otherwise, they are returned to the queue and can be subsequently read during another transaction.

In addition, Message Queuing guarantees that messages sent in consecutive transactions initiated from the same computer to the same destination queue will arrive in the order in which the transactions were committed. Moreover, as in the other cases of sending transactional messages, each message, if it arrives at the destination queue, will arrive exactly once.

Transaction performance

Transactional messaging is slower than nontransactional messaging because messages are written to disk more than once and greater computer resources are required. Transactional messages can be sent only to transactional queues on the local computer or a remote computer (and nontransactional messages cannot be sent to transactional queues). When messages are received within a transaction, they can be retrieved only from a local transactional queue. However, messages can be retrieved in nontransactional operations from local and remote transactional queues.

In the general case, there are two ways to implement transactional messaging, as follows:

  • As external transactions
  • As internal transactions

External transactions

External transactions are used if resources other than those that Message Queuing can provide need to be part of the transaction. They are coordinated by the Microsoft Distributed Transaction Coordinator (DTC), which is now part of Component Services (formerly known as Transaction Server). Message Queuing then serves as a resource manager under the control of the DTC. Using the DTC as the transaction manager for Message Queuing, transaction-based applications can be implemented, ensuring that all actions either all succeed or all fail. For example, a Message Queuing application can send a message and update a database in the same transaction. The DTC ensures that either both actions succeed (both actions are committed) or neither action is executed (both actions are aborted). The DTC is automatically installed on each computer during Windows Server 2003 family operating system installation for local transactions. To enable network DTC required for Message Queuing transactions across the network, see Enable network DTC access.

For more information on the DTC, see Using Component Services, in the Component Services Help file.

You can use external transactions to send or receive a message that is part of any COM-compliant resource operation and to send or receive multiple messages that are part of a single transaction.

COM+ Transactions

When your application is running in the COM+ (Component Services) environment, Message Queuing can send and receive messages within a COM+ transaction by using the current COM+ transaction object if it is available. Message Queuing, COM+ (Component Services), and DTC work together for this type of transaction.

XA-Compliant Transactions

Message Queuing can work in transaction systems that have an XA-compliant transaction manager. Because of this, DTC is used as a transaction process monitor and Message Queuing is a resource manager.

Internal transactions

Because they have less overhead, internal transactions execute much faster than external transactions coordinated by the DTC. Use internal transactions if there is no need to coordinate Message Queuing operations with operations involving external resources that require the use of the DTC. Message Queuing provides a transaction coordinator that supports only itself as a resource manager.

You can use internal transactions to do the following:

  • Ensure that a message is delivered only once (called exactly-once delivery).
  • Ensure that all messages sent from one computer to another are delivered in order (called in-order delivery).
  • Using acknowledgments, confirm that the transaction was successful (messages were received). You can also use acknowledgments to confirm that messages reached (or were removed from) the destination queue.

There is a special type of internal transaction that Message Queuing provides when sending a single message:

Single-message transactions

When sending a single message, Message Queuing provides a single-message transaction that implicitly uses the Message Queuing internal transaction, and consists of a single operation performed on a single message. A single-message transaction can be used to request guaranteed exactly-once delivery of a single message sent to a transactional queue. The single-message transaction provides the best performance of all transaction types for sending a message. In addition to exactly-once delivery, a single-message transaction is faster than an external transaction.

For more information on transaction types, refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.

Order acknowledgment messages for transactional HTTP messages

Transactional messages are to be delivered exactly once and in the order in which they are sent. When transactional messages are sent over HTTP from the internal network of an enterprise to the Internet, the internal name of the sender's order queue must be translated into a logical address using a mapping to direct the order acknowledgment messages from the receiving computer outside the sender's enterprise, back to the sender's order queue. For more information, see Store and forward servers.


Message storage

Message storage size limits, or quotas, specify the maximum cumulative storage size for all messages contained in a particular queue or on a computer. There are additional storage size limits, or quotas, that specify the maximum cumulative storage size for all journal messages contained in a particular queue journal or for messages contained in the computer journal and the dead-letter queues.

By understanding how messages are stored locally, you can determine the disk space being used to store messages, and you can inspect the properties of local queues.

The following sections discuss these concepts.

Quotas for messages

Quotas for messages can be divided into computer quotas and queue quotas. These quotas specify the cumulative size for all messages (including journal messages) contained in a particular queue or on a computer.

Computer quotas

Computer quotas specify the cumulative limit for all messages stored in destination queues, outgoing queues, and queue journals on a computer. Computer quotas are not applied towards internal private queues. Unlike queue quotas, when a computer quota is reached, no messages can be delivered to any queue or journal on the computer. No negative acknowledgment message is generated, and an error is returned for messages sent locally, while a remote computer tries to resend until one or more messages are removed (read) from a queue on the computer. Computer quotas are set for Message Queuing servers and independent clients. Computer quotas set on Message Queuing servers that support dependent clients apply both to the server and to all its dependent clients. Computer quotas for message storage and journal storage are set separately. For instructions on setting the message storage size for a computer, see Set the message storage size for computers. For instructions on setting the journal storage size for computers, see Set the journal storage size for computers. Following a new installation of Message Queuing, or an upgrade from Windows 2000, the default limit for these storage sizes is 8 gigabytes (GB).

Queue quotas

A queue quota specifies the cumulative storage size (number of bytes) available for all messages stored in a particular queue, whereas a computer quota limits the total storage available for all messages in destination queues, outgoing queues, and queue journals on the computer. When a queue quota is reached, messages can no longer be sent to the queue until one or more messages are retrieved (removed from the queue by a Message Queuing application). Queue quotas can be set for all queues. Queue quotas for message queues and journal queues are set separately. For instructions on setting the quotas for regular messages, see Set the message storage size for queues. For instructions on setting the storage size for the computer journal and dead-letter queues, see Set the journal storage size for queues.

Queue quotas and computer quotas can be set independently, and only on Message Queuing servers and independent clients. Message Queuing servers and independent clients can store messages only up to a certain limited maximum number on each computer, which depends on several factors. Quotas set on Message Queuing servers that support dependent clients apply both to the server and to all its dependent clients, since dependent clients do not store messages locally. Thus, a Message Queuing server supporting several dependent clients can hold no more than its own maximum number of messages divided by the number of dependent clients. For example, if the computer quota for the server is 50 megabytes (MB) and one dependent client creates 50 MB of messages, the server and the other dependent clients supported by the server cannot send messages until the total message storage size drops below that quota.

The computer quota is enforced first, regardless of the cumulative queue quotas. For example, if you specify a 10 MB quota for each of six queues on a computer and a 50 MB quota for the computer, Message Queuing enforces the 50 MB computer quota first before each queue quota is reached. However, each queue quota still prevents any one queue from storing more than 10 MB of messages.

Local message storage

The files used to store messages are located in the Msmq\Storage and Msmq\Storage\Lqs folders (under \Windows\System32 by default).

Messages are stored in memory-mapped files (.mq files) on the hard disk of the source computer, destination computer, or intermediate Message Queuing server with routing services enabled. Disk space is allocated for both express and recoverable messages in 4 MB increments as needed. For each recoverable message, the memory-mapped message file is written to disk, ensuring that the message is recoverable. For express messages, memory-mapped files are written to disk only when the computer does not have sufficient resources to hold the message in memory.

The computer sending the message creates the memory-mapped files. Message Queuing servers used to route messages also store messages in memory-mapped files. If source journaling is used, the memory-mapped files are located on the source computer. If target journaling is used, they are located on the destination computers. Message Queuing servers store all message files for the dependent clients they support.

To help safeguard your system against attacks by intruders, deleting, editing, or adding any file under the Msmq\Storage folder generates an audit entry in the security log.

The memory-mapped files can be stored using any file system supported by Windows Server 2003 family. However, because the NTFS file system for Windows Server 2003 family provides more reliable file recovery after a power failure or system crash, it is highly recommended for Message Queuing servers. In addition, it is recommended that you back up the folders where the message storage files are kept for fault tolerance. If the hard disk that contains the message files fails and if the data cannot be recovered using a backup program or the message backup/restore utility provided with Message Queuing, the messages will be lost. For more information on the message backup and restore utility, see Backing up and restoring messages.

Files in the Msmq\Storage folder

Files with an .mq extension represent memory-mapped files in which messages are stored. The .mq file name extension is prefixed with a letter representing the type of message it is currently storing, as follows:

  • r — Express messages (Express messages are normally stored in RAM, not on disk. This file is used when there is no more available RAM.)
  • p — Recoverable messages.
  • j — Journal messages.
  • l — Message logger file for interpreting recoverable and journal message files.

An .mq file does not represent one particular queue. Messages from multiple queues can be stored in one .mq file, and messages from a single queue can be stored in multiple .mq files. However, a single message cannot span multiple files. This is the reason for the 4 MB limit in message size.

The QMLog file is a history of all transactional processing. When the log is full, the oldest data are overwritten as new entries are made. To allow such continuous cyclic writing to the QMLog file, the message sequence and the state of all active transactions are periodically saved to the following files, respectively:

  • MQInSeqs.lg1
  • MQInSeqs.lg2
  • MQTrans.lg1
  • MQTrans.lg2

The MQInSeqs.* files are referred to as the message logger files, and the MQTrans.* files are referred to as the transaction logger files.

The *.lg1 and *.lg2 files are written to in an alternating pattern to ensure that one file in each pair is recoverable if the other is corrupted during a write operation.

Files in the Msmq\Storage\Lqs folder

Files in the Lqs (local queue storage) folder are text files that describe properties of the local queues.

File names with the nnnnnnnn.hhhhhhhh format represent private queues. The nnnnnnnn portion is the queue number (which is included in the direct format name of the queue). The hhhhhhhh extension is a hash of the queue path and is used for quick lookup.

File names with the aaaaaaaabbbbccccddddeeeeeeeeeeee.hhhhhhhh format represent local public queues. The left-hand 32-character portion of the file name is the globally unique identifier (GUID) of the queue. The hhhhhhhh extension is a hash of the queue path.

Warning

  • If you delete the files in the Lqs folder, you will destroy the internal private queues, in which messages needed for internal Message Queuing operations are stored and without which the Message Queuing service cannot start running. Check for Message Queuing events in Event Viewer. The most common symptoms of the loss of these queues are events with IDs 2020 and 2052.
  • The message store location must only be modified using the Storage tab, in Computer Management, Services and Applications, Message Queuing properties.


Triggers

Message Queuing Triggers is a service that you can use to associate the arrival of each incoming message at a queue with a response. The response depends on the contents of the message and may invoke either a COM component or a stand-alone executable program. For details, see the following links:

  • For an overview of what triggers are and how to define them, see Triggers overview.
  • For more detailed information on conditions and actions you can specify when creating rules for triggers, see Trigger rules.


Triggers overview

Message Queuing Triggers is a service that allows you to associate the arrival of each incoming message at a queue with a response that depends on the contents of the message and may invoke either a COM component or a stand-alone executable program. You can use Message Queuing Triggers to define business rules that can be invoked in response to such messages without any additional programming. Ordinarily, to provide such message-handling functionality, application developers would have to create a receiving application that invokes specific behavior on a per-message basis. By using Message Queuing Triggers, specific behavior can be invoked at the queue level. Application developers no longer need to write any infrastructure code to provide such message-handling functionality. Triggers can be associated with queues located on the local computer and a remote computer.

Triggers are not installed by default during Message Queuing installation. For information on installing triggers, see Installing Message Queuing triggers.

Triggers security

By default, the Message Queuing Triggers service runs under the Network Service account. Services that are running under this account interact with the network using the credentials of the computer account, and this account has the same level of access to resources and objects as members of the Users group accounts. You can specify a less secure account for the Triggers service; for example, the Local System account, allowing access to the entire domain. Note that the Triggers service running under the Network Service account does not interact with the desktop. If this functionality is required, you can configure the Triggers service to run under the Local System account and enable interaction with the desktop in Computer Management.

The account used must be able to access the queues with which triggers are associated. Specifically, the account must be granted the Log On As A Service permission and the Peek Message permission for all applicable queues. If the message processing type of a trigger is "retrieval" or "transactional retrieval," the user must be granted the Receive Message permission for that queue. If you change the security settings for a queue to enable a trigger to monitor it, you must stop and start Triggers to update the service's configuration before the trigger will start to work. Note that executable files invoked by triggers are invoked with the same security privileges as those assigned to the Triggers service.

The Triggers service must run under an account with administrator permissions.

Serialized and nonserialized triggers

Message Queuing triggers can be serialized or nonserialized. The type of triggers you define for a specific queue will affect how the Message Queuing Triggers service processes incoming messages. If you create multiple triggers for a particular queue and at least one of them is serialized, all the triggers will behave as serialized triggers, even if they are not defined as serialized. Triggers with the transactional-retrieval processing type can only be serialized.

A serialized trigger processes messages in the order in which they arrive, testing each message for the conditions of all the rules associated with it and performing all the applicable actions before moving on to the next message. When serialized triggers are defined, the throughput of the Message Queuing Triggers service is lower than for nonserialized triggers because the messages are processed one at a time and the service must wait until all the operations performed on each message are completed.

Nonserialized triggers process messages faster, but the messages are not necessarily processed in the order in which they arrived. Nonserialized triggers provide a faster throughput because the Message Queuing Triggers service does not wait for all the operations performed on one message to be completed before starting to process the next message. It is recommended that you use only one trigger with the serialized option because the order of trigger firing is random with respect to their GUIDs.

Trigger elements

Each trigger is associated with a specific monitored queue on the local computer and is invoked by the Message Queuing Triggers service for every Message Queuing message arriving at that queue. A trigger is configured to obey one or more rules. A rule is defined by one or more conditions and an action in the form of an executable file or COM component that is executed when all the conditions associated with the rule are evaluated as true.

A trigger is an automatic mechanism for implementing a specific action in response to a message event. In the context of Message Queuing Triggers, an event is defined as a set of one or more conditions that may be satisfied by a message arriving in a queue. The collection of all triggers on a particular computer is called the trigger set.

A condition is a criterion that is applied to a message when it arrives at a monitored queue. A condition can test only for a property of the message. Every condition or set of multiple conditions is associated with an action.

An action results when a condition or a set of multiple conditions is true. An action can be expressed as an executable and a parameter list, or as a COM component, a method, and a parameter list. You can also invoke other types of files by making them parameters of an .exe file. For example, you can invoke an .msc file by specifying mmc.exe as the executable file and the full path of the .msc file as a parameter.

A rule is a condition-action pair. A rule specifies the action that will be taken when a specific condition or set of conditions is true. The collection of all rules (for all triggers) on a particular computer is called the rule set.


Trigger rules

All rules created on the local computer are displayed in the Computer Management snap-in. You can attach multiple rules to a trigger. If you do so, the rules are executed in the order in which they are displayed in the Attached rules list on the second page of the New Trigger dialog box or on the Attached Rules tab of the YourTrigger Properties dialog box. You can change the priority (order of execution) of rules in this list by selecting a rule and clicking the applicable button. The rules displayed in the Rules list are disabled by default. To enable a rule for use with a trigger, you must attach the rule to the applicable trigger. For more information, see View or change properties of triggers and rules for triggers.

A rule is composed of one or more conditions and an action that is executed when the conditions are true. Each condition is applied to every message arriving at the monitored queue, and the result is either true or false. Multiple conditions must all be true for an action to be executed. If no condition is specified, a true value will always be returned. This is useful when you want a trigger to fire unconditionally every time a message arrives at the monitored queue. The conditions applied to a particular rule are listed in the Condition list on the Conditions page of the Properties dialog box for that rule. New rules are composed by selecting a supported initial string in the New condition list box and typing a concluding string in the text box below it. These conditions are summarized in the following table.

Condition | Description
Message label contains/does not contain | Tests whether the label of the newly arrived message contains (or does not contain) the string you specified. This string is case-sensitive.
Message body contains/does not contain | This applies only to messages with a string body type (VT_BSTR, VT_LPWSTR). Otherwise, the condition will always be false, and no action is invoked.
Message priority equals/does not equal/is greater than/is less than | Tests whether the priority of the newly arrived message satisfies the mathematical expression you specified.
Application-specific message number (AppSpecific) equals/does not equal/is greater than/is less than | Tests whether an application-specific message number satisfies the mathematical expression you specified.
Message source computer ID (SourceMachineGuid) equals/does not equal | Tests whether the source computer GUID equals (or does not equal) the value you specified.

The actions performed when a condition or set of conditions is true are expressed either in the form of a stand-alone executable file and parameters (arguments), or in the form of a COM component, a method, and parameters. You can specify one or more parameters to be passed per action.

The supported parameters are:

  • Message ID (as variant)
  • Message label (as string)
  • Message body (as variant)
  • Message body (as string)
  • Message priority (as number)
  • Message sending time (as date variant)
  • Message arrival time (as date variant)
  • Message correlation ID (as variant)
  • Message lookup ID (as variant)
  • Queue path name (as string)
  • Queue format name (as string)
  • Response queue format name (as string)
  • Administration queue format name (as string)
  • Application-specific message number (AppSpecific as long)
  • Trigger name (as string)
  • Trigger ID (as string)
  • Message source computer ID (SourceMachineGuid as string)
  • String literal
  • Numeric literal

These parameters are presented in the list box under Parameter on the Invocation Parameters dialog box, which can be accessed by clicking Parameters on the third page of the New Rule dialog box, as well as on the Action page of the Properties dialog box for a particular rule. Note that the Message Queuing Triggers service runs under the Network Service account, and that executable files invoked by triggers are invoked with the same security privileges as those assigned to the Triggers service. If your rule invokes a COM component, make sure that it can be successfully invoked from the security context used by the Triggers service, is properly registered, and has suitable dependencies.

By default, the Message Queuing Triggers service runs under the Network Service account. Services that are running under this account interact with the network using the credentials of the computer account, and this account has the same level of access to resources and objects as members of the Users group accounts. For heightened security, you can change the default Triggers service account to a more secure setting; for example, the Local Service account, which limits access to the local computer. You can also specify a less secure account for the Triggers service; for example, the Local System account, allowing access to the entire domain. Note that the Triggers service running under the Network Service account does not interact with the desktop. If this functionality is required, you can configure the Triggers service to run under the Local System account, and enable interaction with the desktop in Computer Management.

If your trigger invokes an executable file with command-line arguments, these arguments can be included as parameters of the string literal type. However, you must add a separate parameter for each command-line argument.

You can also use parameters to invoke other types of files that can be included as a command-line argument of an .exe file. For example, you can invoke an .msc file by specifying mmc.exe as the executable file and the full path of the .msc file as an invocation parameter of the string literal type.

Triggers and rules are created and modified by mqtrig.dll, but the service is implemented by mqtgsvc.exe. Therefore, information about the state of any new or modified trigger or rule must be passed to the service. This is done by sending a notification message to a specific internal private queue. The service reads each message sent to this queue, updates its internal data accordingly, and then deletes the message.

For more information on how to create rules, see Create and attach rules for triggers.


Multiple Destination Messaging

Message Queuing 3.0 includes a new model for one-to-many messaging. In previous versions of MSMQ, a single message could be sent to a single queue. Now, one-to-many messaging enables the same message to be sent to multiple recipient queues. This can be implemented in a number of ways. For details, see the following links:

  • To learn about implementing one-to-many messaging using an Active Directory distribution group object to encapsulate a collection of destination queues that can serve as a distribution list in Message Queuing, see Distribution lists.
  • To learn how messages can be sent programmatically to multiple destinations specified in the form of a multiple-element format name, see Multiple-element format names.
  • For information on how to send messages to a single destination IP address, to be received and processed by multiple IP hosts, see IP multicasting.


Distribution lists

Message Queuing 3.0 allows sending applications to send a single message to a list of destination queues. That list can be constructed dynamically in the form of a multiple-element format name or can be published and kept in Active Directory in the form of a distribution list. For more information on multiple-element format names, see Multiple-element format names.

A distribution list is a set of target queues and/or distribution lists that can be used to do the following:

  • Send transactional and nontransactional messages to multiple destinations.
  • Specify one or more administration queues for sending application-generated acknowledgment messages, when acknowledgment messages are requested.
  • Specify one or more response queues for sending application-generated response messages, when response messages are requested.

Distribution lists and Active Directory

Distribution lists are public lists that are published as distribution group objects in Active Directory. For more information, see Message Queuing objects. The explicit members of a distribution list must be destinations published in Active Directory; that is, public queues, queue aliases, and other distribution lists. Private queues and URL-named queues cannot be elements of a distribution list.

Private queues and URL-named queues, however, can be referenced indirectly in a distribution list through queue aliases. Queue aliases provide additional benefits when they are used in distribution lists. When a queue alias object is deleted, the alias is automatically removed from all distribution lists that reference the alias. A queue referenced by a queue alias can be modified without having to change a distribution list that references it. For more information on queue aliases, see Queue aliases.

Since distribution lists are objects in Active Directory, they cannot be used in workgroup or offline mode, in which there is no access to Active Directory. In these modes, messages can be sent to multiple destinations by using multiple-element format names, provided they do not contain an element that points to a public queue or a distribution list.

Distribution list security

Because distribution lists are objects in Active Directory, security attributes can be attached to control access to them, and their properties can be queried in Active Directory. In addition, they support encryption similar to queues. Each copy of a message can be encrypted using the public key of the destination computer for that copy.

A security descriptor is assigned to each queue and distribution list. This security descriptor lists the users and groups that are granted or denied access to the queue or distribution list, and the specific permissions assigned to those users and groups. The following specific permissions are associated with distribution lists:

  • Send To permission. Allows a group or user to send messages to the applicable distribution list. By default, this permission is granted to everyone.
  • Add/Remove Self as Member permission for a public queue or queue alias. Allows a group or user to add or remove the applicable public queue or queue alias as a member in a distribution list. All users are granted this permission by default.
  • Add/Remove Self as Member permission for a distribution list. Allows a group or user to add or remove the applicable distribution list as a member in another distribution list. Only the owner of a distribution list has the Add/Remove Self as Member permission for it.

When a queue or distribution list member is added to a distribution list, the set of users with the Send To permission for the distribution list containing the new member is not altered. Thus, in particular, when a distribution list with more restricted access is added to a distribution list with less restricted access, it becomes possible for clients of the expanded distribution list to access the new distribution list with more restricted access. This does not create a security risk because each distribution list can still control the set of users allowed to add members to it.

When a message is sent to a distribution list, Message Queuing verifies that the sender has the Send To permission to each of the top-level members (queues or distribution lists) in the distribution list. This is a compromise for achieving network traffic optimization. When a message is received, Message Queuing verifies that the sender has the Send To permission to the top-level members and to the destination queue itself.

To achieve security in sending operations, member containment in a distribution list is defined to be bidirectional: a member references its container and the container references its members. To respect the security restrictions on members, a member cannot be added to a member of a distribution list without permission from that member and its prospective container. In other words, both the container and the member must agree. For example, if a user wants to insert distribution list DL2 into DL1, the user must have the Add/Remove-Element permission for DL1 and the Add/Remove-Container permission for DL2. However, for the user to remove DL2 from DL1, only one of these permissions is required.

You can use Active Directory Users and Computers to create and delete distribution lists as distribution group objects, to add and delete members, and to view their properties. For more information on performing these tasks, see Create distribution lists, Delete distribution lists, and View, add, or delete elements in a distribution list.

Distribution lists can be referenced programmatically through distribution list format names. For more information on using distribution list format names and their syntax, refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.

Distribution list scope

Distribution lists can be domain-scoped, global, or universal:

  • Universal. Members of universal groups can include other groups and accounts from any domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest.
  • Global. Members of global groups can include other groups and accounts only from the domain in which the group is defined and can be granted permissions in any domain in the forest. Thus, distribution lists with global scope can include queues and distribution lists from the local domain, and queues and global distribution lists from other domains in the forest. They can be moved to another domain.
  • Domain-scoped. Members of domain local groups can include other groups and accounts from Windows Server 2003, Windows 2000, or Windows NT domains and can be granted permissions only within a domain. Thus domain-scoped distribution lists can only contain queues and distribution lists from the local domain as members, and cannot be moved to another domain.

Sending messages to distribution lists

When a message is sent to a distribution list, Active Directory is queried to ascertain its members and to translate any queue aliases into queues. Thus, the distribution list is expanded to a list of target queues. Distribution list members can be added or removed dynamically during the expansion process. Then a copy of the message with the same message ID is sent to each of those queues. If a distribution list contains multiple references to the same destination, duplicate references are ignored when the destinations are opened for sending messages. For example, if the members of distribution list D1 include queue Q1 and another distribution list D2, it may turn out that D2 also contains Q1 or D1. If this is the case, the second reference to Q1 or D1 is ignored. Thus, recursive cycles specified by distribution lists containing other distribution lists are broken.

Distribution lists may reference a mixture of transactional and nontransactional target queues. When a nontransactional message is sent to such a mixture of targets, the message is allowed to be sent to all the transactional and nontransactional target queues on the local or a remote computer. However, when the nontransactional message reaches a transactional queue, it is rejected and transferred to the nontransactional dead-letter queue on the computer hosting the transactional queue for storage, and a negative acknowledgement message indicating that a nontransactional message was sent to a transactional queue is sent to the administration queue specified in the original message.

Sending transactional messages to distribution lists

Message Queuing guarantees that all messages sent within a transaction will arrive exactly once and in the order in which they were sent. Message Queuing also guarantees that all messages sent in consecutive transactions from a given computer to the same destination queue will also arrive exactly once and in the order in which they were sent. This means that the messages sent within the first transaction will arrive before those sent within a subsequent transaction.

These transactional semantics are also supported for distribution lists. Messages sent to the same distribution list within a transaction will be delivered to the distribution list exactly once and in the order in which they were sent. In addition, messages sent within multiple transactions from the same source computer to the same distribution list will be delivered to the distribution list exactly once and in the order in which they were sent. Thus, the delivery of transactional messages to distribution lists and to queues is identical.

This equivalence, however, does not extend to the queues referenced by distribution lists. There is no guarantee of in-order delivery to a queue for transactional messages sent to different distribution lists, even if they contain the same elements (queues). Nevertheless, the messages will be delivered exactly once. In the case of delivery failures, Message Queuing places the original message with an indication of the first failed delivery in the source computer's transactional dead-letter queue.

Consider the following examples:

  • Example: In-order delivery to the same distribution list:
    • Distribution list DL1 = Queue Q1
    • Send message M1 to DL1
    • Send message M2 to DL1
  • In this case, Message Queuing guarantees both in-order and exactly-once delivery.
  • Example: Out of order delivery to different distribution lists:
    • Distribution list DL1 = Queue Q1
    • Distribution list DL2 = Queue Q1
    • Send message M1 to DL1
    • Send message M2 to DL2
  • In this case, even though both distribution lists contain the same elements, messages to Q1 will not necessarily arrive in-order to Q1. However, exactly-once delivery is guaranteed, so that M1 and M2 will arrive once and only once.

In contrast, using multiple-element format names can provide this in-order guarantee for messages sent to different distribution lists, since each message sent to a multiple-element format name containing a list of target queues. For more information, see Multiple-element format names.

Dynamic distribution lists and transactions

Because distribution lists are dynamic, recipients can be added while transactional messages are in transit. Such new recipients will start to receive transactional messages on the next appropriate transaction boundary. Only messages sent after a new queue joins a distribution list will reach the new member.

Distribution list acknowledgements

When a message is sent to a distribution list, potentially a set of different acknowledgements can be generated, since some target queues might receive the message successfully, while others may not. A sender should expect at least n acknowledgment messages for a message sent to a distribution list with n ultimate recipients when acknowledgment messages are requested. More than n acknowledgment messages should be expected when a single message generates a positive acknowledgment message upon arrival at its destination and a positive or negative read acknowledgment message. Note that all distribution lists and embedded distribution lists are expanded and duplicate recipients are eliminated before any messages are sent. However, to optimize message traffic, acknowledgment messages of the same class and generated for the same original message are combined into a single acknowledgment message containing a list of the queue GUIDs that acknowledged the message.


Multiple-element format names

Message Queuing 3.0 allows a sending application to send a single message to a list of destination queues. That list can be constructed dynamically in the form of a multiple-element format name or can be published and kept in Active Directory in the form of a distribution list. For more information on distribution lists , see Distribution lists.

A multiple-element format name can be constructed to do the following:

  • Send transactional and nontransactional messages to multiple destinations.
  • Specify multiple administration queues for sending acknowledgment messages.
  • Specify multiple response queues for sending response messages.

A multiple-element format name is formed as a concatenation of one or more public, private, direct, or distribution list format names separated by commas (for more information on format names, see Format names). Thus, different kinds of format names used in Message Queuing can be used together as elements of a multiple-element format name. The following example shows a multiple-element format name that contains a direct format name, a public format name, and a distribution list format name.

DIRECT=ComputerAddress\QueueName,PUBLIC=QueueGUID,DL=DL_GUID

Multiple-element format names can be used to send messages to multiple destinations even in workgroup or offline mode provided they do not contain an element that points to a public queue or a distribution list. For example, if a multiple-element format name references a private queue and a distribution list, no message will be sent to either target when there is no access to Active Directory.

Multiple-element format names can be used to reference multiple administration and response queues. However, they cannot contain format names of read-only queues, such as queue journals, computer journals, or dead-letter queues. An error is returned if a format name of a read-only queue is included in a multiple-element format name.

To enable downlevel compatibility, a list of explicit destinations is derived from every distribution list or multiple-element format name used to send a message in the source computer, and this information is included along with the distribution list or multiple-element format name in each message packet that is sent. For example, when a message is sent to distribution list D1 that references three queues (Q1, Q2, and Q3), the message packet sent to the three computers contains the explicit destinations Q1, Q2, and Q3 as well as the original distribution list D1. If any of the destination computers is running Message Queuing 2.0 or earlier, it will use the explicit destinations Q1, Q2, or Q3. Any computer that is running Message Queuing 3.0 will use D1 and disregard the repeated destinations.

Sending transactional messages to multiple-element format names

When a transactional message is sent to a multiple-element format name, appropriate guaranteed positive or negative acknowledgment messages can be returned to the sending application. In addition, Message Queuing guarantees that messages sent in consecutive transactions initiated from the same computer to the same destination queue will arrive exactly once and in the order in which the transactions were committed regardless of the way in which the target queue was addressed: either as an element of a multiple-element format name or as an individual queue.

When a transactional message is sent to a multiple-element format name, Message Queuing logically constructs a single transaction that consists of a series of discrete operations for sending the message to each of the target queues contained in the multiple-element format name and then either commits or aborts the entire transaction. This means that sending a message to a multiple-element format name within a transaction is semantically equivalent to sending a series of messages to individual queues within a single transaction.

Consider, for example, a multiple-element format name N1, which contains two queues Q1 and Q2, and a second multiple-element format name N2, which contains Q2 and Q3. Now consider a transaction consisting of the following three actions:

  1. Sending message M1 to N1.
  2. Sending message M2 to N2.
  3. Sending message M3 to Q2.

Messages M1, M2, and M3 will arrive at queue Q2 exactly once and in the order in which they were sent.

However, the guarantee of exactly-once and in-order delivery applies only to identical top-level elements of multiple-element format names and does not extend to queues that are members of different distribution lists referenced by multiple-element format names. Consider the case of two distribution lists D1 and D2, each of which contains queue Q1 as a member, a multiple-element format name N1, which contains D1 and another queue Q2 as elements, and another multiple-element format name N2, which contains D2 and Q2 as elements. If message M1 is sent to N1 and message M2 is sent to N2 within the same transaction, the messages will arrive at Q2 in the order in which they were sent, but they will not necessarily arrive at Q1 in that order. Nevertheless, the messages will be delivered to both queues exactly once.


IP multicasting

Message Queuing provides a mechanism to send and receive IP multicast traffic using the Pragmatic General Multicast (PGM) driver, which is installed and configured as part of the Core subcomponent during every installation of Message Queuing. Messages can be sent to a single destination IP address and then received and processed by multiple IP hosts. A host listens for a specific IP multicast address and receives all packets sent to it. The set of hosts listening on a specific IP multicast address is called the host group.

Using this method, a single copy of the message is sent on the network, and this message can then be received and processed by numerous destination applications. This method is especially useful if the same message has to be delivered to large numbers of receiving applications.

The sender specifies a target IP multicast address. An IP multicast address property is attached to a queue, and subsequently every message sent to that multicast address is inserted into the queue by Message Queuing. Applications continue to read messages from the queue using standard Message Queuing features. The Message Queuing service on a specific host listens to all multicast addresses to which its local queues are bound, routes incoming messages to the appropriate queues, duplicates messages that are sent to multiple queues, and dynamically starts and stops listening to a multicast address as local queues become bound and unbound.

Be aware of the security implications of multicasting. Messages cannot be encrypted, and messages could be read or used by unauthorized persons. Ensure that the address specified is used only for Message Queuing multicasting.

The following are some of the specific features of IP multicast messaging:

  • Only one copy of the message is sent, and it is received and processed only by computers, or hosts, that are listening for it.
  • Hosts can join and leave the host group dynamically at any time.
  • There are no limitations on the size of a host group.
  • A host can send messages to an IP multicast address without belonging to the corresponding host group.
  • Transactional sending is not supported.

A multicast address and a port number in the IP_Address:PortNumber syntax can be associated with any public or private queue. For public queues, this information is stored in Active Directory. For a private queue, this information is stored on the computer where messages sent to the queue are stored. Thus, in workgroup mode, multicast addresses can be associated only with private queues, and in domain mode, a Windows Server 2003 family domain controller must be available to associate multicast addresses with public queues.

IP multicast addresses must be in the class D range from 224.0.0.0 to 239.255.255.255, which corresponds to setting the first four high-order bits equal to 1110. However, only certain ranges of addresses in this range are available for sending multicast messages. For the latest list of reserved multicast addresses, see the link to Internet Assigned Number Authority (IANA) Internet Multicast Addresses at Windows 2000 Resource Kits - Web Resources.(http://www.microsoft.com/windows2000/library/resources/reskit/WebResources/default.asp)

For information on how to specify or view the multicast address and port number for a specific queue, see Specify or view queue multicast addresses and ports.

No additional security mechanisms are provided for multicast messaging. Security is achieved through authorization and authentication based on the mechanisms for one-to-one messaging. Each target queue is protected by authentication based on sender and access based on sender and receiver. Encryption and decryption are not supported.

Multicast messaging with multiple network interface cards

On a computer with multiple network interface cards, a problem will arise when the computer tries to send multicast messages by means of these multiple network interface cards. In effect, Message Queuing will randomly choose a network interface card for sending multicast messages. If the private network interface card is chosen, multicast recipients will not receive the message. To work around this issue, you can specify the source IP address to be used for sending multicast messages. To do this, create the DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MulticastBindIP, in the usual IP address format. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Multicast messaging on a cluster node

For multicast messaging on a cluster node, if no IP address is specified in the MulticastBindIP key, then the IP address will be derived from the following procedure:

  • On a virtual server, the virtual server's IP address defined for the IP address resource is used.
  • Else if the cluster node has only one IP address, that is used.
  • Else if an IP address is specified in the registry, that is used. If the IP address specified cannot be found on the node, an event will be issued and the registry entry ignored.
  • Else if a node has multiple IP addresses, the cluster API is used to make two lists - a first list of all private (not static) IP addresses, and a second list of all the node's IP addresses. These two lists are then compared, to select an address that is in the second list but not the first. An informational event is issued with the IP address chosen. If the only IP addresses available are those in the first list, one of those is used, and an event issued.

To specify an IP address, create a DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\ClusterBindIP, in the usual IP address format. After editing the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.


Internet Messaging

Message Queuing 3.0 provides Internet-messaging support. This section provides information about the basic concepts and features introduced in Message Queuing 3.0 to provide this support. Message Queuing sends messages over HTTP transport to URL-named queues. Message Queuing 3.0 provides Internet-messaging support with the following features:

  • For an overview of Internet messaging, see Internet messaging overview.
  • Message Queuing provides messaging over HTTP as an optional transport protocol. For more information, see HTTP/HTTPS messages.
  • HTTPS provides access control and authentication when messaging with HTTP. For more information, see HTTPS authentication.
  • When messages are sent over HTTP transport, external logical names or aliases can be mapped to internal physical queue locations, protecting internal resources and providing a solution for messaging through firewalls. For more information, see Store and forward servers.
  • HTTP messages are formatted using the SOAP Reliable Messaging Protocol (SRMP) extensions of the SOAP protocol. To read more about the Message Queuing implementation of the SOAP protocol, see SRMP messages.
  • For information on deploying HTTP messaging in Network Load Balancing clusters, see HTTP/HTTPS messaging in Network Load Balancing clusters.
  • For information on HTTP messages in server clusters, see HTTP/HTTPS messaging in server clusters.


Internet messaging overview

Message Queuing 3.0 provides support for Internet and intranet messaging, with the following features:

  • Reference queues using URL addresses.
  • Send and receive HTTP messages to destination queues on an intranet or over the Internet in XML-based, SOAP Reliable Messaging Protocol (SRMP) format.
  • Authenticate messages sent over HTTPS.
  • Support for messaging through firewalls and perimeter networks.
  • Web farm support, including a facility for mapping between external logical queue names and internal queue names, so that internal names do not need to be exposed to message senders.
  • Support for deployment of Message Queuing in hardened MSMQ mode, to enhance the security of Message Queuing computers on the Internet.

HTTP messages

Message Queuing 3.0 includes an optional HTTP Support component, to send and receive messages in an intranet or over the Internet with the HTTP/HTTPS protocol, in addition to the Message Queuing protocol. Messages can be sent over HTTP/HTTPS to destination queues on an intranet within an enterprise or over the Internet, and the sender and recipient can be in different forests or organizations. HTTP/HTTPS is automatically chosen as the transport for any Message Queuing message sent using an HTTP/HTTPS format name. For more information, see HTTP/HTTPS messages.

SRMP messages

SRMP is an extension of the SOAP Message Exchange Protocol (SMXP) that defines a reliable end-to-end messaging protocol for sending HTTP messages. Message properties are transmitted in XML, rather than in binary form. Message Queuing transforms message properties to specific SRMP and SMXP elements, and then on the receiver side, maps these elements to the respective Message Queuing properties before storing the message. For more information, see SRMP messages.

HTTPS authentication

Using HTTPS to send messages ensures authentication of users requesting access to Message Queuing resources by means of a Web server, and establishes a Secure Sockets Layer (SSL) connection for secure communication. A direct format name containing HTTPS as the protocol name invokes a secure HTTP transport through an SSL channel. SSL uses certificates to allow clients and Web servers to authenticate each other, and encryption keys to establish a secure communication connection. For more information, see HTTPS authentication.

Message Queuing in hardened MSMQ mode

To enhance the security of Message Queuing computers in an Internet environment and when sending and receiving HTTP messages, Message Queuing can be deployed in hardened MSMQ mode. Hardened MSMQ mode imposes restrictions on non-HTTP messaging. For more information, see Message Queuing in hardened MSMQ mode.

Messaging with perimeter networks

Most organizations connect to the Internet using a proxy server and a perimeter network protected by firewalls. Incoming messages pass through the firewall, and outgoing messages are sent through a proxy server. The proxy server is a mediator between the organization's intranet and the Internet world. It provides caching and decoupling. Message Queuing uses an HTTP proxy to connect to Web addresses for delivering HTTP messages. Message Queuing thus needs to know the name of the proxy server and the applicable port to which it must connect. At the same time, there may be a list of target names for which the proxy connection is bypassed; that is, Web addresses that do not need to be accessed through the proxy server. An attempt is made to establish a direct connection with such targets. All of the information regarding proxy servers is stored in registry keys. For more information, see Configuring firewalls for Message Queuing and Configuring Message Queuing with a proxy server.

Message Queuing with ISA Server

To use Message Queuing with ISA Server, install ISA Server Service Pack 1 or later. For more information, see ISA Server Service Pack 1.(http://www.microsoft.com/isaserver/downloads/sp1.asp)

Web farm support

For increased scalability and availability, Message Queuing with HTTP Support installed integrates with common network load-balancing mechanisms. Message Queuing applications can be deployed on the nodes of a Network Load Balancing cluster to receive and process messages sent to the cluster. When messages are sent over HTTP transport to a queue at a virtual URL address, a TCP session is established with one of the nodes in the cluster. For more information, see Message Queuing in Network Load Balancing clusters.

Similar Web farms can also be implemented using other load-balancing mechanisms, such as DNS round-robin distribution, and network address translation (NAT). For information on load-balancing Web farms, see Distributing Message Queuing in a network.

When messages are sent over HTTP transport, the network names of the computers within an organization and the names of the queues hosted on them do not need to be disclosed to message senders. Message Queuing provides a store and forward feature to map external and internal names, protecting internal resources. Mapping is enabled on a store-and-forward Message Queuing server, positioned in the front-end of the enterprise, where all incoming HTTP requests are directed. If messages meet mapping criteria, they are forwarded further into the enterprise. For more information, see Store and forward servers.


HTTP/HTTPS messages

Message Queuing includes support for delivering messages over HTTP, in addition to the Message Queuing protocol. Messages can be sent over HTTP transport to destination queues on an intranet within an enterprise or over the Internet, and the sender and recipient can be in different forests or organizations. For Message Queuing to send messages over HTTP, you must install the Message Queuing HTTP Support subcomponent. This subcomponent installs Internet Information Services (IIS) and creates an IIS extension for Message Queuing. For more information, see Choosing installation subcomponents. This subcomponent is not installed during a default Message Queuing installation.

Message Queuing formats messages using the XML-based SOAP Reliable Messaging Protocol (SRMP), an open general-purpose extension of the SOAP Message Exchange Protocol (SMXP). SRMP defines an open implementation-independent protocol for the reliable one-way delivery of SOAP 1.1 messages. For more information, see SRMP messages. Using SRMP, applications can also be written to create messages that are indistinguishable from Message Queuing-generated HTTP messages on computers that do not have HTTP Support installed, such as computers running MSMQ 1.0 or MSMQ 2.0. These messages can be sent as HTTP packets and accepted by queues hosted on computers with HTTP Support installed. They can then be received as HTTP messages by applications running on those computers.

To send messages to a destination queue over HTTP, the target computer must have Message Queuing's HTTP Support subcomponent and IIS installed. Access to the queue can be restricted to specific users by changing the permissions of the virtual directory in the IIS snap-in.

For secure HTTP messaging, HTTPS provides authentication and a Secure Sockets Layer (SSL) connection between a sender and recipient. For more information, see HTTPS authentication.

HTTP message formats

Destination queues for HTTP messages are opened using direct format names that include the URL address of the target computer, the virtual directory name, and the queue name separated by slashes. The default virtual directory name is msmq, but Message Queuing can be configured by IIS to use a different virtual directory. The format names used to send messages over the Internet must include the IP address or complete DNS name of the target computer, while the computer name is sufficient for sending messages within the enterprise. Examples of these direct format names include:

  • DIRECT=HTTP://157.18.3.1/msmq/MyQueue (Single computer or cluster)
  • DIRECT=HTTP://Mike01/msmq/MyQueue (Within the enterprise)
  • DIRECT=HTTP://mail.www.northwindtraders.com/msmq/MyQueue (Over the Internet)
  • DIRECT=HTTPS://mail.www.northwindtraders.com/msmq/MyQueue (Over the Internet)
  • DIRECT=HTTP://193.2.34.5/msmq/MyQueue (Over the Internet)

The public, private, and direct format names of administration or response queues can be included in messages sent over HTTP. Conversely, the names of administration or response queues in HTTP format can be included in messages sent over an ordinary (non-HTTP) transport. However, the use of distribution lists and multiple-element format names for these purposes is not supported.

For information on direct format names, see Direct format names.

Pipelining

Sending a new request before finishing to read all the responses from previous requests is called pipelining. Because proxies do not always support pipelining and because IIS HTTPS currently does not support it, the pipeline modes of HTTP and HTTPS delivery are controlled by two subkeys, namely HttpPipeLine and HttpsPipeline (of type DWORD), under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters registry entry. When they are set equal to 1, pipelining is enabled. By default, HTTP delivery works in pipeline mode, while HTTPS delivery does not. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.


HTTPS authentication

Using HTTPS to send messages ensures authentication of users requesting access to Message Queuing resources by means of a Web server, by establishing a Secure Sockets Layer (SSL) connection for secure communication between a sender and recipient. The sender is always regarded as the SSL client, and the recipient is regarded as the SSL server, regardless of whether the computers are running Message Queuing server or client software. Note that authentication for the purpose of establishing an SSL session is not the same as message authentication, which confirms that a message has not been tampered with and can be used to verify the identity of the message sender. For information on message authentication, see Managing message authentication.

Two kinds of certificates are used in HTTPS authentication:

  • Server certificates. This certificate contains information about the server that allows a client to identify the server before sharing sensitive information.
  • Client certificates. This certificate contains personal information about the user and identifies the SSL client (the sender) to the server.

Server certificates

Before an SSL connection can be established for sending messages, the recipient computer requires a server certificate that resides in the Personal store under Certificates (Local Computer) in the Certificates snap-in on the recipient computer.

For instructions on obtaining a server certificate from a CA and installing it, see Obtain server certificates for HTTPS messaging.

A server certificate obtained from a CA can be issued to the NetBIOS name or full DNS name of a computer. However, when HTTPS messages are sent, the destination specified in messages must be identical to the computer name in the recipient's server certificate. Thus, when only the NetBIOS name of the destination (for example, with a direct format name of the form DIRECT=HTTPS://msmqserv/msmq/private$/q1) is used to send messages within the same forest over an intranet to a computer whose server certificate contains the full DNS name, authentication fails. Consequently, when Message Queuing tries to create an SSL session, it receives a warning that the name in the certificate does not match the name of the destination, and the messages sent in this way accumulate in the outgoing queue.

Verifying server certificates on the sender computer

IIS on the recipient side must send the recipient's server certificate to the sender for authentication. This server certificate, which contains the signature of the certification authority (CA), the recipient's public key, additional information on the recipient, and an expiration date, must be from a CA that the sender trusts. To authenticate the recipient computer, the sender verifies that it trusts the CA and validates the signature in the recipient's server certificate.

When a sender computer trusts a CA, such as VeriSign or Microsoft Certificate Services, it has a certificate from that CA containing the CA's signature and public key in the Trusted Root Certification Authorities store under Certificates (Local Computer) in the Certificates snap-in. For instructions on importing a CA certificate on the sender computer from Microsoft Certificate Services, see Import a CA certificate from Microsoft Certificate Services.

Client certificates

An additional optional security component can be required for SSL sessions if IIS on the recipient side also requests the sender's client certificate for authentication. Client certificates are also obtained from a trusted CA and are stored in the MSMQ\Personal store under Certificates - Service (Message Queuing) on Local Computer in the Certificates snap-in on the sending computer. For information on obtaining and installing a client certificate, see Obtain client certificates.

Mapping client certificates

After a Web resource is configured to require an SSL channel, it still needs to be protected from unauthorized access. Since the anonymous user account has default write permissions for the physical MSMQ directory in IIS, and default IIS behavior is to ignore client certificate authentication, any user can send HTTPS messages. After client certificates are enabled, you can further protect content by creating mappings that relate the information contained in a client certificate to a Windows user account. For instructions, see Enable client certificates. Mapping is flexible, with one-to-one mapping to map individual client certificates to accounts, or many-to-one mapping to accept a wide range of certificates that meet specific criteria. For more information on mapping client certificates, see IIS online Help. After this is done, you can restrict or allow access to the MSMQ virtual directory by configuring security settings for the corresponding physical directory.

When all the conditions imposed by IIS are satisfied, the sender (SSL client) and recipient (SSL server) create and exchange SSL session keys, which are used to encrypt all packets sent over the SSL connection. For more information about certificates and SSL connections, see IIS online Help.

Access control and IIS settings

By default, IIS impersonates a special IIS local user account, IUSR_computername (where computername is the name of the server on which IIS is running). Because this account is local to the IIS computer (unless it is a domain controller), it cannot be authenticated by other computers in the network. It is treated as an anonymous user, and allows users to access Web resources without prompting for name and password information. HTTP messages are authenticated using this anonymous account, and if you want to limit a Web resource to HTTPS access only, you need to disable the anonymous access default. For more information, see Resolving IIS Anonymous Access settings. For instructions on how to do this, see Change the security settings for IIS.

In the context of Message Queuing, IIS can authenticate the sending computer, but not individual users sending messages. For more information on how users sending authenticated messages over HTTP/HTTPS transport can be validated, see Authenticating HTTP/HTTPS messages.


Store and forward servers

When messages are sent over HTTP transport, the network names of the computers within an organization and the names of the queues hosted on them do not need to be disclosed to message senders. Message Queuing 3.0 can map external and internal names, protecting internal resources, and providing a solution for messaging through firewalls. Mapping is enabled on a store and forward server, positioned in the front-end of the enterprise, where all incoming HTTP requests are directed. If messages meet mapping criteria, they are forwarded further into the enterprise. For instance, only messages arriving by means of an HTTPS session, or messages whose sender can be authenticated, or messages selected by another security criterion will be forwarded. This ensures that only authorized messages are ever presented to corporate servers.

Logical and physical addresses

Using this mapping facility, HTTP messages can be redirected from a logical address, accessible from the Internet, to a corresponding internal physical address. These are defined as follows:

  • Logical address. Contained in URL format in the <to> subelement of the <path> element of the SRMP Message.
  • Physical address can be any of the following:
    • A queue on the target computer specified in the logical address, to which the message must be written by the Message Queuing service.
    • A queue on a computer in the internal network. To deliver the message, an HTTP/HTTPS request call is made by the Message Queuing service handling the message.

Mappings are created manually by including <Redirections> entries in XML mapping files. Each <Redirections> element contains 0 or more <redirection> elements, each of which contains exactly one <from> subelement and exactly one <to> subelement. Each <redirection> element describes a map from a logical address (<from>), to a physical address (<to>). These XML mapping files must be stored in the \Windows\System32\Msmq\Mapping folder. A sample mapping template is provided in this folder.

The following example illustrates an XML mapping file:

  <Redirections>
    <redirection>
      <from>http://www.northwindtraders.com/accounts</from>
      <to>http://Accounts01/msmq/private$/DestQ</to>
    </redirection>
  </Redirections>

When an SRMP message reaches the computer specified as the logical address, the Message Queuing service uses a local resolution algorithm to map the logical address to the physical address.

Local resolution algorithm

A local resolution algorithm defines how the local Message Queuing service on the target computer specified in the logical address resolves the logical address into its physical address.

Transparent mapping

By default, if a message arriving from a remote computer address cannot be matched with a physical address in the mapping file, the message is discarded. However, if transparent mapping is enabled, a physical address for the message is set to the message's logical address. To enable transparent mapping, set the TransparentRedirections registry key to a value of 1.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

The local resolution algorithm works as follows:

  • If the logical address specifies a public or private queue on the local computer, and the queue exists, the physical address is set to the logical address of the queue.
  • Otherwise, the Message Queuing service searches through all the <redirection> elements in its local mapping files to try to match the logical address with a <from> subelement in one of the local mapping files, but the corresponding <to> subelement does not indicate a local public or private queue, it sets the physical address to match this <to> subelement, and forwards the message to the remote computer specified in this <to> subelement. This process is called redirection.
  • If transparent mapping is enabled, and the logical address of a message arriving from a remote computer cannot be resolved by any of the above methods, the physical address of the message is set to its logical address and the message is stored on the local computer.
  • If transparent mapping is not enabled, and the logical address of a message arriving from a remote computer cannot be resolved by any of the above methods, the message is discarded.
  • If the logical address of a message arriving from a local application cannot be resolved by any of the above methods, the physical address will be set to the logical address.

Hence if in the example above http://Accounts01/msmq/private$/DestQ does not point to a local private queue, then any SRMP message that is sent to the logical address specified will be forwarded to the computer Accounts01, where it will be written into the local private queue DestQ if such a local queue exists (subject to the normal authorization process) or it will be discarded silently if such a queue does not exist. If this <redirection> element is present in a mapping file on some other computer, the physical address of the message will be set to http://Accounts01/msmq/private$/DestQ and the message will be forwarded to this URL.

This provides a means to put HTTP messages sent to a logical address into an interim queue on the store and forward server in the receiving side of a perimeter network. From here they can be directed to the corresponding queue on a computer in the internal network.

Using wildcards

Limited use of regular expressions in <from> elements are supported. Asterisk-terminated URLs can define a redirection from multiple logical addresses to a single physical address. Only this type regular expression can be used, and only in the <from> element:

<Redirections>
  <redirection>
    <from>https://www.northwindtraders.*</from>
    <to>http://Accounts01/msmq/private$/DestQ</to>
  </redirection>
</Redirections>

In this example, any message with a logical address that starts with the string https://www.northwindtraders. will be redirected to the physical address in the <to> element. Thus, for example, messages with logical addresses https://www.northwindtraders.com/accounts and https://www.northwindtraders.net/data will be both redirected to the physical address http://Accounts01/msmq/private$/DestQ.

This functionality is based on software provided by J. Kanza. For copyright information for this software, see External software copyright and permission notice - J Kanza.

Order acknowledgment messages for transactional HTTP messages

Transactional messages are to be delivered exactly once and in the order in which they are sent. When transactional messages (streamed HTTP messages) are sent over HTTP from the internal network of an enterprise to the Internet, the physical address of the sender's order queue must be translated into a logical address using a mapping, to direct the order acknowledgment messages (stream receipts) from the receiving computer (outside the sender's enterprise), back to the sender's order queue.

Mappings between logical addresses for sending streamed HTTP messages from local applications and logical addresses for returning order acknowledgment messages (stream receipts) from the recipient computers are created manually by including <StreamReceiptSetup> entries in an XML mapping file that is stored on the local computer. Each <StreamReceiptSetup> entry contains 0 or more <setup> elements, each of which contains exactly one <LogicalAddress> subelement and exactly one <StreamReceiptURL> subelement. In each <setup> entry, the <StreamReceiptURL> element specifies the URL that will be included in streamed (transactional) HTTP messages sent from a local application to a logical address matching the URL specified in the <LogicalAddress> element.

When a streamed HTTP message is sent from a local application, the local Message Queuing service searches the <setup> entries in the mapping file. If a URL matching the logical address of the message is found in the <LogicalAddress> element of one of the <setup> entries, the URL specified in the accompanying <StreamReceiptURL> element is inserted into the <sendReceiptsTo> element of the <Stream> entry in the SOAP envelope of the message.

Each <setup> element also defines an implicit mapping that redirects every HTTP message arriving at the local computer with the destination specified in <StreamReceiptURL> to the physical address of the local order queue. Such messages are normally stream receipts (order acknowledgment messages).

A <StreamReceiptSetup> entry may contain one <default> element, which defines the default stream receipt URL that the local Message Queuing service inserts into every outgoing streamed (transactional) HTTP message, unless the logical address of the message matches the <LogicalAddress> element in one of the <setup> elements.

The following is an example of an XML mapping file that specifies the correspondence between a logical address for sending streamed HTTP messages from local applications and the logical address for returning stream receipts from the recipient computer along with the default URL for returning stream receipts:

<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
  <setup>
    <LogicalAddress>
      https://http://www.northwindtraders.com/accounts
    </LogicalAddress>
    <StreamReceiptURL>
      https://www.northwindtraders.com/StreamReceipts
    </StreamReceiptURL>
  </setup>
  <default>
    http://Accounts01/msmq/PRIVATE$/order_queue$
  </default>
</StreamReceiptSetup>

The limited use of regular expressions in the context of <LogicalAddress> elements is supported. Asterisk-terminated URLs can define the correspondence of multiple logical addresses to a single stream receipt URL. This is the only type of regular expression supported in <StreamReceiptSetup> entries, and it is allowed only in the <LogicalAddress> element.

In following example, any message with a logical address that starts with the string http://www.northwindtraders.com/* will use the stream receipt URL specified in the <StreamReceiptURL> element.

<StreamReceiptSetup xmlns="msmq-streamreceipt-mapping.xml">
  <setup>
    <LogicalAddress>
      http://www.northwindtraders.com/*
    </LogicalAddress>
    <StreamReceiptURL>
      http://www.northwindtraders.com/StreamReceipts
    </StreamReceiptURL>
  </setup>
</StreamReceiptSetup>

Outbound message redirection

The number of HTTP/HTTPS sessions established and the number of client certificates needed can be minimized by routing all outbound messages (messages sent out of the enterprise ) through a dedicated intermediate host. This dedicated intermediate host is called a transparent store and forward server (TSFD).

A computer with HTTP Support installed is configured as an intermediate host TSFD by setting the following registry key to 1:

HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\MQS_TransparentSFD

After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Any other value or a lack of this registry key indicates that the computer will not function as a TSFD and that all messages sent to remote queues will be discarded if the computer does not have a regular XML mapping file for them.

For a source computer to be able to redirect its messages through an intermediate host, a special XML configuration file needs to be added. This configuration file defines which messages will be redirected through an intermediate host and which will not. This XML configuration file must be stored in the \Windows\System32\Msmq\Mapping folder and is loaded when the Message Queuing service starts.

The following is an example of an XML configuration file that specifies the correspondence between the address of a destination queue and an intermediate host:

<outbound_redirections xmlns="msmq_outbound_mapping.xml">
  <redirection>
    <destination>http://target_host/msmq/private$/DestQ</destination>
    <through>http://intermediate_host/msmq</through>
  </redirection>
</outbound_redirections>

The <outbound_redirections> element contains 0 or more <redirection> subelements, each of which in turn contains exactly one <destination> subelement and exactly one <through> subelement. Each <redirection> element describes a redirection (or mapping) of the physical address of the destination queue given in the <destination> subelement to the virtual directory on the intermediate host given in the <through> subelement.

MSMQ 3.0 supports a limited use of regular expressions in a <destination> element. Users can use an asterisk-terminated URL to define a redirection of multiple physical addresses of destination queues to a single address of a virtual directory on an intermediate host.

In the following example, all messages sent using the HTTP protocol will be redirected through the intermediate host:

<redirection>
  <destination>http://*</destination>
  <through>http://intermediate_host/msmq</through>
</redirection>

Each <outbound_redirections> element may contain 0 or more <exception> subelements. You can use <exception> elements to exclude messages sent to specific queues from being redirected by outbound <redirection> rules.

MSMQ 3.0 supports a limited use of regular expressions in an <exception> element with the same restrictions as for the previously described <destination> element.

In the following example, all messages sent to private queues on special_host will not be redirected through the intermediate host:

<exception>http://special_host/msmq/private$/*</exception>

You can use the keyword local_names in an <exception> element to exclude messages sent to any internal (intranet) host from being redirected by outbound <redirection> rules.

In the following example, no messages sent to internal hosts will be redirected through the intermediate host:

<exception>local_names</exception>
</outbound_redirections>


SRMP messages

Internet messaging is increasingly using the medium of XML, particularly the XML messaging framework of SOAP 1.1. The Web Services Routing Protocol (WS-Routing) supports both one-way and request/response message exchange paradigms. However, it is explicitly not a goal of WS-Routing to provide reliability. The SOAP Reliable Messaging Protocol (SRMP) is an open general-purpose extension of WS-Routing that adds reliability to WS-Routing and SOAP.

Message Queuing uses both WS-Routing and SRMP elements as well as elements defined in the MSMQ namespace to specify its message properties in HTTP messages. Some Message Queuing message properties have equivalents defined by WS-Routing, and others have equivalents defined by SRMP.

When sending an HTTP message, Message Queuing automatically transforms the individual binary message properties to specific WS-Routing elements, SRMP elements, and elements of the MSMQ namespace, and includes them in the header portion of the SOAP envelope. On the receiver side, Message Queuing maps these XML elements to the respective binary message properties before storing the message. The end-to-end semantics for transmitting message properties over a non-HTTP transport are preserved for messages sent over an HTTP transport.

The header portion of the SOAP envelope in an HTTP message contains two required entries and up to seven optional entries in the following order:

  • <path>

    (Required.) Contains WS-Routing subelements.

  • <properties>

    (Required.) Contains SRMP subelements.

  • <services>

    (Optional.) Contains SRMP subelements.

  • <Stream>

    (Optional.) Contains SRMP subelements. This entry is generated only in transactional messages.

  • <streamReceipt>

    (Optional.) Contains SRMP subelements. A <streamReceipt> entry is generated only in order acknowledgment messages (stream receipts) sent for transactional messages (streamed HTTP messages).

  • <deliveryReceipt>

    (Optional.) Contains SRMP subelements. A <deliveryReceipt> entry is generated only in acknowledgment messages sent in response to a request to indicate that the original message reached the destination queue.

  • <commitmentReceipt>

    (Optional.) Contains SRMP subelements. A <commitmentReceipt> entry is generated only in acknowledgment messages sent in response to a request to indicate whether or not the original message is received from the destination queue before its time-to-be-received timer expires.

  • <Msmq>

    (Optional.) Contains subelements defined in the MSMQ namespace.

  • <Signature>

    (Optional.) Contains subelements that specify an XML digital signature.

For more information about SRMP elements and the equivalent Message Queuing properties, see the Message Queuing Software Development Kit (SDK). For details of how to access the SDK, see Additional Message Queuing resources.

Applications can be written to create messages that are indistinguishable from Message Queuing-generated HTTP messages on computers that do not have HTTP Support installed, such as computers running MSMQ 1.0 or MSMQ 2.0. These messages can be sent as HTTP packets and accepted by queues hosted on computers with HTTP Support installed. They can then be received as HTTP messages by applications running on those computers.


HTTP/HTTPS messaging in Network Load Balancing clusters

Message Queuing can be implemented in Network Load Balancing clusters to receive and process messages sent to the cluster. To implement Message Queuing in a Network Load Balancing cluster, Message Queuing is installed with the same set of subcomponents on all nodes in a cluster. So that if you install Message Queuing with HTTP support on one node, install Message Queuing with the same functionality on all other nodes.

All computers in the cluster are addressed by the same virtual cluster IP address or set of virtual cluster IP addresses, and when messages are sent over HTTP transport to a queue at a cluster IP address, a TCP session is established with one of the hosts in the cluster. Messages can be sent only to destinations specified by direct format names that include a URL or IP address of the cluster.

In a Web farm implementation, such as a Network Load Balancing cluster, successive HTTP connections from the same source might be directed to two different servers. This means that end-to-end reliable messaging is difficult, and Message Queuing does not guarantee exactly-once delivery through a Web farm, although a best-effort attempt is made by means of a lightweight nonpersistent duplicate removal mechanism. This issue can be addressed by the use of Message Queuing's store and forward feature. Store and forward mapping uses XML files located on Message Queuing computers, with Message Queuing usually installed on each host in the Network Load Balancing cluster. These XML files maintain a mapping between the logical external URL or IP address to which the message is sent, and the physical internal address of a queue. For every incoming message arriving at a Network Load Balancing host running Message Queuing with store and forward functionality, the Message Queuing service will read the logical address to which it was sent. If a message meets mapping criteria, it is forwarded further into the enterprise. For more information, see Store and forward servers.

Similar Web farms and store and forward functionality can also be implemented using DNS round-robin distribution, and network address translation (NAT). For an overview of these, see Distributing Message Queuing in a network.


HTTP/HTTPS messaging in a server cluster

Microsoft Windows Graphic

HTTP/HTTPS messaging in server clusters

This section applies only to users running XOX or XOX in a server cluster configuration. To implement Message Queuing in a server cluster, Message Queuing is installed with the same set of subcomponents on all nodes in a server cluster. This means that if you install Message Queuing with HTTP Support on one node, install Message Queuing with the same functionality on all other nodes.

When you install Message Queuing with the HTTP component on a cluster node, IIS will also be installed on that node, if it is not already installed. You then define cluster groups for Message Queuing, and create a virtual server - a cluster group that will contain the Message Queuing resource, plus other resources upon which the Message Queuing resource depends. For further information, see Message Queuing in server clusters. Each virtual server is associated with a network name and an IP address. To support these virtual servers, IIS must assign a Web site for all virtual server IP addresses. To do this, configure the default Web site setting to All Unassigned, which assigns to the default Web site all IP addresses that are not assigned to a specific site. Alternatively, you can specify the IP address of a particular virtual server as the default Web site. For instructions on setting these options, see Configure Message Queuing with HTTP for server clusters.

Failover for the Message Queuing resource with HTTP

If the IIS service on the cluster node goes down, this does not cause the Message Queuing cluster group to fail over. This means that in such a case the Message Queuing resource will continue to work on the node, but HTTP messaging cannot be used. For more information on forcing failover of cluster groups when IIS goes down, see the Windows Server 2003 family Help file, or the IIS Help file.


Message Queuing in Clusters

This section provides information about messaging over clusters, and how to administer message queuing in clusters. For details, see the following links:

  • For details on deploying Message Queuing in a server cluster, see Message Queuing in server clusters.
  • For information on implementing Message Queuing on a Network Load Balancing cluster, see Message Queuing in Network Load Balancing clusters.


Message Queuing in server clusters

The Message Queuing service can be implemented in a server cluster, which appears to network clients as a single, highly available system. Such clusters are used to increase reliability and fault tolerance through failover as well as to achieve load balancing. Message Queuing server clusters can be created only on computers running XOX or XOX. For these clusters, the Message Queuing service is installed on every node in the cluster. These instances of the Message Queuing service are needed to support Message Queuing resources in the virtual servers. In addition, although they are unaware of clustering, they are needed, even in a clustered system, to serve the many applications and system components that run outside the context of any virtual server and call Message Queuing APIs.

Cluster groups and virtual servers

A cluster group is a collection of cluster resources with the following characteristics:

  • Groups define the units of failover. That is, when one resource in a group fails and it is necessary to move the resource to an alternate node, all of the resources in the group are moved to the alternate node.
  • A group is always owned by one node at any point in time. Likewise, a resource is always owned by a single group. These relationships ensure that all of a group's members reside on the same node.

To access a network application or resource in a nonclustered environment, network clients must connect to a physical server (that is, a specific computer on the network identified by a unique network name and Internet Protocol (IP) address). If that server fails, access to the application or resource is impossible. Through server clusters, XOX or XOX enable the creation of virtual servers. Unlike a physical server, a virtual server is not associated with a specific computer and can be failed over like a group. If the node hosting the virtual server fails, clients can still access its resources using the same server name. A virtual server is a group that contains a network name resource, IP address resources, other virtual servers, and other resources - including applications like Message Queuing, to be accessed by the clients of the virtual server.

When you form cluster groups for Message Queuing, you must create a virtual server. The Message Queuing resource is dependent on a Physical Disk resource, to store message and queue data, and a Network Name resource, so that remote clients can access it. This virtual server is created on each node of the cluster using standard cluster tools (Cluster Administrator is the standard GUI tool) or cluster-creating APIs. If you are using triggers, HTTP messaging, or external transactions on your cluster, requiring a Distributed Transaction Coordinator (DTC) resource, a single DTC resource is created only in one of the virtual servers. Then you create a Message Queuing resource using Cluster Administrator in some or all of the existing cluster groups. The first time that a Message Queuing resource on any virtual server is brought online, the cluster Network Name resource creates a pseudo-computer object, and the Message Queuing resource creates the Message Queuing objects under it in Active Directory. Each virtual server functions similarly to a physical computer, so a Message Queuing server running in the context of a virtual server provides services similar to a Message Queuing server running on a physical computer. In particular, queues can be created on a virtual server, and messages can be sent to them. Such queues are addressed using the VirtualServerName\QueueName syntax.

For more information on Cluster Administrator, see Using Cluster Administrator, in the Cluster Administrator Help file.

For more information on creating virtual servers for Message Queuing using Cluster Administrator and on creating a DTC resource in a server cluster, see Installing Message Queuing in a server cluster.

Note that when you select the Physical Disk resource for the Message Queuing cluster group, Message Queuing allocates its storage in the MSMQ\STORAGE folder on the shared disk. After storage has been allocated, you cannot modify the folder location.

Message Queuing clients can communicate with a standard Message Queuing server running on a node of a server cluster, or if Message Queuing applications are cluster-aware, they can run on a Message Queuing server running in the context of a virtual server.

In the active/active model, which is supported by all versions of Message Queuing following MSMQ 1.0, there can be multiple Message Queuing virtual servers running (active) on a single node. Thus, in a simplified example, if there are two nodes in a server cluster and Message Queuing is installed on both of them and if these two nodes host a total of three virtual servers, any of these virtual servers can fail over to the other node.

In the event of a failover, the resources of a group on one node, initially the preferred node, are taken offline and then brought back online on another node. The data stored on the physical disk remains unchanged because only the ownership of the Physical Disk resource is transferred to the new node. Upon failback, the resources are moved back logically to the preferred node.

Because the Message Queuing Triggers service is cluster-aware and supports the active/active paradigm, when the Message Queuing service fails over to another node, the Triggers service will fail over along with it. For this to occur, you must create a Message Queuing Triggers resource with resource dependencies on the Message Queuing resource and the Network Name resource on the applicable node using Cluster Administrator. When failover occurs, the trigger and rule definitions, which are stored in the Windows registry, can then propagate between cluster nodes along with the other Message Queuing keys. After failover, the Triggers service can thus continue to process the incoming messages in each monitored queue and invoke the applicable stand-alone executable or COM component according to the rules defined.

Virtual servers are managed using standard snap-ins. The Users and Computers snap-in can be used to manage the Message Queuing resources within a virtual cluster just as it is used to manage Message Queuing computers in a network. You can also open the Computer Management snap-in from within a virtual server for local management of the Message Queuing resource.

In a server cluster, the Message Queuing servers installed on the nodes must all provide the same set of services to enable failover. The types of services provided by Message Queuing running in the context of a virtual server depend on the configuration of the Message Queuing servers installed on the host nodes. For example, if Message Queuing servers with routing services enabled are installed on the nodes of a server cluster, these services will also be available in the context of the virtual servers hosted on those nodes.

Note that the Downlevel Client Support component cannot run on a virtual server. However, computers requiring this component can query a remote Message Queuing server with this component, running on a domain controller.

IP addressing with multiple network interface cards on a cluster node

On the physical node of a cluster, there are usually two network interface cards with different IP addresses. One of these network interface cards is used only for internal cluster communication. To ensure that Message Queuing does not use the private IP address of an internal cluster Network Interface Card, which would result in messaging failure, Message Queuing maintains a list of all private IP addresses on a cluster node. When Message Queuing starts, it checks this list to make sure that the IP address of an internal network interface card is not selected for messaging. Alternatively, you can specify an IP address on the cluster node that must be used for messaging, instead of allowing Message Queuing to randomly select an IP address from those available.

The IP address used for messaging is derived by applying the following conditions:

  • On a virtual server, the virtual server's IP address defined for the IP address resource is used.
  • Else if the cluster node has only one IP address, that is used.
  • Else if an IP address is specified in the registry, that is used. If the IP address specified cannot be found on the node, an event will be issued and the registry entry ignored.
  • Else if a node has multiple IP addresses, the cluster API is used to make two lists - a first list of all private (not static) IP addresses, and a second list of all the node's IP addresses. These two lists are then compared, to select an address that is in the second list but not the first. An informational event is issued with the IP address chosen. If the only IP addresses available are those in the first list, one of those is used, and an event issued.

To specify an IP address, create a DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\ClusterBindIP, in the usual IP address format. After editing the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Note that after restarting a node computer, the Message Queuing service running on the node does not restart automatically, and you need to restart it manually. However, Message Queuing resources that were online do come back online automatically.

IP addressing for multicast messaging on a cluster node

On a cluster node with multiple network interface cards, a problem will arise when the computer tries to send multicast messages by means of these multiple network interface cards. In effect, Message Queuing will randomly choose a network interface card for sending multicast messages. If the private network interface card is chosen, multicast recipients will not receive the message. To work around this issue, you can specify the source IP address to be used for sending multicast messages. To do this, create the DWORD value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MulticastBindIP, in the usual IP address format. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

Note that for multicast messaging on a cluster node, if no IP address is specified in the MulticastBindIP, then the IP address to be used will be derived from the procedure detailed previously in the section entitled IP addressing with multiple network interface cards on a cluster node.

Memory management for Message Queuing resources in clusters

If you have multiple Message Queuing resources in a server cluster, message activity may not function as expected unless you increase the system view space memory pool size of each node by 4 MB for each instance of the Message Queuing resource. This is recommended for cluster nodes with one or two Message Queuing resources and necessary for cluster nodes with three or more Message Queuing resources: To do this:

  • Open Registry Editor using regedit.
  • Open the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management.
  • Create a new DWORD value called SystemViewSize.
  • Calculate and specify this value as follows:
    • Use this formula: (16 + (the number of Message Queuing resources x 4)).
    • For example, the value for a cluster with three Message Queuing resources equals 28.
  • Reboot each node.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

For more information on server clusters for XOX and XOX, see Server clusters, in the Windows Help file.


Message Queuing in Network Load Balancing clusters

Message Queuing services can be implemented in an Network Load Balancing cluster. Network Load Balancing clusters distribute client connections over multiple servers, providing scalability and high availability for client requests for services and applications, but they do not have failover capabilities. In its most common implementation, Network Load Balancing distributes incoming TCP/IP traffic between multiple Internet Information Services (IIS) servers, which comprise a Web farm. Network Load Balancing can combine up to 32 servers running XOX or XOX into a single load-balancing cluster. Servers can be added without shutting down the cluster.

The heart of Network Load Balancing is the WLBS driver, which is loaded into each member server, or host, in the cluster. This driver includes the statistical mapping algorithm that the cluster hosts collectively use to determine which host handles each incoming request.

Under this type of clustering, if a host fails or goes offline, Network Load Balancing automatically reconfigures the cluster to redirect subsequent client requests to hosts that are still viable members of the cluster. Any client connections that were open when the host failed or went offline are ended. On retry, the client connection is routed to a viable host. The downtime for client connections is less than 10 seconds.

Network Load Balancing allows all computers in the cluster to be addressed by the same set of cluster Internet Protocol (IP) addresses, while also maintaining their existing, dedicated IPs. This feature transparently distributes client requests among the hosts in the cluster, using virtual Internet Protocol (IP) addresses. You must run IIS 5.0 or another TCP/IP service on each host, and the hosts must serve the same content so that any of them can handle any request. You can copy updated pages to local disks on the hosts, or you can use commercial file-replication software to perform updates. Network Load Balancing allows you the option of specifying that all connections from the same client IP address be handled by a particular server (unless, of course, that server fails). It also permits you to allocate all requests from a Class C address range to a single server.

When you set up a Web farm using Network Load Balancing, each server is in constant communication with all the others. They exchange performance statistics and divide the responsibilities of handling incoming requests. Every incoming request is seen by every server in the farm, and Network Load Balancing has its own algorithm to determine which server will handle each request.

When messages are sent over HTTP transport to a queue at a virtual URL address, a TCP session is established with one of the nodes in the cluster. Messages can be sent only to destinations specified by direct format names. In the case of express and recoverable messages, the receiver is not required to maintain any internal state, and Message Queuing does not guarantee exactly-once delivery through a Web farm, although a best-effort attempt is made by means of a lightweight nonpersistent duplicate removal mechanism. When transactional messages are sent over HTTP transport, in-order delivery is guaranteed by including an SRMP stream header entry that includes information for message sequencing. For more information, see Store and forward servers.

When a session between a client and a node is disconnected and the client is routed to a different node for the next session, the messages whose delivery was not acknowledged are resent by the client and accepted by the new node with the possible creation of duplicates.

Message Queuing applications can be deployed on the nodes of an Network Load Balancing cluster to receive and process messages sent to the cluster.

Similar Web farms can also be implemented using DNS round-robin distribution, and network address translation (NAT).


Cross-Platform Messaging

This section provides information about messaging between systems running Message Queuing and those running a different messaging software. These disparate systems communicate by means of a connector application. For details, see the following links:

  • Foreign computers and sites
  • MSMQ-MQSeries Bridge


Foreign computers and sites

Message Queuing clients can communicate with foreign computers using a connector application. Foreign computers run operating systems that do not support Message Queuing or use other messaging systems. Connector applications run on Message Queuing servers and enable foreign computers to communicate with Message Queuing clients. A Message Queuing server running a connector application typically has two additional queues, called connector queues: one used for transactional messages and one used for nontransactional messages. For a definition of transactional messages, see Transactional messaging. When a Message Queuing client sends a message to a foreign computer, the message is first routed to a connector queue on the Message Queuing server and is then forwarded to the foreign computer.

Examples of connector applications are Microsoft MSMQ-MQSeries Bridge, which allows connectivity with computer platforms running IBM MQSeries.

Microsoft MSMQ-MQSeries Bridge extends the functionality of Message Queuing to provide seamless, transactional connectivity with IBM MQSeries Version 2.x and Version 5.x platforms. Microsoft MSMQ-MQSeries Bridge currently ships as part of Microsoft Host Integration Server 2000. For more information on Microsoft Host Integration Server 2000, refer to the Microsoft Host Integration Server Web site.(http://www.microsoft.com/hiserver/)

Foreign sites

To communicate with foreign computers, you must first create a foreign site, add the foreign computers to the foreign site, and create queues on the foreign computers. All of these are Message Queuing objects in Active Directory whose existence in the physical world is not essential. Then, you must create a routing link between the foreign site and a Windows Server 2003 family or Windows 2000 Message Queuing (non-foreign) site that contains a Message Queuing server running a connector application, define this Message Queuing server as a site gate for the routing link, and add the foreign site to the list of sites where this computer resides.

Foreign computers can be assigned to the same foreign site if the computers are all serviced by the same connector application. Connector applications run on Message Queuing servers and enable foreign computers to communicate with other Message Queuing computers in your network.. When a Message Queuing computer sends a message to a foreign computer, the message is routed to the Message Queuing server running the connector application in the foreign site because this server is also a site gate in the routing link connecting to the foreign site. When the server identifies the message destination as a queue on a foreign computer, it places it in a connector queue. The message is subsequently processed by the connector application, which communicates with the foreign computer.

You must create a routing link between the foreign site and each Windows Server 2003 family or Windows 2000 site that will communicate with the foreign site. The Message Queuing routing server that runs the connector application in the foreign site must also function as a site gate in each routing link connecting to the foreign site. Site gates are always associated with a particular routing link. Note that if the routing server running the connector application, and functioning as a site gate, is unavailable, site gates in other sites cannot route messages to the applicable connector queue for transmission to computers in the foreign site.

For information on how to create a foreign site, see Create foreign sites.

For information on how to add foreign computers to a foreign site and how to add a Message Queuing server running a connector application to a foreign site, see Add foreign computers to a site.

For information on how to create and configure a routing link, see Routing links.


MSMQ-MQSeries Bridge

Microsoft MSMQ-MQSeries Bridge is a connector application used to interface computers running Message Queuing applications and computers running IBM MQSeries applications. To send a message from a Message Queuing computer to a MQSeries computer, a destination queue on the foreign (MQSeries) computer must already exist. For more information on configuring Microsoft MSMQ-MQSeries Bridge and foreign computers running IBM MQSeries, see the documentation provided with Microsoft MSMQ-MQSeries Bridge.

Microsoft MSMQ-MQSeries Bridge currently ships as part of the Microsoft Host Integration Server 2000. For more information, refer to the Microsoft Host Integration Server Web site (http://www.microsoft.com/hiserver/).


Administering Message Queuing

This section provides conceptual information about the administrative tasks for Message Queuing:

  • For an overview of the tools provided to administer your Message Queuing network, see Administration overview.
  • For information about planning and deployment, installing Message Queuing, and upgrading computers running MSMQ 1.0 and MSMQ 2.0, see Planning, Installing, and Upgrading Message Queuing.
  • For information on administering sites, configuring routing links, messaging through firewalls, and configuring DNS settings, see Administering a Message Queuing Network.
  • For information on Message Queuing objects in Active Directory, see Administering Message Queuing in Active Directory.
  • For information on assigning Message Queuing servers for routing, administering server cluster nodes, and joining a workgroup computer to a domain, see Administering Message Queuing Computers.
  • To learn more about security tasks, see Administering Security.
  • To learn about administering queues, see Administering Queues.
  • For more on administering and managing distribution lists, see Administering Distribution Lists.
  • For background information about message tasks, see Administering Messages.
  • To learn more about defining and processing triggers, see Administering Triggers.
  • For information about monitoring Message Queuing and performance tuning, see Monitoring and Testing Message Queuing.


Administration overview

You administer your Message Queuing network and computers primarily using snap-ins displayed in the Microsoft Management Console (MMC). For a few administrative tasks, you use the Message Queuing Properties dialog box, which can be opened from Computer Management. The following table shows the administrative tools used to manage Message Queuing.

Administrative tool name | Type of tool | Type of tasks used for
Computer Management | MMC snap-in | Most workgroup-based tasks; managing queues and messages; some local tasks; managing user certificates and cryptographic keys
Active Directory Users and Computers | MMC snap-in | Most domain-based tasks; managing computers, queues, and messages
Active Directory Sites and Services | MMC snap-in | Some domain-based tasks; managing routing links, and foreign sites for cross-platform messaging.

For general information about using MMC and snap-ins, see Microsoft Management Console.

MSMQ Explorer was the administrative tool used to administer MSMQ objects on MSMQ 1.0 computers, but it will not run on Windows 2000, XOX, or Windows Server 2003 family computers. For XOX and Windows Server 2003 family computers, Message Queuing is administered using the Computer Management, Active Directory Users and Computers, and Active Directory Sites and Services snap-ins in MMC consoles. This section does not discuss how to administer security for Message Queuing. For more information, see Security overview.

Using snap-ins to administer Message Queuing

Three snap-ins are used to manage Message Queuing. The Computer Management snap-in gives you access to local queue and message information. The Active Directory Users and Computers snap-in and the Active Directory Sites and Services snap-in give you access to information in Active Directory for routing configurations, computers, queues, and other Message Queuing objects throughout your Windows Server 2003 family forest. For more information on the objects associated with Message Queuing, see Message Queuing and Active Directory.

Most Message Queuing objects appear in the console tree (usually the left pane) of the MMC console displaying the snap-ins. When you want to view the properties for a particular Message Queuing object, you can usually right-click the object in the console tree, and then click Properties. The details pane (usually the right pane) of the MMC console displaying the snap-ins typically shows the name, type, and properties (using columns) of Message Queuing objects.

Active Directory replication can delay the display of information updates, so changes you make using a snap-in do not appear until after replication takes place. For example, when you add a queue to a computer in site C from a computer in site B, you do not see the change in the applicable snap-in until the change has been replicated from site C to site B. You can press F5 after making a change to refresh the information displayed in the snap-in.

Computer Management snap-in

The Computer Management snap-in can be used to perform many of the daily administrative tasks involving queues and messages on computers. In fact, it is the only snap-in available to manage Message Queuing in a workgroup environment (not part of a Windows Server 2003 family or Windows 2000 domain).

You can use the Computer Management snap-in to perform the following tasks:

  • Create and view private queues and set queue properties.
  • View cached public queues (if the local computer has at one time belonged to a domain and had access to Active Directory).
  • Pause and resume the operation of an outgoing queue.
  • Pause and resume the operation of all outgoing queues for a computer.
  • View message properties and purge outgoing messages.
  • Manage queues and messages on other computers.

In addition, you can use the Message Queuing Properties dialog box, which can be opened from the Computer Management snap-in, to perform the following local administrative tasks for Message Queuing:

  • Specify which local disk drives and folders on which to store message and log files.
  • Register, remove, renew, and view user certificates.
  • Renew cryptographic keys.
  • Specify a new site to which messages will be forwarded for a mobile computer. This applies only to Message Queuing 3.0 computers that belong to a Windows NT 4.0 enterprise and are capable of connecting to MSMQ 1.0 controller servers to access the MQIS database.

Outgoing queues are visible only when using the Computer Management snap-in. They are not displayed in any other snap-in.

The Computer Management snap-in allows you to manage queues and messages on other computers (provided you have administrative permissions for the other computers). For more information on how to manage queues and messages on other computers, see Manage queues on other computers.

You can also manage the queues and messages for all computers in your workgroup (or domain) by creating an MMC console (.msc) file that displays all the applicable computers. For information about creating console files, see Creating consoles.

Notes

  • You manage Message Queuing in the context of a virtual server in a cluster using the Computer Management snap-in only. In this case, a cluster group object having the name of the Network Name resource of the virtual server is displayed. Message Queuing objects are displayed under this object.

Active Directory Users and Computers snap-in

You can use the Active Directory Users and Computers snap-in to perform the following domain-based administrative tasks for Message Queuing involving Active Directory:

  • View all Message Queuing computers and set computer-specific properties.
  • Create, view, delete, and find all public queues and set queue properties.
  • Create, view, and delete local private queues and set queue properties.
  • View message properties and purge messages.
  • Send MQPing messages, test messages, and configure message route tracking.
  • Create and delete queue aliases as well as view and change their properties.

The shortcut link used in the procedure topics (step 1) to open the Active Directory Users and Computers snap-in opens MMC in author mode. This snap-in must be initially opened in author mode so that you can select the proper view options for displaying all Message Queuing objects in Active Directory. You will note the subsequent step in the procedures:

"On the View menu, click Users, Groups, and Computers as containers, and then click Advanced Features."

You can save these changes so that these views are always enabled by default by creating your own .msc file for this snap-in. In such a case, the first time you open the .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 the user mode selected with the correct view 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.

Active Directory Sites and Services snap-in

You can use the Active Directory Sites and Services snap-in to perform the following domain-based administrative tasks for Message Queuing involving Active Directory:

  • Create and delete routing links as well as view and set their properties (including the site gates).
  • Create foreign sites and foreign computers as well as view and set their properties.
  • Set the default lifetime of messages on your network (known as the time-to-reach-queue setting).

The shortcut link used in the applicable procedure topics (step 1) to open the Active Directory Sites and Services snap-in opens MMC in author mode. This snap-in must be initially opened in author mode so that you can select the proper view option for displaying Message Queuing objects in Active Directory. You will note the subsequent step in the procedures:

"On the View menu, click Show Services Node."

Again, you can save these changes so that this view is always enabled by default by creating an .msc file for this snap-in in the manner described previously.

To use Message Queuing to send and receive messages, relevant Message Queuing applications must first be designed, developed, and deployed.


Planning, Installing, and Upgrading Message Queuing

This section discusses planning and deployment issues, installation options, and upgrade strategies. For more information, see:

  • Planning for Message Queuing
  • Installing Message Queuing
  • Upgrading to Message Queuing


Planning for Message Queuing

This section suggests ways to plan for and deploy Message Queuing in your organization. Planning and deployment options are included. The section on business scenarios provides simple overviews for deploying Message Queuing in different organizations. For details, see the following links:

  • For an overview of planning Message Queuing deployment, see Planning overview.
  • For information on licensing considerations for a Message Queuing network, see Licensing considerations.
  • Message Queuing can be deployed in either a domain or a workgroup environment. In the context of Message Queuing, a domain environment includes domain controllers that provide a directory service such as Active Directory. For more information, see Deploying in a domain environment.
  • A workgroup does not provide or have access to such a directory service, and can be run in an environment that is not part of a domain. For more information about workgroup deployment, see Deploying in workgroup mode.
  • Message Queuing 3.0 supports the sending of messages over HTTP. For more information on deploying in an Internet environment, see Internet deployment considerations.
  • For an overview of how different business situations can use Message Queuing, see Business scenarios.


Planning overview

When planning a Message Queuing deployment, it is important to consider performance requirements. After you have assessed these requirements, you can make informed decisions about your hardware requirements and upgrading strategies. Generally, performance of Message Queuing applications, like other applications, can be improved with the following strategies:

  • Increasing the amount of system memory for each server.
  • Upgrading the processor or adding additional processors.
  • Increasing the number, speed, or size of the disks.
  • Replacing disk drives and volume sets with striped drive arrays.
  • Limiting the number of other services running on the computer by moving nonessential software to other computers. A server that runs additional services needs greater hardware resources than it would otherwise.

Disk considerations

Consider the following:

  • Number of disks. Since Windows Server 2003 family operating systems and Message Queuing are able to perform many disk operations in parallel, using separate physical disks (as opposed to single disks with multiple partitions) will result in performance improvements for most Message Queuing applications. Applications that use recoverable or transactional messages will see the greatest improvement because these messages are constantly being written to disk and retrieved from disk.
  • Disk type. Not all hard disks deliver equivalent performance. In particular, there are high-performance disks that use hardware striping and battery-protected write-through disk controllers that delay write operations until they can be performed most efficiently. These disks will significantly improve messaging performance, especially when sending or receiving recoverable or transactional messages. Note also that for the best messaging performance on Message Queuing servers, put the messaging (*.mq) files, message log files, and transaction log files on separate physical disks.
  • Disk size. When deciding disk size for your computers, consider the space requirements for Message Queuing files, the type of messaging (recoverable, transactional or express), the total number of messages that are likely to accumulate on the server at any time, and the total size of those messages. It can be difficult to anticipate message storage requirements. However, if you use Message Queuing servers for session concentration within a site (in-routing and out-routing servers) or in routing links (site gates), you must allow for additional message storage space on those servers. Also, servers that support dependent clients are likely to need additional disk space.
  • Number of disk drives. Adding disk drives ensures that disk access has a minimal impact on messaging performance. However, if your CPU (processor) usage is at or near 100%, adding disk drives does not improve messaging performance. To determine whether your computers are limited by disk access or by processing power, use System Monitor to track the % Processor Time counter (located in the Processor object) and the Avg. Disk Queue Length counter (located in the DiskLength object). If the sustained % Processor Time value is above 75% during the time messages are being sent, adding processing capacity may improve messaging performance. If the Avg. Disk Queue Length value for any drive is greater than 0.6 when messages are being sent, additional disks may improve messaging performance. For more information on monitoring Message Queuing performance, see Monitoring performance.

Memory considerations

Consider the following:

  • Storing messages. To maximize messaging performance, there must be enough memory on a given computer to hold all of the messages that are expected to accumulate in its queues under normal operation. Messages may accumulate on the source computers, if destination computers are unreachable. On destination computers, messages will accumulate if receiving applications are not running, or are unable to keep up with the arrival rate of messages.
  • Calculating RAM requirements. To calculate the amount of RAM required to hold all messages, you must consider message sizes. For example, when sending 20,000 messages that are approximately 1 kilobytes (KB) each with typical header sizes, allow at least 23 megabytes (MB) (20,000 × 1 KB + 20,000 × 150) of available RAM beyond normal system requirements. Note that this applies only to cases where all messages actually accumulate on a computer. If messages are normally retrieved (removed from queues) as quickly as they are delivered, significantly less RAM will be required.

Rolling out Message Queuing

A rollout process can consist of the following phases:

  • Setting administrative policy. When setting out such a policy, consider how access control will be established in your organization, how administrative duties will be delegated, how work will be documented, and how backups and emergencies will be handled.
  • Conducting lab tests. Lab testing helps you to determine the load that Message Queuing places on your servers, and tests your in-house Message Queuing applications. Before conducting such tests, ensure that your computers meet the minimum hardware requirements for running Message Queuing, and that your Message Queuing applications are functioning properly.
  • Conducting one or more pilot rollouts. After Message Queuing has been tested in a lab, you can deploy in a limited environment. It is recommended that the pilot rollout be introduced on a limited scale, such as 15 to 50 users. You can then make any needed adjustments to your administrative policy and to your Message Queuing applications for the final rollout. If you make extensive changes to the final rollout plan, consider doing a second pilot rollout.
  • Conducting the final rollout. After analyzing the results of the pilot rollouts, you are ready to finalize the plans for the full-scale rollout of Message Queuing in your organization. The final rollout plan is an extension of the pilot planning process, with the added steps of documenting, budgeting for, and carrying out the final logistics.


Licensing considerations

Message Queuing counts Windows Server 2003 family client access licenses (CALs). If no CALs are available, Message Queuing applications can fail to send messages and to open all queues. Message Queuing enforces the following rules for counting CALs:

  • An independent client running on XOX can have no more than 10 concurrent Message Queuing sessions and remote-read sessions with other independent clients running on XOX.
  • A dependent client does not count CALs, but its supporting server counts any sessions or queues opened on behalf of the dependent client. All Message Queuing sessions, remote-read sessions, and queues opened by dependent clients are counted. The number of dependent clients that can be supported is limited by the number of server CALs on the server.
  • All sessions used by a Message Queuing computer are counted only once.

For more information on licensing for Windows Server 2003 family operating systems, see Licensing, in the Windows Help file.


Deploying in a domain environment

During installation, if you choose to install Message Queuing with Active Directory Integration and the installation computer is part of a domain, Message Queuing objects are created in Active Directory. For more information about installation options, see Installation overview. For more information about Message Queuing objects in Active Directory, see Message Queuing and Active Directory.

An Active Directory domain includes one or more domain controllers that store directory information for the domain. The collection of all domains in a Windows Server 2003 network is called a forest, and one or more domains in the forest can be designated as a global catalog, with directory information for other domains in the forest, in addition to its own. Active Directory employs a multi-master model, so that any Windows Server 2003 family domain controller can read from or write to objects stored in Active Directory. For more information, see Introduction to Active Directory, in Active Directory Help.

Accessing Active Directory

In a domain environment, computers running XOX, or a Windows Server 2003 operating system, and Message Queuing can directly access Message Queuing objects in Active Directory. On the other hand, Windows 2000 computers running Message Queuing require either a Windows Server 2003 domain controller running the Downlevel Client Support Component to provide the Message Queuing Directory Service, or a Windows 2000 domain controller hosting a Message Queuing server in its site and its domain to access such objects in Active Directory. In addition to this requirement, a Windows NT 4.0, Windows 98, or Windows 95 computer running MSMQ 1.0 also requires that this domain controller be configured as a global catalog server.

Notes

  • When receiving a user's request to Active Directory, Active Directory Service Interfaces (ADSI) resolves the query by attempting to locate a domain controller in the user's domain. This can potentially be a problem for users who log on to remote computers in a different domain from their own. If the remote computer's domain is not connected to the user's domain, the Active Directory query will fail.

Sites

In a domain environment, a Message Queuing network can be divided into different Windows Server 2003 family sites, which are interconnected using routing links. Sites map the physical structure of your network, whereas domains generally map the logical structure of your organization, independently of each other. There may be multiple domains in a single site as well as multiple sites in a single domain. For more information, see Message Queuing and Active Directory. For more general information on sites in Windows Server 2003 family, see Sites overview, in the Active Directory Help file.

In the context of Message Queuing, a site can consist of the following:

  • Windows Server 2003 domain controllers, which hold configuration and status information in the Active Directory and replicate such information between sites using site links. Active Directory employs what is called a multi-master model, which means that any Windows Server 2003 domain controller can read from or write to objects stored in Active Directory.
  • Windows Server 2003 family computers, all of which use the same network protocol (typically IP). Any two computers in a site that use the same network protocol have direct connectivity with each other. Such connectivity also implies fast and cheap communication.
  • Collections of associated subnets, each with a single IP subnet address.

When a Message Queuing client communicates with a Message Queuing server, it directs the request to a predetermined server in the same site, if one is available.

Site considerations

All sites are determined during the planning and installation of Windows Server 2003 family computers in your organization. There is not a separate site topology as there was in previous versions of Message Queuing. This simplifies your site planning.

However, it is recommended that you consider the factors listed in the following table.

Site consideration | Requirement or suggestion
Communication link | The communication link between sites must be permanent.
Available network bandwidth | The network bandwidth must be able to support the volume of messages transmitted within the site.
Performance | The number of domain controllers in each site affects performance. Each additional domain controller in a site generates more network traffic for Active Directory replication throughout that site. You need to weigh the benefits of redundancy against the performance overhead of increased replication.
Performance and connectivity | Configuring a domain controller as a global catalog server in each site will enhance performance and reduce connectivity issues.
Organizational | Group together users who work in the same site to improve overall performance of the system, reduce network traffic, and reduce resource use.

Note

  • There is no longer a special definition of a site in the context of Message Queuing as there was for MSMQ 1.0. When upgrading from MSMQ 1.0, each MSMQ 1.0 site is mapped to a Windows Server 2003 family site, and for cross-platform messaging, each foreign connected network is mapped to a foreign site. If you are upgrading from MSMQ 1.0, see Upgrade overview for a list of changes.

Offline mode

A Message Queuing computer can also belong to a domain but be temporarily unable to communicate with a domain controller. This is known as offline mode and occurs when:

  • The computer itself is offline.
  • All the domain controllers in its site are offline.
  • An attempt is made to access a remote computer and the remote computer is temporarily unable to query a domain controller for authentication.

In all these cases, the computer's configuration as a member of a domain is maintained in the registry, and normal domain operation resumes as soon as a domain controller becomes available. While in offline mode, messages can be sent directly by using direct format names. When other format names are used, the messages are stored on the local computer and are sent as soon as a domain controller becomes available. For more information, see Format names.

Managing computers in a domain under the Local User account

Computers that are part of a domain can be managed under the Local User account. To do this, the Message Queuing Directory Service must be running on the domain controller, and you need to add the EnableLocalUser key (DWORD=1), to the registry of the local computer, at location HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\EnableLocalUser

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.


Deploying in workgroup mode

For Message Queuing, any mode of operation that does not allow access to Active Directory is known as workgroup mode. Note that this is regardless of whether a computer belongs to a domain, and that computers that belong to a domain can operate in workgroup mode. Computers in workgroup mode require direct connectivity with a destination computer for messaging.

Computers that belong to a domain

If you are installing Message Queuing on a computer that is a member of a Windows Server 2003 or Windows 2000 domain, you can specify whether the computer will operate in domain mode, by installing the Active Directory Integration subcomponent, or in workgroup mode, by not installing the subcomponent. In the context of Message Queuing, workgroup mode can be defined as any mode of operation that does not allow access to a directory service, even if the applicable computer belongs to a domain.

The default installation setting is that the Active Directory Integration component is installed, and when your computer is part of a domain, Setup will attempt to contact a Windows Server 2003 or Windows 2000 Server domain controller in the local site or a nearby site. If successful, the computer will operate in domain mode, meaning that access to Active Directory will be enabled. If one of these domain controllers cannot be located, you will be prompted for the name of an MSMQ 1.0 PEC or PSC (in a Windows NT 4.0 enterprise) in the local site. If you do not supply such a name, and select Next in the setup process, Message Queuing will be installed in workgroup mode. In such a situation, where the Active Directory Integration subcomponent is installed but the computer is unable to access a domain controller, the next time you restart such a computer, or stop and restart the Message Queuing service, Message Queuing will automatically attempt to contact a domain controller in the local domain. If a domain controller is available and contact is successful, the computer will then operate in domain mode.

Computers that do not belong to a domain

For computers that are not part of a domain and have no access to Active Directory, during default setup they are installed as independent clients in workgroup mode. The Active Directory Integration subcomponent is still installed, and if the workgroup computer later joins a domain, this subcomponent is activated. Conversely, a Message Queuing computer can be part of a domain and then join a workgroup. Such a computer can later rejoin the same domain.

The following restrictions exist when using Message Queuing in workgroup mode:

  • Computers in workgroup mode require direct connectivity with a destination computer, and only support direct message transmission. Messages sent by such computers cannot be routed.
  • There is no access to Active Directory. As such, you can create and manage private queues only on a local computer. You can view the list of private queues on another computer, and the messages in them, using the Computer Management snap-in. For information on managing queues on remote computers, see Manage queues on other computers. You cannot view or manage public queues or any other information in Active Directory. You can, however, send messages to or retrieve messages from private queues if there is direct connectivity.
  • Internal certificates cannot be used for sending authenticated messages; an external certificate must be used. For more information on user certificates, see Managing user certificates.
  • Messages cannot be encrypted. For more information on encryption, see Encryption for Message Queuing.
  • There is no support for dependent clients. For more information on restrictions on the deployment of dependent clients, see Dependent clients.
  • Cross-platform messaging is not supported. For more information, see Cross-Platform Messaging.

Joining a Windows NT 4.0 domain

When a computer running Message Queuing in workgroup mode joins a Windows NT 4.0 domain, the installation subcomponent for Active Directory Integration is removed. After the computer has been joined to the domain and rebooted, open the Control Panel, double-click Add or Remove Programs, click Add/Remove Windows Components, and in the Windows Components Wizard, select Application Server, click Details, select Message Queuing, click Details, and select Active Directory integration.


Internet deployment considerations

Message Queuing 3.0 has increased support for Internet messaging and includes the following features:

  • HTTP as an optional transport protocol
  • An XML-based SOAP extension that defines a reliable end-to-end messaging protocol
  • Support for load-balancing, Web farms, and firewalls

If your network will be sending or receiving messages through the Internet, consider the following:

  • Network load balancing. For increased scalability and availability, Message Queuing integrates with common network load-balancing mechanisms, namely, Network Load Balancing (NLB), NAT, and DNS round-robin. For more information, see Message Queuing in Network Load Balancing clusters.
  • Messaging through perimeter networks. Most organizations connect to the Internet using a proxy server and a perimeter network protected by firewalls. Incoming messages pass through the firewall, and outgoing messages are sent through a proxy server. The proxy server is a mediator between the organization's intranet and the Internet world. It provides caching and decoupling. Message Queuing uses an HTTP proxy to connect to Web addresses for delivering HTTP messages. Message Queuing thus needs to know the name of the proxy server and the applicable port to which it will connect. At the same time, there may be a list of target names for which the proxy connection is bypassed; that is, Web addresses that do not need to be accessed through the proxy server. An attempt is made to establish a direct connection with such targets. All of the information regarding proxy servers is stored in registry keys. For more information, see Configuring firewalls for Message Queuing and Configuring Message Queuing with a proxy server.
  • Deploying Message Queuing in hardened MSMQ mode. This new feature enhances the security of Message Queuing computers running on the Internet. Hardened MSMQ mode is intended to support scenarios that employ only HTTP (SRMP) messages. For more information, see Message Queuing in hardened MSMQ mode.

For information on Internet messaging, see Internet Messaging.


Business scenarios

The following scenarios show how different business situations could benefit from using Message Queuing. They also serve as representative examples of the different options available when you use Message Queuing.

Because the differences between using Message Queuing servers and clients affect implementation details, not actual business scenarios, the scenarios have been kept simple. It is recommended that application developers see the Message Queuing SDK for representative samples of Message Queuing applications.

Floor automation scenario

Figure showing a representative floor automation scenario

You can use Message Queuing to control the automated manufacturing of any product that is produced by a numerically controlled industrial machine that is, in turn, controlled through a computer. In the example in the accompanying figure, Message Queuing is used to collect work orders and manage the information flow for production.

The following Message Queuing features are critical to the success of floor automation:

  • Guaranteed message delivery. Ensures that each message is delivered and helps ensure a reliable messaging system.
  • Message prioritization. Efficiently routes messages. For example, although quality assurance (QA) messages need to be delivered eventually, they should not obstruct the efficient delivery of time-critical messages.
  • Connectionless messaging. Enables all computers and machines to interact as a single system.
  • Multiple-platform support. Integrates personal computers and legacy systems. For example, an accounting package can reside on an IBM mainframe MVS system and can communicate with Message Queuing applications residing on personal computers using Microsoft MSMQ-MQSeries Bridge. For more information, see Foreign computers and sites.
  • Performance. Because messages can be delivered quickly, they can control real-time production processes, such as cooking temperature.
  • Asynchronous delivery. Makes it possible for faster devices to continue processing without having to wait for slower devices to respond.

Ticket sales scenario

Figure showing a representative ticket sales scenario

The accompanying figure shows how multiple clients can access a ticket sales Web server using the Internet. Web clients view HTML pages that show ticket availability, pricing, and seating diagrams.

A business selling tickets to events can use the following Message Queuing features to improve its system:

  • Internet connection. Accepts orders over the Internet by using a Message Queuing application and COM components in conjunction with Active Server Pages (ASP) and Internet Information Services (IIS). This is done through Web forms, which provide security and multiple-platform support.
  • Connectionless messaging. Account updating and ticket shipping, performed asynchronously.
  • Multiple-platform support. Integrates personal computers and legacy systems. For example, the ticket sales server might be running on a UNIX computer. For more information, see Foreign computers and sites.

Publish-and-subscribe scenario

Message Queuing can be used to simplify the development of typical publish-and-subscribe programs, such as news wire services and financial data subscription services. Although a server program must continuously send updated data of a specified type to the client, the server does not have to resend the data if the client is offline or unavailable.

Figure showing a representative publish-and-subscribe scenario

The accompanying figure shows a publish-and-subscribe scenario that keeps a mobile sales staff current on the status of available goods. A Message Queuing application can also be used to take orders, and the two systems can be integrated. However, to simplify the details of the example, this publish-and-subscribe scenario covers only the dissemination of information.

In this figure, mobile clients retrieve data in the field. Regional servers retrieve data from the main server only for the types of information to which the clients subscribe. Each client then receives only information it subscribes to receive. This reduces both intersite communication and mobile communication costs.

In this scenario, the regional servers and the data center are located in different sites. Messages are routed between the data center and the sites along routing links in which the main server in the data center and the regional servers are configured to be site gates.

The following Message Queuing features are critical to the success of traditional publish-and-subscribe programs:

  • Connectionless messaging and message prioritization. Places the burden of message delivery on Message Queuing. You do not have to deal with information that expires (which, therefore, is no longer useful) or with information that cannot be delivered in a timely fashion.
  • Security. Ensures that the information is delivered to the correct client, and ensures that services are not used without payment.

Banking scenario

Figure showing a representative banking scenario

Financial transactions require both security and transaction-based programming. Automated teller machine (ATM) transactions also require connectionless messaging. In the accompanying figure, each ATM has its own local database. Even if the local, regional, or headquarters database is temporarily offline, the ATM can still process transactions.

In this scenario, the regional data centers, each of which has direct connections to multiple local data centers that communicate directly with several ATMs, are located in different sites. Messages are routed between the headquarters data center and the sites along routing links, in which the main server in the headquarters data center and the servers in the regional data centers are configured to be site gates.

This banking scenario uses these Message Queuing features:

  • Connectionless messaging. For communication between ATMs and regional centers.
  • Transactional messaging. For sending messages that occur synchronously with the updating of the financial databases. Messages are delivered only once.
  • Security. For ensuring the integrity of the system. Would-be thieves cannot impersonate an ATM, and transactions cannot be monitored by persons attempting to steal account numbers and personal identification numbers.

Stock brokerage scenario

Figure showing a representative stock brokerage scenario

In the example shown here, customers communicate by telephone with traders who make trade requests on their behalf. The trade server performs the following tasks in the following order:

  1. Queries the account server to verify that the transaction can be completed.
  2. Verifies the transaction with the risk-management server.
  3. Places the trade request with the stock exchange server.

The stock exchange server makes the stock transaction and then asynchronously updates the customer account and risk-management server.

This stock transaction scenario uses these Message Queuing features:

  • Security. For message authentication, encryption, and access auditing to ensure a secure environment.
  • Multiple-platform support. Integrates personal computers and legacy systems. For more information, see Foreign computers and sites.
  • Transactions (exactly once delivery). For guaranteed message delivery, ensuring accurate accounting.
  • Connectionless messaging. For updating accounts and making risk assessments asynchronously.


Installing Message Queuing

This section explains the requirements for installing Message Queuing software on computers running Windows Server 2003 family operating systems. It also explains how to install new Message Queuing software remotely, using a script. For details, see the following links:

  • For general installation information, see Installation overview.
  • For information on installation requirements and restrictions, see Installation requirements and restrictions.
  • For information on permissions required to install Message Queuing components, see Installation permissions.
  • To help you select which Message Queuing subcomponents to install, see Choosing installation subcomponents.
  • For information on integrating Message Queuing with Active Directory, see Active Directory Integration subcomponent.
  • For information on installing Message Queuing servers, independent clients, and dependent clients, see Installing Message Queuing Computers.
  • For a guide to installing Message Queuing triggers, see Installing Message Queuing triggers.
  • For advice on installing Message Queuing in a server cluster configuration on XOX or XOX computers, see Installing Message Queuing in a server cluster.
  • For information about using Windows unattended setup feature to install Message Queuing software, see Unattended setup.
  • For help with uninstalling Message Queuing software components, see Uninstalling Message Queuing.


Installation overview

Message Queuing is not installed by default during installation of Windows Server 2003 family operating systems, but the files needed to install it and its subcomponents are copied to the computer during this process. When you install Message Queuing, an additional 6.7 megabytes (MB) of space is required for Message Queuing folders. You install Message Queuing on a computer by adding it as a Windows component after installation of the operating system is complete. The Message Queuing component can be found in Add or Remove Programs, Add/Remove Windows Components, Application Server, Message Queuing.

To configure Message Queuing, you choose the Message Queuing subcomponents you require by selecting Message Queuing, clicking Details, and then selecting or clearing the applicable check boxes.

The Message Queuing subcomponent tree has the following form:

Message Queuing
line graphic Common
line graphic line graphic Core
line graphic line graphic Local Storage
line graphic Active Directory Integration
line graphic Triggers
line graphic MSMQ HTTP Support
line graphic Routing Support
line graphic Downlevel Client Support

For more detailed information on these components, see Choosing installation subcomponents.

Message Queuing can be installed in two modes:

  • Active Directory mode. If you install Message Queuing with Active Directory Integration and the installation computer is part of a domain, Message Queuing objects are created in Active Directory. This mode supports direct message transmission, and messaging using path names. For more information on these types of messaging, see Path names. For more information on Active Directory domain mode, see Deploying in a domain environment.
  • Workgroup mode. Any mode of operation that does not allow access to Active Directory is known as workgroup mode, regardless of whether a computer belongs to a domain. Computers in this mode require direct connectivity with a destination computer, and only support direct message transmission. Messages sent by such computers cannot be routed. For more information, see Deploying in workgroup mode.

Note that during a default installation, the Active Directory Integration subcomponent is installed. If the computer is in the workgroup mode, the presence of this subcomponent allows for the possibility that the computer might later join a domain. In that case, the computer will try to integrate with Active Directory and attempt to create a Message Queuing object in Active Directory, each time the Message Queuing service is started. For more information, see Active Directory Integration subcomponent.

By choosing the subcomponents you require, you can decide on Message Queuing functionality for your Windows Server 2003 family computer, as follows:

  • Dependent client. Dependent clients require the Local Storage subcomponent of the Common component to be selected. Dependent clients rely on a supporting server for all their messaging functions and cannot use new Message Queuing 3.0 features. It is recommended that you install independent clients, rather than dependent clients, where possible.
  • Independent client. These clients can operate in workgroup mode or Active Directory domain mode. Computers configured as independent clients run the Message Queuing service, host queues, send and receive messages, operate while disconnected from the network, access Active Directory directly, and can act as a supporting server for dependent clients. However, for an independent client in workgroup mode, direct connectivity is required to send messages, and the computer cannot act as a supporting server for dependent clients. To differentiate between independent clients and Message Queuing servers:
    • Independent clients do not provide the message routing capabilities of a Message Queuing server with the Routing component enabled.
    • Independent clients do not have the Downlevel Client Support component enabled, and cannot provide Active Directory access for MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers, or Message Queuing 2.0 clients running on Windows 2000 computers.

Default installation settings

A default installation installs the Common (Core and Local Storage) and Active Directory Integration components. Installing the Active Directory Integration component means that if your computer is part of a domain, and has access to Active Directory, your computer will operate in domain mode following installation. If your computer is in workgroup mode, or in a domain but without Active Directory access, the Active Directory Integration component attempts to access a domain controller, and work in domain mode each time the Message Queuing service is restarted. This allows you to join your workgroup computer to a domain and work in domain mode at any time following installation.

If you are installing Message Queuing on a computer that is a member of a Windows Server 2003 family domain or Windows 2000 domain, you can still specify whether the computer will operate in domain mode (by ensuring that Active Directory Integration subcomponent is selected) or in workgroup mode (by canceling the selection of the Active Directory Integration subcomponent).

During any installation or upgrade, there are certain requirements and restrictions that apply and must be met before you can install Message Queuing. For more information, see Installation requirements and restrictions. For more information on installation permissions, see Installation permissions.

Unattended setup

Windows unattended setup feature can be used to install Message Queuing software remotely. For more information, see Unattended setup.


Installation requirements and restrictions

Installation requirements

Regardless of whether you are performing a new installation of Message Queuing or upgrading from previous versions, the following requirements must be met before you can successfully install Message Queuing on a computer running a Windows Server 2003 family operating system:

  • You must be logged on with the proper administrative permissions for the computer on which you want to install or upgrade Message Queuing. For more information on the permissions required for installation, see Installation permissions.
  • It is recommended that you have network connectivity if you want to install or upgrade Message Queuing on a computer that is part of a Windows Server 2003 family or Windows 2000 domain. However, Message Queuing can be installed offline.
  • To support MSMQ 1.0 clients on Windows NT 4.0, Windows 98, or Windows 95 computers, and MSMQ 2.0 clients on Windows 2000 computers in a Windows Server 2003 domain, you must install the Message Queuing Downlevel Client Support component on a Windows Server 2003 domain controller or install Message Queuing 2.0 on a Windows 2000 domain controller in the local domain.
  • If a domain controller in the local site or in a nearby site cannot be accessed or does not exist, the installation process can continue. In this case, if the Active Directory Integration subcomponent is not selected, Message Queuing will be installed in workgroup mode, even if the computer on which Message Queuing is being installed belongs to a domain. If the Active Directory component is selected, the installation process continues, and Message Queuing will attempt to create the Active Directory object every time the Message Queuing service is restarted.

Installation restrictions

To successfully install or upgrade Message Queuing, the following restrictions must be observed:

  • Do not install Message Queuing simultaneously on multiple Windows Server 2003 family domain controllers. In Active Directory, creating an object with the same name at the same time on multiple domain controllers may result in objects' names being changed. This can happen because it takes a certain amount of time for changes to be replicated among domain controllers.
  • Do not manually create Message Queuing objects (such as the msmq object, for example) in Active Directory before you install or upgrade Message Queuing.

In addition, the following restrictions apply to specific subcomponent configurations:

  • A dependent client cannot be installed in workgroup mode. Thus, the Core subcomponent cannot be installed without the Local Storage subcomponent in workgroup mode.
  • After Message Queuing is installed, the Local Storage subcomponent cannot be added or removed.
  • The domain controller that an independent client will attempt to contact during installation cannot be defined in advance in attended setup. If you want to specify a pre-Windows Server 2003 family domain controller, you must run Setup in unattended mode and include a ControllerServer entry in the [msmq] section.
  • No additional subcomponents can be installed on a dependent client. If you want to add a subcomponent, you must first uninstall Message Queuing and install it again as an independent client.
  • The Downlevel Client Support component cannot be installed if the computer does not belong to a domain.
  • The Downlevel Client Support component cannot be installed if no domain controller is available, as in offline mode.
  • The Routing Support component cannot be installed if the computer does not belong to a domain.
  • The Routing Support component cannot be installed if no domain controller is available, as in offline mode.

Finally, there may be certain restrictions on creating queues on computers that are specified during Message Queuing Setup. For more information, see Access control for Message Queuing.

Installing Message Queuing using a Windows NT 4.0 user account

When you install Message Queuing on a computer running Windows Server 2003 family and you are logged on using a Windows NT 4.0 domain user account, it is recommended that you have at least one Message Queuing server running on a Windows Server 2003 family domain controller that is in the same domain in which you are installing. Otherwise, you will be prompted to enter the name of the primary site controller (PSC) in a Windows NT 4.0 domain during setup.

Installing MSMQ 1.0 in a Windows Server 2003 family domain

The following applies if you are installing MSMQ 1.0 on a computer running Windows NT 4.0, Windows 98, or Windows 95 in a Windows Server 2003 family domain:

When prompted for the name of a PSC during setup, you must enter the name of a domain controller instead. This Windows Server 2003 family domain controller must be running the Message Queuing directory service (Downlevel Client Support), must be configured as a global catalog server, and must be in the same site and the same domain in which you are installing MSMQ 1.0.

If you plan to install MSMQ 1.0 on computers running Windows NT 4.0 in a new Windows Server 2003 family domain, you select the Downlevel Client Support subcomponent during installation of the first domain controller in the new domain. If you are installing MSMQ 1.0 on computers running Windows NT 4.0 in an existing Windows Server 2003 family domain, you verify that the Everyone group has been added to the "Pre-Windows Server 2003 family Compatible Access" group for the domain. To do this, open Active Directory Users and Computers. In the console tree, double-click Builtin, right-click Pre-Windows Server 2003 family Compatible Access, click Properties, and on the Members page, check to see if the Everyone group is listed. If not, click Add, and then select Everyone.

Also, dependent clients running Windows NT 4.0 must have Windows NT 4.0 Service Pack 4 (SP4) or higher installed. SP4 or higher is required for transactional messaging.

In addition, for computers running Windows 98 or Windows 95, you must be granted the Create Computer Objects permission for the Computers container object in Active Directory, as the computer object for such computers does not exist in Active Directory.

To allow users to install MSMQ 1.0 in a Windows Server 2003 family domain, you must use the Delegation of Control Wizard to grant specific permissions to all users in the domain. For more information, see Set installation permissions to enable upgrade from MSMQ 1.0.


Installation permissions

The following table shows the administrative permissions required to install different Message Queuing software components and to create various Message Queuing computers. By default, logging on using an account with these permissions allows the applicable Message Queuing objects to be created in Active Directory during Message Queuing installation.

Message Queuing computer | Permission level required
Message Queuing server on a domain controller | domain administrative permissions (or member of the Domain Admins group)
Message Queuing server on a nondomain controller with Routing Support | enterprise administrative permissions (or member of the Enterprise Admins group).
Message Queuing server on a nondomain controller without Routing Support | local administrative permissions (or member of the local Administrators group)
Independent client | local administrative permissions (or member of the local Administrators group)
Dependent client | local administrative permissions (or member of the local Administrators group)

For more information on administrative groups for Windows Server 2003 family, see Default groups, in the Active Directory Help file.

Notes

  • When installing a Message Queuing server on a nondomain controller with routing enabled, domain administrative permissions are sufficient, provided Setup can contact a Windows Server 2003 or Windows 2000 domain controller and provided you are granted the specific permissions for objects listed in the table that follows.
  • When installing Message Queuing in a server cluster, the user account under which the cluster service is running must be granted permissions to create computer objects and Message Queuing objects. This can be done only on a XOX or XOX. See the following table for specific permissions needed to create specific objects.

If you do not want to grant users such general or wide-ranging permissions to install Message Queuing, you can grant permissions to create those objects specifically required to create different Message Queuing computers. The following table lists the specific child objects in Active Directory that you must be granted permission to create for Message Queuing installation to complete.

Message Queuing computer | Specific permissions required | For which object
Message Queuing server (on a domain controller or on a nondomain controller with routing enabled) | Create MSMQ Configuration Objects | applicable domain controller object located in Active Directory Users and Computers
Message Queuing server (on a domain controller or on a nondomain controller with routing enabled) | Create All Child Objects | Servers container object located in Active Directory Sites and Services
Message Queuing server (on a nondomain controller with no routing) | Create MSMQ Configuration Objects | applicable computer object located in Active Directory Users and Computers
Independent client | Create MSMQ Configuration Objects | applicable computer object located in Active Directory Users and Computers
Dependent client | none | not applicable

You can grant these specific permissions to specific users or to all users in a domain using the Delegation of Control Wizard.

For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, see Message Queuing and Active Directory.

For more information on permissions for objects, see Access control for Message Queuing.

For an example of how to grant permissions using the Delegation of Control Wizard, see Set installation permissions to enable upgrade from MSMQ 1.0.

Notes

  • To install Message Queuing, you may also need the Delete MSMQ Configuration Objects permission, because if Setup finds an msmq (MSMQ Configuration) object in Active Directory, it must delete it before creating a new one.
  • To uninstall Message Queuing, you must be granted the Delete MSMQ Configuration Objects permission.


Choosing installation subcomponents

The following table lists the subcomponents of Message Queuing, the 32-bit Windows Server 2003 family operating systems on which they can be installed, their dependencies on other subcomponents, and their names in the .inf file.

Component or subcomponent name | Description and setup steps | Suitable platforms | Depends on | Name in the .inf file
Message Queuing | Parent for all subcomponents | All Windows Server 2003 family operating systems except XOX | DTC | msmq
Common | Performs common setup tasks, parent for the Core and Local Storage subcomponents | All Windows Server 2003 family operating systems. | none | msmq_Common
Core | Performs the most fundamental setup operations, creates and sets registry keys, and provides dependent client functionality | All Windows Server 2003 family operating systems. | none | msmq_Core
Local Storage | Creates and installs the Message Queuing service and provides independent client functionality | All Windows Server 2003 family operating systems. | Core | msmq_LocalStorage
Active Directory Integration | Creates an msmq object and (if needed) an MSMQ Setting object in Active Directory and thereby provides integration with Active Directory whenever the computer belongs to a domain | All Windows Server 2003 family operating systems. | Local storage | msmq_ADIntegrated
Triggers | Installs the Message Queuing Triggers service | All Windows Server 2003 family operating systems. | Local storage | msmq_TriggersService
MSMQ HTTP Support | Creates an IIS extension for Message Queuing (called MSMQ) | All Windows Server 2003 family operating systems. | Local storage, IIS (the World Wide Web Publishing service) | msmq_HTTPSupport
Routing Support | Creates an MSMQ Setting object in Active Directory and provides Message Queuing routing server functionality | Windows Server 2003 family operating systems. | Active Directory Integration | msmq_RoutingSupport
Downlevel Client Support | Installs the Message Queuing directory service on a domain controller | All Windows Server 2003 family operating systems. | Active Directory Integration | msmq_MQDSService

The Message Queuing subcomponent tree has the following form:

Message Queuing
line graphic Common
line graphic line graphic Core
line graphic line graphic Local Storage
line graphic Active Directory Integration
line graphic Triggers
line graphic MSMQ HTTP Support
line graphic Routing Support
line graphic Downlevel Client Support

Notes

  • On 64-bit platforms, the Core and Local Storage subcomponents are combined in a single subcomponent, called Common, which in this case, provides independent client functionality.

Default options

When you select Message Queuing in the Windows Components Wizard on computers running on platforms from the Windows Server 2003 family, the following subcomponents are selected by default:

  • Common (consisting of Local Storage and Core)
  • Local Storage
  • Active Directory Integration

This means that, by default, an independent client capable of integrating with Active Directory (whenever the computer belongs to a domain) will be installed on computers running Windows Server 2003 family operating systems.

If a computer belongs to a workgroup, the Active Directory Integration subcomponent is selected by default. In workgroup mode, the presence of this subcomponent means that the computer will allow for the possibility that it joined a domain and will try to integrate with Active Directory each time the Message Queuing service is started (that is, it will attempt to create an msmq object in Active Directory, and so on). As long as the computer remains in workgroup mode, no msmq object is created in Active Directory, only direct messages can be sent, and only private queues can be created or deleted.

Computers running on 64-bit platforms

A dependent client cannot be installed on a computer running on a 64-bit Windows Server 2003 family platform. Therefore, we can simplify the list of Message Queuing subcomponents for 64-bit computers by combining the Core and Local Storage subcomponents into a single Common subcomponent, and we do not need two levels of Message Queuing subcomponents. The subcomponent tree for 64-bit computers has the following form:

Message Queuing
line graphic Common
line graphic Active Directory Integration
line graphic Triggers
line graphic MSMQ HTTP Support
line graphic Routing Support
line graphic Downlevel Client Support

The Routing Support and Downlevel Client Support subcomponents are available only on platforms from the Windows Server 2003 family. Furthermore, Downlevel Client Support can be installed only on a domain controller. If only the Core subcomponent is selected, an independent client will be installed.

The following table shows the subcomponent dependencies for 64-bit computers.

Subcomponent name | Depends on | Comment
Message Queuing | DTC | parent
Core | none | none
Active Directory Integration | Core | none
Triggers | Core | none
MSMQ HTTP Support | Core, IIS (the World Wide Web Publishing service) | none
Routing Support | Active Directory Integration | only on servers
Downlevel Client Support | Active Directory Integration | only on servers

Registry keys

A registry key is created in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Setup for each subcomponent installed, and its value is set equal to 0x1. It indicates that the applicable subcomponent was installed successfully on the computer. The absence of a key means that the subcomponent was not installed. The following list gives the names of these registry keys:

  • msmq_Core
  • msmq_LocalStorage
  • msmq_ADIntegrated
  • msmq_TriggersService
  • msmq_HTTPSupport
  • msmq_RoutingSupport
  • msmq_MQDSService


Active Directory Integration subcomponent

During a default installation, the Active Directory Integration subcomponent is installed, regardless of whether your computer is a member of a domain.

If you are installing Message Queuing on a computer that is a member of a Windows Server 2003 or Windows 2000 domain, you can specify whether the computer will operate in domain mode, by installing the Active Directory Integration subcomponent, or in workgroup mode, by not installing the subcomponent. In the context of Message Queuing, workgroup mode can be defined as any mode of operation that does not allow access to a directory service, even if the applicable computer belongs to a domain. The workgroup mode of operation requires direct connectivity to send messages.

If you are installing Message Queuing on a computer that belongs to a domain and you select the Active Directory Integration subcomponent (as in the default configuration), Setup will attempt to contact a Windows Server 2003 or Windows 2000 Server domain controller in the local site or a nearby site. If successful, the computer will operate in domain mode, meaning that access to Active Directory will be enabled and an msmq object will be created in Active Directory. Note that a Windows Server 2003 or Windows 2000 Serverdomain controller can only be found automatically. If one of these domain controllers cannot be located, you will be prompted for the name of an MSMQ 1.0 PEC or PSC (in a Windows NT 4.0 enterprise) in the local site. If you do not supply such a name, and select Next, Message Queuing will be installed in workgroup mode. In such a situation, where your computer belongs to a domain and has the Active Directory Integration subcomponent installed, but is temporarily unable to access a domain controller, the computer will work in workgroup mode. However, the next time you restart such a computer, or stop and restart the Message Queuing service, Message Queuing will automatically attempt to contact a domain controller in the local domain. If a domain controller is available and contact is successful, the computer will then operate in domain mode.

If your computer does not belong to a domain, default installation of the Active Directory Integration subcomponent allows for the possibility that the computer might later join a domain.

For more information on the characteristics of workgroup mode, domain mode, and offline mode, see Deploying in a domain environment, and Deploying in workgroup mode.

For information on security permissions required by Message Queuing with the Active Directory Integration component on a computer that belongs to a domain, see Installation permissions.

.


Installing Message Queuing Computers

This section provides information about installing different types of Message Queuing computers, and the platforms that support them. For details, see the following links:

  • For a summary of what types of Message Queuing computers can be installed on different Windows Server 2003 family computers, see Installation platforms for Message Queuing computers.
  • For information on installing Message Queuing servers, and the necessary requirements, see Installing Message Queuing servers.
  • For information on installing Message Queuing on a domain controller, see Installing on a domain controller.
  • For details of requirements for installing independent clients, see Installing independent clients.
  • To learn about installing dependent clients with a supporting server, see Installing dependent clients.

Note that for the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed on it. The term Message Queuing client can refer to either an independent client or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed. Such computers are referred to as having independent client functionality or dependent client functionality.


Installation platforms for Message Queuing computers

The following table shows which types of Message Queuing computers can be created on which Windows Server 2003 family operating systems.

Type of Message Queuing computer | Windows Server 2003 family operating systems
Message Queuing server | All Windows Server 2003 family operating systems
Independent client | All Windows Server 2003 family operating systems
Dependent client | All 32-bit Windows Server 2003 family operating systems

Notes

  • For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed. The term Message Queuing client can refer to either an independent client or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality or dependent client functionality.
  • A dependent client cannot be installed on a computer operating in workgroup mode or on a 64-bit computer.


Installing Message Queuing servers

This topic covers the installation of Message Queuing server software on computers running on platforms from the Windows Server 2003 family that do not have previous versions of Message Queuing installed.

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed. The term Message Queuing client can refer to either an independent client or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality or dependent client functionality.

Before installing a Message Queuing server on a Windows Server 2003 family computer in a particular site, verify that there is at least one Windows Server 2003 or Windows 2000 domain controller trusted for delegation in the local site or in a nearby site. To reduce replication traffic, configure a Windows Server 2003 or Windows 2000 domain controller in each site as a global catalog server. During setup, an attempt is made to automatically detect the nearest Windows Server 2003 or Windows 2000 domain controller in the local site or in a nearby site. If a suitable domain controller cannot be found, Setup assumes that you are installing a Message Queuing client in a Windows NT 4.0 environment and prompts you for the name of a controller server (PEC or PSC) before Setup can continue.

If a Windows Server 2003 or Windows 2000 domain controller is not available, you can also start the installation again and install Message Queuing without the Active Directory Integration subcomponent. If this option is chosen, only private queues can be created and managed, direct connectivity is needed to send messages, and the computer will never try to access Active Directory. In the context of Message Queuing, any mode of operation that does not allow access to a directory service is called workgroup mode, even if the applicable computer belongs to a domain.

Alternatively, Message Queuing can be installed on a computer that belongs to a workgroup and has not joined a domain. In this case, Setup will install Message Queuing in workgroup mode. In this mode of operation, only private queues can be created and managed, and direct connectivity is needed to send messages. However, in this case, the Active Directory Integration subcomponent will be installed, but the computer will not be able to access Active Directory and will continue to operate in workgroup mode until it joins a domain. After the computer joins a domain, the next time you restart it, or stop and restart the Message Queuing service, Message Queuing will automatically attempt to access Active Directory through a domain controller in the local domain and create an msmq object.

Similarly, if a Message Queuing server is taken offline or if all the domain controllers from its domain in the local and nearby sites are offline, the computer will not have access to Active Directory and will operate in offline mode. As in workgroup mode, only private queues can be created and managed and direct connectivity is needed to send messages. Each time the computer is restarted, Message Queuing will attempt to locate its domain controller. If successful, Message Queuing will return to the domain mode of operation, which enables access to Active Directory.

Before you can install a Message Queuing server, the following requirements must first be met:

  • You must install a Windows Server 2003 family platform from the server family.
  • To install a Message Queuing server on a Windows Server 2003 family domain controller, you must be logged on with domain administrative permissions or belong to the Domain Admins group.
  • To install a Message Queuing server with routing services on a nondomain controller, you must be logged on with enterprise administrative permissions or belong to the Enterprise Admins group.
  • To install Message Queuing, you may also need the Delete MSMQ Configuration Objects permission, because if Setup finds an msmq (MSMQ Configuration) object in Active Directory, it must delete the object before creating a new one.
  • To uninstall Message Queuing, you must be granted the Delete MSMQ Configuration Object permission.

For more information on the administrative permissions required for installation, see Installation permissions.

Installing additional Message Queuing servers

In a domain environment, when Message Queuing servers are installed on additional Windows Server 2003 family computers in the same site, Setup automatically attempts to locate a Windows Server 2003 domain controller, or Windows 2000 domain controller, in the local or a nearby site. If one cannot be located, Setup assumes that you are installing a Message Queuing client in a Windows NT 4.0 environment and prompts you for the name of a controller server (PEC or PSC) before Setup can continue.

For information on installing Message Queuing servers on additional Windows 2000 computers in the same site, see the version of this topic in the online Help file for Message Queuing in a Windows 2000 computer.

If you are installing a Message Queuing server with routing services in a mixed-mode domain environment, you must specify the name of a Windows Server 2003 domain controller running the Message Queuing directory service (Downlevel Client Support) or a Windows 2000 domain controller hosting a Message Queuing server in the same site (not the name of an MSMQ 1.0 PSC) if prompted during setup.

You can also choose to install a Message Queuing server without routing on a nondomain controller in a workgroup environment (or any other environment that does not provide a directory service such as Active Directory). In this case, direct connectivity is required to send messages.


Installing on a domain controller

If Message Queuing is being installed only on Windows Server 2003 family computers in a particular site, there is no need to install Message Queuing on a domain controller in that site because Message Queuing clients on Windows Server 2003 family computers can access Active Directory directly. However, if you intend to install Message Queuing on a Windows 2000 computer in a site, you must install Message Queuing with Downlevel Client Support on a Windows Server 2003 domain controller in the site, or install a Message Queuing server on a Windows 2000 domain controller in the site, or promote the Windows 2000 computer on which you want to install a Message Queuing server to a domain controller. In addition, even in a pure Windows Server 2003 family enterprise, enabling routing services for Message Queuing servers running on domain controllers may degrade performance. It is therefore preferable to install such Message Queuing servers on nondomain controllers. If you need to install Message Queuing on a domain controller (because you want to run an application over Message Queuing), it is recommended that you install a Message Queuing server without routing enabled (a server with independent client functionality).

To create a server that will provide access to Active Directory for Message Queuing 1.0 clients on Windows 95, Windows 98, Windows Millennium Edition, Windows NT 4.0 computers, or Message Queuing 2.0 clients running on Windows 2000 computers, promote the computer to a Windows Server 2003 domain controller. For information on how to promote a computer to a Windows Server 2003 family domain controller, see the Active Directory Help topic on installing on a domain controller.

Furthermore, before you can install MSMQ 1.0 on clients running on Windows NT 4.0, Windows 98, or Windows 95 computers, in a Windows Server 2003 domain, there must be at least one domain controller running the Message Queuing directory service (Downlevel Client Support component) or Message Queuing 2.0 that is configured as a global catalog server in the local site from the domain of each computer on which you want to install MSMQ 1.0. For information on how to configure a domain controller as a global catalog server, see Configure a domain controller as a global catalog server. For more information on the global catalog in Active Directory, see The role of the global catalog. Note that the Message Queuing Downlevel Client Support service must run under the default LocalSystem account.

For each applicable domain controller, also verify that it is trusted for delegation before installing Message Queuing. This property is enabled by default. If this property is disabled, the Message Queuing service cannot run. For information on how to verify that this property is enabled, see Make a domain controller trusted for delegation.

If you install a Message Queuing server with Downlevel Client Support on a domain controller and security has not been weakened in your forest to support MSMQ 1.0 clients or Message Queuing 2.0 clients logged on with local user accounts, Setup prompts you about whether or not to weaken security. This mode of operation is optional. However, to effectively support computers running MSMQ 1.0 and computers running Message Queuing 2.0 that are logged on using a local user account, security for Active Directory needs to be weakened. Nevertheless, dependent clients cannot run under a local user account, and 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, will not be able to access Active Directory when it logs on using a local user account even if the security for Active Directory is weakened. For more information, see Enabling weakened security.

For information on how to install a Message Queuing server after all requirements are met, see Install Message Queuing servers.

Important

  • When you make a change from a computer running a Windows Server 2003 operating system against directory service objects belonging to computers running Windows 95, Windows 98, Windows NT 4.0, or Windows 2000, these earlier computers are unable to receive notification about the change from the Windows Server 2003 family computer. To resolve this, Active Directory detects by default that the object belongs to an earlier computer and attempts to make the change without accessing Active Directory directly. To override this default behavior:
    • For a single computer, set the DisableDownlevelNotifications key in the registry.
    • For an enterprise-wide system, set the PROPID_E_CSP_NAME attribute in the msmq enterprise object.
  • Each Windows Server 2003 family site containing MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers must contain at least one Windows Server 2003 domain controller that is running the Message Queuing directory service (Downlevel Client Support) and is configured as a global catalog server or at least one Windows 2000 domain controller that is running Message Queuing and is configured as a global catalog server from the domain of each such client. This is required to enable such clients to communicate with Message Queuing servers. For information on how to configure a computer as a global catalog server, see Configure a domain controller as a global catalog server.


Installing independent clients

This topic covers the installation of Message Queuing servers with independent client functionality on computers. Computers configured as independent clients can operate in workgroup mode or Active Directory domain mode. These computers run the Message Queuing service, host queues, send and receive messages, operate while disconnected from the network, access Active Directory directly, and can act as a supporting server for dependent clients. However, for an independent client in workgroup mode, direct connectivity is required to send messages, and the computer cannot act as a supporting server for dependent clients. For more information, see Independent clients.

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed. The term Message Queuing client can refer to either an independent client or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality or dependent client functionality.

Before installing a Message Queuing server with independent client functionality, note the following:

  • To install Message Queuing in domain mode, you must have network connectivity. During a default installation, the Active Directory Integration subcomponent is installed, and Setup will automatically attempt to contact a Windows Server 2003 or Windows 2000 domain controller. If this attempt is successful, Message Queuing is installed in domain mode. If such a domain controller cannot be found, you will be prompted to enter the name of an MSMQ 1.0 PEC or PSC in the local site (for a Windows NT 4.0 enterprise). If you do not enter a name, Message Queuing will automatically be installed in workgroup mode. In the context of Message Queuing, any mode of operation that does not allow access to a directory service is called workgroup mode, even if the applicable computer belongs to a domain. The workgroup mode of operation requires direct connectivity to send messages.
  • During a default installation, the Active Directory Integration component is installed. If your computer is in a domain, but without Active Directory access, this component will attempt to access a domain controller and work in domain mode each time the computer, or the Message Queuing service, is restarted. If your computer is not part of a domain and is in workgroup mode, installing this component provides you with the option of joining the computer to a domain at a later time.
  • You can also install your Message Queuing server with independent client functionality in workgroup mode by canceling the selection of the Active Directory Integration component that is selected as part of the default installation settings.
  • You must be logged on with local administrative permissions (as a member of the local Administrators group). For more information on the permissions required for installation, see Installation permissions.
  • If you are installing a Message Queuing server with independent client functionality on a Windows Server 2003 family computer in a Windows NT 4.0 enterprise, and you want to specify an MSMQ 1.0 PEC during installation, you can only do this from unattended setup. For more information, see Unattended setup.
  • To install Message Queuing, you may also need the Delete MSMQ Configuration Objects permission, because if Setup finds an msmq (MSMQ Configuration) object in Active Directory, it must delete the object before creating a new one.
  • To uninstall Message Queuing, you must be granted the Delete MSMQ Configuration Object permission.
  • A Message Queuing server configured with independent client functionality does not have the Routing subcomponent enabled. In addition, the Downlevel Client Support component is not enabled, and independent clients cannot provide Active Directory access for MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers, or Message Queuing 2.0 clients running on Windows 2000 computers.

For instructions on how to install an independent client after all requirements are met, see Install independent clients.


Installing dependent clients

This topic describes the installation of Message Queuing servers with dependent client functionality. It is recommended that you install independent clients wherever possible.

For the purposes of this documentation, the term Message Queuing server refers to a Windows Server 2003 family computer that has Message Queuing installed. The term Message Queuing client can refer to either an independent client, or a dependent client. Both of these terms are used to describe Message Queuing servers that have particular Message Queuing components installed, and such computers are referred to as having independent client functionality, or dependent client functionality.

Before you can install Message Queuing with dependent client functionality, the following requirements must first be met:

  • You must have network connectivity and be able to contact a supporting server.
  • Dependent clients cannot be installed on 64-bit computers, or on Windows Server 2003 family computers operating in workgroup mode.
  • You must be logged on with local administrative permissions as a member of the local Administrators group. For more information on the permissions required for installation, see Installation permissions.
  • You must have a Windows Server 2003 family computer installed with at least independent client functionality, to act as a supporting server. This computer must be configured to support dependent clients.
  • Note that computers configured as independent clients cannot provide Active Directory access for MSMQ 1.0 clients. These clients require Message Queuing servers running on a domain controller to act as a supporting server.

Supporting servers for dependent clients.

A dependent client requires server support for all its messaging functionality. The Message Queuing server that supports a dependent client (by storing queues and messages) is referred to as the supporting server. Note that following installation, Message Queuing servers are not configured to support dependent clients. In addition, to enable a Windows Server 2003 family computer to act as the supporting server for dependent clients, you must change the security configuration of the Microsoft Distributed Transaction Coordinator (DTC) to enable network DTC. For instructions on enabling dependent client support and changing the DTC configuration, see Enable a supporting server.

During setup of a dependent client, you must specify the name of such a Message Queuing server in the same site or in a nearby site. If no name is specified, setup cannot continue. Dependent clients and their supporting servers do not have to be in the same site. However, because all communication with the dependent client goes through the supporting Message Queuing server, if the communication link to the supporting server is slow or expensive, all dependent client communication will also be slow or expensive.

For information on how to install a dependent client after all installation requirements have been met, see Install dependent clients.


Installing Message Queuing triggers

Message Queuing Triggers is an integral part of Message Queuing and can be installed during Message Queuing Setup by selecting the Triggers subcomponent. Triggers and rules are defined and managed in the Computer Management snap-in. Diagnostic data generated by the Message Queuing Triggers service are recorded in the Application Log and can be viewed using Event Viewer.

The support for Message Queuing Triggers can be installed by Message Queuing Setup during the installation of a Message Queuing server or independent client on computers running platforms from the Windows Server 2003 family. Message Queuing Triggers cannot be installed on a dependent client.

To install Message Queuing Triggers, select the Triggers subcomponent of Message Queuing during the installation of a Message Queuing server or an independent client. If the check box for this subcomponent is selected, the Triggers service is installed automatically and started. If this check box is not selected, the Triggers service can be installed later by running Add or Remove Programs and selecting Triggers in the Windows Components Wizard.

An answer file for unattended setup can contain an msmq_TriggersService = ON entry, which corresponds to selecting the Triggers check box on the Message Queuing page of the Windows Components Wizard.

Setup requires the presence of four files for the Triggers service in the \Windows\System32 folder: mqtrig.dll, mqtgsvc.exe, mqgentr.dll, and mqtgclus.dll.

By default, the Message Queuing Triggers service runs under the Network Service account. Services that are running under this account interact with the network using the credentials of the computer account, and this account has the same level of access to resources and objects as members of the Users group accounts. For heightened security, you can change the default Triggers service account to a more secure setting; for example, the Local Service account, which limits access to the local computer. You can also specify a less secure account for the Triggers service; for example, the Local System account, allowing access to the entire domain. Note that the Triggers service running under the Network Service account does not interact with the desktop. If this functionality is required, you can configure the Triggers service to run under the Local System account, and enable interaction with the desktop in Computer Management.

Message Queuing Triggers installs with a set of default configuration values that are stored in the registry. These values can be changed later using the Computer Management snap-in. For more information on how to change the default configuration, see Change default configuration values for triggers.

Message Queuing Triggers is cluster-aware and supports the active/active model. When the Message Queuing service fails over to another node, the Triggers service can fail over along with it. For this to occur, you must create a Message Queuing Triggers resource with resource dependencies on the Message Queuing resource and the Cluster Name resource on the applicable node using Cluster Administrator, and you must bring it online. The trigger and rule definitions for the cluster resource are stored in the local Windows registry. The Message Queuing Triggers resource is checkpointed with this registry key and the subkeys under it so that when the resource is moved to a new node (during failover, for example), the required keys propagate to the local registry on the new node. After failover, the Triggers service can thus continue to process the incoming messages in each monitored queue and invoke the applicable stand-alone executable or COM component according to the rules defined. For more information on server clusters and the active/active model, see Distributing Message Queuing in a network. For more information on creating and configuring Message Queuing Triggers resources in a virtual server, see Configure trigger resources for server clusters.


Installing Message Queuing in a server cluster

This section applies only to users running XOX or XOX in a server cluster configuration. Installing Message Queuing in a server cluster will provide active/active queue failover in case of computer failure or malfunction.

Installing the required instances of the Message Queuing service on each node of a server cluster before creating and configuring a Message Queuing resource is similar to installing Message Queuing on any other server. However, there are several additional requirements and considerations to keep in mind when installing Message Queuing in a server cluster, including the following:

  • Install Message Queuing with the same set of subcomponents on all nodes in a server cluster. For example, if you install a Message Queuing server with Routing Support on one node, install Message Queuing servers with Routing Support on the other nodes as well.
  • Create one Message Queuing resource for each cluster group, using Cluster Administrator. To open Cluster Administrator, click Start, point to All Programs, point to Administrative Tools, and then click Cluster Administrator.
  • If you intend to use triggers, HTTP/HTTPS messaging, or external transactions on your cluster, before creating a Message Queuing resource in any cluster group hosted on a computer in a server cluster, do the following:
    • Cluster Microsoft Distributed Transaction Coordinator (DTC). This must be done using Cluster Administrator, and not by running comclust.exe. DTC is installed by default on Windows Server 2003 family operating systems.
    • Configure the DTC, create a DTC resource, and bring it online. Note that only one DTC resource is created for an entire server cluster. For more information on creating a DTC resource, see Checklist: Installing a Distributed Transaction Coordinator resource, in the Server Clusters Help file. For instructions on bringing a DTC resource online, see Bring a resource online, in the Server Clusters Help file.
    • After the DTC resource is online, install Message Queuing on each cluster node.
  • After the preceding tasks are completed, you can create Message Queuing resources on any virtual server in the cluster. When you create a Message Queuing resource in a cluster group, configure it with a Network Name resource and a Disk resource using Cluster Administrator. For instructions on configuring Message Queuing and Message Queuing Triggers resources for server clusters, see Configure Message Queuing resources for server clusters, and Configure trigger resources for server clusters.

Notes

  • It is recommended that Message Queuing be installed on the physical computer before creating a Message Queuing resource.
  • You must not create more than one Message Queuing resource in a single cluster group, because the behavior of such multiple resources is undefined.
  • To uninstall Message Queuing on a computer that is part of a server cluster, the Message Queuing virtual server must be deleted from the node before uninstalling Message Queuing on the physical node computer.
  • On a cluster, the Message Queuing service start configuration is set to manual. Thus, after restarting a node computer, the Message Queuing service running on the node does not restart automatically. However, Message Queuing resources that were online do come back online automatically.
  • For more information on configuring resources using Cluster Administrator, see Server Cluster Resources, in the Server Clusters Help file.
  • For information on upgrading Message Queuing in a server cluster, see Upgrading Message Queuing in a server cluster.
  • For instructions on how to start the Message Queuing service, see Start or stop services for Message Queuing.


Unattended setup

You can use Windows unattended setup to install Message Queuing software by remotely using an answer file. It is recommended that this file be located either in the Message Queuing installation folder on the source computer from which you are running unattended setup or in the Windows system folder (typically C:\Windows) on the target computer on which you are installing Message Queuing.

For more information on unattended setup for Windows Server 2003 family, see Planning for unattended setup in the Windows Help file.

During Message Queuing unattended setup, no text or dialog boxes are displayed. Errors are logged to the Msmqinst.log file located in the Windows system folder (typically C:\Windows) of the target computer.

Because the name of an online Message Queuing server is required for some installation types, it is easiest to create and run separate unattended setup scripts for computers in each Windows Server 2003 family or Windows 2000 site. You can use a single script file for multiple sites, but if you do so, you must create separate file entries for each computer that is not in the specified (default) site.

To run Message Queuing unattended setup, type the following command at the command prompt in the Windows system folder:

sysocmgr.exe /i:sysoc.inf /u:path and file name of answer file

Answer file entries

The answer file specifies various installation settings. The applicable settings for Message Queuing are described below.

Setup looks in the [Components] section to determine what to do for each of the Message Queuing subcomponents. In this section ON means to install the subcomponent, and OFF means to uninstall it, while the absence of an entry means that the state of the subcomponent will not be changed. The keys appearing in entries in this section are as follows:

msmq_Core

An msmq_Core = ON entry calls for installation of the Core subcomponent, which performs the most fundamental setup operations: creates and sets registry keys, and provides dependent client functionality. It is mandatory if you want to install Message Queuing. To install a dependent client, you must specify a supporting server. The supporting server can be any Message Queuing server operating in domain mode with at least independent client functionality, preferably in the local site, but also in a nearby site. Specify its name using the SupportingServer key in the [msmq] section. No additional subcomponents can be installed on a dependent client. To perform an unattended uninstallation of Message Queuing software, include the entry msmq_Core = OFF. All message and log files are removed when Message Queuing is uninstalled. However, no Message Queuing files are removed from the \Windows\System32 and \Windows\System32\Drivers folders.

msmq_LocalStorage

An msmq_LocalStorage = ON entry calls for installation of the Local Storage subcomponent, which installs the Message Queuing service and provides independent client functionality. This entry is mandatory if you are installing any additional subcomponent. Local Storage cannot be installed without the Core subcomponent. Thus, if you are installing Local Storage, there is no need to include an msmq_Core = ON entry. This subcomponent will be installed automatically. After the Local Storage subcomponent is installed, it cannot be removed without completely uninstalling Message Queuing.

msmq_ADIntegrated

The entry msmq_ADIntegrated = ON calls for installation of the Active Directory Integration subcomponent, which creates an msmq object and (if needed) an MSMQ Setting object in Active Directory and thereby provides integration with Active Directory whenever the computer belongs to a domain. If you want to use a specific pre-Windows 2000 domain controller, you must specify it using the ControllerServer key in the [msmq] section. Active Directory Integration cannot be installed without the Core and Local Storage subcomponents. Thus, if you are installing Active Directory Integration, there is no need to include msmq_Core = ON and msmq_LocalStorage = ON entries. The applicable subcomponents will be installed automatically.

You can include an msmq_ADIntegrated = ON entry if you are installing Message Queuing in a workgroup environment or any environment that does not have access to Active Directory. In this case, the ControllerServer entry is ignored and the computer will never attempt to connect to a domain controller to access Active Directory. Such a computer requires direct connectivity to other computers to send and receive messages. This entry is applicable only if you are installing a configuration with independent client functionality on a nondomain controller.

msmq_TriggersService

This key specifies whether the Message Queuing Triggers service will be installed. If you include an msmq_TriggersService = ON entry, it will be installed. Conversely, if you include an msmq_TriggersService = OFF entry, it will be removed. Setting this key equal to ON is equivalent to selecting the Triggers subcomponent during the installation of Message Queuing with independent client functionality. Thus, if you are installing Triggers, there is no need to include msmq_Core = ON and msmq_LocalStorage = ON entries. These subcomponents will be installed automatically.

msmq_HTTPSupport

This key specifies whether MSMQ HTTP Support, which installs Internet Information Services (IIS) and creates an IIS extension for Message Queuing (MSMQ), will be installed. If the answer file includes an msmq_HTTPSupport = ON entry, an IIS extension will be created. Conversely, if you include an msmq_HTTPSupport = OFF entry, the extension will be removed. MSMQ HTTP Support cannot be installed without the Core and Local Storage subcomponents. Thus, if you are installing MSMQ HTTP Support, there is no need to include msmq_Core = ON and msmq_LocalStorage = ON entries. The applicable subcomponents will be installed automatically.

msmq_RoutingSupport

The entry msmq_RoutingSupport = ON calls for installation of the Routing Support subcomponent, which creates an MSMQ Setting object in Active Directory and provides routing services. This key can be used only when you are installing Message Queuing on computers running on platforms from the Windows Server 2003 family. The Routing Support subcomponent can only be installed on computers that have access to Active Directory. Routing Support cannot be installed without the Core, Local Storage, and Active Directory Integration subcomponents. Thus, if you are installing Routing Support, there is no need to include msmq_Core = ON, msmq_LocalStorage = ON, and msmq_ADIntegrated = ON entries. The applicable subcomponents will be installed automatically. Routing Support can be uninstalled by including an msmq_RoutingSupport = OFF entry.

msmq_MQDSService

Include a msmq_MQDSService = ON entry if you need to install the Message Queuing directory service on a domain controller to provide access to Message Queuing objects in Active Directory for downlevel clients. Setting this key equal to ON is equivalent to selecting the Downlevel Client Support subcomponent during the installation of Message Queuing on a domain controller. This key is relevant only to platforms from the Windows Server 2003 family. To install Downlevel Client Support, Message Queuing must be integrated with Active Directory.

The keys appearing in entries in the [msmq] section are as follows:

ControllerServer

This key specifies the NetBIOS or DNS name of the MSMQ 1.0 site controller hosting a Message Queuing server that the computer will try to contact during Setup. Specifying a Windows 2000 domain controller or a Windows Server 2003 domain controller will generate an error. This key is applicable only to an independent client or a routing server being installed on a domain computer and only when msmq_ADIntegrated is set equal to ON. It is optional, but if it is not included in the answer file, Setup will try to find a suitable domain controller automatically through AD.lib. If an entry is specified, unattended setup will use the entry and will not attempt to find the computer automatically. If it fails, however, unattended setup will not continue.

Do not include an entry with this key if you are installing Message Queuing on a domain controller.

SupportingServer

This key is set equal to the NetBIOS or DNS name of a Message Queuing server that will be used to support the dependent client being installed. This entry is required when you are creating a dependent client.

SupportLocalAccountsOrNT4

A SupportLocalAccountsOrNT4 = TRUE entry provides support for computers running MSMQ 1.0 and computers running Message Queuing 2.0 that are logged on using a local user account. This entry enables weakened security for Active Directory on a domain controller, which is then replicated to all other domain controllers in every domain in your forest. Thus, it must be included only for the first instance of Message Queuing with Downlevel Client Support on a domain controller in your forest, and Downlevel Client Support must be installed on all domain controllers. Then, computers requiring this support will be able to query Active Directory and view the properties of Message Queuing objects. Otherwise, such computers will not be able to query Active Directory about Message Queuing objects. This key is optional, and if it is set to FALSE, weakened security is removed.

For the security implications of weakening Active Directory security, see Enabling weakened security.

Notes

  • 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, will not be able to access Active Directory when it logs on using a local user account even if weakened security for Active Directory is enabled.

Site

Include a line with this key if you are installing a Message Queuing routing server. Setup may not be able to automatically resolve the proper site if subnets in your network are not configured correctly. In such a case, this entry becomes mandatory. Set the key equal to the name of the default Active Directory site containing the domain controller with which this server will communicate.

Sample answer file

You can use the following sample answer file as a template. Use a text editor to appropriately edit the entries.

Note

  • Unattended setup ignores any file entries that begin with a semicolon (;). You can use these to place comments in your answer file.

  [Version]
  Signature = "$Windows NT$"

  [Global]
  FreshMode = Custom
  MaintenanceMode = RemoveAll
  UpgradeMode = UpgradeOnly

  [Components]
  msmq_Core = ON | OFF
  msmq_LocalStorage = ON | OFF
  msmq_ADIntegrated = ON | OFF
  msmq_TriggersService = ON | OFF
  msmq_HTTPSupport = ON | OFF
  msmq_RoutingSupport = ON | OFF
  msmq_MQDSService = ON | OFF

  [Msmq]
  ControllerServer = MyDomainController
  SupportingServer = MyDomainControllerOrRoutingServer
  SupportLocalAccountsOrNT4 = FALSE | TRUE
  Site = DefaultFirstSiteName

Be sure to test your unattended setup script before deployment.


Uninstalling Message Queuing

To uninstall Message Queuing software from a computer, it is recommended that you first be granted the Delete MSMQ Configuration Object permission. If you do not have this permission, you can still uninstall Message Queuing, but this object will not be deleted from Active Directory. For more information on installation permissions, see Installation permissions.

Running Message Queuing Setup

You uninstall Message Queuing using Add or Remove Programs in Control Panel. When you uninstall Message Queuing from a computer, Message Queuing Setup removes all of the queues (including private queues) and messages for that computer from Active Directory and from the local computer. However, no Message Queuing files are removed from the \Windows\System32 and \Windows\System32\Drivers folders.

When you uninstall a Message Queuing server, all the applicable computer objects (the MSMQ Configuration and MSMQ Settings objects) are also deleted, and the name of the server is removed from the message routing lists of clients using that server.

For information on how to uninstall Message Queuing software, see Uninstall Message Queuing.

You can also uninstall certain individual Message Queuing subcomponents by running Add or Remove Programs and clearing the check boxes for the applicable subcomponents in the Windows Components Wizard. For more information on the Message Queuing subcomponents, see Choosing installation subcomponents.

Removing Message Queuing objects from Active Directory

If you cannot uninstall Message Queuing software from a computer, such as during a hardware malfunction or if you no longer have physical access to a computer, you can remove Message Queuing objects for the computer from Active Directory. When you remove the Message Queuing objects from Active Directory, all queues and messages on the local computer are also removed.

For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, see Message Queuing and Active Directory.

For information on how to remove objects for Message Queuing in Active Directory, see Remove Message Queuing objects from Active Directory.

Notes

  • You must not delete the MsmqServices object unless you are removing Message Queuing from every computer in your organization. This object is the "enterprise" object for Message Queuing.


Upgrading to Message Queuing

This section explains the requirements for upgrading earlier versions of Message Queuing software (MSMQ 1.0 and MSMQ 2.0) on computers that are being upgraded to Windows Server 2003 family operating systems from Windows NT Server 4.0 or Windows 2000 Server. For details, see the following links:

  • For an overview of upgrading, see Upgrade overview.
  • For information on upgrading on clusters, see Upgrading Message Queuing in a server cluster.


Upgrade overview

This topic provides an overview of upgrading from MSMQ 1.0 on Windows NT Server 4.0 computers, and from Message Queuing 2.0, which runs on Windows 2000, to Message Queuing 3.0.

Upgrading from MSMQ 2.0 on Windows 2000 computers

MSMQ 2.0, running on a Windows 2000 computer will automatically be updated to Message Queuing 3.0 during the upgrade to a Windows Server 2003 family operating system.

Upgrading from MSMQ 1.0 on Windows NT 4.0 computers

For computers running Windows NT Server 4.0, the Message Queuing software is also automatically upgraded to Message Queuing 3.0, with the exception of MSMQ 1.0 controller servers. Message Queuing is upgraded for controller servers using the Message Queuing migration tool. The upgrade entails upgrading MSMQ 1.0 controller servers, and migrating all the information stored in the MQIS database to Active Directory. After the upgrade, PECs will be upgraded to a Windows Server 2003 family operating system, promoted to domain controllers, and running Message Queuing 3.0. Other MSMQ 1.0 controller servers will be upgraded to Windows Server 2003 family computers, running as Message Queuing 3.0 routing servers.

Note that mixed-mode operation is not permitted in Message Queuing 3.0. In other words, a configuration of MSMQ 1.0 controller servers running on Windows NT 4.0 computers, together with Message Queuing domain controllers in a Windows Server 2003 domain environment, is not supported.

For more information on this upgrade scenario, see the white paper at Microsoft Message Queuing (http://www.microsoft.com/).


Upgrading Message Queuing in a server cluster

This topic applies only to XOX or XOX users who need to upgrade an existing server cluster that is running an earlier version of Message Queuing software. For more information on how Message Queuing functions in a server cluster, see Distributing Message Queuing in a network.

Upgrading from Windows 2000 on a cluster containing Message Queuing resources

When upgrading Message Queuing resources from a Windows 2000 cluster, do the following:

  • Confirm that your computer hardware configuration is compatible with XOX or XOX.
  • Take all Message Queuing resources in the cluster offline using Cluster Administrator.
  • Upgrade all of the cluster nodes to XOX or XOX. Before upgrading, use Cluster Administrator to remove resources that are not supported by these operating systems.
  • Bring the Network Name resources back online, ensure that the Distributed Transaction Coordinator (DTC) is online, and then bring the Message Queuing resources online. Note that DTC is required if you want to use external transactions, triggers, or HTTP messaging with Message Queuing applications on your cluster.

For instructions on managing cluster resources, see Manage resources, in the Server Clusters Help file.

Note that during a rolling upgrade of a cluster, Windows Server 2003 family computers do not support failover of the Message Queuing service from XOX nodes to Windows 2000 nodes.

For more information on creating and configuring Message Queuing Triggers resources in a virtual server, see Configure trigger resources for server clusters.

Upgrading MSMQ 1.0 in a server cluster

You can also upgrade from Windows NT Server 4.0 to XOX or XOX on a cluster that contains DTC and Message Queuing resources. There is a Knowledge Base (KB) article available with detailed instructions for this upgrade scenario. To search for this KB article, see Searching the Knowledge Base.(http://www.microsoft.com/)


Administering a Message Queuing Network

This section provides conceptual information about common tasks for administering a Message Queuing network. Instructions for completing individual tasks can be found in the How To... section in this online Help file. For details about administering Message Queuing networks, see the following links:

  • For information on moving Windows Server 2003 family computers between sites, see Moving mobile computers between sites.
  • To learn about messaging between different kinds of messaging systems, see Configuring cross-platform messaging.
  • For information on adding and removing sites from a server list, see Adding and removing sites from a server list.
  • For information on routing links, see Configuring routing links.
  • To learn about configuring your company's firewall to allow Message Queuing messages through, see Configuring firewalls for Message Queuing.
  • To learn about configuring DNS settings so that Message Queuing can resolve computer names correctly, see Configuring Message Queuing with a proxy server.


Moving mobile computers between sites

Windows Server 2003 family computers can be moved to other Windows Server 2003 family sites. When you move a computer to a new site, Message Queuing automatically detects the domain controllers in its new site and uses them for information services. It then updates the directory service with the new site in which the computer resides. After the new site is established, all messages that were sent to the computer while it was disconnected are automatically rerouted from the previous site to the new site. Whenever the computer connects at the new site, its messages are routed directly to it at that site. If the computer is a Message Queuing routing server, it automatically recovers its full functionality in the new site.

A Windows Server 2003 family computer that uses an MSMQ 1.0 site controller as an information server is not capable of automatically revealing its new site. In this case, you can provide the name of the new site either before disconnecting the computer from the network or after reconnecting to the network. Selecting a new site enables your computer to connect to the closest controller server and thus optimizes access to the MQIS database. If you specify the new site before disconnecting from the network, messages sent to the computer while it is disconnected are routed directly to the new site while the computer is en route. If the computer's new site is not specified, Message Queuing will attempt to use a site controller in its former site. Any message sent to that computer will be routed to its previous site. This applies only to Message Queuing independent clients and Message Queuing servers without routing enabled. Message Queuing servers that have routing enabled (provide routing services to clients) are not supported in an environment of MSMQ 1.0 site controllers.

For information on how to specify a new site for mobile computers, see Specify a new site for mobile computers.


Configuring cross-platform messaging

For cross-platform messaging to communicate with foreign computers, you must first create a foreign site, add the foreign computers to the foreign site, and create queues on the foreign computers. All of these entities are Message Queuing objects in Active Directory. Then you must create a routing link between the foreign site and a Windows Server 2003 site that contains a Message Queuing server running a connector application, define this Message Queuing server as a site gate for the routing link, and add the foreign site to the list of sites where this computer resides.

Note that for Windows Server 2003 family computers running a connector application, after adding the foreign site to the list of sites, the foreign site will not appear in the list until you restart the Message Queuing service on the domain controller of the domain to which the Message Queuing server running the connector application belongs.

Foreign computers can be assigned to the same foreign site if the computers are all serviced by the same connector application. Connector applications run on Message Queuing servers and enable foreign computers to communicate with other Message Queuing computers in your network. A common Message Queuing connector application is Microsoft MSMQ-MQSeries Bridge. When a Message Queuing computer sends a message to a foreign computer, the message is routed to the Message Queuing server running the connector application in the foreign site because this server is also a site gate in the routing link connecting to the foreign site. When the server identifies the message destination as a queue on a foreign computer, it places it in a connector queue. The message is subsequently processed by the connector application, which communicates with the foreign computer.

You must create a routing link between the foreign site and each Windows Server 2003 family or Windows 2000 site that will communicate with the foreign site. The Message Queuing routing server that runs the connector application in the foreign site must also function as a site gate in each routing link connecting to the foreign site. Site gates are always associated with a particular routing link. Note that if the routing server running the connector application, and functioning as a site gate, is unavailable, site gates in other sites cannot route messages to the applicable connector queue for transmission to computers in the foreign site.

For information on how to create a foreign site, see Create foreign sites.

For information on how to add foreign computers to a foreign site and how to add a Message Queuing server running a connector application to a foreign site, see Add foreign computers to a site.

For information on how to create and configure a routing link, see Routing links.


Adding and removing sites from a server list

In most cases, Message Queuing determines the sites in which servers reside automatically. Message Queuing also offers procedures for manually adding and removing sites from the list of sites where a Message Queuing server with routing enabled, which is also known as a routing server, resides. Any routing server that resides in a specific site can be configured as an in-routing or out-routing server for computers that reside in that site. Such routing servers can be also configured as site gates in routing links to that site. A routing server can reside in multiple sites, and it can be configured as an in-routing server, an out-routing server, or a site gate independently in each site in which it resides.

For information on how to add sites to the list of sites where a Message Queuing server with routing enabled resides, see Add sites to a Message Queuing server's list of sites.

For information on how to remove sites from the list of sites where a Message Queuing server with routing enabled resides, see Remove sites from a Message Queuing server's list of sites.

To learn more about sites and subnets, see Sites overview, in the Active Directory Help file.


Configuring routing links

Message Queuing uses routing links to route messages between sites. When a new Windows Server 2003 site is created, you must also create a corresponding routing link to guarantee that messages can always be sent to other sites. However, you will not be prompted to create a routing link when a new site is created. Create multiple routing links to provide load balancing and redundancy. For more information, see Routing links.

For general information on routing, see Routing overview. For instructions on creating a routing link, see Create routing links.

By default, users in the Enterprise Admins group and Domain Admins group can create or modify routing links. For information on how to set permissions for routing links, see Set permissions for routing link objects.

You can change routing-link costs where alternative routes are possible and you want to enforce one route over another route using link costs. You can assign costs that reflect the differences in bandwidth or communications costs between the different links. Costs can range from 1 to 999999.

For example, two sites in one city, called A and B, are connected by a high-speed link, and an overseas site, called C, is connected to site B by a low-speed link. In this case, you can define the cost between A and B as 1, and the cost between B and C as 2. For information on how to change routing-link costs, see Change the cost for a routing link.

A routing link may use Message Queuing servers with routing enabled, called site gates, to route messages between two sites. A routing link can have any number of site gates or no site gate, and each site gate can be in either or both of the sites connected by it. If a routing link is associated with a pair of site gates, one in each site, only those servers are used to transfer messages on the routing link on behalf of clients. It is recommended that all sites in your organization be interconnected using routing links.

After a routing link has been created, you can double-click on the link and change the link's description.

For information on how to change the Message Queuing servers used for a routing link, see Change site gates for a routing link.


Configuring firewalls for Message Queuing

The following sections describe configurations for messaging through firewalls.

HTTP messaging through firewalls

The use of HTTP as a transport enables MSMQ to leverage existing firewall support, without the need for Message Queuing-specific firewall configurations, and it is recommended that HTTP be used for messaging through firewalls. For more information on HTTP messaging, see HTTP/HTTPS messages.

Messaging through firewalls using the Message Queuing protocol

To send messages across firewalls using the native Message Queuing protocol, specific configuration settings are required to allow Message Queuing computers located on either side of the firewall to communicate with each other. Note that for best security practice, it is recommended that HTTP messaging be used as a solution for messaging through firewalls. These specific configuration settings include allowing Message Queuing computers located on an external network to be able to connect to Message Queuing computers on your internal network over the Internet. This is achieved by opening the following service ports on your firewall.

TCP | 1801
RPC | 135, 2101, 2103, 2105
UDP | 3527, 1801

Important

  • If Message Queuing computers located on an external network require access to Active Directory, it is strongly recommended that you set up a virtual private network (VPN) connection with the Point-to-Point Tunneling Protocol (PPTP). Otherwise, your network security could be compromised. For more information on VPN connections and PPTP, see the Point-to-Point Tunneling Protocol (PPTP), in the Windows Help file.

Notes

  • With direct format names, only the TCP port needs to be opened. This provides for two-way sending, but only local reading. If you need to read from remote queues, or if you need to query Active Directory for information regarding public queues or other Message Queuing objects, you must also open the RPC ports.
  • RPC ports 2103 and 2105 can be incremented by 11 if the initial choice of an RPC port is in use when the Message Queuing service starts. Message Queuing queries RPC port 135 to discover the 2xxx-series ports.
  • Before establishing a connection with another Message Queuing computer, Message Queuing sends a ping message on UDP port 3527 to verify that the other computer responds, and only then does it attempt to establish a connection. If you do not want to open this port on the firewall, you can disable this feature by setting registry key value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\msmq\parameters\UsePing to zero. This might incur some performance cost as ping verification is disabled. After setting the registry, restart the Message Queuing service for the changes to take effect.

    • Caution

    • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

The following firewall configurations allow you three different operating modes for remote Message Queuing computers located on external networks.

Sending messages only

For remote clients to be able to send messages, you must allow these clients access to TCP port 1801 on your firewall.

In this configuration, remote clients cannot access Active Directory nor will messages be routed by Message Queuing servers through your internal network. This means that remote clients must be able to directly connect to the destination computer on your internal network over this port. Remote clients can then send messages using a direct format name for the destination queue.

This does not apply to dependent clients.

Sending messages with Active Directory access

In addition to opening TCP port 1801, allowing access to RPC ports 135 and 2101 permits remote clients access to Active Directory. RPC port 135 is used for handshaking between a remote client and a Message Queuing server. Message Queuing servers also use RPC port 2101 for communicating with each other.

Assuming that multicast network packets are allowed to pass through your firewall, allowing access to UDP port 1801 also permits remote clients to send a broadcast message to automatically determine their site.

This does not apply to dependent clients.

Sending and receiving messages with Active Directory access

In addition to opening TCP port 1801 and RPC ports 135 and 2101, allowing access to RPC ports 2103 and 2105 also permits remote clients to access queues and retrieve messages on Message Queuing computers located on your internal network.

Access to RPC ports 2103 and 2105 also allows remote dependent clients to send and receive messages using their supporting server on your network.


Configuring Message Queuing with a proxy server

Most organizations connect to the Internet using a proxy server for dispatching outgoing messages and a perimeter network protected by firewalls for routing incoming messages. A proxy server acts as a liaison between the intranet and the Internet. It creates a protected channel for passing information between the private network and the Internet and provides caching. Message Queuing uses an HTTP proxy to connect to URL addresses for delivering HTTP messages. Message Queuing thus needs to know the name of the proxy server and the applicable port to which it must connect. At the same time, there may be a list of target names for which the proxy connection is bypassed; that is, URL addresses that do not need to be accessed through the proxy server. An attempt is made to establish a direct connection with such targets. A Message Queuing application can only send messages over HTTP through a proxy server. No other type of Message Queuing messages can be sent. All of the information regarding proxy servers is stored in registry keys, at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Internet Settings. After setting the registry, restart the Message Queuing service for the changes to take effect.

Caution

  • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.

You can use the Proxy Configuration utility to configure a proxy server. To configure a proxy server, type the following command at the command prompt:

proxycfg.exe -p ProxyServerName:PortNumber BypassedTargets

Note that wildcards can be used to define a list of bypassed targets.

The proxy server configuration is read whenever an outgoing queue is created to send messages to a new URL, so you do not need to stop and restart the Message Queuing service for new proxy settings to take affect. However, if you change the proxy server configuration using the Proxy Configuration utility and you want an active outgoing queue to use the new settings, you must pause and resume that outgoing queue.


Administering Message Queuing in Active Directory

This section provides information about Message Queuing objects found in Active Directory, and their location. For details, see the following links:

  • For information about each Message Queuing object in Active Directory, see Message Queuing objects.
  • For details of where each Message Queuing object is located in the Active Directory snap-ins, see Message Queuing object locations.


Message Queuing objects

This topic provides an overview of all Message Queuing objects in Active Directory. For more detailed information on Message Queuing objects, see the Active Directory topic in the Microsoft Platform Software Development Kit (SDK). To open the Active Directory Start Page in the Platform SDK section of the MSDN Library, in Contents, click Active Directory.

    Where?

    • MSDN Library
    • Platform SDK
    • Networking and Directory Services
    • Directory Services
    • Active Directory

MsmqServices object

An MsmqServices object is created when the first domain controller of your forest is configured. There can be only one MsmqServices object in a forest. The MsmqServices object is of the MSMQ-Enterprise class type. The MsmqServices object contains organization-wide configuration information for Message Queuing.

Routing link object

A routing link object with a user-defined name is created for each routing link that you create between two Message Queuing sites and contains connectivity information. Routing link objects are of the MSMQ-Routing-Link class type.

MSMQ Settings object

An MSMQ Settings object is created for each Message Queuing server that is installed on a Windows Server 2003 family domain controller and for each Message Queuing server with routing services. The MSMQ Settings object contains configuration information, such as what Message Queuing-specific services the server provides. The MSMQ Settings object is of the MSMQ-Settings class type.

Message Queuing object

An msmq object is created for each independent client and for each Message Queuing server, and it contains configuration information for the local computer. The msmq object is of the MSMQ-Configuration class type. The msmq object is the parent object of the queue objects under it. The msmq object is also known as the MSMQ Configuration object, for example, in names of specific permissions for this object and in the Delegation of Control Wizard.

Queue object

A queue object with a user-defined name is created for each queue and contains information associated with the particular queue. Queue objects are of the MSMQ-Queue class type. Each queue object contains a Queue messages folder and a Journal messages folder.

Distribution list object

Distribution lists are essentially distribution group objects in Active Directory. They can contain explicit references only to destinations published in Active Directory; that is, to public queues, queue aliases, and other distribution lists, but not to private and URL-named queues. Queue aliases are published in Active Directory and can point to any queue, including private and URL-named queues. Thus, queue aliases pointing to private and URL-named queues can be included in a distribution list.

Queue alias object

A queue alias object with a user-defined name is created for each queue alias and contains information associated with the particular queue alias, such as the string comprising the alias and the format name to which the alias points. Queue alias objects are of the MSMQ-Custom-Recipient class type. For more information on queue aliases, see Queue aliases.

Distribution group object

Distribution lists are essentially distribution group objects in Active Directory. They can contain explicit references only to destinations published in Active Directory; that is, to public queues, queue aliases, and other distribution lists, but not to private and URL-named queues. Queue aliases are published in Active Directory and can point to any queue, including private and URL-named queues. Thus, queue aliases pointing to private and URL-named queues can be included in a distribution list.

A distribution group object with a user-defined name is created for each distribution list published in Active Directory and contains information associated with the particular distribution list, such as the elements comprising the distribution list, which can be public queues, queue aliases, and other distribution lists. Distribution group objects are of the Group class type. For more information on distribution lists, see Distribution lists.


Message Queuing object locations

This table describes where Message Queuing objects are located in Active Directory.

Object name | Location
MsmqServices object The MsmqServices object is displayed in the console tree (usually the left pane) of the Active Directory Sites and Services snap-in in the following location:
  • Active Directory Sites and Services
  • Services
  • MsmqServices
Routing link object Routing link objects are located under the MsmqServices object in the details pane of the Active Directory Sites and Services snap-in:
  • Active Directory Sites and Services
  • Services
  • MsmqServices
  • Routing link object
MSMQ Settings object

The MSMQ Settings object is displayed in the details pane (usually the right pane) of the Active Directory Sites and Services snap-in when the applicable server object is selected. Server objects are found in the following location:

  • Active Directory Sites and Services
  • Sites
  • YourSiteObject
  • Servers
  • YourServerObject
msmq object

The msmq object and child container objects are displayed in the console tree of the Active Directory Users and Computers snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • YourOrganizationalUnitObject (such as Computers or Domain Controllers)
  • YourComputerObject
  • msmq
  • YourQueueFolder (such as Private Queues and System Queues)
  • YourQueueObject
  • Queue messages
    Journal messages
Queue object | Queue objects are located under the msmq object of the computer on which they reside (except for dependent clients, whose Queue objects are located under the msmq object of the supporting server).
Queue alias object Queue alias objects are displayed in the console tree of the Active Directory Users and Computers snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • YourContainer (such as Computers or Domain Controllers)
  • YourQueueAliasObject
Distribution group object Distribution group objects are displayed in the console tree of the Active Directory Users and Computers snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • Users
  • YourDistributionGroupObject


Administering Message Queuing Computers

This section provides conceptual information about common administration tasks for Message Queuing computers. Instructions for completing individual tasks can be found in the How To... section in this online Help file. For details about administering Message Queueing computers, see the following links:

  • To learn about administering server cluster nodes, see Administering server cluster nodes.
  • For information on assigning Message Queuing servers as in-routing and out-routing servers, see Assigning in-routing and out-routing servers.
  • For information on joining workgroup computers to a domain, see Joining a domain from a workgroup.
  • For information on configuring DNS settings so that Message Queuing can resolve computer names, see Configuring DNS settings for Message Queuing.


Administering server cluster nodes

You administer Message Queuing running in a server cluster node the same way as you would a standard Message Queuing server, using the same snap-ins.

In addition, you can also locally administer Message Queuing running in the context of a virtual server in a cluster by using the Computer Management snap-in. A virtual server is a cluster group that contains a Disk resource and a Network Name resource. A virtual server functions similarly to a server running on a physical computer, so a Message Queuing server running in the context of a virtual server provides services similar to the services provided by a Message Queuing server running on a physical computer.

To administer Message Queuing running in the context of a virtual server, the associated node on which the virtual server is running must be online and available. For information on how to create a Generic Application resource for managing a Message Queuing cluster resource from a local Computer Management snap-in, see Configure Message Queuing resources for server clusters.


Assigning in-routing and out-routing servers

Message Queuing servers, called in-routing servers or out-routing servers, can be used to route messages within a site. Each independent client (or Message Queuing server without routing enabled) can be configured to use up to three in-routing servers and out-routing servers to route messages on its behalf.

It is recommended that in-routing and out-routing servers be used for mobile clients that are mostly disconnected from the network or connect to the network through a remote access server.

The same Message Queuing server can serve as both an in-routing server and out-routing server. However, all such servers must be located in the original site of the client (the site the client was installed in). When a mobile client moves to another site, these in-routing and out-routing servers are not used for message routing until the client returns to its original site.

For redundancy, it is recommended that you configure clients to use more than one in-routing or out-routing server.

For information on how to specify or change the in-routing or out-routing servers that a client can use, see Change in-routing or out-routing servers.


Joining a domain from a workgroup

Message Queuing can be used in an environment that is not part of a Windows Server 2003 domain, such as a computer that is part of a Windows Server 2003 family operating system workgroup, or a Windows 2000 workgroup. If Message Queuing is run on a computer that is part of a workgroup, that computer can later join a domain. Conversely, a Message Queuing computer can be part of a domain, and then join a workgroup. Such a computer can then rejoin the same or a new domain at a later time. A Message Queuing computer running on Windows Server 2003 family operating systems can join any new Windows Server 2003 family or Windows 2000 domain. For a Message Queuing computer running on a Windows Server 2003 family computer to be able to join a new domain, a domain controller must be available in its site. It is also advisable that the domain controller be configured as a global catalog server. In addition, Message Queuing computers can join only Windows Server 2003 and Windows 2000 domains. For information on how to join a domain from a workgroup, see Join a domain from a workgroup.

In Windows Server 2003, directory service functionality is configured by the user. When a Message Queuing computer has been configured with directory service functionality, this functionality will be provided whenever that computer is promoted to a domain controller.

Caution

  • When you join a Message Queuing computer in workgroup mode to a domain, or move a Message Queuing computer to a different forest, all messages in outgoing transactional queues on the computer will be discarded, or placed in the dead-letter queue if negative source journaling is enabled.

Joining a Windows NT 4.0 domain

When a computer running Message Queuing in workgroup mode joins a Windows NT 4.0 domain, the installation subcomponent for Active Directory Integration is removed. After the computer has been joined to the domain and rebooted, open the Control Panel, double-click Add or Remove Programs, click Add/Remove Windows Components, and in the Windows Components Wizard, select Application Server, click Details, select Message Queuing, click Details, and select Active Directory integration.

For information on the operating restrictions of running Message Queuing in a nondomain environment, see Deploying in workgroup mode.


Configuring DNS settings for Message Queuing

If you are operating in an environment that requires the resolution of DNS domain names, such as an environment in which queries are sent to Active Directory, the DNS settings (for example, the DNS server addresses) must be configured properly on each computer for Message Queuing to resolve computer names correctly.

It is recommended that you verify that each computer is set with a fully qualified DNS name. Otherwise, some Message Queuing operations may fail. This property is typically set automatically by the Net Logon service on each computer in a Windows Server 2003 domain. To check this property, open Active Directory Users and Computers. In the console tree, right-click the applicable computer object, click Properties, and on the General page, inspect DNS Name.

For information on how to configure DNS properties for Message Queuing, see Set DNS properties for Message Queuing.


Administering Security

This section provides background information about security tasks for Message Queuing. Instructions for completing individual tasks can be found in the How To... section in this online Help file. For details about administering security, see the following links:

  • For background information about the Message Queuing service and the Local System account, see Managing the Message Queuing service account.
  • To learn about weakened security for Active Directory, and when to enable it, see Enabling weakened security.
  • For information on message authentication, see Managing message authentication.
  • To learn about authentication for Message Queuing using user certificates, see Managing user certificates.
  • For information on server authentication, see Managing server authentication.
  • For details of how HTTP/HTTPS messages are authenticated, see Authenticating HTTP/HTTPS messages.
  • For information on IIS security, see Resolving IIS Anonymous Access settings.


Managing the Message Queuing service account

Services run in their own security context. To establish a security context, a service needs to log on to the system. The Message Queuing service runs by default under the LocalSystem account, and you can change this default account if necessary.

The Message Queuing Downlevel Client Support service is installed on Message Queuing servers that provide Active Directory Integration to Windows 95, Windows 98, and Windows NT 4.0 computers running MSMQ 1.0, and Windows 2000 computers running MSMQ 2.0. This service must run under the default LocalSystem account.

The following are features of the LocalSystem account:

  • The LocalSystem account is a member of the local Administrators group.
  • The LocalSystem account already has the required rights to run as a service.
  • The LocalSystem account already has the Generate Security Audits privilege.

The default LocalSystem account is a member of the Authenticated Users group, and is granted the Read permission for all Message Queuing objects in Active Directory. This permission allows these users to read the attributes of Message Queuing objects in Active Directory, but does not control the rights of users to receive (and remove) messages from queues. Change the account that the Message Queuing service runs under only if you do not want to grant the Read permission to all members of the Authenticated Users group. In this case, to run the Message Queuing service under a specific user account, you need to do the following:

  • Grant the Read permission for all Message Queuing objects in Active Directory to the user account.
  • Add the user account to the local Administrators group.

If you must provide greater functionality you may consider granting the user account the following privileges:

  • Log on as a service
  • Act as part of the operating system
  • Replace a process level token
  • Increase quotas
  • Generate security audits

In addition, if you use a local user account to run Message Queuing applications on Windows 2000 independent clients, such clients cannot authenticate Message Queuing servers that run on domain controllers. Such domain controllers provide access to Active Directory. If authenticating those Message Queuing servers is a requirement, you must use a domain user account instead.

For information on how to change the account the Message Queuing service runs under, see Change the Message Queuing service account.

Triggers service security

By default, the Message Queuing Triggers service runs under the Network Service account. Services that are running under this account interact with the network using the credentials of the computer account, and this account has the same level of access to resources and objects as members of the Users group accounts. For heightened security, you can change the default Triggers service account to a more secure setting; for example, the Local Service account, which limits access to the local computer. You can also specify a less secure account for the Triggers service; for example, the LocalSystem account, allowing access to the entire domain. The account used must be able to access the queues with which triggers are associated. Specifically, the account must be granted the Log On As A Service permission as well as the Peek Message permission for all applicable queues. If the message processing type of a trigger is "retrieval" or "transactional retrieval," the user must be granted the Receive Message permission for that queue. If you change the security settings for a queue to enable a trigger to monitor it, you must stop and start Triggers to update the service's configuration before the trigger will start to work. Note that executable files invoked by triggers are invoked with the same security privileges as those assigned to the Triggers service.


Enabling weakened security

Message Queuing servers running on Windows Server 2003 domain controllers, or Windows 2000 domain controllers can operate using weakened security for Active Directory. If you install Message Queuing with the Message Queuing Downlevel Client Support component on a domain controller, a dialog will appear, asking you if you want to enable or disable weakened security. Enable weakened security if any of the following operating configurations apply to your organization:

  • A domain environment where users running MSMQ 1.0 (on Windows NT 4.0, Windows 98, or Windows 95) access the Message Queuing Downlevel Client Support service on Windows Server 2003 domain controllers, and Windows 2000 domain controllers for directory services. This applies even if such users are logged on with Windows Server 2003 or Windows 2000 domain accounts.
  • A Windows Server 2003 family domain, or Windows 2000 domain, where users running Message Queuing (on Windows Server 2003 family operating systems, XOX, or Windows 2000) are logged on with Windows NT 4.0 domain accounts.
  • An environment where Message Queuing 2.0 users are logged on with local user accounts. Note that:
    • 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 a Message Queuing server, will not be able to access Message Queuing objects in Active Directory when it logs on with a local user account, even if the security for Active Directory is weakened.

If weakened security is enabled, a Message Queuing server running on a Windows Server 2003 domain controller or a Windows 2000 domain controller will access Active Directory within its own security context. This access will be under the LocalSystem account on the applicable domain controller. You can view the properties of Active Directory objects, including msmq (MSMQ configuration) objects and queue objects. You can also check security settings for operating systems requiring the Downlevel Client Support service or XOX clients. You cannot bypass any security restrictions on creating objects or setting object security.

For users running MSMQ 1.0, when the MSMQ service starts an RPC call to a Message Queuing server running on a Windows Server 2003 domain controller, the call is impersonated as an anonymous logon in the default security context. To allow such an anonymous user access to Active Directory, domain security is weakened by not impersonating this call. Consequently, all queries for Message Queuing objects in Active Directory are accepted by Windows Server 2003 Message Queuing servers. This means only that the properties of Message Queuing objects can be viewed. It does not mean that messages can be retrieved (removed) from public queues.

You can also check how Message Queuing is configured and modify this setting after installation using ADSI Edit. For information on how to do this, see Weaken security using ADSI Edit.

It is also possible to support MSMQ 1.0 users (and other configurations discussed) without weakening security. In this case, you must grant the Everyone group the List Content permission on all computer objects in each domain. This, however, greatly compromises the domain security.


Managing message authentication

Message authentication, which confirms that a message has not been tampered with and can be used to verify the identity of the sender of a message to the receiver, is implemented using certificates. Messages are authenticated asynchronously without the sender and the receiver communicating with one another.

The use of message authentication is optional. Message Queuing applications are not required to use authentication when sending or receiving messages. It should be noted that the use of message authentication slows the transfer of messages. When used, Message Queuing applications that send or receive authenticated messages must use the cryptographic service provider installed by default with Windows Server 2003 family operating systems, and which is needed for both message authentication and encryption. For more information on message encryption, see Encryption for Message Queuing.

For more information on authentication for Windows Server 2003 family, see Authentication, in Windows help.

For more information on certificates for Windows Server 2003 family, see Certificates overview in Windows help.

In addition to confirming that no tampering has been done to a message, message authentication can be used to verify the identity of the user who sent the message. Authentication is done at the request of the sending application, which indicates that a message is to be authenticated by setting its authentication level.

An authenticated message is sent with a digital signature and a certificate. Digital signatures are created and validated using public-key (asymmetric) encryption. In Message Queuing, the sender uses the private key to create a digital signature, and the receiver uses the public key in the certificate attached to the message to validate the digital signature.

Because Message Queuing is an asynchronous messaging system, the source computer and the destination computer are not assumed to be online and connected at the same time.

The sender of a message cannot always be authenticated. For example, before you can authenticate the sender of a message sent between computers in the same forest with access to Active Directory, a user certificate must be registered in Active Directory. Registering a certificate in Active Directory associates the certificate with the owner's security ID (SID). You can also use the internal user certificate created on the local computer during setup, which is automatically registered the first time you log on to the computer.

Then, when an authenticated message is sent, a Message Queuing application on the source computer creates a digital signature for the message, attaches the digital signature, the SID, and the applicable certificate to the message, and sends the message. The Message Queuing service on the destination computer validates the digital signature and then queries the applicable directory service to see whether the SID/certificate pair is registered. If the SID/certificate pair is registered, the message is considered authenticated and is placed in the destination queue.

When the sending application indicates that a message is to be authenticated by setting its authentication level, the Message Queuing runtime code does the following:

  1. Retrieves the applicable certificate. By default the internal certificate is retrieved. However an external certificate is used if one is provided on the sender certificate property. For more information, see Managing user certificates.
  2. Obtains the private signing key for the certificate used. For Windows Server 2003 family computers, certificates are stored in certificate stores. Certificates can also be found in a public certificate store, but Message Queuing will not accept these. In the case of external certificates, Message Queuing searches for the private key in the personal certificate store (the external certificate must be registered there). For internal certificates, Message Queuing locates the private key internally.
  3. Computes a hash value from a fixed limited portion of the message using a hash algorithm. The default hash algorithm is the Secure Hash Algorithm (SHA).
  4. Encrypts the hash value using private key obtained in step 2 to create a digital signature.
  5. Attaches the digital signature, the security ID (SID), the name of the hash algorithm, and a digital certificate containing the public cryptographic key for the source computer to the message.

On the destination computer, the Message Queuing service does the following:

  1. Computes a hash value from a fixed limited portion of the message using the same hash algorithm as the source computer.
  2. Decrypts the digital signature attached to the message using the public cryptographic key from the digital certificate to obtain a second hash value.
  3. Compares the two hash values to confirm that the message was not tampered with during delivery.
  4. If the values match, locates the user certificate in Active Directory and verifies that the user who registered the certificate matches the sender (the SID) listed on the message. If the hash values do not match, the message is discarded, and a negative acknowledgment is returned to the sending application, if such an acknowledgment was requested.

In this case, the digital signature uniquely identifies the user who sent the message as well as the message itself. Because no user can digitally sign a message with another user's identity, no user can deny having sent a message if it contains a validated digital signature that can be identified with a specific sender.

You can also send authenticated messages to connector applications. The intermediary Message Queuing server (running the connector application) can validate authenticated messages.

You can specify whether or not a queue accepts only authenticated messages. For more information, see Allow only authenticated messages on queues.

Authentication in workgroup mode

When authenticating messages when the receiving computer is in workgroup mode, you cannot work with user certificates registered in Active Directory to map the certificate to the respective user security ID (SID). Instead, do the following:

On the sender computer:

  • The user gets an external certificate from a CA that is trusted by both the sender and the receiver, particularly the receiver.
  • Set Message Queuing to use this certificate when sending the message (use MQGetSecurityContextEx).
  • Message Queuing finds the private key and attaches the signature, but does not add the SID (use MQMSG_SENDERID_TYPE_NONE).

On the receiver computer, the procedure is the same as that described above for an Active Directory computer, except that:

  • The Message Queuing service does not attempt to locate the certificate in Active Directory.
  • The user must verify the certificate by verifying the certificate chain (use CertGetCertificateChain and CertVerifyCertificateChainPolicy).
For more information on internal certificates, see Managing user certificates.

For more information on cryptographic keys used by Message Queuing, see Cryptographic keys.


Managing user certificates

There are two types of user certificates, or public-key certificates, that Message Queuing can use: internal certificates and external certificates. An internal certificate is automatically created during Message Queuing Setup for the user installing Message Queuing. External user certificates contain information that is supplied by a certification authority (CA). Unless stated otherwise, the information in this section applies to both types of user certificates.

You manage user certificates for a Message Queuing computer using the Message Queuing Properties dialog box in Computer Management. For information on how to view all user certificates that are registered in Active Directory, see View certificates for Message Queuing. All certificates have a validity period. After the end of the validity period, the certificate is no longer considered an acceptable or usable credential. Also, if Message Queuing is installed on a computer operating in a workgroup, and then the computer joins a domain, you must manually renew the internal certificate. For information on how to renew internal user certificates, see Renew certificates for Message Queuing.

User certificates can be stored in Active Directory. If you reinstall Windows Server 2003 family on a computer (rather than upgrade an existing installation), you must delete the user's previous (now obsolete) certificate. For information on how to delete a user certificate, see Remove certificates for Message Queuing. Next, you must register the new certificate manually. For information on how to register a user certificate, see Register certificates for Message Queuing.

Notes

  • If permissions are used to control access to queues, user certificates must be registered in Active Directory so that Message Queuing can map the certificate to the respective SID of the user. Although it is possible to send unauthenticated messages to queues that restrict access, doing so could compromise security as the content of such messages could be tampered with or read while en route.
  • In the case of a cluster, a user profile, which is needed to store a user certificate in the registry, will not be created for a user account that is used only for a cluster service until it logs onto a node of the cluster at least once. After a user profile is created, the user must manually register a user certificate for Message Queuing.
  • 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, and obsolete certificates can be deleted. For instructions, see Remove certificates for Message Queuing.

External certificates

External user certificates contain information that is supplied by a certification authority (CA), rather than the SID, for verifying a sender's identity. The information in an external certificate is guaranteed by the CA that created the certificate. The Message Queuing service on the destination computer still validates the digital signature when a message is received but does not validate the external certificate itself. It is the responsibility of the receiving application to validate an external certificate before acting on the message. For more information on certification authorities, see Certification authorities.

An external certificate can be registered in Active Directory and then used to authenticate the sender's SID when authenticated messages are sent to other computers in the same forest, precisely as in the case of an internal certificate, but with a possibly higher level of security.

If you register an external certificate in Active Directory and thereby associate an SID with the certificate, you can send messages to queues that restrict access. This is because the Message Queuing service verifies the sender's SID. Registering an external certificate thus provides an additional, although optional, measure of authentication, which can be used by the receiving application.

External certificates are required for sending authenticated messages to environments other than Windows Server 2003 family or Windows 2000. Other reasons you may want to use an external certificate include the following:

  • You want to control who can send authenticated messages by controlling the use of certificates. Internal certificates are created automatically during the installation of Message Queuing and can be used by everyone.
  • You want to send messages to someone who does not have access to Active Directory.
  • You belong to a workgroup, as opposed to a domain.

In cases where SIDs cannot be used to authenticate the sender, as in the case of a message sent between computers operating in workgroup mode, an external certificate can be used for message authentication. In such cases, when an authenticated message is sent, the Message Queuing service on the source computer creates a digital signature for the message, attaches the digital signature and the applicable external certificate to the message, and sends the message. The Message Queuing service on the destination computer validates the digital signature.

More specifically, on the source computer, the Message Queuing service does the following:

  1. Computes a hash value from a fixed limited portion of the message using a hash algorithm.
  2. Encrypts the hash value using the sender's private cryptographic key to create a digital signature.
  3. Attaches the digital signature, the name of the hash algorithm, and a digital certificate containing the sender's public cryptographic key to the message.

On the destination computer, the Message Queuing service does the following:

  1. Computes a hash value from a fixed limited portion of the message using the same hash algorithm as the source computer.
  2. Decrypts the digital signature attached to the message using the public cryptographic key from the digital certificate to obtain a second hash value.
  3. Compares the two hash values to confirm that the message was not tampered with during delivery.
  4. If the values match, validates the external certificate (this step is optional).

One way to obtain an external certificate is to use Internet Explorer 5.0 or later to request a certificate from a certification authority. For example, you can contact one of the following representative CA vendors:

  • AT&T
  • InternetMCI Mail
  • Keywitness Canada
  • VeriSign Commercial Software Publishers

In general, you can obtain different levels of external certificates. Some external certificates do not prove your identity. They prove only that you are the same person each time you send a message. This is sufficient for subscription-based applications. Other levels of external certificates prove that you are who you claim to be.


Managing server authentication

Server authentication is used by clients to authenticate queries sent to domain controllers and Message Queuing servers. A client can verify that the query results have not been tampered with and that the results were returned by the correct domain controller or Message Queuing server. The method used for server authentication depends on the version of Message Queuing (and hence the operating system) running on the server and the client. The following table shows the method used for each situation.

Client | Server | Server authentication method
Message Queuing client running on Windows Server 2003 family | Windows Server 2003 or Windows 2000 domain controller | Kerberos V5
Message Queuing client running on Windows 2000 | Message Queuing server running on Windows Server 2003 family or Windows 2000 | Kerberos V5
Message Queuing client on Windows 2000 | MSMQ 1.0 controller server running on Windows NT 4.0 | Server certificate
MSMQ 1.0 client running on Windows NT 4.0, Windows 98, or Windows 95 | Message Queuing server running on Windows Server 2003 family or Windows 2000 | Server certificate

Using server certificates

Server certificates are used to authenticate some Message Queuing servers. You need to create and register a server certificate for the following:

  • Message Queuing servers that reply to Active Directory queries from MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95.
  • MSMQ 1.0 controller servers running on Windows NT 4.0 that reply to queries from Message Queuing clients on Windows 2000 computers.

Note that Message Queuing clients running on Windows Server 2003 family or Windows 2000 use Kerberos V5 to authenticate Windows Server 2003 family or Windows 2000 Servers, and do not require server certificates.

For information on how to create a server certificate, see Create server certificates for Message Queuing. For information on how to change an existing server certificate, see Change server certificates for Message Queuing.

Server certificates used to authenticate Message Queuing servers must be installed separately from any user (client) certificates that may be installed for message authentication. However, if properly configured, the same certificate can be used by Message Queuing to authenticate servers and by Internet Information Services (IIS) for secure Web (HTTPS) communication.


Authenticating HTTP/HTTPS messages

When messages sent over HTTP/HTTPS transport are authenticated, the sender attaches an XML digital signature and a user certificate, which contains the user's name, the user's public key, and the signature of the issuer. A user can obtain an external user certificate from a certification authority (CA), such as VeriSign or Microsoft Certificate Services, or use the internal user certificate that is created on the local computer during setup and is automatically registered the first time the user logs on to the computer. If an external user certificate is used, the user must register that certificate in Active Directory in the local forest using the Message Queuing UI. In contrast to messages sent over ordinary transport, here the sender's SID is not used for authentication, and the recipient must rely on other means, for example, external certificates from a trusted CA, to validate the digital signature. This applies both to messages sent within the same forest and to messages sent between different forests.

When messages are sent over HTTPS transport, additional security requirements must be satisfied before an SSL session is established between the sender and the recipient. For For more information, see HTTPS authentication.

When a message requiring authentication is sent within the same forest, the recipient decrypts the digital signature, and tries to locate the user certificate in Active Directory according to its GUID. If the user certificate is not found in Active Directory, Message Queuing tests the certificate to ascertain whether it is self-signed (an internal user certificate). If it is found in Active Directory and self-signed, the message is inserted into the queue, but not marked as authenticated. However, if the user certificate is not found in Active Directory and it is not self-signed, the sender is regarded as an anonymous user and is allowed to access the destination queue accordingly.

When messages are sent over HTTP/HTTPS transport between different forests, the recipient cannot search for the certificate in Active Directory in the sender's forest. To overcome this problem and use the same user certificate to authenticate messages sent between different forests, perform the following steps:

  1. Export the sender's user certificate to a file.
  2. Send the file to the recipient's forest.
  3. In the recipient's forest, create a pseudo-user to represent the sender or the sender's group.
  4. Import the certificate to the pseudo-user's personal certificate store.
  5. Log on as the pseudo-user.
  6. Use the Message Queuing UI to register the certificate in Active Directory to the pseudo-user.
  7. Grant the pseudo-user permissions to write to Message Queuing queues.

The recipient can now authenticate messages sent between forests by querying Active Directory in the local forest as in the case of messages sent over HTTP/HTTPS transport within a single forest.

For information on how to register a user certificate, see Register certificates for Message Queuing.


Resolving IIS Anonymous Access settings

By default, Internet Information Services (IIS) impersonates a special IIS local user account. Since this account is local to the IIS computer (unless it is a domain controller), it cannot be authenticated by other computers in the network and is treated as an anonymous user.

Active Server Page (ASP) applications and scripts run under IIS, and by default impersonate the IIS local user for any Message Queuing operations, including queries to Active Directory. Since anonymous users no longer belong to the Everyone group in Windows Server 2003 family, these queries fail, and ASP applications and scripts cannot locate, create, and delete queues. In addition, an anonymous user cannot open a queue for remote read, and you cannot read messages from queues that do not belong to the IIS computer using ASP.

You can resolve this issue in either of the following ways:

  • Using a domain user account instead of the IIS local user account for Anonymous Access. The account must have the required permissions for the Message Queuing operation, for example access to Active Directory.
  • Disable Anonymous Access. Trust the IIS computer for delegation to allow multiple hops in communicating with a domain controller. Note that this option will not resolve remote read limitations.

For instruction, see Change the security settings for Internet Information Services.


Administering Queues

This section provides information about managing and configuring queues for Message Queuing. You can use the Computer Management snap-in or the Active Directory Users and Computers snap-in to administer queues. For more information, see Administration overview. Instructions for completing individual tasks can be found in the How To... section in this online Help file. For details about administering queues, see:

  • Managing queues
  • Managing queue properties
  • Setting queue quotas
  • Enabling target journaling


Managing queues

The Computer Management snap-in or the Active Directory Users and Computers snap-in is used to manage and administer queues. For more information, see Administration overview.

Creating queues

There may be certain restrictions on creating queues on computers that are determined during Message Queuing Setup. For more information, see Access Control for Message Queuing.

For information on how to create, delete, or find a queue, see Create queues, Delete queues, and Find queues.

Viewing queues

The operation of viewing the contents of a queue from the same computer on which the queue is located is called local reading. The operation of accessing the contents of a queue from a computer other than the one on which the queue is located is called remote reading.

You can view the contents of only those queues that you have sufficient permissions to open. Therefore, there can be public queues whose contents are not visible in the snap-ins. For more information, see Access control for Message Queuing.

By default, any user with the Get Properties permission for the msmq object can view the queue status of local outgoing queues. To limit this default, you can do either of the following:

  • Change users' Get Properties permissions for the msmq object.
  • In the registry, add the dword RestrictAdminAPI with a registry value of 1, under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Msmq\Parameters. This restricts the ability to view the queue status of active outgoing queues to local administrators, regardless of security permissions for the msmq object.

    • Caution

    • Incorrectly editing the registry may severely damage your system. It is recommended that you back up any valuable data on the computer before making changes to the registry.
  • After setting the registry, restart the Message Queuing service for the changes to take effect.

Viewing internal private queues and outgoing queues

There are certain internal private queues that are used exclusively for internal operation, and the Active Directory Users and Computers and Computer Management snap-ins do not display any internal private queues. For more information, see Internal private queues and outgoing queues.

Outgoing queues on a computer are used to store messages temporarily before the messages are sent to their destinations. Outgoing queues are visible only when using the Computer Management snap-in. However, transactional messages in outgoing queues cannot be viewed from Computer Management.

Pausing and resuming queues

You can pause and then later resume the operation of a local outgoing queue, thereby deferring the sending of messages from that queue to the corresponding destination queue. This way, you can send all pending messages to a destination queue at a later time. For information on how to pause or resume an outgoing queue, see Pause or resume an outgoing queue.

You can also take Message Queuing offline from the network. When you take Message Queuing offline from the network, you pause the operation of all outgoing queues on the local computer. This is useful when you communicate over a slow, expensive connection and want to defer sending messages in all outgoing queues on the computer to a later time. For information on how to take Message Queuing offline from the network for a computer, see Take outgoing queues offline.

Managing queues with triggers

When you delete a queue, the triggers associated with that queue are not deleted. If you later re-create a queue of the same name, any existing triggers will be used by this queue. However, this re-created queue will not be monitored by the Message Queuing Triggers service until the computer is restarted, or the associated triggers disabled and then enabled again. For instructions on setting the enabled or disabled property for a trigger, see View or change properties of triggers and rules for triggers.


Managing queue properties

The Computer Management snap-in or the Active Directory Users and Computers snap-in is used to administer queues. For more information, see Administration overview.

Messages are sent to public queues based on the sum of each message's priority value and the destination queue's priority, or base priority, value. Messages with the highest numerical total are sent first. Messages are sent first by base priority, and then by message priority. Private queues do not support base priority, so messages are sent only according to message priority.

For information on how to change the base priority for a queue, see Change the base priority of queues.

The queue type ID specifies the type of service provided by the queue. The queue type ID must be a valid GUID in the form {dddddddd-dddd-dddd-dddd-dddddddddddd}, where d is a hexadecimal text digit. It can be used to search for queues of a specific type. After you have located queues by type ID, you can use the name retrieved to open or delete the queue. The use of the queue type ID is optional.

For information on how to change the queue type ID, see Change queue type IDs.

Each queue can have a label, which is a string with a maximum length of 124 Unicode characters that can be used to identify the queue. For example, queues that accept messages sent by a specific application may all have the label "Messages from my application." For information on how to change the queue label, see Change queue labels.

You can specify whether a queue accepts encrypted messages, unencrypted messages, or both by selecting the privacy level for the queue. If the queue privacy level is set to None, the queue accepts only unencrypted messages. If the queue privacy level is set to Body, the queue accepts only encrypted messages. If the queue privacy level is set to Optional, the queue accepts both unencrypted and encrypted messages. You can check whether a message sent to the queue was encrypted or unencrypted by using Active Directory Users and Computers (or programmatically by checking the PROPID_M_PRIV_LEVEL message property).

For information on how to set the privacy level for a queue, see Change the privacy level for queues.

You can also specify whether a queue accepts only authenticated messages. For more information on how to set this option, see Allow only authenticated messages on queues. For general information on message encryption, see Encryption for Message Queuing.


Setting queue quotas

The Computer Management snap-in or the Active Directory Users and Computers snap-in is used to administer queues. For more information, see Administration overview.

Queue quotas specify the cumulative limit for messages stored in a particular queue. When the message quota for a destination queue is reached, new incoming messages are discarded, and a negative acknowledgment message indicating that the destination queue is full is generated. Messages can be placed in the queue only after one or more messages are removed (read) from the queue.

Queue quotas can be set only for Message Queuing servers and independent clients. Queue quotas set on Message Queuing servers that support dependent clients apply both to the server and to all its dependent clients.

For background information on quotas, see Quotas for messages.

For information on how to set a queue quota for normal messages, see Set the message storage size for queues.

For information on how to set a queue quota for journal messages, see Set the journal storage size for queues.


Enabling target journaling

Target journaling is configured on a queue basis. If it is enabled, a copy of each incoming message is placed in the applicable queue journal when a message is removed (read) from the destination queue.

For information on how to enable target journaling for a queue, see Enable or disable target journaling.


Administering Distribution Lists

A distribution list is a set of one or more distribution lists, or target queues, which can be used to do the following:

  • Send transactional and nontransactional messages to multiple destinations.
  • Specify one or more administration queues for sending application-generated acknowledgment messages, when acknowledgment messages are requested.
  • Specify one or more response queues for sending application-generated response messages, when response messages are requested.

For details about administering distribution lists, see the following links:

  • To learn about creating distribution lists, and setting properties and security permissions, see Creating and managing distribution lists.
  • To learn about managing queues, queue aliases, and other distribution list members of a distribution list, see, Managing distribution list elements.


Creating and managing distribution lists

Distribution lists are public lists that are published as distribution group objects in Active Directory. You can use Active Directory Users and Computers to create and delete distribution lists as distribution group objects, and to view their properties. For more information on performing these tasks, see Create distribution lists, Delete distribution lists, and View, add, or delete elements in a distribution list. For more conceptual information on distribution lists, see Distribution lists.

When you create a distribution list (group) in Active Directory, you are prompted to specify the minimal information needed to establish the object in Active Directory. Each distribution list (group) has many more properties (attributes) that can be viewed and set, as follows.

Property | Details
Group name | Name of distribution list object
Description | Description of distribution list object
Group scope | Distribution lists can be domain-scoped, global, or universal
Group type | The type of group for this object is distribution
Distribution list (group) elements (members) | Elements that make up the distribution group
Folders containing the members in Active Directory | Location of group elements
Distribution lists (groups) of which the applicable distribution list (group) is a member | If the distribution list is in turn the member of another distribution list
Administrative permissions | Security for the distribution list

Setting distribution list scope

Distribution lists can be specified as "Global", "Domain-scope" or "Universal":

  • Domain-scope distribution lists can only contain queues and distribution lists from the local domain as members, and cannot be moved to another domain.
  • Distribution lists with global scope can include queues and distribution lists from the local domain, and queues and global distribution lists from other domains in the forest. They can be moved to another domain.
  • Distribution lists with universal scope can include other groups and accounts from any domain in the domain tree or forest and can be granted permissions in any domain in the domain tree or forest.

Setting distribution list security

Because distribution lists are objects in Active Directory, security attributes can be attached to control access to them. A security descriptor is assigned to each queue and distribution list. This security descriptor lists the users and groups that are granted or denied access to the queue or distribution list, and the following specific permissions are associated with distribution lists:

  • Send To permission allows a group or user to send messages to the applicable distribution list. By default, this permission is granted to everyone.
  • Add/Remove Self as Member permission for a public queue or queue alias allows a group or user to add or remove the applicable public queue or queue alias as a member in a distribution list. All users are granted this permission by default.
  • Add/Remove Self as Member permission for a distribution list allows a group or user to add or remove the applicable distribution list as a member in another distribution list. Only the owner of a distribution list has the Add/Remove Self as Member permission for it.

For more information on distribution list security, see Distribution lists.

Distribution lists can be referenced programmatically through distribution list format names. For more information on using distribution list format names and their syntax, refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.


Managing distribution list elements

Distribution lists are public lists that are published as distribution group objects in Active Directory. You can use Active Directory Users and Computers to add and delete members of a distribution list. For more information, see View, add, or delete elements in a distribution list. For more conceptual information on distribution lists, see Distribution lists.

The explicit members of a distribution list must be destinations published in Active Directory, including:

  • Public queues. For more information on public queues, see Public and private queues.
  • Queue aliases. For more information on queue aliases, see Queue aliases.
  • Other distribution lists.

You cannot explicitly use private queues or URL-named queues as members of your distribution lists, but they can be included in a distribution list, and referenced indirectly by using queue aliases. For instructions, see Create queue aliases.

You can also identify all distribution lists for a given element, and remove a distribution list, queue, or queue alias from one or more distribution lists if required. For instructions, see Get a list of distribution lists containing a given element.


Administering Messages

This section provides information about configuring and managing messages. Instructions for completing individual tasks can be found in the How To... section in this online Help file. For details about administering messages, see the following links:

  • For information on message lookup and purging messages, see Managing messages.
  • For information on sending test messages and tracking message routes, see Tracking messages and routes.
  • To learn more about backing up messages, see Backing up and restoring messages.
  • To learn about setting queue quotas and computer quotas for messages, see Setting message quotas.
  • For information about storing messages on multiple disks, see Storing message files on multiple disks.
  • To learn about sending transactional messages to multiple destinations, see Sending transactional messages to multiple destinations.


Managing messages

A message body can contain text or binary information. If a message body contains text information, this information is displayed. If a message body contains binary information, hexadecimal data is displayed along with its text translation. Message bodies can be viewed on the Body dialog box for the message.

To retrieve messages from a queue, you must first be granted the Receive Messages permission for the queue. It is not sufficient to have the Read permission granted for the queue. For information on how to set permissions for queues, see Access control for Message Queuing.

Message lookup

Applications can be written to peek at or retrieve a specific message without navigating through the queue to find the message. This functionality is based on a 64-bit lookup identifier that is assigned to each message when it is placed in a destination queue. The lookup identifier of a message is unique within the queue and is always greater than the lookup identifier of the preceding message and less than the lookup identifier of the next message. Note that this functionality is designed to help you look at specific messages you have received. It is not a random search mechanism.

Both messages sent by applications and messages sent by Message Queuing have a lookup identifier. The local queue manager generates the lookup identifier and sets the lookup identifier properties of the message (PROPID_M_LOOKUPID and MSMQMessage.LookupId) whenever it places a message in a queue. Message Queuing generates a lookup identifier for messages placed in user- and application-generated queues, such as destination queues, administration queues, response queues, and report queues, as well as for copies of messages placed in system-generated journals, dead-letter queues, and connector queues. If a message is sent to several destination queues, or if a copy of a message is stored in a computer journal or queue journal, each copy of the message will be assigned its own lookup identifier when it is placed in its respective queue.

Message Queuing has an API function and methods of the MSMQQueue object that enable applications to perform the following tasks programmatically without using cursors:

  • Peeking at the first message in the queue.
  • Peeking at the message preceding the message specified by the message lookup identifier supplied.
  • Peeking at the message specified by the message lookup identifier supplied.
  • Peeking at the message immediately following the message specified by the message lookup identifier supplied.
  • Peeking at the last message in the queue.
  • Retrieving the first message in the queue.
  • Retrieving the message preceding the message specified by the message lookup identifier supplied.
  • Retrieving the message specified by the message lookup identifier supplied.
  • Retrieving the message immediately following the message specified by the message lookup identifier supplied.
  • Retrieving the last message in the queue.

When API function calls are made to peek at or retrieve messages, messages can be processed asynchronously, synchronously, or within a transaction. However, the method calls process the messages synchronously.

A receiving application can use the lookup identifier of a message to go directly to that message and then continue navigating the queue from that point toward the front or the end of the queue. Lookup identifiers differ from cursors in this respect. When cursors are used, the application must start at the front of the queue and navigate towards the end of the queue.

Purging messages

You can purge all messages in any queue, including outgoing queues. The only exception to this is system queues. Note that you cannot purge individual messages in a queue. For instructions on purging all messages in a queue, see Purge all messages in a queue.


Tracking messages and routes

You can track the passage of messages from a source computer to a target queue by sending test messages. You can also track the route taken in your network by test messages or all messages sent from the source computer to test queues on remote computers by enabling the message route tracking feature. Neither of these features is enabled by default following Message Queuing installation. For instructions on enabling these features, see Enable route tracking and test messages.

Sending a test message

You can send a test message from an independent client or a Message Queuing server to a test queue on any other independent client or Message Queuing server within the same Windows forest. To do so, after you have enabled test messages, you must first create a test queue, or change the type ID of an existing queue, so that you can send test messages to the test queue on the destination computer. For more information, see Sending test messages.

Report messages, which track the routes of messages through your network, are always sent to the report queue specified by the source computer for test messages if message tracking is enabled on the source computer.

For information on how to send a test message, see Send test messages.

Message route tracking

You can use the message route tracking feature to track the route that messages take through your network. When all the conditions for route tracking are satisfied, a report message is sent to the report queue for the source computer when the message leaves its source computer, when it arrives at its destination computer, and whenever the message arrives at or leaves a Message Queuing server with routing enabled.

After message route tracking is enabled, there are two basic requirements for its use. First, you must enable message route tracking and create or specify a report queue for the source computer. Second, the route tracking flag (property) in the message must be set programmatically by the sending application. In addition, only messages sent to a remote computer are tracked, and messages sent over HTTP/HTTPS transport as well as messages sent to multiple destinations using IP multicast, distribution lists, or multiple-element format names cannot be tracked in the current version of Message Queuing.

For information on message route tracking, see Track message routing. For information on setting properties programmatically, refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.

Only one queue can be specified in the header of a message as the report queue for that message. If a route-tracked message with a report queue specified in its header subsequently passes through a Message Queuing server with routing enabled that also has message route tracking enabled, Message Queuing sends a conflict report message to the report queue for that server when the message leaves it.

For example, consider three computers, called A, B, and C, where message route tracking is enabled for computer A. In this example, the Message Queuing application on computer A sends a message to computer C through out-routing server B. If the report queue for computer A is called QA, a report message is sent to QA when the following events occur:

  • The message leaves computer A.
  • The message arrives at out-routing server B.
  • The message leaves out-routing server B.
  • The message arrives at computer C.

If out-routing server B is also configured with message route tracking enabled, with report messages being sent to QB, this queue receives a conflict report message when the message leaves out-routing server B. The original source queue QA, however, continues to receive the regular tracking messages.

In a second example, computer A does not have message route tracking enabled, but route tracking is enabled on computers B and C. In this case, the message starts reporting its movements when it leaves out-routing server B. A total of two report messages are sent to QB (when the message leaves computer B and when the message arrives at computer C), but no conflict report messages are sent.

In a third example, neither computer A nor computer B has message route tracking enabled, but route tracking is enabled on computer C. In this case, no report messages are sent before the message reaches the destination computer, but one report message is sent to QC when the message arrives at its destination. No conflict report messages are sent.

Report messages consist of a label and a body. The label has the following format:

gggg:dddd:hh sent from <computer> to <address> at <time>
gggg:dddd:hh received by <computer> to <address> at <time>

where gggg is the first four hexadecimal digits of the globally unique identifier (GUID) of the source queue, dddd is the internal message identifier, and hh is the hop count.

The internal message identifier is the message sequence number, which is part of the entire message identifier. The message identifier is not used in its entirety because it is too big to be easily read. It is a 16-byte source GUID and a 4-byte sequence number.

When conflict report messages are sent, the labels contain the string "Report Message Conflict."

The body of a regular report message contains the ID of the message, the target queue, the destination of the next hop (if any), and the hop count in an XML format. For example, the body of the report message sent to QA when the message leaves the out-routing server in the first example will have the following form:

<MESSAGE ID>message_ID</MESSAGE ID>
<TARGET QUEUE>format_name_of_target_queue_on_computer_C</TARGET QUEUE>
<NEXT HOP>IP_address_of_computer_C</NEXT HOP>
<HOP COUNT>1</HOP COUNT>

The body of a conflict report message contains has an additional line containing the original source queue. For example, the body of the "Report Message Conflict" message sent to QB when the report message just described is sent to QA in the first example will have the following form:

<ORIGINAL QUEUE>format_name_of_QA</ORIGINAL QUEUE>
<MESSAGE ID>message_ID</MESSAGE ID>
<TARGET QUEUE>format_name_of_target_queue_on_computer_C</TARGET QUEUE>
<NEXT HOP>IP_address_of_computer_C</NEXT HOP>


Backing up and restoring messages

You can use the message backup and restore command-line utility, Mqbkup, provided with Message Queuing to protect message storage files, log files, transaction log files, and registry settings against computer failure. You must first create a folder to use for backup before using the utility. You run the utility from a command prompt by typing mqbkup.

The syntax of the utility is:

mqbkup {-b folderpath | -r folderpath | -?}

where:

-b folderpath backs up the files to the specified folder,

-r folderpath restores the files from the specified folder,

-? displays help for the utility.

Before restoring messages, you must close Control Panel and all Message Queuing applications.

Certificate and cryptographic key information is not backed up using this utility.

After a restore operation, you must register a new user certificate. For information on how to register a certificate, see Register certificates for Message Queuing.

This utility stops and restarts the Message Queuing service.


Setting message quotas

Message storage limits can be set by configuring the following:

Set computer quota

This quota specifies the cumulative limit for all messages stored in destination queues, outgoing queues, and queue journals on a computer. After a computer quota is reached, no messages can be delivered to any queue or journal on the computer. The computer quotas can be set for Message Queuing servers and independent clients. Following a new installation of Message Queuing, or an upgrade from Windows 2000, the default limit for these storage sizes is 8 gigabytes (GB). For more information, see Message storage. Computer quotas are set separately to limit message storage size and journal size. When you set the journal storage size limit for a computer, you automatically set equal quotas for the computer journal (the Journal messages queue), the dead-letter queue, and the transactional dead-letter queue. For instructions on setting the message storage limit for a computer, see Set the message storage size for computers. For instructions on setting the journal storage size for computers, see Set the journal storage size for computers.

Set queue quota

This quota specifies the cumulative storage size (number of bytes) available for all messages stored in a particular queue, whereas a computer quota limits the total storage available for all messages in destination queues, outgoing queues, and queue journals on the computer. When a queue quota is reached, messages can no longer be sent to the queue until one or more messages are retrieved (removed from the queue by a Message Queuing application). Queue quotas can be set for all queues. Queue quotas for journal queues and other queues are set separately. For instructions on setting the quotas for regular messages, see Set the message storage size for queues. For instructions on setting the journal storage size for a queue, see Set the journal storage size for queues.


Storing message files on multiple disks

Independent clients and Message Queuing servers can improve their messaging performance by storing the various files used to implement messaging across several physical disks. Message Queuing can use three different disks to implement message functions. For the best messaging performance on Message Queuing servers, put the messaging (*.mq) files, message log files, and transaction log files on separate physical disks.

For information on how to store messaging files on multiple disks, see Store messages on multiple disk drives.


Sending transactional messages to multiple destinations

Both distribution lists and multiple-element format names have support for transactional messaging. When a message is sent to a distribution list or a multiple-element format name within a transaction, a copy of the message is sent to each applicable outgoing queue. Failure in sending the message to any of these outgoing queues will abort the entire transaction. A distribution list or a multiple-element format name may reference a mixture of transactional and nontransactional target queues. When a transactional message is sent to such a mixture of targets, the message is allowed to be sent to all the transactional and nontransactional target queues on the local or a remote computer. However, when the message reaches a nontransactional queue, it is rejected and transferred to the transactional dead-letter queue on the computer hosting the nontransactional queue for storage, and a negative acknowledgement message indicating that a transactional message was sent to a nontransactional queue is sent to the administration queue specified in the original message.

Exactly-once and in-order delivery

Message Queuing guarantees that transactional messages will be delivery in-order and only once. The Exactly-Once In-Order Delivery (EOD) protocol is an end-to-end protocol, guaranteeing that messages are not duplicated or delivered out-of-order. To achieve this, the sender attaches information to each message that allows the receiver to eliminate duplicate and out-of-order messages. All messages that have order relation between them are said to be in the same message stream. Each message in a stream carries a sequence number, identifying the message in the stream, and a previous number identifying the preceding message in the same message stream. The first message in a stream always carries a previous number equal to zero.

Each receiver filters the newly arriving messages and accepts only those messages that arrive in-order and are not duplicates. To implement this, the receiver uses the sequence numbers and previous numbers attached to the messages. The receiver needs to keep track of the sequence number of the last message accepted in each message stream, there is no need to keep message history or a larger database. The receiver acknowledges by sending the sequence number of the last message accepted back to the sender. This lets the sender know that the receiver accepted all messages up to the acknowledged message.

Sending messages

The sender tags each message with a monotonically increasing sequence number and links it to the previous message using the previous number. When there is no previous message in the message stream the sender places a zero in the previous number field. This ensures that the receiver will accept the message. A message that is discarded at the sender side (for example, when the time to receive the message before time-out has elapsed) is removed from the message stream, and the next message is linked to the message preceding the removed message.

The sender needs to keep resending the same messages until an "order-acknowledgment" arrives from the receiver. The acknowledgment carries a sequence number indicating that all messages up to that number have safely arrived in-order and exactly-once at the target. The sender can thus safely discard all messages up-to and including the indicated sequence number.

To overcome crash scenarios where the receiver cannot recover its database (last accepted message sequence number for a given message stream), the sender must assign the first message in the queue a previous number of zero. On the other hand, after a sequence number has been attached to a message, it must never be changed.

Receiving Messages

The receiver keeps track of the last accepted message sequence number for each message stream. It uses this number to filter out arriving messages and accept only those that arrive in-order and are not duplicates. The receiver initiates this last number with a zero for each new message stream. The simplest algorithm the receiver must implement looks like the following:

if(message.sequence <= last_accepted_sequence)
{
    Reject Message
}

if(message.previous > last_accepted_sequence)
{
    Reject Message
}

Accept Message

last_accepted_sequence = message.sequence;

When a new message stream has been created, the receiver occasionally sends an "order-acknowledgment" containing the last accepted sequence number. This acknowledgment signals the sender that the target has accepted all messages in the message stream up to the indicated sequence number. The receiver keeps sending these acknowledgments for active message streams; that is, message streams for which messages continue to arrive even if these messages are not accepted.

The receiver sends these "order-acknowledgments" to the acknowledgment return address indicated by the incoming message. All messages within the same message stream must have the same acknowledgment return address.

It is recommended that the quality of service for acknowledgment messages be as lightweight as possible because the receiver maintains the state to regenerate the acknowledgment persistently (last sequence number).

For more information on sending messages within transactions, see Transactional messaging.

For information on sending transactional messages to distribution lists, see Distribution lists.

For information on sending transactional messages to multiple-element format names, see Multiple-element format names.


Administering Triggers

This section provides conceptual information about administering Message Queuing triggers. Instructions for completing individual tasks can be found in the How To... section in this online Help file. For details about Message Queuing triggers, see the following links:

  • To learn about defining message processing types for triggers, see Defining message processing types.
  • For information on how trigger messages are processed, see Processing trigger messages.
  • To learn about creating triggers, see Creating triggers.
  • To learn about default trigger values, see Modifying default trigger values.
  • For an example, see Implementing triggers.


Defining message processing types

A message processing type is defined for each trigger. The available message processing types are peeking, retrieval, and transactional retrieval.

When peeking is selected as the message processing type for a given trigger and the Message Queuing Triggers service is running, it peeks at each message arriving at the monitored queue, tests it for the conditions of all the rules associated with the queue, and performs all the applicable actions, but does not remove it from the queue.

When retrieval is selected as the message processing type, the Message Queuing Triggers service peeks at each message arriving at the monitored queue, tests it for the conditions of all the rules associated with the queue, and invokes all the applicable actions. If at least one condition is satisfied, and no invoked action fails, the message is removed from the queue.

The transactional retrieval type of message processing is similar to the retrieval type, but in this case the message is returned to the queue if any of the operations involved in retrieving the message cannot be completed and the retrieval transaction is aborted.

When messages arrive at a monitored queue, Message Queuing does not limit access to these messages to the Message Queuing Triggers service. Thus, it is possible for another Message Queuing application to open the queue and remove messages before the Message Queuing Triggers service manages to process those messages.


Processing trigger messages

The Message Queuing Triggers service starts to process the messages in the queue as soon as the service starts running. The service starts at the beginning of the queue and processes all the messages in the queue. After processing all the existing messages, the service waits at the end of the queue for a new message. If the service is stopped and restarted, it will process all messages remaining in the queue again.

Processing messages having the same priority

When all the messages sent to a monitored queue have the same priority, new messages are always placed at the end of the queue. After processing all the existing messages in the queue, the Message Queuing Triggers service will activate the trigger each time a new message arrives at the end of the queue. The illustration below shows a queue with four messages and portrays a trigger with the peeking type of message processing. The Message Queuing Triggers service already peeked at message 1, message 2, message 3, and message 4 and will continue to peek at messages as they arrive at the end of the queue.

Figure showing peeking at messages having the same priority

Processing messages having different priorities

When messages with different priorities arrive in a queue, a new message can be placed anywhere in the queue. For example, when a high-priority message is placed somewhere in the queue, the Message Queuing Triggers service processes the new message next regardless of where it is placed in the queue and then continues to process all the low-priority messages that are in the queue.

In the next illustration, which also portrays a trigger with the peeking type of message processing, the Message Queuing Triggers service makes one pass through the queue peeking at message 1, message 2, message 3, and message 4. Then, when message 5, a new message of priority 1, arrives at the queue, it is placed between message 2 and message 3. The service goes back and peeks at message 5 and then continues to peek at message 3 and message 4 again.

Figure showing peeking at messages having different priorities

Note that in this case, the trigger is activated twice for message 3 and twice for message 4. You can avoid messages being read more than once by using a transactional queue (where all messages have a priority of 0). For more information on transactional queues, see Transactional messaging.

Processing messages within transactions

When a message is retrieved from within a transaction, Message Queuing does not roll back the cursor if the transaction is aborted. For example, given a queue with two messages, message 1 and message 2, if you remove message 1 from within a transaction, Message Queuing will move the cursor to message 2. However, if the transaction is aborted for any reason, message 1 is inserted back into the queue, but the cursor remains at message 2.

For the peeking type of message processing in a queue containing one message when a COM component invoked by a trigger rule receives the message invoking it and the same COM component is configured to be part of an external transaction, if any operation in the transaction cannot be completed, the transaction is aborted and the message is returned to the queue. Then, if the trigger is serialized, the Triggers service waits until the process performed by the COM component ends (aborts) before starting to process a message again. In this case, the queue cursor moves on to wait for the next message, and the trigger does not invoke the COM component again for the same message. However, if the trigger is not serialized, as soon as the Triggers service finishes peeking at the message, it sends a request to peek at the next message and waits for a message to appear in the queue. Therefore, when the transactional COM component is invoked, there is already a pending peeking operation in the system. When the message is returned to the empty queue in the aborted transaction, it arrives at the queue in the position to which the queue cursor is pointing. In this case, the returned message is processed again, the COM component is invoked for the same message, and a perpetual loop exists until a new message arrives or all the operations in the transaction can be completed.

Sample implementation of Message Queuing Triggers

Suppose you create a new trigger named PrivateTrigger, which is associated with the private queue MyComputer\MyQueue and has two rules attached to it: MyRule1 and MyRule2.

Each of these rules defines a condition (such as "Message label contains marketing") and an action to be taken when the condition is true (such as "open MSPaint.exe" with the parameter Message label).

When a message arrives at MyComputer\MyQueue, the Message Queuing Triggers service is notified. Next, for the trigger, PrivateTrigger, defined for that queue, the rules MyRule1 and MyRule2, which are attached to that trigger, are applied. Last, Microsoft Paint is opened if all the conditions for those rules are satisfied (are true).

For more information about implementing the Message Queuing Triggers service, see Installing Message Queuing triggers.


Creating triggers

Triggers are created on the local computer in Triggers under the Message Queuing Triggers folder in the console tree of the Computer Management snap-in or in Triggers under any queue that is already monitoring a trigger by right-clicking Triggers, pointing to New, and then clicking Trigger. In the latter case, the queue selected automatically becomes the monitored queue. On the first page of the New Trigger dialog box, you must type a name for the new trigger in Trigger name. The monitored queue can be a user-defined queue registered in Active Directory, whose path name must be typed in Queue path name, or one of the automatically created queues on the local computer, which is selected by clicking the applicable button. Regardless of where the creation of a trigger is initiated, every trigger created on the local computer is displayed in the Computer Management snap-in under Triggers and under the applicable monitored queue. You then select the message processing type, and finally you indicate whether the trigger will be enabled and whether it will be serialized. For more information on the message processing type, enabled triggers, and serialized triggers, see Triggers overview.

By default, the Message Queuing Triggers service runs under the Network Service account. For heightened security, you can change the default Triggers service account to a more secure setting. You can also specify a less secure account for the Triggers service. The account used must be able to access the queues with which triggers are associated. Note that executable files invoked by triggers are invoked with the same security privileges as those assigned to the Triggers service. If your rule invokes a COM component, make sure that it can be successfully invoked from the security context used by the Triggers service, is properly registered, and has suitable dependencies. For more information, see Triggers overview.

You can attach an existing rule to the new trigger by selecting a rule and then associating it with the trigger. The order in which the rules are tested (their priorities) can be specified. For more information, see Create triggers.

Before creating a trigger, verify that the account under which the Message Queuing Triggers service is running has been granted the Peek Message permission for all existing queues that will be associated with triggers. For more information, see Set permissions for computer and queue objects.

Managing triggers and queues

When you delete a queue, the triggers associated with that queue are not deleted. If you later re-create a queue of the same name, any existing triggers will be used by this queue. However, this re-created queue will not be monitored by the Message Queuing Triggers service until the computer is restarted, or the associated triggers disabled and then enabled again. For instructions on setting the enabled or disabled property for a trigger, see View or change properties of triggers and rules for triggers.


Modifying default trigger values

The Message Queuing Triggers service has a set of default configuration values. You can modify these values after the service is installed by using the Computer Management snap-in.

Configuration information as well as the trigger and rule definitions are stored in the local registry.

You can modify any of the following configuration settings:

  • Initial number of threads. The default value is 5.
  • Maximum number of threads. The default value is 20.
  • Default message body size. The default value is 2048. This parameter is the size of the buffer that Message Queuing Triggers allocates for an incoming message. It is recommended that the value of this setting be sufficient for a buffer that can accommodate 90% of all messages that are expected to arrive at the monitored queue. An excessively low value will force the service to reallocate this buffer for every message that arrives with a larger message body. An excessively high value will waste resources.

When you change a configuration setting, you will need to stop and restart the service before the new setting will take effect. For more information on how to change configuration settings, see Change default configuration values for triggers.


Implementing triggers

Suppose you create a new trigger named PrivateTrigger, which is associated with the private queue MyComputer\MyQueue and has two rules attached to it: MyRule1 and MyRule2.

Each of these rules defines a condition (such as "Message label contains marketing") and an action to be taken when the condition is true (such as "open MSPaint.exe" with the parameter Message label).

When a message arrives at MyComputer\MyQueue, the Message Queuing Triggers service is notified. Next, for the trigger, PrivateTrigger, defined for that queue, the rules MyRule1 and MyRule2, which are attached to that trigger, are applied. Last, Microsoft Paint is opened if all the conditions for those rules are satisfied (are true).

For more information about implementing the Message Queuing Triggers service, see Installing Message Queuing triggers.


Monitoring and Testing Message Queuing

This section provides information on monitoring Message Queuing, so that you can tune performance and identify issues. For details, see the following links:

  • Monitoring events
  • Monitoring performance
  • Monitoring transactional messages
  • Monitoring connectivity
  • Sending test messages


Monitoring events

You can monitor Message Queuing events using Event Viewer.

Message Queuing logs information about its operation to the Windows Server 2003 family event logs. Message Queuing events are located in the Source column under "MSMQ." Most events are written to the Application Log. Security-related events are written to the security log, and service-related events are written to the system log.

For information on how to view Message Queuing events, see View Message Queuing events.

For more information on Event Viewer, see Event Viewer.

There are three types of application events for Message Queuing in the Windows Server 2003 family Application Log, as follows:

  • Informational events. Infrequent, significant events that describe successful operations.
  • Warnings. Not necessarily significant events, but indicative of potential problems.
  • Errors. Events generated for significant problems.

Some application events are not logged at each occurrence. For example, if a Message Queuing server cannot establish a session with the destination computer, an event is logged for the first failure only and another event is logged after the session is established.

There are two types of security-related events for Message Queuing in the security log, as follows:

  • Success Audit. Generated when selected objects are successfully accessed.
  • Failure Audit. Generated when access to a selected object is denied.

For more information on access auditing, see Auditing Message Queuing objects.


Monitoring performance

You can monitor the performance of Message Queuing by using the performance counters provided. You can view these performance counters using System Monitor. The default performance counters are grouped under the following objects:

  • MSMQ Service
  • MSMQ Queue
  • MSMQ Session
  • MSMQ Incoming HTTP Traffic
  • MSMQ Outgoing HTTP Session
  • MSMQ Incoming Multicast Session
  • MSMQ Outgoing Multicast Session

For instructions on tracking counters, see Track Message Queuing service counters, and Track Message Queuing queue counters.

For more information on System Monitor, see System Monitor overview.

Notes

  • Performance counters are not available when multiple instances of Message Queuing are running in a server cluster.
  • Only the MSMQ Service and MSMQ Queue objects are always visible.

MSMQ Service performance object

The MSMQ Service performance object is provided on Message Queuing servers and independent clients. The MSMQ service object contains performance counters that you can use to monitor Message Queuing statistics for a selected computer.

The value you see for memory usage includes the memory space occupied by all messages in local queues on the computer. Because recoverable messages are stored on disk, this memory space is backed up by memory-mapped files on disk, not from the Windows Server 2003 family paged memory pool. For more information on how messages are stored, see Local message storage.

MSMQ Queue performance object

The MSMQ Queue performance object contains performance counters that you can use to monitor message statistics for a selected queue. There can be an instance of the object for each open queue and for each queue containing messages on the computer where the queue resides up to the maximum number of instances allowed on that computer. In addition, there can be an instance for each outgoing queue opened for every destination queue on the computer where the outgoing queue resides up to the maximum number of instances allowed on that computer. The name given a queue counter is the format name of the queue. Note that there can potentially be multiple outgoing queues (and counter instances) for the same queue, opened with different format names. If a connector application is running on the computer, a counter is available for the connector queue also; the queue name is displayed as foreign=GUID.

Under Instance, only the first 97 queues created on the computer, including private queues, are listed. The queue counters for a specific computer appear for each instance. The Computer Queues instance represents the source or computer journal and the dead-letter queue for the computer. The Bytes in Queue and Messages in Queue counters monitor that computer's dead-letter queue. The Bytes in Journal and Messages in Journal counters then monitor the computer journal (Journal messages in the System Queues folder).

An outgoing queue is identifiable because the computer name listed in the counter instance matches the name of the computer on which the corresponding destination queue resides.

MSMQ Session performance object

The MSMQ Session performance object is visible only when the computer has established an active session with another Message Queuing computer. This object contains counters that can be used to monitor statistics about active sessions between computers running Message Queuing. Multiple instances of this object may be listed, one for each session. There can be an instance of this object on both computers involved in each session up to the maximum number of instances allowed on each computer. Instance lists the IP address of the computer with which there is an active session.

Performance objects for HTTP messages

The MSMQ Incoming HTTP Traffic and MSMQ Outgoing HTTP Session performance objects include counters that monitor messages sent over HTTP transport. These objects contain counters that monitor statistics about incoming HTTP messages, the rates at which the messages and message bytes arrive at the computer in an incoming HTTP connection, the total number of HTTP messages that arrived in the connection, and the total number of message bytes that arrived in the connection as well as counters that monitor the statistics about active outgoing HTTP sessions between the computer and other computers, the rates at which message bytes and messages are sent from the computer in a specific outgoing session, the total number of HTTP messages sent in the session, and the total number of message bytes sent in the session.

Performance objects for multicast messaging

The MSMQ Incoming Multicast Session and MSMQ Outgoing Multicast Session performance objects contain counters that monitor messages sent in multicast sessions. These objects contain counters that monitor statistics about active incoming multicast sessions, the rates at which the messages and message bytes arrive at the computer in a specific incoming multicast session, the total number of multicast messages that arrived in the session, and the total number of message bytes that arrived in the session as well as counters that monitor the statistics about active outgoing multicast sessions between the computer and other computers, the rates at which message bytes and messages are sent from the computer in a specific outgoing session, the total number of multicast messages sent in the session, and the total number of message bytes sent in the session.

Improving messaging performance

If available processing resources (CPU time) are not limiting messaging performance, it is possible that independent clients and Message Queuing servers can improve messaging performance by storing the various message and log files used to implement messaging across multiple physical disks.

To determine whether your computers are limited by disk access or by processing power, track the % Processor Time counter (located in the Processor object) and the Avg. Disk Queue Length counter (located in the DiskLength object). If the sustained % Processor Time value is above 75 percent during the time messages are being sent, adding processing capacity may improve messaging performance. If the Avg. Disk Queue Length value for any drive is greater than 0.6 when messages are being sent, additional disks may improve messaging performance.

For information on how to store the message and log files on separate physical disks, see Store messages on multiple disk drives.


Monitoring transactional messages

You can monitor Message Queuing transactions using the Component Services snap-in when the Microsoft Distributed Transaction Coordinator (DTC) is running.

Message Queuing uses the DTC, installed by default with Windows Server 2003 family, for implementing external transactions. You can use the Component Services snap-in to monitor statistics for transactional messages that are sent or received within external transactions and to monitor statistics for all transactions managed by the DTC. For more information, see View external transactions.

When you monitor external transactions, the details pane opened by clicking Transaction Statistics in the console tree of the Component Services snap-in provides useful information on active, committed, and aborted transactions. The DTC must be running to perform external transactional messaging for Message Queuing.

For more information on transactional messaging, see Transactional messaging.

For more information on the Microsoft DTC, see Using Component Services.


Monitoring connectivity

Message Queuing offers an MQPing test, which has some similarity to the ping command supported by the TCP/IP protocol. You can use MQPing to determine whether the Message Queuing service is running on the computer being tested and whether that computer is currently connected to the network. When a computer running Message Queuing receives an MQPing request, it returns a response message to a response queue on the computer that sent the MQPing request. Thus, unlike the ping command, MQPing does not test for direct IP connectivity between the two computers, but verifies that messages can be sent between them with allowance for the possibility of routing.

For information on how to use MQPing, see Test connectivity using MQPing.


Sending test messages

The Computer Management snap-in or the Active Directory Users and Computers snap-in is used to administer queues. For more information, see Administration overview.

A test message is a message that is generated by the Message Queuing service on a specified source computer and sent to a target queue on a specified destination computer. The source computer can be any independent client or Message Queuing server, and the specified destination computer hosting the target queue can be any other independent client or Message Queuing server within the same forest. The target queue must be a test queue; that is, a nontransactional public queue with a queue type ID set equal to {55EE8F33-CCE9-11CF-B108-0020AFD61CE9}.

Test messages are sent to verify that messages can be sent from a given source computer and delivered to public queues on a given destination computer and, if message route tracking is enable, to track the route taken by messages sent from the source computer to public queues on the destination computer. For more information on tracking the routes taken by messages, see Tracking messages and routes.

You can either create a new test queue or transform an existing public queue into a test queue. Most existing public queues can be made to function as a test queue by changing the type ID to that of a test queue. However, it is useless to change the type ID of a transactional queue or a queue requiring message authentication to convert it into a test queue, because test messages, which are nontransactional and are not authenticated, will not be delivered to a transactional queue or to a queue requiring message authentication (unless the queue is located on the source computer).

Sending test messages is not enabled by default following Message Queuing installation, and must be enabled before you can send a test message. For instructions, see Enable route tracking and test messages. For information on how to send a test message, see Send test messages.


Troubleshooting and Additional Resources

This section provides help on troubleshooting Message Queuing and links to additional Message Queuing resources.

For help with installation, deployment, and administration issues, see:

  • Troubleshooting installation problems
  • Troubleshooting administration problems
  • Troubleshooting triggers

For information and links to other Message Queuing resources, see:

  • Additional Message Queuing resources


Troubleshooting installation problems

This topic provides guidelines for solving problems associated with installing new Message Queuing software or running Message Queuing Setup.

When encountering installation problems, always inspect the setup log files first. This is especially important when you perform an unattended setup, because you will not know if something went wrong. The Message Queuing setup log file, Msmqinst.log, is located in the Windows folder. If this file does not identify the problem, look at the Windows Server 2003 family setup log file, Setuperr.log, which is located in the Windows folder (typically C:\Windows).

What problem are you having?

You have completed Windows Server 2003 family Setup, but cannot find Message Queuing.

Cause: Message Queuing is not installed by default during Windows Server 2003 family Setup.

Solution: Using Add or Remove Programs in Control Panel, install Message Queuing after Windows Server 2003 family is installed.

See also: Installation overview

You cannot install Message Queuing, or you receive an "Access is Denied" error.

Cause: To install Message Queuing clients, you must be logged on with local administrative permissions for the computer on which you want to install software. To install Message Queuing servers or Message Queuing servers with Downlevel Client Support on Windows Server 2003 family domain controllers, you need to have domain administrative permissions. To install Message Queuing servers with Routing Support on nondomain controllers, you need to have enterprise administrative permissions.

Solution: Verify that you are logged on with the proper permissions for the computer you want to install Message Queuing on.

Solution: Allow Active Directory replication to complete, and then try again.

See also: Installation permissions

You have been prompted for the name of a server during Message Queuing Setup in a Windows Server 2003 family enterprise.

Cause: For a Windows Server 2003 family computer, Setup was unable to automatically locate a Windows Server 2003 family domain controller in the local site or a nearby site.

Solution: Verify that both the computer on which you are running Message Queuing Setup and the domain controller have network connectivity.

See also: Installation overview

You receive a "Message Queuing application is running" error while uninstalling Message Queuing.

Cause: A Message Queuing application is currently running.

Solution: Close all Message Queuing applications.

See also: Start or stop services for Message Queuing

You are installing a Message Queuing computer as a dependent client and cannot configure a supporting server for it.

Cause: Following installation, the default setting is that Message Queuing server computers do not support dependent clients.

Solution: Enable the required Message Queuing server to act as a supporting server for dependent clients. For instructions, see Enable a supporting server.


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.

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.

See also: Active Directory Users and Computers snap-in, Active Directory Sites and Services snap-in, Message Queuing and Active Directory

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.

See also: Security overview

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: Grant yourself the Peek Message and Read permissions for the queue. 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.

See also: Access control for Message Queuing

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.

See also: Authentication for Message Queuing

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 TokenGroupsLobalAndUniversal attribute for all users, and requires no further manual administration.

See also: Access control for Message Queuing

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.)

See also: Backing up and restoring messages

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.

See also: Access control for Message Queuing

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 triggers

This topic discusses the most common problems encountered when using the Message Queuing Triggers service.

What problem are you having?

The Message Queuing Triggers service fails to start.

Cause: The Message Queuing Triggers service has been configured to run under a domain user account without proper administrative permissions.

Solution: Configure the Message Queuing Triggers service to run under the default Network Service account, which has sufficient permissions to run the Message Queuing Triggers service, or grant yourself the necessary permissions. The Triggers service must run under an account with administrator permissions.

Cause: The Message Queuing Triggers service has failed. In-process Component Object Model (COM) components that are invoked can sometimes fail and thereby cause the Message Queuing Triggers service to fail.

Solution: Rectify the condition that causes the COM component to fail, and then restart the Message Queuing Triggers service.

A trigger is defined, but it does not appear to be firing.

Cause: The trigger is currently disabled.

Solution: Verify that the trigger has been enabled.

See also: View or change properties of triggers and rules for triggers

Cause: The account under which the Message Queuing Triggers service is running has not been granted the Peek Message permission for the monitored queue. Or, if the message processing type of the trigger is "retrieval" or "transactional retrieval," the account has not been granted the Receive Message permission for that queue.

Solution: Change the permissions for the queues, and then restart the Message Queuing Triggers service.

See also: Set permissions for computer and queue objects

Cause: The Message Queuing Triggers service is not running.

Solution: Verify that this service has been started.

Cause: The Message Queuing Triggers service has been paused.

Solution: Verify that this service is not in a paused state.

Cause: The first rule created and assigned to the first trigger for a queue is applied to messages already contained in the queue, instead of to messages reaching the queue after this rule is assigned.

Solution: Verify which message Message Queuing Triggers is processing.

Cause: The trigger conditions are not all satisfied. If any trigger condition evaluates as false, the trigger will not fire.

Solution: Verify that all conditions of the rule are true.

Cause: The Message Queuing Triggers service cannot be initialized when running under a non-administrator account.

Solution: By default, the Message Queuing Triggers service runs under the Network Service account. If you have changed this default, ensure that the account you have specified has administrator permissions.

The processing of messages by the Message Queuing Triggers service slows disproportionately as more messages arrive at a monitored queue.

Cause: This is normal when the Message Queuing Triggers service runs under heavy loads. It occurs because the maximum number of threads is reached.

Solution: You can accelerate the processing of messages by increasing the maximum number of allowable threads. You can increase the number of working threads in the Computer Management snap-in. To do this, open Computer Management, click Services and Applications, click Message Queuing, right-click Triggers, and then click Properties. Increase the maximum number of threads in Max number of threads.

I cannot see my triggers application on the desktop, although I see in Task Manager that the application is running.

Cause: The Triggers service runs by default under the Network Service account, and interaction with the desktop functionality is only available for the Local System account.

Solution: Configure the Triggers service to run under the Local System account.


Additional Message Queuing resources

This section provides sources of additional information for Message Queuing and other software products that work with Message Queuing.

Microsoft Platform Software Development Kit

The Message Queuing Software Development Kit (SDK) is available as part of the Microsoft Platform SDK in the Microsoft Developer Network (MSDN) Library. The Message Queuing SDK includes background information on developing Message Queuing applications and a reference section that thoroughly describes the functions, properties, structures, and COM components supplied and used by Message Queuing. The Message Queuing SDK also contains sample code and program files for representative types of applications.

The Microsoft Platform SDK is released on a regular basis in the MSDN Library, which is available both on CDs and on the Web. To access the Message Queuing SDK on the Web, refer to the MSDN Library Web site.(http://msdn.microsoft.com/library/default.asp)

Web Sites

  • For the latest information on Message Queuing, see the Message Queuing Web page.(http://www.microsoft.com/msmq)
  • For the latest Frequently Asked Questions (FAQs) on Message Queuing, see the Message Queuing FAQ Web page.(http://support.microsoft.com/msmq/faq.htm)
  • For the information on Message Queuing available from Microsoft Product Support Services, see the Microsoft Product Support Services home page.(http://support.microsoft.com/directory/default.asp)

Internet newsgroups

You can subscribe to the following newsgroups by following the instructions provided with your Web browser or newsreader software for connecting to an Internet news server:

  • microsoft.public.msmq.deployment
  • microsoft.public.msmq.interop
  • microsoft.public.msmq.networking
  • microsoft.public.msmq.performance
  • microsoft.public.msmq.programming
  • microsoft.public.msmq.security
  • microsoft.public.msmq.setup

Books

If you are interested in reading books that pertain to application development for Message Queuing, see the following list:

  • Dickman, Alan. Designing Applications With MSMQ: Message Queuing for Developers. Addison-Wesley Publishing Co., 1998.
  • Homer, Alex, and David Sussman. Professional MTS and MSMQ Programming with VB and ASP. Wrox Press Inc., 1998.
  • Sessions, Roger. Chapter 11 in COM and DCOM: Microsoft's Vision for Distributed Objects. John Wiley & Sons, 1998.


External software copyright and permission notice - J Kanza

Microsoft Windows Graphic

External software copyright and permission notice - J Kanza

All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, publish, distribute, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation. Permission is also given to modify the software to any extend, under the condition that, in the modified software, the prefix "GB_" is changed to something else, and the name directories for includes files ("gb" in this distribution) is also changed.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder.


Purging messages

You can purge all messages in any queue, except for system and private queues. You cannot purge individual messages in a queue.

For information on how to purge all messages in a queue, see Purge all messages in a queue.


Queue object

A queue object with a user-defined name is created for each queue and contains information associated with the particular queue. Queue objects are of the MSMQ-Queue class type. Each queue object contains a Queue messages folder and a Journal messages folder.

Queue objects are located under the msmq object of the computer on which they reside, except for dependent clients, whose queue objects are located under the msmq object of the supporting server.

Objects used to create distribution lists

Distribution lists are essentially distribution group objects in Active Directory. They can contain explicit references only to destinations published in Active Directory; that is, to public queues, queue aliases, and other distribution lists, but not to private and URL-named queues. Queue aliases are published in Active Directory and can point to any queue, including private and URL-named queues. Thus, queue aliases pointing to private and URL-named queues can be included in a distribution list.


Routing link object

A routing link object with a user-defined name is created for each routing link that you create between two Message Queuing sites and contains connectivity information. Routing link objects are of the MSMQ-Routing-Link class type.

Routing link objects are located under the MsmqServices object in the details pane of the Active Directory Sites and Services snap-in.


Upgrade objects

The MSMQ Computers organizational unit (OU) object is created only by the Message Queuing migration tool in a mixed-mode domain environment (where there is at least one MSMQ 1.0 controller server running on a Windows NT 4.0 computer together with a Message Queuing server running on a Windows Server 2003 family or Windows 2000 computer) and is used as a container for the computer objects for MSMQ 1.0 computers that belong to Windows NT 4.0 domains.

The MSMQ Computers OU object is displayed in the console tree of the Active Directory Users and Computers snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • MSMQ Computers

MSMQ Users organizational unit object

The MSMQ Users OU object is created only by the Message Queuing migration tool in a mixed-mode domain environment (where there is at least one MSMQ 1.0 controller server running on a Windows NT 4.0 computer together with a Message Queuing server running on a Windows Server 2003 family or Windows 2000 computer) and is used as a container for MSMQ upgraded user objects.

The MSMQ Users OU object is displayed in the console tree of the Active Directory Users and Computers snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • MSMQ Users

MSMQ upgraded user object

An MSMQ upgraded user object is created only by the Message Queuing migration tool in a mixed-mode domain environment and contains registered certificates for former MSMQ 1.0 users who belonged to Windows NT 4.0 domains. An MSMQ upgraded user object is of the MSMQ-Upgraded-User class type.

The MSMQ upgraded user objects are listed in the details pane of the Active Directory Users and Computers snap-in when the MSMQ Users object is selected in the console tree.

  • Active Directory Users and Computers
  • YourDomainObject
  • MSMQ Users

Notes

  • When a user from a trusted Windows NT 4.0 domain logs on to a computer that is running any version of the Message Queuing service and belongs to a Windows Server 2003 family domain, even in a non-mixed mode, the Message Queuing service creates an MSMQ upgraded user object for that user.


Pausing and resuming queues

The Computer Management snap-in or the Active Directory Users and Computers snap-in is used to administer queues. For more information, see Pausing and resuming queue operations.

Outgoing queues on a computer are used to store messages temporarily before the messages are sent to their destinations. Outgoing queues are visible only when using the Computer Management snap-in.

You can pause and then later resume the operation of a local outgoing queue, thereby deferring the sending of messages from that queue to the corresponding destination queue. This way, you can send all pending messages to a destination queue at a later time. For information on how to pause or resume an outgoing queue, see Pause or resume an outgoing queue.

You can also take Message Queuing offline from the network. When you take Message Queuing offline from the network, you pause the operation of all outgoing queues on the local computer. This is useful when you communicate over a slow, expensive connection and want to defer sending messages in all outgoing queues on the computer to a later time. For information on how to take Message Queuing offline from the network for a computer, see Take outgoing queues offline.


Planning for remote clients

Remote dial-up Message Queuing clients can connect to your network through a computer that is configured as a remote access server. To reduce long-distance charges and ensure that remote clients always connect to the same site, configure a remote access server for each site. While it is possible to configure clients to connect to your network through a remote access server at any site, this configuration does not provide the same benefits.

A remote access server must be configured with only one IP address. If the computer is configured with more than one IP address, the automatic site recognition that some clients perform can fail. As a result, clients that connect to your network using remote access can have poor messaging performance or be unable to send or receive messages.

When using remote access for clients, note the following:

  • Clients must not be configured to use the NetBEUI protocol when using remote access. Configuring a client to use NetBEUI causes the client name to be resolved to the IP address of the server, rather than to the IP address of the client computer. Support for the NetBEUI protocol is disabled by default.
  • You cannot sequentially dial into two different sites over a dial-up line without first stopping and restarting the Message Queuing service on the client.

For more information on remote access for Windows Server 2003 family computers, see Remote access.


Trigger elements

Each trigger is associated with a specific monitored queue on the local computer and is invoked by the Message Queuing Triggers service for every Message Queuing message arriving at that queue. A trigger is configured to obey one or more rules. A rule is defined by one or more conditions and an action in the form of an executable file or COM component that is executed when all the conditions associated with the rule are evaluated as true.

A trigger is an automatic mechanism for implementing a specific action in response to a message event. In the context of Message Queuing Triggers, an event is defined as a set of one or more conditions that may be satisfied by a message arriving in a queue. The collection of all triggers on a particular computer is called the trigger set.

A condition is a criterion that is applied to a message when it arrives at a monitored queue. A condition can test only for a property of the message. Every condition or set of multiple conditions is associated with an action.

An action is an executable behavior that is taken when a condition or a set of multiple conditions is true. An action can be expressed as an executable and a parameter list, or as a COM component, a method, and a parameter list. You can also invoke other types of files by making them parameters of an .exe file. For example, you can invoke an .msc file by specifying mmc.exe as the executable file and the full path of the .msc file as a parameter.

A rule is a condition-action pair. A rule specifies the action that will be taken when a specific condition or set of conditions is true. The collection of all rules (for all triggers) on a particular computer is called the rule set.

Notes

  • Triggers can be associated with queues located on the local computer and a remote computer.