Exchange Message Queue RiskLevel

When using the Get-Queue cmdlet to view configuration information for queues on Exchange servers, several properties are available for each queue such as DeliveryType, NextHopDomain, Status, MessageCount, LastError, Velocity, RetryCount, and many, many more.

Some of these properties have already been discussed in MSExchange.org articles and/or tips such as Exchange 2013 Queue Velocity. Another interesting one is RiskLevel:

So what is this Risk Level property? Well, according to the Queue filters TechNet article, “this property is reserved for internal Microsoft use, and isn't used in on-premises Exchange 2013 organizations.” As such, I am assuming on-premises customers do not need to worry about this. But just for information, according to the MSDN RiskLevel enumeration webpage, this property has four possible values:

• Normal: The associated message is normal risk.
• Bulk: The associated message is part of a bulk mailing.
• High: The associated message is high risk.
• Low: The associated message is low risk.

Exchange 2013 Queue Velocity

When you use the Get-Queue cmdlet in Exchange 2013 you will see a Velocity property (not visible in the Queue Viewer tool):

So what exactly is this Velocity? Does zero means no emails is coming in or going out? Is zero a good thing?

The Velocity property is simply the drain rate of the queue. Exchange 2013 measures the rate of messages entering and leaving every queue and stores these values in queue properties. These rates can be used as an indicator of queue and transport server health. There are three properties: Velocity (which we have seen in the previous screenshot) and IncomingRate and OutgoingRate, both visible in the screenshot just below:

Their meaning is as follows:

IncomingRate

This values is the rate at which messages are entering the queue. It is calculated from the number of messages entering the queue every 5 seconds averaged over the last 60 seconds. The formula can be expressed as (i1+i2+i3+i4+i5+i6)/6, where in is the number of incoming messages in 5 seconds.

Let us say that, as an example, we received 12 messages in the first 5 seconds and then 8 in the following 5 seconds. As such, our incoming rate is (12+8)/6 = 3.333

OutgoingRate

This value is the rate that messages are leaving the queue. It is calculated from the number of messages leaving the queue every 5 seconds averaged over the last 60 seconds. The formula can be expressed as (o1+o2+o3+o4+o5+o6)/6, where on is the number of outgoing messages in 5 seconds.

Continuing with our previous example, let us say that in the first 5 seconds 4 messages were sent, followed by 7 messages in the following 5 seconds and 9 messages in the next 5 seconds. As such, our outgoing rate is (4+7+9)/6 = 3.333

Velocity

This property is the drain rate of the queue, and is calculated by subtracting the value of IncomingRate from the value of OutgoingRate.

In our example Velocity = OutgoingRate – IncomingRate = 3.333 – 3.333 = 0.

Although messages took slightly over to leave the queue (5 extra seconds), remember that what is considered is the average over the last 60 seconds, in which case, messages left the queue at the same time they entered in our example.

• If the value of Velocity is greater than 0, messages are leaving the queue faster than they are entering the queue.
• If the value of Velocity is equals 0, messages are leaving the queue as fast as they are entering the queue. This is also the value we see when the queue is inactive.
• If the value of Velocity is less than 0, messages are entering the queue faster than they are leaving the queue, which is not ideal.

Bottom line: a positive value of Velocity indicates a healthy queue that is efficiently draining, and a negative value of Velocity indicates a queue that is not efficiently draining.

Does this mean I need to worry whenever this value is not zero? Well, not exactly. We also need to consider the values of the IncomingRate, OutgoingRate, and MessageCount properties, as well as the magnitude of the Velocity value for the queue. If someone all of the sudden sends a large email to everyone in your organization, it is possible that the Velocity will be negative for a short while.

Resubmit Messages in Queues

There might come a time where you experience a problem with you Hub/Edge Transport servers, Mailbox servers or e-mail gateway and messages are stuck in Queues. Once you resolve the issue, you can either wait a few minutes for Exchange to resubmit the e-mails or you can manually resubmit them to the Submission queue for the categorizer to reprocess as long as they have the following status:

·         Mailbox delivery queues or remote delivery queues that have the status of Retry. The messages in the queues must not be in the Suspended state;

·         Messages in the Unreachable queue that aren't in the Suspended state;

·         Messages in the poison message queue.

 

 

To manually resubmit messages, you can use the following methods (examples below):

·         Use the Retry-Queue cmdlet with the -Resubmit parameter;

·         Export the messages to .eml message files and resubmit them by placing them in the Replay directory;

·         Use Queue Viewer or the Resume-Message cmdlet to resubmit the messages in the poison message queue. You can’t use the Retry-Queue with the -Resubmit parameter cmdlet to resubmit messages in the Poison Queues.

 

 

By using the –Resubmit parameter, messages are forced to be resubmitted through the Categorizer for a new delivery attempt. If you do not use the –Resubmit parameter, the delivery queue will try to connect to the next hop immediately without resubmitting the messages through the Categorizer.

 

 

Let’s look at a few examples:

1. To export a copy of a message (so you can put it into the Replay directory) that has an InternalMessageID of 1234 that's located in the remote delivery queue for the domain MSExchange.org on the server HUB01 to the path C:\MSExchange Export\export.eml:

Export-Message HUB01\MSExchange.org\1234 -Path “C:\MSExchange Export\export.eml”

2. To resubmit all the messages in the 62306 delivery queue of the HUB01 server, use the following cmdlet (you can’t use the EMC):

Retry-Queue “HUB01\62306” -Resubmit $True

3. To resubmit all the messages in all delivery queues of server HUB01 that have a status of Retry (again, you can’t use the EMC):

Retry-Queue –Server “HUB01” -Filter {Status -eq "Retry"} -Resubmit $True

4. To resubmit all messages located in the Unreachable queue of server HUB01, use the following cmdlet (again, you can’t use the EMC):

Retry-Queue “HUB01\Unreachable” -Resubmit $True

5. Let’s force a connection attempt for all queues that are holding messages for the domain msexhange.org, have a status of Retry and are located on the server HUB01:

Retry-Queue –Server “HUB01” -Filter {NextHopDomain -eq “msexchange.org” -and Status -eq “Retry”}

 

6. To resubmit messages in the Poison Queues, you have to resume the messages. As I mentioned previously, the Poison Queue cannot be resubmitted by using the Retry-Queue cmdlet with the -Resubmit parameter.

Remember that the Poison Queue contains messages that are determined to be harmful to the Exchange system after a server failure. They may also be victims of a poorly written agent that crashed the Exchange server while it was processing them. If you're unsure of the safety of the messages in the poison message queue, you should export them to files so you can examine them.

 

Using the Exchange Management Console to resume messages in the Poison Queue:

1.       In the EMC click Toolbox;

2.       Open the Queue Viewer tool;

3.       In Queue Viewer, click the Queues tab;

4.       Click the Poison Queue and select View Messages;

5.       Select one or more messages from the list, right-click them and select Resume.

 

To use the Shell you must first determine the identity of the message to be resumed. This example will show the identity of all messages in the poison queue:

Get-Message -Queue “Poison” | Select Identity

 

Now you can use the identity to resume the message. For example, let’s resume the message with an identity value of 123:

Resume-Message 123

 

Empty Poison Queues

If for some reason you have e-mails in a Poison Queue and you can’t get rid of them using the Exchange Management Shell [EMS] or Console [EMC], here is another method:
1. Open the Windows Services MMC;
2. Find the Microsoft Exchange Transport service and Pause it;
3. Open the EMS and run Get-Queue –Server <server_name> until all the queues are empty (except for the Poison queue);
4. Once all queues are empty stop the Microsoft Exchange Transport service;
5. Navigate to the location where your transport database is located (by default C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\data\Queue\) and delete all files in that folder;
6. Start the Microsoft Exchange Transport service.

Exchange will create a brand new database and your Poison queue will be cleared!