Condividi tramite

How often does MSMQ crawl your forest?

  • Articolo

MSMQ comes in two parts:

  1. The moving of messages from one place to another
  2. The mapping of where messages can be sent

For this blog post, I'm concentrating on the second.

If you have Active Directory-integrated clients then you will have a lot of information stored on the domain controllers to make them work.

For example, you may want to route messages from one side of your enterprise (or forest) to the other. This requires an understanding of the site topology and availability of routing servers between sender and destination. The MSMQ service will, at regular intervals, check the shape of the forest and update it's local information when required - basically lists of all the sites and the MSMQ servers within them.

There are four registry values to control this process.

These two contain the times of the next refresh of the Enterprise (or Forest) and Site lists (expressed as the number of 100 nanoseconds units since January 1, 1601):

and these two determine how frequently the lists are refreshed:

  • DSSiteListRefresh - the time interval, in hours, in which updating the current site's list of servers will take place; new time written to DSNextSiteListRefreshTime default value is 168 hours (7 days).
  • DSEnterpriseListRefresh - the time interval, in hours, in which updating the full sites / servers list will take place; new time written to DSNextEnterpriseListRefreshTime; default value is 672 hours (28 days).

Restarting the MSMQ service will NOT force a refresh - the DSNextSiteListRefreshTime and DSNextEnterpriseListRefreshTime registry values are used to maintain the "next refresh" times across a restart. Only if they are deleted will MSMQ perform a refresh the next time the service is restarted. The registry values will be recreated based on the DSSiteListRefresh and DSEnterpriseListRefresh values.

Before Windows 2000 sp2, these settings used to be governed by the single DSListRefresh registry value; this setting is now redundant.

In a large enterprise, there may be a lot of sites and servers to be returned to a requesting machine so any changes to DSSiteListRefresh and DSEnterpriseListRefresh should be made with caution. Increasing frequency puts more load on the domain controllers and generates increased network traffic.

If the list query fails, the MSMQ service will persist at regular intervals, as dictated by:

  • DSListRefreshErrorRetryInterval - the time interval, in minutes, in which the next update (retry) of either site or enterprise data will take place in case the current update failed;default value is 60 minutes.

There are a couple of related registry values which may (or may not) be of interest:

[[Edited October 20th, 2009]]

Note - DSNextEnterpriseListRefreshTime does not appear in the registry of MSMQ Routing Servers and is not used.