DEEP DIVE + Azure Management PREVIEW: Office 365 Analytics

This article shows you how to connect your Office 365 organization to an existing or new Azure Log Analytics workspace and begin to centrally monitor and alert on events occurring in your Azure AD, Exchange online and SharePoint online services. This capability for Microsoft customers can consolidate and elevate more enterprise health and security data into the Azure portal.

The Challenge of Meaningful Office 365 Monitoring

How to effectively monitor Office 365 services is a common ask from IT stakeholders. Monitoring Office 365 means a different thing to different people and varies from a simpler ask, like making sure Outlook web URL is available to log into, to more sophisticated tasks like alerting on security sensitive incidents. In essence an organization can be paying a decent amount of money on cloud services, and have many or most business critical processes dependent on those cloud services, and legitimately want to put up some guard rails and sensors.

What’s been tried

Making sure what you paid for is available is fundamental, and there is an expectation that cloud services will be delivered with performance and configuration as expected per service level agreements (SLAs). How to detect a departure from expected service delivery is a tactical business need. How to leverage the power of the cloud for data aggregation and analysis that supports decision making is strategic.

There are a number of ways to report on and even alert on Office 365 usage, especially by relying on the built-in Office 365 Audit Logging and email-alerts available at Microsoft 365 Admin Center -> Security & Compliance. Limitations of that approach include depending on ‘yet another portal’ to interact with daily, and the only alerting action being email to Exchange email recipients in your organization. That approach doesn’t scale or play well with existing ITSM workflow for incident ticketing and support.

Other tools

Microsoft provides a very simple O365 management pack for System Center Operations Manager (SCOM) that monitors just two things: O365 support incidents submitted by the customer and known service outages in Microsoft regions. There are many community and paid SCOM management packs to help out, with most being oriented towards mail flow and O365 license status. An Internet search for Office 365 monitoring will return many hits from many solution providers.

Why it’s hard: The nature of having to log into O365 services, with a licensed and authorized Azure AD or Microsoft credential, in order to test the user experience makes ‘rolling your own’ O365 monitoring solution based on synthetic logins difficult for non-developers.

Bringing O365 Log data into Azure Log Analytics

A newly re-issued preview solution from the Microsoft Management folks is available to try out: the Office 365 management solution in Azure (Preview). This solution replaces an earlier one with similar functions, but using newer methods than expose more data. This solution surfaces log and audit data from your Office 365 organization in the Azure portal. Figure 1 shows the solution in an Azure Log Analytics workspace dashboard.

Figure 1 – The Overview blade of the Office 365 Analytics (Preview) Solution

Understand this is not a performance monitor for O365 services, but rather a way to ‘plug into’ the data stream of your O365 organization in a way that lets you spot anomalies and trends. The data is processed in near real time, enabling valid rapid response scenarios to widespread user issues and security-impacting incidents. Azure Automation monitors can watch for conditions representing anomalies and incidents and launch a comprehensive response within a few minutes of their occurrence.

Why it’s important: The Azure portal and its analytics, alerting, and automation resources has always been the ‘destination portal’. Rolling up impactful enterprise data into the Azure portal is hugely valuable where it can be viewed and acted on in a synchronized and synthesized fashion with other enterprise cloud, datacenter, identity, and security events. An example is leveraging the Notification Action Groups in Azure Automation for centralized alert notification that can include ITSM ticketing and automated remediation.

Pre-requisites to deploy the solution

  • You will need the Organizational Office 365 subscription and credentials for a user account that is a Global Administrator in that Office subscription.
  • You will need an Azure subscription to proceed as well as an Azure Log Analytics workspace in that Azure subscription.
    • You can create these quickly if you don’t have both yet.
    • If you already have an Azure subscription and/or Azure Log Analytics workspace, make sure the Username that is an O365 administrative account is an Owner of the Azure subscription (or with appropriate subordinate rights you may engineer). Cross-subscription administrators are not supported, that is, using an Azure Log Analytics workspace in a subscription with a different Azure AD tenant than the O365 administrative account.
  • To receive Office 365 audit data, you must configure auditing in your Office 365 subscription. Note that mailbox auditing is configured separately. You can still install the solution and collect other data if auditing is not configured. Optional enable instructions are below.

Note: Multiple office subscriptions can be connected to an Azure Log Analytics workspace. However, an office subscription can only be connected to one Azure Log Analytics workspace.

STRATEGY SHIFT IN HOW TO MONITOR LIVE O365 EXCHANGE USER PERFORMANCE

Before

After

