My Analytics, Workplace Analytics & Delve - or from the backend perspective Office Graph & Microsoft Graph

The analytics features in Microsoft 365 remain a sensitive topic for works councils and data privacy officers. This article describes the options currently available to customize these apps.

Overview and history of Office Graph & Microsoft Graph

At the time of its initial release in 2014, Office Graph was the backend for Delve, among other things. The Office Graph has since evolved and the Microsoft Graph was joined. To provide a coherent Microsoft Graph schema, Microsoft introduced an itemInsights entity that inherits all the properties of the existing officeGraphInsights resource. Currently, for backward compatibility reasons, the officeGraphInsights entity is still available. Generally, the "insights" generated by the Microsoft Graph can be disabled for the entire tenant or per Azure AD group in the Admin Center:

More details about this and the options with PowerShell / API are described in this Microsoft article: Customizing item insights privacy in Microsoft Graph. Currently, August 2021, the options described in the article are still in "Preview" status.

The apps My Analytics, Workplace Analytics & Delve

All three apps aggregate and analyze users' actions in Microsoft 365 to give individual users a system-wide view of what's happening in Microsoft 365.

Delve: The Delve app mines all documents that a user is actively working on and attempts to analyze correlations between their own work and that of other users. The goal is to show users correlations and common work areas with other users. The following always is true:

• Security by Design. Everyone only sees what they have access to.
• Private signals can only be seen by the person himself, e.g. which content might be interesting for him. This cannot be impersonated in the sense of: please show me what is interesting for John Doe.
• Public Signals only show what can also be found in other ways, e.g. via search.

Delve can be customized by each user: The "Show Documents in Delve" setting is available at the following link: https://delve.office.com/ 

If a user deactivates this function, however, his signals are still collected by the Office Graph / Microsoft Graph and are available to other users who also have access to the affected documents. Only the user himself will not see any reports about the documents he is working on or has access to after deactivation.

The Office Graph / Microsoft Graph also creates the overview and reports for the user under office.com and in apps like Outlook or Microsoft Teams. The following functions / customizations are available here:

• Meeting Insights: When a user calls up an appointment in their calendar, Outlook displays other content relevant to that appointment. This can include mails and files in the mailbox, files from OneDrive or SharePoint for which the user has at least read permission. Meeting Insights can currently only be switched on or off for the entire tenant.
• Item Insights: This feature creates recommendations based on user interaction/common tasks in Microsoft 365. These recommendations can include documents or other types of content and are displayed in People Cards (Contacts), Delve, Office.com, and other locations. Item Insights can be turned on or off per Azure AD group.

The Office Graph can also be disabled completely, as described here: Control access to Delve. This will then affect many other features such as:

• SharePoint Home
• SharePoint Activities
• OneDrive Suggestions
• Copy / Pats Functions
• etc.

My Analytics: My Analytics creates an overview of the complete working day and provides reports on how long the user has spent on mails, meetings and other things. The My Analytics function can be controlled via the license. If a user is not assigned the license for this app, the function is not available.

My Analytics, like the Delve app, cannot be impersonated and reports are only available to the individual user to view

The My Analytics app can also be configured per user:

The following applies here:

• If the app as a whole is deactivated, the user will no longer be able to access his dashboards in My Analytics. The Insights Outlook add-ins are then also no longer available.
• Inline suggestions and weekly digests will no longer be generated.
• Email activity will no longer be included in the count for other users' email open rates.

Workplace Analytics: In Workplace Analytics, data from daily work in Microsoft 365 is used to identify patterns. Data protection is considered here by default, by only presenting data anonymized and aggregated at the group level.

The Workplace Analytics function can also be controlled via the license. If a user is not assigned the license for this app, his data will not be collected and analyzed. Workplace Analytics can currently only be licensed via an EA. For details, see: Requirements for Workplace Analytics

Workplace Analytics offers the following options for configuration:

• Sources: Administrators and analysts use these to verify that Microsoft 365 and organizational data has been uploaded correctly to Workplace Analytics.
• Upload: Administrators use this to prepare and upload organization and customer data.
• Administrator Settings: Administrators use this to configure system default settings, privacy settings, and manager settings.
• Analytics Settings: Analysts use this to customize meeting exclusion rules that help ensure data accuracy.

Details: Workplace Analytics Settings

By the way: The Viva Insights feature also uses data from the Microsoft Graph, combines it with its AI and creates the corresponding dashboard. The apps My Analytics and Viva Insights will be merged in the future:

Source: https://docs.microsoft.com/en-us/workplace-analytics/myanalytics/mya-landing-page

Guest users in Azure AD - available options and scenarios

The easiest way to give an external person access to a Microsoft 365 service is to invite him as a guest user via Azure AD. If an external person is invited directly via Teams, SharePoint, PowerBI, etc., this also automatically results in a guest user in Azure AD.

However, this is not the only option. Technically, there are different ways to do it:

1. A user is invited as a guest. The authenticating instance is either another Azure AD, or an IDP supported by Azure AD. Well known examples are Google and Facebook. More details are described here: Identity Providers for External Identities
2. The second option is that the user is created in the local AD or in the Azure AD. This is the case if customers or partners already have accounts in the local AD that should now also be used to access cloud resources, or if a company wants to manage guest users completely itself. The IDP is then also the own AD / Azure AD for the guest user.
3. A guest user who logs in via one-time passcode. Details are described in this article: Onetime Passcode Authentication to access Microsoft 365 Group resources

