Usually, the Exchange external Autodiscover DNS entity is configured as a regular A or CNAME record. In some cases, a service record (SRV) is used instead. Here is a simple syntax of quickly querying for the SRV record:

During Cloud migration projects we ofter get questions similar to this:

“OK, we’ve moved to Office 365? Now what? How our Multifunction Device will send emails?”

I hope this blog post will help to understand what options are available to address the situation with Multifunction Device and any other devices and applications that should send emails through a corporate messaging system.

Note: This blog post outlines guidance on how to allow SSO on End-Users devices operated by Microsoft Windows OS and running Microsoft Office products.

Solution Objectives

As many of you know, one of the most important components in SSO (in regards to office 365 services), when a user uses Office applications is Modern Authentication. Modern Authentication is enabled by default in Office 2016, however, to make Office 2013 (we still see A LOT of companies use Office 2010 and Office 2013) fully compatible with Modern Authentication some additional steps are required.

Of course, cloud identity is very big and important topic. We see a lot of different vendors, like Azure AD, Okta, Onelogin, and etc. providing cloud identity solutions.

Recently we were asked to help one VERY big enterprise (more than 80000 users!) with their cloud identity and SSO challenges. This organisation decided to use Okta.

So, the information included in this section represents the summary of the recommended settings, inside OKTA Admin panel and all required changes on the client side.

Here are 3 scripts that I wanted to call out:

• Install Exchange 2016 Pre-requisites.ps1 – Makes it easier to install Exchange 2016 prerequisites
• O365_Installs_Connections.ps1 – Makes it easier to prepare machines from which we administer Office 365
• O365_Logon Module – An easier way to log into Office 365 services using PowerShell

I hope there is no need to explain what is “Azure AD Connect” :). We like it or not, but all organisations, that want to work with Office 365 / Azure probably be starting with a hybrid configuration where existing Active Directory objects (and in some cases passwords) on-premises sync to Azure AD using Azure AD Connect.

Recently Microsoft released Azure AD Connect build 1.1.377.0, that introduced “Azure Pass-Through Authentication” (It is currently in public preview). Azure Pass-Through Authentication aimed to provide the following features: