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 -Credential $cred -Authentication Basic -AllowRedirection

Import-PSSession $Session

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

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.

Deleted SharePoint Online Site collections will be available in recycled state for 30 days and the deleted SharePoint site collection will be permanently deleted. Using SharePoint Online PowerShell, we can view the deleted SharePoint Site collection and restore the deleted SharePoint Site Collection.

To view the deleted SharePoint Site Collection, we can run the below command


Status of the deleted site will show like recycled

Get-SPODeletedSite | FL Status, DaysRemaining

To view the deleted OneDrive Personal Site

Get-SPODeletedSite –IncludePersonalSite:$True

To Restore the deleted SharePoint Online Site Collection, we can run the below command

Restore-SPODeletedSite -Identity

Hope this post is informative. Leave your comments if any assistance required.

Configuring OWA session timeout is an important security measure that every organization should follow to keep Organizations data safe. Below the default session time out settings for Outlook Web Access (OWA) or Outlook on the Web (OotW).

OWA forms based authentication provides 2 option to choose whether you logged in from a Private or Public computer. OWA session time out depends on user’s selection.

  • If it is a Private computer – OWA session time out at 15 minutes of inactivity
  • If it is a Private computer – OWA session time out at 8 to 12 hours of inactivity

Make a note of the word 15 minutes of inactivity. Session will time out only when there is no activity at outlook web access.

Note: Typing something in meeting requests, appointments contacts, or tasks is not considered as an activity.

Your Corporate Security may advice you to configure a session time out based on the security concerns like every 15 minutes or two hours once etc. and to change the settings, you should have Organization Administrator rights in Exchange Online and you need to run the below command.

Set-OrganizationConfig -ActivityBasedAuthenticationTimeoutEnabled:$True -ActivityBasedAuthenticationTimeoutWit hSingleSignOnEnabled: $True -ActivityBasedAuthenticationTimeoutInterval 00:15:00

You have to wait for quite some time for the settings to replicate and You can run the below command to check the settings are properly configured.

Get-OrganizationConfig | fl Activity*

Ultimate aim of this post is that, when you are setting OWA session timeout for lesser interval and configured Azure Conditional Access Policy to trigger MFA when accessing Exchange Online Mailbox in OWA, users experience will be affected as every time they have to Key in MFA challenge when logging in OWA.

Educate your users about the 15 minutes OWA session time out settings and your MFA challenge settings and if they are the user where they will access only OWA to see their emails, then ask them to check the option not to prompt for MFA challenge for next 24 hours.

Again, if you think it is a security concern, discuss with your corporate security about the challenge and decide a solution considering user experience and security measures.

Hope this is informative and you like it.

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.

Let us assume that Exchange Hybrid Organization pointed its MX record to Office 365 or Exchange Online Protection, the mail flow works as shown in the below diagram.

In this article, we will see how the inbound and outbound flow works when the email routing configured to route through Exchange Online Protection.

Inbound Mail Flow

MX record point towards Office 365 Tenant -> Exchange Online Protection will receive the email and it will do the Recipient validation using Directory Based Edge Blocking, if the recipient is not available email will be dropped -> Anti-Virus scanning will occur, EOP has 3 AV engines -> Recipient resolution will occur like distribution group expansion -> Transport Rule will be applied, if any marked as SPAM using Transport rule then those emails will be quarantined -> Anti-Spam Protection will occur which includes, content scanning, outlook safe sender validation, URL blocking, bulk mail filtering, international spam filtering – > customer delivery pool and then to On-Premise Server.

Outbound Mail Flow

Office 365 or On-Premise user send an email -> Virus Scanning will occur -> Recipient Resolve -> Transport Rules -> SPAM Protection -> Outbound Delivery Pool -> Recipient MX resolution -> Recipient domain.

If an outbound email identified with high SPAM score, then it will delivered via high-risk delivery pool.

Above are the high level illustration of how the mail flow works in Office 365.