In Azure AD's, a guest user from the first or the third scenario technically looks like this: John.Smith_gmail.com#EXT#@tenantname.onmicrosoft.com. However, the user logs in normally as John.Smith@gmail.com.

A user created via the second scenario, however, also technically has a UPN that follows the "normal" layout: Jane.Doe@tenantname.onmicrosoft.com.

What makes a user a guest user?

Which instance does the authentication says nothing about whether a user is technically a guest user or a member. The value "UserType" which can be set via PowerShell determines whether an account is defined as a guest or as a member.

Example:

Connect-MsolService

Set-MsolUser -UserPrincipalName "John.Smith@gmail.com" -UserType Member

This makes the user John.Smith@gmail.com, who was invited as a guest, a full member in Azure AD. This user can now also be added to a Microsoft Team as a member or owner.

The other way a user from the on-premises AD or Azure AD can be configured as a guest user.

Example:

Connect-MsolService

Set-MsolUser -UserPrincipalName "Jane.Doe@tenantname.onmicrosoft.com" -UserType Guest

When a user is changed from a guest to a member, he must also be licensed. If a user is newly created or synchronized via AAD Connect, it is always a member of Azure AD. Via "-UserType Guest" he can be turned into a guest account and does not need to be licensed anymore.

Microsoft article about this:

• Grant locally-managed partner accounts access to cloud resources using Azure AD B2B collaboration
• GitHub - external-identities/invite-internal-users.md

Examples

Example 1 - Account in Azure AD is reconfigured from member to guest user:

Example 2 - Account in Azure AD is reconfigured from guest user to member:

Use app enforced restrictions vs. Use Conditional Access App Control

Blocking downloads or at least blocking them on unmanaged devices is a common requirement in the context of Microsoft Teams and SharePoint. Different features can be used to implement such requirements.

App Enforced Restrictions

Generally, these settings can be configured in the SharePoint Admin Center:

If this setting is used, the system automatically creates two conditional access policies in Azure AD:

These policies can be customized and thus also used as a starting point for a more detailed conditional access policy that, for example, only applies to selected users or groups.

The first screenshot above also shows the following message: We will automatically change the "Apps that don't use modern authentication" setting to block access (because these apps can't enforce this device-based restriction). The background is that apps that do not use modern authentication cannot enforce any device-based setting. If such apps remain allowed, the created conditional access policies can be bypassed.

Another information in the screenshot above makes clear that not all detailed settings are available via the UI in the SharePoint Admin Center: "If you don't want to limit or block access organization-wide, you can do so for specific sites". The link behind "Learn how" is to the documentation of the options via PowerShell.

Example: Set-SPOSite -Identity https://<SharePoint online URL>/sites/<name of site or OneDrive account> -ConditionalAccessPolicy AllowLimitedAccess

Options with Sensitivity Label

The solution via Sensitivity Label means that the settings in the SharePoint Admin Center are no longer used. The label offers the same options as for example "Allow limited, web-only access":

This setting has the following effect both in the SharePoint Admin Center and in the label configuration:

Users on unmanaged devices can only access the designated website through the browser, without being able to download, print, or sync files. They also cannot access content through apps, including Office desktop apps.

In this scenario, the corresponding label is assigned to one or more SharePoint sites. The label then enforces the configured setting. If the label and the settings in the SharePoint Admin Center conflict, the label wins.

With both options, it is thus possible to prevent downloading content from pages explicitly configured using PowerShell or labeled with a sensitivity label that enforces web-only access. It may take 5-10 minutes for the policy to take effect. It will not take effect for users who are already signed in from unmanaged devices.

Limitations of the solution with App Enforced Restrictions

The following restrictions apply when using App Enforced Restrictions:

• If you limit access on unmanaged devices, users on managed devices must use one of the supported OS and browser combinations, or they will also have limited access.
• If you limit access and edit a site from an unmanaged device, image web parts won't display images that you upload to the site assets library or directly to the web part.
• If you're using classic SharePoint site templates, site images may not render correctly. This is because the policy prevents the original image files from being downloaded to the browser.
• When Access Control for Unmanaged Devices in SharePoint is set to Allow limited, web-only access, SharePoint files cannot be downloaded but they can be previewed. The previews of Office files work in SharePoint but the previews do not work in Microsoft Yammer.

Use Conditional Access App Control

To create rules more granular / with advanced options, "Block Download" can also be enforced with Cloud App Security. This is done by using the "Conditional Access App Control" options in Conditional Access in Azure AD:

Cloud App Security then acts as a broker that is in front of the access to Office 365:

This also allows scenarios such as assigning a sensitivity label as soon as a document is downloaded.

Further options:

• Add file filters to the policy: Extension, File Name, File Size, Sensitivity Label
• Inspection Method: Can be used to configure include or exclude conditions 
• Actions: Block, Protect (Apply sensitivity label to downloads & monitor all activities), require step-up authentication like MFA etc.,
• Configure Alerts

Further details and how to implement the solution are described in this blogpost: Secure your environment by Conditional Access & App Controls

What is the difference between "Use app enforced restrictions" and "Use Conditional Access App Control"?

If the focus is only to prevent downloading on a unmanaged device, this can be achieved with both methods. The method via Microsoft Cloud App Security offers more detailed options, is not limited to SharePoint and Exchange, and does not have the limitations of App Enforced Restrictions. (see Limitations of the solution with App Enforced Restrictions) Another significant difference is the license required in each case. App Enforced Restrictions in combination with Azure AD Conditional Access required only an Azure AD P1 license. The Conditional Access App Control solution requires a Cloud App Security license for all affected users.