Microsoft 365 Certifications

Microsoft announced the New Role Based / Workloads Certification exams in Q4 – 2018. New Microsoft 365 certifications have 2 titles

  • Microsoft 365 Certified: Enterprise Administrator Associate
  • Microsoft 365 Certified: Enterprise Administrator Expert

Enterprise Administrator Associate certification available for below 4 Microsoft 365 workloads and we need to write 2 exams for each workloads. If you complete the 2 exams associated with the respective workloads, you will get the Microsoft 365 Certified: Enterprise Administrator Associate

  • Message Administrator Associate
  • Team Work Administrator Associate
  • Security Administrator Associate
  • Modern Desktop Administrator Associate

Enterprise Administrator Expert certification has 2 exams. We can take any of the above workloads exams + the 2 Enterprise Administrator Expert certification exam to get the Microsoft 365 Certified: Enterprise Administrator Expert Title.

Below table shows the exam details of Microsoft 365 Certified: Enterprise Administrator Associate certification

New Roles Exam
Microsoft 365 Certified: Messaging Administrator Associate
Microsoft 365 Messaging Administrators MS-200: Planning and Configuring a Messaging Platform
MS-201: Implementing a Hybrid and Secure Messaging Platform
Transition Path – MS-202: Microsoft 365 Messaging Administrator Certification Transition (70-345 Completed)
Microsoft 365 Certified: Teamwork Administrator Associate
Microsoft 365 Teamwork Administrators MS-300: Deploying Microsoft 365 Teamwork
MS-301: Deploying SharePoint Server Hybrid
Transition Path – MS-302: Microsoft 365 Teamwork Administrator Certification Transition (70-339 Completed)
Microsoft 365 Certified: Security Administrator Associate
Microsoft 365 Security Administrators MS-500: Microsoft 365 Security Administration
Microsoft 365 Certified: Modern Desktop Administrator Associate
Microsoft 365 Modern Desktop Administrators MD-100: Windows 10
MD-101: Managing Modern Desktops
Transition Path – Completed Exam 70-698 : Installing and Configuring Windows 10 can write MD-101 only

Below table shows the exam details of Microsoft 365 Certified: Enterprise Administrator Expert Title.

Microsoft 365 Certified: Enterprise Administrator Expert

Enterprise Administrator Expert

MS-100: Microsoft 365 Identity and Services
MS-101: Microsoft 365 Mobility and Security

Transition Path – If you have MCSE: Productivity, then completing MS-100 & MS-101 will give you Microsoft 365 Certified Enterprise Administrator Expert certification.

If not, You need to complete any one of the Microsoft Workload Exam + MS-100 & MS-101 to earn the Microsoft 365 Certified Enterprise Administrator Expert certification.

All the best and Good luck with your exams – Super Hybrid Cloud Team.

We will see how the authentication works when accessing Exchange Online Mailbox in Outlook Web Access. Before looking at the OWA authentication flow, we need to understand the Identity Models available in Office 365.

  • Cloud Identities – User accounts provisioned directly in Azure Active Directory using Office 365 Portal or Azure AD PowerShell.
  • Synchronized Identities with password hash – User accounts and the hash of their on-premises Active Directory password is synchronized to azure active directory.
  • Federated Identities – Federation established using ADFS and User accounts synchronized to the Azure Active Directory from On-Premise Active directory.

Federated Identity model is the preferred Identity model for most of the Organization. Federated Identities model uses Active Directory Federation Service technology to establish a federation trust between the Office 365 tenant and the on-premises Active Directory. With the Federated Identity model, when a user tries to access an Office 365 workload, he will get an SAML security token from ADFS, which is handed to Azure AD as proof for being allowed to access the respective workload.

Below diagram explains the authentication flow for Internal OWA client accessing Exchange Online Mailbox.

  1. OWA web client from Internal network tries to access Exchange Online using Outook.office365.com URL, Exchange online redirect the web client to authentication with Azure AD login.microsoftonline.com
  2. OWA client will be redirected to login.microsoftonline.com and login screen appears to enter the credential, once the user enters the user name (user@superhybridcloud.com), Azure AD will check whether the domain is federated or not. In our case it is federated domain, Azure AD will redirect the web client to authenticate with federated identity, which is sts.superhybridcloud.com.
  3. Sts.superhybridcloud.com will resolve to ADFS server available in On-Premise. Windows Integrated Authentication will be configured on ADFS and the authentication will automatically happen in the backend using logged in credential.
  4. ADFS will validate the credential with AD and retrieve the necessary claims related information from AD.
  5. AD validates the credential and provide the requested claims information to ADFS.
  6. ADFS server present a token holding the claims about the user to web client
  7. OWA client will present the received token to Azure AD and authentication will be successful, the web client will be redirected back to outlook.office365.com
  8. Authentication successful and the OWA client will go to Exchange online with successful authentication status and user can access his mailbox in OWA.

Below diagram explains the authentication flow for the Internet OWA client accessing his Exchange Online Mailbox.

If the OWA web client is from internet, all the steps explained above will be applicable. Only difference is, the redirection to STS is through ADFS Proxy or Web Application Proxy servers and also, the web client will be asked to authenticate via Form based authentication page.

Hope you are able to understand the authentication flow for Exchange Online when using Outlook web access. We will see how the outlook authentication works when accessing Exchange Online Mailbox. For any additional clarification, please post your comments.

Before we look at how the Outlook authentication works? we need to understand what is Basic Authentication client and Modern Authentication Clients.

Basic Authentication Clients: Clients or applications that is not a browser-based client that access Office 365 services are Basic authentication clients. Outlook 2013 by default is a basic authentication client and few other clients like EWS clients and EAS clients are Basic authentication clients.

Modern Authentication Clients (OAuth): Modern Authentication uses Active Directory Authentication Library (ADAL) based sign-in for Office clients. ADAL based sign-in supports features like MFA, certificate based authentication and smart card authentication. Outlook 2016 by default is a modern authentication office client, where Outlook 2013 requires an Office update and registry settings modified to act like a Modern Authentication client.

Unlike other authentication method, OAuth provides 2 tokens (Access and Refresh tokens) to the client when it successfully authenticates against Azure Active Directory. Access token is a JSON Web Token (JWT), which is valid for 1 hour and a Refresh token valid for 14 days, if it is continuously accessed it will be valid for 90 days.

Now, we will see how the authentication works on both Basic Authentication client and Modern Authentication client.

  • Basic Authentication

Below diagram explains the authentication for basic authentication client, let us take an Outlook 2013 client or an EWS / Exchange Active Sync client tries to access an Office 365 Mailbox.

  1. Outlook client do an Autodiscover lookup and it know it has to connect outlook.office365.com to access Office 365 Mailbox and initiated the connection to Exchange Online by sending the basic authentication credential over SSL.
  2. Exchange Online sends the details to Azure AD using Proxy Authentication
  3. Azure AD sends the respective endpoint configured for this type of request which is sts.superhybridcloud.com to Exchange Online
  4. Exchange Online will go sts.superhybridcloud.com, which is ADFS Proxy or WAP server in DMZ.
  5. ADFS Proxy or the WAP server proxies the Exchange Online request to ADFS Servers
  6. Active Directory authenticates the request from ADFS
  7. Active Directory sends a logon token along with users information as claims
  8. ADFS server will send the token with claim information to Exchange online
  9. Exchange Online sends the details with Azure AD
  10. Azure AD returns in to Exchange Online in a state where it can be used to authenticate the client and the client are connected.

     

  • Modern Authentication

Microsoft working on updating all the clients to work like modern authentication, which will use OAuth Authentication. OAuth uses access and refresh tokens to allow access to Office 365 workloads using Azure Active Directory. We will see how it works when we use outlook 2016 to access Exchange Online Mailbox.

  1. Outlook do an Autodiscover lookup and find the Exchange Online Url as outlook.office365.com. Outlook will try to connect outlook.office365.com
  2. Exchange Online redirects the Outlook client to Authentication endpoint in Azure AD (login.microsoftonline.com). Outlook client will use ADAL browser control to reach Azure AD.
  3. Azure AD authentication endpoint will detect the UPN domain is federated and redirect to internal ADFS endpoint.
  4. ADFS require the outlook client to authenticate.
  5. Once the authentication completed, AD will send the user claim information to ADFS.
  6. ADFS server get the user related information as a claim and sent SAML token with claims about the user to Outlook client
  7. Outlook client present that token to Azure AD and after successful authentication, the client will be provided with the access and refresh token.
  8. Outlook client sent the access token to Exchange Online on behalf of user and he will connected to Exchange Online.

