If you are still using Microsoft Forefront Protection 2010 for Exchange Server (FPE), you are officially out of time. I’m seeing a number of Technet Forum threads about things no longer working as expected or signatures that do not update. Time to move to another on-prem product or a cloud solution like Exchange Online Protection (EOP). ( And let’s not even talk about the support for Exchange 2010)
All is not quiet on the Exchange 2013 front if you are running Public Folders. Once you migrate from legacy PFs, ( I assume you aren’t crazy enough to start using Public Folders in a greenfield 2013 org), you may start seeing over Managed Availability Alerts such as:
Log Name: Microsoft-Exchange-ManagedAvailability/Monitoring
Date: 1/26/2016 8:30:31 AM
Event ID: 4
Task Category: Monitoring
The public folder mailbox PFMBX01 is approaching its storage limit. Consider splitting the mailbox using Split-PublicFolderMailbox.ps1. This warning will not be sent again for at least twenty four hours.
At this point, you may be tempted to move folders from this mailbox to another.
However, before you do that, check the actual quota usage either in EAC:
Get-MailboxStatistics <PFMBX> |FL totalitemSize
TotalItemSize : 14.2 GB (15,248,828,208 bytes)
So what’s going here? Why are alerts firing when the mailbox quota warning has not been reached? Quite simply, it’s a bug.
The MA service doesn’t or can’t differentiate between individual folders that are nearing their quota and the actual Public Folder Mailbox. For the admin, this can create a lot of confusion. If an individual folder is nearing quota, the folder contacts will get alerted and that is typically sufficient. If the mailbox itself is nearing it’s quota warning level, the admin will obviously want to take action soon.
Hopefully this will be fixed in Exchange 2013 with a future CU.
For 2016, I will update this blog when I have time to test.
If you are concerned about missing actual PF mailbox over quota events, I suggest creating a scheduled PowerShell task that checks the mailbox sizes and fires off an email alert if the quota is approached.
One of the great powers of being the messaging guy or girl is the ability to create transport rules in response to business requirements. Seemingly subtle differences in the rule’s logic, however, can make a huge difference.
For example: You craft a rule to block spoofed messages from the internet that appear to come from your SMTP domain. Like all good internet citizens, you have enabled DMARC, so you construct a rule like this:
So, what happens to the message when the rule is applied? Since you are setting the SCL to 9, it will end up in the quarantine by default . Or will it?
Consider this: Since you are marking the message as SPAM, you are also giving the end-user the ability to bypass that rule by whitelisting the sender.
Because EOP honors both the RFC 5321 MAIL FROM: and the RFC5322 FROM:, if the MAIL FROM: just happens to be on an user’s safelist – added through Outlook or OWA – the message will be allowed, even if the FROM: is a spoofed domain.
If you don’t like the prospect of messages potentially slipping through without hitting the quarantine first, force it instead:
Well, maybe. Since you are pushing the message to the quarantine by rule, the end-users will not see the messages in their personal quarantines and will not be able to release the message without administrator intervention as documented here:
But maybe that is what you want.
Regardless, you can craft the rule to meet your needs. And options are always good.
Looks like another mailbox anchoring issue!
Note This issue will be fixed in Cumulative Update 12 for Exchange Server 2013.
I have been preaching this on the forums for many years, but it’s worth a reminder. There is generally no reason to muck with the default receive connectors.
And yes, I am aware of the advice from the 2010 days:
Note that in 2013/16, anonymous is already enabled on the “Default Frontend” connector to boot!
Messing with them is a sure way to stop mail flow between servers and who knows what else.
If you need to customize or have the very common requirement to enable support for inbound TLS with a common FQDN across servers, create a new receive connector on each server. You’ll be glad you did.
I used to think so. It seemed pretty cut and dry to me at least. After all, the official public documentation from Microsoft is very clear:
Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell snap-in and running cmdlets other than the *-TransportAgent cmdlets is not supported and may result in irreparable damage to your Exchange deployment.
This is reiterated by my friend Rhoderick:
But Rhoderick does say something I never really paid attention to before now:
Unless you are following a specific process that is documented by Microsoft or are working with a Microsoft support representative, the only way you should be connecting to Exchange is the method documented above
So there it is. Another exception to the rule that you may want to be aware of if you are running Exchange 2013 CU11. In the event of a “critical failure”, Microsoft advises you use the PSSnapin.
If you open EMS and are not able to connect to any Exchange Servers due to loss of communication, then you will need to add the PSSnapin for Exchange to your local PowerShell Session.
Hopefully you will never be in a failure scenario that necessitates using the PSSnapin, but if you are, it’s an available option.
For more on the mailbox anchoring issue, hop over to Andrew’s blog:
For those poor souls still using Public Folders, there are some benefits to upgrading to 2013/2016 Modern PFs. The over quota messages now contain the full path to the folder – not just the folder name – so that folder contacts can easily find the actual folder that is nearing its limit. Whew!
Your public folder “MyFolder” is almost full.
Your public folder “\Org\Dept\Group\Email\MyFolder” is almost full.
Continuing the 2013/2016 Public Folder theme… If you see this error in power shell:
Public folder ‘\MyPublicFolder isn’t mail-enabled.
+ CategoryInfo : NotSpecified: (:) [Get-MailPublicFolder], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=Exchange01,RequestId=73da9220-fa76-4b50-923d-f1d45b2e4470,TimeStamp=1/11/2016 11
:50:40 AM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 9A83BDC,Microsoft.Exchange.Management.MapiTa
+ PSComputerName : yourserver.contoso.com
yet it shows it mail-enabled in EAC, consider that if you are in a multi-domain, it may not show as mail-enabled unless you set the scope to the entire forest (Set-ADServerSettings -ViewEntireForest $true)
Oh, and while I am thinking of it, in a multi-domain forest, the AD objects for legacy mail-enabled PFs were created in the MESO folder of the same domain as the folder creator. In 2013/16 PFs, the AD objects are created in the root domain MESO folder from what I have seen… Just something to keep in mind if you try to find them!
Try this instead:
Set-MailPublicFolder “mail enable public folder” -ForwardingAddress “address” -DeliverToMailboxAndForward:$True
I have seen this as well. Hopefully this will get fixed soon. Stay tuned. In the mean time, hopefully the work-around will work for you.
My friend Andrew (what a cool name), has written an article about the latest change in Exchange 2013, starting with CU11 ( and Exchange 2016 CU1). I have to admit I am not a fan of anchoring for Powershell connections, but will withhold final judgment until after I get a chance to play around more with CU11. See: