I will give a short intro about my Exchange Environment before jumping into the details on how to install Exchange Server 2019.

I have a Domain Controller with a domain name SHC.Com, Exchange Server 2013 and Exchange Server 2016 are there in this lab. I’m going to install Exchange Server 2019 on a 4 CPU with 16 GB RAM for this Exchange Server 2019 Step by Step Installation demo.

Prerequisites for Exchange Server 2019:

  • OS: Windows Server 2019 Standard / Datacenter Edition
  • Hardware: 64-bit processor with 128 GB RAM recommended
  • Active Directory Schema: AD Forest Functional Level Windows Server 2012 R2 or higher
  • Hybrid Support: Coexistence of Exchange Server 2013 CU1 and Exchange Server 2016 CU11 and above
  • Other Prerequisite: .NetFrameWork 4.7.2, Visual C++ Redistributable Package for Visual Studio 2012, Unified Communications Managed API 4.0
  • Windows Features: Exchange Server 2019 installation has the option to deploy the required Windows Features during the installation. If for any reason, if you want to install the Windows Features Manually then run the below command.

Install-WindowsFeature Server-Media-Foundation, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-PowerShell, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Metabase, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, RSAT-ADDS

Note: Forgot to add IIS Management Console on the screen capture. Please install it before the Exchange 2019 Installation or allow the Exchange 2019 installation to include the required windows features.

Validating the Prerequisites:

Forest & Domain Functional Level

Exchange Server 2019 Computer details

Windows Features Installation:

Other Prerequisites

Existing Exchange Servers (Co-existence of Exchange Server 2013 CU21 & Exchange Server 2016 CU11)

Prerequisites verified and we are good to start the Exchange Server 2019 Installation.

Step by Step Exchange Server 2019 Installation:

Prepare the AD Schema & Domain and then start the Exchange Server 2019 installation.

Step 1: Preparing the AD Schema

Step 2: Preparing the Domain

Restart the computer once before starting the Exchange 2019 installation.

Step 3: Exchange Server 2019 Installation

I don’t want to bore you with the GUI screen captures as it is not different from Exchange 2013 / Exchange 2016 installation.

We will see what’s New in Exchange Server 2019 on the next post. Post your comments for any queries in Installing Exchange Server 2019.

Your users may user different type of Strong Authentication method on their choice when MFA enabled for them. If you want to take a report on the type of Authentication Method, use the below PowerShell command.

Get-Msoluser -All |select DisplayName,@{N=’Email’;E={$_.UserPrincipalName}},@{n=”MFA_Methods”;e={($_.StrongAuthenticationMethods).MethodType}},@{N=’MFA_Requirements’;E={($_.StrongAuthenticationRequirements).state}} | export-csv C:\Temp\MFA_Strongauth_Dec31.csv –NoTypeInformation

Send-AS Permission in On-Premise Exchange environment can be assigned using the below PowerShell command,

Add-ADPermission -Identity “UserAccount” -User “UserwhoNeedsPermission” -AccessRights ExtendedRight -ExtendedRights “Send As”

But, as per Microsoft article, Send-As Permission over cross Exchange platform like Hybrid Exchange environment is not supportable. But still, you can run the below command to provide Send-As Permission for a On-Premise Mailbox on a Mailbox in Office 365.

Add-RecipientPermission “UserMailbox” -AccessRights sendas -Trustee “On-Premise Mailbox”

Azure AD Connect Sync the User Profile photo during the initial sync only. Any further changes on the Photo in On-Premise will not Sync / Update to Azure AD.

We need to manually change the photo if any changes required. You can follow the below PowerShell command to change the photo.

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $Session

Set-UserPhoto “userid” -PictureData ([System.IO.File]::ReadAllBytes(“C:\Temp\userphoto.jpg”))

In this post, we will see how to control External Sharing in SharePoint Online & OneDrive for Business Online. It is better to control external sharing to restrict who can share contents with whom and this ensures your organization data safe.

Default settings on OneDrive for Business Online or for SharePoint Online is to share the content with anyone in the world (not to aliens 😉 ). Below the shows the default settings. ‘

You can login to Admin.OneDrive.com to control the external sharing both the applications.

OneDrive for Business Online

In addition, you can login to SharePoint Online Admin center to see the default settings, which will be like Allows external sharing with Authentication users, which means share with anyone who can authenticate with Azure AD.

Below the settings available for external sharing and you can choose any option that best suits your requirement or policy.

  • Only People in your organization – In other words, you are disabling the external sharing capabilities.
  • Existing external users – External users account already created in your Azure AD. If you create an external user, user in your organization can share with that external user
  • New and existing external users – You can share with anyone, if they authenticate with Azure AD using their organization account or using their live.com account then that account will be created in your organization’s Azure AD and users in your organization can share the content with them.
  • Anyone – Default option, as it is says sharing can be done to anyone and there is no requirement to login using his or her account.

We can move the slider based on our requirement to set the external sharing options.

Advanced settings for External Sharing:

Organizations may want to set the external sharing only to the domains that they collaborate on daily basis, to achieve this; on the same OneDrive admin center we control the advanced external sharing options.

You can manage the Advanced settings for external sharing settings here. I have explained the available options below.

Let external users shared items they don’t own: By default, it allows the external users to share the content with other users.

Allow or block sharing with people on specific domains: You can add the domains to which your organization users can share the documents.

External users must accept sharing invitations using the same account that the invitations were sent to: It is the best options to validate only the intended recipient is opening the shared content.

If you ask me, I would recommend organization’s to go with the below settings to ensure your data is on control.

Hope this is informative. We will see the external sharing with other domain and external user experience on my next post.

If you are migrating from AD RMS to Azure RMS, or fully on Azure RMS, you may end up in issue when protecting a content or when trying to open a protected content, here we will see the troubleshooting steps for Azure RMS.

Note 1: Identify the User.

During the AD RMS to Azure RMS migration, few users will be migrated as Azure ARMS users and few may still pointing to AD to have IRM functionality. If a user is complaining that, he is not able to protect or consume a content. You need to identify whether the user is AD RMS user or Azure RMS users first. It will help you to know which logs (Azure RMS or AD RMS) you have to look at.

Note 2: Basic things to validate

  1. User should reach the respective service. AD RMS user should have access to AD RMS server and Azure RMS user should have internet access to consume to Azure RMS service hosted in cloud.
  2. If user is Azure RMS user, ensure the required registry settings are properly set using Azure RMS analyzer
  3. Office should be updated with recent updates
  4. Azure Information Protection client to be latest Generally Available one.
  5. Ensure the below sites are added as trusted sites in IE.
  • https://*.azurerms.com
  • https://ecn.dev.virtualearth.net
  • https://*.microsoftonline.com
  • https://*.microsoftonline-p.com
  1. If the user is using Office 2013, ensure the Office is ADAL compliant
  2. If the user is using Office 2010, ensure the Microsoft Online Services Sign in Assistant installed

Note 3: Validate the IRM Configuration

Use Test-IRMConfiguration command after connecting to Exchange Online PowerShell or on On-Premise Exchange Management Shell. Overall list should show as PASS like below.

Test-IRMConfiguration -Sender User1@superhybridcloud.com –Recipient User2@superhybrid.com

Note 4: User is not able to protect a content

If the user is not able to protect a content, there will be only 2 possible reasons

  1. User machine not properly initialized to use the service, in other words not bootstrapped. Or
  2. User is not part of the on-boarding controlling policy or not enabled with Azure RMS license to protect the contents

Note 5: User not able to open a protected content

If the user is unable to consume a protected content, check the below things.

  1. Check whether he is able to protect a document, if not check the things mentioned in Note 3.
  2. Ensure user opening the protected content is having permission on the template that was used to protect the content

Note 6: User RMS Analyzer to check the perquisites.

For Issue related to Azure RMS, you can user RMS Analyzer to validate the Prerequisites. RMS Analyzer prompts you to choose a role before starting the perquisites check like below

If it showing Microsoft Online Sign on Assistant not installed or the SCP not registered like below, you can ignore those steps.

You can continue to check the settings that will show the things that are configured as part of bootstrapping.

For any reason if you are not able to identify the issue, you can reset the settings using RMS Analyzer and the reconfigure the device with Azure RMS settings.

Note 7: Collect the Logs

You validated all the settings mentioned above still an issue, you can use the logging option on the RMS Analyzer utility and share the logs with Microsoft support to analyse the issue.

Note 8: AADRM User Log

Always good to looks at Aadrmuser log which will show the details on which stage the user not able to protect or consume a protected content.

You can connect to Azure RMS PowerShell and run the below command to get the logs. You can read the logs on your own. Few things to be analysed only by Microsoft support, you can share the logs with them.

Get-AadrmUserLog -ForDate 1/22/2018 -Path c:\temp

Hope this post is useful for troubleshooting the Azure RMS related issues.

Once you activate Azure Information Protection service on your Office 365 Tenant, you can manage Azure RMS service by connecting through PowerShell. Below show how to connect Azure RMS service using PowerShell.

As prerequisites, you need to install Azure Rights Management Administration Tool, which can be downloaded from here.

Note: To Install Windows PowerShell for Azure Rights Management, you need Windows PowerShell 2.0 or above and .Net FrameWork 4.5.

Once the Windows PowerShell for Azure Right Management Installed, you can connect to Azure RMS service using below command.


After entering the credential, you will be connected to Azure Right Management Service and you can manage Azure RMS now.

We saw the Azure AD sign-in options in the last post and here we will see the difference between Federation Authentication, Password Hash Sync Authentication and Pass-through authentication.



Password Hash Sync


ADFS Requirement

ADFS & WAP servers are required

Not Required

Not Required

AD Connect Requirement




AuthN Agent



Yes. Installed on AD Connect server or member server

How it works

Azure AD redirects you to ADFS as the authentication domain configured as federated domain. ADFS server authenticate the user with AD and return a security token to authenticate with Azure AD

AD Connect sync the Hash of the Password Hash in Azure AD and Azure AD accepts both the user name and password validate it with the synced hash.

Azure AD accepts the user name and password and send it On-Premise AuthN agent server which will authenticate with AD and return the successful authentication to Azure AD

Single Sing On (SSO)

Yes, via On-Premise AD credential


Requires seamless SSO enabled

Seamless SSO

Yes, when device connected to AD

Yes, when device connected to AD

Yes, when device connected to AD

Password Remains

In On-Premise

Azure AD

In On-Premise

MFA Support

On-Premise ADFS or through Azure AD

Azure AD

Azure AD

Conditional Access

On-Premise ADFS or through Azure AD

Azure AD

Azure AD

HA for Authentication

Depends on the ADFS infrastructure

Available in azure AD

Depends on AuthN agent deployments

Account lockout in On-Premise

Immediate effect

Still be active in the cloud

Immediate effect

Disable On-Premise AD Account

Reflect when sign-in occurs

Reflect to Azure AD on the next sync cycle

Reflect when sign-in occurs

Authenticates to Azure AD

Security Token from ADFS

User Name & Password

Kerberos Token


  • Password maintained in On-Premise
  • On-Premise MFA
  • On-Premise Conditional Access Support
  • Seamless SSO.
  • Cost effective & Easy to deploy
  • Cloud Authentication & scalability
  • Identity Protection
  • User to remember one password
  • Ability to login cloud service even if AD down.
  • No need of ADFS deployment
  • Cloud Authentication
  • Seamless SSO.
  • Simple deployment of AuthN agent.
  • HA for AuthN agent.
  • Automatic certification roll over


  • Doesn’t provide cloud authentication scalability.
  • Identity Protection required P2 License.
  • SSL requirement.
  • Authentication prompt when switching applications.
  • No granular logon restrictions.
  • Azure AD Premium license required for self-service password reset.
  • HA to be setup On-Premise
  • Password gathered at Azure AD

Above are the difference between the Azure AD authentication options. Hope this is informative. Learn more about the sign-in options

In this post, we are going to discuss the Azure AD sign in option available to access the claims aware application like Office 365. Below are the four sign-in options available when accessing a Microsoft cloud application or any claims aware application integrated with Azure AD. We will see how the sign-in options work in short on this post and a detailed explanation for each authentication in separate post.

  • Federation Authentication
  • Password Hash Synchronization Authentication
  • Pass-through Authentication
  • Seamless SSO (enabled when choosing PHS or PTA)

On the Azure portal under AD Connect, you can see the authentication options.

Federation Authentication:

Most of the Companies preferred to use federated authentication. When the federation sign in option enabled, the domain used for authentication will be configured as federated domain in Azure AD. Below shows the authentication flow for federation sign-in

How it works?

To explain the Federation Sign-in flow, when you access any claims aware application that trusts Azure AD as the STS, the application will redirect you to authenticate with Azure AD, Azure AD prompts you to login with the user name option only and when you enter the user name, the domain validated whether it is a federated domain. Since it is a federated domain, you are redirected to On-Premise ADFS infrastructure, (to WAP server if you are in Internet and to ADFS server if you sign-in from Intranet). ADFS prompts you to enter the user name and password passed and it authenticates with Active Directory. On successful authentication with AD, ADFS send a Security token to User that will be send back to Azure AD for successful authentication.

Note: You need to maintain a ADFS infrastructure to have this federation sign-in option and it is having additional benefits like you use On-Premise MFA server for multifactor authentication.

You can look for below authentication options which won’t cost you much and AD connect server will help you to meet your requirement.

Password Hash Synchronization Authentication:

No need to confuse about the Password Synchronization option, we are not directly synchronizing the password from On-Premise to Azure AD. Only the Hash of the Password hash synchronized with Azure AD using Azure AD connect.

How it works?

When Password Hash Synchronization authentication enabled for the tenant, Hash of the password hash is available in Azure AD after Synchronization. If a user access a Azure Integrated application, user redirected to authenticate with Azure AD, Azure AD prompt the user to enter the credential, both user name and the password will be entered in Azure AD authentication dialogue window and it will be validated against the hash Synced in Azure. If successful, user will be provided security token to the authenticate the service\application. Switching from one application to other, prompts the user to validate the credential when this sign-in option used.

Pass-through Authentication:

If we use the Pass-through authentication, user name the password will be gathered in Azure AD but Passwords validated in On-Premise AD. AuthN Agent configured in AD Connect or any member server supports this Pass through Authentication. Below shows the pass-through authentication flow.

How it works?

When user access any office 365 application, it will redirect the user to Azure AD for authentication, Azure AD prompt the user to enter both the user and password and it will be sent to AuthN agent server in On-Premise using a securing tunnel established when configuring the AuthN agent. AuthN agent component validate the user name and password with Active Directory using a Win32 API call to Active Directory and the successful authentication will be sent back to Azure AD. Azure AD authentication successful and send a security token to access the application, the user will gain access to Application.

Seamless Single Sign-On Authentication:

Seamless SSO works with Password Hash Synchronization and Pass-through authentication. For the seamless SSO to work, the machine has to be domain joined and should have access to AD. Machine authenticates with Azure AD using Kerberos token.

How it works?

When Seamless SSO enabled, new computer object created in AD that holds 2 SPN for authentication with Azure AD. Let us take User access a claims aware application, user will be redirected to Azure AD for authentication, Azure AD instructs the client to do a authentication test to find the client is SSO capable and it will send a unauthorized response and to get a token a token from AD. Client requests a Kerberos token ticket from AD and the same will be send it to Azure AD, Azure AD returns a security token which will sent to application and the authentication will be successful.

If Seamless SSO fails, the other enabled option PTA or PHS will be used for authentication.

I hope this post is informative to you.

Soft deleted mailboxes will be available for 30 days. If the mailbox available in soft deleted state then we can restore the mailbox.

We can view whether the mailbox is in soft deleted state using the below command

Get-Mailbox UserID –Softdeleted

If it is available as a soft deleted mailbox, then we can run the below command to restore the mailbox.

New-MailboxRestoreRequest -SourceMailbox <GUID from above step> -TargetMailbox <GUID from new target mailbox you’ve created>

Wait for the restore to happen in the backend. To check the restore request status, you can run the below command

Get-MailboxRestoreRequest –Identity MailboxRestoreRequest1

Exchange Online made the soft deleted mailbox very simple. You can follow the above steps to restore a soft deleted mailbox.