What is a Scoped Send Connector?

After so many years of being available, the Scoped property of Send Connectors is still confuses some Exchange administrators, or simply goes by unnoticed.

So what exactly is a Scoped Send Connector? Simply put, when we configure a send connector as scoped, we are stating that only Exchange 2007/2010 Hub Transport or Exchange 2013/2016 Mailbox servers in the same Active Directory (AD) site as the send connector can use it. If this option is not selected, then the connector can be used by any Exchange server in any AD site in the same Exchange organization.

But what is the point of this option if we need to specify the Source Servers for the send connector? Doesn’t this option stipulate which Exchange servers can use the connector?! Well, not exactly...

The source servers for a send connector determine the destination Exchange server for mail that needs to be routed through the send connector. The send connector scope controls the visibility of the connector within the Exchange organization.

Once again, send connectors are by default visible to all the Exchange servers in the entire AD forest, and are used in routing decisions. However, we can limit a send connector’s scope so that it is only visible to other Exchange servers in the same AD site. The send connector is invisible to Exchange servers in other AD sites, and is not used in their routing decisions. A send connector that is restricted in this way is said to be scoped.

To configure scoped send connectors in the EAC (assuming Exchange 2013/2016), we select Scoped send connector in the Address space section of the new send connector wizard, or on the Scoping tab in the properties of existing send connectors (as previously shown).

When using the Exchange Management Shell, we use the IsScopedConnector parameter on the New-SendConnector and Set-SendConnector cmdlets.

Exchange PowerShell Variables

Since the release of Exchange Server 2007 (the first version to include PowerShell) that the Exchange Management Shell (EMS) includes the following three pre-defined variables:

• $exbin - contains the full path to Exchange's Bin directory;
• $exinstall - contains the full path to Exchange's install folder;
• $exscripts - contains the full path to the Exchange's script folder.

In a default installation of Exchange 2016, this is what these variables contain:

These variables are used in different scenarios such as some scripts provided by Microsoft, and can also be used by administrators to facilitate the management of Exchange. But where are these variables defined? Can we add a couple more?

When we load the EMS, the Exchange.ps1 script located in the Bin directory is run. Within this script we can find these variables defined:

$global:exbin = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup).MsiInstallPath + "bin\"
$global:exinstall = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup).MsiInstallPath
$global:exscripts = (get-itemproperty HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup).MsiInstallPath + "scripts\" 

If, for any reason, you would like to add another variable, you can add it here. For example, to add a variable to your Message Tracking Logs directory you could do something like this:

$global:exmsgtl = "E:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking\"

Exchange Meeting Room Statistics

Room mailboxes have been available for a very long time now, and most organizations make extensive use of them for all their meeting room bookings. In certain cases, having statistical information about these rooms helps organizations plan or redesign their offices in a more efficient way. This information can show how often certain rooms are utilized, the average meeting duration, who tends to book more meetings, and so on.

In this article we will develop a script to provide us with some of this information and to serve as a stepping stone to gather further information depending on the reader’s particular needs. The end result will look something like this:

 

In this example, I only searched one meeting room called ITD – 16A – Small CF VC. For the month of December we can see that a total of 115 meetings were booked, out of which 55% are recurring meetings. The average meeting duration was 46 minutes, each meeting had an average of 8 attendees and there were slightly more meetings booked in the morning.

To download the script and the read the entire article, please go to MSExchange’s Exchange Meeting Room Statistics article page.

Distribution Groups Statistics

As an Exchange Administrator, have you ever wondered if all those Distribution Groups are actually being used? Organizations running Microsoft Exchange Server are likely to have been running Exchange for a at least a few years and also likely to continue to do so for a while. After all those years, more and more distribution groups get created, some of them stop being used, some are simply forgotten, etc.

Maybe you got asked by the Audit department or by your manager for a list of the 20 most utilized groups, or maybe you are just curious. The good news is that as long as you have Message Tracking Logs enabled, you can easily get this information!

The easiest way to track messages sent to distribution groups is to list all the expansion events. When a user sends an email to a group, Exchange needs to expand that group in order to know who to send the email to. This gets registered with an EventID of EXPAND. Additionally, the RelatedRecipientAddress field in the EXPAND entry contains the PrimarySmtpAddress of the expanded group. And this is pretty much all the information we need.

Using the following cmdlet, we can get a list of all the emails sent to distribution groups on the 1st of January 2016:

Get-MessageTrackingLog -Start 01/01/2016 –End 01/02/2016 -EventID Expand | Select Timestamp, RelatedRecipientAddress, MessageSubject

But what we really want is to know how many emails were sent to which groups during a particular time. Not a problem! All we need to do is tweak the cmdlet above and add Group-Object:

Get-MessageTrackingLog -Start 01/01/2016 –End 01/02/2016 -EventID Expand | Group RelatedRecipientAddress | Sort Count –Descending | Select Count, Name

Do not forget to add Get-TransportService (or Get-TransportServer in Exchange 2007 and 2010) to get the logs across all transport servers if you have more than one!

If you are interested in getting the Top 20 most used groups, for example, this is also very easy:

Get-TransportService | Get-MessageTrackingLog -ResultSize Unlimited -Start 01/01/2016 -EventID Expand | Group RelatedRecipientAddress | Sort Count -Descending | Select -First 20 | FT Count, Name -AutoSize

How to Convert a Distribution List into a Mailbox

Sometimes, an organization/administrator might have the need to convert a Distribution Group (DG) (or Distribution List) into a normal mailbox or a shared mailbox. Reasons for this vary, but the most common one is when an organization has the need to start sending emails as that DG.

 

Unfortunately, there is no native way of achieving this. But it is completely achievable and straightforward. The best way is to:

1. Write down the DG’s LegacyExchangeDN. To do so, you can run the cmdlet: Get-DistributionGroup “DG_name” | Select LegacyExchangeDN;
2. Delete the DG;
3. Create a (shared) mailbox with the same SMTP address;
4. Add the DG’s legacyExchangeDN as an X500 address to the new mailbox.

I am not going into detail of what the legacyExchangeDN is and how or why it is used as this is already well documented all over the Internet. As a quick overview, the auto-complete cache in Outlook and in OWA uses the value of the legacyExchangeDN attribute to route email messages internally. If the value changes, the delivery of email messages may fail with a 5.1.1 NDR.

 

If you already deleted the DG and have no way of retrieving its legacyExchangeDN, you have two options:

1. Clear the auto-complete cache (straightforward but most of the times not the best approach);
2. Manually create an X500 proxy address for the old legacyExchangeDN attribute for the DG.

To create an X500 proxy address, you need to use an NDR you have received when emailing the DG, which should contain the recipient’s address such as:

IMCEAEX-_O=LetsExchange_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=f6a32c0ab0e64f33b2a7b3f9a48c2da6@nunomota.pt

From here, make the following changes based on the recipient address in the NDR:

• Replace any underscore character (_) with a slash character (/);
• Replace “+20” with a blank space;
• Replace “+28” with an opening parenthesis character;
• Replace “+29" with a closing parenthesis character;
• Delete the “IMCEAEX-“ string;
• Delete the “@nunomota.pt” string;
• Add “X500:” at the beginning.

After you make these changes, the proxy address will look similar to:

X500:/O=LetsExchange/OU=Exchange Administrative Group (FYDIBOHF23SPDLT)/CN=Recipients/CN=f6a32c0ab0e64f33b2a7b3f9a48c2da6

Exchange Mailbox ForwardingSMTPAddress setting not working

For a variety of different reasons, sometimes there is the necessity of users or administrators to automatically forward e-mails addressed to one mailbox to another mailbox. To achieve this there are several options such as Outlook Inbox Rules or Transport Rules. Another option is to configure the mailbox itself using the ForwardingAddress setting which can be configured using the Exchange Management Console/Exchange Admin Center.

However, in some cases the end recipient is a SMTP address external to the local Exchange environment. As ForwardingAddress only works with local recipients, we can create a contact for the target mailbox and then use ForwardingAddress with the contact.

But creating a contact might not be desirable, so a more “direct” way is to use the ForwardingSmtpAddress setting instead (which can only be configured through the Shell). As such, what most administrators do is something like this:

Set-Mailbox nuno -ForwardingSMTPAddress mota@somedomain.com -DeliverToMailboxAndForward $True

After doing this, the administrator notices that e-mails are still not being automatically forwarded... Let us see why.

Within Exchange and Office 365, administrators can create remote domains. By default, every Office 365 tenant leverages the “*” domain. When a specific remote domain does not exist, the “*” remote domain setting are applied to the message. However, this is not true for on-premises Exchange environments where, by default, there are no remote domains.

A property of a remote domain is the AutoForwardEnabled property, which allows administrators to define if auto-forwarding is allowed on e-mails destined to the domain specified. By default auto-forwarding in Office 365 is allowed to all domains, but not in on-premises environments.

This means that administrators need to create a remote domain for the forwarding addresse's domain (or a generic one), in my example, somedomain.com, and ensure AutoForwardEnabled is set to $True (which it is by default when creating a new remote domain):

New-RemoteDomain -Name ExternalDomain -DomainName somedomain.com
Get-RemoteDomain ExternalDomain | Select DomainName, AutoDorwardEnabled

Note that using ForwardingAddress is a way for an administrator to bypass forwarding settings on remote domains, meaning it is not necessary to create a remote domain for the forwarding to work.

Bottom line: if you want to use the ForwardingSmtpAddress setting, make sure you have a remote domain for that SMTP addresse's domain with AutoForwardEnabled set to $True.

AssociatedItemCount versus ItemCount in Exchange

When running the Get-MailboxStatistics cmdlet, two of the attributes returned are AssociatedItemCount and ItemCount. But what exactly are the differences between the two?!

 

As one would expect, ItemCount is the total number of e-mails, contacts, etc. items available and visible to the end-user on the mailbox. Basically, everything the users sees.

 

On the other hand, AssociatedItemCount are special messages in the Associated Table of a folder. They are most often rules and other special messages like the MRM FAI message. Basically, things that are “associated” with a folder, usually other file-like objects not visible to users such as IPM.Configuration.RssRule, IPM.Configuration.AutoComplete, Outlook Rules Organizer or IPM.Microsoft.MigrationStatus.

 

These are not visible to the user, only through MFCMapi for example (right-click a folder and select Open Associated Contents table).

 

Folder Associated Information (FAI) is a collection of message objects that are stored in a folder object and are typically hidden from view by e-mail applications. An FAI Message object is used to store a variety of settings and auxiliary data, including forms, views, calendar options, favorites and category lists.

Check Account Permissions to Mailboxes

If you want to check what permissions an Active Directory user account has on a specific mailbox, simply use the following cmdlet which will enumerate all the permissions the user has on that mailbox:

Get-Mailbox "mailbox" | Get-MailboxPermission -User "AD_user"

If, alternatively, you want to check which mailboxes that specific user has permissions to, you can update the cmdlet to:

Get-Mailbox -ResultSize Unlimited | Get-MailboxPermission -User "AD_user" | FT Identity, AccessRights, Deny

However, please be careful as this cmdlet will enumerate all mailboxes in the organization. If there are dozens of thousands, you might want to target only specific mailboxes.

Free/Busy Information Period (Exchange 2013-2007 Error)

Free/busy information requests to an Exchange 2007 organization from an Exchange 2013 organization may fail due to a mismatch in the requested free/busy information period. By default, Exchange 2007 accepts availability requests for 42 days of free/busy information and Exchange 2013 may request 62 days of free/busy information. If the request exceeds the default 42 limit imposed by Exchange 2007, the request will fail.

 

In order to prevent this failure, follow the steps below to configure your Exchange 2007 CAS servers to accept longer period free/busy information requests:

1. On all your Exchange 2007 CAS servers, open the following file with a text editor such as Notepad (remember to create a backup copy first!):
<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config

2. Locate the appSettings section;

3. Add a new key “<add key="maximumQueryIntervalDays" value="62" />” and save the web.config file. The maximumQueryIntervalDays value is not present by default. When this value is not present, Exchange 2007 uses the default interval of 42 days.

4. Restart IIS on all the Exchange 2007 CAS servers.

Exchange Server Vulnerability Could Allow Remote Code Execution

Unfortunately, there seems to be another vulnerability in Exchange Server WebReady Document Viewing feature, this time with the third-party code Oracle Outside In libraries.

This security update resolves publicly disclosed vulnerabilities and one privately reported vulnerability in Microsoft Exchange Server.

The most severe vulnerabilities are in Microsoft Exchange Server WebReady Document Viewing and could allow remote code execution in the security context of the transcoding service on the Exchange server if a user previews a specially crafted file using Outlook Web App.

The transcoding service in Exchange that is used for WebReady Document Viewing is running in the LocalService account. The LocalService account has minimum privileges on the local computer and presents anonymous credentials on the network.

This security update is rated Critical for all supported editions of Exchange Server 2007 and 2010!

For more information and to download the update, please see Microsoft Security Bulletin MS12-080 - Critical

iOS 6 issues with Exchange - Update

This is an update post of the iOS 6 issues with Exchange post from early October.

Looks like Apple has released an update for iOS 6 (available via iTunes and wirelessly) which supposedly fixes the issues of this OS with Microsoft Exchange meetings!

“This update contains improvements and bug fixes, including:

• Fixes a bug that prevents iPhone 5 from installing software updates wirelessly over the air;

• Fixes a bug where horizontal lines may be displayed across the keyboard;

• Fixes an issue that could cause camera flash to not go off;

• Improves reliability of iPhone 5 and iPod touch (5th generation) when connected to encrypted WPA2 Wi-Fi networks;

• Resolves an issue that prevents iPhone from using the cellular network in some instances;

• Consolidated the Use Cellular Data switch for iTunes Match;

• Fixes a Passcode Lock bug which sometimes allowed access to Passbook pass details from lock screen;

• Fixes a bug affecting Exchange meetings”

You can find details regarding this update here.

iOS 6 Issues with Exchange

There have been some reports that iOS 6 is not working properly for many Exchange users... Apparently there are two issues:

Push E-mail

Push delivery of e-mail does not work, meaning users have to manually check for e-mails. It seems that this issue is not carrier or device specific and rebooting or reconfiguring the Exchange accounts only “fixes” the issue temporarily.

Meetings

This second issue happens when users decline a meeting invitation from an iOS 6 device. Instead of simply sending a notification to the meeting organizer, iOS 6 sends meeting cancellation notices to the entire group of attendees, cancelling the invitation for everyone!

In the environment where I work, we don’t seem to be experiencing any of these issues. Initially I asked colleagues if they were having any problems with push e-mail and they were all working fine (I believe our ServiceDesk has not received any calls regarding this yet – we have 651 devices on iOS 6 so far).

As to the second issue, I tested it three times with different users and with the new iPad, iPhone 4S and iPhone 5 and couldn’t replicate the issue...

However, this seems to be affecting many, many Exchange 2007/2010 organizations out there, so please be aware of this and test it!

UPDATE: The Exchange Team has just published a post on this: iOS6 devices erroneously take ownership of meetings!

UPDATE 2: looks like Apple has released an update for iOS 6 (available via iTunes and wirelessly) which supposedly fixes the issues of this OS with Microsoft Exchange meetings! More information here.

List Litigation Hold Users and Size

