Message Queuing

Message Queuing is a messaging infrastructure and a development tool for creating distributed, loosely-coupled, messaging applications for the Windows 2000 operating system. Such applications can communicate across heterogeneous networks and with computers that may be offline. Message Queuing provides guaranteed message delivery, efficient routing, security, transactional support, and priority-based messaging.

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

  • Before you begin installing or upgrading Message Queuing, see the Checklists.
  • To find features that have been moved in Windows 2000, see New ways to do familiar tasks.
  • For tips about using Message Queuing, see Best practices.
  • For step-by-step help with specific tasks, see How to....
  • For general background information, see Concepts.
  • For problem-solving guidelines, see Troubleshooting.


Checklists

This section provides checklists for upgrading your existing MSMQ 1.0 controllers, and for installing Message Queuing server and client software on new computers.

  • Checklist: Upgrade for MSMQ 1.0 controller servers
  • Checklist: Installation for Message Queuing servers
  • Checklist: Installation for Message Queuing clients


Checklist: Upgrade for MSMQ 1.0 controller servers

Use this checklist when upgrading MSMQ 1.0 controller servers, such as the PEC, PSCs, and BSCs. You must use the Message Queuing Upgrade wizard to upgrade the PEC and each PSC to Message Queuing servers.

You must upgrade your MSMQ 1.0 controller servers in the following order:

  1. The primary enterprise controller (PEC).
  2. Then the backup site controllers (BSCs) in each site.
  3. Then the primary site controllers (PSCs) in each site.

For information on upgrading MSMQ 1.0 on a server cluster, see Upgrading MSMQ 1.0 on a server cluster.

Step | Reference
Before upgrading the operating system, back up and export the key certificate from Windows NT 4.0 if this computer will support MSMQ 1.0 clients. | To export key certificates from Windows NT 4.0
After Windows 2000 Server Setup is finished, review important upgrade concepts and requirements. You must upgrade your MSMQ 1.0 controller servers in a specific order. | Upgrade requirements and considerations for Message Queuing
Log on with enterprise administrative permissions. This is required to run the Message Queuing Upgrade wizard later. | Upgrade requirements and considerations for Message Queuing
Promote the PEC computer to a Windows 2000 domain controller. | Follow the Configure Your Server wizard
If the computer has been promoted to a domain controller, verify the computer is trusted for delegation. | To set the delegation trust for a computer
For the PEC computer, configure the computer as a Global Catalog server. | To set a computer as a Global Catalog server; Upgrade requirements and considerations for Message Queuing
Run the Message Queuing Upgrade wizard. When prompted, select the database scan option and then select a logging type. View the resultant log file as needed. (This does not apply for BSC computers.) | Follow the Message Queuing Upgrade wizard
Verify the Message Queuing service has started. For the upgraded PEC computer, verify the Message Queuing Replication service has also started. | To start or stop services for Message Queuing
Import the key certificate you previously exported, if this computer will support MSMQ 1.0 clients. | To import server certificates for Message Queuing
Create a routing link, if this computer will be used as a site gate to route messages to another site. | To create routing links
Send a test message. | To send test messages

Note

  • This checklist should be repeated for each MSMQ 1.0 controller server that you want to upgrade. 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, as long as you observe the proper upgrade order.


Checklist: Installation for Message Queuing servers

Use this checklist when installing Message Queuing server software on computers that do not have MSMQ 1.0 installed. Message Queuing is not installed by default during Windows 2000 Setup.

Step | Reference
Review key concepts and determine the server functionality needed. | Components of Message Queuing
Review installation requirements. | Installation overview for Message Queuing
Log on with the appropriate administrative permissions. | Installation permissions
For the first installation of Message Queuing in your organization, and for each Windows 2000 site, promote the computer to a Windows 2000 domain controller. | Follow the Configure Your Server wizard.
For each Windows 2000 domain controller, verify the computer is trusted for delegation. | To set the delegation trust for a computer
For one installation in each Windows 2000 site, configure the domain controller as a Global Catalog server. | To set a computer as a Global Catalog server
If this is not the first installation in a site, verify a Message Queuing server running on a Windows 2000 domain controller is available in the same site you are installing in. | Installation overview for Message Queuing
Run Message Queuing Setup and select the services needed. | To install Message Queuing servers
For the first installation of Message Queuing in your organization, when prompted during Setup, weaken permissions if this computer will support Windows NT 4.0 or local users. | Weakened security considerations
Verify the Message Queuing service has started. | To start or stop services for Message Queuing
Create a server certificate, if this computer will support MSMQ 1.0 clients. | To create server certificates for Message Queuing
Create a routing link, if this computer will be used as a site gate to route messages to another site. | To create routing links
Send a test message. | To send test messages


Checklist: Installation for Message Queuing clients

Use this checklist when installing Message Queuing client software on computers that do not have MSMQ 1.0 installed. Message Queuing is not installed by default during Windows 2000 Setup.

Step | Reference
Review key concepts and determine the client functionality needed. | Components of Message Queuing
Review the installation requirements. | Installation overview for Message Queuing
Log on with local administrative permissions. | Installation permissions
Verify a Message Queuing server running on a Windows 2000 domain controller is available in the same site you are installing in. | Installation overview for Message Queuing
Run Message Queuing Setup and select the client type. | To install independent clients; To install dependent clients
Verify the Message Queuing service has started. | To start or stop services for Message Queuing
If this computer will need to authenticate MSMQ 1.0 controller servers running Windows NT 4.0, enable this feature. (This does not apply to dependent clients.) | To authenticate MSMQ 1.0 controller servers
Send a test message. | To send test messages


New ways to do familiar tasks

This table lists common tasks for Message Queuing. The user interface for performing these tasks is different in Windows 2000 than it was in 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 2000 use
Set access control, set 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 To 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 or IPX/SPX properties for Message Queuing computers | Network in Control Panel | Open Network and Dial-up Connections in Control Panel. For more information, see To 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.

Note

  • The Active Directory Users and Computers snap-in and the Active Directory Sites and Services snap-in are not provided with Windows 2000 Professional. These snap-ins are required to administer a domain-based Message Queuing network or to access information in Active Directory. You can install these snap-ins, along with other administrative tools used to remotely administer servers, by installing Windows 2000 Administration Tools, which is provided on the Windows 2000 Server disc set. In this way, you can perform domain-based administrative tasks and access Active Directory from a Message Queuing computer running Windows 2000 Professional. For more information, see Managing servers remotely.


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, there are several additional requirements that must be met and other issues that should be considered before you can successfully upgrade Message Queuing in your organization. For example, you must upgrade your 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.
    • To ensure that the broadcast request that independent clients generate during automatic site recognition will be answered.

    In addition, to support MSMQ 1.0 clients running Windows NT 4.0 and to improve performance, at least one Message Queuing server should be installed on a Windows 2000 domain controller that is configured as a Global Catalog server in every Windows 2000 site.

    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 as well as Active Directory access, install these servers on different computers. For example, install a Message Queuing server with routing enabled on a nondomain controller computer, and install another Message Queuing server on a Windows 2000 domain controller to provide Active Directory access.

  • Install Message Queuing servers on multiple domain controllers.

    For increased 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 are comprised of site gates, which are Message Queuing servers configured to route messages between sites.

    For more information, see Message routing between sites.

    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 Message routing within a site.

    • Message Queuing client in this context 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 should a hard disk fail. 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, 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 other MSMQ 1.0 controllers 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 journal queues and dead letter queues often. For information on how to perform this task, see To purge all messages in a queue.

  • Do not store more than 1.6 GB of messages per computer.

    Although the theoretical message storage maximum is 2.0 GB per computer, there is disk storage overhead with using Message Queuing that must be taken into account. Therefore, it is recommended that you store no more than approximately 1.6 GB to 1.8 GB of messages on a computer.

    For computer running Windows 2000 Advanced Server, do not store more than approximately 2.6 GB to 2.8 GB of messages on a computer.

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

    To minimize use of the Windows 2000 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 To 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 messages for Message Queuing
  • Monitor and test Message Queuing


Install Message Queuing

  • To set a computer as a Global Catalog server
  • To set the delegation trust for a computer
  • To set install permissions for MSMQ 1.0
  • To install Message Queuing servers
  • To install independent clients
  • To install dependent clients
  • To install the MSMQ Exchange Connector
  • To configure Message Queuing resources for server clusters
  • To uninstall Message Queuing
  • To uninstall the MSMQ Exchange Connector


Set a computer as a Global Catalog server

To set a computer as a Global Catalog server

  2. In the console tree, right-click NTDS Settings.

    Where?

    • Active Directory Sites and Services
    • Sites
    • your applicable site
    • Servers
    • your applicable server
    • NTDS Settings
  3. Click Properties.
  4. On the General tab, select the Global Catalog Server check box.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • Each site that operates in mixed-mode must contain at least one Message Queuing server running on a domain controller that is configured as a Global Catalog Server. This is required to support MSMQ clients running Windows NT 4.0 in a Windows 2000 site.

Related Topics


Set the delegation trust for a computer

To set the delegation trust for a computer

  3. In the console tree, right-click the applicable domain controller.

    Where?

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

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • If this property is disabled for the domain controller, the Message Queuing service cannot run.

Related Topics


Set install permissions for MSMQ 1.0

To set install permissions for MSMQ 1.0

  2. In the console tree, right-click Computers (or applicable organizational unit).

    Where?

    • Active Directory Users and Computers
    • your_domain
    • your_organizational_unit (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 only authenticated users permission to install Message Queuing, under Name, click Authenticated Users, click Add, and then click OK.
    • To allow everyone permission to install Message Queuing, under Name, click Everyone, click Add, and then click OK.
  6. On the Group or User Selection page, click Next.
  7. On the Predefined delegations page, click Custom task, and then click Next.
  8. On the Active Directory Object Type page, click Objects in folder, select the Computer objects check box, and then click Next.
  9. On the Permissions page, under Filter options, click to clear the Show general permissions check box, and then select the Show creation/deletion of subobject permissions check box.
  10. Under Permissions to delegate, select the Create MSMQ Configuration objects check box, select the Delete MSMQ Configuration objects check box, and then click Next.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, 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.
  • The Delete MSMQ Configuration Objects permission is required to uninstall Message Queuing.

Related Topics


Install Message Queuing servers

To install Message Queuing servers

  1. Open Add/Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components. In the Windows Components wizard, click Next.
  3. Select the Message Queuing Services check box, and then click Next.
  4. In the Message Queuing Installation wizard, click Message Queuing server.
  5. To provide message routing services, select the enable routing check box.
  6. Follow the remaining instructions in the wizard.

Notes

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
  • For each site running Windows 2000, you must install a Message Queuing server on a domain controller running Windows 2000 before you can install Message Queuing on other computers in the same site.
  • A Message Queuing server cannot be installed on computers running Windows 2000 Professional.
  • You can choose to install a Message Queuing server without routing on a nondomain controller in workgroup mode if the computer is part of a Windows 2000 workgroup. In this case, direct connectivity is required to send messages.

Related Topics


Install independent clients

To install independent clients

  1. Open Add/Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components. In the Windows Components wizard, click Next.
  3. Select the Message Queuing Services check box, and then click Next.
  4. In the Message Queuing Installation wizard, click Independent client.
  5. If prompted, type the DNS or NetBIOS name of a Message Queuing Server running on a domain controller in the local site.
  6. Follow the remaining instructions in the wizard.
  7. If prompted about restarting your computer now, click Yes to allow Setup to complete.

Notes

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
  • Independent clients are installed only on computers running Windows 2000 Professional.
  • You must install a Message Queuing Server on a domain controller in the local site before you can install an independent client.
  • If a Message Queuing server on a domain controller in the local site cannot be accessed or does not exist, Setup will continue and will install Message Queuing in workgroup mode. Workgroup mode of operation requires direct connectivity to send messages.
  • You can also choose to 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.

Related Topics


Install dependent clients

To install dependent clients

  1. Open Add/Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components. In the Windows Components wizard, click Next.
  3. Select the Message Queuing Services check box, and then click Next.
  4. Click Dependent client.
  5. If prompted, type the DNS or NetBIOS name of a Message Queuing Server in the local site.
  6. When prompted about restarting your computer, click Yes to allow Setup to complete.

Notes

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
  • If a Message Queuing server in the local site 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.

Related Topics


Install the MSMQ Exchange Connector

To install the MSMQ Exchange Connector

  1. On your hard disk, locate the Winnt\System32 folder and double-click the Mqexchng.exe file to start the MSMQ Exchange Connector Setup program.
  2. Click Continue, and then click Install.
  3. In Choose Server, type the name of the server that you want the MSMQ Exchange Connector to use, and then click Continue.
  4. In Choose Site, click the name of the site for the server you entered, and then click Continue.
  5. In the Install dialog box, type all the following information, and then click Continue.
    • In Inbound Queue, type the label of the queue from which the MSMQ Exchange Connector reads incoming messages.

      If the queue does not exist, it is created by the MSMQ Exchange Connector when it starts.

    • In Service Account, type the name of the user account (using the domain\user name format) for the MSMQ Exchange Connector service to use.
    • In Service Password, type the domain password for the user account specified in Service Account.
    • In Service folder, type the path to a folder in which to store the MSMQ Exchange Connector program files.

      For example, type C:\exchq. If the folder does not exist, Setup creates it.

Notes

  • The MSMQ Exchange Connector cannot be installed on computers running Windows 2000 Professional.
  • If used, you only need to install one MSMQ Exchange Connector in your Microsoft Exchange enterprise.
  • The following applies only to computers running Windows 2000 Advanced Server: If you are installing the MSMQ Exchange Connector on a server cluster, it is recommended that you install the MSMQ Exchange Connector on a separate node than the node that Microsoft Exchange Server is installed on.

Related Topics


Configure Message Queuing resources for server clusters

To configure Message Queuing resources for server clusters

  1. Click Start, point to Programs, point to Administrative Tools, and then click Cluster Administrator.
  2. Click the Groups folder.
  3. In the details pane, click the cluster group to which you want resources for Message Queuing to belong.
  4. On the File menu, point to New, and then click Resource.
  5. In the New Resource wizard, create a resource for Message Queuing, and type the appropriate information in Name and Description. In Resource type, select Message Queuing, and then click Next.
  6. On the Possible Owners page, click Add as needed to add nodes shown in Available nodes to Possible owners, and then click Next.
  7. On the Dependencies page, under Available resources, click Network Name, click Disk, and then click Add. When completed, click Finish.
  8. Click the Resources folder. In the details pane, click the the resource you just created. On the File menu, click Bring Online.
  9. To manage the resource you just created from the Computer Management snap-in, create another resource by repeating steps 2 through 5. In the the New Resource wizard, in Resource type, select Generic Application.
  10. On the Generic Application Parameters page, in Command line, type:

    cmd.exe

    Select the Allow application to interact with desktop check box, select the Use Network Name for computer name check box, and then click Next.
  11. Repeat step 7. Under Available resources, click Network Name, click the resource you previously created in step 5, and then click Add. When completed, click Finish.
  12. Repeat step 8.
  13. In the dialog box, type compmgmt.msc.

Notes

  • This task is performed on a computer that is part of a server cluster and is running Windows 2000 Advanced Server.
  • All Message Queuing applications that run in the context of a cluster group (that are cluster-aware) depend on the Network Name resource and the resource you create for Message Queuing. Repeat steps 9 through 13 to properly configure resources for such applications.
  • Once created, do not rename resources for Message Queuing.

Related Topics


Uninstall Message Queuing

To uninstall Message Queuing

  1. Open Add/Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components wizard, click Next.
  4. Click to clear the Message Queuing Services check box, and then click Next.
  5. When asked if you want to permanently delete the storage files created by MSMQ, click Yes.

Note

  • To open Add/Remove Programs, click Start, point to Settings, click Control Panel, and then double-click Add/Remove Programs.
  • When uninstalling Message Queuing in a multi-domain environment, you should wait for Active Directory replication to occur before attempting to reinstall Message Queuing on the same computer.

    • Related Topics


Uninstall the MSMQ Exchange Connector

To uninstall the MSMQ Exchange Connector

  1. On your hard disk, locate the Winnt\System32 folder and double-click the Mqexchng.exe file to start the MSMQ Exchange Connector Setup program.
  2. Click Remove.
  3. Click the connector you want to remove, and then click Continue.


Administer a Message Queuing network

  • To create routing links
  • To change the cost for a routing link
  • To change site gates for a routing link
  • To create foreign sites
  • To add foreign computers to a site


Create routing links

To create routing links

  2. On the View menu, click Show Services Node.
  4. Point to New, and then click MSMQ Routing Link.
  5. In Site 1 and in Site 2, use the DOWN ARROWS to select the two sites between which you want to route messages.
  6. In routing link cost, change the cost if necessary.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • All routing links are assigned a default cost of 1. You should only change routing link costs in the case where you have multiple routing links and you want to enforce one route over another route using link cost. In that case, you can assign costs that reflect the differences in the communications costs.
  • Costs can range from 1 to 4,294,967,295.
  • By default, only users in the Enterprise Admins group can create or modify routing links if there are multiple domains in your organization. For users in the Domain Admins group to be able to create or modify routing links, they will need to be granted the Create All Child Objects permission for the MsmqServices object. For information on how to set permissions for routing links, see Related Topics.

Related Topics


Change the cost for a routing link

To change the cost for a routing link

  2. On the View menu, click Show Services Node.
  3. In the console tree, click MsmqServices.

    Where?

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

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • All routing links are assigned a default cost of 1. You should only change routing link costs in the case where you have multiple routing links and you want to enforce one route over another route using link cost. In that case, you can assign costs that reflect the differences in the communications costs.
  • Costs can range from 1 to 4,294,967,295. A cost of zero indicates that two sites are not connected.
  • By default, only users in the Enterprise Admins group can create or modify routing links if there are multiple domains in your organization. For users in the Domain Admins group to be able to create or modify routing links, they will need to be granted the Create All Child Objects permission for the MsmqServices object. For information on how to set permissions for routing links, see Related Topics.

Related Topics


Change site gates for a routing link

To change site gates for a routing link

  2. On the View menu, click Show Services Node.
  3. In the console tree, click MsmqServices.

    Where?

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

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • By default, only users in the Enterprise Admins group can create or modify routing links if there are multiple domains in your organization. For users in the Domain Admins group to be able to create or modify routing links, they will need to be granted the Create All Child Objects permission for the MsmqServices object. For information on how to set permissions for routing links, see Related Topics.

Related Topics


Create foreign sites

To create foreign sites

  2. On the View menu, click Show Services Node.
  4. Click New Foreign Site.
  5. Type a name for the new site.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.

Related Topics


Add foreign computers to a site

To add foreign computers to a site

  2. On the View menu, click Show Services Node.
  4. Click New Foreign Computer.
  5. In Name, type the name of the foreign computer, and in Site, type the name of the foreign site to which the computer will be added to.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • 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.

Related Topics


Administer Message Queuing computers

  • To join a domain from a workgroup
  • To add Message Queuing servers to a site list
  • To remove Message Queuing servers from a site list
  • To specify a new site for mobile clients
  • To change in-routing or routing-servers
  • To change the supporting server for a dependent client
  • To view the dependent client list for a server
  • To set the message storage size for computers
  • To set the journal storage size for computers
  • To store messages on multiple disk drives
  • To set DNS properties for Message Queuing
  • To start or stop services for Message Queuing
  • To remove Message Queuing objects from Active Directory
  • To configure the MSMQ Exchange Connector


Join a domain from a workgroup

To join a domain from a workgroup

  1. Open System in Control Panel.
  2. On the Network Identification tab, click Properties.
  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.
  • You can also 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.


Add Message Queuing servers to a site list

To add Message Queuing servers to a site list

  4. Click Properties.
  5. Click the Sites tab, and in All Sites, select a site to add the server to, and then click Add.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The Message Queuing server is not actually added to a site during this operation; it is merely added to the site list maintained for in-routing and out-routing servers.

Related Topics


Remove Message Queuing servers from a site list

To remove Message Queuing servers from a site list

  4. Click Properties.
  5. Click the Sites tab, and in ComputerName Sites, select a site to remove the server from, and then click Remove.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The Message Queuing server is not actually added to a site during this operation; it is merely added to the site list maintained for in-routing and out-routing servers.

Related Topics


Specify a new site for mobile clients

To specify a new site for mobile clients

  2. Click the Mobile tab, and in New Site, use the DOWN ARROW and select the site that the independent client will move to.
  3. When prompted, click Restart Windows Now.

Notes

  • To open Message Queuing, click Start, point to Settings, click Control Panel, and then double-click Message Queuing.
  • This task does not apply to dependent clients, Message Queuing servers with routing enabled, or Message Queuing servers installed on domain controllers.
  • You should select the new site before disconnecting the client from the network. In this way, messages are routed to the new site while the client is in transit.

Related Topics


Change in-routing or routing-servers

To change in-routing or routing-servers

  4. Click Properties.
  5. Click the Routing tab.
  6. To change an in-routing server used, under In Routing Servers, use the DOWN ARROW to select a new Message Queuing server; select none to remove a particular Message Queuing server used as an out-routing server.
  7. To change an out-routing server used, under Out Routing Servers, use the DOWN ARROW to select a new Message Queuing server; select none to remove a particular Message Queuing server used as an out-routing server.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • This task is applicable only for, and is performed from, independent clients and Message Queuing servers without routing enabled that are installed on a nondomain controller.
  • 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.
  • You should assign more than one in-routing and out-routing server per client. This provides load balancing and failure recovery.

Related Topics


Change the supporting server for a dependent client

To change the supporting server for a dependent client

  2. On the MSMQ Client tab, type the name of the supporting Message Queuing server.

Notes

  • This task is performed from the dependent client.
  • If you have a previous 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 installed.

Related Topics


View the dependent client list for a server

To view the dependent client list for a server

  4. Click Properties.
  5. Click the Dependent Clients tab, and then click Refresh to ensure that the list is current.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, 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.

Related Topics


Set the message storage size for computers

To set the message storage size for computers

  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

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • 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.

Related Topics


Set the journal storage size for computers

To set the journal storage size for computers

  4. Click Properties.
  5. On the General tab, 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 journal queues on the selected computer.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • When the journal storage size is reached, journal messages cannot be sent to any journal queues on the computer until the cumulative size of journal messages in all queues drops below the specified limit.
  • Journal messages in journal queues can include source journal messages, dead-letter messages, and transaction dead-letter messages. It does not include messages in target journal queues.
  • For information on how to set the message storage size limit (or quota) for a computer, see Related Topics.

Related Topics


Store messages on multiple disk drives

To store messages on multiple disk drives

  2. On the Storage tab, type a different drive letter, as applicable in Message Files Folder, Message Logger Folder, or Transaction Logger Folder.
  3. If prompted to stop the Message Queuing Service, click Yes.
  4. If prompted, click Restart Windows Now.

Notes

  • By default, Message Queuing stores all message files, log files, and transaction log files in the Winnt\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.

Related Topics


Set DNS properties for Message Queuing

To set DNS properties for Message Queuing

  1. Open Network and Dial-up 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 tab, click Advanced.
  6. Click the DNS tab.
  7. In DNS domain name, type the name of the domain the DNS server is located in.

Notes

  • To open Network and Dial-up Connections, click Start, point to Settings, click Control Panel, and then double-click Network and Dial-up 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.

    Where?

    • Computer Management
    • Services and Applications
    • Services
  3. In the details pane, do the following:
    • For the Message Queuing service, right-click Message Queuing.
    • For the Message Queuing replication service, right-click Message Queuing Replication Service.
    • For the MSMQ Exchange Connector service, right-click MSMQ Exchange Connector Service.
  4. To start an applicable service, click Start.
  5. To stop an applicable service, click Stop.

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


Remove Message Queuing objects from Active Directory

To remove Message Queuing objects from Active Directory

  4. Click Delete. When prompted, click Yes.
  6. In the details pane, right-click Msmq Settings.

    Where?

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

Notes

  • For computers running Windows 2000 Professional, the Active Users and Computers and the Active Directory Sites and Services snap-ins are not provided; consequently you cannot perform this task unless these snap-ins are installed. You can use Windows 2000 Administration Tools to install these snap-ins on a computer running Windows 2000 Professional. For more information, see Managing servers remotely.
  • 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.

Related Topics


Configure the MSMQ Exchange Connector

To configure the MSMQ Exchange Connector

  1. Run Exchange Administrator and connect to the applicable computer running Exchange Server in your Exchange site.
  2. Click the applicable site next to Configuration.
  3. Click Connections.
  4. Double-click MSMQ Connector (queue label), where queue label is the name of the MSMQ connector queue that receives inbound messages.

    The MSMQ Connector Properties dialog box appears.

  5. On the Options tab, do one or more of the following:
    • To enable the processing of inbound messages, select the Enable Inbound check box.

      Or, to disable processing, clear this check box.

    • To specify the maximum number of threads that can be used to process inbound messages, type a number in Inbound Threads.
    • To enable the processing of outbound messages, select the Enable Outbound check box.

      Or, to disable processing, clear this check box.

    • To specify the maximum number of threads that can be used to process outbound messages, type the number in Outbound Threads.

Notes

  • If the message-processing load is greater in one direction than in the other, or if the computer is not processing messages fast enough, increase the number of threads as needed.
  • By default, both inbound processing and outbound processing are enabled. Four threads are used for inbound processing, and four for outbound processing.
  • For more information on using Exchange Administrator, see your Microsoft Exchange Server documentation.

    • Related Topics


Administer security for Message Queuing

  • To set permissions for computer and queue objects
  • To set permissions for routing link objects
  • To set permissions for MSMQ Settings objects
  • To set permissions for Message Queuing files
  • To change ownership of computer and queue objects
  • To change the Message Queuing service account
  • To audit access to computer and queue objects
  • To audit access to routing link objects
  • To export key certificates from Windows NT 4.0
  • To import server certificates for Message Queuing
  • To create server certificates for Message Queuing
  • To change server certificates for Message Queuing
  • To authenticate MSMQ 1.0 controller servers
  • To register certificates for Message Queuing
  • To remove certificates for Message Queuing
  • To view certificates for Message Queuing
  • To renew certificates for Message Queuing
  • To renew cryptographic keys for Message Queuing
  • To weaken security using ADSI Edit


Set permissions for computer and queue objects

To set permissions for computer and queue objects

  3. In the console tree, right-click msmq or the applicable queue.

    Where?

    • Active Directory Users and Computers
    • your_domain
    • your_organizational_unit (such as Computers or Domain Controllers)
    • your_computer
    • msmq
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  4. To grant Message Queuing-specific permissions for the computer, right-click msmq, and then click Properties.

    Or, to grant permissions for a queue on the computer, double-click msmq, double-click the applicable queue folder, right-click the applicable queue, and then click Properties.

  5. On the Security tab, set permissions for the object specified in Step 5, as needed:
    • To grant object permissions to an existing user or group, in Name, select the applicable user or group, and then in Permissions, select the applicable check box next to each applicable permission under the Allow column.
    • To remove object permissions from a user or group, in Name, select the applicable check box next to each applicable permission under the Deny column.
    • 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 you just created and select the applicable check boxes as needed.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • This procedure can be used to set permissions for any Message Queuing object under, and including, the msmq object.

Related Topics


Set permissions for routing link objects

To set permissions for routing link objects

  3. Right-click MsmqServices, and then click Properties.
  4. On the Security tab, set permissions as needed:
    • To grant object permissions to an existing user or group, in Name, select the applicable user or group, and then in Permissions, select the check boxes next to Create All Child Objects and Delete All Child Objects under the Allow column.
    • To remove object permissions for a user or group, in Name, select the check boxes next to Create All Child Objects and Delete All Child Objects under the Deny column.
    • 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 you just created and select the applicable check boxes as needed.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The Create All Child Objects permission and the Delete All Child Objects permission are required for creating and deleting routing links.

Related Topics


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 applicable server object.

    Where?

    • Active Directory Sites and Services
    • Sites
    • your_site_object
    • Servers
    • your_server_object
  3. Click Properties.
  4. On the Security tab, set permissions as needed:
    • To grant object permissions to an existing user or group, in Name, select the applicable user or group, and then in Permissions, select the check boxes next to Create All Child Objects and Delete All Child Objects under the Allow column.
    • To remove object permissions for a user or group, in Name, under the Deny column, select the check boxes next to 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 you just created and select the applicable check boxes as needed.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.

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 Winnt\System32\Msmq), and then click Properties.
  3. On the Security tab, in Name, click Administrators.
  4. In Permissions, under Allow, select the Full Control check box.
  5. In Name, select any user or group you do not want to access the Message Queuing files directly, and click Remove. Repeat this step as needed.

Note

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


Change ownership of computer and queue objects

To change ownership of computer and queue objects

  3. In the console tree, right-click msmq or the applicable queue.

    Where?

    • Active Directory Users and Computers
    • your_domain
    • your_organizational_unit (such as Computers or Domain Controllers)
    • your_computer
    • msmq
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  4. To change ownership of the computer (the msmq object), right-click msmq, and then click Properties.

    Or, to change ownership of a queue on the computer, double-click msmq, double-click the applicable queue folder, right-click the applicable queue, and then click Properties.

  5. On the Security tab, click Advanced.
  6. On the Owner tab, in Change Owner to, click a new user or group, and then click OK.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, 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 allowed Full Control permissions for the object.
  • There can be only one owner per Message Queuing computer or queue.

Related Topics


Change the Message Queuing service account

To change the Message Queuing service account

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

    Where?

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

Notes

  • To open Computer Management, click Start, point to Programs, point to Administrative Tools, and then click Computer Management.
  • 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.
  • The Message Queuing service must run under the LocalSystem account on domain controllers running Windows 2000 in order to access objects in Active Directory.
Related Topics


Audit access to computer and queue objects

To audit access to computer and queue objects

  2. In the console tree, click Active Directory Users and Computers.
  3. In the console tree, right-click msmq or the applicable queue.

    Where?

    • Active Directory Users and Computers
    • your_domain
    • your_organizational_unit (such as Computers or Domain Controllers)
    • your_computer
    • msmq
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  4. To audit access to the computer, right-click msmq and then click Properties.

    Or, to audit access to a queue on the computer, double-click msmq, double-click the applicable queue folder, right-click the applicable queue, and then click Properties.

  5. On the Security tab, click Advanced.
  6. On the Auditing tab of the Access Control Settings dialog box, click Add.
  7. In the Select User, Computer, or Group dialog box, in Name, click a user or group to audit access for, and then click OK.
  8. In the Auditing Entry dialog box, in Apply onto, click the applicable objects to audit user access to; then, under Access, select the appropriate check boxes next to the applicable entries, and then click OK.

    Or, to clear all audit entries, click Clear All.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The information generated by an audit is stored in the Windows 2000 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 msmq object.
  • Before you perform this task, you must first enable auditing by establishing an audit policy for the local computer.

Related Topics


Audit access to routing link objects

To audit access to routing link objects

  2. In the console tree, click MsmqServices.

    Where?

    • Active Directory Sites and Services
    • Services
    • MsmqServices
  3. In the details pane, right-click a routing link, and then click Properties.
  4. On the Security tab, click Advanced.
  5. On the Auditing tab of the Access Control Settings dialog box, click Add.
  6. In the Select User, Computer, or Group dialog box, in Name, click a user or group to audit access for, and then click OK.
  7. In the Auditing Entry dialog box, in Apply onto, click the applicable objects to audit user access to; then, under Access, select the appropriate check boxes next to the applicable entries, and then click OK.

    Or, to clear all audit entries, click Clear All.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The information generated by an audit is stored in the Windows 2000 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 auditing by establishing an audit policy for the local computer.

Related Topics


Export key certificates from Windows NT 4.0

To export key certificates from Windows NT 4.0

  1. On your computer that is running Windows NT 4.0 and Internet Information Services 4.0, open Internet Services Manager.
  2. In the console tree, right-click Default Web Site, and then click Properties.
  3. Click the Directory Security tab, click Edit under Secure Communications, click Key Manager, and select the key certificate you want to use for Windows 2000.
  4. On the Key menu, point to Export Key, click Backup File, and type the file name for the backup file.

Notes

  • To open Internet Services Manager on a computer running Windows NT 4.0, click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager.
  • This task applies only if you are upgrading an MSMQ 1.0 controller server to a Message Queuing server.
  • You must export the key certificate before you upgrade the computer to Windows 2000. Then you can import the certificate to Windows 2000. You need to import a server (key) certificate only for each Message Queuing server that will reply to Active Directory queries from MSMQ clients running on Windows NT 4.0, Windows 95, or Windows 98.

Related Topics


Import server certificates for Message Queuing

To import server certificates for Message Queuing

  1. Click Start, click Run, type mmc, and then click OK.
  2. Click Console, and then 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, click Default Web Site.

    5. Where?

    • Console Root
    • Internet Information Services
    • YourComputerName
    • Default Web Site
  5. On the Action menu, click Properties.
  6. Click the Directory Security tab, and then click Server Certificate. In the Web Server Certificate wizard, click Next.
  7. Click Import a certificate from a Key Manager backup file, and then click Next.
  8. Enter the path and file name for the backup file you previously created when you exported the certificate from Windows NT 4.0, and then click Next.
  9. Type the proper password, click Next, and then click Finish.
  10. After you have obtained the certificate,
  11. Click the Server Certificate tab, and then click Select a Certificate for Server Authentication.
  12. Under Issued to, select the certificate with the name of the Message Queuing server you imported the certificate to, and then click OK.

Notes

  • You can open the Internet Information Services snap-in after you have added it to a console by clicking Start, pointing to Programs, pointing to Administrative Tools, and then clicking Internet Services Manager.
  • This task applies only if you are upgrading an MSMQ 1.0 controller server to a Message Queuing server.
  • You must first export the key certificate before you upgrade the computer to Windows 2000. Then you can import the server certificate. You need to import a server (key) certificate only for each Message Queuing server that will reply to Active Directory queries from MSMQ clients running on Windows NT 4.0, Windows 95, or Windows 98.

Related Topics


Create server certificates for Message Queuing

To create server certificates for Message Queuing

  1. Click Start, click Run, type mmc, and then click OK.
  2. On the Console menu, click Add/Remove Snap-in.
  3. In the Add/Remove Snap-in dialog box, click Add, select Certificates, and then click Add.
  4. In the Certificates snap-in dialog box, click Computer account, click Next, click Finish, click Close, and then click OK.
  5. In the console tree, double-click Certificates, double-click Personal, right-click Certificates, point to All Tasks, and then click Request New Certificate.
  6. Follow the instructions that appear in the Certificate Request wizard. When prompted to type a name for the certificate, type the name of the local Message Queuing server.
  7. After you have obtained the certificate,
  8. Click the Server Certificate tab, and then click Select a Certificate for Server Authentication.
  9. Under Issued to, select the certificate with the name of the applicable Message Queuing server, and then click OK.
  10. When prompted, click Restart Windows Now.

Notes

  • You can open the Certificates snap-in after you have added it to a console by clicking Start, pointing to Programs, pointing to Administrative Tools, and then clicking Certificates.
  • You need to create a server certificate only for each Message Queuing server that replies to Active Directory queries from MSMQ clients running on Windows NT 4.0, Windows 95, or Windows 98.

Related Topics


Change server certificates for Message Queuing

To change server certificates for Message Queuing

  2. Click the Server Certificate tab, and then click Select a Certificate for Server Authentication.
  3. In the Choose MSMQ Server Certificate dialog box, select the applicable certificate, and then click OK.
  4. When prompted, click Restart Windows Now.

Notes

  • This task is performed from the Message Queuing server.

Related Topics


Authenticate MSMQ 1.0 controller servers

To authenticate MSMQ 1.0 controller servers

  2. On the Security tab, click Use secured connections if communicating with a Windows NT 4.0 MSMQ 1.0 controller server, and then click Certification Authorities.
  3. In the Certification Authorities dialog box, click System Certificates.
  4. When prompted, click Yes.
  5. Click to clear those certification authorities you do not want to use or do not trust for secured communications, and then click OK.

Notes

  • This procedure is applicable only for clients running Windows 2000 that communicate with MSMQ 1.0 controller servers running Windows NT 4.0.

Related Topics


Register certificates for Message Queuing

To register certificates for Message Queuing

  2. On the Security tab, under User Certificates, click Register.
  3. In the Personal Certificates dialog box, click a certificate, and then click Register.

Notes

  • 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. You can use this procedure to create and register an internal user certificate if one does not exist, such as when a certificate is removed. 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.

Related Topics


Remove certificates for Message Queuing

To remove certificates for Message Queuing

  2. On the Security tab, under User Certificates, click Remove.
  3. In the Personal Certificates dialog box, click the applicable user certificate, and then click Remove.

Note

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

Related Topics


View certificates for Message Queuing

To view certificates for Message Queuing

  2. Click the Security tab, and then under User Certificates, click View.
  3. In the Personal Certificates dialog box, click a certificate, and then click View Certificate.

Note

  • You can view all user certificates that are registered in Active Directory.

Related Topics


Renew certificates for Message Queuing

To renew certificates for Message Queuing

  2. On the Security tab, under Internal Certificate, click Renew Internal Certificate.

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

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

Related Topics


Renew cryptographic keys for Message Queuing

To renew cryptographic keys for Message Queuing

  2. On the Security tab, under Cryptographic Keys, click Renew Cryptographic Keys.

    A warning appears, stating that incoming messages will be encrypted with a cryptographic key your computer does not have. You will not be able to read those messages.

  3. 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 some other time.

  4. Click Restart Windows Now.

Notes

  • This task does not apply to dependent clients.

Related Topics


Weaken security using ADSI Edit

To weaken security using ADSI Edit

  1. Click Start, point to Programs, point to Resource Kit, and then click Tools Management Console.
  2. In the console tree, click Tools A to Z.

    Where?

    • Microsoft Resource Kits
    • Windows 2000 Resource Kit
    • Tools A to Z
  3. In the details pane, double-click ADSI Editor.
  4. In the console tree, right-click ADSI Edit, and then click Connect to.
  5. Under Connection Point, click Naming Context, click the DOWN ARROW, select Configuration Container, and then click OK.
  6. In the console tree, right-click common name=MsmqServices.

    Where?

    • ADSI Edit
    • common name=Configuration,...
    • common name=Services
    • common name=MsmqServices
  7. Click Properties.
  8. On the Attributes tab, in Select a property to view, click the DOWN ARROW and select mSMQNameStyle.
  9. In Edit Attribute, enter TRUE to relax security.

    Or, enter FALSE to tighten security.

  10. Click Set, and then click OK.

Notes

  • The Windows 2000 Resource Kit must be installed before you can use ADSI Edit. The Windows 2000 compact disc set contains a subset of the full Windows 2000 Resource Kit. For more information, see the Windows 2000 Resource Kit.
  • This procedure is used to weaken Active Directory security in order to support Windows NT 4.0 users, local users, and certain operating configurations.
  • After performing this procedure, you must restart all Message Queuing servers running on Windows 2000 domain controllers for the change to take effect.

Related Topics


Administer queues for Message Queuing

  • To create queues
  • To find queues
  • To delete queues
  • To take outgoing queues offline
  • To pause or resume an outgoing queue
  • To change queue labels
  • To change queue type IDs
  • To change the base priority of queues
  • To enable or disable target journaling
  • To set the journal storage size for queues
  • To set the message storage size for queues
  • To allow only authenticated messages on queues
  • To change the privacy level for queues
  • To manage queues and messages on other 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
    • your_queue_folder (such as Public Queues or Private Queues)
  3. Point to New, and then click Public Queue (or Private Queue).
  4. In Name, type a name for the new queue, and click OK.

    Or, if you want to create a queue to accept transactional messages, type a name, select the Transactional check box, and then click OK.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • You cannot create queues in the Outgoing Queues or System Queues folder. These queues are created automatically.
  • You must have domain administrative permissions and be logged on using a domain user account to be able to create remote public queues.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Find queues

To find queues

  3. In the console tree, right-click any folder or object shown.
  4. Click Find.
  5. In Find, click the DOWN ARROW, and then click MSMQ Queue.
  6. On the Find MSMQ Queue tab, in Label or Type ID, type the appropriate queue information, and then click Find Now.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, 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 the criteria will be displayed.

Related Topics


Delete queues

To delete queues

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  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.

Related Topics


Take outgoing queues offline

To take outgoing queues offline

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
  3. Point to All Tasks, and do one of the following:
    • To take Message Queuing offline from the network, click Take MSMQ Offline.
    • To bring Message Queuing back online, click Bring MSMQ 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 dial-up 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 only be performed using the Computer Management snap-in.
Related Topics


Pause or resume an outgoing queue

To pause or resume an outgoing queue

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • Outgoing Queues
  3. 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 such a queue. This way, you can send all pending messages in the queue to the destination computer 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.
  • This task can only be performed using the Computer Management snap-in.
Related Topics


Change queue labels

To change queue labels

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  3. Click Properties.
  4. On the General tab, in Label, type the new label for the queue.

Notes

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

Related Topics


Change queue type IDs

To change queue type IDs

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  3. Click Properties.
  4. On the General tab, 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 use of the queue type ID is optional and depends on the Message Queuing application. For example, if a Message Queuing application receives messages from a MAPI application, the Message Queuing application may require an input queue with a specific MAPI-type ID.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Change the base priority of queues

To change the base priority of queues

  4. Click Properties.
  5. On the General tab, in Base Priority, type a new value or use the UP or DOWN ARROW to enter a new value.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The base priority can be set from -32768 to 32767. The default priority setting is 0.
  • Private queues do not support base priority (also known as queue priority).

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.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  3. Click Properties.
  4. On the General tab, 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.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Set the journal storage size for queues

To set the journal storage size for queues

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  3. Click Properties.
  4. On the General tab, 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.

Notes

  • To open Computer Management, right-click My Computer, and then click Manage.
  • When the journal storage size is reached, journal messages can no longer be sent to the journal queue until the cumulative size of journal messages in the journal queue drops below the specified limit.
  • If you clear the Limit journal storage to (KB) check box, the journal size will be limited only by the available disk space on the local computer.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

Related Topics


Set the message storage size for queues

To set the message storage size for queues

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  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.
  • When the message storage size 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.

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.

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  3. Click Properties.
  4. On the General tab, select the Authenticated check box.

    Or, to accept any messages on the queue, clear the Authenticated check box.

Notes

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

Related Topics


Change the privacy level for queues

To change the privacy level for queues

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
  3. Click Properties.
  4. On the General tab, 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.

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 you want to manage queues and message on, 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 a remote computer.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.
Related Topics


Administer messages for Message Queuing

  • To view message properties
  • To change the message property columns displayed
  • To purge all messages in a queue
  • To 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).

    Where?

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

Notes

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

Related Topics


Change the message property columns displayed

To change the message property columns displayed

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
    • Queue messages (or Journal messages)
  3. Point to View, and then click Choose Columns.
  4. In the Modify Columns dialog box, make the changes you want:
    • To add a message property column, in Hidden columns, click an entry, and then click Add.
    • To remove an existing message property column, in Displayed columns, click an entry, and then click Remove.
    • To change the order in which message property columns appear, in Displayed columns, click an entry, and click Up or Down to move the column to the left or right, as needed.
  5. Repeat Step 4 for any other columns 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 message property by clicking on the applicable column for ascending or descending sort order.
  • You can also perform this task using the Active Directory Users and Computers snap-in. For more information, see Related Topics.

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

    Where?

    • Computer Management
    • Services and Applications
    • Message Queuing
    • your_queue_folder (such as Public Queues or Private Queues)
    • your_queue
    • Queue messages (or 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 messages from system queues.
  • You cannot purge individual messages from a queue.
  • To increase performance, messages in journal queues 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.

Related Topics


Set the default lifetime for messages

To set the default lifetime for messages

  2. On the View menu, click Show Services Node.
  4. Click Properties.
  5. On the General tab, type a new value and select new units as needed.

Notes

  • The Active Directory Sites and Services snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The default lifetime of a message is also known as the time-to-reach-queue (TTRQ).

Related Topics


Monitor and test Message Queuing

  • To view Message Queuing events
  • To view Message Queuing transactions
  • To view computer performance
  • To view queue performance
  • To send test messages
  • To enable message route tracking
  • To 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.
  4. Scroll until you see "MSMQ" events listed in the column.

Notes

  • To open Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.
  • When viewing events in Event Viewer, you can sort, filter, and search for events, based on event properties.
Related Topics


View Message Queuing transactions

To view Message Queuing transactions

  1. Open MS DTC Admin Console.
  2. Do the following:
    • To view the status of a transaction, click the Transactions tab.
    • To view the statistics of a transaction, click the Statistics tab.

Notes

  • To open MS DTC Admin Console, click Start, click Run, and then type msdtcmgr.exe.
  • You can change the configuration of MS DTC by clicking the Advanced tab.
  • The Distributed Transaction Coordinator service must be running to perform external transactions.

Related Topics


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 you are using.

    Or, to view counters for another computer, click Select counters from computer, and click that computer.

  4. In Performance object, click the down arrow, and then click MSMQ Service.
  5. Click All counters.

    Or, click Select counters from list, and then select the counters 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 review the definition of a counter, click Explain.
  9. Click Close.

    The monitor graph appear in the details pane.

Notes

  • To open System Monitor, click Start, point to Programs, point to Administrative Tools, and then Performance.
  • You can view performance data from System Monitor in Chart, Report, or Histogram views, and can log the performance data to a file. For more information about System Monitor, see Related Topics.

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 from which you are administering.

    Or, to view counters for another computer, click Select counters from computer, and click the applicable computer.

  4. In Performance object, click the down arrow, and then click MSMQ Queue.
  5. Click All counters.

    Or, click Select counters from list, and then select the counters 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 review 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, point to Programs, point to Administrative Tools, and then click Performance.
  • When viewing performance data from System Monitor, you can view the data in Chart, Report, or Histogram views, and can log the performance data to a file. For more information on System Monitor, see Related Topics.

Related Topics


Send test messages

To send test messages

  3. In the console tree, right-click msmq.

    Where?

    • Active Directory Users and Computers
    • your_domain
    • your_organizational_unit (such as Computers or Domain Controllers)
    • your_source_computer
    • msmq
  4. Click Properties.
  5. On the Diagnostics tab, 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 destination_computer\destination_queue), click OK, and then click Send.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • The computer you select is the source computer used to send a test message from.
  • You can send test messages only to test queues. All test queues 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 as 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 feature enabled, if the source computer has a report queue and if the test queue is located on another computer, the message route of such test messages is tracked. For information on how message route tracking is otherwise enabled, see Related Topics.

Related Topics


Enable message route tracking

To enable message route tracking

  4. Click Properties.
  5. Click the Diagnostics tab, and then click Define Tracking.

    The Message Route Tracking dialog box appears.

  6. In Pathname of report queue, click the applicable report queue.

    Or, to create a new queue for report messages, click New, and type the full queue path name (such as MyComputer\MyQueue).

  7. Click Track all messages.

    Or click Track only test message.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
  • To enable message route tracking, you must first create a report queue. For information on how to create a new queue, see Related Topics.
  • If you click Track all messages and if the sending application has set the message route tracking flag, and if the destination queue is located on another computer, all messages sent from the source computer have their routes tracked. This information is then sent to the report queue. Tracking occurs both for messages sent by the source computer and for messages routed through a Message Queuing server.
  • 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.

Related Topics


Test connectivity using MQPing

To test connectivity using MQPing

  4. Click Send MQPing message.

Notes

  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, 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 attempts for 45 seconds to connect to the computer. You may need to send several MQPing messages to determine if a computer is connected or not.

Related Topics


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 is a messaging infrastructure and a development tool for creating distributed, loosely-coupled, messaging applications for the Windows 2000 operating system. Applications developed for Message Queuing send messages to queues, which are temporary storage locations used to ensure that messages reach their destination. Such applications can communicate across heterogeneous networks and with computers that may be offline. Message Queuing provides guaranteed message delivery, efficient routing, security, transactional support, 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, independent 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 only discusses the infrastructure and features provided by Message Queuing and not how to develop applications. For information on developing Message Queuing applications, you most acquire the Message Queuing Software Development Kit (SDK), which is part of the Microsoft Platform SDK. For more information on the Message Queuing SDK, see Microsoft Platform Software Development Kit.

Where needed for clarity, the documentation distinguishes between those features that are provided with Message Queuing and those features that are obtained programmatically using Message Queuing applications.

There are a number of terminology and administrative changes in the current version of Message Queuing 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 previous versions, Message Queuing was called Microsoft Message Queuing Server, or MSMQ 1.0. An attempt has been made to differentiate between the use of Message Queuing when discussing the current version (for Windows 2000) and of MSMQ 1.0 when discussing previous versions (for Windows NT 4.0, Windows 95, and Windows 98). However, as some sub-components and parts of the user interface still use the term MSMQ, this term is sometimes used in the documentation to refer to the current version. Which version is being referred to should be clear by context.
  • Message Queuing may be referred to as MSMQ 2.0 in external literature and other external sources.

Summary of features

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

New features

  • Active Directory integration. Integration with, and the extension of, the Active Directory directory service, to store all configuration and status information.
  • Mixed-mode operation. Message Queuing can operate in mixed-mode domain environments, which means MSMQ 1.0 controller servers running on Windows NT 4.0 and Message Queuing servers running on Windows 2000 can communicate seamlessly.
  • Windows 2000 security integration. Message Queuing still supports privacy and security through the use of access control, auditing, encryption, and authentication and leverages new security features built into Windows 2000, such as the Kerberos V5 security protocol.

    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.

  • Workgroup support. Message Queuing can be installed and run in a Windows 2000 workgroup, rather than in a domain. In addition, Message Queuing that is installed in a workgroup can later join a domain, and then separate from the domain again.
  • Active/active cluster support. Message Queuing now fully supports active/active operation 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.
  • Microsoft Management Console (MMC) support. Message Queuing is now administered using snap-ins hosted in an MMC console.

Legacy features

  • Connectionless messaging. With store-and-forward message queuing, computers are not affected by network disturbances and do not have to establish sessions. Because a sessionless model is used at the application level, the source computer and the destination computer do not need to support the same network protocol. Both Internet Protocol (IP) and Internet Packet Exchange (IPX) protocols are supported.
  • 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.
  • Guaranteed message delivery. Messages can be stored on a disk-based queue and then later forwarded to provide guaranteed delivery.
  • Transactional messaging. 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.
  • 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.
  • Disparate system integration. Message Queuing can be used across a wide variety of hardware platforms using connectivity products provided by other vendors.

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. For example, Microsoft Exchange Server moves e-mail messages between Exchange users, using a central post office and mail folders.

Message Queuing can however complement e-mail applications such as Microsoft Exchange Server 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 with e-mail include the following:

  • The Message Queuing sender and recipient is an application, whereas an e-mail sender and recipient is generally a person.
  • 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.

Cross platform support

MSMQ-MQSeries Bridge extends the functionality of Message Queuing to provide seamless, transactional connectivity with IBM MQSeries Version 2 and Version 5 platforms. MSMQ-MQSeries Bridge is provided with Microsoft SNA Server version 4.0 Service Pack 2 and later.

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 Windows 2000 Server and Windows 2000 Advanced Server disc sets. You must use additional client software available from Level 8 Systems in conjunction with MQC 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/)

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.


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
  • Components of Message Queuing
  • Queue type
  • Message type and delivery
  • Message routing
  • Message storage
  • Message Queuing objects in Active Directory
  • Business scenarios for Message Queuing


Network topology of Message Queuing

Message Queuing is a messaging infrastructure made up of computers that provide various functions and that are connected in a Windows 2000 network. This section discusses how Message Queuing computers are connected in a such network.

Message Queuing can be used in either a domain environment or in 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 is any environment that does not provide such a directory service.

Domain environment

In a domain environment, Message Queuing runs on Windows 2000 domain controllers to provide access to Active Directory. The total 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 a domain that consists of both MSMQ 1.0 controller servers running on Windows NT 4.0 and Message Queuing servers running on Windows 2000 that communicate with each other.

Sites

In a domain environment, a Message Queuing network is 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 which 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 2000 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 more information on sites in Windows 2000, see Sites.

Note

  • There is no longer a special definition of a site 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 all previous foreign connected networks are mapped to one or more foreign sites. If you are upgrading from MSMQ 1.0, see the Upgrade overview for Message Queuing for a list of changes.

Routing links

In a domain environment, routing links are logical communications links created by Message Queuing to route messages between different sites, and are comprised of two Message Queuing servers, one in each site. Message Queuing servers used to perform this function are called site gates. If a routing link is defined with two site gates, only those servers can transfer messages between the designated sites.

Multiple routing links can be used to route message between sites in your network for load-balancing or redundancy. In this case, link costs can be assigned to each routing link to prioritize which link is used to route messages (the default link). Routing-link costs can be used to represent the relative bandwidth or cost of communicating using that link.

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.

For more information on how messages can be routed through your network, see Message routing.

Workgroup environment

Message Queuing can be run in an environment that is not part of a domain, such as a workgroup, or any other environment that does not provide a directory service. 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 a nondomain environment:

  • Messages sent by such computers cannot be routed by a Message Queuing server—direct connectivity with the destination computer is required.
  • There is no access to Active Directory. As such, you can only create and manage private queues on a local computer. You cannot view or manage public queues or any other information in Active Directory. You can, however, send messages to, or read 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.


Components of Message Queuing

Message Queuing is a messaging infrastructure made up of computers that provide various functions and that are connected in a network. This section discusses the software components for Message Queuing. These software components define the functionality a Message Queuing computer provides in your network.

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 the following additional services:

Directory access

By default, Message Queuing servers installed on Windows 2000 domain controllers enable client computers the capability of viewing or changing information listed in the Active Directory directory service.

For general information on Windows 2000 domain controllers, see Domain controllers.

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). Message Queuing servers that provide message routing between sites are called site gates. A pair of site gates in turn define a routing link between two sites.

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 use a supporting server to send and receive messages on its behalf.

If site gates are used to route message between sites, only those assigned Message Queuing servers can route messages between the sites. Message Queuing servers can also be configured to enable client computers that use different network protocols (such as IP and IPX) to communicate with each other.

Clustered services

Message Queuing servers can also provide services in the context of a cluster group. When you install a Message Queuing server on a server cluster, you create a resource for Message Queuing and add it to a cluster group called a cluster virtual server. A cluster virtual server is a cluster group that contains a Disk resource and a Network Name resource. A cluster virtual server functions similarly to a server running on a physical computer, so a Message Queuing server running in the context of a cluster virtual server provides similar services to a Message Queuing server running on a physical computer.

Message Queuing clients can either communicate with the standard Message Queuing server running on a computer node of the server cluster, or if Message Queuing applications are cluster-aware, they can communicate with the virtual Message Queuing server running in the context of a cluster virtual server. There can be multiple cluster virtual servers (and hence multiple virtual Message Queuing servers) running on a server cluster.

The types of services Message Queuing provides while running in the context of a cluster virtual server depends on the configuration of the Message Queuing server installed on a node. For example, if a Message Queuing server with routing services enabled is installed on a node of a server cluster, a Message Queuing server with routing services will also be available in the context of the cluster virtual server associated with the node. The exception to this is for nodes that are Windows 2000 domain controllers. Message Queuing servers running on nodes that are domain controllers provide access to Active Directory; however, the corresponding Message Queuing server running in the context of a cluster virtual server cannot provide access to Active Directory.

For more information on server clusters for Windows 2000 Advanced Server, see Server clusters.

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 independent clients can run only on Windows 2000 Professional and Message Queuing servers run only on Windows 2000 Server or Windows 2000 Advanced Server. For this discussion, an independent client and such a Message Queuing server (if installed on a nondomain controller) can be used interchangeably.

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

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 site for example, 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. If the new site is specified before disconnecting from the network, all messages are routed immediately to the new site.

As stated previously, clients can be configured to use Message Queuing servers (in-routing servers and out-routing servers) for routing messages within a site. 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 an independent client is operating in a mixed-mode domain environment where it communicates 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 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 reading of messages. Messages stored on another Message Queuing computer cannot be read 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 the supporting server, for all functions. A dependent client relies on its supporting server to perform all functions on its behalf, such as hosting queues, storing messages, sending messages, and receiving messages.

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

The MSMQ Exchange Connector provides a way for Microsoft Exchange users to communicate with Message Queuing applications. Using the MSMQ Exchange Connector, e-mail can be sent to Message Queuing applications and Message Queuing mail messages can be sent to Microsoft Exchange users.

The MSMQ Exchange Connector is the recommended solution for connecting Microsoft Exchange users to Message Queuing applications. Only one MSMQ Exchange Connector is needed in an Exchange enterprise.

When a Message Queuing client sends a message to an Exchange client, the message is first sent to a queue on a Message Queuing server and then forwarded by the MSMQ Exchange Connector to the Exchange client through the Exchange server that the MSMQ Exchange Connector is communicating with. Microsoft Exchange clients can obtain queue addresses for Message Queuing clients from the shared Exchange Address Book.

MSMQ MAPI transport provider

The MSMQ MAPI transport provider allows you to connect MAPI client applications (such as Microsoft Exchange clients) to Message Queuing applications. As a transport provider, the MSMQ MAPI Transport Provider translates between e-mail and Message Queuing mail messages. MAPI clients can exchange e-mail with Message Queuing applications using the MSMQ MAPI transport provider.

Note that the MSMQ MAPI transport provider differs from the MSMQ Exchange Connector in the following ways:

  • The MSMQ MAPI transport provider makes it possible for any MAPI client to send messages to and receive messages from Message Queuing clients. The MSMQ Exchange Connector enables only Microsoft Exchange clients to send messages to and receive messages from Message Queuing clients.
  • The MSMQ MAPI transport must be installed on each MAPI client computer that uses Message Queuing to send and receive messages. The MSMQ Exchange Connector does not have to be installed on more than one Message Queuing server in an Exchange enterprise.
  • Every MAPI client has its own queue for storing incoming messages, created by the MSMQ MAPI transport provider. Microsoft Exchange clients receive messages using a single queue created by the MSMQ Exchange Connector.
  • It is more difficult for a group of MAPI clients using the MSMQ MAPI transport to share addresses of queues. Each MAPI client must store queue addresses for Message Queuing clients in a local Personal Address Book (PAB). Microsoft Exchange clients can obtain queue addresses from the shared Exchange Address Book.

The MSMQ MAPI transport provider is installed by default during Message Queuing Setup.

MSMQ RPC transport provider

The MSMQ remote procedure call (RPC) transport provider can be used as a reliable transport for asynchronous RPC-based Message Queuing applications.

Message Queuing uses authenticated RPC for communication with all domain controllers. All authenticated RPC connections are first validated by a domain controller. The domain controller must be online, otherwise Message Queuing clients cannot read messages sent using the MSMQ RPC transport provider.

The MSMQ RPC transport provider is installed by default during Message Queuing Setup.

Connector applications and foreign computers

Message Queuing clients can communicate with foreign computers using a connector application. Foreign computers run operating systems not supported by 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. 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 the 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.

The MSMQ-MQSeries Bridge is provided with Microsoft SNA Server version 4.0 Service Pack 2 and later.

MQC is included on the Windows 2000 Server and Windows 2000 Advanced Server disc sets. To send a message to a foreign computer running a non-Windows operating system however, you must first acquire and install client software available from Level 8 systems onto your foreign computers. For more information, contact Level 8 Systems, or refer to the Level 8 Systems Web site.


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 queues for Message Queuing.

Public queues

In a domain environment, public queues are queues that are published in Active Directory and hence replicated throughout your Windows 2000 forest. Note that only the properties for these queues is displayed, not the actual queues themselves or their contents. Any computer within a Windows 2000 forest can potentially access information for public queues.

