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. 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.

Message Queuing is of particular 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 hence discusses only management of the infrastructure provided by Message Queuing and not application development. For information on developing Message Queuing applications, see the Message Queuing Software Development Kit (SDK), which is part of the Microsoft Platform SDK in the Microsoft Developer Network (MSDN) Library. For more information on accessing the Message Queuing SDK, see the Microsoft Platform Software Development Kit in Resources.

  • Before installing or upgrading Message Queuing, see Checklist: Installation for Message Queuing clients.
  • To find features that have been moved in Windows XP, see New ways to do familiar tasks.
  • For tips about using Message Queuing, see Best practices.
  • For help with specific tasks, see How to....
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.

© 1997-2001 Microsoft Corporation.
All rights reserved.


Checklist: Installation for Message Queuing clients

Use this checklist when installing Message Queuing clients on Windows XP computers that do not have previous versions of Message Queuing installed. Message Queuing is not installed by default during Windows XP Setup.

Step | Reference
Review key concepts and determine the client functionality needed. | Message Queuing computers
Review the installation requirements. | Installation overview for Message Queuing
Review the problems that may arise during installation and their solutions. | Troubleshooting installation problems for Message Queuing
Log on with local administrative permissions (as a member of the local Administrators group). | Installation permissions in Installation overview for Message Queuing
For a dependent client, verify that a Message Queuing server with at least independent client functionality is available, preferably in the same site in which you are installing. Any such server operating in domain mode can serve as a supporting server. | Dependent client setup
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. | Send test messages

Notes

  • New Windows XP 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.


New ways to do familiar tasks

This table lists common tasks for Message Queuing that are performed using different user interfaces in Windows XP and Windows NT 4.0.

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

If you want to | In Windows NT 4.0 use | In Windows XP
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 for Message Queuing.
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 Administering a Message Queuing network.
Create foreign sites or add foreign computers | MSMQ Explorer | Open Active Directory Sites and Services. For more information, see Administering a Message Queuing network.
Configure Message Queuing computers and properties; set computer quotas or properties | MSMQ Explorer | Open Active Directory Users and Computers. For more information, see Administering Message Queuing computers.
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; set queue quotas or properties | MSMQ Explorer | Open Computer Management or open Active Directory Users and Computers. For more information, see Administering queues for Message Queuing.
View or delete messages; view message properties | MSMQ Explorer | Open Computer Management or open Active Directory Users and Computers. For more information, see Administering messages for Message Queuing.

This table lists common tasks for Message Queuing that are performed using different user interfaces in Windows XP and Windows 2000.

If you want to | In Windows 2000 use | In Windows XP
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 | Message Queuing in Control Panel | Open Computer Management. For more information, see 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.
Authenticate MSMQ 1.0 controller servers | Message Queuing in Control Panel | Open Computer Management. For more information, see Authenticate MSMQ 1.0 controller servers.
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

  • The Active Directory Users and Computers snap-in and the Active Directory Sites and Services snap-in are not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. These snap-ins are required to administer a domain-based Message Queuing network or to access and display information in Active Directory. You can start these snap-ins by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-ins installed. This way, you can perform domain-based administrative tasks and access Active Directory from a Message Queuing computer running Windows XP Professional. For more information, see Administration tools.
  • In a mixed-mode environment, the Windows NT 4.0 primary enterprise controller (PEC) has been upgraded to a Windows 2000 domain controller configured as a Global Catalog server and a Message Queuing server, and the remaining servers comprise a mixture that includes at least one Windows NT 4.0 MQIS server and any number of Windows 2000 computers. Such an environment will exist until the entire migration process is completed and all the Windows NT 4.0 MQIS servers in the enterprise are upgraded. If a Message Queuing client running Windows XP communicates with a Windows NT 4.0 MQIS server in such an environment, the MMC snap-ins can be used on the Windows XP computer to access information regarding the MSMQ configuration that is stored on the Windows NT 4.0 MQIS server and to view the properties of all the MSMQ objects on that computer. However, in this case, the Active Directory Users and Computers snap-in does not show the permissions associated with these objects on the security page. These permissions can be viewed either from the Computer Management snap-in or locally on the MSMQ 1.0 server using MSMQ Explorer.
  • MSMQ Explorer does not run on Windows XP or Windows 2000 computers.
  • There are no tools that allow you to manage an MSMQ 1.0 enterprise from a Windows XP or Windows 2000 computer.


Best practices

The following list represents some best practices for Message Queuing. You should implement these practices wherever possible.

  • Meet all requirements before installing or upgrading Message Queuing.

    There are a number of requirements that must be met and permissions that must be granted before you can successfully install Message Queuing in your organization. For more information, see Installation overview for Message Queuing.

    If you are upgrading from MSMQ 1.0, you must meet several additional requirements and consider several other issues before you can successfully upgrade Message Queuing in your organization. For example, you must upgrade your MSMQ 1.0 controller servers in a particular order. For more information, see Upgrade requirements and considerations for Message Queuing.

  • Install Message Queuing servers in every Windows 2000 site.

    You should install at least one Message Queuing server with routing enabled in every Windows 2000 site in your forest. This is to ensure the following:

    • That messages will be able to reach their destination between sites.
    • That the broadcast request generated by independent clients during automatic site recognition will be answered.

    In addition, to enable MSMQ 1.0 clients running on Windows NT 4.0, Windows 98, or Windows 95 computers to communicate with Message Queuing servers, there must be at least one domain controller running Message Queuing 2.0 that is configured as a Global Catalog server from the domain of each such client in a Windows 2000 site containing such clients.

    The first domain controller in a Windows 2000 forest is automatically configured as a Global Catalog server.

  • Do not install a Message Queuing server with routing on a domain controller.

    If you need Message Queuing servers that provide both message routing services and access to Active Directory (for example, in a mixed-mode environment), install these servers on different computers. For example, install a Message Queuing server with routing enabled on a non-domain controller, and install a Message Queuing server on another Windows 2000 domain controller to provide access to Message Queuing objects in Active Directory.

  • Install Message Queuing servers on multiple domain controllers.

    For increased fault tolerance, performance, and scalability, you should install Message Queuing servers on multiple Windows 2000 domain controllers in each Windows 2000 domain.

  • Use routing links to connect all sites.

    All sites should be connected by routing links to all other sites. Routing links can have any number of site gates, which are Message Queuing servers configured to route messages between sites, or no site gate at all.

    For more information, see Intersite routing.

    A routing link should be created to every new Windows 2000 site that is created.

  • Use multiple in-routing and out-routing servers within a site.

    Configure Message Queuing clients to use in-routing and out-routing servers for message routing. In-routing and out-routing servers are Message Queuing servers that have been assigned to route messages within the same site.

    Because Message Queuing clients rely on in-routing and out-routing servers for sending and receiving messages, you should configure each client to use more than one server. Up to three Message Queuing servers can be assigned per client for use as in-routing or out-routing servers. For more information, see Intrasite routing.

    • In this context, Message Queuing client refers to independent clients and Message Queuing servers that do not have routing enabled. Dependent clients cannot use in-routing or out-routing servers.

  • Use a remote access server for remote clients.

    To reduce operating costs and increase performance, you should install a remote access server on at least one Message Queuing server in each site. While it is possible to configure Message Queuing clients to connect to your network through a remote access server at any site, this configuration does not provide the same benefits. In addition, such clients must not be configured to use the NetBEUI protocol when using remote access. For more information, see Using remote access with clients.

  • Avoid deploying dependent clients.

    Because of several limitations with using dependent clients, it is recommended that you deploy independent clients rather than dependent clients wherever practical. For more information, see Dependent client considerations.

    If you must use dependent clients, the supporting Message Queuing server should be located in the same site as the dependent client. This will improve messaging performance for the dependent client.

  • Backup your message and log files regularly.

    For increased reliability, use the message backup and restore utility that is included with Message Queuing to back up the folders where messaging and other program files are stored. This will allow you to restore message files if a hard disk fails. For more information, see Backing up and restoring messages.

  • Do not stop the Message Queuing service.

    Do not stop the Message Queuing service on a computer unless absolutely necessary. Otherwise, all express messages will be lost. In addition, in a mixed-mode domain environment, where the Windows NT 4.0 primary enterprise controller (PEC) has been upgraded to a Windows 2000 domain controller configured as a Global Catalog server with Message Queuing running on it, but at least one MSMQ 1.0 controller server remains, the upgraded PEC computer requires that this service, as well as the Message Queuing replication service, run at all times in order to replicate information to the MSMQ 1.0 controller servers.

  • Store message files on several high-performance disks.

    For increased messaging performance, you should store the various files used to implement messaging on several physical disks. 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 dedicated to Message Queuing. For more information, see Number of disks.

    For the best messaging performance, use high-performance disks that utilize hardware striping and write-through disk controllers. For more information, see Disk type.

    • In addition, because the NTFS file system for Windows 2000 provides more reliable file recovery after a power failure or system crash, it is the recommended file system for Message Queuing servers.

  • Do not use journaling unless needed.

    Journaling can use up disk space quickly. If you must use journaling, to increase messaging performance, you should purge messages in all journals and dead-letter queues often. For information on how to perform this task, see Purge all messages in a queue.

  • Do not exceed more than 80 to 90% of the theoretical message storage maximum per computer.

    The theoretical message storage capacity on a computer is limited by the amount of RAM, the total disk storage capacity, the number of accumulated messages currently stored in the computer, and the version of Message Queuing running on the computer. In terms of the number of messages stored, the limit for a computer running the current version of Message Queuing with more than 512 MB of RAM is about 5 million messages. At the same time, the maximum disk space allocated for a single message is 4 MB. Multiplying the maximum number of messages stored by the maximum storage size of a single message reveals that the theoretical maximum number of bytes that can be stored on a single computer can exceed 1 terabyte. However, there is disk storage overhead associated with the use of Message Queuing that must be taken into account. Therefore, it is recommended that you do not utilize more than approximately 80 to 90% of the theoretical message storage maximum for each computer.

  • Do not store more express messages than physical RAM can hold.

    To minimize use of the Windows XP paging file and thereby increase messaging performance, do not store more express messages than physical RAM can hold.

    For more information, see Memory considerations.

  • Avoid changing the Message Queuing service account.

    The Message Queuing service runs under the LocalSystem account by default. You should not change the account that the Message Queuing service runs on unless absolutely necessary. For more information, see Message Queuing service account considerations.

  • Renew cryptographic keys regularly.

    To increase security, you should renew cryptographic keys on computers periodically, such as once a year. You should also renew cryptographic keys any time you suspect they have been compromised. For information on how to perform this task, see Renew cryptographic keys for Message Queuing.


How to...

  • Install Message Queuing
  • Administer a Message Queuing network
  • Administer Message Queuing computers
  • Administer security for Message Queuing
  • Administer queues for Message Queuing
  • Administer distribution lists for Message Queuing
  • Administer messages for Message Queuing
  • Administer triggers for Message Queuing
  • Monitor and test Message Queuing


Install Message Queuing

  • Configure a domain controller as a Global Catalog server
  • Make a domain controller trusted for delegation
  • Set install permissions for MSMQ 1.0
  • Install independent clients
  • Install dependent clients
  • 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.

      3. 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

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • Each 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 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) or primary site controller (PSC) is migrated, it is automatically promoted to a domain controller configured as a Global Catalog server.

Related Topics


Make a domain controller trusted for delegation

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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • If this property is disabled for a domain controller, the Message Queuing service cannot run.


Set install permissions for MSMQ 1.0

To set install permissions for MSMQ 1.0

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

      3. Where?

      • Active Directory Users and Computers
      • YourDomain
      • YourOrganizationalUnit (such as Computers or Domain Controllers)
  3. Click Delegate control to start the Delegation of Control Wizard, and then click Next.
  4. On the Group or User Selection page, click Add.
  5. On the Select Computers or Groups page, do the following:
    • To allow authenticated users permission to install Message Queuing, under Name, type:

      Authenticated Users

      Then click OK.
    • To allow everyone permission to install Message Queuing, under Name, type:

      Everyone

      Then click OK.
  6. On the Users or Groups page, click Next.
  7. 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.
  8. On the Permissions page, under Show these permissions, click to clear the General check box and then select the Creation/deletion of specific child objects check box.
  9. Under Permissions, select the Create MSMQ Configuration objects check box, select the Delete MSMQ Configuration objects check box, click Next, and then click Finish.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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 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 grayed.
  • The Delete MSMQ Configuration Objects permission is required to uninstall Message Queuing.


Install independent clients

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 Message Queuing check box.
  4. If you do not want to install one or more of the optional subcomponents that are installed by default, do the following.
    • Click Details to open the Message Queuing page.
    • If the computer belongs to a domain and you want it to operate in workgroup mode, clear the Active Directory Integration check box.
    • If you do not want to install Message Queuing Triggers, clear the Triggers check box.
    • If you do not intend to send messages by HTTP transport, clear the MSMQ HTTP Support check box.
    • Click OK.
  5. Click Next.
  6. If prompted, type the DNS or NetBIOS name of a Windows 2000 domain controller or of an MSMQ 1.0 PEC or PSC in the local site.
  7. Follow the remaining instructions in the wizard.
  8. If prompted about restarting your computer now, 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 computers: Core, Local Storage, Active Directory Integration, Triggers, and MSMQ HTTP Support. When you create a dependent client, you install only the Core subcomponent.
  • Only independent clients can be installed on computers running Windows XP Professional.
  • If a domain controller cannot be accessed or does not exist in the local site or in a nearby site, you can still install an independent client if you restart Setup and clear the Active Directory Integration check box. Message Queuing will be installed in a mode of operation that does not allow access to public queues and requires direct connectivity to send messages. 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 2000 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 non-Windows XP computer.


Install dependent clients

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 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.
  7. When prompted about restarting 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 computers: Core, Local Storage, Active Directory Integration, Triggers, and MSMQ HTTP Support. When you create a dependent client, you install only the Core subcomponent.
  • 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 either specify another Message Queuing server or click Cancel. If you click Cancel, Setup will still complete successfully. Using this feature, you can install a dependent client before you install its supporting Message Queuing server.
  • To enable a Message Queuing server on a Windows 2000 domain controller to act as a supporting server for a dependent client, you must perform the following procedure to change the security configuration of the Microsoft Distributed Transaction Coordinator (DTC):
    1. Stop all Message Queuing services.
    2. Open Component Services.
    3. In the console tree, click Component Services.
    4. On the toolbar, click the Configure My Computer button.
    5. In the My Computer dialog box, click the MSDTC tab.
    6. On the MSDTC page, click Stop to stop the Microsoft Distributed Transaction Coordinator (DTC), and then click Security Configuration.
    7. In the Security Configuration dialog box, select the Network DTC Access check box and then the Network Transactions check box, and click OK.
    8. In the My Computer dialog box, click Start to restart the DTC, and then click OK.
    9. Restart the Message Queuing services that were stopped in Step 1.
  • Dependent clients cannot be installed on computers in workgroup mode or on 64-bit computers.
  • New Windows XP 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.


Uninstall Message Queuing

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, click to 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, you should 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.


Administer a Message Queuing network

  • Create routing links
  • Change the cost for a routing link
  • Change the site gates for a routing link
  • Create foreign sites
  • Add foreign computers to a site


Create routing links

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.

      4. Where?

      • Active Directory Sites and Services
      • Services
      • MsmqServices
  4. Point to New and then click 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 Link cost, change the cost if necessary.
  7. In Description, type a descriptive name for the routing link.

Notes

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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. You should 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.


Change the cost for a routing link

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.

      4. 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 Link cost, specify a new cost.

Notes

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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. You should 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.


Change the site gates for a routing link

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.

      4. 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

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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 at all.
  • 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.


Create foreign sites

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.

      4. 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

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • This procedure can be performed only by users with domain administrative permissions.
  • A routing link defines the route for connectivity between any two sites, including a foreign site and a non-foreign site, 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 (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 2000 Message Queuing (non-foreign) site that contains a Message Queuing server running a connector application (see Related Topics).
    2. Define this Message Queuing server as a site gate for the routing link (see Related Topics).
    3. Open Active Directory Users and Computers.
    4. In the console tree, right-click the msmq object of the computer running the connector application.
    5. Click Properties.
    6. 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 thereby 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.


Add foreign computers to a site

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.

      4. 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, and 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

  • You can start Active Directory Sites and Services and Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-ins installed. The Active Directory Sites and Services and Active Directory Users and Computers snap-ins are not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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, 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 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.

        4. 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 thereby add it to the foreign site.
  • Messages cannot be sent over HTTP transport to foreign computers.


Administer Message Queuing computers

  • 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 limit for computers
  • Set the journal storage size limit for computers
  • Store messages on multiple disk drives
  • Set DNS properties for Message Queuing
  • Start or stop services for Message Queuing
  • Remove Message Queuing objects from Active Directory


Join a domain from a workgroup

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.

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.
  • 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.


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

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.

      4. 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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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 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.


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

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.

      4. 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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Specify a new site for mobile computers

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.
  • This task applies only to Windows XP 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. Thus, the Mobile tab appears in the Message Queuing Properties dialog box only on such computers. In all other cases, Message Queuing computers can usually automatically detect the site in which they reside. For more information see see Moving mobile computers to a new site.
  • Selecting a new site (in a Windows NT 4.0 environment) enables your computer to connect to the closest controller server and thus optimizes access to the MQIS database. You can select the new site either before disconnecting the computer from the network or after reconnecting to the network. If you set the new site before disconnecting, messages are routed to the new site while the computer is on route.
  • If the correct site is not set (in a Windows NT 4.0 environment), the Message Queuing service will attempt to access a controller server in the original site and will still be functional provided there is connectivity.


Change in-routing or out-routing servers

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.

      4. 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 and select a new Message Queuing server; 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 and select a new Message Queuing server; select none to remove the Message Queuing server used as an out-routing server.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • This task is applicable only to independent clients and Message Queuing servers without routing enabled that are installed on a non-domain 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, you should assign more than one in-routing or out-routing server per client. This provides load balancing and failure recovery.


Change the supporting server for a dependent client

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.
  • 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.
  • To enable a Message Queuing server on a Windows 2000 domain controller to act as a supporting server for a dependent client, you must perform the following procedure to change the security configuration of the Microsoft Distributed Transaction Coordinator (DTC):
    1. Stop all Message Queuing services.
    2. Open Component Services.
    3. In the console tree, click Component Services.
    4. On the toolbar, click the Configure My Computer button.
    5. In the My Computer dialog box, click the MSDTC tab.
    6. On the MSDTC page, click Stop to stop the Microsoft Distributed Transaction Coordinator (DTC), and then click Security Configuration.
    7. In the Security Configuration dialog box, select the Network DTC Access check box and then the Network Transactions check box, and click OK to return to the My Computer dialog box, click Start to restart the DTC, and then click OK.
    8. Restart the Message Queuing services that were stopped in Step 1.
  • 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 Service Pack 4 or higher installed or else transactional messaging will not function.
  • New Windows XP 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.


View the dependent client list for a server

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.

      4. 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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.
  • For information on how to change the supporting Message Queuing server for a dependent client, see Related Topics.


Set the message storage size limit for computers

To set the message storage size limit 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.

      4. 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 message queues on the selected computer.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.
  • When the message storage reaches the size limit, messages can no longer be sent to any message queues on the computer 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.


Set the journal storage size limit for computers

To set the journal storage size limit 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.

      4. 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 in kilobytes) of all journal messages that can be stored in all journals on the selected computer.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.
  • 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 sent to any journal on the computer until the cumulative size of the journal messages in all journals on that computer drops below the specified limit.
  • 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.


Store messages on multiple disk drives

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.
  • For information on using System Monitor to determine whether or not additional disk drives can improve messaging performance, see Related Topics.


Set DNS properties for Message Queuing

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.


Start or stop services for Message Queuing

To start or stop services for Message Queuing

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

      3. 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 grayed):
    • 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, the Message Queuing replication service, and the Message Queuing Triggers service.


Remove Message Queuing objects from Active Directory

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.

      4. 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.

      7. Where?

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

Notes

  • You can start Active Directory Users and Computers and Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-ins installed. The Active Directory Users and Computers and Active Directory Sites and Services snap-ins are not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Administration tools.
  • It is best to remove Message Queuing objects from Active Directory by simply uninstalling Message Queuing software from the actual computer. You should perform the procedure above only 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 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.


Administer security for Message Queuing

  • 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
  • Audit access to routing link objects
  • Authenticate MSMQ 1.0 controller servers
  • 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
  • Weaken security using ADSI Edit
  • Change the security settings for Internet Information Services


Set permissions for computer and queue objects

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.

      4. 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 user or group for access, click Add. In Name, select the applicable user or group, click Add, and then click OK. Then select the group or user that you just added and select the applicable check boxes as needed.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Set permissions for routing link objects

To set permissions for routing link objects

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

      3. Where?

      • Active Directory Sites and Services
      • Services
      • MsmqServices
  3. Right-click MsmqServices, 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 user or group for access, click Add. In Name, select the applicable user or group, click Add, and then click OK. Then select the user or group that you just created and select the applicable check boxes as needed.

Notes

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Set permissions for MSMQ Settings objects

To set permissions for MSMQ Settings objects

  1. Open Active Directory Sites and Services.
  2. In the console tree, right-click the MSMQ Settings object for the applicable server.

      3. Where?

      • Active Directory Sites and Services
      • Sites
      • YourSiteObject
      • Servers
      • YourServerObject
      • MSMQ Settings
  3. 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 user or group for access, click Add. In Name, select the applicable user or group, click Add, and then click OK

      Then select the group or user that you just added and select the applicable check boxes as needed.

Notes

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.


Set permissions for Message Queuing files

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.)
  • 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.


Set permissions for distribution lists

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).

      4. 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 Look For, select the Group and/or Users check box as appropriate, clear the remaining check boxes, and click OK. In Name, type the name of a group or user or the names of several groups or users separated by semicolons, click OK, and click OK again. Or click Advanced to search for groups or users, enter the applicable parameters, click Find Now, select the group or user, click OK, click OK again, and click OK a third time.

      Then select the group or user that you just added and select the applicable check boxes as needed.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a computer that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • Message Queuing distribution lists are distribution group objects in Active Directory.


Change ownership of computer and queue objects

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.

      4. 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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • By default, the computer object is the owner of the msmq object. You use this procedure to change the ownership of the msmq object or queue object.
  • When a local user (a user not logged on to a Windows 2000 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.


Change the Message Queuing service account

To change the Message Queuing service account

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

      3. 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.
  • The Message Queuing service runs under the LocalSystem account by default. You should change the Message Queuing service to run under a user account if your administrative policy prohibits you from running services under the LocalSystem account.
  • 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.


Audit access to computer and queue objects

To audit access to 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 audit access to a computer (an msmq object), in the console tree, right-click msmq.

      4. 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 User, Computer, or Group dialog box, in Name, click a user or group for which you want to audit access, and then click OK.
  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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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 cannot be used to audit access to a private queue on a remote computer.
  • Before you perform this task, you must first enable access auditing by establishing an audit policy for the local computer.


Audit access to routing link objects

To audit access to routing link objects

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

      4. 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 User, Computer, or Group dialog box, in Name, click a user or group for which you want to audit access, and then click OK.
  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

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.
  • Before you perform this task, you must first enable access auditing by establishing an audit policy for the local computer.


Authenticate MSMQ 1.0 controller servers

To authenticate MSMQ 1.0 controller servers

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

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
  3. Click Properties.
  4. On the Service Security page of the Message Queuing Properties dialog box, click Use secured connections if communicating with an MSMQ controller server running Windows NT 4.0, and then click Certification Authorities.
  5. In the Certification Authorities dialog box, click System Certificates.
  6. When prompted, click Yes.
  7. Click to clear those certification authorities that you do not want to use or do not trust for secured communications and then click OK.

Notes

  • To open Computer Management, right-click My Computer and then click Manage.
  • This procedure is applicable only for clients running Windows 2000 that communicate with MSMQ 1.0 controller servers running Windows NT 4.0.


Register certificates for Message Queuing

To register certificates for Message Queuing

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

      3. 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 registered certificate for the local computer is removed using a remote computer, the certificate is removed from Active Directory, but will still exist on the local computer.


Remove certificates for Message Queuing

To remove certificates for Message Queuing

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

      3. 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.
  • 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.


View certificates for Message Queuing

To view certificates for Message Queuing

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

      3. 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.
  • You can view all user certificates that are registered in Active Directory.


Renew certificates for Message Queuing

To renew certificates for Message Queuing

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

      3. 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.
  • Only the user who installed Message Queuing can renew the internal certificate. If Message Queuing was installed in workgroup mode and the computer subsequently joined a domain, only a domain administrator can renew the internal certificate.
  • When the certificate is successfully renewed, a message appears stating that the internal certificate was successfully renewed and registered in Active Directory.


Renew cryptographic keys for Message Queuing

To renew cryptographic keys for Message Queuing

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

      3. 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.

    A warning appears stating that incoming 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.

  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.
  6. When prompted to restart Windows, click Restart Now.

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.


Weaken security using ADSI Edit

To weaken security using ADSI Edit

  1. Click Start, point to All Programs, point to Windows XP Support Tools, point to Tools, and then click ADSI Edit.
  2. In the console tree, right-click CN=MsmqServices.

      3. Where?

      • Configuration Container
      • CN=Configuration,...
      • CN=Services
      • CN=MsmqServices
  3. Click Properties.
  4. On the Attributes page, in Select a property to view, click the arrow that opens the list and select MSMQNameStyle.
  5. In Edit Attribute, enter TRUE to weaken security. Or, enter FALSE to tighten security.
  6. Click Set, and then click OK.

Notes

  • Windows XP Support Tools, which is provided on the Windows XP compact disc, must be installed before you can use ADSI Edit. To install these tools, perform the following steps:
    1. Insert the Windows XP CD into your CD-ROM drive.
    2. Open the Support folder, and then open the Tools folder.
    3. Double-click Setup.
    4. Follow the instructions that appear in the Windows XP Support Tools Setup Wizard.
  • This procedure is used to weaken Active Directory security in order to support MSMQ 1.0 users, Message Queuing 2.0 clients logged on with local user accounts, and certain operating configurations.
  • 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 Message Queuing servers running on Windows 2000 domain controllers.


Change the security settings for Internet Information Services

To change the security settings for Internet Information Services

  1. Click Start, click Run, type:

    mmc

    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 Default Web Site.

      5. Where?

      • Console Root
      • Internet Information Services
      • YourComputer
      • Default Web Site
  5. Click Properties and then click the Directory Security tab.
  6. Under Anonymous access and authentication control, click Edit.
  7. Deselect the Anonymous access check box. Or, next to Account used for anonymous access, click Edit, type the name of a domain user, and click OK.
  8. Click OK and then click OK again.
  9. Click Start, click Run, type:

    net stop iisadmin

    Then press ENTER.
  10. Click Start, click Run, type:

    net start smtpsvc

    Then press ENTER.
  11. Type:

    y

    Then press ENTER.
  12. Click Start, click Run, type:

    net start w3svc

    Then press ENTER.
  13. Open Active Directory Users and Computers.
  14. On the View menu, click Users, Groups, and Computers as containers and then click Advanced Features.
  15. In the console tree, right-click the name of your computer.

      16. Where?

      • Active Directory Users and Computers
      • YourDomain
      • Computers
      • YourComputer
  16. Click Properties.
  17. On the General page, select the Trust computer for delegation check box and then click OK.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • By default, Internet Information Services (IIS) uses a local user account, which is treated as an anonymous user account by other computers in the network. Active Server Page (ASP) applications and scripts run under IIS and thus impersonate the anonymous user when they send queries to Active Directory. Because anonymous users no longer belong to the Everyone group in Windows XP, these queries fail, and ASP applications and scripts cannot locate, create, or delete queues. This procedure makes IIS run under the domain user account of the user logged onto the computer where IIS is running or under a specified domain user account.
  • In order for the changes to take effect, you must stop and start the IIS admin service. Stopping this service also stops the World Wide Web Publishing and Simple Mail Transport Protocol (SMTP) services, which depend on it. Starting the World Wide Web Publishing and Simple Mail Transport Protocol (SMTP) services automatically starts the IIS admin service.
  • Trusting the computer for delegation allows multiple hops to communicate with a domain controller.


Administer queues for Message Queuing

  • Create queues
  • Find queues
  • Delete queues
  • Take outgoing queues offline
  • Pause or resume an outgoing queue
  • Change queue labels
  • Change queue type IDs
  • Change the base priority of queues
  • Enable or disable target journaling
  • Set the journal storage size limit for queues
  • Set the message storage size limit for queues
  • Allow only authenticated messages on queues
  • Change the privacy level for queues
  • Specify or view queue multicast addresses and ports
  • Manage queues and messages on other computers
  • Manage queues and messages using Active Directory Users and Computers


Create queues

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.


Find queues

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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Delete queues

To delete queues

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

      3. 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.


Take outgoing queues offline

To take outgoing queues offline

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

      3. 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.


Pause or resume an outgoing queue

To pause or resume an outgoing queue

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

      3. 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.


Change queue labels

To change queue labels

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

      3. 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.


Change queue type IDs

To change queue type IDs

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

      3. 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.


Change the base priority of queues

To change the base priority of queues

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

      3. 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 or DOWN ARROW 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.


Enable or disable target journaling

To enable or disable target journaling

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

      3. 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.


Set the journal storage size limit for queues

To set the journal storage size limit for queues

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

      3. 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 sent to 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.


Set the message storage size limit for queues

To set the message storage size limit for queues

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

      3. 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.
  • 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 is reached, messages can no longer be sent to the queue until the cumulative size of messages in the queue drops below the specified limit.
  • 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.


Allow only authenticated messages on queues

To allow only authenticated messages on queues

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

      3. 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.


Change the privacy level for queues

To change the privacy level for queues

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

      3. 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.


Specify or view queue multicast addresses and ports

To specify or view queue multicast addresses and ports

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

      3. 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. In domain mode, a domain controller that supports multicast addresses in Active Directory 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.


Manage queues and messages on other computers

To manage queues and 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 queues and messages, and then click OK.
  4. Perform the desired task just 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.


Manage queues and messages using Active Directory Users and Computers

To manage queues and 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 queue or message.

      4. 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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Administer distribution lists for Message Queuing

  • 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

To create distribution lists

  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 Users.

      4. Where?

      • Active Directory Users and Computers
      • YourDomain
      • Users
  4. Point to New, and click Group.
  5. In the New Object - Group dialog box, type the name of the distribution list under Group Name, select Global or Domain local, and select Distribution.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a computer that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • Message Queuing distribution lists are distribution group objects in Active Directory.
  • When you create a distribution list (group) in Active Direcotry, 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.


View, add, or delete elements in a distribution list

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

  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 distribution list (group).

      4. Where?

      • Active Directory Users and Computers
      • YourDomain
      • Users
      • YourDistributionList(Group)
  4. Click Properties.
  5. 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) by clicking the applicable element (member), clicking Remove, and then clicking OK.
  6. 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 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 click OK a third time.
  7. 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 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 click OK a third time.
  8. 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 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 click OK a third time.
  9. 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 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 click OK a third time.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a computer that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


View or change properties of distribution lists

To view or change properties of distribution lists

  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 distribution list (group).

      4. Where?

      • Active Directory Users and Computers
      • YourDomain
      • Users
      • YourDistributionList(Group)
  4. Click Properties.
  5. View or change the distribution list (group) properties as needed.
    6. 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) in which the applicable distribution list (group) is a member | Member of
Administrative permissions | Security

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a computer that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.
  • The group type for a distribution list must be "Distribution."
  • The group scope for a distribution list can be "Global" or "Domain local."


Get a list of distribution lists containing a given element

To get a list of distribution lists containing a given element

  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, do one of the following:
    • Right-click the applicable distribution list (group).

        • Where?

        • Active Directory Users and Computers
        • YourDomain
        • Users
        • 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
  4. Click Properties.
  5. 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 by clicking the name of the host distribution list (group) and then clicking Remove.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a computer that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Delete distribution lists

To delete distribution lists

  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 Users.

      4. Where?

      • Active Directory Users and Computers
      • your_domain
      • Users
  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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a computer that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Administer messages for Message Queuing

  • View message properties
  • Change the message property columns displayed
  • Purge all messages in a queue
  • Set the default lifetime for messages


View message properties

To view message properties

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

      3. 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.


Change the message property columns displayed

To change the message property columns displayed

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

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • YourQueueFolder (such as Public Queues or Private Queues)
      • YourQueue
      • Queue messages
        Journal messages
  3. Point to View and then click Add/Remove Columns.
  4. In the Add/Remove Columns dialog box, make the changes that you want:
    • To add a message property column, in Available columns, click an entry and then click Add.
    • To remove an existing message property column, in Displayed columns, click the applicable entry and then click Remove.
    • To change the order in which message property columns appear, in Displayed columns, click an entry and click Move Up or Move Down to move the column to the left or right, as needed.
  5. Repeat step 4 for any other columns that you want to change.

Notes

  • To open Computer Management, right-click My Computer and then click Manage.
  • The results of this procedure can be seen in the details pane. Messages can also be sorted according to a specific message property by clicking on the applicable column. To reverse the sort order, click the column heading a second time.
  • You can also perform this task in the Active Directory Users and Computers snap-in. For more information, see Related Topics.


Purge all messages in a queue

To purge all messages in a queue

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

      3. 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 should 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.


Set the default lifetime for messages

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.

      4. 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

  • You can start Active Directory Sites and Services by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Sites and Services snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • The default lifetime of a message is also known as the time-to-reach-queue (TTRQ).


Administer triggers for Message Queuing

  • 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


Create triggers

To create triggers

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

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • Message Queuing Triggers
      • 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, click Existing rules if you want to attach an existing rule to the new trigger. On the Existing Rules dialog box, in Rule list, select an existing rule or rules to attach, click Attach for each rule selected, and click Close to return to the second page of the New Trigger dialog box. You can use the Up and Down buttons to change the order in which the rules are tested or click Detach to disassociate the selected rule from the trigger. 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.
  • 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 by right-clicking Triggers, pointing to New, and then clicking 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 Message Queuing Triggers folder. By default, for each trigger, the details pane displays the name of the monitored queue and the number of rules associated with it as well as indicating whether the trigger is enabled and whether it is serialized.
  • 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 as well as 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. It is recommended that you use only a single trigger with the serialized option because the order of trigger firing is random with respect to their GUIDs.
  • After a trigger has been created, rules can be attached to it. For more information, see Related Topics.


Create and attach rules to triggers

To create and attach rules to triggers

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

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • 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 on the second page of the New Rule dialog box, enter a condition by selecting the initial string in the list box, typing the applicable final string in the 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. Under Rule action on the third page of the New Rule dialog box, specify whether the trigger will invoke a stand-alone executable or a COM component (the default) by clicking the applicable button.
  9. For a COM component, in COM component ProgID, type the ID of the COM component, and in Method name, type the name of the method.
  10. For a stand-alone executable, in Executable path, type the full path of the executable file and click the Interact with desktop check box if you want the application console window to appear.
  11. To add parameters for either a COM component or a stand-alone executable, click Parameters. In the Invocation Parameters dialog box, 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. 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. Then click OK to return to the third page of the New Rule dialog box, and click Finish.
  12. To attach existing rules to a trigger, do the following:
    • In the console tree, click Triggers under Message Queuing Triggers.

        • Where?

        • Computer Management
        • Services and Applications
        • Message Queuing
        • Message Queuing Triggers
        • 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 and then click Properties. Click the Attached Rules tab and then click Existing rules. On the Existing Rules page, for each rule that you want to attach, select the rule in Rule List, and click Attach. Then click Close to return to the Attached Rules page and 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. By default, for each rule, the details pane displays the name of the rule and its description and indicates whether the Interact with desktop check box is selected.
  • 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.
  • 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.


View or change properties of triggers and rules for triggers

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.

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • 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.
    5. Trigger Property | Tab or dialog box
Trigger name | 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 | Existing Rules

    Or, view or change rule properties as needed.

    Rule property | Tab or dialog box
Rule name | General
Rule description | General
Conditions applied to the rule | Conditions
Whether the rule launches a stand-alone executable or a COM component | Action
Path of a stand-alone executable | Action
COM component ProgID | Action
Method chosen for a COM component | Action
Interact with desktop | Action
Message parameters used and their order | Invocation Parameters

Notes

  • To open Computer Management, right-click My Computer and then click Manage.
  • The Properties dialog box for a specific trigger has General and Attached Rules tabs, and there is an Existing Rules dialog box, which can be accessed from the Attached Rules page. The Properties dialog box for a specific rule has General, Conditions, and Action tabs, and there is an Invocation Parameters dialog box, which can be accessed from the Action page.
  • The monitored queue of an existing trigger cannot be changed.
  • 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 Conditions 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 Action page of the Properties dialog box for the particular rule.
  • The rules displayed on the Existing Rules page 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 on the Attached Rules page. 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.


Delete triggers and rules for triggers

To delete triggers and rules for triggers

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

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • 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.


Change default configuration values for triggers

To change default configuration values for triggers

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

      3. Where?

      • Computer Management
      • Services and Applications
      • Message Queuing
      • 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. This value should 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.


Monitor and test Message Queuing

  • View Message Queuing events
  • View external transactions
  • View computer performance
  • View queue performance
  • Send test messages
  • Enable message route tracking
  • Test connectivity using MQPing


View Message Queuing events

To view Message Queuing events

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

Notes

  • To open Event Viewer, click Start, click Run, type:

    eventvwr

    Then click OK.
  • When viewing events in Event Viewer, you can sort, filter, and search for events, based on event properties.


View external transactions

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, click Transaction List.
  4. To view the statistics of external transactions, click Transaction Statistics.

Notes

  • To open the Component Services snap-in, click Start, click Run, type:

    dcomcnfg

    Then click OK.

  • The Microsoft Distributed Transaction Coordinator (DTC) must be running to implement external transactions.
  • On a Windows NT 4,0 computer, external transactions are monitored by using the MS DTC Admin Console. To open the MS DTC Admin Console on a Windows NT 4.0 computer, click Start, click Run, and type:

    dac.exe

    Then press ENTER. The status of external transactions can be viewed on the Transaction page, and their statistics can be viewed on the Statistics page.


View computer performance

To view computer performance

  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 Message Queuing Service.
  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, click Explain.
  9. Click Close.

    The monitor graphs appear in the details pane.

Notes

  • To open System Monitor, click Start, click Run, type:

    perfmon

    Then click OK.
  • 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 2000 Server help.
  • For more information on monitoring Message Queuing, see Related Topics.


View queue performance

To view queue performance

  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 click the applicable computer.
  4. In Performance object, click the arrow that opens the list and select Message Queuing 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, click Explain.
  9. Click Close.

    The monitor graph appears in the details pane.

Notes

  • To open System Monitor, click Start, click Run, type:

    perfmon

    Then click OK.
  • 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 2000 Server help.
  • For more information on monitoring Message Queuing, see Related Topics.


Send test messages

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.

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.
  • You can verify that the test messages sent 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.


Enable message route tracking

To enable message route tracking

  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.

      4. 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

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • 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.


Test connectivity using MQPing

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.

      4. Where?

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

Notes

  • You can start Active Directory Users and Computers by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-in installed. The Active Directory Users and Computers snap-in is not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. For more information, see Related Topics.
  • You can also send an MQPing message by right-clicking msmq, clicking Properties, clicking the Diagnostics tab, and then clicking 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 was successful or failed. You may need to send several MQPing messages to determine whether or not a computer is connected.


Concepts

This section provides general background information about Message Queuing.

  • Message Queuing overview
  • Understanding Message Queuing
  • Using Message Queuing
  • Resources


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.

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.

Message Queuing is of particular interest to system administrators (for installing and managing the infrastructure) and to software developers (for creating messaging applications). This documentation is written for system administrators and hence discusses only the infrastructure and features provided by the Message Queuing user interface and administration tools and not how to develop applications. For detailed information on developing Message Queuing applications, you should refer to the Message Queuing Software Development Kit (SDK), which is part of the Microsoft Platform SDK in the Microsoft Developer Network (MSDN) Library. For more information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.

Where needed for clarity, the documentation distinguishes between those features that are provided by using Message Queuing user interface and administration tools and those features that are obtained programmatically by using Message Queuing applications.

he current version of Message Queuing includes a number of terminology and administrative changes from previous versions. If you are upgrading from a previous version, see the Upgrade overview for Message Queuing for a list of changes.