A feature introduced in Exchange 2010 RTM and that is being used more and more it Litigation Hold. It is used during a lawsuit, investigation or similar events to preserve mailbox items from inadvertent or purposeful modification or deletion by the user (or someone with access to the mailbox) and from automated deletion by retention policies. Until the hold is removed, deleted items are not purged from the mailbox database and if a mailbox item is modified, a copy of the original item is also retained. These are returned in Discovery searches performed when the mailbox is on Litigation Hold. Any retention policies applicable to the mailbox don't need to be suspended. Because messages continue to be deleted as expected (except from the Recoverable Items\Purges folder!), users may not notice they're on Litigation Hold.

 

To check if there are any users in your organization currently enabled for Litigation Hold, simply run the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True}

If you want to check the Recoverable Items folder size for all mailboxes on Litigation Hold, i.e. how many data is being held by Litigation Hold, use the following cmdlet:

Get-Mailbox -ResultSize Unlimited -Filter {LitigationHoldEnabled -eq $True} | Get-MailboxFolderStatistics –FolderScope RecoverableItems | FT Identity, FolderAndSubfolderSize

 

Or if you simply want to check a single mailbox:

Get-MailboxFolderStatistics <user> -FolderScope RecoverableItems | Select Identity, FolderAndSubfolderSize

Hope this helps!

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

 

Users do not receive quota warning messages

We all know that, for better or for worse, the way Exchange calculates and sends Quota Messages changed with Exchange 2010 SP1. We also know that this has caused nothing but confusion for many Administrators out there...

In this post I will try to give an overview of the new behaviour for normal mailboxes and, more important, explain when users will actually receive these messages.

Pre Exchange 2010 SP1

In Exchange environments previous to Exchange 2010 SP1, Exchange sends a quota message to mailbox owners when a:

1. Mailbox exceeds its IssueWarningQuota limit (the lowest storage quota);

2. Mailbox exceeds its ProhibitSendQuota limit (the middle storage quota);

3. Mailbox exceeds its ProhibitSendReceiveQuota limit (the highest storage quota).

Remember that:

• quota messages are sent to mailbox owners, so if a mailbox is owned by a security group (shared mailbox), quota messages are sent to the security group;

• quota messages are sent with high importance and are not subject to storage quotas, which means they are always delivered even if the recipient's mailbox is full;

• quotas can be configured at a mailbox or database level.

These quota messages are sent during the QuotaNotificationSchedule specified for each mailbox database, which would normally be something like every day from 4AM to 6AM:

Get-MailboxDatabase | Set-MailboxDatabase -QuotaNotificationSchedule “Mon.04:00-Mon.06:00, Tue.04:00-Tue.06:00, Wed.04:00-Wed.06:00, Thu.04:00-Thu.06:00, Fri.04:00-Fri.06:00, Sat.04:00-Sat.06:00, Sun.04:00-Sun.06:00”

During this period, Exchange goes through every mailbox in the database(s) and if any has exceeded the quota threshold, it sends the owner an e-mail. No matter if the schedule was 1h, 2h or 10h, as long as Exchange has enough time to go through every mailbox, everyone over quota receives one warning message.

Exchange 2010 SP1 Onwards

Now comes SP1 and all hell breaks loose... We still have:

• the same 3 levels of quotas;

• quotas configurable at the user or database level;

• quota messages sent during the QuotaNotificationSchedule.

BUT.... The way these messages are generated has changed... Now, every mailbox has a flag that controls whether it is checked to see if it has exceed a quota threshold. This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit! Unfortunately, this flag is a system property (part of the code) and therefore not visible using MFCMapi...

Let’s take an example and imagine a mailbox currently 450MB in size. This mailbox (or its database) has IssueWarningQuota set to 400MB and ProhibitSendQuota set to 1GB. We can see the mailbox is over its warning limit but because 450MB is not over 50% of the ProhibitSendQuota (500MB), it will not be checked and will not receive a quota warning message!

