When troubleshooting various Exchange issues it can be very beneficial to get a network capture to look at the actual packets going over the wire.  For example when looking at Outlook connectivity issues we can enable Outlook client logging and RPC Client Access Logging on the Exchange Server.  Both are both great troubleshooting tools and while we can solve a lot of issues with that information, there can still be great value in looking at the actual network packets.  Is there some inline WAN optimisation device that is causing an issue or do we see retransmits?

Unlike in days of old * we do not install the full version of NetMon from the SMS installation media, it can be downloaded from the Microsoft Download Centre. 

Note that there are separate packages for x86, x64 and Itanium installations.  Ensure that you chose the correct type else it will not install.   

Installing Network Monitor is straightforward.  It will install the tool itself, and then the parsers which are required to split and analyse the traffic.  The parsers that come with the Netmon download are a bit out-dated nowadays.  The latest parsers can be downloaded from Codeplex.   Installing the newer parsers will overwrite the older ones. 

By default Netmon 3.4 will install into C:\Program Files\Microsoft Netmon 3.  This folder is used for both x86 and x64 installations since the image type is native to the OS. 

I won’t go into detail in using the Netmon GUI, rather let’s focus on the command line aspects of capturing.  As it can be easier to capture data this way rather than explaining what buttons or options someone has to select in the UI.  From a Microsoft perspective this allows us to send out a command that we know will be correctly executed and the required data gathered.  Else the data could be missed and we have to wait for another occurrence thus delaying the troubleshooting. 

The GUI Network Monitor executable file is Netmon.exe.  For command line work we need to use NMCap.exe. 

Quick & Simple Examples

Some quick examples before we go down the rabbit hole……

Capture All Traffic To A Rolling Log File

NMCap.exe /Network * /Capture /File C:\Netmon.cap:100MB

Capture Traffic On A Named Interface – Local Area Connection

NMCap.exe /Network “Local Area Connection” /Capture /File C:\NetMon.cap:100MB

Capture All Traffic – Chained Log Files

NMCap.exe /Network * /Capture /File C:\Netmon.chn:100MB

Command Line Options

To explore all of the command line options open an elevated CMD prompt, and change directory to C:\Program Files\Microsoft Netmon 3 directory.  Once there run

NMCap.exe /?

To see examples run:

NMCap.exe /Examples

I’ll let you pick through all of the syntax, but there are a couple to note.  First up, the file extension controls if circular logging is used.

/File <Capture File>[:<File Size Limit>]   Name of capture file to save frames to. Extensions are used to determine the behavior of NMCap.
       .cap -- Netmon 2 capture file
       .chn -- Series of Netmon 2 capture files: t.cap, t(1).cap, t(2).cap...
      <File Size Limit> is optional. It limits the file size of each capture file generated.  Default single capture file size limit is 20 MB. The upper bound of the file size limit is 500 MB. The lower bound of the file size limit depends on the frame size captured. (Note that the maximal size of Ethernet frames is 1500 bytes).  The files are circular, so once the size limit is reached, new data overwrites older data.

      Example Usage: /File t.cap:50M

There are various start and stop conditions that can be used.  They can be time or action based.  If noting is specified use Ctrl + C to stop the capture.  Take a look at the help for more details on /TerminateWhen, /StopWhen and /StartWhen. 

Capturing Data Via The Command Line

In Short the command line steps are:

1. Open elevated CMD prompt
2. Ensure C:\Netmon folder exists
3. Change directory to C:\Program Files\Microsoft Netmon 3 directory
4. Run the Netmon capture command

One thing to note!  There are options to limit the networks that data will be captured on.  For example Nmcap.exe /Network 3 could be used.  How do we know what networks are present, and which interface is what?

NMCap.exe /DisplayNetwork to the rescue!

Netmon Bundled Examples

Example 1:

This example starts capturing all TCP frames and will be saved in a capture file name tcp.cap. If you want to stop capturing, Press Control+C.

nmcap /network * /capture tcp /File tcp.cap

Example 2:

This example starts capturing network frames that DO NOT contain ARPs, ICMP,NBtNs and BROWSER frames.  If you want to stop capturing, Press Control+C.

nmcap /network * /capture  (!ARP AND !ICMP AND !NBTNS AND !BROWSER) /File NoNoise.cap