Notes

  • 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. The current version of Message Queuing, which is based on the original MSMQ technology and conceptions and is supplemented with numerous new features, is offically 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.
  • 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.

Summary of features

Following is a summary of the major features of Message Queuing, divided into new features for Windows XP and legacy features from previous versions:

New features

  • Triggers. Message Queuing Triggers is now a component of the core product, 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 Message Queuing Triggers.
  • Sending messages to multiple destinations. 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 pre-Windows XP computers is provided. In addition, message delivery to IP multicast destinations using the PGM protocol is supported. For more information about these features, see Sending messages to multiple destinations.
  • Delivering messages over HTTP transport. SRMP (SOAP Reliable Messaging Protocol), an XML-based messaging protocol, has been developed for delivering high-QoS (quality of service) messages. The direct, public, and private format names of administration/response queues can be included in messages sent over HTTP transport. Similarly, the names of administration/response queues in HTTP format can be included in messages sent over ordinary (non-HTTP) transport. For more information about these features, see Delivering messages over HTTP transport. For more information on format names, see Format names.
  • Active Directory integration. Integration with, and extension of, the Active Directory 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. 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.
  • Message lookup. Message Queuing 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 Message lookup.

Legacy features

  • Mixed-mode operation. Message Queuing can operate in mixed-mode domain environments, which means that MSMQ 1.0 controller servers running on Windows NT 4.0 can communicate seamlessly with a Message Queuing server running on a Windows 2000 domain controller.
  • Integration with Windows security mechanisms. Message Queuing still supports privacy and security through the use of access control, access auditing, encryption, and message authentication. It also leverages newer security features available already in Windows 2000, such as the Kerberos V5 security protocol, for server authentication. In addition, the U.S. version of Message Queuing now supports 128-bit encryption as well as 40-bit encryption. Also, only users with the proper permissions and locally-run Message Queuing applications are allowed to create queues. For more information about security, see Security overview for Message Queuing.
  • Workgroup support. Message Queuing can be installed and run on computers belonging to a Windows XP 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 again. For more information about belonging to a workgroup or a domain, see Network topology of Message Queuing and Joining a domain from a workgroup.
  • 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.
  • 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.
  • 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 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 Message routing.
  • 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 support and connectivity to foreign computers.

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 vs. e-mail

Message Queuing is not an e-mail application and plays a different role in your organization. Message Queuing moves data between applications, using a system of queues distributed on various computers. In contrast, e-mail is an application that enables communication between people using a central post office and mail folders.

Message Queuing can, however, complement e-mail applications by allowing different clients to communicate with each other.

Some key similarities with e-mail include the following:

  • Neither technology requires recipients to be present at the time messages are sent to them. Both technologies store messages and then forward them when the recipient is available.
  • Both types of messages indicate the address of the sender and the receiver.

Some key differences from e-mail include the following:

  • The Message Queuing sender and recipient are applications, whereas an e-mail sender and recipient are generally people.
  • A Message Queuing message body is generally binary data, typically understood only by applications that process the message. An e-mail message body is generally formatted text, understood by any person who reads it.
  • A Message Queuing application does not need a computer to be online to send messages. E-mail typically needs a connection to a server or post office to send e-mail.
  • Message Queuing is optimized to provide extremely fast communication throughput in comparison with e-mail applications.
  • Message Queuing provides message prioritization, guaranteed message delivery, and acknowledgment of messages.
  • Message Queuing provides options for memory-based, disk-based, or transactional delivery of messages.


Understanding Message Queuing

This section introduces the key concepts and terminology you should know before you install and administer Message Queuing.

  • Network topology of Message Queuing
  • Message Queuing computers
  • Queue type
  • Queue names
  • Message type and delivery
  • Sending messages to multiple destinations
  • Message routing
  • Message storage
  • Message Queuing objects in Active Directory
  • Delivering messages over HTTP transport
  • Message Queuing Triggers
  • Business scenarios for Message Queuing


Network topology of Message Queuing

Message Queuing (also known as MSMQ) is a messaging infrastructure made up of computers that provide various functions and are connected in a Windows network, which may include computers running Windows XP as well as previous versions of Windows. This section discusses how Message Queuing computers are connected in such a network.

Message Queuing can be used in either a domain environment 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, while a workgroup environment does not provide such a directory service. A Message Queuing computer belonging to a domain can be configured not to access a directory service. Such a computer, like a Message Queuing computer belonging to a workgroup, is said to be operating in workgroup mode. In addition, there are other situations in which Message Queuing computers belonging to a domain will not have access to Active Directory. Such situations arise when a Message Queuing server is offline or when all the domain controllers in its site are offline. Such a computer is said to be operating in offline mode.

Domain environment

In a Windows 2000 domain environment, Windows XP computers running Message Queuing can directly access Message Queuing objects in Active Directory. On the other hand, a Windows 2000 computer running Message Queuing requires the presence of a Windows 2000 domain controller hosting a Message Queuing server in its site and its domain to access such objects in Active Directory. 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. The collection of all domains in a Windows 2000 network is called a forest.

Message Queuing can also run in a mixed-mode domain environment, which means that a domain consisting of both MSMQ 1.0 controller servers running on Windows NT 4.0 and Message Queuing servers running on Windows 2000 can communicate with each other.

Sites

In a domain environment, a Message Queuing network can be divided into different Windows 2000 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. Logical and physical structure are independent of each other, so there may be multiple domains in a single site as well as multiple sites in a single domain.

In the context of Message Queuing, a site comprises the following:

  • Windows 2000 domain controllers, which hold configuration and status information in the Active Directory directory service and replicate such information between sites using site links. Active Directory employs what is called a multi-master model, which means that any Windows 2000 domain controller can read from or write to objects stored in Active Directory.
  • Windows XP 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.

For information on the factors that determine the sites in your network, see Site considerations.

Notes

  • 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 2000 site and each foreign connected network is mapped to a foreign site. If you are upgrading from MSMQ 1.0, see Upgrade overview for Message Queuing for a list of changes.

For more information on routing links, see see Intersite routing.

Workgroup mode

Message Queuing can be run in an environment that is not part of a domain, such as a workgroup, or on a computer that is configured not to send queries regarding Message Queuing objects to Active Directory. If Message Queuing is run on a computer that is part of a workgroup, that computer can later join a Windows 2000 domain. Conversely, a Message Queuing computer can be part of a domain and then join a workgroup. Such a computer can then later rejoin the same domain.

The following restrictions exist when using Message Queuing in workgroup mode:

  • Messages sent by such computers cannot be routed by in-routing servers, out-routing servers, and site gates. Direct connectivity with the destination computer is required.
  • There is no access to Active Directory. As such, you can create and manage private queues only on a local computer, and you can view the properties of queues on another computer (but not create or modify them) using the Computer Management snap-in (for information on managing queues on remote computers, see Manage queues and messages 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 instead. For more information on user certificates, see 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 client considerations.
  • Messages cannot be sent to foreign queues or connector applications.

Offline mode

Message Queuing can run on a computer that belongs to a domain and is configured to access Active Directory but is temporarily unable to communicate with a domain controller. This occurs when the computer itself is offline or all the domain controllers in its site are offline. A similar situation arises when an attempt is made to access a remote computer (for example, for viewing files) 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.

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 on the various types of format names, see Format names.

Cross-platform support and connectivity to foreign computers

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, and Message Queuing Connector (MQC), which allows connectivity with computers running Message Queuing on non-Windows-based platforms.

Microsoft MSMQ-MQSeries Bridge extends the functionality of Message Queuing to provide seamless, transactional connectivity with IBM MQSeries Version 2 and Version 5 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/).

Message Queuing Connector (MQC) can be used to extend the functionality of Message Queuing to other non-Windows-based operating systems, including UNIX, AS/400, Tandem, Digital VMS, CICS/MVS and Unisys ClearPath HMP. MQC is included on the disc sets for the Windows 2000 Server family. However, to send a message to a foreign computer running a non-Windows operating system, you must first acquire and install additional client software available from Level 8 systems onto your foreign computers for a complete solution. For more information on Level 8 Systems products, contact Level 8 Systems or refer to the Level 8 Systems Web site (http://www.level8.com/index.cfm?handle=gmq).

These products can be used in conjunction with each other to provide organization-wide connectivity. For example, you can send messages between a UNIX computer running Message Queuing and an AS/4000 computer running IBM MQSeries.

For more information on implementing messaging with foreign computers, see Configuring foreign sites and foreign computers.


Message Queuing computers

Message Queuing computers connected in a network can have different functionality, depending on the software subcomponents installed on them. This section discusses the software subcomponents for Message Queuing in the context of the types of Message Queuing computers created by installing them. For more information on the all Message Queuing subcomponents and their installation, see Installation overview for Message Queuing.

Message Queuing servers

Message Queuing servers provide the backbone for communications in your Message Queuing network. All Message Queuing servers run the Message Queuing service, host queues, store messages locally, and can send and receive messages by default.

For planning information for Message Queuing servers in your network, see Selecting Message Queuing server hardware.

Message Queuing servers can also provide directory service access to pre-Windows XP clients and routing. These additional services are discussed in the next two sections.

Directory access

Message Queuing servers installed on Windows 2000 domain controllers provide the capability of viewing or changing information listed in Active Directory to pre-Windows XP clients by default. Windows XP clients can access Active Directory directly without the aid of a Message Queuing server.

For general information on Windows 2000 domain controllers, see "Domain controllers" in the Windows 2000 Server help.

Routing services

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 at all.

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.

Message Queuing computers in clusters

The Message Queuing service as well as Message Queuing Triggers can be implemented in clusters. 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 between clusters created by the Cluster service, which are called server clusters and have the additional capability of providing fault tolerance through failover, and clusters created by Network Load Balancing (NLB), which are known as NLB clusters and do not have failover capabilities.

NLB clusters for Message Queuing

The second type of cluster within which Message Queuing services can be implemented is a Network Load Balancing (NLB) cluster. NLB 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, NLB distributes incoming TCP/IP traffic between multiple Internet Information Services (IIS) servers, which comprise a Web farm. NLB can combine up to 32 servers running Windows 2000 Advanced Server or Datacenter Server into a single load-balancing cluster. Servers can be added without shutting down the cluster.

The heart of NLB 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, NLB 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.

NLB 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. NLB 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 NLB, 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 NLB 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 via a lightweight nonpersistent duplicate removal mechanism.

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 re-sent 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 a NLB cluster to receive and process messages sent to the cluster.

Similar Web farms can also be implemented using DNS round-robin distribution, Cisco's LocalDirector, and network address translation (NAT).

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. Nevertheless, round-robin distribution can be a useful starting point or a low-cost alternative for small groups of servers. If you are using round-robin distribution, you should closely monitor your servers so that you can quickly remove any failed machines from the distribution list.

LocalDirector

LocalDirector is a hardware-based solution from Cisco Systems with an embedded operating system that can load balance incoming HTTP requests. LocalDirector listens for incoming requests on a single virtual IP address and is able to redirect them across a set of IIS servers. Each physical server in the Web farm has its own unique IP address. However, unlike the load balancing techniques discussed earlier, the IP addresses of the physical servers are never seen by users. Load balancing is performed every time a request comes in across the virtual IP address. This is a style known as request-based load balancing.

The functional details of NLB and LocalDirector are very different, but they produce the same results. Each user makes a request for virtual IP address, and the request is routed to one of many servers in a Web farm. Both NLB and LocalDirector provide effective request-based load balancing that has many advantages over session-based solutions. Request-based load balancing is more granular because the load balancing algorithm is run far more frequently. This results in a more even distribution of requests across servers.

Request-based load balancing also provides higher levels of fault tolerance. With either NLB or LocalDirector, you can issue a command to take a server offline. This allows you to perform maintenance or to upgrade each server in the Web farm without an interruption in service. Both solutions can also detect when a server has failed and avoid directing future requests to an unavailable IP address.

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.

Independent clients

Independent clients run the Message Queuing service, host queues, send and receive messages, and can operate while disconnected from the network by default. Independent clients do not require synchronous access to a Message Queuing server to send or receive messages. The primary difference between independent clients and Message Queuing servers is that independent clients do not provide Active Directory access or the message routing capability of Message Queuing servers that have routing enabled.

An independent client and a Message Queuing server that does not have routing enabled provide similar functionality. The only difference is that only independent clients can run on Windows XP Professional, while Message Queuing servers can run only on platforms from the Windows 2000 Server family. For this discussion, an independent client and a Message Queuing server without routing enabled (if installed on a non-domain controller) are functionally equivalent.

If an independent client (or equivalent Message Queuing server) 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.

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 2000 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.

A Message Queuing 3.0 computer that belongs to an 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.

If a Message Queuing independent client is operating in a mixed-mode domain environment, where it must communicate with an MSMQ 1.0 controller server running Windows NT, the following information applies: When an independent client moves to a different site, the client can automatically recognize the new site in which it resides. Upon reconnecting to the network, the client sends out a broadcast message and monitors all the replies to that broadcast. If a Message Queuing server other than the one assigned to the client in the original site replies and if that new server can communicate with a server in the original site of the client, the client connects to and uses the new site. If one of the servers that replies is an assigned server in the original site of the client, the independent client does not connect to the new site.

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 2000 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 or received by computers running other messaging systems.

Dependent clients

Dependent clients require synchronous access to a Message Queuing server, called a supporting server, for all messaging functions. 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. 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 unable to send and receiver messages.

New Windows XP 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 and multiple-element format names are not supported for dependent clients.

Dependent clients will no longer be supported in future versions of Message Queuing.

Because of these and other limitations, it is recommended that you deploy independent clients rather than dependent clients in your organization wherever practical. For more information, see Dependent client considerations.

MSMQ RPC transport provider

The MSMQ remote procedure call (RPC) transport provider was supported by the previous versions of Message Queuing for Windows NT 4.0 and Windows 2000. It is no longer supported in Windows XP.

MSMQ Exchange Connector

The MSMQ Exchange Connector was supported by the previous versions of Message Queuing for Windows NT 4.0 and Windows 2000. It is no longer supported in Windows XP.


Queue type

In the context of Message Queuing, queues are temporary storage locations for different types of messages. The following sections describe the various types and purposes of Message Queuing queues. For information on the format names used for these types of queues, see Queue names.

Public queues

In a domain environment, public queues are queues that are published in Active Directory and hence are replicated throughout your Windows 2000 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.

Public queues are not accessible in a workgroup environment.

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 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.

Journals

The process of storing copies of messages is called journaling. These copies, called journal messages, are stored in queues of a special type, called journals. These include the computer journal in the case of source journaling or in queue journals in the case of target journaling.

Source journaling

Source journaling is the process of storing copies of outgoing nontransactional 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 is disabled by default.

When source journaling is enabled for a nontransactional message, 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.

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 it is enabled, a copy of each message reaching the applicable queue is transferred to the corresponding queue journal when the message is received (removed by a Message Queuing application).

There is, however, no guarantee that all incoming messages will be placed in a queue journal when they are received. For example, if the storage size limit, or quota, for a queue journal is exceeded, then after additional messages are successfully retrieved (removed) from the corresponding queue, no copies of those messages will be in the queue journal, and they will be lost forever.

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.

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.

Administration queues

Administration queues store acknowledgment messages and are specified programmatically in the original messages by the sending application. Any available nontransactional queue can be specified as an administration queue. Multiple administration queues can be specified with distribution lists, multiple-element format names, and IP multicast addresses.

Administration queues do not contain administrative messages, which are stored in internal private queues.

For more information on acknowledgment messages, see Message type.

Response queues

Response queues store response messages that are sent back to the sending application by the receiving application. Response queues are specified programmatically by the sending application when a message is sent. Any available queue can be specified as a response queue.

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.

Response messages are not the same as administrative response messages, which are stored in an internal private queue.

Report queues

Report queues store report messages, which 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. 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.

Internal private queues

Message Queuing uses up to seven standard internal private queues as well as additional internal private queues that serve as interim queues for storing and forwarding messages in transit to a destination queue. Being private queues, none of these queues is published in Active Directory. In addition, they are not listed in the Private Queues folder in the MMC snap-ins, and any information on these queues and their contents can be obtained only programmatically. You cannot delete internal private queues.

The following table describes each of the standard internal private queues and how it is used:

Internal private queue | Use
admin_queue$ | Storing administrative messages.
msmqadminresp | Storing administrative response messages (except MQPing messages).
mqis_queue$ | Storing returned MQPing messages and responses to write requests made by the Message Queuing replication service or by the Message Queuing directory service on computers with no replication service in a mixed-mode environment.
msmqtriggersnotifications | Storing messages which notify the Triggers service (mqtgsvc.exe) that triggers or rules have been created or modified by mqtrig.dll. Messages stored in this queue are deleted after processing.
notify_queue$ | Storing notification messages. These messages list computer and queue property changes, including creation and deletion of queues.
nt5pec_mqis_queue$ | Storing responses to write requests made by the Message Queuing directory service on computers running the Message Queuing replication service, such as a former primary enterprise controller (PEC), in a mixed-mode environment.
order_queue$ | Tracking transactional messages that require in-order delivery.

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.

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 Messaging Queuing environment.

For more information on communicating with foreign computers, see Cross-platform support and connectivity to foreign computers.


Queue names

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

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 or .\QueueName for a public queue located on the local computer. 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 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 and to send messages to computers on the Internet as well as to send messages directly to a computer.

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:

DIRECT=ComputerAddress\PublicQueueName
DIRECT=ComputerAddress\PRIVATE$\QueueName
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 (including the network protocol, TCP) or as any name for the target computer that is supported natively by the underlying operating system (OS is used to indicate that the computer's native protocol should 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. HTTP format names can use forward slashes or backslashes to separate their components (other format names require backslashes). For example, the following two format names can be used to reference "MyPublicQueue".

DIRECT=HTTP://URL_Address/msmq/MyPublicQueue
DIRECT=HTTP://URL_Address\msmq\MyPublicQueue

Public format names

Public format names are used to reference public queues. Public queues can also be referenced by direct format names. 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 which are bound to a specific location.

Private format names

Private format names are used to reference private queues. Private queues can also be referenced by direct format names. 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 on 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

A distribution list format name can be an element of a multiple-element format name, and, 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, you should refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.


Message type and delivery

In the context of Message Queuing, messages consist of a body and a set of properties. Messages 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.

Messages can be authenticated as well as encrypted. For information on message authentication, see Message authentication. For information on message encryption, see Encryption for Message Queuing.

Messages can be differentiated according to type, priority, and delivery method. The following sections discuss these concepts.

Message type

Message type, also called message class, indicates 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/or 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 or did not reach the target queue for a specified reason and/or 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 Queue type.

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 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 Queuing applications set the message priority for nontransactional messages in the range from 0 to 7, where 7 represents the highest priority. The message priority for transactional messages is always equal to the default value (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

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 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

Transactional messages are messages that are sent or received within a transaction. A transaction is an action or a series of actions that transform a system from one consistent state to another. 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.

In Message Queuing, a transaction can encompass only one unit of work, such as sending messages or receiving messages. Thus, the same message cannot be sent and received within a single transaction.

All Message Queuing transactions require execution of the two-phase commit protocol. Consider, for example, a simple messaging transaction consisting of all the actions that must be performed when a sending application sends a single message to a destination queue. In the first phase, Message Queuing verifies whether or not all of these actions can be completed. If all the actions can be completed, Message Queuing commits the transaction and sends the message to the queue. Otherwise, if any of the actions cannot be completed, Message Queuing aborts the transaction and undoes any effects of the transaction. When the transaction is committed, the message is "queued" for delivery. Ultimately, the message is delivered to the destination queue exactly once.

A transaction can also consist of sending multiple messages. In this case, 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.

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 identifying the preceding message in the same message stream. 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.

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 (two-phase) transactions, which are coordinated by the Microsoft Distributed Transaction Coordinator (DTC), which is now part of Component Services (formerly known as Transaction Server). The DTC is automatically installed on each computer during Message Queuing Setup.
  • As internal (single-phase) transactions, which are coordinated by Message Queuing.

External transactions are used if resources other than those that Message Queuing can provide need to be part of the transaction. 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).

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.

Because they have less overhead, internal transactions execute much faster than external transactions coordinated by the DTC. You should 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.

For more information on the Microsoft DTC, see Using Component Services.

When transactional messages are sent over HTTP transport from the internal network of an organization to the Internet, the sender's local order queue must be mapped to an external name in order to direct the order acknowledgment messages from the recipients to the proper destination.


Sending messages to multiple destinations

The one-to-many messaging model enables clients to send the same message to multiple recipient queues. Message Queuing offers several ways to implement this model. First, an Active Directory distribution group object that encapsulates a collection of destination queues can serve as a distribution list in Message Queuing. Second, a message can be sent programmatically to multiple destinations specified in the form of a format name, called a multiple-element format name, which consists of a list of comma-delimited destinations. (Although a multiple-element format name is also a kind of distribution list, in the context of Message Queuing, the term distribution list always refers to a distribution group published in Active Directory.) Third, messages can be sent to a single destination IP address, and then received and processed by multiple IP hosts, which listen for a specific IP multicast address and receive all packets to it.

Distribution lists and multiple-element format names can also be used 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.

Distribution lists

Distribution lists are public lists that are published as distribution group objects in Active Directory. The explicit members of a distribution list must be destinations published in Active Directory; that is, public queues, queue aliases, and other distribution lists, but not private queues and URL-named queues.

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.

Distribution lists can have domain local or global scope. Distribution lists with domain local scope can have only queues and other distribution lists from the local domain as members and cannot be moved to another domain. Distribution lists with global scope can have, in addition, queues and other global distribution lists from other domains in the forest and can be moved to another domain.

Conversely, because 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, which are described in the next section, provided they do not contain an element that points to a public queue or a distribution list.

You can use Active Directory User 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, you should refer to the Message Queuing Software Development Kit (SDK). For information on accessing the Message Queuing SDK, see Microsoft Platform Software Development Kit.

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 and multiple-element format names, which are described in the next main section, can also be used to specify multiple administration queues when acknowledgment messages are requested as well as to specify multiple response queues when response messages are requested.

Distribution lists or multiple-element format names 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 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.

A sender should expect at least n acknowledgment messages for a message sent to a distribution list or a multiple-element format name 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 messages 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.

Security settings for distribution lists

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 as queues do. 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:

  • The Send To permission allows a group or user to send messages to the applicable distribution list. By default, this permission is granted to everyone.
  • The 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 as a member in a distribution list. All users are granted this permission by default.
  • The 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 member (a queue or a distribution list) 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.

Multiple-element format names

The functional differences between distribution lists and multiple-element format names stem from the fact that distribution lists are public lists that are published in Active Directory, while multiple-element format names are private lists that are not stored in Active Directory and must be created and maintained at the application level.

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 queue, 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 compatibility with pre-Windows XP computers, 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.

Reliable 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.

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.

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.

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 domain controller that supports multicast addresses in Active Directory 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/Windows 2000/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/receiver. Encryption and decryption are not supported.

Sending messages to multiple destinations within transactions

Both distribution lists and multiple-element format names have support for sending 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.

To achieve exactly-once and in-order delivery (EOD), 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.

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.

The following paragraphs describe specific features of sending transactional messages to distribution lists and multiple-element format names.

For more information on sending messages within transactions, see Transactional messaging.

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.

The same 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). Consider the case of two distribution lists D1 and D2, each of which contains queue Q1 as a member. If message M1 is sent to D1 and message M2 is sent to D2 within the same transaction, the messages will not necessarily arrive at Q1 in the order in which they were sent. 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.

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 will reach the new member.

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 M2 to N2, and 3) sending 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.


Message routing

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.

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.

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.

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 is 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. For more information on the various types of Message Queuing computers, see Message Queuing computers.

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.

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. You should 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.

In a domain environment with more than one Windows 2000 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.)

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 at all.
  • Routing links should not be confused 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, in turn, delivers the message to a site gate. This process continues until the message reaches the destination computer.

Let us take, for example, a routing link that connects sites A and B and 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, then 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.

For information on how to change the cost of an existing routing link, see Change the cost for a routing link.

For more information on creating and configuring routing links, see Configuring routing links.

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

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 2000 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 Configuring a firewall.


Message storage

Message storage size limits, or quotas, specify the maximum cumulative size for all messages contained in a particular queue or on a computer. Similarly, the journal storage size limits, or quotas, specify the maximum cumulative size for all journal messages contained in a particular queue journal or on a computer.

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 broken down 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. Queue quotas and the computer quota can be set independently. 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. Computer quotas are not applied towards internal private queues.

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.

Queue and computer quotas can be set only on Message Queuing servers and independent clients. Queue quotas and computer quotas set on Message Queuing servers that support dependent clients apply both to the server and to all its dependent clients. For example, if the computer quota for the server is 50 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.

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. For Message Queuing servers supporting multiple dependent clients, this limit applies to the server because 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.

Notes

  • The theoretical message storage capacity of a computer is limited by the amount of RAM, the total disk storage capacity, the number of accumulated messages currently stored in the computer, and the version of Message Queuing running on the computer. In terms of the number of messages stored, the limit for a computer running the current version of Message Queuing with more than 512 MB of RAM is about 5 million messages. At the same time, the maximum disk space allocated for a single message is 4 MB. Multiplying the maximum number of messages stored by the maximum storage size of a single message reveals that the theoretical maximum number of bytes that can be stored on a single computer can exceed 1 terabyte.

For more information on how to set quotas, see Setting computer quotas for messages and Setting queue quotas for 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 XP. However, because the NTFS file system for Windows XP provides more reliable file recovery after a power failure or system crash, it is highly recommended for Message Queuing servers. In addition, you should 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.


Message Queuing objects in 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.

The following tables 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 non-domain 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 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 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 by Windows 2000 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.

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

A routing link object with a user-defined name is created for each routing link that you create between two Message Queuing sites or between a Message Queuing site and a foreign site 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.

MSMQ Settings object

An MSMQ Settings object is created for each Message Queuing server that is installed on a Windows 2000 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.

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

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.

The msmq object (and child container objects) is displayed in the console tree of the Active Directory Users and Computer 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

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).

Distribution group object

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.

Distribution group objects are displayed in the console tree of the Active Directory Users and Computer snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • Users
  • YourDistributionGroupObject

For more information on distribution lists, see Distribution lists.

MSMQ Computers organizational unit object

This organizational unit (OU) object is created only by the Message Queuing Upgrade Wizard 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 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 organizational unit object is displayed in the console tree of the Active Directory Users and Computer snap-in in the following location:

  • Active Directory Users and Computers
  • YourDomainObject
  • MSMQ Computers

MSMQ Users organizational unit object

This organizational unit (OU) object is created only by the Message Queuing Upgrade Wizard 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 2000 computer) and is used as a container for MSMQ Upgraded User objects.

The MSMQ Users organizational unit object is displayed in the console tree of the Active Directory Users and Computer 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 Upgrade Wizard 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 Computer snap-in when the MSMQ Users object is selected in the console tree.

    Where?

    • 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 2000 domain, even in a non-mixed mode, the Message Queuing service creates an MSMQ upgraded user object for such a user as well.


Delivering messages over HTTP transport

Message Queuing includes support for delivering messages over HTTP transport. Thus, messages can be sent to and received from queues over HTTP transport as in the familiar Message Queuing programming model. Queues can be addressed by URL names both within an intranet and on the Internet. The sender and receiver can be in different forests or organizations. An open, XML-based protocol, called SRMP (SOAP-Reliable Messaging Protocol) is defined and implemented. Asynchronous messaging, including asynchronous B2B messaging, is enabled with a solution for firewalls. For increased scalability and availability, Message Queuing integrates with common network load-balancing mechanisms, namely, Network Load Balancing (NLB), NAT, Cisco LocalDirector, and DNS round-robin. For information on load-balancing Web farms, see NLB clusters for Message Queuing.

Message can be sent over HTTP transport to queues on the Internet or an intranet using URL-style direct format names, which are described in the next section. For Message Queuing to send messages over HTTP transport, the MSMQ HTTP Support subcomponent must be installed. This subcomponent, which is not selected by default during setup on Windows XP Professional, installs Internet Information Services (IIS) and creates an IIS extension for Message Queuing.

URL names for queues

The public, private, and direct format names of administration or response queues can be included in messages sent over HTTP transport. Conversely, the names of administration or response queues in HTTP format can be included in messages sent over ordinary (non-HTTP) transport. However, the use of distribution lists and multiple-element format names for these purposes is not supported.

The host name and resource in the HTTP header are converted to UTF-8 format. This enables sending HTTP messages to computers and queues that have non-English Unicode names.

For information on the direct format names used for URL-named queues, see Direct format names.

Express/recoverable messages sent over HTTP transport

When messages are sent over HTTP transport, the receiver is not required to maintain any internal state, and Message Queuing does not guarantee exactly once delivery (EOD), although a best-effort attempt to achieve it is made through a lightweight duplicate removal mechanism. When a session between a client and one of the nodes is disconnected and the client is routed to another node for the next session, the messages for which a session acknowledgment message was not sent before are re-sent by the client and accepted by the new node (resulting in possible duplicates). However, since EOD is not guaranteed in any case, the receiving application can either deal with duplicates or ignore the problem.

Direct format names of the form DIRECT=TCP:ClusterIP\QueueName are used to send messages to an NLB virtual server.

Message Queuing through a perimeter network (DMZ)

Most organizations connect to the Internet using a perimeter network (also known as a DMZ) protected by firewalls with proxy servers. A proxy server acts as a liaison between the intranet and the Internet world. 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 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 should 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.

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.

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.

External and internal queue names

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 senders located outside of the organization. The internal names of the queues and host computers can be mapped to external names or aliases. This way, messages sent over HTTP transport to the external HTTP format name of a queue can be directed to the corresponding queue hosted on a computer within the organization.

Transactional messages are to be delivered exactly once and in the order in which they are sent. When transactional messages are sent over HTTP transport from the internal network of an organization to the Internet, the internal name of the sender's order queue must be translated into an external queue name using a mapping in order to direct the order acknowledgment messages from the receiving computer (which is located outside of the sender's organization) back to the sender's order queue. The order acknowledgement message is sent in the SRMP envelope.