Device Management in Azure AD is required to ensure the devices connecting to the cloud services are meeting the Company Security and Compliance Standards. If you have On-Premise Active Directory, computers related to that company are joined to that AD and administrators will have control to those AD joined devices like pushing group policies etc.

Joining a Computer to Azure Active Directory is similar to joining a computer to local active directory. Difference is Azure AD is in Cloud and when joining a machine to Azure AD, it provides additional capabilities like Single Sign On experience when accessing the applications and we can restrict access to those devices based on the Azure AD Join status using Azure Conditional Access.

Device Join to Azure Active Directory are three types:

  • Hybrid Azure AD Join: Device joined to On-Premise Active Directory and Azure Active Directory.
  • Azure AD Join: Device joined directly with Azure AD (not On-Premise AD Domain joined)
  • Azure AD Registered (Workplace Join): Device registered with Azure Active Directly like Windows 10 Personal and Mobile Devices.

During the Azure conditional access validation, all the above devices joined to azure are considered as domain joined devices and the respective settings will be applied.

Hybrid Azure AD Join in Windows 10

Windows 10 Device Registration process explained as

  1. Group Policy pushed to the machine starts the device registration with Azure AD
  2. Windows Device will query AD to get the information about the Azure AD Tenant
  3. Windows Device authenticates itself to Azure AD via ADFS to get a token for device registration
  4. Windows Device generates key pairs used for device registration
  5. Windows Device registers with Azure AD via Azure Device Registration Service.

Below the detailed explanation on how the Hybrid Azure AD Join works

We need to configure few things for Hybrid Azure AD Join to work properly like AD Connect deployment, Group Policy pushing and ADFS Issuance Transformation Rule etc… those prerequisites configuration steps not explained here. We will assume those are already set and will see the flow on how the Azure AD Join working in Windows 10 Machine.

  1. Group policy pushed to Windows 10 clients, which creates a task for the device registration to work and the task will be triggered.
  2. Windows 10 client queries AD (Service Connection Point object) which has the details about the Azure AD tenant to which the client has to connect. Azure AD Connect deployment will create those objects. I have highlighted the path for reference on the diagram.
  3. Azure AD Tenant information like the Azure AD name and the ID will be sent to Windows 10 Client.
  4. A hidden Internet browser is launched and the OAuth code authentication request is sent to Azure AD
  5. Azure AD redirects the client to authenticate with ADFS
  6. Client will reach ADFS by sending the computer account as identity, using Windows Integrated Authentication. Note: If the device is in Internet, then the authentication will fail because the WAP server will have form based authentication and you won’t know the prompt in hidden browser to authenticate.
  7. ADFS validates the computer identity with AD
  8. After the successful authentication, AD send the claim details to ADFS
  9. ADFS send a token along with 3 claims to Windows client, which the device will sent it to Azure AD for successful authentication
  10. Client sends the token along with 3 claims about the device received from ADFS to Azure AD
  11. Azure AD trust the token from ADFS server as it is already integrated and send a final token to Client for Azure Device Registration
  12. Device creates a Private/Public key pair to be used in a certificate-signing request from Azure DRS, to obtain the certificate that the device will use to authenticate to Azure AD later on. In addition, the task generates a second private/public key pair that is later used to bind the Primary Refresh Token (PRT) to the physical device upon authentication.
  13. Task send the Certification Signing Request along with final token received from Azure AD to Azure Device Registration Service.
  14. Azure DRS authorize the token, create a certificate, creates a Device object with its certificate thumbprint and return the certificate to the client.
  15. Client stores the certificate in the User My Store.

