Limiting Data

Following on the Dutch report slamming Microsoft for potential GDPR violations in how it deals with personal data extracted from Office and Office 365, my thoughts turned to how you can stop some of the data flows.

Lots of Workloads, Lots of Audit Data

No control is possible over the internal telemetry Office 365 apps send back to Microsoft. All we can think about is the switches and controls available in Office 365. One problem that’s immediately apparent is the sheer number of workloads. If you look at the events ingested in the Office 365 audit log, we get:

• Exchange Online.
• SharePoint Online.
• OneDrive for Business.
• Teams.
• Planner.
• Yammer.
• Azure Active Directory.
• Power BI.
• Office 365 eDiscovery.
• Stream.
• Flow.
• Kiazala.
• Dynamics 365.

The wide spectrum of activities encompassed in the list partially explains the 20 to 30 different engineering groups who are interested in the Office events mentioned in the Dutch DPIA report.

Pause the Audit Log

You can stop information flowing into the Office 365 audit log by running the command

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $False

This pauses ingestion into the audit log. However, my belief is that the pre-ingestion events stay in the generating workload. For example, if Teams generates an audit event when a new channel is added to a team, that event is stored somewhere in the Teams Azure service before the Office 365 audit log ingests it. If ingestion is stopped, the Teams events are still in Teams.

Exchange Mailbox Auditing

There’s no documentation about how to stop audit events accumulating in many of the Office 365 workloads. You can disable mailbox auditing in Exchange Online by running the command:

Set-OrganizationConfig AuditDisabled $True

However, this only controls mailbox auditing and has no effect on administrative auditing.

SharePoint Online

The documentation for SharePoint Online auditing describes how SharePoint generates data for the Office 365 audit log, but is unclear what might happen if ingestion to that log is paused. It might be that SharePoint reverts to legacy audit data collection, but there’s no certainly on the matter.

A setting in the SharePoint Online Admin Center allows control over the Office Graph (now the Microsoft Graph) by stopping SharePoint capturing information about how people interact with documents. If you turn this off, Office 365 features that depend on the Graph (like Delve) are a lot less effective.

Azure

Azure Active Directory is critical to Office 365 and every tenant uses a free instance as its directory service. Azure Active Directory retention policies state that data is held for between 7 and 90 days depending on its type and your licenses.

As for the rest of Azure, a lot of information is logged and there doesn’t seem to be much control at a tenant level over what’s stored and how long storage lasts.

Work to Do

This note only scratches the surface of the work that would need to be done by an Office 365 tenant to understand exactly what data flows due to auditing activities to Microsoft and what that data might hold in terms of personal data under GDPR. And then to decide what to do if they wanted to limit some of those flows.

I’m not advocating that any Office 365 tenant should disable audit logging for any workload. Too much value is to be gained from analyzing the content of the Office 365 audit log to understand what happens in the tenant, how users behave and misbehave, and the course of events that might need to be documented (here’s an example).

Your Data. You Own It

One thing’s for sure. Microsoft has some work to do to deliver the commitment made in the Office 365 Trust Center where they say:

With Office 365, it’s your data. You own it. You control it.

What we need is true control for customers over the information gathered from across Office 365 about user activities and stored in Microsoft databases. It will be interesting to see how Microsoft seeks to assuage the issues raised in the Dutch DPIA over the coming months.

For more information about the Office 365 audit log, read Chapter 21 of the Office 365 for IT Pros eBook.

The post Restricting the Flow of Audit Data for User Office 365 Activities to Microsoft appeared first on Office 365 for IT Pros.

Creating New Teams is Easy

New teams can be created in a variety of ways – through a Teams client, via PowerShell, or by using the Graph API.

If you create a team via a client, the person creating the team is automatically added as the owner. Their account is also added to the membership of the underlying Azure Active Directory (and Office 365) group. Teams masks this fact by only ever displaying the owner entry if you check using a client or PowerShell.

For instance, here’s a small team with 1 owner and 3 members as viewed through the Teams client:

Examining Team Membership

If we look at the membership of the team via PowerShell, we see the following:

Get-TeamUser -GroupId eba86b74-aef7-4a6b-aa8a-b9769e97716e -Role member

UserId User Name Role
------ ---- ---- ----
d36b323a-32c3-4ca5-a4a5-2f7b4fbef31c Kim.Akers@office365itpros.com Kim Akers member
a3eeaea5-409f-4b89-b039-1bb68276e97d Ben.Owens@office365itpros.com Ben Owens (Business Director) member
c6133be4-71d4-47c4-b109-e37c0c93f8d3 Oisin.Johnston@office365itpros.com Oisin Johnston member

Get-TeamUser -GroupId eba86b74-aef7-4a6b-aa8a-b9769e97716e -Role owner

UserId User Name Role
------ ---- ---- ----
eff4cd58-1bb8-4899-94de-795f656b4a18 Tony.Redmond@office365itpros.com Tony Redmond owner

But if we examine the membership via Azure Active Directory, we see:

Get-AzureADGroupMember -ObjectId eba86b74-aef7-4a6b-aa8a-b9769e97716e

ObjectId                             DisplayName                   UserPrincipalName                  UserType
--------                             -----------                   -----------------                  --------
eff4cd58-1bb8-4899-94de-795f656b4a18 Tony Redmond                  Tony.Redmond@office365itpros.com   Member
d36b323a-32c3-4ca5-a4a5-2f7b4fbef31c Kim Akers                     Kim.Akers@office365itpros.com      Member
a3eeaea5-409f-4b89-b039-1bb68276e97d Ben Owens (Business Director) Ben.Owens@office365itpros.com      Member
c6133be4-71d4-47c4-b109-e37c0c93f8d3 Oisin Johnston                Oisin.Johnston@office365itpros.com Member

And the same information is reported for the Office 365 Group:

Get-UnifiedGroupLinks -LinkType Member -id eba86b74-aef7-4a6b-aa8a-b9769e97716e

Name           RecipientType
----           -------------
TRedmond       UserMailbox
Kim Akers      UserMailbox
Ben Owens      UserMailbox
Oisin.Johnston UserMailbox

Planner Likes Members

Why is this important? Well, it’s not if you only ever create new teams via a client. It becomes important if you create new teams via PowerShell or the Graph, because it means that you should always add new owners as members first, and then add them as an owner. If you don’t, applications that check for membership of the underlying group will fail. Planner is one application that I know that won’t allow a team owner access unless they are also a member, but that doesn’t mean that there aren’t others that will also fail, now or in the future.

Creating a New Team with PowerShell

The right way to create a new team with PowerShell is to create the team with the New-Team cmdlet and specify the name of the team owner in the call (this also adds that person as a member). Afterwards, add other owners and members of the team with the Add-TeamUser cmdlet, making sure to add the owners first as a team member and then as an owner.

In this example, we create a new team and then add one owner and one member. The $TeamId variable stores the GUID for the new team, which makes it easy to call Add-TeamUser. As you can see, Donald Vickers is added both as an owner and as a member.

$TeamId = (New-Team -DisplayName "Planning Team" -Alias PlanningTeam -Description "Team for the folks who like to plan" -AccessType Private -Classification Confidential -Owner Brian.Weakliam@office365itpros.com)

Add-TeamUser -GroupId $TeamId.GroupId -User Donald.Vickers@Office365itpros.com -Role Member
Add-TeamUser -GroupId $TeamId.GroupId -User Donald.Vickers@Office365itpros.com -Role Owner

All good clean PowerShell fun…

Note: The current Teams PowerShell module is 0.9.6. You need to use this version to see things work as described in this article.

We cover using PowerShell to work with Teams and Office 365 Groups in Chapter 14 of the Office 365 for IT Pros eBook. We like Teams, so there’s lots to discuss.

The post Tip: Make Sure to Add Owners as Members When Creating New Teams appeared first on Office 365 for IT Pros.

Sensitivity Labels are a Game Changer

Today’s Petri.com post discusses the use of Office 365 sensitivity labels through an updated set of Office desktop applications coming soon. A previous post reviewed the migration from Azure Information Protection (AIP) labels. Of course, you can create and deploy sensitivity labels to protect Exchange and SharePoint content without going anywhere near AIP. In the long term, AIP labels are only needed if you want to protect content that isn’t stored inside Office 365.

The important point is that AIP labels and sensitivity labels share a common foundation in the Azure Information Protection service and the set of rights management templates published through that service. Both update the same file metadata and both use the same permissions.

Rights management has been around for a long time. I think the technology got a bad rap because it was deemed complex and unwieldy.  Sensitivity labels change the dynamics because they are easy to create and publish, and easy for users to apply to Office documents stored inside SharePoint and to email sent by Exchange Online. For these reasons, sensitivity labels will make protection through rights management and encryption a daily part of Office 365 life.

Rights and Permissions

Protection means that a user cannot access content unless they have the rights to do so. Furthermore, once a user accesses content, the permissions assigned to them (the rights) dictate what they can do (print, edit, forward, reply, etc.). Protecting documents and email gives authors confidence that they control that content. For instance, adding a new recipient to a reply to protected message is useless from the perspective of that recipient because they don’t get the right to open the content because they’re not in the set assigned to the original message. All in all, protecting Office 365 content is a good thing.

The Downside of Protection

Even good technology can have its downside and protection is no different. Once you protect a document, you lose some functionality. The biggest issue is that Office 365 cannot search the content because it can’t decrypt the content to index it. This means that content searches and eDiscovery must rely on document metadata for its indexes. If users populate the metadata with terms that search can use to find documents, it might not be so much of a problem. But users are humans and humans often don’t do such a good job with metadata.

Of course, if a content search finds some protected content, you then face the further difficulty of what to do with it. Investigators might want to review the content to check whether it’s needed for eDiscovery purposes, but the content is encrypted. The solution is to use super-user privilege to decrypt the content. A technical solution exists, but dealing with encrypted files can be painful.

ISVs and Protection

In addition to the issues thrown up inside Office 365, any ISV who deals with Office 365 content needs to understand if the advent of sensitivity labels and increased use of rights management within Office 365 impacts their product. If a product depends on gaining access to content, it’s going to run into a brick wall when it tries to access protected content.

No Argument Against Protection

You can’t really argue against the goodness of securing access to confidential information. Sensitivity labels give users control over their information, and they should know what’s confidential and needs to be protected. Some user education is needed to ensure that everyone knows how best to use the range of visual markings and protection available through sensitivity labels, but overall, this is a very good feature that’s arriving into Office 365.

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

The post Office 365 Sensitivity Labels Bring Rights Management to the Masses appeared first on Office 365 for IT Pros.

It’s The Last Mile to Office 365 Stupid!

In both the Ignite 2017 and 2018 conferences, Microsoft spent a lot of time to get the message across to Office 365 tenants that problems in network connectivity are often due to issues in the last mile. In other words, the problem lies in getting traffic from client workstations through the customer’s network to the internet and on to Microsoft’s network. Once data reaches Microsoft’s network, ultra-fast dark fiber connections make sure it gets to the right place without delay.

A Proof of Concept

We include a curated set of links to Ignite presentations, Microsoft white papers, and other guidance about network planning in Chapter 2 of the Office 365 for IT Pros eBook. Last week, Microsoft added another useful tool to the set available to tenant administrators in the form of a proof of concept for a Network Performance Tool.

As Microsoft say, they’re starting with small steps and the current release of the tool focuses on the network egress location (where your traffic hits the Microsoft network) and the Office 365 front door server (the first Office 365 server that handles your traffic). Other tests will follow as Microsoft develops the tool.

Running the POC

You can run the tool to check your network performance to Office 365 by connecting to it with a browser. I ran the tool several times from different workstations and got different results, even though all workstations were connected on the same Wi-Fi network. In most cases, the tool reckoned that both my network access and front door server were in Dublin, but sometimes the front door server moved to London.

The Dublin result was expected because my house is within a few miles of Microsoft’s Office 365 datacenters in Dublin. Being told that my front door server was in London was harder to explain because my tenant is in the Office 365 EMEA datacenter region (Dublin, Amsterdam, Vienna, Helsinki) and the UK datacenter is in its own region.

Comparison Against Other Office 365 Tenants

The tool also compares your data with that of other customers. While happy to see that I had good performance, I couldn’t quite work out what I could do better to get excellent performance. My connection is simple: local Wi-Fi network to local router to ISP to the internet. There’s not much to improve other than increasing the performance of the internet connection.

Other tenants will be in the same situation. You can do your best to deploy a solid internal network, but cloud services all depend on the ability to transmit information across the internet to the cloud provider. I’ll wait for my ISP to improve their performance and will use the tool as Microsoft improves it from the POC state to check whether I ever approach excellence.

The post Office 365 Network Performance (POC) Tool appeared first on Office 365 for IT Pros.

Cloud App Security Alerts Join the Office 365 Audit Data

Office 365 keeps on changing. The recent announcement that Microsoft is surfacing Office 365 Cloud App Security alerts through extra interfaces is an example of a change that might be considered small, unless you work in the area of security and compliance.

One thing that attracted my attention is the fact that Office 365 Cloud App Security (bundled with E5 licenses) now sends its alerts to the Office 365 audit log. This makes sense because Office 365 alerts and alert policies are powered by the events captured in the audit log.

Analyzing Cloud App Security Audit Records

In any case, events in the audit log show up with RecordType SecurityComplianceAlerts. Like all events in the audit log, some work is needed to unpack and interpret the information stored in the AuditData property. I used some code from Chapter 21 of the Office 365 for IT Pros eBook to examine what useful material is included by running the Search-UnifiedAuditLog cmdlet to retrieve the records.

Office 365 audit log records are normalized, but only to a point. Normalization means that a set of the same basic fields are included in all records, no matter what workload generates a record. The devil in the detail is that the contents of the AuditData property is open to interpretation and each workload can do its own thing in terms of what is output. And in the case of Cloud App Security, the contents of AuditData vary depending on an alert.

The upshot is that more work than should be necessary is needed to parse the data to make it useful for reporting and analysis. I only found two types of alerts generated by Cloud App Security, so that’s what the code below deals with. You might find others and need to update the code to handle whatever Microsoft decided to stuff into AuditData for the alert.

$Records = (Search-UnifiedAuditLog -RecordType
SecurityComplianceAlerts -StartDate 1-Jan-2019 -EndDate 30-Jan-2019 -Formatted
-ResultSize 3000)
If ($Records.Count -eq 0) {
   Write-Host "No alert audit records found." }
Else {
   Write-Host "Processing" $Records.Count "audit records..."
$Report = @()
ForEach ($Rec in $Records) {
   $AuditData = ConvertFrom-Json $Rec.Auditdata
   $Data = ConvertFrom-Json $Auditdata.data
   If ($Rec.Operations -eq "AlertTriggered") {
      $ReportLine = [PSCustomObject][Ordered]@{
           TimeStamp; = $Rec.CreationDate
           User        = $Data.f3u
           Action      = $Data.an
           Status      = $AuditData.ResultStatus
           Severity    = $AuditData.Severity
           Workload    = $AuditData.Source
           Operation   = $Rec.Operations
           Category    = $AuditData.Category }
      $Report += $ReportLine}
    Else {
      $ReportLine = [PSCustomObject][Ordered]@{
           TimeStamp   = $Rec.CreationDate
           User        = $Data.eid
           Action      = $Data.lon
           Status      = $AuditData.ResultStatus
           Severity    = $AuditData.Severity
           Workload    = $AuditData.Source
           Operation   = $Rec.Operations
           Category    = $AuditData.Category }
        $Report += $ReportLine}
  }} 

$Report | Select Timestamp, Operation, User, Action
Processing 42 audit records...

TimeStamp            Operation            User          Action
---------            ---------            ----          ------
21 Jan 2019 16:58:00 AlertEntityGenerated Tony.Redmond@ eDiscoverySearchStartedOrExported
21 Jan 2019 16:58:00 AlertTriggered       Tony.Redmond@ eDiscovery search started or exported
2 Jan 2019 19:54:00  AlertTriggered       Tony.Redmond@ eDiscovery search started or exported
…

It’s worth pointing out that some of the alerts that flow into the audit log duplicate events already logged by a workload, which is certainly the case for the eDiscovery searches featured above.

Always Tracking New Developments

We’ll continue to track what happens as Microsoft releases the other updates mentioned in their post and update whatever we need to in the Office 365 for IT Pros eBook. Keeping up-to-date with developments inside Office 365 is what we do!

The post Cloud App Security Alerts Flow into Office 365 Audit Log appeared first on Office 365 for IT Pros.

Teams Writes Items into Mailboxes

As I am sure everyone is now well aware, Teams creates items in group and personal mailboxes to capture compliance records for channel and personal conversations. The mailbox items are not perfect copies of Teams messages (they don’t record likes, for instance), but they are indexed and discoverable by Office 365 content searches and therefore useful for compliance purposes.

Searching the Office 365 Audit Log

Poking around in the nether reaches of Office 365 is kind of normal for the Office 365 for IT Pros writing team, and this week we noticed that the Office 365 audit log includes records for the capture of Teams compliance records. However, only records for messages posted to channel conversations by tenant users are captured in the audit log. Audit records for messages posted to personal chats or those posted by guest users are not captured. Capturing of these records happened over 90 days in the past, which is all you can go back in the Office 365 audit log unless you have an E5 license and your tenant has been upgraded to 365-day retention.

If you want to check the audit records on your tenant, use the Audit log search in the Security and Compliance Center or run the PowerShell command (adjust the dates to stay within the 90-day range) shown below:

$Records = Search-UnifiedAuditLog  -StartDate 21-Nov-2018 -EndDate 20-Feb-2019 -operations "Create" -resultsize 5000 | Format-Table CreationDate, Operations, UserIds

Among the records, you’ll probably see some for the special user S-1-5-18. These records capture the introductory message posted in the General channel when a new team is created.

Interpreting Audit Records for Teams Messages

Taking a technique explored in Chapter 21 of the Office 365 for IT Pros eBook to expand the content of the AuditData property of audit records, we can interpret the records we find (here’s another example). In this case, we can generate a quick count of messages posted to the teams in the tenant.

If ($Records.Count -eq 0) {
   Write-Host "No audit records records found." }
 Else {
   Write-Host "Processing" $Records.Count "audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      If ($Rec.Operations -eq "Create") {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $ReportLine = [PSCustomObject][Ordered]@{
           TimeStamp   = $Rec.CreationDate
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Team        = $AuditData.MailboxOwnerUPN
           Subject     = $AuditData.Item.Subject
           MessageId   = $AuditData.Item.InternetMessageId}
      $Report += $ReportLine
  }}}
$GroupData = $Report | Group-Object -Property Team
$GroupData | Sort Count -Descending | Select Name, Count

Name                                               Count
----                                               -----
Office365ITPros@Office365ITPros.com                  192
ExchangeMVPs@office365itpros.com                     130
Audie-tronadmirers@office365itpros.com               128
JapanRugbyWorldCup2019@office365itpros.com           112
Volleyball@office365itpros.com                       110
...

Remember that this count is inaccurate. It doesn’t include any messages posted to Teams by guest users, nor does it capture anything for messages posted to Teams channels via connectors or bots. However, knowing about these records and how to interpret them might come in handy as a way of looking at Teams activity.

To look at the data a different way, if you wanted to find out who is the most prolific poster to Teams, change the Group-Object command to:

$GroupData = $Report | Group-Object -Property User
$GroupData | Sort Count -Descending | Select Name, Count

Name                                Count
----                                -----
Tony.Redmond@office365itpros.com      155
Jeff.Guillet@office365itpros.com      122
S-1-5-18                               11
Kim.Akers@office365itpros.com          10
...

The interesting thing is that we can conclude that 11 new teams were created in the period because that’s the count of messages created by S-1-5-18!

Interesting though this little discovery is to the true Office 365 nerd, it’s probably not going to feature in the Office 365 for IT Pros eBook. We do have some standards!

The post Office 365 Captures Audit Records for Teams Compliance Items appeared first on Office 365 for IT Pros.

New Tools, New Tasks

When it comes to automating Office 365 operations, administrators have the choice of multiple tools. In the past, PowerShell was the tool, but recently I have seen several other tools grow in popularity. Just like Office 365 itself, automation doesn’t stay still.

PowerShell and Office 365

PowerShell is critical to Office 365. Behind the scenes, many Office 365 operational processes are coded in PowerShell. To me, the flexibility of PowerShell in the way that it goes from a single command to simple scripts to moderately complicated procedures right up to full-blown operational frameworks is very powerful.

In the hands of an expert (not me), PowerShell can do some remarkable things that possibly lie far beyond the expectations of its inventors. Take the script written by Vasil Michev to report the membership of Exchange distribution lists.

On the surface, this seems like a straightforward operation and there are many examples of how people have approached the problem posted on the internet. The basic idea is to use Get-DistributionGroup to return a set of distribution lists in the tenant and Get-DistributionGroupMember to expand the membership of each list. Things become more complex when you consider that lists might have dynamic membership, or that their membership can be made up from different mail recipient types, or that they can include nested distribution lists. The upshot is that the task is much harder when all the possible members of distribution lists are considered.

PowerShell Problems in Office 365

Good as PowerShell is in the hands of experts, it suffers from the fact that it is not universally available for all the Office 365 apps. Exchange Online has excellent support, SharePoint Online less so. Teams is just starting. Planner knows nothing about PowerShell, and so on.

PowerShell can be messy at times too. Microsoft doesn’t show much interest in adding PowerShell support for some Office 365 applications, nor does it seem able to consolidate modules together so that you can load a single set of cmdlets spanning multiple apps (supporting MFA) with one command.

The last downside is PowerShell’s inability to access user data, which is why other protocols (like Exchange Web Services) exist. This is not a problem if you only need to write operational procedures, but it can be limiting at times.

Considering Flow

Which brings me to the new world of automation tools available for Office 365 administrators. An example is worth a thousand words, so if you’re unsure that you need to go near tools like Flow and the Graph, have a look at a practical example from Lee Ford showing how to use Forms to collect a user request for a new team, Flow to orchestrate the steps to approve and action the request, and the Graph to create the new team complete with an owner.

If you’re unfamiliar with Flow, it will take you some time to work through the steps described in the article. The flow isn’t perfect because it lacks some steps, such as what happens if approval is not granted for a new team, and in production the flow would run from a service account rather than a user account. But that’s not the point – the flow shows you what’s possible without writing a line of code (OK, some JSON is involved) to bring together bits of Office 365 to accomplish a task.

New World of Automation

PowerShell is great. Used in the right way PowerShell helps administrators get lots of work done. But the world is changing and other possibilities for automation now exist. If you haven’t had a look at Flow, maybe it’s time for you to do so?

We include a whole chapter on Flow (Chapter 23) in the Office 365 for IT Pros eBook. And we have tons of PowerShell too. In fact, we’re fully automated.

The post Automating Office 365 with PowerShell and Flow appeared first on Office 365 for IT Pros.

Connecting PowerShell to Office 365 The Right Way

In my note about automating Office 365 with PowerShell and Flow, I criticized Microsoft for publishing too many PowerShell modules, which makes it messy if you want to manage many different parts of Office 365 in a single PowerShell instance (window).

The inevitable question then arises about how to configure PowerShell to work best with Office 365. Or put another way, how to build the best script to connect the various bits of Office 365 as efficiently as possible using a command window or the PowerShell ISE (or however else you choose to use PowerShell). In response, I think two approaches exist:

• Build your own script from scratch and include the commands to connect to the different parts of Office 365 that you want to work with. This Microsoft post includes most of the commands you’ll need to use. However, you still need to do some work to build and test the script to make sure it is fit for purpose, including using multi-factor authentication to connect to services that support MFA, like Exchange Online.
• Pick up one of the many example scripts that exist and modify it for your own purposes.

PowerShell Connection Scripts

Normally, I tell people looking for a good connection script for Office 365 to head over to MVP Michel de Rooij’s site and learn about his Connect-Office365Services.ps1 script. Michel has developed and enhanced the script over the years to track developments in the service and it’s an excellent start for for anyone who wants to work with Office 365.

Yesterday, MVP Chris Goosen posted an update to his Connect-365.ps1 script. Michel influenced this script too and the nice thing about it is that it includes a GUI to allow you to choose what Office 365 services to connect to and whether to use MFA. This is a nice touch.

If You Don’t Like a Script, Change it

In both cases, the scripts are available from the TechNet Gallery or GitHub and because the code in the scripts is relatively straightforward PowerShell, you can change how the scripts work to reflect your view on how best to connect.

The Office 365 for IT Pros eBook includes over 1,000 examples of how to use PowerShell to work with different parts of Office 365. Before you can use those examples, you need to connect – so that’s why you need a script.

The post Configuring PowerShell for Office 365 appeared first on Office 365 for IT Pros.

Automated Policy Creation to Protect Sensitive Information

Microsoft currently offers Office 365 tenants the opportunity to preview a new version of the Office 365 Admin Center, which is expected to replace the current version later this year.

The new portal was on full display at the Ignite 2018 conference last September, and at the time Microsoft demonstrators promised me that we’d see automated suggestions surface in the portal to help tenant administrators get to grips with the range of functionality available to protect data. Remember that Microsoft gathers an enormous amount of signals about the content users create (something they need to be careful about in the era of GDPR), so they have masses of data to analyze to understand where improvements might be made.

This week, the first suggestion popped up in the Office365ITPros tenant when the portal offered us the opportunity to protect sensitive data better. In fact, a Data Loss Prevention (DLP) policy would do the trick.

Curious Choice for Data to Protect

When I examined the recommendation, I discovered that the Admin Center was concerned that my tenant wasn’t doing a good job of protecting content holding the U.S. Individual Taxpayer Identification Number (ITIN) sensitive data type (one of the standard types available in Office 365).

The suggested settings seemed OK, so I clicked Create policy to see what would happen. After all, it couldn’t do any damage, could it?

Slight Error. Please Retry

Unhappily, the new Office 365 Admin Center was unable to create the DLP policy. Such is life and errors like this are prone to happen in preview releases.

You can expect Microsoft to continue to deliver automated suggestions through the Office 365 Admin Center to help administrators do a better job of managing their tenants. It will be interesting to see how far Microsoft goes with their suggestions and how tenants react to what’s suggested.

While we’re waiting for Microsoft to complete the new Office 365 Admin Center and improve the automated creation of DLP policies, why not read Chapter 22 of the Office 365 for IT Pros eBook to learn how to create policies manually.

The post New Office 365 Admin Center Offers to Create DLP Policy appeared first on Office 365 for IT Pros.

Helping Exchange Protect Users from Bad Email

Given the amount of spam floating around today, it comes as no surprise that many organizations deploy an Exchange transport rule to mark inbound external email with a suitable warning. This is a straightforward rule to configure and it can help stop users being fooled by bad messages that get past the array of checks used by Exchange Online Protection to detect and suppress spam. Even the best anti-spam defense is sometimes fooled by a phishing attempt (at times, you wonder how some “amateur night at the races” phish attempts manage to get through).

Visual Marking to Help Users

The usual approach is to add two visual markings to external messages with the aim that these markings highlight the risk that could be present in external email. The first marking is a disclaimer placed at the top of the message body; the second is a prefix added to message subjects. In the rule below, we see that some HTML text is used for compose the disclaimer while a simple “#External:” prefix is used for the message subject.

Refining the Rule

Exchange applies the rule to any message sent from an external domain to a recipient within the organization. You can get pretty creative with the conditions that cause a rule to fire with the aim of only applying marking to messages that deserve to be treated with some caution. For instance, you could add a condition so that the rule would only fire if the message had an Spam Confidence Level (SCL) higher than 1. This means that any message that came through Exchange Online Protection’s spam checking with an SCL that says it definitely isn’t spam would not be marked. Exchange Online delivers messages with an SCL of 5 or higher to users’ Junk Email folders.

You could also look for a value in a message header and use it to decide if to apply marking. For instance, you might decide to mark all messages that don’t pass DMARC checking (look in the Authentication-Results header for dmarc=none or dmarc=fail).

The Message Header Analyzer tool is very useful when reviewing message headers to decide which to use and what value to look for. This is an add-in that you can load into Outlook (and OWA) to run against messages in your mailbox.

Adding Exceptions

As in the case of rules to add disclaimer text or auto-signatures to outbound messages, I usually add some exceptions to the rule. The first exception is to stop Exchange applying the rule to messages where the #External: prefix already exists in the subject. The logic here is that if someone is involved in a messaging thread, they’ve made the decision that it’s safe to do so and don’t need to be reminded for each reply.

The second exclusion is to not apply the marking for well-known domains. The exact list of these domains will differ from organization to organization but is likely to include important partners and trusted companies, like petri.com and microsoft.com as shown in the example. You could also add onmicrosoft.com to exclude Office 365 tenants that use their service domains for email. However, some spammers have used Office 365 tenants in the past, so this exclusion comes with some risk.

Using exceptions and refining the rule so that not all inbound email is marked has two effects. First, it means that marked messages have a meaning that they won’t have if every inbound message is marked. Second, it stops users complaining when perfectly legitimate business communications are marked. You wouldn’t paste a great big warning label across every parcel that comes into the company by post, so there’s no need to warn about every message coming into your tenant.

Composing HTML Marking

Most email is in HTML format today, so it makes sense to compose the marking in HTML. You might be fluent in HTML, but I am not, so I used the online HTML editor to compose the text and then cut and pasted the HTML into the EAC rule editor.

I also added a small (25 x 25 pixel) graphic to make the marking more visually interesting. All you need is a small graphic file located on a web site that can be reached by Exchange. The HTML I ended up with is:

<p><strong><span style="background-color: #ff6600;"> [WARNING]</span> </strong>This message comes from an external organization. Be careful of embedded links. <img src="https://i0.wp.com/office365itpros.com/wp-content/uploads/2019/03/stop.jpg" alt="Stop" /></p>

The Rule

The important parts of the rule (as returned by the Get-TransportRule cmdlet) are shown below:

FromScope                                     : NotInOrganization
SentToScope                                   : InOrganization 
HeaderContainsMessageHeader                   : Authentication-Results
HeaderContainsWords                           : {dmarc=fail, dmarc=none}
ExceptIfSubjectContainsWords                  : {#External:}
ExceptIfSenderDomainIs                        : {bwwmediagroup.com, audi.ie, revenue.ie, dell.com...}
ApplyHtmlDisclaimerLocation                   : Prepend
ApplyHtmlDisclaimerText                       : <p><strong><span style="background-color:#ff6600;">[WARNING]</span> </strong>This message comes from an external organization. Be careful of embedded links.<img src="https://i0.wp. com/office365itpros.com/wp-content/uploads/2019/03/stop.jpg" alt="Stop" /></p>
ApplyHtmlDisclaimerFallbackAction             : Wrap

The Visual Effect

The visual marking for the message body is shown below. Of course, the danger always exists that users will become used to the warning and ignore it over time, so it might be good to change the wording, color, or images used over time.

Remember to check that the marking shows up well on all email clients in use, including mobile devices. Also, any change to an Exchange Online transport rule takes some time to be effective within a tenant due to rule caching and the need to update multiple servers.

Markings Only Warn

The best and most obvious markings that a message might be suspect can and will be ignored by human beings. That sober recognition of what people are capable of might discourage you from adding marking rules, but that’s no reason not to go ahead and use this technique. After all, if it stops one person being phished, it’s worthwhile.

Need more help with Exchange transport rules? Look no further than Chapter 17 of the Office 365 for IT Pros eBook. It’s packed full of useful information about email processing and anti-malware techniques.

The post Marking External Email with an Exchange Transport Rule appeared first on Office 365 for IT Pros.

Relieves Some of the Boredom Involved in Adding Users

The Office 365 Admin Center and its latest iteration, the preview version of the Microsoft 365 Admin Center (much nicer to use in parts), both offer the option to bulk-create Office 365 accounts. The processing flow is simple:

• Populate a CSV file with account details (a limited number of properties are supported).
• Upload the CSV file to the Admin Center.
• Verify that the CSV file is valid.
• Use the data in the CSV file to create accounts.

The idea is to relieve the tedium of creating multiple accounts, a value that anyone who has had to populate a tenant with account information (for real or to build out a test tenant) can easily recognize. However, there are some issues that need to be taken into account.

Preparing a CSV for Bulk Account Creation

To begin, head to the Active Users section of the Admin Center and select Add multiple users. You now have the choice to download a prototype CSV file to populate with details of the accounts you want to create. If you’ve done this before, you might already have prepared a file for processing – or if you’re very lucky, someone else has done the work manually or by generating the necessary data from another application, like a HR system.

The CSV file is very straightforward. All you really need to populate is the User Name (User Principal Name or UPN), which must be unique. Ideally, the UPN is the same as the email address you want to assign to the new account, and the email address must also be unique. Apart from the UPN, you can leave all the other fields blank except the Country or Region, which Office 365 needs to assign licenses as some features are country-dependent.

As far as I can tell, there’s no limit about the number of accounts you can include in a CSV. However, it’s probably wise to limit the number in a batch to a manageable amount (100 or so). Once you’ve populated the CSV with account information, you can ask Office 365 to verify the information.

Validation is very basic and the errors generated by the process are not very helpful. For instance, it will detect if you include accounts for more than one country and generate an error like:

[{“Row number”:2,”Errors”:[“Invalid domain name used in username. “]},{“Row number”:3,”Errors”:[“Invalid domain name used in username. “]}]

Only engineers would love the formatting of the error report. In any case, don’t expect validation to check that accounts already exist. The real intention of the validation seems to check that the CSV file is in the correct format.

Assigning Office 365 Licenses

Clicking Next brings you to license assignment. Obviously, you can’t assign licenses that you don’t own, but you can create accounts that don’t have the right licenses. One thing that you can’t do is assign different licenses to the accounts you create. You’re limited to the one license for everyone. The limitation on multiple country and license choice within a CSV file is a good reason to divide accounts into batches.

After selecting a license, you can go ahead to the final phase and create the accounts. If all goes well, you’ll have the choice to see the automatically-assigned passwords for the new accounts in email or in a downloadable CSV file. If things don’t go so well, you can download the log file (another CSV) to see errors like

The email address is being used by user (Rory Best) Rory.Best@Office365itpros.com. Please use a different email address.

This error is pretty self-explanatory.

Bare-Bones Office 365 Accounts Generated

Bulk account creation works, but the amount of time the process saves is possibly limited. You must create the CSV file, check that it works, process it, and resolve errors. And then you’ve still got to build out the account to make it fully functional by:

• Adjusting licenses if necessary.
• Adding the new user to distribution lists, Office 365 Groups, and Teams. The new accounts will be added to org-wide teams, if these are available in the tenant.
• Adding manager (reporting) information so that the Office 365 apps can show organizational structures.
• Add a photo for the account.
• Allocate calling plans or numbers if you use Teams or Skype for Business Online to replace a traditional PBX.
• Assign administrative roles.
• Assign extra email proxy addresses (if needed).
• Enable multi-factor authentication.
• Manage mailbox properties, like disabling access to mailboxes via older protocols such as IMAP4 and POP3.

It’s unsurprising that a ton of work remains to transform a bare-bones account to something that is fully usable by the account holder. To be fair to Microsoft, they don’t know how each tenant organizes its affairs, so they have delivered something that works at a basic level for all.

Maybe Roll Your Own Bulk Creation with PowerShell?

Given the situation, a more satisfactory answer for many tenants is to create their own bulk creation process using PowerShell where the script can do all the work to create the Office 365 account, populate all the necessary properties, add the user to appropriate distribution lists, groups, and teams, and so on. Or use what Microsoft provides in the Admin Center and be prepared to fix things up afterwards, perhaps with the assistance of a tool like Hyperfish to find obvious gaps in your tenant directory.

Need help figuring out how to automate Office 365 account creation? The Office 365 for IT Pros eBook has lots of examples of how to use PowerShell to accomplish tasks like account creation, license assignment, joining distribution lists and teams, and so on. You might find your answer in our example scripts!

The post Adding Multiple Office 365 Users with the Microsoft 365 Admin Center appeared first on Office 365 for IT Pros.

New Consoles Turn Up in Office 365 Tenants

Previewed in January 2019, this week the new Microsoft 365 Security Center and Microsoft 365 Compliance Center have turned up in Office 365 tenants. The new consoles integrate different components from across the Microsoft 365 suite and will eventually replace the Office 365 Security and Compliance Center (SCC). Use https://compliance.microsoft.com to access the Microsoft 365 compliance center and https://security.microsoft.com for the Microsoft 365 security center, or click the Security and Compliance links now available in the Office 365 Admin Center.

Fit and Finish Needed

Although deemed generally available by Microsoft, the new consoles need some fit and finish to become fully functional. Many options in the Compliance Center take you back to the SCC. For example, you must use the SCC to create new supervision policies or manage sensitive information types. There’s no trace of the Office 365 audit log or content searches either. However, you can manage retention and sensitivity labels and create and apply policies for these labels in the new center (but not a retention policy that applies a default retention setting to one or more locations).

The new centers share the same design language as the Microsoft 365 Admin Center. Screen layouts are less bulky and clearer than in the SCC, so they’re a little easier on the eye. Some options (like Alerts and Classification) appear in both consoles. Monitoring and Reports is also a common option, but you see different data for compliance than you see for security.

Split Responsibilities

Apart from integrating other Microsoft 365 components alongside Office 365, dividing security and compliance into separate consoles allows Microsoft to have different access roles to control who can use the consoles. If you run a small tenant when the only administrative role used is a global administrator, the division in responsibilities won’t make any difference to you, but in larger tenants, being able to assign precise administrative responsibilities is a good thing. We therefore have roles like the Security Administrator and Compliance Administrator (see this page for details).

Impact on the Office 365 for IT Pros eBook

As noted above, Microsoft needs to do some work to bring the new consoles up to scratch so that they can phase out the Office 365 Security and Compliance Center. We hope that Microsoft fixes the problems that afflicted the SCC during this process, such as the many warning messages that something couldn’t be done because some ill-defined and unknown quota had been exceeded.

For the moment, the Office 365 for IT Pros writing team will continue to focus on the SCC and keep a watching brief on developments in the new consoles. Once everything is ready, we will switch our coverage to the Microsoft 365 consoles and update whatever is needed (screen shots etc.) across a range of chapters.

Being able to respond to changes like this as they’re rolled out by Microsoft is one of the charms of a eBook. The rate of change in Office 365 sure doesn’t make live easy for printed books.

The post Microsoft 365 Security and Compliance Centers Now Generally Available appeared first on Office 365 for IT Pros.

Exchange Online Promises Forensic Coverage of Mailbox Accesses

In January, we reported Microsoft’s announcement that a new mailbox audit record called MailItemsAccessed in the set of actions that can be captured for mailbox activity. At the time, we said “The new action will capture details of when a message in a mailbox is opened by the mailbox owner, delegate (someone with read access to the mailbox), or using administrative access. According to Microsoft, the data gathered gives
“comprehensive forensic coverage of mailbox accesses.”

Sometimes things don’t go quite to plan in the cloud, and Office 365 Admin Center notification MC176515 published on 26 March 2019 contained the blunt message that “We have rolled back the feature, at this time, and so the MailItemsAccessed action will no longer be available.” The additional information link in the notification leads to a discussion about how to manage mailbox auditing for Exchange Online that doesn’t mention MailItemsAccessed at all and the title of the notification could be clearer, meaning that administrators could easily miss it.

All-in-all, given that the new audit record opened the possibility of comprehensive forensic coverage of mailbox accesses, Microsoft’s terse statement deserved some interrogation.

Microsoft’s Explanation

I reached out to Greg Taylor, Marketing Director for Exchange, who told me that: “There were technical challenges that during the process of rolling out of MailItemsAccessed to the different regions. Keeping in mind the necessity of complete accuracy and availability of data, we decided to roll the changes back, make the fixes and re-initiate the rollout. We will begin the rollout again soon, and will be sharing more details with respect to the rollout plan and availability.”

Reading between the lines, we can say that:

• Bugs were discovered. Speculating what might have happened, perhaps not all accesses to messages were captured in audit records , or the audit records were not correctly ingested from Exchange Online into the Office 365 audit log (something that has happened before).
• Microsoft detected the problem and because it involves data (loss?), they decided to pull the code that generates the new audit record.
• They’re working on the fixes and will restart the rollout when the new code is available. No timeline is available for when this might be.

Audit Records are Important

I think everyone will agree that audit records are important. Office 365 must generate audit records when expected, the audit records must contain the correct data, be immutable, and discoverable. The problem found by Microsoft with the MailItemsAccessed audit record might belong in either or both of the first two buckets, so it’s good that they have taken the action to find and fix the problem.

Now, if only someone could teach the people who write the Office 365 notifications how to use clear, concise, and informative language, we’d all be in a happier place.

We cover mailbox auditing and the Office 365 audit log in Chapter 21 of the Office 365 for IT Pros eBook. The advent of the MailItemsAccessed audit record is covered there. We’ll add a caveat now and remove it after Microsoft restarts its deployment. It’s what we do in the ePublishing world!

The post Microsoft Halts Deployment of MailItemsAccessed Audit Records appeared first on Office 365 for IT Pros.

Do You Really Want OWA Users to Access Third Party File Providers?

Those who browse the deep recesses of Microsoft documentation often find unannounced pleasures awaiting their delight. Such is the case of Set-OWAMailboxPolicy, where the ThirdPartyFileProvidersEnabled setting is documented. Despite the best efforts of Vasil Michev (the esteemed technical editor of the Office 365 for IT Pros eBook), the setting seems to be not well known. It deserves more.

By default, the setting is false, which means that OWA users can’t access third-party file providers like Box, Google Drive, or Dropbox to upload attachments. Before users can access a third-party file provider, they must authenticate their account (including an MFA challenge if MFA is enabled for the account) and give access to OWA.

Once the connection is made between the third-party file provider and OWA, the user can browse for attachments. Here’s what it looks like for a Dropbox account.

Goodness and Badness

There’s goodness and badness in allowing users to access third-party file providers. It’s good that they attach files stored in the providers to bring them into Exchange Online and so expose the content to Office 365 data governance. It’s bad if it encourages the long-term use of third-party file providers for business information. Each organization will have to make up its mind how to handle the situation and decide if they want to enable access to other file services.

Discovering Who Can Use Third-Party File Providers

To check what OWA mailbox policies allow access to third-party file providers, use the command:

Get-OwaMailboxPolicy | Format-Table Name, ThirdPartyFileProvidersEnabled

Name                       ThirdPartyFileProvidersEnabled
----                       ------------------------------
OwaMailboxPolicy-Default                             True
Restricted Download Access                          False
OWAFullAccess                                        True
NoOfflineAccess                                      True

We can see that three of the OWA mailbox policies allow third-party file providers. To discover the mailboxes covered by these policies, use the command:

Get-Mailbox -RecipientTypeDetails UserMailbox | Get-CasMailbox |? {$_.OWAMailboxPolicy -ne "Restricted Download Access"} | Format-Table DisplayName

We use Get-Mailbox to feed a filtered list of user mailboxes (excluding room, shared, discovery, and resource mailboxes) to Get-CasMailbox, check what OWA mailbox policy applies to each , and output a list of names. Simple!

For more information about OWA (but not third-party file providers), see Chapter 10 of the Office 365 for IT Pros eBook.

The post OWA’s ThirdPartyFileProvidersEnabled Setting appeared first on Office 365 for IT Pros.

The blog posted by the Exchange development group yesterday to announce new tools to migrate from G Suite should really have been titled “migrate email from G Suite” because the solution only handles mail, calendar, and contacts. Or maybe the experience is intended to migrate the bits of G Suite that people really use and ignore Docs, Drive, and the other pieces. In any case, the Exchange guys are obviously very excited that the functionality is now rolling out and should appear in Office 365 tenants over the coming weeks.

The MRS Key to Migration

The advent of better migration tools is a good thing. Microsoft has built the migration on top of a well-known and robust foundation in the Mailbox Replication Service (MRS), which has been moving mailboxes between servers since Exchange 2010. Since its initial ability to move mailboxes from one version of Exchange to another, MRS has expanded its abilities to handle more scenarios and has moved literally millions of mailboxes from on-premises organizations to Office 365 tenants. Now it can move messages, contacts, and calendar items from Gmail to Exchange Online, treating each Gmail user as a migration request and bundling those requests into migration batches that MRS processes in the background.

There’s no great magic involved in connecting to G Suite. MRS uses the IMAP4 protocol to access and read information from Gmail mailboxes. Only 2 GB can be read from a mailbox daily. As Microsoft notes, this limit is enforced by Google (at least the limit is per mailbox). In any case, MRS will process mailboxes larger than 2 GB until they are completely moved over to Exchange Online using incremental synchronization before performing the final switchover. The process will just take a little longer (well, potentially days longer).

Limits

Some limits exist. The default for the largest item is 35 MB, but this can be increased to 150 MB by adjusting the transport configuration of Exchange Online in the target tenant. Note that the size of any message can be larger than expected because of the packaging used to preserve fidelity when messages pass between different servers. The 150 MB limit might, for instance, mean that a Gmail message of 135 MB (including all attachments) can be moved, but depending on the attachments and the format of the message, the limit might be smaller. Like for any other migration, it is a good idea to ask users due to be migrated to find large messages in their Gmail account and remove any that they don’t need to be moved.

Other limits exist in terms of the data that can be migrated. Essentially, users should be prepared to recreate rules and automatic replies and to review contacts after their mailbox is moved. Migration is all about moving mailbox data and not the settings for the Gmail account or other Google-related settings.

Cultural Changes for Users

Another cultural change facing migrated users is the change from Gmail labels to folders. The impact of this might be slight for people who only ever use the Inbox and Sent Items folders, but others who have created their own system of labels to mark and process email will need some coaching to transition to folders, understand the Focused Inbox,(which some people hate), and how Exchange Online archives messages (with retention policies or the Archive option), and other features such as OWA’s clean up mailbox.

If people have used Outlook to connect to Gmail, their transition to Outlook connected to Exchange Online should be smooth. However, their client might need to be updated to make sure that they use a supported version (and if their Office 365 plan includes it, the click to run version). The same is true for people who have used Outlook Mobile to connect to Gmail as Outlook Mobile (considered by some to be the best mobile client for Gmail). On the other hand, those transitioning from the traditional Gmail browser client to OWA will need some retraining to become comfortable with their new mailbox.

More G Suite Data to Migrate

There’s more than email to migrate when an organization moves from G Suite to Office 365. Microsoft suggests that you can move files from Team Drive to SharePoint Online, but there’s also many commercial migration products that should be considered before launching into a full-scale migration.

Going to G Suite?

If you want to go the opposite way and move from Office 365 to G Suite, Google launched the beta of G Suite Migrate in March 2019. In the early days of Office 365, it was quite common to hear about companies moving from on-premises Exchange to Gmail, but that doesn’t seem so common now.

Google’s tool supports migration from Exchange (on-premises and online), SharePoint, OneDrive for Business, and file shares, but misses out big parts of Office 365 like Teams and Planner. All of which proves that migration is a complex business and that any migration project deserves substantial up-front planning before a single byte is moved.

Administrators who move from G Suite to Office 365 need help too. Our advice is to buy a copy of the Office 365 for IT Pros eBook. The book contains far too much information to digest immediately, but it will be a source of comfort as they navigate their new home in the cloud.

The post Microsoft’s “New Migration Experience” from G Suite to Exchange Online appeared first on Office 365 for IT Pros.

Reduced Confusion as Everyone Waits for Native Support in Office Clients

As is the nature of the Microsoft cloud, the preview version of the Azure Information Protection client (unified labeling edition) has been replaced by the generally available version, now available for download and deployment. Microsoft’s April 16 announcement on the topic was upbeat but I still find considerable confusion in the field about labels, Azure Information Protection, Office, encryption, and rights management. Let’s see if we can clarify the situation.

Rights Management

Rights management is the technology that allows content owners (authors) to protect documents and files by stamping them with a template. The template defines the rights given to recipients to interact with the content such as the ability to edit or print. Rights management is automatically enabled for all Office 365 E3 and E5 tenants.

Azure Information Protection

Azure Information Protection (AIP) is a suite of technology built by Microsoft to control and help secure email, documents, and files. Reflecting their original name of “classification labels,” AIP labels are used to classify material inside or outside Office 365 with different degrees of sensitivity to reflect the confidentiality of the content. Labels are associated with rights management templates but also include other features like content marking. Labels used for the most sensitive information are likely to invoke encryption to protect the information against unauthorized access. AIP labels and templates are managed in the Azure Information Protection blade of the Azure portal. An AIP license is needed to assign AIP labels to files.

Office 365 Sensitivity Labels

Office 365 Sensitivity Labels are like AIP labels except that they are managed through the Security and Compliance Center. Both sets of labels share a common base in rights management and if a tenant started with AIP labels, they can migrate the set of AIP labels to become sensitivity labels and thereafter continue managing the labels through the Security and Compliance Center.

Sensitivity Labels are designed to protect Office 365 content like email and documents stored inside Office 365. Office 365 E3 and E5 plans include the licenses to use sensitivity labels, including the ability to encrypt email and documents. Figure 1 shows an Outlook message protected by a sensitivity label. You can also see the protection bar, which shows the current label applied to an item, and the sensitivity button, to expose the set of labels available to the user.

Although Exchange Online, SharePoint Online, and OneDrive for Business support sensitivity labels today, it will take some time before sensitivity label support is picked up in other workloads, like Teams.

AIP Client (s)

Two versions of the AIP clients are available. The standard version reads its policy and label information from the Azure portal. The unified labeling version reads equivalent information from the Security and Compliance Center. Both versions integrate with the Office desktop applications. You should use the AIP unified labeling client with Office 365, making sure to use the latest version whenever possible.

If you see a Protect button in the Office desktop apps, you know you’ve installed the older version of the AIP client. The unified labeling client installs a Sensitivity button (as shown in Figure 1).

Although the unified labeling version of the AIP client is not quite as functional as the older client. Microsoft expects it to reach close to feature parity with its older counterpart by the end of 2019. Microsoft’s blog post also makes the important point that “going forward new features will be included in the Azure Information Protection unified labeling client whereas we’re not planning to add new features to the Azure Information Protection client”. In other words, future development efforts are focused on the unified labeling version, so tenants starting deployment projects today are strongly advised to use this version.

Encryption

One of the big features of rights management templates is the ability to protect content through encryption. The keys used for the encryption can be tenant-provided (BYOK or HYOK) or Microsoft-managed (MMK). In either case, the AIP client is responsible for encrypting content after an AIP or sensitivity label is applied to a message, document, or file. This is why you need to deploy AIP clients to workstations.

Native Support

It’s obviously inconvenient to have to deploy yet another client to user workstations. To make things easier, Microsoft is building native support for sensitivity labels (and encryption) into the Office ProPlus (click-to-run) desktop apps and the Office Online apps. Office mobile apps (Word, PowerPoint, Excel) also support the application of sensitivity labels today. Outlook Mobile can read protected content and will be able to apply sensitivity labels to new messages soon.

When the Office apps include native support for sensitivity labels, you won’t need to deploy the AIP client to get this functionality unless you intend applying labels to content stored outside Office 365, in which case you need an AIP license (available in P1 and P2 plans and as part of the Enterprise Mobility + Security suite or Microsoft 365 Enterprise plans).

Summing Up

Most organizations have a mixture of content that needs to be protected inside and outside Office 365. The unified labeling version of the AIP client delivers this functionality today. In the future, native support in the Office apps will create a more integrated solution for Office content, but you’ll still need to deploy an AIP client to handle content stored in file servers and other non-Office 365 locations.

Still confused abut AIP, labels, encryption, and Office 365? We suggest you read Chapter 24 of the Office 365 for IT Pros eBook where this topic is covered in detail.

The post Unified Labelling Version of Azure Information Protection Client Now Generally Available appeared first on Office 365 for IT Pros.

Paul and Tony Debate the Key Question of the Day

Paul Robichaux and I both contribute to the Office 365 for IT Pros eBook, and we both work with Quadrotech, an ISV specializing in migration to Office 365 and the management of data once it reaches Office 365. Paul is the Chief Technology Officer and all-round nice guy, and I’m a board member. And of course, Quadrotech has been the sponsor for Office 365 for IT Pros for the last three years.

Recently, Paul and I came together to debate the changing role for Office 365 Admins in front of a video camera. The location was a nice library in a hotel in Palma de Mallorca, but that’s not important. What is important is the discussion we had about how to cope with the ever-changing world of Office 365 and that you can watch the video on YouTube. We hope you like it.

The post The Changing Role of Office 365 Admins (Video) appeared first on Office 365 for IT Pros.

New Video from Quadrotech

In another video covering interesting topics related to Office 365, I had the chance to discuss the complexities involved in tenant-to-tenant (T2T) migrations with Mike Weaver of Quadrotech. Mike is the product owner of Quadrotech’s Cloud Commander T2T product, so he’s deeply interested in the topic.

Right now, I think it’s fair to say that the industry has mastered the issues involved in moving Exchange Online, SharePoint Online, and OneDrive for Business data from one place to another, including T2T. The big challenge is now with applications like Teams and Planner because Microsoft hasn’t yet released APIs to allow streaming of chat and application metadata at scale. That capability is promised, but it hasn’t yet been delivered to ISVs.

Corporate Transformations Aren’t Easy

The nature of T2T is that it is usually part of some corporate restructuring (mergers, acquisitions, split-offs, divestitures, and so on). As such, the technology issues are often less challenging than the legal and business issues. For this reason, it’s hard to say that T2T products will ever perform a complete restructuring of an Office 365 tenant, but it’s reasonable to expect that they can automate many common processes like moving data, making sure that email continues to flow, preserving permissions, making sure that data governance isn’t compromised, and so on. Today, T2T projects often have to resort to manual or bespoke processes to complete a transition, but over time I expect out-of-the-box products to handle the majority of the work involved in a corporate transformation.

Business doesn’t pause for technology and T2T will continue to be a need. It’s an interesting topic. I hope you enjoy the video on YouTube. The show is only 15 minutes long.

For more information on Office 365, read the Office 365 for IT Pros eBook. Cover-to-cover, the 550,000 words and 1,150 pages should take you a month or so. But at least you’ll be informed at the end. At least, that’s the theory!

The post The Complexities of Office 365 Tenant to Tenant Migration appeared first on Office 365 for IT Pros.

A Profusion of Teams Can Consume Storage

When Teams creates a new team, it provisions a SharePoint Online team site along with other resources like a shared notebook and wiki. All of this is goodness, unless you like managing SharePoint storage manually.

SharePoint Site Storage Management

By default, SharePoint Online uses a central pool of storage that all sites draw upon on an as-needed automatic basis up to a maximum of 25 TB per site. Sounds good, because who wants to keep a close eye on site storage quotas to adjust them whenever sites need more space to allow users to store documents and do other useful work. But the downside is that if you allow free creation of Office 365 groups and teams, the central pool can be absorbed quicker than you anticipate and force the tenant to buy more storage from Microsoft just to keep operations running.

Enterprise tenants get 1 TB of SharePoint storage plus 10 GB per licensed Office 365 account. The new SharePoint Online Admin Center makes it easy to see how much storage the tenant has and what sites are consuming most storage. You can also export details of sites to a CSV file to dice and slice the data as you want.

If you use Office 365 retention policies to make sure that documents are kept for specific periods, you’ll discover that more storage is consumed because SharePoint must keep copies of deleted files. In any case, most tenants are happy to leave SharePoint to manage site storage automatically, which is the default management setting for Office 365 tenants. You only need to change the Site storage limits setting to Manual in the SharePoint Admin Center if you want to control the storage allocation for individual sites.

Controlling Individual Site Storage

One reason why you might want to control storage for individual sites is when a tenant makes extensive use of Teams and you don’t want the sites created for teams to be able to grow to 25 TB. In this scenario, you can switch the Site storage limit setting to Manual and then:

• Edit the storage quota for each site through the SharePoint Admin Center, or
• Use PowerShell to set a storage quota for every site associated with Teams and then adjust the quota upwards as necessary for individual sites.

Given the number of sites that you might need to process, the second option (PowerShell) is best.

Setting Storage Quotas for SharePoint Sites with PowerShell

The only complication we face is that the cmdlets needed for the job are spread across three modules: Teams, Exchange Online, and SharePoint Online. Once you’ve loaded the modules and connected to the three endpoints with a tenant administrator account, the code to update sites is pretty simple:

• Find all teams.
• Find the SharePoint site URL for each time (already covered in a previous post).
• Update the storage quota for the site.

Here’s some code to do the work. In this example, we set a 20 GB quota for each site with a warning limit at 98% of quota:

# SetTeamsSitesStorage.PS1
# Set the storage for the SharePoint sites belonging to Teams to a certain storage value
#
# Find Teams
Write-Host "Finding Teams in the Tenant..."
$Teams = (Get-Team -Visibility Public | Select DisplayName, GroupId)
ForEach ($T in $Teams) {
    $SPOUrl = (Get-UnifiedGroup -Identity $T.GroupId | Select -ExpandProperty SharePointSiteURL)
    If ($SPOUrl -ne $Null) {
       Write-Host "Setting SharePoint Site quota to 20 GB for" $T.DisplayName
       # Set storage value for SharePoint site
       Set-SPOSite -Identity $SPOUrl -StorageQuota 20480 -StorageQuotaWarningLevel 20070 }
    Else {Write-Host "Can't Process storage update for" $T.DisplayName "- Please check SharePoint site" -ForegroundColor Red}}}

After you’ve set the storage quotas for the sites owned by Teams, you can set the Site storage limits setting back to Automatic to allow SharePoint to manage storage for the sites that don’t belong to Teams.

Of course, the problem with any procedure like this is that you need to periodically rerun the code to deal with newly-created sites. To avoid reprocessing sites, you could update one of the 15 customized attributes available for Office 365 groups when you set the storage for a site and check if the attribute is set the next time the script runs.

—————————————

For more on managing Teams with PowerShell, read Chapter 14 of the Office 365 for IT Pros eBook.

The post Limiting SharePoint Storage for Teams appeared first on Office 365 for IT Pros.

Office 365 Developers Take 237 Days to Fix Compliance Issue

In September 2018, I reported the failure of a PowerShell demo at the UK Evolve conference. The failure was not my fault (my code was, of course, immaculate). It was caused by a truncation of data in Office 365 audit records generated for group creation (the add group operation).

Bafflingly, the same code had worked perfectly during a similar demo at the European Collaboration Summit in late May. Something had changed inside Office 365 to cause the truncation. Checking the audit records in my tenant revealed that the change to the audit record structure happened between July 5 and July 11. And as it turned out, the truncation affected other group actions too, like adding a member to a group or deleting a group.

A Chat at Ignite

I reported the problem to Microsoft on September 12. Two weeks later, I met with some Exchange engineers at the Ignite conference in Orlando to review the problem. I’m not sure that Microsoft understood that a failure in audit records was a serious issue in terms of compliance, but I did my best to emphasize that it was unacceptable for audit records to be compromised. I went away from the meeting happy that the problem was understood and would be corrected.

Alas, the problem wasn’t quite as easily fixed as I anticipated. In fact, the fix only became available on May 7, some 237 days since the original problem report and 306 days since a code update introduced the issue to the Office 365 audit log. The fix also applies to the other group-associated events that were truncated before.

Holes Remain in the Office 365 Audit Log

Truncated records remain in the Office 365 audit log and will not be backfilled. This means that any group creation or update event stored in the audit log since early July 2018 is truncated. Office 365 E5 tenants have access to audit record for 365 days while the records for other tenants are cleared after 90 days. Untruncated events are available in Office 365 Cloud App Security or third-party products like Quadrotech’s Radar for Security and Audit that ingest audit data from Office 365 without going through the audit log.

Office 365 tenant administrators might not have been aware of the problem because Microsoft filtered the truncated events out from the set shown in Security and Compliance Center audit log searches. The only way to find the problematic events was with the Search-UnifiedAuditLog cmdlet. Hopefully, the fixed events will now reappear in the audit log search.

So So Slow

Since last September, I have been in contact with multiple people inside the Office 365 development group to try and advance the fix. It’s been a source of wonderment and frustration to me that Microsoft could leave an obvious gaping hole in an audit/compliance function for so long. It has not been their proudest hour.

In any case, the fix is in and truncation has stopped (at least for these records). We should be thankful for small mercies.

For more information about the Office 365 audit log and many practical examples of how to interrogate its contents, read Chapter 21 of the Office 365 for IT Pros eBook. We’ve been complaining about the truncation problem since last September because it affected one of the examples used in Chapter 21. All fixed in the next update.

The post The Sad Case of Truncated Office 365 Audit Events appeared first on Office 365 for IT Pros.