Mappings of the internal names of queues to external queue names are created manually in XML mapping files. Both the internal and external queue names must be written as HTTP format names. For example, the internal name of an order queue must be written with the internal network name of the local host (http://LocalHost\msmq\private$\order_queue$). Note also the directions of the slashes. The following is an example of an XML mapping file with mappings of the internal name of an application queue hosted on a computer within an organization to a corresponding external queue name and of the internal name of an order queue to an external queue name:

<mapping host="localhost" xmlns="msmq-queue-mapping.xml">

   <queue>
       <name>http://internal_network_name\msmq\internal_queue</name>
       <alias>http://external_network_name\msmq\external_queue</alias>
   </queue>

    <queue>
        <name>http://internal_network_name\msmq\private$\order_queue$</name>
        <alias>http://external_network_name\msmq\private$\order_queue$</alias>
    </queue>

</mapping>

These XML mapping files should be stored in the \Windows\System32\Msmq\Mapping folder.

HTTPS messages

When messages are sent over HTTPS transport, a Secure Sockets Layer (SSL) connection must be established between the sender and the 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.

Before an SSL connection can be established for sending messages, IIS on the recipient side must send the recipient's server certificate to the sender for authentication. This server certificate, which contains the CA's signature, the recipient's public key, additional information on the recipient, and an expiration date, must be from a certification authority (CA) that the sender trusts. When a computer trusts a particular CA, 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. The server certificate must reside in the Personal store under Certificates (Local Computer) in the Certificates snap-in on the recipient computer. To authenticate the recipient computer, the sender verifies that it trusts the CA and validates the signature in the recipient's server certificate.

For detailed information on obtaining a server certificate from a CA and installing it, see Obtaining a Server Certificate in the IIS 6.0 Documentation.

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.

To use a client certificate, perform the following procedure on the sending and receiving computers:

  • On the sending computer, perform the following tasks:
    1. In your Web browser, open the form for requesting a certificate from your CA.
    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 under Type of certificate needed, select Client Authentication Certificate.
    4. Select the Use local machine store and Mark keys as exportable check boxes, click Submit, and then click Install.
    5. Open the Certificates snap-in by clicking Start, clicking Run, typing mmc, and then clicking OK.
    6. On the File menu, click Add/Remove Snap-in.
    7. In the Add/Remove Snap-in dialog box, click Add, select Certificates, and then click Add.
    8. Select Computer account, click Next, and then click Finish.
    9. In the Add Standalone Snap-in dialog box, click Add, select Service account, click Next, and click Next again.
    10. Under Service account, select Message Queuing, click Finish, click Close, and click OK.
    11. Locate the automatically installed client certificate in the Personal store.

      12. Where?

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

      13. Where?

      • Console Root
      • Certificates - Service (Message Queuing) on Local Computer
      • MSMQ\Personal
      • Certificates
  • On the receiving computer, perform the following tasks:
    1. Open Computer Management.
    2. In the console tree, right-click Default Web Site.

      3. Where?

      • Computer Management
      • Services and Applications
      • Internet Information Services
      • Web Sites
      • Default Web Site
    3. Click Properties.
    4. On the Directory Security page, under Secure communications, click Edit.
    5. In the Secure Communications dialog box, select Accept client certificates.

When all the conditions imposed by IIS are satisfied, the sender and recipient 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 the IIS 6.0 Documentation.

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.

In the context of Message Queuing, IIS can authenticate the sending computer, but not individual users sending messages. The next section describes how users sending authenticated messages over HTTP/HTTPS transport can be validated.

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.

When a message requiring authentication is sent within the same forest, the recipient decrypts the digital signature, validates it using the sender's public key, and tries to locate the user certificate in Active Directory according to its GUID. If the user certificate is found, the signature of the issuer (CA) is validated using its public key, which is stored on any computer that trusts the issuer. However, 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), and if the test is positive, the message is rejected. 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. In order to overcome this problem and use the same user certificate to authenticate messages sent between different forests, you should 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. Use the Message Queuing UI to register the certificate in Active Directory to the pseudo-user.
  6. 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.


Message Queuing Triggers

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.

Message Queuing Triggers is an integral part of Message Queuing 3.0. The earlier stand-alone version, known as MSMQ Triggers, can be installed on Windows 2000 computers running Message Queuing 2.0 as well as Windows NT 4.0 computers running MSMQ 1.0.

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 an argument list or as a COM component, a method, and a parameter list. You can also invoke other types of files by making the 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.

Message processing type

A message processing type is defined for each trigger. The available message processing types are peeking, retrieval, and transactional retrival.

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, 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 performs all the applicable actions, but does not remove it 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.

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.

Processing 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. In the case of a queue monitored by a trigger with the peeking type of message processing, after the Message Queuing Triggers service peeks at several messages in the queue, it will continue to peek at additional messages as they arrive at the end of the queue without peeking at the older messages again.

Processing messages having different priorities

When messages with different priorities arrive in a queue, 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.

When a trigger with the peeking type of message processing is assigned to a queue containing two messages of priority 1 (message 1 and message 2) followed by two messages of priority 2 (message 3 and message 4), 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.

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 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 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.

An interesting situation arises 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 Pbrush.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 and running Message Queuing Triggers.


Business scenarios for Message Queuing

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. Application developers should 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, Cross-platform support and connectivity to foreign computers.
  • Performance: Because messages can be delivered very quickly, 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. Because IIS and Message Queuing are not available with Windows XP Home Edition, this cannot be done on computers running that platform.
  • 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 Cross-platform support and connectivity to foreign computers.

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 Cross-platform support and connectivity to foreign computers.
  • Transactions (exactly once delivery): For guaranteed message delivery, ensuring accurate accounting.
  • Connectionless messaging: For updating accounts and making risk assessments asynchronously.


Using Message Queuing

This section provides information on planning, installation and upgrade requirements, security, and administration.

  • Planning for Message Queuing
  • Installing, upgrading, and uninstalling Message Queuing
  • Securing Message Queuing
  • Administering Message Queuing


Planning for Message Queuing

This section suggests ways to plan for and deploy Message Queuing in your organization. The successful use of Message Queuing depends on the successful installation and implementation of Message Queuing servers, clients, and applications.

  • Planning a Message Queuing network
  • Selecting Message Queuing server hardware
  • Message Queuing application development
  • Deploying Message Queuing


Planning a Message Queuing network

Assessing the growth requirements of your organization and planning your network accordingly is the first step in rolling out your Message Queuing infrastructure and applications.

As the use of Message Queuing in your organization increases, messaging traffic also increases. You should plan to install Message Queuing servers to route messages into wider-bandwidth communication links. All sites should be connected by routing links to other sites. For link redundancy, you should use multiple routing links for intersite routing if possible.

Site considerations

All sites are determined during the planning and installation of Windows 2000 Server 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, you should 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.
Organizational | Group together users who work in the same site to improve overall performance of the system, reduce network traffic, and reduce resource use.

Routing-link considerations

If your organization has more than one Windows 2000 site, you must create routing links to guarantee that messages can be routed between different Windows 2000 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. You should 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.

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 2000 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.

Message Queuing server considerations

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 between 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.

For performance and scalability reasons, you should install Message Queuing routing servers on multiple computers in each Windows 2000 site.

In addition, because Message Queuing routing servers answer the broadcast request that clients generate during automatic site recognition, you should install at least one Message Queuing routing server in every Windows 2000 site in your forest.

In-routing and out-routing servers should 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, you should carefully consider how installing Message Queuing routing servers on domain controllers may influence their performance and security.

Finally, every dependent client in your network needs a supporting server, which can be any Message Queuing server with or without routing enabled.

For information on server hardware considerations, see Selecting Message Queuing server hardware.

Independent client considerations

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 is 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 users who are disconnected from the network can continue to receive messages at their assigned in-routing servers. However, because such routing settings are ignored when independent clients connect to a new site, this configuration works best if the independent clients do not reconnect to the network at another site.

Notes

  • 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.

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 XP 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 and multiple-element format names are not supported for dependent clients.
  • Dependent clients cannot be installed on computers in workgroup mode or on 64-bit computers.
  • Dependent clients will no longer be supported in future versions of Message Queuing.

Because of these limitations, it is recommended that you deploy independent clients rather than dependent clients wherever practical.

Licensing considerations

Message Queuing applications may communicate with a larger number of servers than traditional network-based applications do. For this reason, per-seat licensing may be more cost effective for your Message Queuing computers.

Message Queuing counts Windows 2000 Server 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 Windows XP Professional can have no more than 10 concurrent Message Queuing sessions and remote-read sessions with other independent clients running on Windows XP Professional.
  • 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 example, if a computer running Windows XP Professional has both a Message Queuing session and a remote-read session with a computer running Windows 2000 Server, the server counts these as one CAL.
  • Computers running Windows XP Professional do not count sessions with computers running Windows 2000 Server; however, computers running Windows 2000 Server do count sessions with computers running Windows XP Professional.

For more information on licensing for Windows 2000 Server, see Licensing modes.

Internet deployment considerations

If your network will be sending or receiving messages through the Internet, you should consider the following problems:

  • Network load balancing. For increased scalability and availability, Message Queuing integrates with common network load-balancing mechanisms, namely, Network Load Balancing (NLB), NAT, Cisco LocalDirector, and DNS round-robin. For information on load-balancing Web farms, see NLB clusters for Message Queuing.
  • Messaging through perimeter networks. Most organizations connect to the Internet using a proxy server and a perimeter network (also known as a DMZ) protected by firewalls. 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 should 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.


Selecting Message Queuing server hardware

Your server hardware decisions affect the performance of your network. When choosing hardware for servers, consider your future business needs and choose computers that can be easily upgraded or expanded. Therefore, as the number of users in your organization grows, you may be able to reconfigure existing hardware rather than add more computers. There are several ways to make the most of existing server hardware for Message Queuing, including the following:

  • Increase the amount of system memory for each server.
  • Upgrade the processor, or add additional processors.
  • Increase the number, speed, or size of the disks.
  • Replace disk drives and volume sets with striped drive arrays.
  • Limit 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. Without those additional resources, such as greater disk and memory resources, the server can support fewer dependent clients.

By planning ahead, you can choose hardware that is easily upgraded. If you identify a performance bottleneck after deployment, you may be able to upgrade your existing hardware rather than purchasing new computers or changing the site layout.

Disk considerations

You should address the following issues regarding server disk subsystems for the number of disks, disk size, and disk type.

Number of disks

Because Windows 2000 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, and retrieved from, disk.

Message Queuing servers as well as independent clients can improve their messaging performance by storing the various files used to implement messaging on several physical disks. Up to three disks can be used to store such files. 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 more information on how message and log files are stored, see Local message storage.

Maximum performance will be obtained when five separate physical disks are used for message and log files, as follows:

  • Message files
  • Message log files
  • Transaction log files
  • Windows paging files
  • Application data files

In situations where it is not practical to have five disks installed in a computer, three disks will usually provide the most incremental performance gains. For example, performance from a three-disk configuration will usually be two to three times better than from a single-disk configuration. A five-disk configuration will typically be 50 percent faster than using three disks. If you have only two disks, put the messaging files on one disk and put the message log and transaction log files on the other disk.

For the best transactional performance, place the data and log files for the application used to implement transactional messaging on two or more different disks. If you have an additional disk, consider putting the Microsoft Distributed Transaction Coordinator (DTC) transaction manager log file on a separate disk.

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 percent, 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 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 more information on monitoring Message Queuing performance, see Monitoring performance.

Disk size

To determine the minimum disk size for your servers, consider the following:

  • The total number of messages that are likely to accumulate on the server at any time, and the total size of those messages.
  • The disk space used to store files used to implement messaging as well as the Message Queuing program files.

Because messages can be stored on a destination computer, source computer, and any Message Queuing server in between, 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.

The amount of disk space used for messages depends on the message delivery type (recoverable/transactional or express), message size, and messaging volume. Message Queuing allocates a maximum of 4 MB of disk space for a single message.

Recoverable and transactional messages are written to disk in 512-byte blocks. These messages use approximately 150 bytes for the message header (depending on the message properties sent).

Because express messages are also written to disk when insufficient memory is available to store them, you must factor in their disk-space allocation. Express messages are stored in 64-byte blocks, so disk space may be used more efficiently if the message size is small.

Because journal messages are stored until either you delete them or a Message Queuing application reads the journal, you must also allow for additional disk space when storing journal messages.

As a rule, however, you should base your message-delivery selection on business needs, not disk-space requirements. For more information on the message delivery types available, see Message delivery.

Notes

  • When a Message Queuing server (or independent client) runs out of disk space, it can no longer send or receive messages, nor can queues be created on it.

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. While the performance of different disks will vary by manufacturer and other factors, a three-way hardware-striped disk with a 2-MB battery-protected controller, as opposed to a standard SCSI Class II disk, can increase message throughput up to tenfold.

Because the NTFS file system for Windows XP provides more reliable file recovery after a power failure or system crash, it is the recommended file system for Message Queuing servers. Using three or more disks formatted with NTFS allows you to use Redundant Array of Independent Disks (RAID) support provided with Windows 2000 Server for fault tolerance.

Memory considerations

For optimal performance, your Message Queuing servers should have enough physical RAM to avoid heavy use of the Windows paging file. Because accessing the paging file is much slower than accessing physical memory, increasing the amount of physical memory can greatly improve messaging performance. However, other hardware resources, such as the CPU and I/O subsystems, may limit overall performance.

To maximize messaging performance, there should 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 computer (if the destination computer is unreachable), on the destination computer (if the receiving application is not running, or is unable to keep up with the arrival rate of messages), or on an intermediate Message Queuing server.

Calculating the amount of RAM required to hold all messages requires an understanding of message sizes. The size of a message is the sum of the size of the message body and the size of the data kept in the message header. Message headers typically contain approximately 150 bytes of data, although the actual size of a given header is dependent on the number of properties used by the Message Queuing application. Therefore, when sending 20,000 messages that are approximately 1 Kilobytes each with typical header sizes, allow at least 23 MB (20,000 × 1 KB + 20,000 × 150) of available RAM beyond normal system requirements.

Notes

  • This recommendation 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.

In addition, quotas specify the cumulative limit for all messages (including journal messages) on a computer or in an individual queue. The computer and queue quotas are based on size and can be set independently. The theoretical message storage capacity for Message Queuing servers and independent clients is limited by the amount of RAM, the total disk storage capacity, the number of accumulated messages currently stored in the computer, and the version of Message Queuing running on the computer. In terms of the number of messages stored, the limit for a computer running the current version of Message Queuing with more than 512 MB of RAM is about 5 million messages. At the same time, the disk space allocated for a single message cannot exceed 4 MB. Multiplying the maximum number of messages stored by the maximum storage size of a single message reveals that the theoretical maximum number of bytes that can be stored on a single computer can exceed 1 terabyte. For more information on quotas, see Quotas for messages.

Processor considerations

If your server input/output subsystem is fast and is not the single limiting performance factor and if you have enough RAM memory to handle messaging without excessive use of the Windows paging file, a faster processor can improve messaging performance. For Message Queuing servers, consider using multiple processors. Only Intel-based computers are supported.

Network adapter considerations

High-speed network adapters and network drivers help optimize messaging performance by achieving high throughput rates with low CPU use.

Because numerous clients may simultaneously access a Message Queuing server, you should install one or more high-performance network adapters, based on a high-speed bus such as PCI or EISA. Installing multiple adapters in a multiple-processor computer means that a single computer can handle more client requests, with each adapter servicing a separate network segment or network protocol.

Quantity considerations

Hardware that can be used for Message Queuing servers range from single-processor Pentium-class computers to the most powerful multiple-processor configuration that Windows 2000 Advanced Server and Datacenter Server support. Therefore, you could have an organization of 10,000 clients, with 100 users for each of 100 servers or with 500 clients for each of 20 servers. This decision depends on the requirements and budget of your organization.

The following table lists the advantages and disadvantages of using more, less powerful computers:

Advantages | Disadvantages
Less expensive to increase capacity | More hardware to maintain
More hardware choices available | Minor increases in users or load require more hardware
Closer proximity to users, reducing network traffic for client/server interactions |

The following table lists the advantages and disadvantages of using fewer, more powerful computers:

Advantages | Disadvantages
System is better designed for upgrading | Network adapters must be able to handle more traffic to each server
Storage requirements may be lower |
Fewer data replications are required |


Message Queuing application development

To use Message Queuing to send and receive messages, relevant Message Queuing applications must first be designed, developed, and deployed.

Because this documentation is geared towards system administrators who are interested in installing and managing the infrastructure that Message Queuing provides, it does not discuss application development. The Message Queuing Software Development Kit (SDK), which is part of the Microsoft Platform SDK, provides information for software developers on how to develop Message Queuing applications. For more information on the Message Queuing SDK, see the Microsoft Platform Software Development Kit.


Deploying Message Queuing

This section suggests a rollout process for deploying Message Queuing in a medium-scale to large-scale organization. You should choose a plan that meets your business needs.

The rollout process can consist of the following phases:

  • Setting administrative policy.
  • Conducting lab tests.
  • Conducting one or more pilot rollouts.
  • Conducting the final rollout.

Setting administrative policy

Your administrative policy is a working document. How it is implemented can be influenced by the policies that you establish. You should consider the following:

  • Establishing access control within your organization.
  • Delegating administrative duties.
  • Documenting work.
  • Preparing for emergencies.
  • Scheduling regular backups.

You should also establish administrative policies to handle emergencies, such as if a server is corrupted, removed, or destroyed. With emergency plans, you can lessen the severity of disruptions.

Conducting lab tests

Lab testing allows you to determine what type of load Message Queuing puts on your servers as well as to test your in-house Message Queuing applications. Preparing the test site and equipment involves the following tasks:

  • Ensuring that all computers meet the minimum hardware requirements for running Message Queuing.
  • Ensuring that your Message Queuing applications function properly.

Conducting a pilot rollout

When you have tested Message Queuing in the lab, you are ready to deploy Message Queuing in a limited environment. The pilot rollout should be introduced on a limited scale, such as 15 to 50 users. Using this information, you can 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.


Installing, upgrading, and uninstalling Message Queuing

This section explains the requirements for installing and upgrading Message Queuing software on computers running Windows XP. It also explains how to install new Message Queuing software remotely using a script.

  • Installation overview for Message Queuing
  • Installing new Message Queuing clients
  • Installing and running Message Queuing Triggers
  • Running Message Queuing unattended setup
  • Upgrading Message Queuing
  • Uninstalling Message Queuing


Installation overview for Message Queuing

Message Queuing is not installed by default during Windows XP Setup, but the files needed to install it and its subcomponents are copied to the computer during this process. You can install Message Queuing on a computer using the following methods:

  • Select the Message Queuing check box and Message Queuing subcomponents during Windows XP Setup. Having Message Queuing installed during Windows XP Setup is a two-step process. The first step, which is carried out during every installation of Windows XP, but not of Windows XP Home Edition, involves copying the program files to your local disk. The second step, which occurs after Windows XP is installed and you log on for the first time, completes the installation of Message Queuing.
  • Add or Remove Programs in Control Panel, after Windows XP is installed. In this case, the installation process is completely automated, and the pop-up from the Configure Your Server Wizard does not appear.

In both cases, the required Message Queuing subcomponents can be chosen in the Windows Components Wizard by selecting the Message Queuing check box, clicking the Details button, and selecting or clearing the applicable check boxes. If you select the combination of subcomponents that creates an independent client, you can also install several additional optional subcomponents.

The second method can be used to install new Message Queuing software on your computers at any time. With some exceptions (see Installation restrictions), additional subcomponents can be installed and subcomponents can be removed at a later time by this method using the Windows Components Wizard.

When Message Queuing is installed on a computer, the Microsoft Distributed Transaction Coordinator (DTC) is also installed by default. The DTC is required for transactional messaging and for creating a DTC resource in one virtual server in a server cluster.

Since the Message Queuing files are copied to the computer during Windows Setup even if Message Queuing is not installed, no additional disk space is occupied when Message Queuing is installed.

Subcomponents for Message Queuing Setup

The following table lists the subcomponents of Message Queuing that can be installed on 32-bit Windows XP, their dependencies on other subcomponents, and their names in the .inf file:

Component or subcomponent name | Description and setup steps | Depends on | Name in the .inf file
Message Queuing | parent for all subcomponents | DTC | msmq
Common | performs common setup tasks: parent for the Core and Local Storage subcomponents | none | msmq_Common
Core | performs the most fundamental setup operations: creates and sets registry keys, and provides dependent client functionality | none | msmq_Core
Local Storage | creates installs the Message Queuing service and provides independent client functionality | 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 | Local storage | msmq_ADIntegrated
Triggers | installs the Message Queuing Triggers service | Local storage | msmq_TriggersService
MSMQ HTTP Support | creates an IIS extension for Message Queuing (called MSMQ) | Local storage, IIS (the World Wide Web Publishing service) | msmq_HTTPSupport

The Message Queuing subcomponent tree has the following form:

Message Queuing
Common
Core
Local Storage
Active Directory Integration
Triggers
MSMQ HTTP Support

Notes

  • On the 64-bit platform, the Core and Local Storage subcomponents are combined in a single subcomponent, called Core, which, in this case, provides independent client functionality.

Default options

When you select Message Queuing in the Windows Component Wizard on computers running Windows XP Professional, the following subcomponents are selected by default:

  • Core
  • Local Storage
  • Active Directory Integration
  • Triggers

This means that, by default, an independent client capable of integrating with Active Directory (whenever the computer belongs to a domain) will be installed and the Message Queuing Triggers service will be installed and started on computers running Windows XP Professional.

If a computer belongs to a workgroup (on either Windows XP Professional or any of the Server platforms), 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, etc.). 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/deleted.

Computers running on 64-bit platforms

A dependent client cannot be installed on a computer running on 64-bit Windows XP. 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
Core
Active Directory Integration
Triggers
MSMQ HTTP Support

The following table shows the subcomponent dependencies for 64-bit computers:

Subcomponent name | Depends on | Comment
Message Queuing | DTC | parent
Core |  |
Active Directory Integration | Core |
Triggers | Core |
MSMQ HTTP Support | Core, IIS (the World Wide Web Publishing service) |

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

Access mode

If you are installing the default configuration of Message Queuing on a computer that is a member of a Windows XP workgroup, an independent client operating in workgroup mode will be installed, and the Message Queuing Triggers service will be installed and started. Workgroup mode means that the computer is unable to access Active Directory. Although the Active Directory Integration subcomponent will also be installed in the default configuration, the computer will not be able to access Active Directory and will continue to operate in workgroup mode until it joins a domain. After such a 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.

If you are installing Message Queuing on a computer that is a member of a Windows 2000 domain, you can still specify whether the computer will operate in domain mode (by installing the Active Directory Integration subcomponent) or in workgroup mode (by not installing the Active Directory Integration subcomponent). 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.

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 2000 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. Otherwise, you will be prompted for the name a Windows 2000 domain controller or of an MSMQ 1.0 PEC or PSC (in a Windows NT 4.0 enterprise) in the local site. If contacting the computer specified still fails, you should cancel the installation process and install Message Queuing without Active Directory Integration. In this case, Message Queuing will be installed in workgroup mode.

If you do not install the Active Directory Integration subcomponent, the computer will operate in workgroup mode, meaning that access to Active Directory will be disabled. You can choose to have a computer operate in workgroup mode if domain controllers are currently unavailable or are not yet deployed in your organization. However, such a computer will never try to access the directory service or operate in domain mode. Conversely, if a computer is a member of a domain and the Active Directory Integration subcomponent is installed, but the computer is temporarily unable to access a domain controller at any time after installation, it will operate in offline 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 resume operating in domain mode. For more information on the characteristics of workgroup mode, domain mode, and offline mode, see Network topology.

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 Windows XP:

  • 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.
  • You must have network connectivity if you want to install or upgrade Message Queuing on a computer that is part of a Windows 2000 domain.
  • Before you can install or upgrade Message Queuing on pre-Windows XP computers in a Windows 2000 domain, you must install a Message Queuing 2.0 server on a Windows 2000 domain controller in the local domain. This requirement does not apply if you install or upgrade Message Queuing on a computer that is part of a Windows NT 4.0 domain that contains MSMQ 1.0 controller servers, such as the PEC or a PSC.
  • 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 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.

Installation restrictions

To successfully install or upgrade Message Queuing, the following restrictions must be observed:

  • Do not install Message Queuing 2.0 simultaneously on multiple Windows 2000 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/removed.
  • After the Active Directory Integration subcomponent is installed, it cannot be removed.
  • The domain controller which an independent client will attempt to contact during installation cannot be defined in advance in attended setup. If you need to specify the 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.

Finally, there may be certain restrictions on creating queues on computers that are specified during Message Queuing Setup. For more information, see Security descriptors for msmq objects.

Installation platforms

The following table shows which types of Message Queuing computers can be created on which Windows platforms:

Type of Message Queuing computer | Windows platform
Message Queuing server | the Windows 2000 Server family
Independent client | 32-bit and 64-bit Windows XP Professional, but not Windows XP Home Edition
Dependent client | 32-bit Windows XP Professional, but not Windows XP Home Edition

Notes

  • Only an independent client, Active Directory Integration, Triggers, and MSMQ HTTP Support can be installed on a computer running Windows XP Professional.
  • A dependent client cannot be installed on a computer operating in workgroup mode or a 64-bit computer.

Installation permissions

The user installing an independent client or a dependent client on a Windows XP computer must have local administrative permissions (or be a member of the local Administrators group). 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.

For more information on administrative groups for Windows XP, see Built-in and predefined groups.

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 in order for Message Queuing installation to complete:

Message Queuing computer | Specific permissions required | For which object
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 objects in Active Directory.

For more information 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 install permissions for 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.

Installation scenarios

The following addresses some installation scenarios you may encounter:

Failed installation attempt

If Message Queuing installation fails for any reason, Setup tries to delete the msmq (MSMQ Configuration) object and any other applicable objects in Active Directory before creating new ones during a repeated installation. However, sometimes you may need to manually delete the applicable objects before running the installation process again. If you do not do this, there will be objects created with the same name in Active Directory, which will lead to unpredictable operation. For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, see Message Queuing objects in 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 should 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.

Installing Message Queuing using a Windows NT 4.0 user account

When you install Message Queuing on a computer running Windows XP and you are logged on using a Windows NT 4.0 domain user account, you should have at least one Message Queuing server running on a Windows 2000 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 2000 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 2000 domain:

When prompted for the name of a primary site controller (PSC) during setup, you must enter the name of a domain controller instead. This Windows 2000 domain controller must be running a Message Queuing server, 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 2000 domain, you should install a Messsage Queuing server on 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 2000 domain, you should verify that the Everyone group has been added to the "Pre-Windows 2000 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 2000 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 should have Windows NT 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 2000 domain, you must use the Delegation of Control Wizard to grant specific permissions to all users in the domain. For more information, see Set install permissions for MSMQ 1.0.


Installing new Message Queuing clients

This topic covers the installation of Message Queuing client software on computers that do not have MSMQ 1.0 installed. You can install either independent clients or dependent clients. It is recommended that you install independent clients wherever possible. For information on upgrading MSMQ 1.0 client software, see Upgrade overview for Message Queuing.

Before you can install Message Queuing client software on any computer, the following requirements must first be met:

  • You must have network connectivity and be able to contact a Windows 2000 domain controller in the local site or in a nearby site (or an MSMQ 1.0 PEC or PSC in the local site) if you want to install Message Queuing client software on a computer in domain mode.
  • You must be logged on with local administrative permissions (as a member of the local Administrators 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 it before creating a new one.
  • To uninstall Message Queuing, you must be granted the Delete MSMQ Configuration Object permission.

For more information on the permissions required for installation, see Installation permissions.

Independent client setup

Independent client software can be installed on computers running Windows XP Professional, but not on computers running Windows XP Home Edition.

Setup automatically attempts to locate a Windows 2000 domain controller in the same site or a nearby site. If one cannot be located, you will have to provide the DNS or NetBIOS name of such a domain controller or of an MSMQ 1.0 PEC or PSC when prompted. If the computer specified cannot be contacted, you can cancel and restart the installation process and install Message Queuing without access to Active Directory by clearing the Active Directory Integration check box. 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. Workgroup mode of operation requires direct connectivity to send messages. For more on information on installing Message Queuing without access to Active Directory, see Access mode.

You can also 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). In this case, too, direct connectivity is required to send messages.

For information on how to install an independent client after all requirements are met, see Install independent clients.

Dependent client setup

Dependent client software can be installed on computers running 32-bit Windows XP Professional, but not on 64-bit computers or on computers operating in workgroup mode.

The Message Queuing server that supports a dependent client (by storing queues and messages) is referred to as the supporting server. Any Message Queuing server operating in domain mode with at least independent client functionality can be 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 displays a message stating that the server is not reachable. You can either specify a Message Queuing server or click Cancel. If you click Cancel, Setup will still complete successfully. Using this feature, you can install a dependent client before you install its supporting Message Queuing server.

If you want to enable a Windows 2000 domain controller to act as the supporting server for dependent clients, you must change the security configuration of the Microsoft Distributed Transaction Coordinator (DTC). For more information, see Install dependent clients.

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.

Notes

  • If you have an MSMQ 1.0 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 have Windows NT Service Pack 4 or higher installed or transactional messaging will not function.


Installing and running 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.

Installation

The support for Message Queuing Triggers can be installed by Message Queuing Setup during the installation of an independent client on computers running Windows XP Professional. 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 indepedent 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 on 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 five files for the Triggers service in the \Windows\System32 folder: mqtrig.dll, mqtrig.tlb, mqtgsvc.exe, mqgentr.dll, and mqtgclus.dll.

By default, the Message Queuing Triggers service runs under the LocalSystem account. It can also run under a domain administrative account. The service reads and writes registry settings, and, by default, every domain user has the applicable rights. The user's account 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 in order 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. For more information on how to set permissions for Message Queuing objects, see Set permissions for computer and queue objects.

Message Queuing Triggers installs with a set of default configuration values that are stored in the registry. These values can be changed later on using the Computer Management snap-in. For more information on how to change the default configuration, see Change default configuration values for 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 should 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 Message Queuing Triggers.

You can attach an existing rule to the new trigger by clicking Existing rules on the second page of the New Trigger dialog box. You then select an existing rule or rules to attach to the trigger in Rule list on the Existing Rules dialog box and then associate them with the trigger by clicking Attach. The order in which the rules are tested (their priorities) can be changed using the Up and Down buttons. For more information on creating triggers, 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 rules for triggers

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 under Attached rules on the second page of the New Trigger dialog box or on the Attached Rules page 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 Existing Rules dialog box 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 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). Otherwise, the condition will always be false.
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 arguments 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. 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.

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 past to the service. This is done by sending a notification message to the msmqtriggersnotifications 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.

Changing default configuration 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. The value of this setting should 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.


Running Message Queuing unattended setup

You can use Windows unattended setup to install Message Queuing software by remotely using an answer file. This file should 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.

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 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 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 non-domain 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 subcomponets will be installed automatically.

The keys appearing in entries in the [msmq] section are as follows:

ControllerServer

This key is set equal to the NetBIOS or DNS name of the Windows XP or Windows 2000 domain controller with which the independent client or routing server being installed on a domain computer should communicate in the specified site when msmq_ADIntegrated is set equal to ON. You may not have to specify this entry. Setup will try to find a suitable domain controller through AD.lib automatically. If it fails, however, unattended setup will not continue. If an entry is specified, unattended setup will use the entry and will not attempt to find the computer automatically.

Do not include an entry with this key if you are installing Message Queuing on a domain controller.

SupportingServer

This key is set equal 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.

ServerAuthenticationOnly

This key can be set equal to TRUE or FALSE, the default being FALSE. Include a ServerAuthenticationOnly = TRUE entry only for clients that will communicate with MSMQ 1.0 controller servers running Windows NT 4.0 and that will need to authenticate such servers. This key has no meaning when Message Queuing is being installed on a domain controller.

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.

Notes

  • 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]
  ControllerServer = MyDomainController
  SupportingServer = MyDomainControllerOrRoutingServer
  ServerAuthenticationOnly = FALSE | TRUE
  Site = DefaultFirstSiteName

Be sure to test your unattended setup script before deployment.


Upgrading Message Queuing

This section explains the requirements for upgrading the earlier versions of Message Queuing software (MSMQ 1.0 and 2.0) on computers that are being upgraded to the Windows XP operating system from earlier Windows operating systems.

  • Upgrade overview for Message Queuing
  • Upgrade requirements and considerations for Message Queuing
  • Upgrading your MSMQ 1.0 computers


Upgrade overview for Message Queuing

This topic provides an overview of upgrading from MSMQ 1.0, which runs on Windows NT 4.0, Windows 98, and Windows 95, and from Message Queuing 2.0, which runs on Windows 2000, to Message Queuing 3.0.

The Message Queuing software on all Windows 95, Windows 98, and Windows NT 4.0 computers, except for MSMQ 1.0 controller servers, and on Windows 2000 and Windows Me clients is automatically upgraded during Windows XP Setup. The MSMQ 1.0 primary enterprise controller (PEC) and primary site controllers (PSCs) are upgraded using the Message Queuing Upgrade Wizard, which automatically starts after Windows 2000 Server Setup is completed in conjunction with the Configure Your Server Wizard.

Important

  • Before you use the Message Queuing Upgrade Wizard, you should read the upgrade requirements and considerations first. Specifically, you should read the Upgrade requirements and considerations for Message Queuing first and then read Using the Message Queuing Upgrade Wizard.

Message Queuing 3.0, like Message Queuing 2.0, is compatible with MSMQ 1.0. Simultaneously running MSMQ 1.0 controller servers with the newer versions of the server software in a domain after upgrade of the PEC is referred to as mixed-mode operation. The process of upgrading all MSMQ 1.0 controller servers (the PEC, PSCs, and backup site controllers (BSCs)) to Message Queuing servers in your organization is referred to as migration.

Some elements of MSMQ 1.0 have counterparts with different names in Message Queuing 2.0 and 3.0. The following table lists these elements and their counterparts in the current version of Message Queuing:

Version for Windows NT 4.0 | Current version | Comments
Microsoft Message Queue Server (MSMQ) or MSMQ 1.0 | Message Queuing 3.0 | Message Queuing 3.0 may be referred to as MSMQ 3.0 in external literature and other external sources.
MSMQ enterprise | Windows 2000 forest | You cannot migrate more than one MSMQ 1.0 enterprise to a single Windows 2000 forest.
MSMQ site | Windows 2000 site | There are no longer MSMQ-specific sites.
MSMQ site link | routing link | A routing link defines the route for connectivity between two sites.
MQIS | Active Directory | Message Queuing is now fully integrated with Active Directory.
connected network | none | Connected networks are no longer used.
foreign connected network | foreign site | A foreign connected network is upgraded to a foreign site on Windows 2000.
MSMQ (or MQIS) controller server | Message Queuing server with routing enabled, or routing server | MSMQ controller servers, which provided both routing and directory services, included the primary enterprise controller (PEC), primary site controllers (PSCs), and backup site controllers (BSCs). A Message Queuing server must be running on a Windows 2000 domain controller if you need to provide directory services for Message Queuing objects to computers running MSMQ 1.0 and 2.0.
MSMQ routing server | Message Queuing server with routing enabled, or routing server | Routing servers can be configured as in-routing and out-routing servers as well as site gates.
MSMQ independent client (running on Windows NT 4.0 Server) | Message Queuing server without routing enabled | A Message Queuing server without routing enabled on a non-domain controller provides the same functionality as an MSMQ independent client running on Windows NT 4.0 Server.
MSMQ independent client (running on Windows NT 4.0 Workstation, Windows 95, or Windows 98) | independent client | Only an independent client can be installed on computers running Windows XP Professional.
MSMQ dependent client | dependent client | The new features in the current version, such as HTTP transport, Message Queuing Triggers, and sending messages to multiple destinations, are not available to dependent clients.
MSMQ Explorer | Microsoft Management Console (MMC) snap-ins | The snap-ins used for administering Message Queuing include Computer Management, Active Directory Users and Computers, and Active Directory Sites and Services.

For more information on terms and concepts used in MSMQ 1.0, see the Microsoft Message Queue Server Administrator's Guide.


Upgrade requirements and considerations for Message Queuing

This topic describes the requirements and considerations that need to be addressed if you are upgrading from MSMQ 1.0, which runs on Windows NT 4.0, Windows 98, and Windows 95, or from Message Queuing 2.0, which runs on Windows 2000.

The Message Queuing software on all Windows 95, Windows 98, and Windows NT 4.0 computers, except for MSMQ 1.0 controller servers, and on Windows 2000 and Windows Me clients is automatically upgraded during Windows XP Setup.

Subcomponent considerations

In any upgrade, Setup attempts to reproduce the Message Queuing functionality of the original computer by installing the applicable subcomponents. The following table describes the Messages Queuing subcomponents that are installed automatically during upgrades of Windows NT 4.0 and Windows 2000 computers to Windows XP Professional:

Subcomponent name | Description | Types of computers on which it is installed during upgrades from Windows NT 4.0 | Types of computers on which it is installed during upgrades from Windows 2000
Core | performs the most fundamental setup operations: creates and sets registry keys, and provides dependent client functionality | any computer with MSMQ 1.0 installed | any computer with Message Queuing 2.0 installed
Local Storage | installs the Message Queuing service and provides independent client functionality | any MSMQ 1.0 independent client | any Message Queuing 2.0 independent client
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 | any computer with MSMQ 1.0 installed | any computer on which the AlwaysWithoutDS registry subkey is equal to 0 or does not exist
Triggers | installs the Message Queuing Triggers service | none | none
MSMQ HTTP Support | creates an IIS extension for Message Queuing (MSMQ) | none | none

Notes

  • Message Queuing software is not upgraded during upgrades to Windows XP Home Edition.
  • The AlwaysWithoutDS subkey is stored the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\Setup registry key.
  • The Message Queuing Triggers add-on module is not removed during upgrades. After an upgrade, it can be uninstalled, and then the Triggers subcomponent can be installed by running Add or Remove Programs and selecting Triggers in the Windows Components Wizard.

After upgrading to Windows XP, some of the subcomponents can be removed and others can be installed by running Add or Remove Programs and clearing or selecting the check boxes for applicable subcomponents in the Windows Components Wizard. For more information on the Message Queuing subcomponents, see Subcomponents for Message Queuing Setup.

Upgrade restrictions

In addition to the installation restrictions discussed in the overview section, the following list of restrictions must be observed:

  • You can no longer create MSMQ sites if a Message Queuing server is running anywhere in your forest.
  • You can no longer create standard connected networks if a Message Queuing server is running anywhere in your forest. However, you can still create foreign connected networks.

Directory service considerations

MSMQ 1.0 used a Microsoft SQL Server-based database, called the MQIS database, to maintain configuration information for MSMQ computers, queues, and users. MSMQ 1.0 controller servers each held a copy of the MQIS database, which was fully replicated among the controller servers using a dedicated algorithm.

Message Queuing now uses the Active Directory directory service to store configuration information and cannot use the MQIS database. When an MSMQ 1.0 controller server is upgraded, the information stored in the MQIS database is automatically converted and stored in Active Directory.

In a mixed-mode environment, where at least one MSMQ 1.0 controller server remains and there is at least one Windows 2000 domain controller configured as a Global Catalog server and hosting a Message Queuing server, data replication takes place in both directions between your MSMQ 1.0 controller servers and Message Queuing servers, regardless of where a change in configuration was initiated.

The MSMQ MQIS Restore Wizard (available with Windows NT Service Pack 4) can be used to restore the MQIS database for a failed MSMQ 1.0 controller server. An MQIS database can be restored only from another PSC or from a BSC in a site that contains a PSC. An MQIS database cannot be restored from an upgraded MSMQ 1.0 controller server (which now uses Active Directory). While operating in a mixed-mode environment, care should be taken to have at least two controller servers, each of which can serve as a source for restoring the database on the other. When this is no longer possible, you should upgrade all remaining PSCs.

Message Queuing is now administered using Microsoft Management Console (MMC) snap-ins. However, an MSMQ 1.0 PSC remaining in a mixed-mode environment executes all changes to objects owned by it, regardless of where the changes are initiated. Thus, an object for an MSMQ 1.0 site that is created or modified using these snap-ins requires that the changes be executed on the MSMQ 1.0 PSC that is the owner of the object. This means that the applicable PSC must be online when an attempt is made to modify the object from a snap-in in cases where the client computer running the snap-in is communicating with a Windows 2000 domain controller or with another Windows NT 4.0 MQIS server. The changes are subsequently replicated throughout your Windows 2000 forest.

Connected network considerations

MSMQ 1.0 used the concept of connected networks in which any two computers can communicate directly. Advances in communication networks, the introduction of virtual private networks, and the momentum of Internet protocols have rendered the need for connected networks obsolete. Therefore, Message Queuing no longer supports connected networks.

If your organization does not have direct connectivity between all client computers and you previously made use of connected networks to define connectivity topology, you may need to configure your network during the migration process and after it is completed. Establishing routing links between sites can provide the same degree of connectivity that you previously had using connected networks. This will ensure that all messages can be routed to their destination.

For information on how to create routing links, see Create routing links.

Following are descriptions of some typical connected network scenarios with ways to configure your network after migration:

  • All computers in your organization use both the IP and the IPX protocols. There is no configuration required on your part. Messages will be routed using the IP protocol.
  • Some computers in your organization use only the IPX protocol, and some use only the IP protocol. The Message Queuing service no longer supports the IPX protocol. Therefore, you must add the IP protocol to any servers that use only the IPX protocol.
  • Your organization uses multiple disconnected IP networks. Consider adding routers or using remote access to provide connectivity. You can also configure disconnected IP networks as separate Windows 2000 sites.
  • Your organization uses foreign computers for messaging. Foreign computers are usually configured to forward messages to a Message Queuing server in a non-foreign site that is running a connector application. Such a Message Queuing server can also be used as the in-routing/out-routing server for foreign computers in the site. Consider placing such Message Queuing servers and all foreign computers in a single foreign site, and then create routing links to that site.

Administrative tool considerations

MSMQ Explorer was the administrative tool used to manage MSMQ objects on MSMQ 1.0 computers, and the Message Queuing utility in Control Panel was used for some administrative tasks in Windows 2000. These tools are no longer used, and MSMQ Explorer does not run on a Windows XP computer. Message Queuing is now administered using the Computer Management, Active Directory Users and Computers, and Active Directory Sites and Services snap-ins in MMC consoles.

In a mixed-mode environment, the Windows NT 4.0 primary enterprise controller (PEC) has been upgraded to a Windows 2000 domain controller configured as a Global Catalog server, and the remaining servers comprise a mixture that includes at least one Windows NT 4.0 MQIS server and any number of Windows 2000 computers. Such an environment will exist until the entire migration process is completed and all the Windows NT 4.0 MQIS servers in the enterprise are upgraded. If a Message Queuing client running Windows XP communicates with a Windows NT 4.0 MQIS server in such an environment, the MMC snap-ins can be used on the Windows XP computer to access information regarding the MSMQ configuration that is stored on the Windows NT 4.0 MQIS server and to view the properties of all the MSMQ objects on that computer. However, in this case, the Active Directory Users and Computers snap-in does not show the permissions associated with these objects on the security page. These permissions can be viewed either from the Computer Management snap-in or locally on the MSMQ 1.0 server by using MSMQ Explorer.

An MSMQ 1.0 client remaining in a mixed-mode or Windows 2000 environment uses MSMQ Explorer to manage its objects and to view objects on other computers.

Notes

  • There are no tools that let you manage an MSMQ 1.0 enterprise from a Windows XP computer.


Upgrading your MSMQ 1.0 computers

The primary enterprise controller (PEC) and each primary site controller (PSC) in a Windows NT 4.0 enterprise are upgraded using the Message Queuing Upgrade Wizard, which is available after Windows 2000 Server Setup from the Configure Your Server Wizard. Other MSMQ 1.0 software components are automatically upgraded from Windows NT 4.0 during Windows 2000 Setup.

As you upgrade all the MSMQ 1.0 controller servers in your enterprise, you must upgrade them in the following order:

  1. Upgrade the primary enterprise controller (PEC).
  2. Upgrade all the backup site controllers (BSCs) in a single site.
  3. Upgrade the primary site controller (PSC) in the same site.
  4. Repeat steps 2 and 3 in every site until all the controller servers are upgraded.

You do not need to complete upgrading computers in one site before you begin the upgrade process for another site. You can upgrade multiple sites simultaneously provided all the BSCs in a particular site are upgraded before the PSC of that site.

Using the Message Queuing Upgrade Wizard

This section pertains to using the Message Queuing Upgrade Wizard to upgrade the PEC and each PSC in your organization. Before you use the Message Queuing Upgrade Wizard, you should read Upgrade requirements and considerations for Message Queuing first.

Important

  • You must have enterprise administrative permissions or belong to the Enterprise Admins group to run the Message Queuing Upgrade Wizard.

After all upgrade requirements have been met, and you have promoted the MSMQ controller server to a Windows 2000 domain controller configured as a Global Catalog server and have logged on as a member of the Enterprise Admins group, you are ready to run the Message Queuing Upgrade Wizard. This wizard transfers the information contained in the MQIS database to Active Directory. The Message Queuing service on the upgraded computer is started when you have completed running the Message Queuing Upgrade Wizard.

The wizard first scans the MQIS database for errors and inconsistencies and saves the results to a log file for your inspection. Then the MQIS database is imported into Active Directory. It is highly recommended that you select the database scan option when prompted in the wizard and then select a logging type. This allows you to inspect the log file and decide whether to continue or cancel the wizard at that point.

Notes

  • If you need to run the wizard a second time on a computer, you must first stop and disable the Message Queuing service and the Message Queuing Replication service before you rerun the wizard. When the wizard has completed, you can restart the Message Queuing service.

Upgrading the MSMQ primary enterprise controller

The primary enterprise controller (PEC) is the first computer that is upgraded using the Message Queuing Upgrade Wizard. This computer must first be promoted to a Windows 2000 domain controller configured as a Global Catalog server and trusted for delegation.

For information on how to configure a computer as a Windows 2000 domain controller, see "Checklist: Installing a domain controller" in the Windows 2000 Server help. 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 information on how to set the delegation trust, see Make a domain controller trusted for delegation.

The Message Queuing replication service, which synchronizes data between Active Directory and the MQIS database on all other MSMQ 1.0 controller servers, starts only on the upgraded PEC computer. The Message Queuing service on the upgraded PEC computer must also be running for replication to occur. By default, replication occurs every 15 minutes. You cannot uninstall Message Queuing on this computer while the Message Queuing replication service is running. (Some PSCs or BSCs are not yet upgraded.) After the last controller server in your organization has been upgraded, the Message Queuing replication service will automatically stop.

If your organization consists of multiple Windows domains, the Message Queuing replication service must run under an enterprise administrative account (or belong to the Enterprise Admins group). For information on how to change the account under which a service runs, see Change the Message Queuing service account. Be sure and double-click Message Queuing Replication (instead of Message Queuing) in the details pane.

To support MSMQ 1.0 computers in a mixed-mode environment, where at least one Windows NT 4.0 controller server remains and there is at least one Windows 2000 domain controller configured as a Global Catalog server and hosting a Message Queuing server, the Message Queuing Upgrade Wizard automatically weakens security for Active Directory on the upgraded PEC computer. For more information, see Weakened security considerations.

Upgrading MSMQ backup site controllers

For each site, the BSCs must be upgraded before the PSCs are upgraded (except for the site containing the PEC, which is also the PSC for the site).

Backup site controllers (BSCs) are automatically upgraded during Windows 2000 Server Setup to Message Queuing servers with routing enabled, without any interaction on your part. If you promote the computer to a Windows 2000 domain controller during upgrade of the operating system, the upgraded server will provide access to Active Directory as well. In this case, the computer must be trusted for delegation also, as discussed previously.

Upgrading MSMQ primary site controllers

For each site, the BSCs must be upgraded before the PSC is upgraded (except for the site containing the PEC, which is also the PSC for that site). Each PSC computer must first be promoted to a Windows 2000 domain controller trusted for delegation, and it may also need to be configured as a Global Catalog server (if there is no other Message Queuing server running on a domain controller configured as a Global Catalog server in the local site).

The Message Queuing Upgrade Wizard compares the MQIS database on the PSC with Active Directory and corrects any inconsistencies between the two. If any inconsistency between the MQIS on the PSC and Active Directory is detected, Active Directory is changed to match the MQIS on the PSC computer. Therefore, it is important that all MSMQ 1.0 controller servers are synchronized before starting the upgrade process.

Upgrading MSMQ 1.0 routing servers and MSMQ 1.0 clients

MSMQ 1.0 routing servers, MSMQ 1.0 independent clients, and MSMQ 1.0 dependent clients are automatically upgraded during Windows 2000 Setup without any interaction on your part. During setup, if prompted, type the name of a Windows 2000 domain controller (of a supporting server for a dependent client) in the local site.

You are not required to upgrade these computers in a particular order.

The MSMQ Exchange Connector is no longer supported in Windows XP.


Uninstalling Message Queuing

To uninstall Message Queuing software from a computer, you must first be granted the Delete MSMQ Configuration Object permission. 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 Subcomponents for Message Queuing Setup.

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 objects in 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 should 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.


Securing Message Queuing

This section introduces the security concepts you must understand to install and use Message Queuing in your organization.

  • Security overview for Message Queuing
  • Access control for Message Queuing
  • Authentication for Message Queuing
  • Encryption for Message Queuing
  • Access auditing for Message Queuing


Security overview for Message Queuing

Message Queuing takes advantage of the various built-in security features of the Windows XP operating system. Specifically, Message Queuing uses access control, message authentication, encryption, and access auditing for security. These same security processes applied also to MSMQ 1.0. However, 128-bit encryption is now supported in addition to 40-bit encryption.

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.

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 2000 computers) and Windows NTLM (for compatibility with MSMQ 1.0 running on Windows NT 4.0). Thus, Kerberos V5 and NTLM are used for server authentication, which verifies a Message Queuing server to a client.

Kerberos V5 also provides for the delegation of queries from one domain controller to another if a suitable domain controller is not reached in one hop. Conversely, if a query made by a computer using NTLM does not reach a domain controller in the same domain as the sending computer in one hop, the session is ended.

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.

Encryption is implemented using both public key (asymmetric) and secret key (symmetric) algorithms. Encryption is used by Message Queuing applications to encrypt messages sent between Message Queuing computers.

Access 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 access events to be audited for the object.

By managing security properties for objects, you can set permissions, assign ownership, and monitor user access.

In addition, there are several other issues that must be taken into account before you configure security for Message Queuing in your network, as discussed in the following sections.

Weakened security considerations

Message Queuing servers running on Windows 2000 domain controllers can operate using weakened security for Active Directory. If used, weakened security is enabled during installation of the first Message Queuing server on a Windows 2000 domain controller in your forest. This setting is then replicated to all other domain controllers in every domain in your forest. Weakened security should be enabled if any of the following operating configurations apply to your organization:

  • A mixed-mode domain environment where users running MSMQ 1.0 (on Windows NT 4.0, Windows 98, or Windows 95) access Message Queuing servers running on Windows 2000 domain controllers for directory services. (This applies even if such users are logged on with Windows 2000 domain accounts.)
  • A Windows 2000 domain where users running Message Queuing (on Windows XP 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. (However, 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 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 2000 domain controllers will access Active Directory within its own security context under the LocalSystem account on the applicable domain controller to view the properties of Active Directory objects, particularly msmq (MSMQ configuration) objects and queue objects, or to check their security settings for pre-Windows XP clients, but it will not bypass any security restrictions on creating objects or setting their security.

For users running MSMQ 1.0, when the MSMQ service starts an RPC call to a Message Queuing server running on a Windows 2000 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 2000 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.

Message Queuing service account considerations

Unlike other programs, which are executed by a security principal (user or computer), services run in their own security context. To establish a security context, a service needs to log on to the system, just as security principals do. The Message Queuing service can run under either the LocalSystem account or a specific user account on a computer. The LocalSystem account is a standard authenticated domain user account in Windows 2000. The Message Queuing service runs under the LocalSystem account by default. You can change the account that this service runs under. This may be useful when you need to provide this service with specific permissions.

The following are advantages of using the LocalSystem account to run the Message Queuing service:

  • 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.

By default, if the Message Queuing service runs under the default LocalSystem account on all computers in an enterprise, members of the Authenticated Users group are 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. You should 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.

To provide more complete functionality, the user account should also be granted 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.

Other security considerations

Message Queuing guarantees the security of all messages sent from a source computer to a destination computer. To guarantee full security, the receiving application and the destination queue must reside on the same computer. This is because messages are stored as plaintext in the destination queue. The operation of accessing 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. Messages are not encrypted or authenticated when read remotely. However, Message Queuing does guarantee that messages have not been tampered with.

By default, Internet Information Services (IIS) uses a local user account, which is treated as an anonymous user account by other computers in the network. Active Server Page (ASP) applications and scripts run under IIS and thus impersonate the anonymous user when they send queries to Active Directory. Because anonymous users no longer belong to the Everyone group in Windows XP, these queries fail, ASP applications and scripts cannot locate, create, and delete queues, and messages sent using such scripts cannot successfully reach their destination queues. This situation can be corrected by running IIS under the domain user account of the user logged onto the computer where IIS is running or under a specified domain user account.

In this case, the computer must be trusted for delegation to allow multiple hops in communicating with a domain controller.

For information on how to change the security settings for IIS, see Change the security settings for Internet Information Services.


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 objects in 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 it, 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 Windows XP Professional, see "Access control" in the Windows 2000 Server help.

Using administrative groups

You can simplify the administration of access control by using one or more administrative user groups and then setting the appropriate permissions to each group. Then simply add individual users to the user group to grant them those permissions. For example, you can create a user group of Site Administrators for each site within your Windows 2000 forest. Then you can grant domain administrative permissions to the Site Administrators group for each Message Queuing server in that site.

For more information on administrative groups for Windows XP Professional, see "Built-in and predefined groups" in the Windows 2000 Server help.

Security descriptors for msmq objects

The msmq object is the parent object for the queues on any particular computer. 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 in Active Directory. Thus, which users are allowed to create queues on a computer is determined by the security descriptor for the msmq object on the applicable computer, which, in turn, is determined during Message Queuing Setup, as follows.

When you install an independent client or a Message Queuing server without routing (on a non-domain controller) in workgroup mode or in domain mode in a Windows 2000 forest, the default security descriptor for the msmq object allows the following users to create queues on such computers:

  • Users with domain or enterprise administrative permissions can create queues on the computer.
  • The user who ran Message Queuing Setup can create queues on the computer.
  • All users can create queues on a foreign computer.

When you install an independent client or a Message Queuing server without routing (on a non-domain controller) and you specify the name of an MSMQ 1.0 controller server (running Windows NT 4.0) during setup, the default security descriptor for the msmq object allows everyone to create queues on the computer.

When you install MSMQ 1.0 on a computer in a Windows 2000 domain, the default security descriptor for the msmq object allows everyone to create queues on the computer.

In a Windows 2000 forest, applications running on a Windows XP computer can create queues on that computer provided the computer can communicate with a Windows 2000 domain controller. Applications running on a pre-Windows XP computer can create queues only if the computer can communicate with a Windows 2000 domain controller hosting a Message Queuing server. In a Windows NT 4.0 enterprise, the client computer must be able to communicate with an MSMQ 1.0 controller server.

Setting permissions for msmq objects

In the Active Directory Users and Computers snap-in, the msmq object is a child object of the applicable computer object. Thus, an msmq object can be created and delected only by users who are granted the Create All Child Objects and Delete All Child Objects permissions, respectively, for the parent computer object. The msmq object is also referred to as the MSMQ Configuration object, for example, in names of specific permissions for this object and in the Delegation of Control Wizard.

You can change the default permissions provided by Active Directory for this object, and you can also set additional Message Queuing-specific permissions. By default, the Everyone group has the generic Read permission for an msmq object and is thus allowed to view its properties and security descriptors. By default, the Everyone group is granted the generic Create All Child Objects and Delete All Child Objects permissions for an msmq object, which are needed to create and delete queues, respectively.

The following table summarizes the Message Queuing-specific permissions that you can view and set for an msmq object. You can grant these permissions per user, or you can use the Delegation of Control Wizard to grant them to a group, such as the Authenticated Users group, in a domain.

Message Queuing permission | Allows a group or user to...
Peek Computer Journal | View the contents of the computer journal and peek at journal messages in it.
Peek Dead Letter | View the contents of the computer dead-letter queue and peek at messages in it.
Receive Computer Journal | Read (remove) journal messages from the computer journal.
Receive Dead Letter | Read (remove) dead-letter messages from the computer dead-letter queue.

When you grant either the Receive Dead Letter or Receive Computer Journal permission to a group or user, that group or user is also automatically granted the Peek Message permission. (The Receive Dead Letter and Receive Computer Journal permissions without the Peek Message permission are useless.)

For information on how to set permissions for an msmq object, see Set permissions for computer and queue objects.

For information on how to change the ownership of an msmq object, see Change ownership of computer and queue objects.

Setting permissions for queue objects

In the Active Directory Users and Computers snap-in, queue objects are child objects of the msmq object.

You can change the default permissions provided by Active Directory for queue objects, and you can also set additional Message Queuing-specific permissions for queues.

By default, the person who created a queue is granted the generic Full Control permission, and the Everyone group is granted the generic Write permission for a queue object. Users granted the Write permission for a queue can send messages to the queue.

When granted the generic Read permission for a queue, users can view only the properties and security descriptor for queues.

The following table summarizes the Message Queuing-specific permissions that you can set for a queue object. You can grant these permissions per user, or you can use the Delegation of Control Wizard to grant them to a group, such as the Authenticated Users group, in a domain.

Message Queuing permission | Allows a group or user to...
Peek Message | View the contents of the queue and queue journal and peek at messages in it.
Receive Journal | Read (remove) journal messages from the queue journal.
Receive Message | Read (remove) normal messages from the queue.

When you grant either the Receive Message or Receive Journal permission to a group or user, that group or user also automatically is granted the Peek Message permission. (Without the Peek Message permission, the Receive Message and Receive Journal permissions are useless.)

For information on how to set permissions for a queue object, see Set permissions for computer and queue objects.

For information on how to change the ownership of a queue object, see Change ownership of computer and queue objects.

Notes

  • Trust relationships between domains are required for sending messages to queues that restrict access. If a user sends a message to a queue that restricts who can send messages to it, the computer that owns the queue must be a member either of the same domain as the sender or of a domain that trusts that sender's domain. Otherwise, the message is rejected and access to the queue is denied. For general information on domains, see "Domains" in the Windows 2000 Server help.

Setting permissions for distribution lists

Distribution lists are public lists that are published as distribution group objects in Active Directory. The explicit members of a distribution list must be destinations published in Active Directory, that is, public queues, queue aliases, and other distribution lists.

Each distribution list has a Message Queuing DACL assigned to it. The following table describes specific permissions associated with distribution lists. You can grant these permissions per user, or you can use the Delegation of Control Wizard to grant them to a group or users in a domain.

Permission | Allows a group or user to...
Send To | To send messages to the applicable distribution list.
Add/Remove Self as Member (for a public queue or queue alias) | To add or remove the applicable public queue or queue as a member in a distribution list.
Add/Remove Self as Member (for a distribution list) | To add or remove the applicable distribution list as a member in another distribution list.

By default, everyone is granted the Send To permission and the Add/Remove Self as Member permission for a public queue or queue alias, but only the owner of a distribution list has the Add/Remove Self as Member permission for it. In addition, by default, all users can create distribution lists.

Messages cannot be read directly from distribution lists. Thus, read access is controlled at the ultimate target queues.

Setting permissions for routing link objects

In the Active Directory Sites and Services snap-in, each routing link object is a child object of the MsmqServices object. Thus, setting permissions for a routing link object means granting permissions to create or delete child objects (the Create All Child Objects and Delete All Child Objects permissions) to users for the parent MsmqServices object.

By default, only users with enterprise administrative permissions (users belonging to the Enterprise Admins group) have both of these permissions and can create, modify, and delete routing links if there are multiple domains in your organization. For users in the Domain Admins group to be able to modify or delete routing links, they need to be granted the Delete All Child Objects permission for the MsmqServices object.

You can change only the default permissions provided by Active Directory for this object. There are no Message Queuing-specific permissions for this object.

For information on how to set permissions for routing link objects, see Set permissions for routing link objects.

Setting permissions for MSMQ Settings objects

Setting permissions for an MSMQ Settings object means granting permissions to create or delete child objects for the parent server object. In the Active Directory Sites and Services snap-in, the MSMQ Settings object is a child object of the server object.

You can change only the default permissions provided by Active Directory for this object. There are no Message Queuing-specific permissions for this object.

For information on how to set permissions for MSMQ Settings objects, see Set permissions for MSMQ Settings objects.

Setting permissions for messaging files

By default, only members of the local Administrators group for a computer have full access to locally stored message files, log files, and LQS (local queue storage) files. No other users can access them.

By default, file-level access is set on the Storage and Lqs folders. Each time a new file is stored in either of these folders, the file inherits the security settings for that folder. However, if you move the message file to a different folder using the Computer Management snap-in, the security settings from the original folder are not copied to the new folder. Files that move from the default folders to the new folders move only with their own default security settings (not those of the Storage or Lqs folders).

For information on how to set permissions for locally stored message and log files, see Set permissions for Message Queuing files.

Notes

  • Folder-level and file-level access is available only on NTFS-formatted drives. Only folder-level access is available on FAT-formatted drives.


Authentication 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 XP and/or Windows 2000 computers) and Windows NTLM (for compatibility with MSMQ 1.0 running on Windows NT 4.0). Thus, Kerberos V5 and NTLM are used for server authentication, which verifies a Message Queuing server to a client.

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, however, Message Queuing applications that send or receive authenticated messages must use the cryptographic service provider installed by default with Windows XP, 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 XP Professional, see "Authentication" in the Windows 2000 Server help.

For more information on certificates for Windows XP Professional, see "Certificates overview" in the Windows 2000 Server help.

Message authentication

Message authentication is a process which confirms that no tampering has been done to a message. In addition, this process can be used to verify the identity of the user who sent the message.

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.

More specifically, on the source computer, the Message Queuing application 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 private cryptographic key for the source computer to create a digital signature.
  3. 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.

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.

Because this type of authentication requires queries to Active Directory, it cannot be used to authenticate messages when the receiving computer is in workgroup or offline mode.

For more information on cryptographic keys used by Message Queuing, see Cryptographic keys.

You can also send authenticated messages to foreign computers. 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.

The next sections provide more information on user certificates in greater.

User certificates

There are two types of user certificates, or public-key certificates, that Message Queuing can use: internal certificates and external certificates. Internal certificates are automatically created during Message Queuing Setup and can be used by everyone. 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 XP 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.

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" in the Windows 2000 Server help.

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 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, a Message Queuing application 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 application 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 has 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 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 you can obtain. 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.

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. In a mixed-mode domain environment, where a Message Queuing client may communicate with an MSMQ 1.0 controller server or, conversely, an MSMQ 1.0 client may communicate with a Message Queuing server, the method that a client uses to authenticate a server 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 XP | Windows 2000 domain controller | Kerberos V5
Message Queuing client running on Windows 2000 | Message Queuing server running on Windows 2000 | Kerberos V5
Message Queuing client on Windows XP or Windows 2000 | MSMQ 1.0 controller server running on Windows NT 4.0 | Windows NTLM (using a server certificate)
MSMQ 1.0 client running on Windows NT 4.0, Windows 98, or Windows 95 | Message Queuing server running on Windows 2000 | Windows NTLM (using a server certificate)

Server certificates are used to authenticate some Message Queuing servers. You need to create and register a server certificate only for those 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. Message Queuing clients running on Windows XP or Windows 2000 use Kerberos V5 to authenticate Windows 2000 servers.

If you have a Message Queuing client (running on Windows XP) that communicates with an MSMQ 1.0 controller server (running on Windows NT 4.0) and you want to authenticate this server, you must manually do so. For information on how to configure such clients to authenticate MSMQ 1.0 controller servers using server certificates, see Authenticate MSMQ 1.0 controller servers.

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 (HTTP-S) communication.

Authentication of HTTP messages

When messages sent over HTTP transport are authenticated, the sender attaches an XML digital signature and an internal or external user certificate, which contains the user's name, the user's public key, and the signature of the issuer. 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 certification authority (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 satisifed before an SSL session is established between the sender and the recipient.

For more information on obtaining external certificates from CAs and validating digital signatures attached to messages sent over HTTP transport within the same forest and between different forests, see Authenticating HTTP/HTTPS messages.

For more information on sending messages in SSL sessions over HTTPS transport, see HTTPS messages.


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 Microsoft Cryptographic Application Program Interface CryptoAPI, 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. It should be noted 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 cryptographic service provider (CSP) installed by default with Windows XP, 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 XP 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.

Notes

  • The U.S. version of Windows 2000 supports 128-bit encryption in addition to 40-bit encryption; however, non-U.S. versions of Windows 2000 do not support 128-bit encryption. In the U.S. version, the 128-bit CSP is called the Microsoft Enhanced Cryptographic Service Provider.

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. Because proper permissions are required for a user to access the destination computer and queue, clear-text messages on the destination computer are not a security concern. 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 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 Computer and Users (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

  • 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 XP Professional, see "Generating encryption keys and certificate requests" in the Windows 2000 Server help.

Cryptographic key renewal is a security feature of Message Queuing. It is a good idea to renew your cryptographic keys periodically, such as once a year. You should also 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 auditing for Message Queuing

You can use access 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 XP Professional, see "Auditing security events" in the Windows 2000 Server help.

The security log records audited operations, called audit messages, which you can view using Event Viewer. For more information on Event Viewer, see Event Viewer.

Configuring access auditing

Before you implement access auditing, you must first establish an audit policy. An audit policy specifies categories of security-related events that you want to audit. When you establish the audit policy for a Message Queuing server, the Manage auditing and security log permission must be granted for the Message Queuing server that will perform the audited operation. For information on how to establish an audit policy, see "Establish an audit policy" in the Windows 2000 Server help.

Next, you select the object access category and set auditing options for specific objects. When you have set the object access category, you can use the Properties page for individual Message Queuing objects to specify whether to audit successes or failures for the permissions granted to each group or user. For information on how to set auditing options for a computer (msmq) 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, an audit message is not created.

Notes

  • You may receive an error message stating that access auditing is not enabled. This indicates that access auditing is disabled or that no audit policy has been established on the computer that you are using; it does not mean that access auditing is not enabled on the computer for which you are trying to audit access.

Audit messages

Audit messages 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 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.

Figure showing how audit messages are created

When a queue is accessed, the audit message for this operation is always created on the computer on which the queue resides. Because all queue operations, except the Receive Message and Peek Message operation, are performed by a Message Queuing server, audit messages are created on the Message Queuing server that carried out the operation. Audit messages are created only when a queue is accessed, not each time a message is received or sent.

Each audit message has an Open entry and a Close entry in the security log. When a queue is accessed for a Receive Message or Peek Message operation, the Close audit entry is written to the log immediately after the Open entry is written to the log.


Administering Message Queuing

This section explains how to administer and monitor computers, queues, and other objects used by Message Queuing. Read these topics after you have installed Message Queuing and have configured security parameters for Message Queuing in your organization.

  • Administration overview for Message Queuing
  • Administering a Message Queuing network
  • Administering Message Queuing computers
  • Administering queues for Message Queuing
  • Administering messages for Message Queuing
  • Monitoring Message Queuing

This section does not contain information on setting security parameters. For information on protecting Message Queuing data in your organization, see Securing Message Queuing.


Administration overview for Message Queuing

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 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 a Windows XP or Windows 2000 computer. For Windows XP, Message Queuing is administered using the Computer Management, Active Directory Users and Computers, and Active Directory Sites and Services snap-ins in MMC consoles. For information on accessing information on a MSMQ 1.0 controller server from a Message Queuing client running Windows XP or Windows 2000 in a mixed-mode environment, see Administrative tool considerations.

Notes

  • This section does not discuss how to administer security for Message Queuing. For information on security for Message Queuing, see Security overview for Message Queuing.

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 2000 forest. For more information on the objects associated with Message Queuing, see Message Queuing objects in 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 information updates displayed, 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.

Important

  • The Active Directory Users and Computers snap-in and the Active Directory Sites and Services snap-in are not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. These snap-ins are required to administer a domain-based Message Queuing network or to access and display information in Active Directory. You can start these snap-ins by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-ins installed. This way, you can perform domain-based administrative tasks and access Active Directory from a Message Queuing computer running Windows XP Professional. For more information, see Administration tools.

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 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 to store message and log files on
  • Register, remove, renew, and view user certificates
  • Change and view the server certificate
  • Renew cryptographic keys
  • Specify whether or not to use server authentication when communicating with MSMQ 1.0 controller servers
  • 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 and messages 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" in the Windows 2000 Server help.

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 properites

The shortcut link used in the procedures (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 on them)
  • 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 procedures (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.


Administering a Message Queuing network

This section describes how to configure those Message Queuing properties that apply in a domain environment on a network-wide level, such as configuring Message Queuing routing links and foreign sites. You use the Active Directory Sites and Services snap-in to perform administrative tasks on a network-wide level. Also discussed is how to configure your firewall to allow communications between Message Queuing computers on your internal network and on external networks.

Configuring routing links

Message Queuing uses routing links to route messages between sites. When a new Windows 2000 site is created, you should 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. You should create multiple routing links to provide load balancing and redundancy.

For information on how to create a routing link, see Create routing links.

Notes

  • By default, only users having enterprise administrative permissions (or belonging to 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 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 Set permissions for routing link objects.

All routing links are assigned a default link cost of 1. You should 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 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 at all, 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. All sites in your organization should be interconnected using routing links.

For information on how to change the Message Queuing servers used for a routing link, see Change site gates for a routing link.

For more general information on routing links and site gates, see Intersite routing.

Configuring foreign sites and foreign computers

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 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. Common examples of Message Queuing connector applications are Microsoft MSMQ-MQSeries Bridge and Message Queuing Connector (MQC). 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 2000 site that will communicate with the foreign site. A Message Queuing 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. Moreover, if the site gate in a routing link to the foreign site becomes unavailable, the site gates in other sites that communicate with the foreign site cannot route messages to the applicable connector queue for transmission to computers in the foreign site. Site gates are always associated with a particular routing link. For this reason, you should create multiple routing links to the foreign site if possible.

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 Configuring routing links.

Using Microsoft 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 on Microsoft Host Integration Server 2000, refer to the Microsoft Host Integration Server Web site (http://www.Microsoft.com/hiserver/).

Using Message Queuing Connector

Message Queuing Connector (MQC) is a connector application used to communicate between computers running Message Queuing applications on Windows-based operating systems and computers running Message Queuing applications on non-Windows-based operating systems. MQC is included on the disc sets for the Windows 2000 Server family and can be installed on a computer that is running a Message Queuing server. To send a message to a foreign computer running a non-Windows-based operating system, you must first acquire and install client software available from Level 8 systems. Some foreign computers function similarly to dependent clients and thus require a Message Queuing server running MQC as their supporting server. For more information on MQC, see the documentation provided with MQC. MQC is located on the disc sets for the Windows 2000 Server family in the Valueadd\3rdparty\Level8\Mqc.que folder.

For more information on the client software required in such a case, see the documentation provided by Level 8 Systems or refer to the Level 8 Systems Web site (http://www.level8.com/index.cfm?handle=gmq).

Message Queuing, Microsoft MSMQ-MQSeries Bridge, and MQC can be used in conjunction to provide organization-wide connectivity. For example, you can send messages between computers running Message Queuing on UNIX and computers running IBM MQSeries on AS/400.

Configuring a firewall

You can configure your organization's firewall to allow Message Queuing computers located on either side of the firewall to communicate with each other. This includes 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).

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 quues 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.
  • MQPing operates over UDP port 3527.

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.


Administering Message Queuing computers

This section describes how to configure and manage Message Queuing computers on your network. Generally, you use the Computer Management and Active Directory Users and Computers snap-ins to perform administrative tasks on a computer-wide level.

Joining a domain from a workgroup

Message Queuing can be used in an environment that is not part of a Windows 2000 domain, such as a computer that is part of a Windows XP 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 Windows XP computer running Message Queuing can join any new Windows 2000 domain. For Windows XP computer running Message Queuing 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 2000 domains. For information on how to join a domain from a workgroup, see Join a domain from a workgroup.

In Windows 2000, directory service functionality is configured by the user. When a Message Queuing server has been configured with directory service functionality, this functionality will be provided whenever that computer is promoted to a domain controller.

For information on the operating restrictions of running Message Queuing in a nondomain environment, see Workgroup mode.

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.

In-routing and out-routing servers should 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/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.

Adding or removing sites from the list of sites where a routing server resides

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.

Moving mobile computers to a new site

Windows XP computers can be moved to other Windows 2000 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 XP 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.

Using remote access with 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, you should 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 even not be able to send or receive messages.

When using remote access for clients, be wary of 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 servers, see "Remote access" in the Windows 2000 Server help.

Changing the supporting server for a dependent client

Dependent clients require synchronous access to a Message Queuing server, called 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. When you install a dependent client, you designate its supporting server. You can also later change the supporting server.

For information on how to change 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.

Notes

  • 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 have Windows NT Service Pack 4 or higher installed or else transactional messaging will not function.

Setting computer quotas for messages

Computer quotas specify the cumulative limit for all messages stored in all queues on a computer. When a computer quota is reached, messages can no longer be sent to the computer, 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.

For background information on quotas, see Quotas for messages.

For information on how to set a computer quota for normal messages, see Set the message storage size limit for computers.

For information on how to set a computer quota for journal messages, see Set the journal storage size limit for computers.

Storing messaging 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 more information on determining the number of disks to use, see Number of disks.

For information on how to store messaging files on multiple disks, see Store messages on multiple disk drives.

Configuring DNS settings

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, then the DNS settings (for example, the DNS server addresses) must be configured properly on each computer for Message Queuing to resolve computer names correctly.

You should also 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 2000 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.

Testing computer 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.


Administering queues for Message Queuing

This section describes how to manage and configure 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 for Message Queuing.

Creating, finding, and deleting queues

There may be certain restrictions on creating queues on computers that are determined during Message Queuing Setup. For more information, see Security descriptors for msmq objects.

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 Setting permissions for queue objects.

There are certain internal private queues that are used exclusively for internal operation. These include interim queues that store and forward messages in transit to a destination queue. The Active Directory Users and Computers and Computer Management snap-ins do not display any internal private queues. Consequently, if a message is currently in an interim queue, it does not appear in any queue in these snap-ins.

Notes

  • You may receive an error indicating insufficient resources when running multiple Message Queuing applications (or multiple instances of an application) that retrieve messages from a remote queue. For information on how to resolve this problem, see Troubleshooting administration problems for Message Queuing.
  • When using the Computer Management snap-in, transactional messages in outgoing queues cannot be viewed.

Changing queue properties

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, open, or delete queues of a specific type. 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 Computer and Users (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. For general information on message encryption, see Encryption for Message Queuing.

You can also specify whether or not 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 Message authentication.

Setting queue quotas for messages

Queue quotas specify the cumulative limit for messages stored in a particular queue. When a queue quota is reached, messages can no longer be sent to the queue until 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 limit for queues.

For information on how to set a queue quota for journal messages, see Set the journal storage size limit 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.

Pausing and resuming outgoing queue operation

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.

Sending a test message to a queue

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.

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 in order 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).

For information on how to send a test message, see Send test messages.


Administering messages for Message Queuing

This section describes how to administer messages for Message Queuing, including how to view and purge messages, how to set the default lifetime of messages, and how to view or set message properties.

You can use the Computer Management snap-in or the Active Directory Users and Computers snap-in to administer messages. For more information, see Administration overview for Message Queuing.

For information on monitoring transactional messages, see Monitoring transactional messages.

Reading 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 Setting permissions for queue objects.

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.

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, 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.

Changing message properties

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. For information on how to set the lifetime of messages on your network, see Set the default lifetime for messages.

You can view various properties for messages. For information on how to view message properties, see View message properties.

You can also 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 information on how to change which message properties are displayed, see Change the message property columns displayed.

Tracking messages

You can track the passage of messages from a source computer to a target queue by sending test messages, and you can 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.

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, 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 a test message to a queue.

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 along the way.

There are two basic requirements for using message route tracking. 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 how to enable message route tracking, see Enable message route tracking. For information on the Message Queuing SDK (to set properties programmatically), see the 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 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.


Monitoring Message Queuing

This section discusses how you can monitor Message Queuing events using Event Viewer, monitor Message Queuing performance using System Monitor, and monitor Message Queuing transactions using the Component Services snap-in when the Microsoft Distributed Transaction Coordinator (DTC) is running.

Monitoring events

Message Queuing logs information about its operation to the Windows XP event logs. Message Queuing events are located in the Source column under "Message Queuing." Most events are written to the Application Log. Security-related events are written to the security 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 XP 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 once 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 Access auditing for Message Queuing.

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
  • MSMQ Replication Service

For more information on System Monitor, see "System Monitor overview" in the Windows 2000 Server help.

Note

  • Performance counters are not available when multiple instances of Message Queuing are running in a server cluster.

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 counters that monitor the total number of bytes in messages count all the bytes in messages, including all the bytes in all of their properties.

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 XP 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. 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 by virtue of the fact that the computer name listed in the counter instance does not match the name of the computer on which the 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.

MSMQ Replication Service performance object

The MSMQ Replication Service performance object is visible only in mixed-mode environments when the MSMQ 1.0 primary enterprise controller (PEC) has been upgraded to a Message Queuing server running Windows 2000 and the Message Queuing replication service is running. The counters under this object monitor various performance statistics when data are replicated with an MSMQ 1.0 controller server running Windows NT 4.0.

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.

For more information on determining how many disks to plan for on your servers, see Number of disks.

Monitoring transactional messages

Message Queuing uses the Microsoft Distributed Transaction Coordinator (DTC), provided with Windows XP, 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, or two-phase, 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.


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 open the introductory topic on Message Queuing in the Platform SDK section of the MSDN Library, in Contents, click Message Queuing.

    Where?

    • MSDN Library
    • Platform SDK
    • Networking and Directory Services
    • Networking and Directory Services\Network Communication
    • Message Queuing

To access the Message Queuing SDK on the Web, refer to the MDSN 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).
  • For information on computer-based training solutions from Integrity eLearning, Inc., formally known as Integrity Training, Inc., refer to the Integrity eLearning Web site (http://www.ielearning.com).
  • For more information about solutions from Level 8 Systems for connectivity to non-Windows platforms, refer to the Level 8 Systems Web site (http://www.level8.com/index.cfm?handle=gmq).
  • For more information about message-queuing software in general, refer to the MessageQ.Com Web site (http://www.messageq.com).

Notes

  • Web addresses can change, so you may be unable to connect to some of the Web sites mentioned here.

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.


Troubleshooting

This section provides problem-solving guidelines when installing, upgrading, and administering Message Queuing.

  • Troubleshooting installation problems for Message Queuing
  • Troubleshooting upgrade problems for Message Queuing
  • Troubleshooting administration problems for Message Queuing
  • Troubleshooting Message Queuing Triggers


Troubleshooting installation problems for Message Queuing

This topic provides guidelines for solving problems associated with installing new Message Queuing software or running Message Queuing Setup.

When encountering installation problems, you should always inspect the setup log files first. This is especially important when you perform an unattended setup because there is no way for you to know whether something went wrong. The Message Queuing setup log file, Msmqinst.log, is located in the Windows folder (typically C:\Windows). If this file does not pinpoint the problem, you should next look at the Windows XP setup log file, Setuperr.log, which is located in the system folder (typically C:\Windows\System32).

What problem are you having?

You have completed Windows XP Setup but cannot find Message Queuing

Cause: Message Queuing is not installed by default during Windows XP Setup.

Solution: Install Message Queuing after Windows XP is installed using Add or Remove Programs in Control Panel.

See also: Installation overview for Message Queuing

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.

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 2000 enterprise

Cause: For a Windows XP computer, Setup was unable to automatically locate a Windows 2000 domain controller in the local site or a nearby site. For a pre-Windows XP computer, Setup was unable to automatically locate a suitable Windows 2000 domain controller running Message Queuing in the local site. Such a domain controller must be present in a site before Message Queuing can be installed on other pre-Windows XP computers in that site.

Solution: Do the following:

  1. Verify that both the computer on which you are running Message Queuing Setup and the domain controller have network connectivity.
  2. For a pre-Windows XP computer, verify that the Message Queuing service is running on the domain controller.
  3. For a pre-Windows XP computer, specify the DNS name or NetBIOS name of a Windows 2000 domain controller hosting a Message Queuing server in the local site. If no such domain controller exists, you can enter the name of an MSMQ 1.0 controller server instead.

See also: Installation overview for Message Queuing

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


Troubleshooting upgrade problems for Message Queuing

This topic provides guidelines for solving problems associated with upgrading your MSMQ 1.0 controller servers or running the Message Queuing Upgrade Wizard.

When encountering installation problems, you should always look at the setup log files first. This is especially important when you perform an unattended setup because there is no way for you to know whether something went wrong. The Message Queuing setup log file, Msmqinst.log, is located in the Windows folder (typically C:\Windows). If this file does not pinpoint the problem, you should next look at the Windows XP Setup log file, Setuperr.log, which is located in the system folder (typically C:\Windows\System32).

What problem are you having?

You cannot run the Message Queuing Upgrade Wizard

Cause: You must have enterprise administrative permissions or belong to the Enterprise Admins group to run the Wizard.

Solution: Add yourself to the Enterprise Admins group.

Cause: There is no Global Catalog server in the site in which you are running the Wizard.

Solution: Configure a Windows 2000 domain controller in the local site as a Global Catalog server. In addition, you must have at least one domain controller that is running Windows NT 4.0 online in each domain in which you run the Message Queuing Upgrade Wizard.

Cause: Microsoft SQL Server is not running on the computer.

Solution: Start the services for SQL Server.

Cause: The Message Queuing service may be running while you are trying to run the wizard a second time on a computer (such as when the wizard detected errors or inconsistencies in the MQIS database).

Solution: Stop the Message Queuing service, and then run the Message Queuing Upgrade Wizard again.

See also: Upgrade requirements and considerations for Message Queuing; Upgrading your MSMQ 1.0 computers

The Message Queuing Upgrade Wizard was unable to import the MQIS database successfully

Cause: The wizard scans the MQIS database first for errors before importing it to Active Directory. There may be errors or inconsistencies in the MQIS database that the wizard was unable to resolve.

Solution: Do the following:

  1. Rerun the wizard, and when prompted, select the Scan database and log results only check box and select a logging type.
  2. Inspect the log file and resolve any errors.

See also: Upgrading your MSMQ 1.0 computers


Troubleshooting administration problems for Message Queuing

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 any administrative tools or menu shortcuts for Message Queuing

Cause: Message Queuing is administered using extensions to the Computer Management, Active Directory Users and Computers, and Active Directory Sites and Services snap-ins in MMC consoles.

Solution: Open the Computer Management, Active Directory Users and Computers, or Active Directory Sites and Services snap-ins as needed.

If you want to manage a dependent client, you must refer to the supporting server.

Solution: On Windows XP Professional, only the Computer Management snap-in is installed by default. The Active Directory Users and Computers snap-in and the Active Directory Sites and Services snap-in are not provided with Windows XP Professional and cannot be installed on a Windows XP Professional computer by installing Windows 2000 Administration Tools. These snap-ins are required to administer a domain-based Message Queuing network or to access and display information in Active Directory. You can start these snap-ins by opening Remote Desktop Connection on your Windows XP Professional computer to access Terminal Services on a Windows 2000 domain controller or member server that has the snap-ins installed. This way, you can perform domain-based administrative tasks and access Active Directory from a Message Queuing computer running Windows XP Professional.

See also: Administration overview for Message Queuing; Administration tools

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 click Start. Then 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 should be able to 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.

You can save these changes so that these views are always enabled by default 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 objects in Active Directory

You are not allowed to 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 pre-Windows XP clients, this service must run under the LocalSystem account on Windows 2000 domain controllers.

Solution: Verify that the Message Queuing service is running under the LocalSystem 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 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 2000 domain controller that is configured as a Global Catalog server, or the server certificate has expired or does not exist. 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 and has a valid server certificate.

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.

See also: "Replication" and "Configure Replication" in the Windows 2000 Server help.

Windows NT 4.0 clients and local users cannot access Active Directory

Cause: Weakened security was not selected during 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, and 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 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 XP Resource Kit to weaken security.

See also: Weakened security considerations

You are not allowed to 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: Viewing queues

You are not allowed to create queues

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

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

See also: Setting permissions for msmq objects

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: Configuring 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 XP 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: User certificates, Authentication for Message Queuing

All 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.

See also: Setting permissions for queue objects

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: Reading messages

Messages can no longer be sent 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:

  1. By requesting negative acknowledgment messages and checking their class (This technique is applicable to queue quotas, not to computer quotas.).
  2. 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 computer quotas for messages; Setting queue quotas for messages

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 losses.).

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 2000 may not have Windows NT Service Pack 4 (SP4) installed. SP4 or later is required for transactional messaging.

Solution: Install Windows NT 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 the test message has the correct queue type ID. You should 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 a test message to a queue

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 LQS (local queue storage) files.

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

See also: Setting permissions for messaging files

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: Access auditing for Message Queuing.

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.

MSMQ 1.0 clients cannot authenticate a Message Queuing server

Cause: When operating in a mixed-mode environment, MSMQ 1.0 clients use server certificates to authenticate Message Queuing servers. The server certificate for the applicable server may be missing or may not be registered in Active Directory.

Solution: Create and register a server certificate for every Message Queuing server that responds to queries from MSMQ 1.0 clients.

See also: Server authentication.

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.

An insufficient resources error is displayed when running multiple applications that retrieve messages from a remote queue

Cause: When a Message Queuing application retrieves a message from a remote queue, a thread is created on the local computer (the computer on which the application is running on). There is a default maximum of 64 threads on a Message Queuing server and a default maximum of 16 threads on an independent client that can be created for this purpose.

Solution: Use the Registry Editor to increase the setting of the MaxRRThreads entry as needed. This entry does not appear in the registry unless you first add it using the Registry Editor or change it afterward. To increase this setting, do the following:

  1. To open Registry Editor, click Start, click Run, and then enter regedt32.exe.
  2. Click the registry subkey Parameters.

    Where?

    • HKEY_LOCAL_MACHINE
    • SOFTWARE
    • Microsoft
    • MSMQ
    • Parameters
  • Click Edit, and then click Add Value.
  • In the Add Value dialog box, in Value Name, enter MaxRRThreads; in Data Type, click the click the arrow that opens the list, select REG_DWORD, and then click OK.
  • In the DWORD Editor dialog box, in Data, enter the new (decimal) value; under Radix, click Decimal, and then click OK.

    • Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

    Notes

    • These threads are created on demand and will exist for as long as the Message Queuing service is running on the local computer.

    Resources for Message Queuing have timed out on 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.

    See also:"Cluster resource" in the Windows 2000 Server help.


Troubleshooting Message Queuing Triggers

This topic discusses the most common problems encountered in using Message Queuing Triggers.

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 LocalSystem account, which has sufficient permissions to run the Message Queuing Triggers service, or grant yourself the necessary permissions.

Cause: The Message Queuing Triggers service has crashed. In-process Component Object Model (COM) components that are invoked can sometimes crash and thereby cause the Message Queuing Triggers service to crash.

Solution: Rectify the condition that causes the COM component to crash, and then restart the Message Queuing Triggers service.

Cause: The Message Queuing Triggers service is unresponsive. This can happen if the action invoked (and the associated EXE or COM component) is blocked.

Solution: Wait for the blocked component to be able to continue.

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 queue(s), 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.

The processing of messages by the Message Queuing Triggers service slows disproportionately as more messages arrive at a monitored queue.

This behavior is normal when the Message Queuing Triggers service runs under heavy loads. It occurs because the maximum number of threads is reached. You can accelerate the processing of messages by increasing the maximum number of allowable threads.


This program could not start.

The operating system could not start this program. Some possible solutions are:

If your computer is on a network, contact your system administrator.

If a system administrator controls your computer, you should ask the administrator why you cannot start the program. Your administrator may have removed the program or set a policy that prevents you from starting it.

Install the necessary hardware.

Some programs are installed automatically when you install the hardware associated with them. To install new hardware click Start, point to Settings, click Control Panel, and then double-click Add New Hardware.

Install the necessary software.

The program might not be installed on your computer because:

  • It is an optional component. To install optional components click Start, point to Settings, click Control Panel, and then double-click Add or Remove Programs.
  • You have not installed the hardware that uses this program. To install new hardware click Start, point to Settings, click Control Panel, and then double-click Add New Hardware.
  • If your computer is on a network, your system administrator may have removed this program or set a policy that prevents you from starting it.

Re-install the program file.

The program file may have been accidentally deleted or corrupted. If you know the name of the file that is missing, you can copy the compressed version from the operating system installation compact disc to your hard drive, and then restore it by doing the following:

  1. Insert the installation compact disc.
  2. Click Browse the CD.
  3. In the folder list, open either the Alpha or I386 folder.
  4. Find the name of the missing file.

    NOTE: The last letter in the file name extension will be replaced by an underscore because it is a compressed version of the file. For example, notepad.exe is called notepad.ex_ on the installation compact disc.

  5. Copy the compressed file to your systemroot\System32 folder on your hard drive.
  6. Click Start, point to All Programs, and then click Command Prompt.
  7. At the command prompt, type:
    expand %systemroot%\system32\my_file_name.ex_ %systemroot%\system32\my_file_name.exe
    and then press ENTER.


Copyright

Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results of the use of this document remains with the user. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Additionally, any public network IDs or addresses referenced in this document are for demonstration/example purposes only. Microsoft's inclusion of such IDs and addresses in this document does not grant you any express or implied right to test or otherwise use or access any such network ID or address.

The links in this area will let you leave Microsoft's product and/or Web site. The linked sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement by Microsoft of the site.

For your convenience, Microsoft may make available on this service or in its software products, tools and utilities for use and/or download. Microsoft does not make any assurances with regard to the accuracy of the results or output that derives from such use of any such tools and utilities. Please respect the intellectual property rights of others when using the tools and utilities made available on this service or in Microsoft software products.

Active Directory, BackOffice, JScript, Microsoft, Microsoft Press, MSDN, MS-DOS, Visual Basic, Visual C++, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other regions and/or countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

© 1997-2001 Microsoft Corporation. All rights reserved.


About this Help file

The topics in this Help file are integrated into Help and Support Center. To view these topics, click Start, and then click Help and Support.


Configure store and forward servers

To configure store and forward servers

This documentation is not available in this preliminary release.