How to confirm if your IP address is blocked by Exchange Online Protection (EOP)

Wednesday, January 11, 2017
Exchange Online Protection uses several mechanisms to protect the service and its customers from receiving spam from known bad or suspicious IP addresses. This article explains how to check if the public IP address used by your messaging server is on the EOP Anti-Spam IP List, and how to remove it if it is.

This is especially important to do for Office 365 hybrid customers, since the on-premises Exchange servers will need to send SMTP emails to cloud users via EOP. I always do this before I begin a hybrid deployment.

From a web browser go to the Office 365 Anti-Spam IP Delist Portal (https://sender.office.com).

Step 1: Enter a valid email address to receive a verification email to complete the check, and enter the public IP address of the messaging server you want to check. You can use a service like WhatIsMyIPAddress.com from the messaging server to determine your public IP. Enter the captcha characters and then click Submit.

Office 365 AntiSpam IP Delist Portal

You will receive an email with the subject Microsoft Office 365 Delisting Service where you need to click a link to confirm your email address. This link is valid for about 10 minutes. If you wait longer than that, you'll need to start over. The email is sent almost immediately, so if you don't see it in your Inbox within a minute, check your junk mail.

Click to confirm your email address


Step 2: A new browser window will open to allow you to delist the IP address you entered in step 1. Click the Delist IP Address button.

Step 2: Delist IP Address



If the IP address is not on the blocked list, you'll see a message similar to the one below:

Step 3: The IP address is not currently blocked by EOP

If the IP address is blocked it will be submitted to be automatically delisted. The website says this takes about 30 minutes, but in practice I've seen it take up to 24 hours. You will not get a confirmation email when the IP address has been delisted. You'll need to re-run the test occasionally until you see that it's not blocked.

Step 3: The IP address is blocked, but will be delisted


The quick geek way to test if your IP address is blocked is to use the telnet client. From the messaging server, telnet to the EOP endpoint using port 25 and try to send an SMTP email. You can find your EOP endpoint using www.mxtoolbox.com. If your IP address is on the EOP block list you will see it after the RCPT TO command .  Here's an example of the telnet output:

Access denied
Here, you can see that the IP address is banned by EOP and instructions for removal.

550 5.7.606 Access denied, banned sending IP [x.x.x.x]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609)


Read more ...

Explaining Conditional Access and Azure Pass Through Authentication

Tuesday, January 3, 2017
My previous article, Is Azure AD Pass-Through Authentication Right for You? generated some comments and questions about how PTA works with conditional access in Azure AD. There was enough confusion that I wrote a companion article, Explaining Conditional Access and Azure Pass Through Authentication.

Conditional access works great in a cloud-only world, but the real world usually contains legacy clients. Learn when it's appropriate to use conditional access policies and when to use AD FS claims rules with Azure pass-through authentication.


Additional resources:
Read more ...

Is Azure AD Pass-Through Authentication Right for You?

Friday, December 9, 2016
Microsoft just released the new Azure Pass-Through Authentication and seamless Single Sign On option available in the new Azure AD Connect. This new authentication mechanism has a lot of great features and is well thought out, but it's not for every organization.

Check out my article, Microsoft Releases Azure AD Pass-Through Authentication and Seamless Single Sign-on, on the ENow Exchange & Office 365 Solutions Engine Blog. In it, I explain what PTA is, how it works, and how to configure it. You will learn how to deploy additional AAD pass-through connectors for high availability and configure SSO. I also discuss why AD FS may be a better solution for your business.



Additional resources:
Read more ...

How to Manage Distribution Groups from Office 365 in a Hybrid Environment

Wednesday, November 30, 2016
When on-premises distribution groups are synced to an Office 365 tenant via Azure Active Directory Connect, migrated users who are owners of the distribution group can't manage them in Outlook. Depending on the version of Outlook used, the user will receive an error message that resembles the following:
The action 'Update-DistributionGroupMember', 'Identity.Members', can't be performed on the object '<name>' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

-or-
Changes to the public group membership cannot be saved. You do not have sufficient permission to perform this operation on this object.


This happens because Outlook tries to update the same directory where the user's mailbox exists. If the mailbox is in Exchange Online this is the Exchange Online Directory Service (EXODS) directory, which syncs with Azure AD. Since EXODS is read-only in a hybrid environment using AAD Connect, the user receives the error.

The trick workaround is to use the dsquery management interface (formerly known as the Windows Address Book way back in the Windows 95 days) to manage the on-premises group. Users can create a desktop shortcut to the dsquery user interface and use it to update the on-prem distribution groups. Optionally, you can create a GPO that pushes this desktop shortcut out to all domain-joined computers' desktops.

To create the desktop shortcut to the dsquery user interface, follow these steps:

  • Right-click an area on the desktop, point to New, and then click Shortcut.
  • Type the following in the box, and then click Next:
%SYSTEMROOT%\System32\rundll32.exe dsquery,OpenQueryWindow
  • Type a name for the shortcut, such as "Manage Distribution Groups", and then click Finish.
The shortcut allows users to search for the group, and then add and remove users or change the group's description for groups they manage.

Managing a Distribution Group using the dsquery UI

It's important to note that the user's computer must be domain-joined and connected to the network for this to work because the changes are written to an on-prem domain controller. After group changes are made, they will appear in Office 365 after directory synchronization runs. Or, you can force directory synchronization to see the changes immediately.

Read more ...

Fix for Performance Counter Updating Error (Event 106) on Exchange Servers

Tuesday, November 29, 2016
You may see multiple warnings or errors in the Application event log on Exchange servers for event 106, indicating that performance counters could not be updated.

Multiple Event ID 106 - Perf Counter Events
An example event 106 reads,
Log Name:      Application
Source:        MSExchange Common
Date:          11/29/2016 12:24:28 PM
Event ID:      106
Task Category: General
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      EX16B.contoso.com
Description:
Performance counter updating error. Counter name is Percentage of Failed Offline GLS Requests in Last Minute, category name is MSExchange Global Locator OfflineGLS Processes. Optional code: 3. Exception: System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.
   at System.Diagnostics.PerformanceCounter.InitializeImpl()
   at System.Diagnostics.PerformanceCounter.get_RawValue()
   at Microsoft.Exchange.Diagnostics.ExPerformanceCounter.set_RawValue(Int64 value)
The TechNet article, "'Performance counter updating error' after you install an Exchange Server 2013 cumulative update", indicates this is a problem on Exchange 2013 after applying a CU, but I've seen this happen after applying an update rollup, cumulative update, or .NET Framework update on Exchange 2010, Exchange 2013, or Exchange 2016 servers.

I wrote the following PowerShell script to reload the Exchange performance counters. You run it directly on the affected Exchange server from an elevated PowerShell or EMS prompt. The script will reload all the performance counters in the %ExchangeInstallPath%\setup\perf directory.
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup
$perfcounters = Get-ChildItem "$env:ExchangeInstallPath\Setup\Perf\" *.xml | Where-Object {!($_.psiscontainer)}
$perfcount = $perfcounters.Count

foreach ($perfcounter in $perfcounters) {
New-PerfCounters -DefinitionFileName $perfcounter.FullName -ErrorAction SilentlyContinue
Write-Progress -Activity "Reloading $perfcount Exchange Performance Counters" -PercentComplete (($i++ / $perfcount) * 100)}
The script may take a few minutes to run and will reload all the Exchange performance counters. Once complete, the event 106 warnings or errors should stop.


Read more ...

Azure AD Connect Adds Support for Windows Server 2016 and SQL 2016

Friday, November 18, 2016
If you're a customer who uses Azure Active Directory Connect, you'll want to know that Microsoft just released version 1.1.343.0, which adds support for Windows Server 2016 and SQL Server 2016 and fixes some bugs.

Improvements:
  • Added support for installing Azure AD Connect on Windows Server 2016 standard or better.
  • Added support for using SQL Server 2016 as the remote database for Azure AD Connect.
  • Added support for managing AD FS 2016 using Azure AD Connect.
Fixed issues:
  • Sometimes, installing Azure AD Connect fails because it is unable to create a local service account whose password meets the level of complexity specified by the organization's password policy.
  • Fixed an issue where join rules are not re-evaluated when an object in the connector space simultaneously becomes out-of-scope for one join rule and become in-scope for another. This can happen if you have two or more join rules whose join conditions are mutually exclusive.
  • Fixed an issue where inbound synchronization rules (from Azure AD) which do not contain join rules are not processed if they have lower precedence values than those containing join rules.

You can download the latest version HERE.

Read more ...

How to Perform HTTP -> HTTPS Redirection in a Single Exchange Server Environment

Tuesday, August 30, 2016
HTTP to HTTPS redirection in Outlook Web App is a user convenience that many admins consider a necessity. It automatically redirects the user's browser to https://mail.contoso.com/owa if they enter http://mail.contoso.com, or simply mail.contoso.com. Without redirection, the user will get an HTTP 403 Forbidden error page, like the one below.


This happens because the SSL settings on the Default Web Site and all subdirectories are configured to require SSL.

In multi-server environments where load balancers are used, HTTP -> HTTPS redirection is normally performed on the load balancer. Most load balancers, such as KEMP or F5, automatically configure it when you deploy one of their Exchange server templates.


In single Exchange environments without a load balancer, you must configure redirection directly on the server itself. The steps below explain how to do this. I've used this method since Exchange 2007 and it works perfectly 100% of the time. Other methods I've seen on the Internet sometimes cause routing errors.

  • Open Internet Information Services (IIS) Manager on the Exchange 2016 or Exchange client access server and navigate to Sites > Default Web Site.
  • Double-click Error Pages and add a new custom error page for status code 403.4 that responds with a 302 redirect to https://mail.contoso.com/owa.



  • Special note for Exchange 2016 - The Exchange team did a little number in the web.config file on Exchange servers to "improve performance", but it removes the custom error page behavior. So you'll need to do the following:
    • Open the C:\inetpub\wwwroot\web.config file in Notepad.
    • Remove the following line, and then save and close Notepad:
<remove name="CustomErrorModule" />


Note that this web.config edit will need to be made after every Exchange 2016 CU installation since setup overwrites this file.

That will handle the HTTP 403.4 - Forbidden: SSL is required error behavior in the browser. All that's left is to handle what happens when a user enters https://mail.contoso.com.

  • Using Notepad, create a web page called default.htm in the C:\inetpub\wwwroot folder of the Exchange 2016 or client access server. Add the following three lines:

<html>
<meta http-equiv="REFRESH" content="0;url=/owa">
</html>
  • Save and close Notepad, and then test redirection.

Read more ...