Public queues do not exist 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. System queues are a type of private queue.

Journal queues

The process of storing copies of messages is called journaling. These copies, called journal messages, are stored in journal queues. Two types of journaling are available: source journaling and 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 source journal queue of the source computer. This occurs either when the message arrives at the destination computer or when the message reaches a Message Queuing server that is one hop closer to the destination computer. Message Queuing servers that route messages for clients do not store a copy of those messages in their source journal queues.

Outgoing messages for dependent clients are placed in the source journal queue on the supporting Message Queuing server.

Target journaling

Target journaling is the process of storing copies of incoming messages on the destination computer. Target journaling is configured on a queue basis. If it is enabled, a copy of each incoming message is placed in the target journal queue when the message is read (removed by a Message Queuing application). A target journal queue (called Journal Messages) is automatically created for each queue. Target journaling is disabled by default.

Dead-letter queues

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

There is one dead-letter queue and one transaction dead-letter queue on each Message Queuing server and independent client. These queues are automatically created.

Messages in dead-letter queues and transaction dead-letter queues are always written to disk, and thus are recoverable.

When a sending application is not allowed to send messages to a particular queue because of security restrictions, those messages are not stored in dead-letter or transaction dead-letter queues. A negative acknowledgement message however may be generated if so configured.

Messages are considered undeliverable when:

  • 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. When the receiving transaction fails, these messages are not placed in the transaction dead-letter queue.

Messages are considered expired when:

  • The lifetime of messages on the network, called the time-to-reach-queue (TTRQ), expires. (This can be set programmatically by a Message Queuing application.)
  • The message time-to-be-delivered (TTBD) expires. (This is always set programmatically by a Message Queuing application.)

For more information on transactional messaging, see Transactional messaging.

Administration queues

Administration queues contain acknowledgment messages for sent messages, and are specified programmatically by the sending application when a message is sent. Any available nontransactional queue can be specified as an administration queue.

Note that administration queues do not contain administrative message; these messages are stored in a system queue.

Response queues

Response queues contain 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, since all administration queues must be nontransactional, this queue will accept only nontransactional messages.

Note that response messages are not the same as administrative response messages, which are stored in a system queue.

Report queues

Report queues contain report messages that indicate the route a message took to its destination and can also contain sent test messages. There can be only one report queue per computer. You can create a report queue only if message-route tracking is first enabled.

System queues

Message Queuing uses up to five system queues. All five system queues are implemented as private queues, which means they are not published in Active Directory. You cannot delete system queues.

The following table describes each system queue and how it is used.

System queue | Use
admin_queue$ | Storing administrative messages
msmqadminresp$ | Storing administrative response messages (except MQPing messages)
mqis_queue$ | Storing returned MQPing messages
notify_queue$ | Storing notification messages. These messages list computer and queue property changes, including creation and deletion of queues.
order_queue$ | Tracking transactional messages that require in-order delivery


Message type and delivery

In the context of Message Queuing, messages comprise 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 discusses 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, journal, dead-letter, and transactional queues. Normal messages do not contain status information; such information is contained in acknowledgement, report, and response messages.
  • acknowledgement messages. Acknowledgement messages report the status of normal messages. These messages can be either positive or negative, and are sent to administration queues on the source computer. A positive acknowledgement message indicates that a message arrived at the destination computer and whether or not the the message was read (removed by the receiving application). A negative acknowledgement message indicates that an error occurred before a message could be delivered to the destination computer or why the message was not read.
  • Report messages. Report messages include test messages and route-tracking messages sent to report queues on the source computer.
  • 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 queues that messages can be sent to, see Queue type.

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 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, from 0 to 7, where 7 represents the highest priority.

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 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 accumulating express messages 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. If the Message Queuing server fails before the network link is restored, the express messages are lost however.

Caution

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

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 shutdown 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 to disk based on a memory-mapped file structure. Performance gains can be realized when using several physical disks to store recoverable messages. For more information, see Disk considerations.

Transactional messaging

Recoverable messaging can be further differentiated into transactional and nontransactional messaging. Transactional messages are sent and received from within a transaction. This means that such messages are either sent together and in the order they were sent (a committed transaction), or not sent at all (an aborted transaction). Likewise, transactional messages are only read (removed) from a queue if and when the transaction is committed, otherwise they are returned to the queue and can be subsequently read during another transaction.

In addition, consecutive transactions initiated from the same computer to the same destination queue will arrive in the order the transactions were committed to each other. Moreover, 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 (and nontransactional messages cannot be sent to transactional queues). There are two ways to implement transactional messaging:

  • As external (two-phase) transactions, which are coordinated by the Microsoft Distributed Transaction Coordinator (MS DTC), which is now part of Component Services (formerly known as Transaction Server). MS DTC is automatically installed during Message Queuing Setup.
  • As internal (single-phase) transactions, which are coordinated by Message Queuing.

External transactions are used if resources other than what Message Queuing can provide need to be part of the transaction. Message Queuing is then used as a resource manager under the control of the DTC. Using the DTC as the transaction coordinator for Message Queuing, transaction-based applications can be implemented, ensuring that all operations 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 or neither action is executed.

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 that require external resources. Message Queuing provides a transaction coordinator that supports only itself as the resource manager.

You can use internal transactions to:

  • 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 acknowledgements, confirm that the received transaction was successful. You can also use acknowledgements to confirm that messages reached (or were removed from) the destination queue.

For more information on MS DTC, see Using Component Services.


Message routing

A Message Queuing client always tries to establish a direct connection, or session, with the destination computer using the underlying network transport protocol. If a direct connection is not possible or not allowed, Message Queuing servers can route messages on behalf of the client computer. Specifically, message routing can occur when one or more 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 servers are used to route messages on behalf of the source or destination computers.
  • Computers use dissimilar network protocols to communicate.

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

Message Queuing servers that provide message routing within a site are called in-routing servers (InRS) or out-routing servers (OutRs). Message Queuing servers that provide message routing between sites on a routing link are called site gates.

Note

  • Message routing is not applicable in a workgroup environment; direct connectivity with the destination computer is required.

Message routing within a site

Message routing within a site, called intrasite routing, is measured in hops, which represent the number of computers a message must pass through to get to the destination computer. The shortest available path (that is, the path with the fewest number of hops) is used when routing a message within a site. For message-routing decisions, two computers are considered to be in the same site if they are assigned IP addresses that belong to that site.

Figure showing message routing within a site

In this diagram, 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 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

Messages can be routed within a site on behalf of clients that use Message Queuing servers, called in-routing servers (InRs) or out-routing servers (OutRs). In this context, the term client refers to an independent client or a Message Queuing server without routing enabled. For this discussion, an independent client and such a Message Queuing server (if installed on a nondomain controller) can be used interchangeably. Dependent clients cannot use in-routing or out-routing servers as all messaging functions are performed by a supporting server.

If a client is configured to use an out-routing server, every outgoing message sent by the client is routed through that server. Likewise, if a client is configured to use an in-routing server, every message sent to the client is routed through that server. A client can use the same Message Queuing server as both its in-routing and out-routing server.

All in-routing/out-routing servers must be in the original site of the client. 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

Message routing within a site may 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 every other independent client, you may reduce your bandwidth usage 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 server is used as both an in-routing server and an out-routing server for each client.

Message routing between sites

Message routing between different sites, called intersite routing, is based on the use of routing links. When using multiple routing links, the route messages take is based on the routing-link cost. All routing links are assigned a default cost of 1. You should only change routing-link costs in the case where you have multiple routing links and you want to enforce one route over another route using link cost.

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 message routing between sites

The route a message takes to get from site A to site C depends on the cost 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.

Site gates

Messages can be routed between sites on behalf of clients using Message Queuing servers, or site gates, that define a routing link. If a client computer uses a routing link, every message sent to another site must be routed through the associated site gate in the client's site. A Message Queuing server must belong to the site that it serves as the site gate for, and must be able to connect to the other site specified by the routing link. For example, for a routing link defined between site A and site B, site gate A must be located in site A and be able to connect to site B, and site gate B must be located in site B and be able to connect to site A.

Session reduction

Message routing between sites 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 session concentration between sites

IPX usage

Message Queuing servers can also be configured to enable client computers that use different network protocols (such as IP and IPX) to communicate with each other. If there are computers in your organization that use the IPX protocol, the following requirements must be met before you can use site gates to provide communication:

  • If all client computers in a site use only the IPX protocol, all Message Queuing servers in that site must be configured to support both the IPX and the IP protocol.
  • IPX-only clients in a site must be configured to use Message Queuing servers that support both the IPX and the IP protocols.

Message Queuing requires name resolution for networks that use the IPX protocol. You can use the Service Advertising Protocol (SAP) Agent included with Windows 2000 to provide name resolution. The SAP Agent must be running on all Message Queuing computers that use the IPX protocol. For more information on using the SAP agent, see Using the Service Advertising Protocol.

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 cumulative size for all messages contained in a particular queue 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 in journal queues) 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 read (removed from the queue by a Message Queuing application). Queue quotas can be set for all queues. Computer quotas are not applied towards system 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 a maximum of approximately 1.6 GB to 1.8 GB of messages on a computer. For Message Queuing servers supporting multiple dependent clients, this limit applies to the server, since dependent clients do not store messages locally. For example, a Message Queuing server supporting three dependent clients can hold no more than 1.8 GB of messages for the three dependent clients.

Note

  • For computers running Windows 2000 Advanced Server, a maximum of approximately 2.6 GB to 2.8 GB of messages can be currently stored on a computer.

Local message storage

The files used to store messages are located in the \Msmq\Storage and \Msmq\Storage\Lqs folders (under Winnt\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 has insufficient 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.

The memory-mapped files can be stored using any file system supported by Windows 2000. However, because the NTFS file system for Windows 2000 provides more reliable file recovery after a power failure or system crash, it is highly recommended for Message Queuing servers. In addition, you should backup 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 = Indexing bitmap for interpreting recoverable and journal message files

An .mq file does not represent a 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 be stored in multiple files. Therefore there is the 4 MB limit in message size.

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

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

The MQInSeqs.* files are referred to 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 of the file 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 formatted nnnnnnnn.hhhhhhhh represent private queues. The nnnnnnnn portion is the queue number (included in the direct format name for the queue). The hhhhhhhh extension is a hash of the queue path.

File names formatted aaaaaaaabbbbccccddddeeeeeeeeeeee.hhhhhhhh represent local public queues. The 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.


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 component types, except for dependent clients. These objects store various information associated with Message Queuing. Under certain conditions, the object name can be changed, which 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 component type and that are displayed in the MMC snap-ins. For general information about MMC and snap-ins, see Microsoft Management Console.

Message Queuing component | Object name | Object class
Message Queuing server on a domain controller | msmq; MSMQ Settings | MSMQ-Configuration; MSMQ-Settings
Message Queuing server with routing services | msmq; MSMQ Settings | MSMQ-Configuration, MSMQ-Settings
Message Queuing server on a nondomain controller | msmq | MSMQ-Configuration
Independent client | msmq | MSMQ-Configuration
Dependent client | none | not applicable

In addition, some information for Message Queuing is also stored in Active Directory in non-Message Queuing objects. Specifically, the User object contains user certificate information; the applicable computer object (above the msmq object) contains certificate information, and the Sites object contains information related to foreign sites.

For advanced information on object attributes, see the Active Directory topic in the Networking section of the Microsoft Platform SDK.

MsmqServices object

The 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 MSMQ-Enterprise-Settings 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 is created for each routing link that you create and contains connectivity information. Routing link objects are of MSMQ-Site-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

The 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 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 in the following location:

  • Active Directory Sites and Services
  • Sites
  • your_site_object
  • Servers
  • your_server_object

msmq object

The msmq object is created for each independent client and for each Message Queuing server, and contains configuration information for the local computer. The msmq object is of MSMQ-Configuration class type. Under the msmq object are located queue objects. The msmq object is also known as the MSMQ configuration object.

The msmq object (and child container 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
  • your_domain_object
  • your_organizational_unit_object (such as Computers or Domain Controllers)
  • your_computer_object
  • msmq
  • your_queue_folder_object (such as Private Queues and System Queues)
  • your_queue_object
  • Queue messages
  • Journal messages

Queue object

A queue object is created for each queue and contains information associated with a particular queue. Queue objects are of MSMQ-Queue class type.

Queue objects are located under the msmq object of the computer on which they reside (except for dependent clients, where the queues are located under the msmq object of the supporting server.

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 (MSMQ 1.0 controller servers running Windows NT 4.0 and Message Queuing servers running Windows 2000), and is used to contain the computer object 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
  • your_domain_object
  • 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 (MSMQ 1.0 controller servers running Windows NT 4.0 and Message Queuing servers running Windows 2000), and is used to contain migrated 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
  • your_domain_object
  • MSMQ Users

Migrated user object

The migrated user object is created only by the Message Queuing Upgrade wizard in a mixed-mode domain environment and contains registered certificates for MSMQ 1.0 users that belong to Windows NT 4.0 domains. The migrated user object is of MSMQ-Migrated-User class type.

The migrated user 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
  • your_domain_object
  • MSMQ Users
  • migrated user


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 business scenarios, these terms are used lightly and the scenarios have been kept simple. Application developers should see the Message Queuing SDK for representative samples of Message Queuing applications.

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 following example, Message Queuing is used to collect work orders and manage the information flow for production.

Figure showing a representative floor automation scenario

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 the MSMQ-MQSeries Bridge. For more information, see Cross platform support.
  • Performance: Since 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

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

Figure showing a representative ticket sales scenario

A business selling tickets to events can use the following Message Queuing features to improve its system.

  • Internet connection: Accepts orders over the Internet using a Message Queuing application and COM components in conjunction with Active Server Pages (ASP) and Internet Information Services (IIS). This is done through Web forms, which provide security and multiple platform support.
  • Connectionless messaging: Account updating and ticket shipping, performed asynchronously.
  • Multiple platform support: Integrates personal computers and legacy systems. For example, the ticket sales server might be running on a UNIX computer. For more information, see Cross platform support.

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 re-send the data if the client is offline or unavailable.

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

Figure showing a representative publish-and-subscribe scenario

In the preceding figure, mobile clients retrieve data in the field. Regional servers retrieve data from the main server only those data types to which the clients subscribe. Each client then receives only information it subscribes to receive. This reduces both intersite communication and mobile communication costs.

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.

Note

  • Message Queuing does not natively support broadcast or multicast services. However, a simple message-dispatching application can be written to send a message to multiple queues.

Banking scenario

Financial transactions require both security and transaction-based programming. Automated teller machine (ATM) transactions also require connectionless messaging. In the following 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.

Figure showing a representative banking scenario

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.

The following stock transaction scenario uses these Message Queuing features:

  • Security: For message authentication, encryption, and auditing to ensure a secure environment.
  • Multiple platform support: Integrates personal computers and legacy systems. For more information, see Cross platform support.
  • 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 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 message routing between sites 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 following factors:

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 Message Queuing servers in each site affects performance. More Message Queuing servers in a site generate more network traffic throughout that site. You need to trade off server redundancy benefits with the performance overhead of Active Directory 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 in order to guarantee that messages can be routed between different Windows 2000 sites. Message routing between sites can be based on an assigned link cost. All routing links are assigned a default cost of 1. You should only change routing link costs in the case where you have multiple routing links and you want to enforce one route over another route using cost.

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.

Message Queuing server considerations

The number of Message Queuing servers you deploy in your organization can depend on the following factors:

  • The number of dependent clients in your network
  • The number of sites you are routing messages between
  • 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 servers on multiple Windows 2000 domain controllers in each Windows 2000 domain.

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

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.

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:

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

Note

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

  • 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 journal 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 the Local User account.

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 Windows 2000 Professional can have no more than 10 concurrent Message Queuing sessions and remote-read sessions with other independent clients running Windows 2000 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 2000 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 2000 Professional do not count sessions with computers running Windows 2000 Server, however computers running Windows 2000 Server do count sessions with computers running Windows 2000 Professional.

For more information on licensing for Windows 2000 Server, see Choosing a licensing mode.

IPX connectivity considerations

If Message Queuing computers have multiple network adapters installed, and you have configured the IPX protocol for use on some of the adapters, you must specify a unique, nonzero, internal network number for each of those computers.

Message Queuing requires name resolution for networks that use the IPX protocol. You can use the Service Advertising Protocol (SAP) Agent included with Windows 2000 to provide name resolution.

For more information on setting IPX properties and using the SAP Agent, see Setting IPX/SPX properties.


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:

  • 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 most improvement because these messages are constantly being written to, and read 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 as follows:

  • Message files
  • Message log files
  • Transaction log files
  • Windows 2000 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 (MS 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 if 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 (in-routing and out-routing servers) or in routing links, you must allow for additional message space on those servers. Also, those 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 each 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 queue, 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.

Note

  • 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 2000 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 2000 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 X 1 KB + 20,000 X 150) of available RAM beyond normal system requirements.

Note

  • This recommendation applies only to cases where all messages actually accumulate on a computer. If messages are normally read (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 a queue. The computer and queue quotas are based on size, and can be set independently. Message Queuing servers and independent clients can store a maximum of approximately 1.6 GB to 1.8 GB (1.6 GB to 1.8 GB for computers running Windows 2000 Advanced Server) of messages on a computer. 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 2000 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 supports. Therefore, you could have an organization of 10,000 clients, with 100 users per 100 servers, or with 500 clients per 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- to large-scale organization. You should choose a plan that meets your business needs.

The rollout process can consist of:

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

  • Establish access control within your organization.
  • Delegate administrative duties.
  • Document work.
  • Prepare for emergencies.
  • Schedule 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

Once 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 Message Queuing

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

  • Installation overview for Message Queuing
  • Upgrading Message Queuing
  • Installing new Message Queuing servers
  • Installing new Message Queuing clients
  • Installing a new MSMQ Exchange Connector
  • Running Message Queuing unattended setup
  • Installing Message Queuing on a server cluster
  • Uninstalling Message Queuing


Installation overview for Message Queuing

Message Queuing is not installed by default during Windows 2000 Setup. You can install Message Queuing on a computer using the following methods:

  • Add/Remove Programs in Control Panel, after Windows 2000 is installed.
  • Configure Your Server wizard, after Windows 2000 is installed. When the Configure Your Server wizard appears at the end of Windows 2000 Setup, click Advanced, click Message Queuing, and then click Configure. This applies only to Windows 2000 Server and Windows 2000 Advanced Server.
  • Select the Message Queuing Services check box during Windows 2000 Setup. Having Message Queuing installed during Windows 2000 Setup is a two-step process. The first step, during Windows 2000 Setup, copies program files to your local disk. The second step, which occurs after Windows 2000 is installed and you logon for the first time, completes the installation for Message Queuing. When the Configure Your Server wizard appears, click Finish Setup, and in Configure Message Queuing Services, click Configure. Follow the instructions that appear in the Message Queuing Installation wizard. This applies only to Windows 2000 Server and Windows 2000 Advanced Server.

The first two methods are recommended for installing new Message Queuing software on your computers.

When Message Queuing is installed on a computer, the Microsoft Distributed Transaction Coordinator (MS DTC) is also installed by default. MS DTC is required for transactional messaging.

Message Queuing can be installed in either a domain environment that includes Active Directory or a workgroup environment (or any other environment that that does not provide a directory service such as Active Directory).

Installation requirements

Regardless of whether you are performing a new installation of Message Queuing or upgrading from MSMQ 1.0, the following requirements must be met before you can successfully install Message Queuing on a computer running Windows 2000:

  • 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.
  • For each Windows 2000 domain, you must install or upgrade Message Queuing on a Windows 2000 domain controller before you can install or upgrade Message Queuing on other computers in that 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, PSCs, and BSCs.
  • If prompted during Message Queuing Setup, you must enter the name of a Message Queuing server running on a Windows 2000 domain controller in the same domain you are installing in. Otherwise, Setup will install Message Queuing in workgroup mode. Workgroup mode of operation requires direct connectivity to send messages.

Installation restrictions

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

  • Do not install Message Queuing 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.
  • If you plan on moving a Message Queuing computer to another domain, you must first uninstall Message Queuing before the move and then reinstall it in the new domain.

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

Installation platforms

The following table shows which Message Queuing software components can be installed on which Windows platforms.

Message Queuing component | Windows 2000 platform
Message Queuing server | Windows 2000 Server and Windows 2000 Advanced Server
Independent client | Windows 2000 Professional
Dependent client | Windows 2000 Professional, Windows 2000 Server, and Windows 2000 Advanced Server
MSMQ Exchange Connector | Windows 2000 Server and Windows 2000 Advanced Server

Installation permissions

The following table shows the administrative permissions required to install different Message Queuing software components. 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 Setup.

Message Queuing component | Permission level required
Message Queuing server on a domain controller | domain administrative permissions (or belong to the Domain Admins group)
Message Queuing server on a nondomain controller with routing enabled | enterprise administrative permissions (or belong to the Enterprise Admins group).
Message Queuing server on a nondomain controller with routing not enabled | local administrative permissions (or belong to the Local Admins group)
Independent client | local administrative permissions (or belong to the Local Admins group)
dependent client | local administrative permissions (or belong to the Local Admins group)

For more information on administrative groups for Windows 2000, see Builtin and predefined groups.

Notes

  • When installing a Message Queuing server on a nondomain controller with routing enabled, domain administrative permissions are sufficient, provided you enter the name of a Message Queuing server running on a Windows 2000 domain controller when prompted during setup, and provided you are granted the specific object permissions listed in the table that follows.
  • When installing Message Queuing on a server cluster, the user account under which the cluster service is running must be granted permissions to create computer objects and Message Queuing objects. See the following table for specific permissions needed to create specific objects.

If you do not want to grant users such general or wide-ranging permissions to install Message Queuing, you can grant permissions to create those objects specifically required to install various Message Queuing components. The following table lists the specific child objects in Active Directory that you must be granted permission to create in order for Message Queuing Setup to complete.

Message Queuing component | Specific permissions required | For which object
Message Queuing server (on a domain controller, or on a nondomain controller with routing enabled) | Create MSMQ Configuration Objects | applicable domain controller object located in Active Directory Users and Computers
 | Create All Child Objects | Servers folder object located in Active Directory Sites and Services
Message Queuing server (on a nondomain controller with no routing) | Create MSMQ Configuration Objects | applicable computer object located in Active Directory Users and Computers
Independent client | Create MSMQ Configuration Objects | applicable computer object located in Active Directory Users and Computers
Dependent client | none | not applicable

You can grant these specific permissions to specific users, or to all users in a domain using the Delegation of Control wizard.

For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, see Message Queuing objects in Active Directory.

For more information on object permissions, see Access control for Message Queuing.

Note

  • 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 Setup fails for any reason, you must delete the applicable objects in Active Directory before attempting to run Setup again. If you do not do this, there will be objects created with the same name in Active Directory, and will lead to unpredictable operation. For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, Message Queuing objects in Active Directory.

For information on how to remove objects for Message Queuing in Active Directory, see To remove Message Queuing objects from Active Directory.

Note

  • 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 installing Message Queuing on a computer running Windows 2000 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 you are installing in. Otherwise, you must enter the name of a primary site controller (PSC) in a Windows NT 4.0 domain when prompted 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 95, or Windows 98 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 Message Queuing server instead. This Message Queuing server must be running on a Windows 2000 domain controller, must be a Global Catalog server, and must be in the same domain you are installing in.

If you plan to install MSMQ 1.0 on computers running Windows NT 4.0 in a new Windows 2000 domain, you should select the pre-Windows 2000 compatible check box during installation of the first domain controller in the new domain. If you are installing MSMQ 1.0 on computers running Windows NT 4.0 in an existing Windows 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 tab, check to see if the Everyone group is listed. If not, click Add, and then select Everyone.

In addition, dependent clients running Windows NT 4.0 should have Windows NT Service Pack 4 (SP4) or later installed. SP4 or later is required for transactional messaging.

In addition, for computers running Windows 95 or Windows 98, you must be granted the Create Computer Objects permission for the Computers folder 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 a domain. For more information, see To set install permissions for MSMQ 1.0.


Upgrading Message Queuing

This section explains the requirements for upgrading previous versions of Message Queuing (known as MSMQ 1.0) software on computers that have been upgraded to the Windows 2000 operating system.

  • 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 if you are upgrading from MSMQ 1.0, which runs on Windows NT 4.0, Windows 95, and Windows 98.

Some MSMQ 1.0 server components 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. Other MSMQ 1.0 software components are automatically upgraded during Windows 2000 Setup.

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 first and then read Using the Message Queuing Upgrade wizard.

Message Queuing, the version name for Windows 2000, is compatible with MSMQ 1.0. Simultaneously running different versions of server software in a domain is referred to as mixed-mode operation. The process of upgrading all MSMQ 1.0 controller servers (PEC, PSCs, and BSCs) to Message Queuing servers in your organization is referred to as migration.

The following table lists the differences between previous versions and the current version of Message Queuing.

Previous versions | Current version | Comments
Microsoft Message Queue Server (MSMQ) or MSMQ 1.0 | Message Queuing | Message Queuing may be referred to as MSMQ 2.0 in external literature and other external sources.
MSMQ enterprise | Windows 2000 forest |
MSMQ site | Windows 2000 site | There are no longer MSMQ-specific sites
MSMQ site link | routing link |
MQIS | Active Directory directory service | There is no longer an MSMQ-specific directory service
connected network | none | Connected networks are no longer used.
MSMQ (or MQIS) controller server | Message Queuing server on a Windows 2000 domain controller | MSMQ controller servers included the PEC, PSCs, and BSCs.
MSMQ routing server | Message Queuing server with routing services |
MSMQ independent client (running on Windows NT Server 4.0) | Message Queuing server | A Message Queuing server without routing on a nondomain controller provides the same functionality as did an MSMQ independent client running on Windows NT Server 4.0.
MSMQ independent client (running on Windows NT Workstation 4.0, Windows 95, or Windows 98) | independent client | The term independent client now applies only to Windows 2000 Professional
MSMQ dependent client | dependent client |
MSMQ Explorer | Microsoft Management Console (MMC) snap-in | 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 95, and Windows 98.

Some MSMQ 1.0 server components 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. Other MSMQ 1.0 software components are automatically upgraded during Windows 2000 Setup.

Upgrade requirements

In addition to the installation requirements discussed in the overview section, the following is a list of requirements that must be met for a successful upgrade of MSMQ 1.0 software in your organization.

  • You must export the server certificate for some MSMQ 1.0 controller server before upgrading the computer to Windows 2000. For more information, see Server authentication.
  • Synchronize all MSMQ 1.0 controller servers before you start the migration process. If there happens to be an MSMQ 1.0 controller server that is not synchronized (is unavailable or disconnected from the network) while objects are deleted from the MQIS database on another MSMQ 1.0 controller server, and then if the PEC is upgraded, there will be inconsistencies between Active Directory and the MQIS database of the unsynchronized MSMQ 1.0 controller server. For example, Queue1 is deleted from the MQIS database on the PEC. This change is then replicated to all other MSMQ 1.0 controller servers except for PSC2, which is currently unavailable. The PEC is now upgraded before PSC2 has had this change replicated to it. Active directory does not contain information for Queue1, but the MQIS database on PSC2 still contains information for Queue1.
  • The PEC computer must be promoted to a Windows 2000 domain controller before upgrading any MSMQ software.
  • PSC computers must be promoted to Windows 2000 domain controllers. Promoting BSC computers to Windows 2000 domain controllers is optional.
  • For each applicable promoted domain controller, verify that the computer is trusted for delegation before upgrading MSMQ software. This property is enabled by default. If this property is disabled, the Message Queuing service cannot run. For information on how to check if this property is enabled, see To set the delegation trust for a computer.
  • Each Windows 2000 site that operates in mixed-mode must contain at least one Message Queuing server running on a Windows 2000 domain controller that is configured as a Global Catalog Server. This is required to support MSMQ clients running Windows NT 4.0 in a Windows 2000 site, and also improves performance. For information on how to configure a computer as a Global Catalog server, see To set a computer as a Global Catalog server.
  • You must upgrade your MSMQ 1.0 controller servers in the following order:
    1. The primary enterprise controller (PEC).
    2. Then the backup site controllers (BSCs) in each site.
    3. Then the primary site controllers (PSCs) in each site.
  • You must use the Message Queuing Upgrade wizard to upgrade the PEC and each PSC.
  • You must have enterprise administrative permissions or belong to the Enterprise Admins group to run the Message Queuing Upgrade wizard.
  • You cannot upgrade MSMQ on the first primary domain controller (PDC) in a Windows NT 4.0 enterprise unless this computer is also the PEC. In all other cases, you must first uninstall MSMQ 1.0 and reinstall it before you upgrade.
  • You must have a Windows 2000 domain controller with a Global Catalog server enabled in each Windows 2000 domain.

Upgrade restrictions

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

  • You cannot migrate more than one MSMQ 1.0 enterprise to a Windows 2000 forest. If you have multiple MSMQ 1.0 enterprises, each MSMQ 1.0 enterprise must be migrated to a different Windows 2000 forest.
  • After you upgrade the PEC, you can no longer install PSCs in your Windows 2000 forest. You can still install a BSC if you specify the name of a PSC during setup. You can still install MSMQ routing servers and MSMQ clients; however, the name of the server that is specified during setup must be a Message Queuing server running on a Windows 2000 domain controller and must be a Global Catalog Server.
  • You can no longer create MSMQ sites if you are running Message Queuing server software in your forest.
  • You can no longer create standard connected networks if you are running Message Queuing server software in your forest. However, you can still create foreign connected networks.
  • You should not delete objects for a PSC (or uninstall MSMQ on the PSC) after the PEC is upgraded, otherwise you must manually remove the applicable objects from Active Directory. For information on how to remove objects for Message Queuing in Active Directory, see To remove Message Queuing objects from Active Directory.

Directory service considerations

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

Message Queuing now uses the Active Directory directory service to store configuration information and does not use the MQIS. When upgrading MSMQ 1.0 controller servers, information stored in the MQIS is automatically converted and stored in Active Directory.

In a mixed-mode environment, data replication takes place in both directions between your MSMQ 1.0 controller servers and Message Queuing servers, regardless of where a change was initiated.

The MSMQ MQIS Restore wizard (available with Windows NT Service Pack 4) is used to restore the MQIS database for a failed MSMQ 1.0 controller server. An MQIS database can be restored only from either 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 one of these computers available. When this is no longer possible, you should upgrade all remaining PSCs.

Message Queuing is now administered using Microsoft Management Console (MMC) snap-ins. Objects for MSMQ 1.0 computers that are created or modified using these snap-ins require that changes be made from the applicable upgraded MSMQ 1.0 controller server that is the owner of the object. These changes are then replicated throughout your Windows 2000 forest. Objects for MSMQ 1.0 computers that are created or modified using MSMQ Explorer are replicated throughout your Windows 2000 forest.

Site considerations

During migration, each MSMQ site is mapped to a Windows 2000 site, and all foreign connected networks are mapped to one or more foreign sites.

In a mixed-mode environment, when you create a new Windows 2000 site, a Message Queuing server running on a Windows 2000 domain controller replicates the change to all remaining PSCs, enabling them to route messages to the new site.

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 after the migration process is complete. 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 To 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 a site use only the IPX protocol, and some use only the IP protocol. If all Message Queuing servers in IPX-only sites use both the IP and IPX protocols, no configuration is required. When an IPX-only or IP-only computer fails to establish a session, the computer forwards the message to a Message Queuing server. If not all Message Queuing servers in a site use both protocols, consider adding both protocols to all Message Queuing servers or use in-routing or out-routing servers to support those computers that use only the IPX protocol.
  • Your organization uses multiple disconnected IP networks. Consider adding routers or using remote access to provide connectivity. For more information, see Routing and Remote Access. 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 the local 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 moving such Message Queuing servers and all foreign computers into a single foreign site, and then create routing links to that site.

Administrative tool considerations

MSMQ Explorer was the administrative tool used to administer MSMQ 1.0. For Windows 2000, Message Queuing is administered using the Computer Management, Active Directory Users and Computers, and Active Directory Sites and Services snap-ins in an MMC console.

If you are operating in a mixed-mode environment where a Message Queuing server is communicating with an MSMQ 1.0 controller server, you will need to continue to use MSMQ Explorer in order to access information on the MSMQ 1.0 controller server.

When upgrading to Message Queuing, MSMQ Explorer files are left on the computer, but the shortcut menu for running it is removed. You can create a shortcut for running MSMQ Explorer on the upgraded computer by copying the Mqxplore.exe file to your desktop.

When installing Message Queuing on a computer that does not have MSMQ 1.0 installed, you must copy the following files from a computer that has MSMQ 1.0 installed on it to the new computer:

  • Mqxplore.exe
  • Mqxplore.hlp
  • Mqxplore.cnt

These files are located in the \Program Files\Msmq folder of the MSMQ 1.0 computer and should be copied to the \System32\Msmq folder on the new computer.

Note

  • MSMQ Explorer is needed only on Message Queuing computers (running Windows 2000) that communicate with MSMQ 1.0 controller servers. When an MSMQ 1.0 controller server is upgraded to a Message Queuing server, MSMQ Explorer is no longer needed and will no longer function on the client computer.


Upgrading your MSMQ 1.0 computers

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

You must upgrade your MSMQ 1.0 controller servers in the following order:

  1. The primary enterprise controller (PEC).
  2. Then the backup site controllers (BSCs) in each site.
  3. Then the primary site controllers (PSCs) in each site.

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.

For specific information on how to upgrade your MSMQ 1.0 controller servers, see Checklist: Upgrade for MSMQ 1.0 controller servers.

For information on upgrading MSMQ 1.0 computers in a server cluster, see Upgrading MSMQ 1.0 on a server cluster.

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 the upgrade requirements and considerations first.

After all upgrade requirements have been met, you have promoted the computer to a Windows 2000 domain controller 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 once you have completed 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.

Note

  • If you need to run the wizard a second time on a computer, you must first stop the Message Queuing service before you rerun the wizard. Once 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 the delegation trust enabled.

For information on how to configure a computer as a Windows 2000 domain controller, see Checklist: Installing a domain controller. For information on how to configure a domain controller as a Global Catalog server, see To set a computer as a Global Catalog server. For information on how to set the delegation trust, see To set the delegation trust for a computer.

On the upgraded PEC computer only, the Message Queuing Replication service starts, which synchronizes data between Active Directory and the MQIS database on all other MSMQ 1.0 controller servers. The Message Queuing service on the upgraded PEC computer must also be running in order 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 PSC or BSC 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 a service runs under, see To change the Message Queuing service account. Be sure and double-click Message Queuing Replication (instead of Message Queuing) in the details pane.

In order to support MSMQ 1.0 computers in a mixed-mode environment running Windows NT 4.0, 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 BSC computers must be upgraded before the PSC computers 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 services, without any interaction on your part. If you have promoted the computer to a Windows 2000 domain controller during upgrade of the operating system, then 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 BSC computers must be upgraded before the PSC computers are upgraded (except for the site containing the PEC, which is also the PSC for the site). Each PSC computer must first be promoted to a Windows 2000 domain controller, the delegation trust enabled, and may also need to be configured as a Global Catalog Server (if there is no other Message Queuing server running on a domain controller 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 routing servers, MSMQ clients, and the MSMQ Exchange Connector

MSMQ routing servers, MSMQ independent and dependent clients, and the MSMQ Exchange Connector are automatically upgraded during Windows 2000 Setup, without any interaction on your part. During setup, specify the name of a Message Queuing server running on a Windows 2000 domain controller in the local site.

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

Upgrading MSMQ 1.0 on a server cluster

The following topic applies only to Windows 2000 Advanced Server users who need to upgrade an existing server cluster that is running MSMQ 1.0. Message Queuing for Windows 2000 now supports active/active failover for Message Queuing (including queues). For more information on the services Message Queuing can provide on a server cluster, see Clustered services.

All upgrade requirements and considerations described previously apply in addition to those stated as follows:

  • Windows NT Server Enterprise Edition with Service Pack 4 (SP4) or Service Pack 5 (SP5) must be running in order to upgrade a cluster node to Windows 2000 Advanced Server.
  • Before you upgrade MSMQ 1.0 software on any node, you must upgrade the operating system of the node to Windows 2000 Advanced Server. For more information, see Windows 2000 Advanced Server Getting Started, or open the \Setuptxt folder on the Windows 2000 Server CD-ROM.
  • You must have enterprise administrative permissions (or belong to the Enterprise Admins group) to run the Configure Message Queuing Cluster Resources wizard (as well as the Message Queuing Upgrade wizard).
  • A rolling upgrade of MSMQ 1.0 on a server cluster is not supported.

The following sections provide detailed information on how to upgrade the different MSMQ 1.0 computer types on a server cluster. Unless otherwise stated, the general order of upgrading MSMQ 1.0 on all computer types on a server cluster is as follows:

  1. Run the Message Queuing Upgrade wizard (Mqmig.exe) for the PEC and PSCs.
  2. Upgrade the operating system to Windows 2000 Advanced Server.
  3. Upgrade the MS DTC resource.
  4. Upgrade the MSMQ resource.

Note

  • You can also upgrade a computer running MSMQ 1.0 that is not part of an existing server cluster to a Windows 2000 server cluster. To do so, you must first upgrade the operating system of the computer to Windows 2000 Advanced Server, then install the cluster software, and then create a new Message Queuing resource. For more information on creating resources for Message Queuing, see To configure Message Queuing resources for server clusters.

Upgrading the MS DTC resource

After you have upgraded the operating system of each node to Windows 2000 Advanced Server, and before you upgrade MSMQ 1.0 software on any node, you must use Cluster Administrator to upgrade the Microsoft Distributed Transaction Coordinator (MS DTC) resource to active/active configuration first.

You must use the following process to upgrade the MS DTC resource in a server cluster:

  1. Take the MS DTC cluster resource offline.
  2. Verify that all services that are dependent on the MS DTC cluster resource, including the services for Message Queuing, Component Services, Microsoft SQL Server, and Microsoft COMTI, are stopped.
  3. On the node that hosts the cluster virtual server containing the MS DTC cluster resource, run Comclust.exe from a command prompt. This program is located in the system folder (typically C:\Winnt\System32).
  4. Run Comclust.exe on each of the remaining nodes. Do not bring the MS DTC cluster resource back online until Comclust.exe is running on all nodes in the server cluster.
  5. Manually restart all dependent services, and then bring the MS DTC cluster resource back online.

For more information on Cluster Administrator, see Using Cluster Administrator. For specific information on how to manage cluster resources, see Manage resources.

Upgrading the MSMQ resource

After you have successfully completed the process for upgrading the MS DTC resource as discussed previously, you use the Configure Message Queuing Cluster Resources wizard to upgrade the MSMQ resource to provide active/active failover support.

You must have enterprise administrative permissions (or belong to the Enterprise Admins group) to run the Configure Message Queuing Cluster Resources wizard (as well as the Message Queuing Upgrade wizard).

From Configure Your Server, click Finish Setup, and then click Configure Message Queuing Cluster Resources. Follow the instructions that appear in the Configure Message Queuing Cluster Resources wizard.

Upgrading the PEC on a server cluster

Upgrading the PEC in a server cluster is a threefold process. First, MQIS data is imported from the PEC to a Message Queuing server running on a Windows 2000 domain controller located outside of the server cluster. Secondly, each remaining PSC and BSC in your enterprise is updated by replacing the name of the PEC that is listed with the name of the domain controller the MQIS has been imported to. Lastly, the PEC is upgraded to a Message Queuing server with routing enabled.

The Message Queuing Upgrade wizard imports the MQIS to Active Directory and then changes the name listed on every BSC in the PEC site and on every PSC in your enterprise from that of the PEC to that of the domain controller the wizard is run on.

After the wizard has completed, you should inspect the All Servers To Update section of the Mqseqnum.ini file, which is located in the system folder (typically C:\Winnt\System32). This section lists those servers that were not successfully updated with the new name. The Message Queuing Upgrade wizard cannot update BSCs and PSCs that were offline or unavailable at the time you ran the wizard.

The Message Queuing Upgrade wizard must be run repeatedly until no servers are listed in the All Servers To Update section of the Mqsecnum.ini file

You must use the following process to upgrade a PEC in a server cluster:

  1. Stop the MSMQ service on the PEC.
  2. From a Message Queuing server located outside of the server cluster that is running on a Windows 2000 domain controller with a Global Catalog server enabled, log on with enterprise administrative permissions.
  3. From this domain controller, run the Message Queuing Upgrade wizard by typing the following from a command prompt:

    mqmig /c /s PEC_name_as_displayed_in_MSMQ_Explorer

  4. Inspect the All Servers To Update section of the Mqseqnum.ini file, which is located in the system folder (typically C:\Winnt\System32), to view the PSCs and BSCs that were offline or otherwise unavailable at the time you ran the wizard. Such servers are not updated with new information by the Message Queuing Upgrade wizard.
  5. If any PSCs or BSCs are listed in the Mqseqnum.ini file, run the wizard again (on the same domain controller) by typing mqmig /u from a command prompt.
  6. Repeat the previous two steps as necessary until no servers are listed in the All Servers To Update section of the Mqsecnum.ini file.
  7. After all PSCs and BSCs have been successfully updated by the wizard, stop and then restart the MSMQ service on each BSC in the PEC site.
  8. For each remaining site, stop and then restart the MSMQ service for that PSC.
  9. For each remaining site, stop and then restart the MSMQ service on each BSC in the site.
  10. Upgrade the operating system of each node to Windows 2000 Advanced Server.
  11. Upgrade the MS DTC resource on each node using Comclust.exe as previously described.
  12. Upgrade the MSMQ 1.0 resource on each node using the Configure Message Queuing Cluster Resources wizard as previously described.

Upgrading BSCs on a server cluster

BSCs are upgraded in a server cluster to Message Queuing servers with routing enabled.

You must use the following process when upgrading BSCs in a server cluster:

  1. Upgrade the operating system of each node to Windows 2000 Advanced Server.
  2. Upgrade the MS DTC resource on each node using Comclust.exe as previously described.
  3. Upgrade the MSMQ 1.0 resource on each node using the Configure Message Queuing Cluster Resources wizard as previously described.

Upgrading a PSC on a server cluster

Upgrading the PSC in a server cluster is a threefold process. First, MQIS data is imported from the PSC to a Message Queuing server running on a Windows 2000 domain controller located outside of the server cluster. Secondly, the Message Queuing Upgrade wizard updates Active Directory with information that may have not been replicated to the PEC at the time the PEC was upgraded. Lastly, the PSC is upgraded to a Message Queuing server with routing enabled.

You must use the following process when upgrading the PSC in a server cluster:

  1. Stop the MSMQ service on the PSC.
  2. From any Message Queuing server located outside of the server cluster that is running on a Windows 2000 domain controller with a Global Catalog server enabled, log on with enterprise administrative permissions.
  3. From this domain controller, run the Message Queuing Upgrade wizard by typing the following from a command prompt:

    mqmig /c /s PSC_name_as_displayed_in_MSMQ_Explorer

  4. Upgrade the operating system of each node to Windows 2000 Advanced Server.
  5. Upgrade the MS DTC resource on each node using Comclust.exe as previously described.
  6. Upgrade the MSMQ 1.0 resource on each node using the Configure Message Queuing Cluster Resources wizard as previously described.

Upgrading MSMQ routing servers and independent clients on a server cluster

MSMQ 1.0 routing servers are upgraded in a server cluster to Message Queuing servers with routing enabled. MSMQ 1.0 independent clients are upgraded to Message Queuing independent clients.

You must use the following process when upgrading these computers in a server cluster:

  1. Upgrade the operating system of each node to Windows 2000 Advanced Server.
  2. Upgrade the MS DTC resource on each node using Comclust.exe as previously described.
  3. Upgrade the MSMQ 1.0 resource on each node using the Configure Message Queuing Cluster Resources wizard as previously described.


Installing new Message Queuing servers

This topic covers the installation of Message Queuing server software on computers that do not have MSMQ 1.0 installed. For information on upgrading MSMQ 1.0 server software, see Upgrade overview for Message Queuing.

The first installation of Message Queuing in every Windows 2000 domain or site must be on a Windows 2000 domain controller. Each subsequent installation of Message Queuing on other computers in a site or domain uses the name of that domain controller to complete Setup. If a subsequent installation is unable to locate such a domain controller, Setup will install Message Queuing in workgroup mode of operation. Workgroup mode requires direct connectivity to send messages. Each time such a computer is restarted, Message Queuing will attempt to locate a Message Queuing server running on a Windows 2000 domain controller. If successful, Message Queuing will convert to domain mode of operation, which requires access to Active Directory.

Before you can run Message Queuing server setup, the following requirements must first be met:

  • To install a Message Queuing server on a Windows 2000 domain controller, you must be logged on with domain administrative permissions or belong to the Domain Admins group.
  • To install a Message Queuing server with routing services on a nondomain controller, you must be logged on with enterprise administrative permissions or belong to the Enterprise Admins group.
  • To uninstall Message Queuing, you must be granted the Delete MSMQ Configuration Object permission.

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

Installing a Message Queuing server on a Windows 2000 domain controller

For performance and scalability reasons, you should install Message Queuing server software on more than one Windows 2000 domain controller in each domain, and on at least one domain controller in each site. In addition, it is not recommended that you enable routing services for Message Queuing servers running on domain controllers; you should install such Message Queuing servers on nondomain controllers instead.

To install a Message Queuing server that will provide access to the Active Directory directory service, you must first promote the computer to a Windows 2000 domain controller. For information on how to promote a computer to a Windows 2000 domain controller, see Checklist: Installing a domain controller.

For the first installation of a Message Queuing server in each Windows 2000 site, the applicable domain controller must also be configured as a Global Catalog server. For information on how to configure a domain controller as a Global Catalog server, see To set a computer as a Global Catalog server. For more information on the Global Catalog in Active Directory, see Global catalog.

For each applicable domain controller, also verify that it is trusted for delegation before installing Message Queuing. This property is enabled by default. If this property is disabled, the Message Queuing service cannot run. For information on how to verify this property is enabled, see To set the delegation trust for a computer.

The first time you install a Message Queuing server in your forest, Setup prompts you whether to weaken security or not. This mode of operation is optional. However, to effectively support computers running MSMQ 1.0 on Windows NT 4.0 and computers that are logged on using a Local User account, security for Active Directory must be weakened. For more information, see Weakened security considerations.

For information on how to install a Message Queuing server after all requirements are met, see To install Message Queuing servers.

Installing additional Message Queuing servers

In a domain environment, when installing Message Queuing servers on additional computers in the same site, Setup automatically attempts to locate a Message Queuing server running on a Windows 2000 domain controller in the same site. If one cannot be located, you will have to provide the DNS or NetBIOS name of such a Message Queuing server when prompted before Setup can continue.

If you are installing a Message Queuing server with routing services in a mixed-mode domain environment, you must specify the name of a Message Queuing server running on a Windows 2000 domain controller in the same domain (not the name of an MSMQ 1.0 controller server) if prompted during Setup.

You can also choose to install a Message Queuing server without routing on a nondomain controller in a workgroup environment (or any other environment that does not provide a directory service such as Active Directory). In this case, direct connectivity is required to send messages.


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

  • A Message Queuing server on a Windows 2000 domain controller must already be installed in the same site and be online.
  • You must be logged on with local administrative permissions.
  • 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 only be installed on computers running Windows 2000 Professional.

Setup automatically attempts to locate a Message Queuing server on a Windows 2000 domain controller in the same site. If one cannot be located, you will have to provide the DNS or NetBIOS name of such a Message Queuing server when prompted. If such a domain controller does not exist, Setup will install Message Queuing in workgroup mode of operation. Workgroup mode of operation requires direct connectivity to send messages. Each time such a computer is restarted, Message Queuing will attempt to locate a Message Queuing server running on a Windows 2000 domain controller. If successful, Message Queuing will convert to domain mode of operation, which requires access to Active Directory.

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, direct connectivity is required to send messages.

For Windows 2000 Server, installing a Message Queuing server without routing on a nondomain controller provides the same functionality as an independent client.

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

Dependent client setup

Dependent client software can be installed on computers running Windows 2000 Server or Windows 2000 Professional, but cannot be installed on Windows 2000 domain controllers.

The Message Queuing server that supports the dependent client (by storing queues and messages) is referred to as the supporting server. Setup automatically attempts to locate such a Message Queuing server in the same site. If one cannot be located, 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.

Dependent clients and their supporting server 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 To install dependent clients.

Note

  • 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 installed or transactional messaging will not function.


Installing a new MSMQ Exchange Connector

You should install the MSMQ Exchange Connector only if it is required in your organization that Message Queuing clients be able to communicate with Microsoft Exchange clients. The MSMQ Exchange Connector is not installed during Message Queuing Setup; there is a separate setup program for installing it. The MSMQ Exchange Connector must be installed on a Message Queuing server.

The MSMQ Exchange Connector requires Microsoft Exchange Server 4.0a (4.0 plus Microsoft Exchange Service Pack 2) or later, with Exchange Administrator installed, for operation.

The MSMQ Exchange Connector (and required Message Queuing server software) does not need to be installed on a computer running Microsoft Exchange Server. You can install the MSMQ Exchange Connector on another computer and configure the connector to communicate with the computer running Exchange Server. To install the MSMQ Exchange Connector in this configuration, you must first install Exchange Administrator on the computer running Exchange Server. You can install Exchange Administrator by running Exchange Server Setup, click Complete/Custom, and select (only) the Microsoft Exchange Administrator check box.

MSMQ Exchange Connector Setup modifies the current Microsoft Exchange site configuration to recognize the connector. To be able to modify the Microsoft Exchange site configuration, you must log on with the Permissions Admin role for the site when you run MSMQ Exchange Connector Setup. For more information on setting Microsoft Exchange site roles, see your Microsoft Exchange Server documentation.

Microsoft Exchange client software does not need to be installed on any Message Queuing client computers that send messages to Exchange clients, nor does Message Queuing software need to be installed on any Exchange client computers.

Note

  • If you are installing the MSMQ Exchange Connector on a server cluster, it is recommended that you install the MSMQ Exchange Connector on a separate computer than the computer that Microsoft Exchange Server is installed on. Since Microsoft Exchange Server requires additional configuration to make it operate correctly in a clustered environment, while the MSMQ Exchange Connector does not, this will aid in installation and troubleshooting efforts.

Running MSMQ Exchange Connector Setup

Determine the following before running MSMQ Exchange Connector Setup:

  • The name of the computer running Microsoft Exchange Server that the MSMQ Exchange Connector will communicate with.
  • The name of the Microsoft Exchange site that the MSMQ Exchange Connector will support.
  • The name of the connector queue (on the Message Queuing server) from which the MSMQ Exchange Connector will read incoming Message Queuing messages. If the queue you specify during MSMQ Exchange Connector Setup does not exist, the MSMQ Exchange Connector service creates such a queue the first time it starts.
  • The user name and password of the account under which the MSMQ Exchange Connector service runs. The MSMQ Exchange Connector service should run under a user account that has sufficient permissions to function in the Microsoft Exchange Server site. This user account must also have its Microsoft Exchange site role set to View Only Admin. This need not be the same account under which you are running MSMQ Exchange Connector Setup.
  • The path to the folder that will store the MSMQ Exchange Connector message and log files. If the folder you specify during MSMQ Exchange Connector Setup does not exist, Setup creates it.

For information on how to install the MSMQ Exchange Connector, see To install the MSMQ Exchange Connector.

For information on how to configure the MSMQ Exchange Connector after it is installed, see Administering the MSMQ Exchange Connector.

For information on how to uninstall the MSMQ Exchange Connector, see To uninstall the MSMQ Exchange Connector.

Note

  • If you run Message Queuing Setup to uninstall Message Queuing software while the MSMQ Exchange Connector service is running on that computer, Setup displays a message stating that a Message Queuing application is running, and quits. Therefore, you should stop the MSMQ Exchange Connector service before uninstalling Message Queuing. For more information, see To start or stop services for Message Queuing.


Running Message Queuing unattended setup

You can use Windows unattended setup to install Message Queuing software remotely using an answer file. This file can be should be located either in the Message Queuing installation folder on the source computer you are running unattended setup from or in the Windows system folder (typically C:\Winnt) on the target computer you are installing Message Queuing to.

For more information on unattended setup for Windows 2000, see Running Setup in Unattended Mode.

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:\Winnt) 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 Windows system folder command prompt:

sysocmgr.exe /i:sysoc.inf /u:path and file name of answer file

Answer file entries

The answer file specifies various installation settings, as follows:

Msmq=

To perform an unattended installation of Message Queuing software, make sure msmq=ON. To perform an unattended uninstallation of Message Queuing software, make sure msmq=OFF.

Unattended uninstall automatically removes all message and log files.

Type=

This entry specifies the type of Message Queuing component to install. There are three valid settings: IND, RS and DEP.

Specifying IND for a computer running Windows 2000 Server or Windows 2000 Advanced Server installs a Message Queuing server without routing services. Specifying IND for a computer running Windows 2000 Professional installs an independent client. Independent client is the default installation type if the entry is not specified.

Specifying RS for a computer running Windows 2000 Server or Windows 2000 Advanced Server installs a Message Queuing server with routing enabled. You cannot specify RS for a computer running Windows 2000 Professional.

Specifying DEP installs a dependent client. You cannot install a dependent client on a Windows 2000 domain controller.

ControllerServer=

This entry specifies the NetBIOS or DNS name of the Message Queuing server running on a Windows 2000 domain controller that will be used to communicate with the Message Queuing installation type (IND or RS) being installed in the specified site. You may not have to specify this entry. Setup will try to automatically find such a server. If it fails however, unattended Setup will not continue. If an entry is specified, then unattended Setup will use the entry and will not attempt to find the server automatically.

Do not use this entry if you are installing Message Queuing on a Windows 2000 domain controller.

SupportingServer=

This entry specifies 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.

ServerAuthenticationOnly=

Use this 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 a server.

SupportLocalAccountsOrNT4=

This entry is used to support computers running MSMQ 1.0 on Windows NT 4.0 and computers that are logged on using a Local User account. If this entry is set to true, such computers are able to query Active Directory and view Message Queuing objects. If set to false, such computers are not able to query Active Directory.

If used, you must set this entry to true on the first Message Queuing server installed on a Windows 2000 domain controller in your forest.

This setting weakens Active Directory security. For the security implications of setting this entry, see Weakened security considerations.

Site=

Use this entry if you are installing a Message Queuing server with routing services enabled (RS installation type). Message Queuing Setup may not be able to automatically resolve the proper site if subnets in your network are not configured correctly. You specify the default site containing the Message Queuing server running on a Windows 2000 domain controller that this server will communicate with.

DisableAD=

This entry is used if you are installing Message Queuing in a workgroup environment or any environment that does not have Active Directory. If set to true, the ControllerServer entry is ignored and the computer will not 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 an independent client or a Message Queuing server without routing on a nondomain controller (Type=IND).

Sample answer file

You can use the following sample answer file as a template. Use a text editor to appropriately edit the entry settings.

Note

  • Unattended setup ignores any file entries that begin with a semicolon (;). You can use these to place comments in your answer file.

[Version]
  Signature = "$Windows NT$"

  [Global]
  FreshMode = Custom
  MaintenanceMode = RemoveAll
  UpgradeMode =  UpgradeOnly

  [Components]
  msmq = on | off

  [Msmq]
  Type = IND | RS | DEP
  ControllerServer = my_message_queuing_server_on_domain_controller
  SupportingServer = my_message_queuing_server_for_dependent_clients
  ServerAuthenticationOnly = false | true
  SupportLocalAccountsOrNT4 = false | true
  Site = my_domain_controller_site
  DisableAD = false | true

Be sure to test your unattended setup script before deployment.


Installing Message Queuing on a server cluster

This section applies only to users running Windows 2000 Advanced Server in a server cluster configuration. Installing Message Queuing on a server cluster will provide active/active queue failover in case of computer failure or malfunction.

Installing Message Queuing software on a node of a server cluster is no different from installing Message Queuing on any other server. However, there are several additional requirements and considerations to keep in mind when installing Message Queuing on a server cluster:

  • You should install the same Message Queuing computer type in a server cluster. For example, if you install a Message Queuing server with routing enabled on one node, you should install Message Queuing servers with routing enabled on the other nodes also.
  • The MS DTC resource must be online before installing Message Queuing on any node.
  • You must manually start the Message Queuing service on each node after Message Queuing is installed.

For information on how to start the Message Queuing service, see To start or stop services for Message Queuing.

After you install Message Queuing in a server cluster, you must create a resource for Message Queuing using Cluster Administrator and then add it a cluster virtual server. A cluster virtual server is a cluster group that contains a Disk resource and a Network Name resource. A cluster virtual server functions similarly to a physical server.

For more information on configuring Message Queuing resources for a server cluster, see To configure Message Queuing resources for server clusters.

For more information on configuring resources using Cluster Administrator, see Manage resources.

For information on upgrading MSMQ 1.0 on a server cluster, see Upgrading MSMQ 1.0 on a server cluster.


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/Remove Programs in Control Panel. When you uninstall Message Queuing from a computer, Message Queuing Setup removes all of the queues (including private queues) for that computer from Active Directory and from the local computer.

When you uninstall a Message Queuing server, all the applicable computer and queue objects are 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 To uninstall Message Queuing.

If you move any Message Queuing computer to another domain, you must uninstall Message Queuing from the computer first and then reinstall Message Queuing after the computer is located in the new domain.

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 Message Queuing objects from Active Directory, all queues and messages on the local computer are also removed. However, Message Queuing software, including registry values and messaging files, remains on the computer.

For more information on Message Queuing objects, where they are created, and where they are located in Active Directory, Message Queuing objects in Active Directory.

For information on how to remove objects for Message Queuing in Active Directory, see To remove Message Queuing objects from Active Directory.

Note

  • 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
  • Auditing for Message Queuing


Security overview for Message Queuing

Message Queuing takes advantage of the various built-in security features of the Windows 2000 operating system. Specifically, Message Queuing uses access control, authentication, encryption, and 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 computer (msmq), queue, routing link, and MSMQ Settings 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.

Authentication is implemented using public key certificates, the Kerberos V5 security protocol, and Windows NTLM (for compatibility with MSMQ 1.0 running on Windows NT 4.0). Public key certificates are used for message authentication, which verifies the sender of a message (the client) to a Message Queuing server. Kerberos V5 and NTLM are used for server authentication, which verifies a Message Queuing server to a client.

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.

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 consideration before you configure security for Message Queuing in your network, as follows:

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:

  • In a mixed-mode domain environment where users running MSMQ 1.0 (on Windows NT 4.0, Windows 95, or Windows 98) access Message Queuing servers running on Windows 2000 domain controllers. (This also applies if such users are logged on with Windows 2000 domain accounts.)
  • In a mixed-mode domain environment where users running Message Queuing (on Windows 2000) in a Windows NT 4.0 domain access MSMQ 1.0 controller servers.
  • In a Windows 2000 domain where users running Message Queuing (on Windows 2000) are logged on with Windows NT 4.0 domain accounts.
  • In a Windows 2000 domain where users are running computers that support only the IPX protocol.
  • Where users are logged on with a Local User account (regardless of the operating system).

If weakened security is enabled, such computers are able to query domain controllers and view object properties in Active Directory. If disabled, such computers are not able by default to query Active Directory. Specifically, when enabled, the Everyone group is allowed the Read permission for queue properties and queue security.

For users running MSMQ 1.0 on Windows NT 4.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 anonymous logon. To allow such an anonymous user access to Active Directory, domain security is weakened by not impersonating this call. Consequently, all queries for objects in Active Directory are accepted by Message Queuing servers. This means only that the properties of Message Queuing objects can be viewed; it does not mean that messages can be read (removed) from public queues.

You can also weaken security afterward using ADSI Edit. For information on how to do this, see To weaken security using ADSI Edit.

It is also possible to support Windows NT 4.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 is not recommended as it is considered a greater compromise of 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. In order 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, and must run under this account for Message Queuing Servers installed on Windows 2000 domain controllers to access Active Directory. For other Message Queuing computers, you can change the account 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 right.

You should only change the account that the Message Queuing Service runs under if you do not allow the Read permission for authenticated users. In this case, the following are requirements for using a specific user account to run the Message Queuing Service:

  • The user account needs to be granted the Read permission for all Message Queuing objects in Active Directory.
  • The user account needs to be added to the local Administrators group.
  • The user account should be granted the Log on as a service, Act as part of the operating system, Replace a process level token, Increase quotas, and Generate security audits rights.

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 Windows 2000 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 To 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 the queue is located on is called a local read. The operation of accessing the contents of a queue from a different computer from the one the queue is located on is called a remote read. Messages are not encrypted or authenticated when read remotely. However Message Queuing does guarantee that messages have not been tampered with.

Scripts written for Microsoft Active Server Pages may run under the security credentials of a local user account, depending on the security settings used for Internet Information Services (IIS). Messages sent using such scripts can successfully arrive at destination queues only if those queues do not restrict access for incoming messages.


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

Permissions can also be used to restrict users from sending messages to, or reading messages from, a particular queue on a computer. Although messages are not objects in Active Directory, they are protected with 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, since 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 the sender has the proper permissions to access the queue.

Note

  • 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 2000, see Access control.

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 2000, see Builtin and predefined groups.

Security descriptors for msmq objects

Which users are allowed to create queues on a computer is determined by the security descriptor for the msmq object on the computer, which in turned is determined during Message Queuing Setup, as follows.

When installing an independent client or a Message Queuing server without routing (on a nondomain controller), and you do not specify a server or you specify the name of a Message Queuing server (running Windows 2000) during setup, 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 that runs Message Queuing Setup can create queues on the computer.
  • Applications that run on a computer can create queues on that computer, given the computer communicates with a Message Queuing server running Windows 2000.
  • All users can create queues on a foreign computer.

When installing an independent client or a Message Queuing server without routing (on a nondomain 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 installing 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.

Setting permissions for msmq objects

Setting permissions for an msmq object means setting Message Queuing-specific permissions for the parent computer object. In the Active Directory Users and Computers snap-in, the msmq object is a child object of the computer object. The msmq object is also referred to as the MSMQ Configuration object.

You can change the default object permissions provided by Active Directory for this object, and you can also set additional Message Queuing-specific permissions. By default, the Everyone group is allowed to view properties and security descriptors for an msmq object.

The following table summarizes the Message Queuing-specific permissions you can 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 user or group to...
Receive Dead Letter | Read (remove) dead-letter messages from the computer dead-letter queue.
Peek Dead letter | View dead-letter messages in the computer dead-letter queue.
Receive Computer Journal | Read (remove) journal messages from the computer journal queue.
Peek Computer Journal | View journal messages in the computer journal queue.

When you grant either the Receive Dead Letter or Receive Computer Journal permission to a user or group, that user or group 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 To set permissions for computer and queue objects.

For information on how to change the ownership of an msmq object, see To 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 object permissions provided by Active Directory for this object, and you can also set additional Message Queuing-specific permissions for queues.

The following table summarizes the Message Queuing-specific permissions 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 user or group to...
Receive Journal | Read (remove) journal messages from the queue.
Receive Message | Read (remove) normal messages from the queue.
Peek Message | View messages in the queue and queue journal.
Send Message | Send a message to the queue.

By default, the Everyone group is granted the generic Write permission for a queue, and the person who created the queue is granted the generic Full Control permission. With the Write permission granted for a queue, users can send messages to the queue; these users also automatically are granted the Send Message permission.

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

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

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

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

Note

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

Setting permissions for routing link objects

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

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

By default, only users with enterprise administrative permissions (or belong 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 link objects, see To 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 object 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 To 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 Message Queuing in Control Panel, 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 To set permissions for Message Queuing files.

Note

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


Authentication for Message Queuing

Authentication for Message Queuing is implemented using public key certificates, the Kerberos V5 security protocol, and Windows NTLM (for compatibility with MSMQ 1.0 running on Windows NT 4.0). Public key certificates, or user certificates, are used for message authentication, which verifies the sender of a message (the client) to a Message Queuing server. Kerberos V5 and Windows NTLM are used for server authentication, which verifies a Message Queuing server to a client.

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 2000, 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 2000, see Authentication.

For more information on certificates for Windows 2000, see Certificates overview.

Message authentication

Message authentication is the process of verifying the user who sent a message is who they claim to be. Message authentication also guarantees that the message has not been tampered with.

An authenticated message is sent with a digital signature and a certificate. A digital signature uniquely identifies a user who sends a message. Because no user can digitally sign a message with another user's identity, no user can deny that they sent a message if it contains the correct digital signature. In turn, a certificate is used to verify a digital signature. Digital signatures are created using a public-key (asymmetric) encryption implementation.

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. Consequently, message authentication is implemented in two steps, as follows:

First, a user certificate is registered in Active Directory using a Message Queuing server that is running on a Windows 2000 domain controller. The Message Queuing server impersonates the sender of the certificate, retrieves the security ID (SID) of the sender, and registers the matching SID and certificate pair in Active Directory. The user certificate is automatically registered the first time you log on to the computer.

Next, when an authenticated message is sent, a Message Queuing application on the source computer creates a digital signature for the message, attaches the user certificate and the SID to the message, and then sends the message. The Message Queuing service on the destination computer validates the digital signature and then queries a Message Queuing server to see if the SID/certificate pair is registered. If the SID/certificate is registered, the message is considered authenticated.

More specifically, on the source computer, the Message Queuing application does the following:

  1. Creates a digital signature using a hash algorithm to compute the hash value for a particular message.
  2. Encrypts the hash value using the private cryptographic key for the source computer.
  3. Attaches the digital signature, security ID (SID), and the user certificate to the message.

On the destination computer, the Message Queuing service does the following:

  1. Decrypts the hash value for the message using the the public cryptographic key that is contained in the user certificate.
  2. Recomputes the hash value and compares it with the hash value for the message.
  3. If the values match, locates the user certificate in Active Directory and verifies that the user who registered the certificate matches the sender listed on the message and that the message was not tampered with during delivery.

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 To allow only authenticated messages on queues.

User certificates

Specifically, user certificates are used authenticate the SID of the message sender. SIDs can only be authenticated if a user certificate is first registered in Active Directory. Message Queuing verifies that the SID attached to the message is the same one that was used to register the certificate in Active Directory. A user certificate for a computer is automatically created for you during setup and registered in Active Directory the first time you log on to the computer. You can also send authenticated messages to a domain other than the domain the SID was created in.

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. The following section applies to both types of user certificates.

You manage user certificates for a Message Queuing computer using Message Queuing in Control Panel. For information on how to view all user certificates that are registered in Active Directory, see To 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. For information on how to renew user certificates, see To renew certificates for Message Queuing.

User certificates are stored on a Message Queuing server running on a Windows 2000 domain controller. If you reinstall Windows 2000 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 To remove certificates for Message Queuing. Next, you must register the new certificate manually. For information on how to register a user certificate, see To register certificates for Message Queuing.

Note

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

External certificates

External user certificates contain information that is supplied by a certification authority (CA), rather than the SID, to verify a sender's identity. The information in the 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 upon the message. For more information on certification authorities, see Certification authorities.

External certificates are required for sending authenticated messages to environments other than Windows 2000. If external certificates are used to send authenticated messages to other computers in the same Windows 2000 forest, then the external certificate needs to be registered in Active Directory only if the sender's SID will also be used to authenticate the message.

If you register such an external certificate in Active Directory, 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 provides an additional, though optional, measure of authentication, which can be used by the receiving application.

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 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 are part of a computer workgroup, as opposed to a domain.

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, there are 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 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 Message Queuing server. In a mixed-mode domain environment, the method 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 2000 | Message Queuing server running on Windows 2000 | Kerberos V5
Message Queuing client on 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 95, or Windows 98 | Message Queuing server on Windows 2000 | Windows NTLM (using a server certificate)

Server certificates are used to authenticate some Message Queuing servers. You must 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 95, or Windows 98. Message Queuing clients (running on Windows 2000) use Kerberos V5 for server authentication.

For information on how to create a server certificate, see To create server certificates for Message Queuing. For information on how to change an existing server certificate used, see To change server certificates for Message Queuing.

If you have a Message Queuing client (running on Windows 2000) 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 To 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.

If you are upgrading MSMQ 1.0 controller servers, you must first back up and export the existing key (server) certificate from Windows NT 4.0 before you upgrade the operating system to Windows 2000. You need to do this only for each upgraded server that will reply to Active Directory queries from MSMQ 1.0 clients. Again, Message Queuing clients running on Windows 2000 use Kerberos V5 for server authentication. For information on how to export your existing key certificate, see To export key certificates from Windows NT 4.0. For information on how to import a server certificate that you previously exported, see To import server certificates for Message Queuing.


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

Note

  • 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. Since 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 you 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, as follows:

On the source computer, Message Queuing does the following:

  1. Creates a secret key.
  2. Encrypts the message body using the secret key.
  3. Encrypts the secret key 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 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 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 To change the privacy level for queues.

Note

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

Cryptographic keys

Public/private cryptographic key pairs for a computer are created for you during Message Queuing Setup and can be renewed using Message Queuing in Control Panel. All Message Queuing computers except dependent clients use cryptographic keys.

For more information on encryption keys for Windows 2000, see Generating encryption keys and certificate requests.

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 an 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 To renew cryptographic keys for Message Queuing.


Auditing for Message Queuing

You can use auditing to record which users attempt to access Message Queuing objects, the type of operation attempted, and if 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 user or group.
  • A Success or Failure attribute for each access event, based on the permissions granted to each user or group in the object's discretionary access control list (DACL).

For more information on auditing for Windows 2000, see Auditing security events.

The Windows 2000 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 auditing

Before you implement auditing, you must first establish an auditing policy. An auditing policy specifies categories of security-related events you which to audit. When you establish the auditing 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 To establish an audit policy.

Next, you select the object access category and set auditing options for specific objects. Once 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 user or group. For information on how to set auditing options for a computer (msmq) or queue object, see To audit access to computer and queue objects. For information on how to set auditing options for a routing link object, see To audit access to routing link objects.

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

Note

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

Audit messages

Audit messages are created in the Windows 2000 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 Windows 2000 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
  • Administering the MSMQ Exchange Connector
  • 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 Microsoft Management Console (MMC). For a few administrative tasks, you use Message Queuing in Control Panel. 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
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
Message Queuing | Control Panel utility | some local tasks; managing user certificates and cryptographic keys

For general information about using MMC and snap-ins, see Microsoft Management Console.

MSMQ Explorer was the administrative tool used to manage MSMQ 1.0. If you are operating in a mixed-mode domain environment where a Message Queuing computer running Windows 2000 is communicating with an MSMQ 1.0 controller server running Windows NT 4.0, you will need to use MSMQ Explorer (on the computer running Windows 2000) to access information on the MSMQ 1.0 controller server. For more information, see Administrative tool considerations.

Note

  • 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, 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 2000 Professional. These snap-ins are required to administer a domain-based Message Queuing network or to access information in Active Directory. You can install these snap-ins, along with other administrative tools used to remotely administer servers, by installing Windows 2000 Administration Tools, which is provided on the Windows 2000 Server disc set. In this way, you can perform domain-based administrative tasks and access Active Directory from a Message Queuing computer running Windows 2000 Professional. For more information, see Managing servers remotely.

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

Outgoing queues are only visible 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 To manage queues and messages on other computers.

You can also manage the queues and message 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.

Note

  • You manage Message Queuing in the context of a cluster virtual server using the Computer Management snap-in only. In this case, a cluster group object is displayed, having the name of the Network Name resource of the cluster virtual server. 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 define message-route tracking.

The shortcut link used in the procedures (Step 1) to open the Active Directory Users and Computers snap-in opens MMC in author mode. Author mode allows you to make changes to snap-ins. 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 this view is always enabled by default by creating your own MMC console (.msc) file for this snap-in. To do that, on the Console menu in the snap-in, click Save As, and specify a folder and file name for the console file. The next time you open the Active Directory Users and Computers snap-in using the .msc file you created, on the Console menu, click Options, and then clear the Always open console files in author mode check box. Now the snap-in will open in user mode with the correct view enabled. Opening snap-ins in user mode is safer from an administrative standpoint as no one else can change the behavior or the look of the snap-in.

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, delete, and view routing links, and set routing link (including site gate) properties.
  • Create, view, and set foreign site and foreign computer 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. 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.

Message Queuing in Control Panel

You can use the Message Queuing utility in Control Panel 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 Windows 2000 site for messages to be forwarded to (for a mobile client).


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. 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 To create routing links.

Note

  • By default, only users with enterprise administrative permissions (or belong 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 only change routing link costs in the case where you use multiple routing links and you want to enforce one route over another route using link cost. 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 4,294,967,295. A cost of zero indicates that two sites are not connected.

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.

A routing link uses Message Queuing servers, called site gates, to route messages between two sites. If a routing link is associated with a pair of site gates, 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.

There must be two site gates assigned to a routing link; one site gate per site.

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

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 then add a Message Queuing server (that is running a connector application) to the foreign site. Foreign computers can be assigned to the same foreign site if the computers are all serviced by the same connector application. Connector applications run on Message Queuing servers and enable foreign computers to communicate with other Message Queuing computers in your network. When a Message Queuing computer sends a message to a foreign computer, the message is first routed to the connector queue on the Message Queuing server (running the connector application) that is located in the foreign site.

Common examples of Message Queuing connector applications are the MSMQ-MQSeries Bridge and the Message Queuing Connector (MQC).

For information on how to create a foreign site, see To create foreign sites.

For information on how to add a foreign computer to a foreign site, see To add foreign computers to a site.

You must create a routing link between the foreign site and each Windows 2000 site that will communicate with the foreign site. The same Message Queuing server that runs the connector application in the foreign site can also function as the site gate in that site for the routing link. However, if the site gate in the foreign site becomes unavailable, site gates in other sites that communicate with the foreign site cannot route messages 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 and configure a routing link, see Configuring routing links.

Using MSMQ-MQSeries Bridge

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 MSMQ-MQSeries Bridge and foreign computers running IBM MQSeries, see the documentation provided with the MSMQ-MQSeries Bridge.

MSMQ-MQSeries Bridge is currently provided with Microsoft SNA Server version 4.0 Service Pack 2 and later.

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 Windows 2000 Server and Windows 2000 Advanced Server disc sets 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 Windows 2000 Server and Windows 2000 Advanced Server disc sets 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/)

Message Queuing, 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 selected service ports on your firewall.

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

  • 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 read messages on Message Queuing computers located on your internal network.

Access to RPC ports 2103 and 2105 also allow remote dependent clients to send and read 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. You use the Active Directory Users and Computers snap-in and the Message Queuing utility in Control Panel 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 2000 workgroup. If Message Queuing is run on a computer that is part of a workgroup, that computer can later join a domain. Conversely, a Message Queuing computer can be part of a domain and then join a workgroup. Such a computer can then later rejoin the same or a new domain. To be able to join a new domain, the new domain must contain a Message Queuing server running on a Windows 2000 domain controller with a Global Catalog server enabled. In addition, Message Queuing computers can join only Windows 2000 domains. For information on how to join a domain from a workgroup, see To join a domain from a workgroup.

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

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

It is recommended that you configure clients to use more than one in-routing or out-routing server for redundancy.

For information on how to specify or change the in-routing or out-routing servers that a client can use, see To change in-routing or routing-servers.

Adding or removing an in-routing/out-routing server from a site list

Message Queuing maintains a site list for in-routing/out-routing servers to be used for message routing and other tracking functions. As such, in-routing/out-routing servers can be listed in multiple sites, and you can add or remove in-routing/out-routing servers from the site list. Note that the computers are not actually added or removed from a Windows 2000 site; they are merely added or removed from the site list that Message Queuing maintains.

For information on how to add an in-routing/out-routing server to a site list, see To add Message Queuing servers to a site list.

For information on how to remove an in-routing/out-routing server from a site list, see To remove Message Queuing servers from a site list.

Moving mobile clients to a new site

Mobile Message Queuing clients can be moved to other Windows 2000 sites. When you move an independent client (or a Message Queuing server with routing disabled) to a new site, all messages that are sent to the client while it is disconnected are rerouted from the the previous site to the new site. While the client connects at the new site, its messages are routed directly to the client at that site. If you specify the new site before disconnecting from the network, messages that are sent to the client while the client is disconnected are routed directly to the new site while the client is en route.

For information on how to specify a new site for mobile clients, see To specify a new site for mobile clients.

This only applies to independent clients and Message Queuing servers with routing disabled. If you move a Message Queuing server that has routing enabled (provides routing services to clients) to another site, you must uninstall Message Queuing from the computer and then reinstall Message Queuing after the computer is located in the new site.

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 and a Message Queuing server with routing enabled. 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 computer that is running both a Message Queuing server with routing services and 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 the IP address of the client computer. Support for the NetBEUI protocol is disabled by default.
  • You cannot sequentially dial into two different sites over a dial-up line without first stopping and restarting the Message Queuing Service on the client.

For more information on remote access for Windows 2000, see Remote access.

Changing the supporting server for a dependent client

Dependent clients require synchronous access to a Message Queuing server, called a supporting server. When you install a dependent client, you designate its supporting server. You can also change the supporting server used afterward.

For information on how to change the supporting server for a dependent client, see To 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 To view the dependent client list for a server.

Note

  • If you have a previous version of the 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 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 To set the message storage size for computers.

For information on how to set a computer quota for journal messages, see To set the journal storage size 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 To store messages on multiple disk drives.

Setting DNS properties

If you are operating in a DNS-only environment, such as an environment that has no WINS server, DNS settings must be configured on each computer in order for Message Queuing to correctly resolve computer names.

In addition, you should 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 tab, inspect DNS Name.

For information on how to configure DNS properties for Message Queuing, see To set DNS properties for Message Queuing.

Setting IPX/SPX properties

Message Queuing requires name resolution for networks that use the IPX protocol. You can use the Service Advertising Protocol (SAP) Agent included with Windows 2000 to provide name resolution. The SAP Agent must be running on all Message Queuing computers that use the IPX protocol. For more information on using the SAP agent, see Using the Service Advertising Protocol.

If Message Queuing computers have multiple network adapters installed and you have configured the IPX protocol for use on some of the adapters, you must specify a unique, nonzero, internal network number for each of those computers. If you do not, you can have problems using the MSMQ RPC transport provider using the IPX protocol. For information on setting network numbers, see To configure NWLink.

Testing computer connectivity

Message Queuing supports the MQPing command, which is similar to the ping feature supported by the TCP/IP protocol. Use MQPing to determine if a Message Queuing computer is currently connected to the network. When a computer running Message Queuing receives an MQPing request, it returns a response message to the response queue on the computer that sent the MQPing request.

For information on how to use MQPing, see To test connectivity using MQPing.

Administering server cluster nodes

You administer Message Queuing running on a server cluster node the same way as you would a standard Message Queuing server, using the same snap-ins.

In addition, you can also administer Message Queuing running in the context of a cluster virtual server using the Computer Management snap-in. A cluster virtual server is a cluster group that contains a Disk resource and a Network Name resource. A cluster virtual server functions similarly to a server running on a physical computer, so a Message Queuing server running in the context of a cluster virtual server provides similar services to a Message Queuing server running on a physical computer.

In order to administer Message Queuing running in the context of a cluster virtual server, the associated node the cluster virtual server is running on must be online and available.


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 is 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 To create queues, To delete queues, and To find queues.

Viewing queues

The operation of viewing the contents of a queue from the same computer the queue is located on is called a local read. The operation of accessing the contents of a queue from a different computer from the one the queue is located on is called a remote read.

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 system queues that are used exclusively for internal operation. These are interim queues that store and forward messages in transit to a destination queue. The Active Directory Users and Computers snap-in does not display these interim queues. Consequently, if a message is currently in one of these interim queues, it does not appear in the Private Queues folder.

Notes

  • When viewing private queues on a local computer, the queue "msmqadminresp" is listed. This is a temporary response queue; there are no readable messages in this queue. If you attempt to open this queue, the "Queue not found" error is displayed.
  • You may receive an insufficient resources error when running multiple Message Queuing applications (or multiple instances of an application) that read 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 according to message priority only.

For information on how to change the base priority for a queue, see To change the base priority of queues.

The queue type ID specifies the type or service provided by the queue. The queue type ID can be used to search for, open, or delete a specific type of queue.

For information on how to change the queue type ID, see To change queue type IDs.

For information on how to change the queue label, see To 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 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 To 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, see To 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 To set the message storage size for queues.

For information on how to set a queue quota for journal messages, see To set the journal storage size for queues.

Enabling target journaling

Target journaling is configured on a queue basis. If it is enabled, a copy of each incoming message is placed in the target journal queue when a message is removed (read) from the destination queue.

For information on how to enable target-journaling for a queue, see To 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 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 such a 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 To 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 dial-up 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 To take outgoing queues offline.

Sending a test message to a queue

You can send a test message from an independent client or Message Queuing server server to a test queue on any other independent client or Message Queuing server within the same Windows 2000 forest. To do so, you must first create a test queue, or change the type ID of existing queue, so that you can send test messages to the test queue on the destination computer.

Test queues have a specific queue type ID value of {55EE8F33-CCE9-11CF-B108-0020AFD61CE9}. You can convert most existing queues to function as a test queue by changing the type ID to that of a test queue. However, you should not convert a transactional queue or a queue requiring message authentication to a test queue because any test messages sent will not be delivered to such a queue.

For information on how to send a test message, see To 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 read messages in 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.

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 To 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 To set the default lifetime for messages.

You can view various properties for messages. For information on how to view message properties, see To 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 To change the message property columns displayed.

Tracking messages

You can track the route a message takes in your network either by sending a test message to a test queue or by enabling the message route tracking feature.

Sending a test message

You can send a test message from an independent client or Message Queuing server server to a test queue on any other independent client or Message Queuing server within the same Windows 2000 forest. To do so, you must first create a test queue, or change the type ID of 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.

Because all test messages are sent with the message route tracking feature enabled, the message path through your network is also tracked if the source computer has a report queue.

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

Message route tracking

You can use the message route tracking feature to track the path messages take through your network. As the messages pass through a Message Queuing server, a report message is sent to a report queue on the source computer, indicating which server the message passed through.

Using message route tracking is a two-step process. First, you enable message route tracking by creating or specifying a report queue on the source computer. Second, the applicable message property is set programmatically by the sending application.

For information on how to enable message route tracking, see To enable message route tracking. For information on the Message Queuing SDK (to set properties programmatically), see the Microsoft Platform Software Development Kit.

Each message supports only one report queue. If a route-tracked message passes through a Message Queuing server that also has message route tracking enabled, Message Queuing sends a report conflict message to the report queue on the source computer.

For example, consider three computers, called A, B, and C, where message route tracking is enabled for computer A. The Message Queuing application on computer A sends a message to computer C through Message Queuing server B. If the computer A report queue is called queue R, a report message is sent to queue R when:

  • The message leaves computer A.
  • The message arrives at Message Queuing server B.
  • The message leaves Message Queuing server B.
  • The message arrives at computer C.

However, if Message Queuing server B is also configured with message route tracking enabled, with report messages being sent to queue S, queue S receives a report-queue conflict message when the message leaves Message Queuing server B. Queue R, however, continues to receive the correct tracking messages.

Report messages are written in the following formats:

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

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 To register certificates for Message Queuing.

This utility stops and restarts the Message Queuing Service.


Administering the MSMQ Exchange Connector

Microsoft Exchange users can use the MSMQ Exchange Connector to send messages and forms to Message Queuing applications. Conversely, Message Queuing applications can use the MSMQ Exchange Connector to send messages to Microsoft Exchange users.

The following references to Exchange clients are generic. These references apply to the Microsoft Exchange client provided with Microsoft Exchange Server, Windows 95, Windows 98, Windows NT 4.0, and Windows 2000. The references also apply to Microsoft Outlook (included with Microsoft Office 97 and later).

Sending messages from Message Queuing to Exchange

The following figure shows how a Message Queuing application can send a mail message to a Microsoft Exchange user by first sending the message to the MSMQ Exchange Connector. The MSMQ Exchange Connector then reads the message from the connector queue, processes the contents, creates a Microsoft Exchange message, and sends the message to the applicable Exchange client through the Exchange server.

Figure showing messages sent from a Message Queuing client to an Exchange client

Sending messages from Exchange to Message Queuing

The following figure shows how Microsoft Exchange clients can send e-mail messages or forms to Message Queuing applications on computers. To do this, the Exchange client uses the queue label of the destination queue (with an "MSMQ" address type) to address the e-mail message. You can define this address as a custom recipient in the Microsoft Exchange Address Book.

Microsoft Exchange Server routes the e-mail message to the MSMQ Exchange Connector. Next, the MSMQ Exchange Connector converts the e-mail message into a Message Queuing message and sends it to the appropriate destination computer. A Message Queuing application on the destination computer can then read the message.

Figure showing messages sent from an Exchange client to a Message Queuing client

Notes

  • Queues on the destination computer must have a queue type ID value of {5eadc0d0-7182-11cf-a8ff-0020afb8fb50} in order to receive mail messages.
  • Because Message Queuing applications do not natively support the MAPI rich text format that Exchange uses, address entries for Message Queuing should be configured so that messages are not sent in rich text format.

Sending messages from Exchange to Exchange

Microsoft Exchange clients can send e-mail messages or forms to other Microsoft Exchange clients in other sites using Message Queuing. This is possible only if both sites have an MSMQ Exchange Connector installed on a Message Queuing server.

Microsoft Exchange Server routes the e-mail message to the MSMQ Exchange Connector. The MSMQ Exchange Connector then converts the e-mail message into a Message Queuing message and sends it to the MSMQ Exchange Connector in the destination site. The MSMQ Exchange Connector in the destination site then converts and forwards the e-mail message to the appropriate Exchange client.

Figure showing messages sent between Exchange clients using the MSMQ Exchange Connector

The figure shows how the MSMQ Exchange Connector can be used to route e-mail messages to Exchange clients in two different sites. This configuration is useful when there is no physical network connection between the two sites.

You can send messages to Exchange clients whose names appear in the Exchange Address Book. To be able to send e-mail messages to an SMTP address (or to any external address that is supported by the Exchange server), you must create a custom recipient in the Exchange address book for the recipient, and then specify CustomRecipAlias@exchinqueue as the address, where CustomRecipAlias is the email alias in the Exchange Address Book and exchinqueue is the queue label of the MSMQ Exchange Connector queue. The address type specified should be "MSMQ".

Because both Microsoft Exchange clients can natively support the MAPI rich text format, address entries can be configured so that messages are sent in rich text format.

Configuring the MSMQ Exchange Connector

You configure the MSMQ Exchange Connector using Exchange Administrator; specifically, in the MSMQ Connector Properties dialog box. On the General tab, you can specify the maximum message size. On the Address Space tab, you can configure the address space and specify the connection cost (this affects Microsoft Exchange routing). On the Options tab, you can do the following:

  • Enable or disable the processing of inbound messages.
  • Specify the maximum number of threads that can be used to process inbound messages.
  • Enable or disable the processing of outbound messages.
  • Specify the maximum number of threads that can be used to process outbound messages.

By default, four threads are used for inbound message processing, and four threads for outbound message processing. If the processing load is greater in one direction than the other, or if the server is not processing messages fast enough, the number of threads can be increased.

For information on how to configure the MSMQ Exchange Connector, see To configure the MSMQ Exchange Connector.

Note

  • When the MSMQ Exchange Connector cannot process a message, the connector puts the message in a folder called Error. This folder is located in the installation folder of the MSMQ Exchange Connector. You can delete the message, or you can attempt to correct and send it to the appropriate destination.

For information on using Exchange Administrator, see your Microsoft Exchange Server documentation.

Starting the MSMQ Exchange Connector service

The MSMQ Exchange Connector runs as a service under Windows 2000 Server. The service is called MSMQ Exchange Connector (queue label), where queue label is the label of the queue created to receive inbound messages. You specify this label during installation of the MSMQ Exchange Connector.

For information on how to start or stop the MSMQ Exchange Connector service, see To start or stop services for Message Queuing.


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 Microsoft Distributed Transaction Coordinator (MS DTC) Admin Console utility.

Monitoring events

Message Queuing logs information about its operation to the Windows 2000 event logs. Message Queuing events are located in the Source column under "MSMQ". Most events (including MSMQ Exchange Connector 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 To 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 2000 Application Log:

  • Informational. Infrequent, significant events that describe successful operations.
  • Warning. Not necessarily significant events, but indicative of potential problems.
  • Error. 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 Windows 2000 Security Log:

  • Success Audit. Generated when selected objects are successfully accessed.
  • Failure Audit. Generated when access to a selected object is denied.

For more information on auditing, see Auditing for Message Queuing.

Monitoring performance

You can monitor the performance of Message Queuing 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 Replication Service
  • MSMQ Exchange Connector

For more information on System Monitor, see System Monitor overview.

Note

  • Performance counters are not available when running Message Queuing on 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 you can use to monitor session and message statistics for the selected computer.

The value you see for memory usage includes the memory space occupied by all messages in local queues on the computer. Because recoverable messages are stored on disk, this memory space is backed up by memory-mapped files on disk, not from the Windows 2000 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 you can use to monitor message statistics for the selected queue on the computer. There are counters for each queue on the computer. If a Message Queuing application has a private queue open on another computer, a counter for that remote queue is also displayed. 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 various instances. The Computer Queues instance represents the source journal and dead-letter queues for the computer. The Bytes in Queue and Messages in Queue counters monitor that computer's dead-letter queue. The Bytes in Journal Queue and Messages in Journal Queue counters monitor a specific computer's source journal queue.

A temporary queue is identifiable by virtue that the computer name listed in the counter instance does not match the name of the computer on which the queue resides.

MSMQ Session performance object

The MSMQ Session performance object is visible only when the computer has established a session with another Message Queuing computer. Multiple instances of this object may be listed, one for each session. Instance lists the IP or IPX address of the computer with which the session is established.

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 MSMQ Replication service is running. The counters under this object monitor various performance statistics when replicating data with an MSMQ 1.0 controller server running Windows NT 4.0.

MSMQ Exchange Connector performance object

The MSMQ Exchange Connector performance object is visible only after the MSMQ Exchange Connector is installed. The counters under this object monitor various performance statistics for the connector.

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 if 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 To 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 (MS DTC), provided with Windows 2000, for monitoring transactions. You can use the MS DTC Admin Console utility to monitor statistics for transactional message and to monitor statistics for all transactions managed by MS DTC. For more information, see To view Message Queuing transactions.

When you monitor external, or two-phase, transactions, the Statistics tab provides useful information on active, committed, and aborted transactions. The Distributed Transaction Coordinator service must be running to perform external transactional messaging for Message Queuing.

For more information on transactional messaging, see Transactional messaging.

For more information on MS 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. The Message Queuing SDK includes background information on developing Message Queuing applications and a reference section that 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 several representative types of applications.

The Message Queuing SDK is located in the "Component Services" section in the Microsoft Platform SDK.

The Microsoft Platform SDK is released on a regular basis through Microsoft Developer Network (MSDN).

Web Sites

  • For the latest information on Message Queuing, see the Message Queuing Overview and Resources Web pages at the Microsoft Web site. (http://www.microsoft.com/)
  • For the latest Frequently Asked Questions (FAQ) on Message Queuing, or for Microsoft Personal Support Center, see the Message Queue Frequently Asked Questions Web pages at the Microsoft Web site. (http://www.microsoft.com/)
  • For information on computer-based training solutions from Integrity Training, Inc., refer to the Integrity Training Web site. (http://www.integritytraining.com)
  • For more information about solutions from Level 8 Systems for non-Windows platforms connectivity, refer to the Level 8 Systems Web site. (http://www.level8.com/falcon.htm)
  • For more information about message-queuing software in general, refer to the MessageQ.Com Web site. (http://www.messageq.com)

Note

  • Web addresses can change, so you may be unable to connect to all 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 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, since there is no way for you to know if something went wrong. The Message Queuing setup log file, Msmqinst.log, is located in the Windows folder (typically C:\Winnt). If this file does not pinpoint the problem, you should next look at the Windows 2000 setup log file, Setuperr.log, which is located in the system folder (typically C:\Winnt\System32).

What problem are you having?

You have completed Windows 2000 Setup, but cannot find Message Queuing

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

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

See also: Installation overview for Message Queuing

You cannot install Message Queuing or you receive an "Access Denied" error

Cause: To install Message Queuing clients, you must be logged on with local administrative permissions for the computer on which you want to install software. To install Message Queuing servers on Windows 2000 domain controllers, you need to have domain administrative permissions. To install Message Queuing servers with routing services enabled on nondomain controllers, you need to have enterprise administrative permissions.

Solution: Verify that you are logged on with the proper permissions for the computer you want to install Message Queuing on.

Solution: Allow Active Directory replication to complete and then try again.

See also: Installation permissions

You have been prompted for the name of a server during Message Queuing Setup

Cause: Setup was unable to automatically locate a Windows 2000 domain controller running Message Queuing in the local site. The first installation of Message Queuing on a site must be on a Windows 2000 domain controller.

Solution: Do the following:

  1. Verify that both the computer you are running Message Queuing Setup on as well as the domain controller have network connectivity.
  2. Verify that the Message Queuing service is running on the domain controller.
  3. Specify the DNS name or NetBIOS name of a Message Queuing server running on a Windows 2000 domain controller in the same 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 an "MSMQ application is running" error while uninstalling Message Queuing

Cause: A Message Queuing application is currently running, or the MSMQ Exchange Connector may be running.

Solution: Close all Message Queuing applications and stop the MSMQ Exchange Connector service.

See also: To 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, since there is no way for you to know if something went wrong. The Message Queuing setup log file, Msmqinst.log, is located in the Windows folder (typically C:\Winnt). If this file does not pinpoint the problem, you should next look at the Windows 2000 setup log file, Setuperr.log, which is located in the system folder (typically C:\Winnt\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 you are running the wizard in.

Solution: Configure a domain controller running Windows 2000 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 that you run the Message Queuing Upgrade wizard in.

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

You cannot find the Message Queuing Software Development Kit

Cause: The Software Development Kit (SDK) for Message Queuing is no longer included with Message Queuing.

Solution: Obtain the Microsoft Platform SDK. The Message Queuing SDK is located in the "Component Services" section in the Microsoft Platform SDK. The Microsoft Platform SDK is released on a regular basis through MSDN.


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 other snap-ins in an MMC console.

Solution: Open the Computer Management, Active Directory Users and Computers, or Active Directory Sites and Services snap-ins as needed.

Solution: On Windows 2000 Professional, you must install Windows 2000 Administration Tools first. The Active Directory Users and Computers snap-in and the Active Directory Sites and Services snap-in are not provided with Windows 2000 Professional. These snap-ins are required to remotely administer a Message Queuing server or to access objects in Active Directory from a computer running Windows 2000 Professional. These snap-ins, along with other snap-ins used to administer servers, are included with Windows 2000 Administration Tools, which is provided on the Windows 2000 Server CD.

See also: Administration overview for Message Queuing; Managing servers remotely

You cannot find any objects for Message Queuing in Active Directory

Cause: You have not selected the proper 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 object or the Domain Controllers object.

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 a custom MMC console (.msc) file for each snap-in. To do that, on the Console menu, click Save As, and specify a folder and file name for the snap-in console file. The next time you open the Active Directory Users or Computers snap-in or the Active Directory Sites and Services snap-in using these files, on the Console menu, click Options, and then clear the Always open console files in author mode check box.

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. This service must run under the LocalSystem account on Windows 2000 domain controllers in order to access objects in Active Directory.

Solution: Verify 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 you communicate with may be offline or the Message Queuing service may be stopped.

Solution: Verify that the Message Queuing server you communicate with 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 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 the Local User account.

Solution: Verify the Message Queuing server you communicate with is properly configured and has a valid server certificate.

Cause: The Message Queuing server is not running the SAP Agent. The SAP Agent is needed to support computers that communicate using only the IPX protocol.

Solution: Install and run the SAP agent on all Message Queuing computers that use the IPX protocol.

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 a few minutes.

Windows NT 4.0 clients and local users cannot access Active Directory

Cause: Weakened security permissions were not selected during the first installation of a Message Queuing server in your organization. To effectively support MSMQ 1.0 clients running Windows NT 4.0 and users running under the Local User account, security for Active Directory must be weakened.

Solution: Use the ADSI Editor provided with the Windows 2000 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 journal queue, 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 site gate may be unavailable.

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

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 Message Queuing in Control Panel to renew the certificate and then register it.

Cause: The Microsoft Base cryptographic service provider (CSP) provided with Windows 2000 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 read messages in a queue

Cause: To read messages in 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.

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-based messages are missing or lost

Cause: Express-based messages are lost whenever the Message Queuing service is stopped on a computer.

Solution: Use the message backup/restore utility to restore messages.

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 Distributed Transaction Coordinator (DTC) service may not be running. The DTC service is required for external transactions.

Solution: Start the DTC service.

A test message cannot be sent to a particular queue

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

Solution: Verify the queue you want to send the test message to 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.

See also: Sending a test message to a queue

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

Cannot locate the audit messages for a particular operation

Cause: Audit messages are stored in the Windows 2000 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 only created in the Windows 2000 Security log when a queue is opened, not each time a message is received or sent.

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

See also: Auditing for Message Queuing.

There are problems communicating with IPX computers

Cause: Message Queuing requires name resolution on IPX networks.

Solution: Start the Service Advertising Protocol (SAP) Agent to provide name resolution on all Message Queuing computers that use the IPX protocol.

See also: Setting IPX/SPX properties.

MSMQ 1.0 clients cannot authenticate a Message Queuing server

Cause: When operating in mixed-mode, MSMQ 1.0 clients (running Windows NT 4.0, Windows 95, or Windows 98) use server certificates to authenticate Message Queuing servers. The server certificate for the applicable server may be missing, or not 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 the Local User account or other unauthenticated account. Message Queuing applications cannot run under nonauthenticated accounts.

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

An insufficient resources error is displayed when running multiple applications that read messages from a remote queue

Cause: When a Message Queuing application reads a message from a remote queue, a thread is created on the local computer (the computer 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 your 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
  3. Click Edit, and then click Add Value.
  4. In the Add Value dialog box, in Value Name, enter MaxRRThreads, in Data Type click the DOWN ARROW and select REG_DWORD, and then click OK.
  5. 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.

Note

  • 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 amount of messages stored.

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


Manage queues and messages using Active Directory Users and Computers

To manage queues and messages using Active Directory Users and Computers

  3. In the console tree, right-click the applicable queue or message.

    Where?

    • Active Directory Users and Computers
    • your_domain
    • your_organizational_unit (such as Computers or Domain Controllers)
    • your_computer
    • your_queue_folder_or_queue
    • your_queue_or_message
  4. Complete the desired task. Use the applicable Computer Management procedure as a guide.

Notes

  • This method can be used only if the local computer is part of a domain running Windows 2000.
  • The Active Directory Users and Computers snap-in is not provided with Windows 2000 Professional; consequently, this procedure cannot be performed until this snap-in installed. Windows 2000 Administration Tools allows you to install the Active Directory Sites and Services snap-in on a computer running Windows 2000 Professional. For information on using Windows 2000 Administration Tools, see Related Topics.
Related Topics