Exchange 2013 Edge IP Block List BypassedRecipients

On Edge Transport servers, IP Block list providers are used by the Connection Filtering agent, which acts on the IP address of the incoming SMTP connection to determine what action, if any, to take on an incoming message.

The Get-IPBlockListProvidersConfig cmdlet is used to view the settings that affect all IP Block list providers that are configured on an Edge Transport server. When running this cmdlet, there is a property called BypassedRecipients:

The BypassedRecipients parameter specifies the e-mail addresses of internal recipients that are exempted from filtering by IP Block list providers.

If we want to configure connection filtering to bypass filtering for e-mails sent to nuno@letsexchange.com, we run the following cmdlet:

Set-IPBlockListProvidersConfig -BypassedRecipients nuno@letsexchange.com

We can easily add multiple values and overwrite any existing entries by using the following syntax: "email1","email2",...

To add or remove one or more values without affecting any existing entries, we can use the following syntax:

Set-IPBlockListProvidersConfig -BypassedRecipients @{Add=”email1”,”email2”; Remove=”email3”}

Exchange 2013 Servicing Model - Support for CU’s & SP’s

In the Servicing Exchange 2013 article there is the following Q&A regarding the support for Cumulative Updates (CUs):

 

Q: How long is a CU supported?

A: A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1.

As we know, a Service Pack (SP) is typically supported for 12 months after the next SP is released. However, since SP1 is CU4, what does this mean in terms of support for SP1? Will SP1 no longer be supported once CU6 gets released? No, not at all!

Lifecycle Support is the reason why CU4 is officially branded SP1 and not a CU, although technically it is. If we check the lifecycle for Exchange 2013, SP1 is explicitly mentioned and it is stated that its “support ends 12 months after the next service pack released”:

 

Which confirms the assumption: servicing model for CU’s, LifeCycle model for SP’s.

 

This also addresses the needs of Microsoft partners who want to certify their products against a release running at a slower cadence. SP1 will be supported according to the LifeCycle policy already mentioned (until 12 months after the release of a subsequent SP) but will only receive security updates. Customers who raise escalations requesting fixes or who want the benefits of the latest set of fixes will have to move to the appropriate CU to receive non security related fixes.

Managed Availability Failed by Design Error

If you navigate to the Exchange’s ProbeResult Crimson Channel under ActiveMonitoring, you will likely find the following error event logged:

EventID: 2
Channel: Microsoft-Exchange-ActiveMonitoring/ProbeResult
ResultId: 479968430
ServiceName: Monitoring
ResultName: HealthManagerHeartbeatProbe
Error:  Failed by design.
Exception: System.Exception: Failed by design. at Microsoft.Office.Datacenter.ActiveMonitoring.TestActiveMonitoringProbe.DoWork(CancellationToken cancellationToken) at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem.Execute(CancellationToken joinedToken) at Microsoft.Office.Datacenter.WorkerTaskFramework.WorkItem. c__DisplayClass2.startexecuting b__0() at System.Threading.Tasks.Task.Execute()

So why is something failing by design?! Basically this probe is testing the Managed Availability framework, including that it can run responders. More specifically, a probe that will test that monitors can become unhealthy and execute null responders.

Bottom line, nothing to worry about :)

Clean-MailboxDatabase in Exchange 2013

In Exchange 2007 and 2010 we had the Clean-MailboxDatabase cmdlet to get disconnected mailboxes visible in the GUI without having to wait for the maintenance schedule.

However, in Exchange 2013 this cmdlet no longer exists but the same problem persists: disconnected mailboxes are not visible immediately after being removed or disabled.... Clean-MailboxDatabase has been replaced by Update-StoreMailboxState, which forces the mailbox store state in the Exchange store to be synchronized with Active Directory.

Its syntax is as follows:

Update-StoreMailboxState -Database “DatabaseIdParameter” -Identity “StoreMailboxIdParameter” [-Confirm [SwitchParameter]] [-WhatIf [SwitchParameter]]

Both the –Database and –Identity parameters are required, meaning we need to know the identity of the mailbox (mailbox GUID) that we want to update the store state for. To do so, we can run the following cmdlet for example:

Get-MailboxDatabase | Get-MailboxStatistics | Format-List DisplayName, MailboxGuid, Database, DisconnectReason, DisconnectDate

Once we know the mailbox’s GUID and in which database it was located, we can update its mailbox state by running:

Update-StoreMailboxState -Database “db_name” -Identity “mailbox_guid”

If we want to update the mailbox state for all mailboxes on a particular database, we can adapt the cmdlet to:

Get-MailboxStatistics -Database “db_name” | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

Finally, if we want to just update the mailbox state for all disconnected mailboxes on a particular database:

Get-MailboxStatistics -Database “db_name” | Where {$_.DisconnectReason -ne $null } | ForEach {Update-StoreMailboxState -Database $_.Database -Identity $_.MailboxGuid -Confirm:$False}

To be honest, I am not sure why this change from Clean-MailboxDatabase to Update-StoreMailboxState. The only reason I can think of is to give administrators the possibility to just update the state of a single mailbox instead of having to update an entire database.