Example 3:

This example starts capturing network frames that are TCP Continuations. The capture filter is searching for String "Continuation in TCP Frame Summary Description. In order to see the complete list of Netmon Properties that are filterable,type ".Property" in the Netmon Filter UI.

nmcap /network * /capture contains(.Property.Description, \"Continuation\") /File TCPContinuations.cap

Example 4:

This example starts capturing network frames at 3:17 PM on September 10, 2002.  All DNS frames that contains the QRecord Questions name 'my_computer' will be saved in a capture file named dns.cap. The size of the capture file will not exceed 6 megabytes. If the user presses x at any time during this capture, the program will terminate, otherwise the capture will stop 10 minutes after it has begun.

nmcap /network * /startwhen /time 3:17:00 PM 9/10/2002 /capture contains(dns.qrecord.questionname,'my_computer') /file dns.cap:6M /stopwhen /timeafter 10Min /TerminateWhen /KeyPress x

Example 5:

This example starts capturing network frames after 10 seconds past. All IPv4 frames that received by local machine which has IP address 192.168.0.1 will be saved in a capture file named ip.cap. The size of the capture file will not exceed 4 megabytes (the default size). If the user presses c at any time during this capture, the program will terminate, otherwise the capture will stop 10 minutes after it has begun.

nmcap /network * /startwhen /timeafter 10 /capture ipv4.destinationaddress == 192.168.0.1 /file ip.cap /stopwhen /timeafter 10 min /TerminateWhen /KeyPress c

Example 6:

Starts capturing network frames immediately. All TCP frames that have a source port or destination port of 80 are saved to the chained capture files named test.cap, test(1).cap, test(2).cap, ... When the user presses the 'x' key the program stops.

nmcap /network * /capture tcp.port == 80 /file c:\temp\test.chn:6M /stopwhen /keypress x

Example 7:

Starts capturing network frames immediately. All syn TCP frames that have the specified IPv4 network address are stored into to the capture file t.cap. The program stops when the TCP connections ends.

nmcap /network * /startwhen /frame tcp.flags.syn == TRUE AND ipv4.Address == 192.168.0.1 /capture /file t.cap:8M /stopwhen /frame (tcp.flags.fin == TRUE OR tcp.flags.reset == TRUE) AND ipv4.Address == 192.168.0.1

Example  8:

This example reassembles fragmented frames of capture.cap at all layers possible. The resultant capture file, Reassembled.cap will contain the Reassembled payloads alongwith the original unfragmented frames.

nmcap /inputcapture capture.cap /reassemblecapture /file Reassembled.cap

Example  9:

This example starts capturing frames and will be saved in a capture file name result.cap. If you want to stop capturing, Press Control+C. When the free disk space is less than 20% the total space of current disk, capture will stop as well.

nmcap /network * /capture /File result.cap /MinDiskQuotaPercentage 20

Example 10:

This example starts capturing frames and also tracks processes that generated network traffic. The resultant output file is ProcessTraffic.cap.

nmcap /network * /capture /File ProcessTraffic.cap /CaptureProcesses

Advanced Examples

The examples below are from real troubleshooting incidents.  Note that %computername% is embedded into the output file so that we can easily identify which capture is which.  Just like in 1994 and we have CV~1.doc, CV~2.doc and CV~3.doc on a floppy disk, it’s a real pain looking at a bunch of files called capture.cap.  Yes we can place them in folders, but they often get messed up!

One of the neat things is that NMCAP uses the same filter syntax as Netmon.exe.  That means you can tweak and develop the capture filter in the UI and then transpose it.  

In the examples below we are using the Blob mechanism to determine the data that we want to capture.  While this is not explicitly documented in the NMCap help content, it does fall within the [FrameFilter] section.  As discussed on the NetMon team blog, to create a filter using the Blob, you need to know the offset and length of the pattern you are matching. Often, the simplest way to do this is open a trace you’ve taken from the network you are interested in, and click on the field in question. Then look in the hex details for that location and offset. 

Below is an example of this.  We have highlighted the IPv4 Destination Address field.  Note in the Hex Details pane, the Frame Offset is then show as 30 with the Sel Bytes of 4. 

For this example the filter would be Blob(FrameData, 30, 4) == 192.168.2.40 

Neat, eh?  I have to thank Curtis Houck for introducing this to me  

Advanced Example 1

Capture all data between Source IP 192.168.16.5 and Destination IP 131.107.2.200.

In this example we will capture on any network, limiting FrameLength to 256 Bytes  with an series of chained output files each of which are limited to 100 MB.  The capture filter uses the Blob methodology described above for high performance parsing.   Blob(FrameData,26,4)==192.168.16.5  is the filter for IPv4 Source Address.  Blob(FrameData,30,4)==131.107.2.200  is the IPv4 Destination Address filter. 

Nmcap /network * /maxframelength 256 /capture Blob(framedata,26,4)==192.168.16.5 or Blob(framedata,30,4)==131.107.2.200 /file C:\NetMon\%computername%.chn:100MB

Advanced Example 2

Capture all data between to Destination IP 192.168.2.15 on network interface 6

This example is similar to the

Nmcap /network 6 /maxframelength 256 /capture Blob(framedata,30,4)==192.168.2.15 /file C:\NetMon\Capture\%computername%.chn:100MB

Cheers,

Rhoderick

* – I still think that I miss having to re-install the service pack on NT and getting prompted to restart just by looking at the network connection properties.  I think….

Some folks in the field may have seen this before, but it’s worth bubbling up to make sure everyone is aware of it! 

I was sitting with one of my esteemed consulting colleagues today and he remarked that it was talking a long time to run one of his Exchange PowerShell scripts.  The customer in question is a global organisation with hundreds of Exchange servers in all corners of the globe.  My colleague was ensuring that the customer had correctly implemented the design and in essence was auditing the configuration.  The script was taking several hours to run.

This customer actually has very good WAN links across the globe and the lines are dedicated for their usage, else the script could have taken even longer! 

Whilst discussing this over coffee, and how to wear a shirt correctly (don’t ask), I asked how he was accessing the Virtual Directory information.  He was using the default mechanism, which unfortunately is the slowest.  So when pulling in the data from each server’s virtual directory it was taking a long, long time.  You will see these symptoms with any of the following cmdlets:

• Get-WebServicesVirtualDirectory
• Get-OwaVirtualDirectory
• Get-ActiveSyncVirtualDirectory
• Get-AutodiscoverVirtualDirectory
• Get-EcpVirtualDirectory
• Get-PowerShellVirtualDirectory
• Get-OABvirtualDirectory

For the purposes of this article, we shall use the Get-OwaVirtualDirectory cmdlet, but the behaviour is mirrored for all of the above.  The core parameters are the same for all of these cmdlets.   Here is the Exchange 2013 link for Get-ActiveSyncVirtualDirectory for example. 

What Causes This

When Get-OwaVirtualDirectory cmdlet is executed against a server the default mechanism is to go over the wire and make RPC calls to the IIS Metabase on that sever.  This is fine if the server making the request and the target  are in the same datacentre.  It is not so fine if they are on different continents! 

How To Workaround This

The solution to this is frustratingly simple.  We can add a parameter to the cmdlet which instructs it not to go to the remote server to get the answer, rather it will query AD to get the data.  Since this data is stored within the Configuration naming context in AD, and those Global Catalog servers are conveniently spread across the enterprise we can make a query to a local GC obviating the need to make a remote query. 

As an example, you may be running this:

Get-OwaVirtualDirectory -Identity "Contoso\owa (default Web site)"

To query AD, simply add –ADPropertiesOnly switch

Get-OwaVirtualDirectory -Identity "Contoso\owa (default Web site)" –AdpropertiesOnly

One thing to note the properties stored in the Internet Information Services (IIS) metabase aren't returned when ADPropertiesOnly is used.  Only the properties stored in AD are returned.  Funny, eh?

Update 12-9-2014: Please also see this post if you are looking for authentication attributes as you may be misled by the results.

Real World Example

Sitting at a machine in Canada running Get-OwaVirtualDirectory against a Singapore machine took just over 5 minutes to return data.  With the AdpropertiesOnly parameter I could see the internal and external URLs in less than 2 seconds!  WIN !!

Bonus Tip

I personally hate having to specify the "Contoso\owa (default Web site)" text when running such cmdlets as it takes more time and is error prone.   To avoid this I just specify the server using the –Server parameter.  For the vast majority of installations a server has a single OWA VDir so this works well.  Should an Exchange 2007/2010 server have multiple OWA VDirs then you may have to be more specific. 

Get-OwaVirtualDirectory –Server Contoso-CAS01  –AdpropertiesOnly

One final thing!  Don’t go looking for ADPropertiesOnly in an Exchange 2007 Management Shell.  It is not there.   The below is from an x64 Exchange 2007 SP3 RU10 machine.

Cheers,

Rhoderick

If you are looking for a “How To” guide to assist with getting started with Office 365 then you will want to take a look at the latest Test Lab Guides that are now available to TechNet.  They were published last week and are hot off the virtual press!

The Test lab Guides are intended to be a series of documents that all leverage a common platform so you do not have to spend time creating a lab from scratch or understanding the underlying infrastructure. 

The recent of articles of note from an Office 365 perspective are:

• Test Lab Guide: Creating a Windows Azure AD and Windows Server AD Environment using DirSync with Password Sync
• Test Lab Guide: Creating a Windows Azure AD and Windows Server AD Environment with Federation (SSO)
• Test Lab Guide: Configuring an Office 365 Trial Subscription

If you want to see all of the test lab content that has been published, go take a look at their blog and for notifications sign up for the RSS feed.

Cheers,

Rhoderick

PS – The astute of you out there may have noticed the spelling used in this post’s title, which was for search engine reasons,  is not my normal spelling.  

As part of my relaxing holiday, I spent a fair bit of time upgrading the hardware in my lab and installing Windows Server 2012 R2 onto all of my Hyper-V hosts.  I then went through and pruned out some old test VMs and made sure the ones I had left were still relevant.

After I did the upgrade to 2012 R2 and powered on some machines that had been dormant for a few months, actually quite a few months (years in some cases), I got some errors when powering some machines on.

Update 30-4-2014: Added clarification that icacls.exe should be executed in cmd prompt session and not PowerShell.

The KB has article Hyper-V virtual machine may not start, and you receive a “‘General access denied error’ (0x80070005)” error message covers the scenario of missing permissions to .vhd files.  I saw a similar thing but with the .vsv and .bin files.  On a side note you may or may not see the pre-created .bin file with newer Hyper-V versions.  Back to the issue, what was going on?

The symptoms that I observed were that:

• The VM would import successfully
• Powering on would result in an error  - could not create or access saved state file
• Error 3080 was logged into the Hyper-V Worker event log

An example of the error is shown below:

PS C:\> Start-VM Typhoon

Start-VM : 'Typhoon' could not initialize. (Virtual machine ID 5BEF5A39-069D-4887-8688-8D80A505A88C)
'Typhoon' could not create or access saved state file E:\Configs\Typhoon\Typhoon\Virtual
Machines\5BEF5A39-069D-4887-8688-8D80A505A88C\5BEF5A39-069D-4887-8688-8D80A505A88C.vsv. (Virtual machine ID 5BEF5A39-069D-4887-8688-8D80A505A88C)
You do not have permission to perform the operation. Contact your administrator if you believe you should have permission to perform this operation.
At line:1 char:1
+ Start-VM Typhoon
+ ~~~~~~~~~~~~~~~~
     + CategoryInfo          : PermissionDenied: (Microsoft.HyperV.PowerShell.VMTask:VMTask) [Start-VM], Virtualization
    OperationFailedException
     + FullyQualifiedErrorId : AccessDenied,Microsoft.HyperV.PowerShell.Commands.StartVMCommand

Fortunately this was quick to fix, along the same line as the aforementioned KB.

Service SID

Before we dive in and correct the issue one thing worth mentioning is around the underlying Windows feature that Hyper-V uses –  per service  security identifier (SID).  Windows Server 2008 introduced the concept of the service SID to further strengthen windows services and to provide even more granularity when applying permissions.  You can read more about them on the askperf blog.   The service SID for a Hyper-V VM is made up of two parts.  The identifier  NT VIRTUAL MACHINE and then the GUID of the VM.   For example:

NT VIRTUAL MACHINE\5BEF5A39-069D-4887-8688-8D80A505A88C

This is the security context that is used to access the various files that make up the VM.  The VM Worker Process will leverage this to work with the files.  To see this we can open up task manager and on the details tab see the GUID listed in the user name field:

Granting Permissions To The Service SID

We will use ICacls.exe to add the service SID ACE entry to the .bin and .vsv files.

We need to know the service SID, so take the GUID of the VM and add that to “NT VIRTUAL MACHINE\”  -- note that there is a back slashbetween the two.  This in essence becomes the user name that will be granted the permissions:

Example:  NT VIRTUAL MACHINE\5BEF5A39-069D-4887-8688-8D80A505A88C

Based off the error message we know that we need to add permissions to the .bin and .vsv files.   The syntax used was:

ICacls.exe 5BEF5A39-069D-4887-8688-8D80A505A88C.bin /grant "NT VIRTUAL MACHINE\5BEF5A39-069D-4887-8688-8D80A505A88C":(F)

ICacls.exe 5BEF5A39-069D-4887-8688-8D80A505A88C.vsv /grant "NT VIRTUAL MACHINE\5BEF5A39-069D-4887-8688-8D80A505A88C":(F)

Note that the above lines will wrap, and that they are a sample.  You will need to adjust to match your GUID, it will be different!  That’s the whole point of a GUID!

If the permissions are correctly set then it will say that each file was successfully processed as per the below:

One the NTFS permissions have been changed, power on the VM and you should be good to go!

On a parting note, Ben Armstrong has a post detailing the layout of a VM and the purpose of each file.  Well worth subscribing to his RSS feed!

ICACLS Error

Added 30-4-2014.  Added this section to point out that the above screen captures are in essence cmd prompt windows. 

If you try and run icacls.exe in a PowerShell session then you will probably get this error:

F : The term 'F' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:146
+ ... AC970011E8F5":(F)
+                    ~
    + CategoryInfo          : ObjectNotFound: (F:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

To illustrate this, let’s fire up a standard PowerShell window, and then change it to a cmd prompt.  “This is PowerShell” is written to the screen to prove that initially this is PowerShell.  We then switch to cmd prompt and use ECHO to write the next message to the screen. 

Note that the prompt indicator changes from  “PS C:\Users>” to “C:\users>”.  To illustrate this the above screenshot has the two prompts highlighted, note the difference….

Cheers,

Rhoderick

Exchange 2010 added multiple features to improve the resiliency of messaging services.  Notable additions included client throttling to ensure that a single mailbox would not consume excessive resources and mailbox quarantine.

Mailbox quarantine is enabled by default, and the first time a lot of admins discover the feature is when a mailbox gets quarantined and the user loses access to their mailbox.   In Exchange 2010 the default quarantine value is 6 hours.  Think about that for a minute, if a mailbox gets quarantined at 09:00, then it will exit quarantine at 15:00.  Whilst a mailbox is quarantined there is no access to the mailbox.  Only by passing the open as admin flag can it be opened.  The mailbox cannot be moved, indexed, opened in OWA/EAS/Outlook or anything whilst it is quarantined.  Quarantined really does mean quarantined…..

Some customers may be OK with the Exchange 2010 6 hour default quarantine duration, others not so much.  TechNet also states that Exchange 2013 has a 24 hour default quarantine duration.

Lets take a look at the feature to investigate what we can configure.  Some other questions that we want to answer are:

• How to configure quarantine
• How to change the quarantine duration
• I changed the quarantine duration, but it made no difference.  Mailboxes are still quarantined for 6 hours.
• How do I test quarantine

Defend The Flag

Exchange 2010 has a single store.exe process where all the databases are loaded, so it is imperative that this critical process is as well defended as possible.  If the store were to crash or get hung up on a single thread then all mailboxes would be affected.  Exchange 2013 implements multiple store.exe processes to mitigate impact.  By analysing the status of mailbox threads, Exchange can determine if a single mailbox is impacting the store.  It is possible that a single mailbox with corrupted data could cause store to crash or become unresponsive.  If this happens repeatedly,  then that would be considered a poison mailbox.  As described on TechNet there are a couple of items that store considers naughty:

• Mailbox Threads crashing
• Stuck threads that have not progressed for an excessively long time

A mailbox that exhibits these behaviours is tagged, and a count is kept.  So that this data is non-volatile and made available to multiple servers in a DAG, it is persisted in the registry.  In a DAG the cluster service replicates this information via the cluster database.    If a mailbox does get tagged with one of these issues you will see the entry here:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-{dbguid}\QuarantinedMailboxes\{mailbox guid}

With CrashCount or LastCrashTime holding the necessary data. 

The key is not created until the store has crashed at least one time by a mailbox.

The default behaviour is to quarantine a mailbox if identified as causing a failure or deadlock three times in a two hour timespan.  Store tags the mailbox as quarantined in the registry and the user cannot get access to the mailbox.  The only access allowed is if the Open_As_Admin flag is passed, you can do this with MFCMapi for example and take a look at the mailbox contents.

The QuarantineState and QuarantineTime registry keys are used to keep track of the quarantine status. 

Mailboxes are automatically released from quarantine if quarantined for longer that the quarantine duration (MailboxQuarantineDurationInSeconds) since it’s last LastCrashTime.  

If the mailbox does not cause further issues, then the registry will be cleaned up.  So if there are no failures in the previous two hours and the mailbox is not currently quarantined the registry will be cleaned up. 

How to Configure Mailbox Quarantine

This is where it gets a little bit interesting!  There are a couple of registry keys that we want to examine:

MailboxQuarantineCrashThreshold  - number of failures which cause mailbox to be quarantined.  By default this is three (3). 

MailboxQuarantineDurationInSeconds – amount of time a mailbox will stay quarantined. This is specified in seconds.  By default the Exchange 2010 value is 21,600 (6 hours). 

TechNet documents the time period for resetting quarantined mailboxes is controlled by the registry key:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-{dbguid}\MailboxQuarantineDurationInSeconds.

Unfortunately there is a lot of content out on them interwebs which state that the registry value must be created in other locations.  For example a quick search suggested these locations:

HKLM\SYSTEM\CurrentControlSet\Services\MSexchangeIS\ParameterSystem\Servername\Private-dbguid\Quarantined Mailboxes\MailboxQuarantineDurationInSecond

or

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<ServerName>\Private-{dbguid}\QuarantinedMailboxes\MailboxQuarantineDurationInSecond

Note that the MailboxQuarantineDurationInSeconds value is NOT below the QuarantinedMailboxes key, it is actually above it. 

How To Test Quarantine

Exchange 2013 has the Enable-MailboxQuarantine and   Disable-MailboxQuarantine cmdlets which allows the admin to easily control when a mailbox is placed in and out of quarantine. 

Exchange 2010 however today does not have a simple way of really testing the quarantine values.  As mentioned, Exchange 2013 has the Enable-MailboxQuarantine and   Disable-MailboxQuarantine cmdlets.  These cmdlets are not available in Exchange 2010.  This means there is no easy way to validate that the change was applied apart from waiting for the next reoccurrence.

How To Remove Mailbox From Quarantine

In Exchange 2013 the Disable-MailboxQuarantine cmdlet can be used.

For Exchange 2010, which does not have the Disable-MailboxQuarantine cmdlet we have to take a different approach.  KB 2603736  states that to take a mailbox out of quarantine immediately all that we need to do is to delete the mailbox’s GUID entry from under the QuarrantinedMailboxes  registry key.    Store should process the registry key deletion and since the registry is the authoritative source of quarantine state the mailbox should be released.  If no action is taken, then the mailbox will exit quarantine after the MailboxQuarantineDurationInSeconds  period has expired. 

How To Check If A Mailbox Is Quarantined

There are a few ways to look at the  status of a given mailbox:

• Event log entries
• Get-MailboxStatistics
• Registry
• ExBPA
• PerfMon

When a mailbox is quarantined, EventID 10018 will be logged into the application event log and this can be easily picked up by monitoring tools. 

We can take a peek at the registry to see if there are any mailbox GUIDs listed there under:

HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{db guid}

Then run Get-Mailbox  <GUID> to see which mailbox it is.

Get-MailboxStatistics for a mailbox also has a property to indicate if a mailbox is quarantined.

          Get-MailboxStatistics Administrator | Select DisplayName, IsQuarantined | Format-Table -AutoSize

ExBPA will also check to see if a mailbox is quarantined.

Finally Exchange also exposes a performance monitor counter to indicate the number of quarantined mailboxes.  SCOM will pick this up with the Exchange Management Pack.  You can manually look at the counter - 

MSExchangeIS Mailbox\Quarantined Mailbox Count

Cheers,

Rhoderick