If you see above, the device registration is successful. For the Single Sign-On experience in Windows 10, the Primary Refresh Token will be received from Azure AD.

User sign-in to client using his credential, the Cloud Authentication Provider plug-in in windows client authenticates with Azure AD and ADFS, to obtain the Primary Refresh Token. Cloud Authentication Provider knows the Azure AD and ADFS details from the cache available during the Device Registration. Cloud AP plugin will directly send the credential to ADFS and get the SAML token and present it to Azure AD for authentication, Azure AD authenticates it and build a PRT with both User and Device claims and it will return to Window device.

I hope this is informative and you like it. Please comment for any clarification.

Exchange Server 2019 is a single server role architecture and it is easy to deploy. I have share the details on how to install Exchange Server 2019 in my blog and here we will see the post installation steps to make the Exchange Server 2019 fully functional.

I’m just sharing basic information post installation steps that you need to do after Exchange Server 2019 installation.

Step 1: Create a Send connector to send emails to External Domain.

By default, there is no option to send an email to external domain. We have a manually create a send connector to send emails to external domain.

Step 2: Create Accepted Domains

Domain in which Exchange 2019 installed will be authoritative by default (domain.local) etc and if we want to have an email address like domain.com, we need to create an accepted domain with the name domain.com

Step 3: Configure Email Address Policy

We have created Accepted domain in the above steps and to stamp that domain.com email address to the recipients, we need to configure the default email address policy and apply the email address policy to all the mailboxes

Step 4: Configure Exchange Certificate

All the services in use to be configured to use SSL instead of self-signed certificate and certificate to be configured for all the services

Step 5: Configure Exchange Virtual Directory External and Internal Urls and Authentication Methods

Services that are published external to be configured with the external Url and internal urls to be modified as per the design plan. Ensure you have configured the right Authentication Method for each Virtual Directory

Step 6: Configure Load Balancing for Client Access Urls

Once the Virtual directory settings are configured, we can consider to configure load balancing for all the Client Access Protocols

Step 7: Verify all types of client connections to Exchange

Check the Outlook connectivity, Auto Discover, OWA, ECP, EWS, Exchange Active Sync, Outlook Anywhere client connection.

Step 8: Setup Monitoring and Alerting

One of the must have thing for Exchange environment is to have proper monitoring solution to monitor and alert if any issues in Exchange.

Step 9: Setup Mobile Device configuration

We can consider to have Mobile Device Access Policies based on the company security standards if Users are allowed to access their mailbox using Mobile devices.

Step 10: Secure Mail Flow

Ensure you have proper Anti-Spam and Anti Malware scanning available for mail flow by configuring the default malware scanning engine or route inbound and outbound mail flow via Exchange Online Protection.

Leave your comments for any queries on the above.

If your mailbox hosted in Office 365 and experiencing slowness while accessing the mailbox using outlook, you need to check below things before raising a ticket with Microsoft.

  • Check the Global DNS Resolution

It is always better to check whether your connection goes the closest regional office 365 datacentre. If your Office 365 tenant hosted in US and you are accessing your mailbox in US but the DNS resolution to Singapore ingress point, then you may to need to contact your ISP to identify/fix the issue.

Check the host name resolution for outlook.office365.com. Below connecting to outlook-in.office365.com as I’m in sitting in India.

 

 

 

    
 

 

NSLOOKUP will show the nearby Ingress endpoint name. Below the ingress point available at office 365 and the location details

  • Check the network latency using ping or psping test

If you are experiencing slowness in accessing your Office 365 Mailbox, you can check the network latency to outlook.office365.com using ping test, average latency should not exceed 300 ms.

  • Outlook Connection Status

Check the Outlook Connection Status by focussing the Average Request and Average Response. You can calculate the round trip time using RTT = Average Request – Average Response which has to be less than 300 ms

  • Trace Route to find the number of hops to reach Microsoft network

Use the tracert command to outlook.office365.com to check the number of hops it is taking to reach the Microsoft network (msn.net)

  • TCP Idle session

TCP time out has to be configured more than 2 hours on the perimeter devices like firewall and other network devices

  • check the latency when using Proxy and a direct internet connection

Most of the organization use proxy server to allow the clients to connect to internet. Check the latency when using proxy and without proxy and if proxy shows more latency check if you can bypass it

  • Disable the outlook Add-Ins to see if any Add-Ins is causing a Problem.

Outlook -> File -> Options -> AddIns -> Manage Add-Ins

  • Also you can use SARA Tool to find any issues in Outlook issues

Above are the basic things that we can check to see if any issue at the end user side. If everything looks normal, then raise a ticket with Microsoft 😉

How Azure AD Connect Works

December 24th, 2018 | Posted by admin in Azure AD - (0 Comments)

Azure AD Connect is the upgraded version of DirSync which is used to provision the On-Premise Objects into Azure Active Directory. There are many ways that can be used to provision the Objects to Azure AD for Office 365 like,

  • Directory Synchronization (DirSync), Office 365 Portal, Windows PowerShell, or API
  • Microsoft Azure AD Connector for FIM 2010 R2
  • Microsoft Azure Active Directory Sync tool (Azure AD Sync Tool)
  • The New Microsoft Azure AD Connect

We will see how the Azure AD Connect works on this post. Directory Sync or the Azure AD Connect is mainly required for Identity Federation and Exchange Hybrid Deployment. Below the flow diagram of how the Azure AD Connect works

Azure Connect support the below features

How Azure AD Connect works?

Azure AD Connect by default is a one-way Sync which synchronize the On-Premise AD objects to Azure AD. Before looking at the Synchronization Data Flow, we will see what are Management Agents and where AD Connect stores the information

Management Agents

Management Agents in Azure AD Connect control the data flow between a connected data source and the meta directory. DirSync or Azure AD Connect uses two managements agents.

  • Active Directory Connector management agent
  • Microsoft Azure Active Directory management agent

DirSync or Azure AD Connect stores the information in two places:

  1. Connector Space

Connect Space has the Replica of the managed objects in the AD DS and each management agent or connector has its own connector space

  1. Metaverse

Aggregate information about a managed object (that is, User, Group, etc.)

Azure AD Connect Synchronization data flow:

  1. User is imported from On-Premise AD into the Active Directory Connector space
  2. User is projected to the Metaverse
  3. User is provisioned to the Microsoft Azure Active Directory Connector space
  4. User is exported to the Office 365 Admin Web Service

Above explains how the Azure AD Connect synchronize the objects from On-Premise AD to Azure AD. If Exchange Hybrid option is selected which installing/configuring the Azure AD Connect, then below 7 attributed will be written back to On-Premise AD. (Exchange Federation is must for below Objects to write back to On-Premise AD).

msExchArchiveStatus

Online Archive: Enables customers to archive mail.

msExchUCVoiceMailSettings

Enable Unified Messaging (UM) – Online voice mail: This new attribute is used only for UM-Microsoft Lync Server 2010 integration to indicate to Lync Server 2010 on-premises that the user has voice mail in online services.

msExchUserHoldPolicies

Litigation Hold: Enables cloud services to determine which users are under Litigation Hold.

ProxyAddresses 
(LegacyExchangeDN as X500)

Enable Mailbox: Offboards an online mailbox back to on-premises Exchange.

msExchSafeSendersHash
msExchBlockedSendersHash
msExchSafeRecipientsHash

Filtering: Writes back on-premises filtering and online safe and blocked sender data from clients.

 

Forward Sync and Back Sync in Azure AD Connect

It is important to know what is forward sync and back sync in Azure AD Connect.

Forward Sync

It is sync from Azure AD to the Online Application directory services

  • Once the AD Objects from On-Premise synced to Azure AD, Azure AD won’t be directly referred by office 365 online application.
  • Each online application in Office 365 has their own directory service. After an object is changed in Azure AD, further synchronization are constantly running that parse relevant changes and ship them to these services’ directory partitions.
  • Since the Application directory are updating the information from Azure AD, it can cause delay in applications becoming available to newly commissioned accounts or users

Back Sync or write Back

When Exchange Hybrid Configuration feature is enabled while configuring AD Connect, there are certain attributes for the Microsoft Exchange Online service that require reverse propagation to the on-premises environment for Exchange co-existence features to work which is referred as Back Sync.

  • Back-Sync: Data is changed in the Exchange Online partition and then synced back to Azure AD using daemons similar to those used for Forward-sync
  • Write-back: Data is shipped from Azure AD directory, back through Admin Web Service, to DirSync service using bi-directional FIM functionality
  • DirSync updates the local AD DS objects with these updated attributes

I hope this post is informative, please leave your comments if any additional information required.

On the last part, we saw how the auto discover works for customers in Office 365 alone. In this post we will see how the Autodiscover working on Exchange On-Premise and Hybrid Edge environment.

How Autodiscover works in Exchange On-Premise?

If a company has their messaging infrastructure in On-Premise alone, this is how the Autodiscover works for Exchange Online Mailbox

  1. Once the user launches the outlook and enter the credential, Outlook will query AD for SCP record to get the Autodiscover Service information.
  2. Once the information available, it will validate the user and try to connect the url which will go to the client access server
  3. CAS server query AD and send the Autodiscover and other exchange related services information in XML file
  4. Outlook uses that information to configure outlook profile.

Below the Test E-Mail Autoconfiguration result that explains the above behaviour

How Autodiscover works in Exchange Hybrid Environment?

Hybrid Exchange environment is nothing but a customer having few mailboxes in On-Premise Exchange and few in Office 365 (Exchange Online). Though both the exchange infrastructure are different, Hybrid Configuration Wizard make those 2 environments coupled together and function as a single environment.

Below the details on how Autodiscover works for a user mailbox in Office 365 for Hybrid environment user.

In above illustration, company user dhanya.com as their SMTP address space and for the mailboxes in Office 365, On-Premise will have a remote mailbox account with the target address as dhanyaonline.mail.onmicrosoft.com as the target address.

  1. Once the user launches the outlook and enter the credential, Outlook will query AD for SCP record to get the Autodiscover Service information.
  2. Once the information available, it will try to validate the user and it can’t find mailbox for Raj and only remote mailbox account available for this user in On-Premise and it will inform outlook to try Autodiscover request for Raj’s Target Address.
  3. Outlook will try to get the Autodiscover information for dhanyaonline.mail.onmicrosoft.com by dns query to internet. Autodiscover.dhanyaonline.mail.onmicrosoft.com will have a CNAME record that points to Exchange Online Autodiscover record
  4. Outlook will connect Autodiscover.outlook.com which will connect to Exchange Online client Access server
  5. Exchange Online validate the user by an authentication prompt
  6. Once verified, Exchange Online will send the Autodiscover information in xml formal to user.

Below the Test E-Mail Autoconfiguration result that explains the above behaviour which clearly shows the above explanation

We see lot of information on how the Autodiscover works for Exchange Online, Exchange On-Premise and Hybrid Exchange environment with explanations. I hope this is informative to you. Leave your comments if any additional information required.

On the last part, we saw how the auto discover works for internal and external clients. In this post we will see how the Autodiscover working on Exchange Online.

How Autodiscover works in Exchange Online?

If a company has their messaging infrastructure in Office 365 alone without any On-Premise infrastructure, this is how the Autodiscover works for Exchange Online Mailbox

  1. When user enters the credential, it will perform a SCP query and it will fail
  2. DNS lookup will happen to find the Autodiscover service for the FQDN autodiscover.domainname.com
  3. Once it finds the Autodiscover record, there will be CNAME record created for Autodiscover pointed to Autodiscover.outlook.com. Here it is pointed to connect Exchange Online to get the Autodiscover information
  4. Outlook will connect autodisover.outlook.com (Exchange Online) and the credential will be validated.
  5. Autodiscover xml file will be returned to outlook client with the server name to connect as outlook.office365.com

Below test connection result show the details on how it worked. For testing, I have directly entered the domainname.onmicrosoft.com email address, so the SCP query is not available on the below result.

Explanation:

Lot of tools are available to see the behaviour of Autodiscover like Outlook Test E-mail AutoConfiguration, Exchange Remote Connectivity Analyser, Fiddler and outlook advanced logging etc. Here we will use the Outlook Test E-mail AutoConfiguration option to explain the Autodiscover Process.

All the requests to Office 365 are considered as external network request and it behaves the same way as explained in the previous article.

  1. Second portion of the email address is considered as a the fqdn and it try to connect to that Url and it failed

  1. Outlook uses the predefined URL as mention below to connect and it failed again

  1. Searching for any local record for domain name and it failed

  1. Redirection method (HTTP instead of HTTPS to predefined URL) followed and it got response to go to https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml. It will prompt to enter the credential for validation at this point

  1. Got response for https & http of https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml and for xml will retrieved from Exchange Online and outlook configures the profiles

This is how you need to split the log to see how the Autodiscover working on your environment.

Everyone knows how Exchange Autodiscover works, as it is there from Exchange Server 2007. Writing this blog to show how it works for Exchange Online, Exchange On-Premise and Exchange Hybrid environment.

Microsoft Exchange Autodiscover service in Exchange helps the Autodiscover capable outlook clients to configure outlook profile easily by providing minimal input. Users know their user name and password information, by providing those information, other information to configure outlook profile can be retried from Exchange using Autodiscover Service. Autodiscover automatically configures user profile for outlook and mobile devices.

Outlook 2007 and later clients supports Autodiscover to connect Exchange 2007 and above.

How Autodiscover works?

Information that are required to configure the outlook profile will be retrieved from Exchange in a XML format and outlook use that information to connect to different services to function properly.

How Autodiscover works when connecting from Internal network.

Note: To locate Autodiscover service, outlook uses LDAP query to Service Connection Point object first (Internal clients) and if it fails it uses DNS query (external clients).

  1. Once user enters the credential (email address and password, where email address is considered as a user name), outlook authenticated with AD and queries for Service Connection Point objects to find the Autodiscover Service in Client access server to which it has to contact to get the Autodiscover information in xml format.

SCP object will be created when Exchange client access server installed and new SCP will be created when new CAS servers are installed, SCP will be updated with the servicebindinginformation FQDN of client access server name in the form of https://cas01.learnexchangeserver.com/autodiscover/autodiscover.xml and keyword that tells to which site this CAS server belongs.

Once the client authenticated to active directory,

  • The Autodiscover service information will be obtained from SCP object, for any reason it that fails
  • Outlook will try the predefined URL like https://autodiscover.learnexchangeserver.com/autodiscover/autodiscover.xml by using DNS
  • If the above fails, outlook will try the HTTP redirect method, it is same predefined URL, instead of https, http will be used
  • If the above fails, SRV record lookup will be used which is the last lookup method and if that fails outlook auto configuration will fail.
  1. Autodiscover Service in CAS server contacts AD to get the URL and the configured Exchange Services details
  2. Autodiscover Service returns a HTTPS response with XML file that includes connection settings and URLS for available Exchange features
  3. Outlook client uses that information to connect to Exchange.

How Autodiscover works when connecting from Internet.

If the Client Machine is not domain joined, or connecting from Internet.

  1. Outlook first tries to locate the Autodiscover service by looking up the SCP object in Active Directory. Since the client is in internet, it will not be able to contact Active Directory,
  2. Outlook Client will try to locate the Autodiscover service by DNS query.

For DNS query, outlook uses the right side of the email address (domain name), that is, learnexchangeserver.com, and then check the DNS for two predefined URLs. For example

https://learnexchangeserver.com/autodiscover/autodiscover.xml

https://autodiscover.learnexchangeserver.com/autodiscover/autodiscover.xml

Note: Need to create a DNS record in Internet to connect to your Client Access Server to make it work.

  1. Autodiscover Service in CAS server contacts AD to get the URL and the configured Exchange Services details
  2. Autodiscover Service returns a HTTPS response with XML file that includes connection settings and URLS for available Exchange features
  3. Outlook client uses that information to connect to Exchange.

On the next part we will see how the Autodiscover work for Exchange Online / Exchange On-Premise and Exchange Hybrid environment.