On top of this, once a mailbox has been checked during the QuotaNotificationSchedule, the flag is cleared and the mailbox will not be checked again until the flag is reset. Now, here’s the problem I found: according to Microsoft documentation, this flag is reset when “either a message is saved in the mailbox or a message is submitted”. When this happens, if the mailbox size is more than 50% of the ProhibitSendQuota, the flag is reset and the mailbox will be checked during the next QuotaNotificationSchedule.

But what exactly is a saved message?! I assumed that if a user drafted a message and saved it without sending it, the flag would be reset. However, from my tests this is not the case... So far, only sending e-mails from a mailbox seems to reset this flag. This means that if you have a mailbox that only receives e-mails, it will never receive the warning message. Again, this is what I am seeing in the environment I work at and from my tests!

You might be asking why I previously emphasised the “1” in “everyone over quota receives one warning message”. By default, with SP1 the QuotaNotificationSchedule is set to run for 15 minutes every day at 1AM. If you increase this to 2h, for example, your users might receive more than one message at a time! I had cases where I had this set to run over 3h for testing purposes, and some users received 3 quota messages...

Troubleshooting

If you would like to see if/which mailboxes are over quota or received a quota message, you have a few methods:

Increase the diagnostic logging on the mailbox server you want to check:

1. Open the Exchange Management Console;

2. Choose Server Configuration;

3. Select the the server name under Server Configuration for which you want to increase logging ;

4. Choose Manage Diagnostic Logging Properties... under the Actions pane;

5. Expand MSExchangeIS;

6. Expand 900 Private;

7. Choose Storage Limits;

8. Select the Expert radio button and click Configure;

9. You don’t need to restart the MSExchangeIS service or dismount and remount the database stores;

10. The next time the QuotaNotificationSchedule runs, look for the EventID 1077 in the Application log.

Use PowerShell to check mailbox statistics:

Get-MailboxStatistics -Database MDB01 | ? {$_.StorageLimitStatus -eq "IssueWarning" -OR $_.StorageLimitStatus -eq "ProhibitSend" -OR $_.StorageLimitStatus -eq "ProhibitSendReceive"} | Select DisplayName, Alias, StorageLimitStatus

Use PowerShell to see which users received a quota message:

Get-TransportServer | Get-MessageTrackingLog -ResultSize Unlimited -Start "08/08/2012" -MessageSubject "your mailbox is" –EventID DELIVER | Select TimeStamp, Recipients, MessageSubject

Exchange 2013

I have been doing some tests with Exchange 2013 to check if the behaviour is the same, but for some reason Exchange doesn’t seem to check my mailbox for quotas...

From the screenshot below, you will see that:

1. Database DB1 has ProhibitSendQuota set to 400MB and IssueWarningQuota to 200MB;

2. My mailbox is using the database’s quota defaults;

3. My mailbox is over the IssueWarningQuota limit with a size of 246MB

4. Exchange has not set the StorageLimitsStatus for my mailbox which should say IssueWarning (if it’s the same as 2007 and 2010).

It was only when I set quota limits at the mailbox level that I started to get warning messages, so I am still trying to understand exactly what is going on with Exchange 2013...

Conclusion

To reiterate, from Exchange 2010 SP1 onwards:

• Every mailbox has a flag to control if the mailbox’s quota is checked;

• This flag is only set if the mailbox size is more than 50% of the ProhibitSendQuota limit;
• If ProhibitSendQuota limit is not used, users will never receive a quota message; 

• If the flag is set, Exchange will send a quota message during the QuotaNotificationSchedule interval and then clear the flag;

• The flag is reset only when a message is sent from the mailbox;

Hope this helps clarifying the new behaviour regarding quota messages!

Exchange 2007 SP3 Update Rollup 8

"On August 13th 2012, the Exchange CXP team released Update Rollup 8 for Exchange Server 2007 SP3 to the Download Center.

This update contains a number of customer reported and internally found issues. See KB 2734323 - Description of Update Rollup 8 for Exchange Server 2007 Service Pack 3 for more details."

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!

Update IPs on Receive Connectors

If you have multiple HUB servers and ever had to update one or more IP addresses from a custom Receive Connector, you know how much work it is involved. Especially if you have to do this often.

If this is your case, here’s how you can easily remove (or add) IPs from a receive connector across all your HUB servers:

# Get Receive Connectors to update
$recCons = Get-ReceiveConnector | Where {$_.Name -match "Unauthenticated SMTP"}

ForEach ($recCon in $recCons)
{
   Write-Host "Updating", $recCon.Identity

   $recCon.RemoteIPRanges -= "10.101.74.10"
   $recCon.RemoteIPRanges -= "10.102.34.12"

   Set-ReceiveConnector $recCon -RemoteIPRanges $recCon.RemoteIPRanges
}

Hope this helps!

Exchange 2007 Cmdlet List

Have you ever wished for a website that had all the Exchange cmdlets in one page so that you could easily search for a cmdlet or even find new ones? Well, such page exists on TechNet! If you go to the Cmdlet List webpage, you will get all the cmdlets that manage features of Exchange Server 2007 together with the server roles on which they are used!

PDC emulator is not excluded from DSAccess topology

When running the Exchange Best Practices Analyzer Tool [ExBPA] you will probably get the following warning:

This is because it is recommended to exclude the Primary Domain Controller [PDC] from the list of DCs available for use by Exchange.

First, let’s clarify what ADAccess and PDC are:

• The PDC Emulator is an Active Directory [AD] operations master role computer that processes replication requests from Microsoft Windows  NT Server 4.0 backup domain controllers and processes all password updates for clients that are not running AD enabled client software. PDC emulators are also Domain Controllers [DC] and are therefore available for use by applications such as Exchange;
• Directory Service Access [DSAccess] is an internal component of Exchange that controls how all Exchange Server components access AD. The primary function of DSAccess is to maintain information about various directory-related events and operations. For example, DSAccess discovers the AD topology and detects if DCs and global catalog servers are available and responding to queries.

By default, DSAccess includes the PDC emulator computer in its list of available and usable DCs. If non-Exchange Server programs are making heavy use of the PDC emulator, Exchange can worsen this situation or even suffer from it.

To prevent such performance issues, the MinUserDC registry value can be added to the registry on an Exchange server to force DSAccess to query all other available DCs before querying the domain controller that holds the PDC emulator operations master role.

To create/update MinUserDC registry value:

1. Open the Registry

2. On a computer that is running Exchange Server 2010, locate the following subkey:

   HKLM\System\CurrentControlSet\Services\MSExchange ADAccess\Profiles\Default\MinUserDC

   On a computer that is running Exchange Server 2007, locate the following subkey:

   HKLM\System\CurrentControlSet\Services\MSExchangeDSAccess\Profiles\Default

3. Locate the MinUserDC value and make any required changes. If this DWORD value does not exist, you can manually create it.

Note: The value for the MinUserDC registry entry is the maximum number of DCs to contact before contacting the PDC emulator. For example, setting MinUserDC to 4 configures DSAccess to exclude the PDC emulator only when a total of 4 DCs are available. When this condition is met, the PDC emulator is excluded from use and DSAccess communicates only with the remaining 3 DCs.

Another way to configure the DSAccess component to exclude a particular DC or a list of DCs from use is by using the Set-ExchangeServer cmdlet together with the -StaticExcludedDomainControllers parameter:

Set-ExchangeServer "server" -StaticExcludedDomainControllers "pdc.domain.com"
Get-ExchangeServer "server" -Status | Select Name, StaticExcludedDomainControllers

However, please note that the MinUserDC key will still allow Exchange to use the PDC Emulator if the other DCs/GCs go offline but the static exclude list will not!

Hope this helps!