Discontinuation of Session Border Controllers in O365 and Why You Should Care

Tuesday, July 18, 2017

Microsoft announced today the Discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging. This article is meant to explain what this means and why it's such a big deal.

Session Border Controllers (SBCs) are used to route SIP-SIP traffic. They act as two-legged single-purpose firewalls, used only for SIP traffic. SBCs are usually deployed in the DMZ, where one interface faces the internal network (gateway/PBX) and the other faces the Internet (Office 365). They are required for all PBXs except Lync Server and Skype for Business to connect to Office 365 for voicemail or cloud PBX. Two SBCs are required for this communication, one on-prem and another Microsoft-owned SBC in Office 365. ß This is what is being retired.

VOIP gateways are needed when a legacy TDM-based PBX does not speak SIP. They translate TDM (PRI) to SIP. A SIP trunk connects the VOIP gateway to the SBC in DMZ.

Customers have one or more of the following types of telephone systems that link to Office 365 for voicemail:

3rd party TDM-based PBX (analog)
Examples include Avaya, AT&T Merlin, Nortel. Requires a voice gateway and SBS to connect to either Exchange UM or EXO UM.


3rd party IP-based PBX (digital)
Examples include Cisco CallManager. Requires an SBS to connect to either Exchange UM or EXO UM.


Lync Server/Skype for Business
Makes an authenticated federated call to the Lync Online service.

An Office 365 customer must create an IP Gateway in the tenant for SBC connectivity to Office 365. This creates a public DNS entry that looks like [GUID].um.outlook.com that maps to the SBC in Office 365. There will be one for each customer, but all on-prem SBCs connect to the same IP Gateway address, so the actual number of SBCs is really unknown.

UM Gateway in Exchange Server

The number of customers utilizing SBCs to connect to Office 365 may be small according to Microsoft, but these are usually very large customers with many SBCs. Once customers settle on a connectivity solution they continue to invest and expand on it. That's why it's such a big deal, especially for these customers.

According to today's announcement, the Office 365 SBCs are scheduled to be decommissioned in July 2018. If you're one of the customers who rely on SBCs to connect your on-premises PBX to Office 365 for Exchange UM or Azure voicemail, you have till then to make a change. As the article states, you have four options:

  • Option 1: Complete migration from 3rd party on-premises PBX to Office 365 Cloud PBX.
  • Option 2: Complete migration from 3rd party on-premises PBX to Skype for Business Server Enterprise Voice on-premises.
  • Option 3: For customers with a mixed deployment of 3rd party PBX and Skype for Business, connect the PBX to Skype for Business Server using a connector from a Microsoft partner, and continue using Exchange Online UM through that connector. For example, TE-SYSTEMS’ anynode UM connector can be used for that purpose.
  • Option 4: For customers with no Skype for Business Server deployment or for whom the solutions above are not appropriate, implement a 3rd party voicemail system.
Options 1, 2, and 4 are pretty well understood, but not trivial. Option 3, the anynode UM connector, requires a bit more explaining.

The anynode Skype for Business Voicemail Connector is a software SIP-to-SIP SBC solution that uses the Microsoft Unified Communications Managed API (UCMA) to communicate directly with Skype for Business Enterprise Voice. It's available from a German software company called TE-SYSTEMS (kind of reminds me of Geomant MWI for Exchange 2007 - anyone remember that?) This is great if your PBX already does SIP, but a number of large customers have analog PBXs in one or more locations. Traditional SBCs can convert analog PSTN calls to SIP using a Voice Gateway feature, and then trunk it over to Skype for Business or Skype for Business Online.

I can understand why Microsoft is discontinuing their SBCs in Office 365. It makes them rely on a third-party system that's sometimes difficult to manage. And after all, Microsoft is in business to sell services like Skype for Business and cloud PBX. But forcing customers to plan for and deploy all-new phone systems, SBC solutions, or voicemail systems in one year is asking a lot. Especially for the size of the customers they're affecting.

So what do you think? Will this tactic make you go "all in" for cloud PBX, as Microsoft hopes, or will it drive you toward one of the other solutions? Either way, you better get started now.

Read more ...

Another Azure AD Connect Update - Version 1.1.558.0

Thursday, July 13, 2017
This is the third update in a row where Microsoft published the AAD Connect release notes before the upgrade is publicly available. And if history serves, they'll update the release notes again after the version is released.

If auto upgrade is currently enabled for your version of AAD Connect, don't be too surprised if your version auto upgrades to this version before it becomes publicly available. Microsoft sometimes trial updates some customers ahead of the public release.

Azure AD Connect version 1.1.558.0 continues to fix issues with OU filtering and expands the number of configurations where auto upgrade can be enabled. It's important to note that if your configuration falls under the new configuration requirements, upgrading to this version will enable auto upgrade. If you don't want auto upgrade enabled, you should run the following cmdlet to disable it:
Set-ADSyncAutoUpgrade -AutoUpgradeState disabled


You can always download the latest public release of AAD Connect here.

Read more ...

New article: What to Do When the Office 365 Portal Goes Down

Thursday, July 13, 2017
I published a new article to the ENow Exchange & Office 365 Solutions Engine Blog (ESE), "What to Do When the Office 365 Portal Goes Down".


This article talks about recent availability failures in the Office 365 portal and provides direct URL links to Office 365 features and admin portals. Bookmark this page for reference the next time the portal becomes unavailable for your tenant!

Read more ...

Azure AD Connect 1.1.557.0 released

Wednesday, July 5, 2017
Hot on the heals of AAD Connect 1.1.553.0, Microsoft has released version 1.1.557.0 with an important update for Microsoft Azure AD cloud and Microsoft Cloud Germany customers.

It's important to note that for some reason this version will not be available to customers through the Azure AD Connect Auto Upgrade feature. You will need to download and install this build manually.

New features and improvements

  • Password writeback is now available for preview with Microsoft Azure Government cloud and Microsoft Cloud Germany. For more information about Azure AD Connect support for the different service instances, refer to article Azure AD Connect: Special considerations for instances.
  • The Initialize-ADSyncDomainJoinedComputerSync cmdlet now has a new optional parameter named AzureADDomain. This parameter lets you specify which verified domain to be used for configuring the service connection point.

Pass-through Authentication

New features and improvements

  • The name of the agent required for Pass-through Authentication has been changed from Microsoft Azure AD Application Proxy Connector to Microsoft Azure AD Connect Authentication Agent.
  • Enabling Pass-through Authentication no longer enables Password Hash Synchronization by default.

This update also fixes an issue with the Initialize-ADSyncDomainJoinedComputerSync cmdlet that caused the verified domain configured on the existing service connection point object to be changed even if it is still a valid domain. This affects tenants with more than one verified domain that can be used for configuring the service connection point.

To accommodate this, the Initialize-ADSyncDomainJoinedComputerSync cmdlet now accepts a new optional parameter named AzureADDomain. This parameter lets you specify which verified domain to be used for configuring the service connection point.

It's unclear if this update fixes the previously reported issue that AAD Connect 1.1.553 does not carry forward OU filtering settings during upgrade. Always check your AAD Connect configuration after upgrading.

Reader Andrew Pretty noted that auto update became enabled for him in this build.


I checked mine as well, and sure enough auto update is enabled. In previous builds auto update was not enabled unless you installed AAD Connect with Express settings (no customization whatsoever). I really wish changes like this were put into the release notes. If you want to turn auto update off, run the following cmdlet:

Set-ADSyncAutoUpgrade -AutoUpgradeState disabled

You can download the latest version of Azure Active Directory Connect here.

Read more ...

AAD Connect 1.1.553 does not carry forward OU filtering settings during upgrade

Saturday, July 1, 2017
I normally update existing posts with updated information, but thought this was important enough to publish as a new one since so many of my customers use OU filtering with AAD Connect.

Microsoft updated the release notes for Azure Active Directory Connect 1.1.553.0 to include the following known issue:

Known issue

  • There is an issue that affects customers who are using OU-based filtering with Azure AD Connect sync. When you navigate to the Domain and OU Filtering page in the Azure AD Connect wizard, the following behavior is expected:
    • If OU-based filtering is enabled, the Sync selected domains and OUs option is selected.
    • Otherwise, the Sync all domains and OUs option is selected.
  • +
The issue it is that the Sync all domains and OUs option is selected, even if OU-based filtering is enabled. Before saving any synchronization configuration changes in the wizard, make sure the Sync selected domains and OUs option is selected first. Otherwise, OU-based filtering will be disabled.
This only affects customers who use OU filtering in AAD Connect. Customers performing upgrades of AAD Connect (or any software) should always pay attention during the upgrade process and check their settings afterwards. It's expected that settings will carry over, but as you can see above, that's not always the case. Never assume anything.

Read more ...

Congratulations 2017-2018 Microsoft MVP!

Saturday, July 1, 2017
I'm pleased to announce that I have been given the Office Servers and Services Microsoft MVP award again for 2017-2018. I have been awarded every year since 2009, so this will be my ninth consecutive year.



The MVP Award is an important recognition to me and I'm very pleased to receive it. It includes several benefits, but the most important one to me are all the interactions with the great product groups at Microsoft. These relationships allow me to reach out to specific product team members to provide feedback and get clarification on product features and behaviors.

It's a mutually beneficial partnership -- under NDA, Microsoft is able to talk with MVPs about product futures, provide access to technology adoption programs (TAPs) to try out new software, and solicit our feedback. As MVPs, we are able to provide important and honest feedback to the product teams about how new features and behaviors will affect our customers, beta test new software and file bug reports, and be advocates for you, the customer.

This also adds value to my IT consulting business, EXPTA Consulting. It's evidence that Microsoft values my technical leadership and real-world experience, which I bring to each and every engagement, and customers know that I provide the best results as their trusted advisor.

I feel great!


Read more ...

Important update for AAD Connect - Version 1.1.553.0

Wednesday, June 28, 2017


Microsoft released Azure Active Directory Connect version 1.1.553.0 on June 26, 2017. More importantly, they published an important security advisory one day later.


Microsoft Security Advisory 4033453 - Vulnerability in Azure AD Connect Could Allow Elevation of Privilege explains,
The [ADD Connect version 1.1.553.0] update addresses a vulnerability that could allow elevation of privilege if Azure AD Connect Password writeback is misconfigured during enablement. An attacker who successfully exploited this vulnerability could reset passwords and gain unauthorized access to arbitrary on-premises AD privileged user accounts. The issue is addressed in the latest version (1.1.553.0) of Azure AD Connect by not allowing arbitrary password reset to on-premises AD privileged user accounts.
Microsoft highly recommends all customers update to version 1.1.553.0 or later to mitigate this vulnerability, even if you don't use the optional password writeback feature. If you are unable to update immediately, the article above describes mitigation steps you can consider.
  • If the AD DS account is a member of one or more on-premises AD privileged groups, consider removing the AD DS account from the groups.
  • If an on-premises AD administrator has previously created Control Access Rights on the adminSDHolder object for the AD DS account which permits Reset Password operation, consider removing it.
  • It may not always be possible to remove existing permissions granted to the AD DS account (for example, the AD DS account relies on the group membership for permissions required for other features such as Password synchronization or Exchange hybrid writeback). Consider creating a DENY ACE on the adminSDHolder object which disallows the AD DS account with Reset Password permission using Windows DSACLS tool.
DSACLS DNofAdminSDHolderContainer /D CONTOSO\ADDSAccount:CA;"Reset Password"

Besides this important security update, AAD Connect 1.1.553.0 includes several fixes, new features, and improvements both in AAD Connect and AD FS management. Read the Azure AD Connect: Version release history for a complete list.

With Azure AD Connect being such an important part of your cloud connectivity and authentication solution, it's super important to stay on top of any updates.



Read more ...