Tony’s Office 365 Snippets – September 8

Tony Redmond

by Tony Redmond on 9/8/2016

Share this:
Print

Article Details

Date Revised:
9/8/2016

Applies to:
AIP, audit events, Azure Information Protection, office 365 groups, SendAs, Sway, team sites


People are figuring out how Office 365 Groups and SharePoint team sites might interact and realize that we don’t have all the answers. My fixation on SendAs audit events was fulfilled when I found an OWA bug that causes more events to be gathered. Sway and Power BI events might be about to show up in the Office 365 audit log. And Azure Information Protection continues to do a fine job of classifying documents.

Linking old Groups and old Sites

Now that the hullabaloo has passed around Microsoft’s announcement that every Office 365 Group will have a SharePoint team site and vice versa, the ramifications and complications of the news is sinking in and some questions have emerged. The most interesting so far is whether it will be possible to take an existing SharePoint team site and link it to an Office 365 Group. Some companies who have invested heavily in team sites are rather concerned that they might have to move a lot of data around to achieve the kind of integrated vision laid out by Microsoft.

I don’t think linking existing groups with sites will be possible, at least not without some engineering investment on the part of Microsoft, so this kind of mix-and-match processing might represent an opportunity for an entrepreneurial ISV. Provision of some administrative interfaces to manage the intermingling of groups and sites is also an “interesting” question that has no answers for now. We await the disclosures at Ignite with interest!

Befuddled users

Last week I reported on the first email scam directed at Office 365 users. Some rightly asked what was so different about this scam compared to all the other social engineering-based attempts to have users yield their bank account details and other confidential information. The best response I saw came in a note posted to the Office 365 Network, which said:

“Our organization sees credential prompts from web apps, Office client apps, Outlook, and other random places, each with a different UI. There's no way for me to tell users what the "real" one should look like, so it's completely plausible that yet another would show up in their O365 mailbox.”

The horrible thing is that the author might well be right. Too many prompts and queries for Office 365 credentials might blindside users to threats. That’s not a good situation.

Why OWA generates bad SendAs events

I reported how an Office 365 Connector could generate many SendAs events in the Office 365 Audit Log. Since then, I uncovered another odd way that SendAs events are generated. In this case, it’s when an OWA client is used to post a new conversation to an Office 365 Group (Figure 1). Posts made by Outlook or mobile clients don’t cause the same problem, so it’s something to do with the way that OWA has implemented the post function.

As it happens, OWA posts in a rather peculiar way in that the client first posts a temporary item in its view while the real content makes its way through the Exchange transport system where rules and other restrictions can be applied. For instance, a school probably has some words that it doesn’t want students using. Posts that contain those words can be blocked with transport rules. Once the item is processed, the real card is added to the conversation and OWA swaps the temporary card out. The reason why this happens is to prevent user anxiety that “my post hasn’t worked” while background processing proceeds. In any case, it’s obvious that something in the implementation causes Exchange to believe that a SendAs audit event needs to be logged. The case is now being investigated by Microsoft and I await their findings with some interest.

OWA posts SendAs events from a new conversation in an Office 365 Group to the Office 365 Audit log

Figure 1: SendAs event logged when OWA posts to an Office 365 group conversation

Sway and Power BI contribute Office 365 Audit events too

Speaking of audit events, I note that the Office 365 Audit Log report indicates that events originating from Sway, Power BI, and eDiscovery activities have shown up in the Audit log search picker (Figure 2). Exchange Online, SharePoint Online, and Azure Active Directory provided the initial feeds into the audit log and it was always planned that the audit log would pick up events from other workloads as soon as those workloads could provide the data.

It’s nice to see a plan coming to fruition, even if all of my attempts to persuade Sway to generate an audit event utterly failed during the week. I’m sure the events are en route to the log and will appear in due course. Or maybe the non-appearance of Sway events is a subtle hint that I should be making more use of Sway.

Sway events in the Office 365 Audit Log

Figure 2: Sway events appear in the Audit log search picker

Programmatic liking

I consider myself a pretty nice guy (at times) but I hate the whole “like” thing whereby people mark their approval of something by indicating a virtual thumbs-up. It smacks more of teenage infatuation than professional business in my book. Nevertheless, I note that MVP Glen Scales has once more done the world a service by explaining how to like an item programmatically using Exchange Web Services. Programmers of the world can delight in Glen’s code examples. I shall pass on to more fruitful pursuits.

Troubleshooting mailbox recovery

Microsoft obviously encounters many situations when administrators have discovered that they have deleted the wrong mailbox and don’t know what they should do to execute a recovery. In an effort to reduce support calls (and cost – but really to improve the customer experience), Microsoft has created a mailbox recovery troubleshooter; a walk-through guide as to what an administrator needs to do to recover a mailbox. It’s not a wizard and recovery requires some proficiency in PowerShell and knowledge of the various PowerShell modules that are involved, but at least it’s a step forward towards automation in this area.

Azure Information Protection works

I’ve been using Azure Information Protection for about two months now and can report that AIP does what it promises to make it easy for people to label and classify information, and, if required by policy, to apply an information rights management template to protect confidential items. Surprising myself, I instinctively check for a label when creating a new document (Figure 3). It’s not often that a technology takes hold so quickly, especially in the security domain, so the AIP team has done a good job.

An Azure Information Protection Policy active in a Word document

Figure 3: The Word document for this article is labelled “Internal”

Office 365 U.K. datacenters now live

Microsoft now provides Exchange Online and SharePoint Online services from U.K.-based datacenters in London and Durham (northern England). The new datacenters allow sensitive data such as that belonging to the U.K. Ministry of Defence to stay nice and safe on the “sceptred isle”. Some might even call it the first sign that Brexit will actually happen. In any case, only U.K. tenants who signed up since September 3, 2016 will be located in the new datacenters. U.K. tenants who signed up before this date have their data located in one of the EMEA datacenters in Dublin, Amsterdam, Vienna, or Helsinki. It’s possible to move tenants between Office 365 datacenter regions, but only after asking Microsoft really nicely and in the knowledge that the move might take up to 24 months to effect. This page has all the details for those who need it.

The voyage to the one true community

On September 2, 2016, Microsoft announced the launch of the Microsoft Tech Community (the editor in me asks why Tech couldn’t have been spelt out?), saying that it brought “multiple communities together in one central location to support discussions and best practice sharing across multiple Microsoft products and services. The Microsoft Tech Community is an evolution of the Office 365 Network, growing to support new Azure, Windows Server & SQL Server Communities and in the future, many more communities.”

This is a continuation of the plan to replace the Yammer-based Office 365 Community with a broader-reaching community that extends over many other Microsoft technologies. The Yammer-based network remains on plan to close on September 15, even if there’s no obvious sign of any of the valuable content that accrued in that network being moved over to the new one.

I have very mixed feelings about the new network. Having searchable content is all well and good, but I hate not being able to easily get at unread contributions in the different forums that I like to follow. The network remains slow and the user interface is unwieldly and unlikeable in my eyes. Microsoft is making changes and attempting to make things better, but the huge question remains why this transition occurred to a platform that exhibits every sign of being immature and unready. I’m sure I shall be told that I am wrong on this point, but you’ve got to call it as you see it…

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.


Topic: Office 365 Groups

Sign in with

Or register