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.

Connect-AadrmService

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.

 

Federation

Password Hash Sync

Pass-Through

ADFS Requirement

ADFS & WAP servers are required

Not Required

Not Required

AD Connect Requirement

Yes

Yes

Yes

AuthN Agent

No

No

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

No

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

Advantages

  • 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

Disadvantages

  • 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.

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

Get-SPODeletedSite

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 https://superhybridcloud.sharepoint.com/sites/specialpay

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

OneDrive for Business Online report helps organization to view the OneDrive Usage details and if any sharing capabilities are restricted or allowed only to few domains, then the OneDrive for Business Online report shows the details on, to which domain sharing capabilities enabled for a User.

Connect to SPO Service in PowerShell and run the below command to generate one drive details

-IncludePersonalSite Parameter shows only the personal site (OneDrive sites) details in the SharePoint Online Tenant.

If you are having more than 200 users in your organization, then you need to run the below command to get all the OneDrive site details. By default, only 200 users details will be pulled.

In addition, we can pass a filter like below and export the results to CSV file

Output file will look like below

You can do a filter and see the required results on the output.

We may have a requirement to see the OneDrive site details of a user, we can see the details of the OneDrive site for the user in PowerShell by using the below command.

Get-SPOSite -Identity https://superhybridcloud-my.sharepoint.com/personal/Raj_superhybridcloud_com

Identity of an OneDrive site will be like below in SharePoint Online. You can construct your OneDrive site collection Url by referring the below

https://superhybridcloud-my.sharepoint.com/ – Tenant Name followed by my.sharepoint.com

/personal/ – it is a personal site collection

/Raj_superhybridcloud_com – User Principal Name of a user like ID@companyname.com, and we need to call it as id_domainname_com

Identity = https://superhybridcloud-my.sharepoint.com/personal/Raj_superhybridcloud_com

In addition, we can view the full details about the one drive site of a user using below command.

Get-SPOSite -Identity https://superhybridcloud-my.sharepoint.com/personal/Raj_superhybridcloud_com | fl

Hope this is informative J

Generating report on SharePoint Online Site collection is easy, you can run the below command to export the report.

Connect to SharePoint Online Management PowerShell and run the below command

Get-SPOSite -Limit All | export-csv C:\Temp\SPOsite.csv -NoTypeInformation

Output will be like below and you can filter based on your requirement

All the information about the Site collections in your tenant will be available in the output.

We can quickly view the SharePoint online management shell version using below command

Get-Module *Sharepoint* | fl

In addition, we can see the version number of this file to know the SharePoint Online Management Shell

C:\Program Files\SharePoint Online Management Shell\Microsoft.Online.SharePoint.PowerShell\Microsoft.Online.SharePoint.PowerShell.dll

Why it is required?

Microsoft may say that few things will work only on a particular PowerShell version. So better to know which version of the SharePoint Online Management shell you are using.