Monitor what:
Client-perspective tools making synthetic transactions
(Can you log in and send an email right now?)

Monitor what:
Event stream from cloud perspective
(You know what the expected number of emails to be sent and received each hour is)

Alert on:
Log in and/or email sending failed

Alert on:
A wide variation (too many or not enough) from normal event stream

Complications

Benefits

  1. Many moving parts to instrument both sides of an Internet email loop
  2. Only monitors one mailbox and its relevant path, not testing the whole plant in aggregate
  1. Only alerting when issue is not isolated and is essentially verified
  2. Plant in aggregate is monitored

Fundamentally: Still a tool you need to deploy

Fundamentally: Built-in telemetry ready to use

Optionally enable Office 365 and/or Exchange mailbox auditing

To enable receipt of the maximum possible data in the Azure portal from Office 365 activities, consider enabling auditing on the Office 365 side before proceeding. Office 365 Auditing is enabled in the Microsoft 365 Admin Center -> Security & Compliance -> Search & investigation -> Audit log search. Exchange auditing is enabled via Azure PowerShell.

Tip: Consider deploying the solution without enable of auditing, and then add auditing after you assess the data stream with base logging only.

Optionally enable Office 365 Auditing

Optionally update the auditing settings in your Office 365 organization. You can still install the Office 365 Analytics solution without enabling auditing but you will get less data. Figure 2 shows where to turn this on in your Office 365 Admin center.


Figure 2 – Optionally enable auditing for your Office 365 organization

When you are successful, you will get the message: “We’re preparing the Office 365 audit log. You’ll be able to search for user and admin activity in a couple of hours.”

Optionally enable Exchange mailbox auditing

Also optionally enable mailbox auditing (reference: https://docs.microsoft.com/en-us/office365/securitycompliance/enable-mailbox-auditing). This PowerShell will enable auditing on all mailboxes on your organization:

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

Import-PSSession $Session

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq “UserMailbox”} | Set-Mailbox -AuditEnabled $true

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq “UserMailbox”} | Set-Mailbox -AuditOwner @{Add=”MailboxLogin”,”HardDelete”,”SoftDelete”,”Update”}

 

To verify that mailbox auditing is enabled, run this PowerShell command, it will dump every mailbox and you can verify the “AuditEnabled” value is “True” for each mailbox:

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq “UserMailbox”} | FL Name,Audit*

To add the Office 365 Analytics (Preview) solution to your Azure subscription:    

< STEP 1> Create an Office 365 application in Azure Active Directory and Configure application for Office 365 as shown in this reference: https://docs.microsoft.com/en-us/azure/monitoring/monitoring-solution-office-365#create-an-office-365-application-in-azure-active-directory. Figure 3 shows what portal notifications to expect after you successfully create the Azure AD application (consult the Azure Log Analytics Activity Log for more details):

Figure 3 – Look for these successful notifications after enabling your Office 365 Solution

< STEP 2> Add the Office 365 Analytics (Preview) solution to your Log Analytics workspace:

  1. In the Azure Portal (https://portal.azure.com) Navigate to New -> Marketplace -> Management Tools -> Office 365 Analytics (Preview) and press Create.
  2. Select an existing OMS Workspace and OMS Workspace settings.
  3. When successful, you will note a message on the solution tile that it can take up to 24 hours for data to appear.

< STEP 3> Prepare the following information needed to run the installation scripts (the scripts take this information as inputs):

From your Log Analytics workspace:

  • Workspace name: The workspace where the Office 365 data will be collected
  • Resource group name: The resource group that contains the workspace
  • Azure subscription ID: The subscription that contains the workspace

From your Office 365 subscription:

  • Username: Email address of an administrative account
  • Tenant ID: Unique ID for Office 365 subscription (also known as Directory ID in your Azure AD Properties)
  • Client ID: 16-character string that represents Office 365 client (also known as the Application ID at Azure AD -> App registrations -> Office 365 Solution)
  • Client Secret: Encrypted string necessary for authentication (copied out during setup of the Office 365 Solution app)

< STEP 4> Copy the following two files from the reference site to a working directory on an Azure PowerShell computer:

https://docs.microsoft.com/en-us/azure/monitoring/monitoring-solution-office-365#create-an-office-365-application-in-azure-active-directory

  • office365_consent.ps1
  • office365_subscription.ps1

< STEP 5> Run these PowerShell commands, entering the Azure login for the O365 Administrator account each time you are prompted:

.\office365_consent.ps1 -WorkspaceName DefaultWorkspace-073dc83b-xxxx-xxxx-874d-0dee1ec9a39d-EUS -ResourceGroupName defaultresourcegroup-xxx -SubscriptionId 073dc83b-xxxx-xxxx-874d-0dee1ec9a39d

.\office365_subscription.ps1 -WorkspaceName DefaultWorkspace-073dc83b-xxxx-xxxx-874d-0dee1ec9a39d-EUS -ResourceGroupName defaultresourcegroup-xxx -SubscriptionId ‘073dc83b-xxxx-xxxx-874d-0dee1ec9a39d’ -OfficeUsername ‘jjoyner@jajoyner.onmicrosoft.com’ -OfficeTennantID ‘4cc06a39-xxxx-xxxx-a931-d7a6018f8b45’ -OfficeClientId ‘f0e089fd-xxxx-xxxx-883f-df886418d222’ -OfficeClientSecret ‘g1zwxxxxPhDxxxxseL/kApxxxxovuWrO9wG8HckOxxxx’

< STEP 6> After some hours, the solution will begin to display data. Click on the Office 365 solution tile to open the solution dashboard as seen in Figure 4:

Figure 4 – The Office 365 solution dashboard

<STEP 7> The solutions dashboard in Figure 4 summarizes all operations in the left-most blade column. The three columns moving right summarize Exchange, SharePoint, and Azure AD activities. The green arrows and boxes demonstrate how the solution surfaces valuable log data such as Mailbox logins, SharePoint page views and file accesses, and Azure AD successful and failed user logins. Let’s say you were interested in seeing what SharePoint files were accessed, clicking on that dashboard item opens the log view seen in Figure 5:

Figure 5 – Drill down into a specific O365 activity yields lots of data

< STEP 8> You can create Azure Log Analytics queries for data analysis and/or for alert creation that key on the presence of or absence of any activity data during any desired timeframe. Just like all your other enterprise data pouring into Azure Log Analytics, you now have visibility of some useful Office 365 activities co-located with your other log and analysis tools and solutions in the Azure portal.

Tags: #MVPBuzz #AzureLogAnalytics #Office365 #PowerShell #sysctr #SCOM #AzureMonitor #Azure #LogAnalytics

4 thoughts on “DEEP DIVE + Azure Management PREVIEW: Office 365 Analytics

  1. hello, useful article thank you. Is it possible to have an separate Azure Tenant connect to the Office 365 API of a separate tenant? Your post indicates it is not possible, but then the next sentence seems to suggest it is possible so was just seeking some clarity.

    Suggests not possible:
    Cross-subscription administrators are not supported, that is, using an Azure Log Analytics workspace in a subscription with a different Azure AD tenant than the O365 administrative account.

    Suggests is possible:
    Note: Multiple office subscriptions can be connected to an Azure Log Analytics workspace. (Multiple Office Subscriptions would have separate Azure AD, and thus the idea of ‘Cross subscription’ administrators would have to be re-introduced)

    I have an on-premise SIEM. I need to get compliance data out of Office 365 into the on-prem SIEM. The basic workflow is 365 API > Log Anaytics Workspace (sep tenant) > Event Logs > Azure Function > On-Prem SIEM.

    If a CSP has multiple 365 customers / tenant and wants to provide a central SIEM solution (Azure Sentinal is a possible but its another subject), the ideal is to have those 365 Tenants publish API permissions so that the central Azure tenant can collect logs and then send those logs to a central SIEM on premise.

    The main question here though, is to clarify, can you use separate tenants or not. Many Thanks

    1. Hi Stuart:
      My experience is that the O365 administrator account has to be in the same AD tenant associated with the Azure subscription of the Log Analytics workspace, sorry if that was unclear.
      Significantly however, the “Office 365 management solution in Azure” is essentially deprecated in favor of connecting O365 to Azure Sentinel.

      Official from Microsoft: “The recommended method to install and configure the Office 365 solution is enabling the Office 365 connector in Azure Sentinel instead of using the steps in this article. This is an updated version of the Office 365 solution with an improved configuration experience. To connect Azure AD logs, use the Azure Sentinel Azure AD connector, which provides richer log data than the Office 365 management logs.”

      The connection between O365 and Sentinel is easy to make and Sentinel is free during the preview period. I recommend investing only in that avenue. As for the ability for a service provider to manage Azure Sentinel on behalf of multiple customers, I fully expect Microsoft has a delegated administration model on their road map to support that. So nothing to lose by investing in Azure Sentinel now.

      John

Leave a Reply to jjoyner Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.