Anything that works now with Microsoft Forefront Protection is probably just dumb luck

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)

https://blogs.office.com/2015/01/23/still-using-forefront-protection-2010-exchange-server-make-move-soon/

Subscriptions expiring before December 31, 2015 will not be renewed; virus updates and signatures will not be made available after this date and the service will end.

https://support.microsoft.com/en-us/kb/2793998

On September 12, 2012, Microsoft announced the End-of-Life date for the following Forefront Server and Forefront Protection products as of December 31, 2015:

  • Microsoft Forefront Protection 2010 for Exchange Server (FPE)
  • Microsoft Forefront Protection 2010 for SharePoint (FPSP)
  • Microsoft Forefront Security for Office Communications Server (FSOCS)
  • Microsoft Forefront Threat Management Gateway Web Protection Services (TMG WPS)

This announcement also applies to earlier versions of these products in the Microsoft Antigen 9 and Forefront Server ranges.

Bogus Public Folder Mailbox Quota Alerts in Exchange 2013

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
Source:        Microsoft-Exchange-ManagedAvailability
Date:          1/26/2016 8:30:31 AM
Event ID:      4
Task Category: Monitoring
Level:         Error
Keywords:     
User:          SYSTEM
Computer:      YOURServer.contoso.com
Description:
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:

Capture

 

Or powershell:

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.

 

 

 

Transport Rules versus Safe Sender Lists in Office 365/EOP: ¿Quien es mas Macho?

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:

Capture2

 

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:

Capture5

Problem Solved!

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:

https://blogs.technet.microsoft.com/eopfieldnotes/2014/08/28/behavior-change-when-setting-the-scl-with-a-transport-rule/

But maybe that is what you want.

Regardless, you can craft the rule to meet your needs. And options are always good.

 

 

 

 

 

Exchange 2013 Queue Viewer/Toolbox fails to open after upgrading to CU11

Looks like another mailbox anchoring issue!

https://social.technet.microsoft.com/Forums/en-US/8adbd807-2cfa-4008-9f56-53999abfc3bf/exchange-2013-toolbox-crashes-when-opening?forum=exchangesvrgeneral

Confirmed:

https://support.microsoft.com/en-us/kb/3140833?sd=rss&spid=16662

Note This issue will be fixed in Cumulative Update 12 for Exchange Server 2013.

 

http://blogs.technet.com/b/exchange/archive/2016/03/01/remote-powershell-proxying-behavior-in-exchange-2013-cu12-and-exchange-2016.aspx

 

Reminder: Leave those Default Receive Connectors Alone!

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:

https://technet.microsoft.com/en-us/library/bb738138(v=exchg.141).aspx

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.

 

Is it really unsupported to use the Exchange PSSnapin?

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:

Loading the 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:

http://blogs.technet.com/b/rmilne/archive/2015/01/28/directly-loading-exchange-2010-or-2013-snapin-is-not-supported.aspx

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:

https://exchangemaster.wordpress.com/2016/01/06/mailbox-anchoring-affecting-new-deployments-upgrades/

 

Improved Exchange Public Folder Over Quota Messages

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!

Before 2013:

Your public folder “MyFolder” is almost full.

Yuck.

After 2013:

Your public folder “\Org\Dept\Group\Email\MyFolder” is almost full.

Yea!

“Public folder ‘\MyPublicFolder’ isn’t mail-enabled”

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
  sks.GetMailPublicFolder
    + 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!

 

Forwarding option to “Leave message intact” not working in Exchange 2013 Public Folders

https://social.technet.microsoft.com/Forums/office/en-US/cdbbe283-744a-4148-9c47-684733cfec06/public-folder-forward-option-leave-message-intact-not-working?forum=exchangesvrsecuremessaging

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.

Anchors Aweigh!

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:

https://exchangemaster.wordpress.com/2016/01/06/mailbox-anchoring-affecting-new-deployments-upgrades/