Office 365 Snippets – September 22, 2016
Office 365 Admin Center and Unlicensed Accounts
The new Office 365 Admin Center is now officially a year old. Originally announced with the normal fanfare beloved by Microsoft marketing in September 2015, the new console was supposed to roll out over the weeks following the subsequent announcement in March 2016. Perhaps Ignite will be the time when Microsoft concludes that the preview status can be ditched.
Before then, some changes are necessary in how the new Office 365 Admin Center reports unlicensed user accounts. As you can imagine, any service that charges on a per-user basis is likely to be picky when it comes to noting which accounts are licensed and which are not. The same goes for customers, who hate paying for accounts that are unused. To help tenant administrators, the Office 365 Admin Center has a filter that purports to list all unlicensed users. The bad news is that the filter doesn’t work. At least, it does work, but it confuses matters by including accounts that don’t need to be licensed, like those used for room or resource mailboxes, or site mailboxes. The accounts used for these objects are all disabled and are never logged into.
The latest problem arose with the recent introduction of guest user access for Office 365 Groups. Guest users are represented by accounts in Azure Active Directory and don’t have or need a license. Yet the Office 365 Admin Center insists on listing guest user accounts and has caused some tenant administrators to wonder whether these accounts have to be licensed. They don’t. Period. It’s just the Office 365 Admin Center using a stupid filter that is technically inaccurate (all the accounts listed lack licenses) but real-world useless.
Sites and Office 365 Groups
Speaking of Office 365 Groups, the long-promised integration between SharePoint team sites and Groups continues to create many questions. Not much has shown up yet, but I hear that things are coming soon (like Christmas). Hopefully all will work before my co-presenter Benjamin Niaulin gets up to tell the Ignite crowd all about the brave new world of Team Sites and Groups at our “Ultimate Guide to Office 365 Groups” session next Wednesday. Nearly a thousand people have signed up to come along and it should be a blast. If you’re in Atlanta and plan to attend the session, come early and get the best seats. Information about all of the Ignite sessions covering Office 365 Groups can be found in this Sway.
A Bug in ActiveSync Reporting
Both Exchange on-premises and Online feature a nice range of PowerShell cmdlets to manage different aspects of device management for Exchange ActiveSync clients. The cmdlets don’t provide the same level of functionality as Microsoft’s Enterprise Mobility Suite (EMS), but they do a good job for many companies.
In any case, last week I encountered a problem with the Get-MobileDeviceStatistics cmdlet where executing the cmdlet generated a Watson dump. For example, this command fetches details of all ActiveSync devices known to a tenant (or on-premises organization) and pipes the devices to Get-MobileDeviceStatistics to report usage information.
[PS] C:\> Get-MobileDevice | Get-MobileDeviceStatistics
All goes well until PowerShell reports that an unexpected error has occurred, as shown in Figure 1.
Microsoft has accepted that the bug exists and the problem is being worked on. If you depend on Get-MobileDeviceStatistics to generate reports, you’ll just have to wait until a fix appears.
How Many Users Are Affected by an Office 365 Outage?
The way that some commentators talk about Office 365 outages, you’d imagine that the service is constantly breaking down. In many cases, assertions are made to justify the need for add-on products designed to protect users in one way, shape, or form. In short, ample helpings of good old-fashioned FUD.
The actual truth is that problems occur within Office 365 on an ongoing basis, which is exactly what you’d expect for a global infrastructure serving hundreds of millions of users. It would be stupid to assume that anything else might happen given the huge number of moving parts that make up the service.
Facts indicate that few of the outages that occur affect more than a small portion of Office 365 as a whole, largely because Office 365 is distributed across twelve data center regions. Even a high-profile incident, like the nine-hour Exchange Online Protection outage on June 30, 2016, are confined to one or perhaps two regions. However, because Microsoft doesn’t reveal the information, it’s hard to quantify exactly how much of Office 365 is affected by any one problem.
Enter the Service Communication API…
The Service Communication API allows programmers to access information about Office 365 service health and outages. The API is used by third-party reporting and monitoring products to retrieve information for their dashboards and reports. You don’t need to write a lot of code to use the API as a blog written in 2014 explains how to access service health information from PowerShell. I’ll let you read the details from the blog, but the interesting thing is that the information that’s retrieved contains a property called AffectedTenantCount, which seems to report the total number of Office 365 users that potentially are affected by a service incident.
For instance, you might see something like this if you list the events extracted through the API. Some filtering occurs so that the only events that are provided are those that might impact your tenant, which is what the Office 365 Service Health Dashboard (SHD) displays.
Id AffectedTenantCount Status -- ------------------- ------ EX75391 6731231 Post-incident report published EX75672 6983060 Post-incident report published SP75824 6517625 Service restored LY75883 3002702 Post-incident report published SP76888 2318260 Post-incident report published EX77020 2303164 False positive SP77334 6641821 Service restored EX77366 6983146 Service degradation SP77401 6648986 Service restored EX77472 6995812 Service restored MO75335 0 Extended recovery OS75607 0 Service restored PB75643 0 Service restored YA75682 0 Post-incident report published
The Messages property for each event (not shown above) contains the text that appears in the Service Health Dashboard. I have no idea whether the count of affected users is accurate or how it is calculated, but I do find it interesting that the data exists and it is plausible that an incident might impact 6,731,231 users, as shown above for EX75391. Of course, this number is the high watermark for affected users. Capabilities such as cached Exchange mode for Outlook mean that many users are able to work without realizing that a problem exists when incidents happen.
More Odd Audit Entries
Scanning audit data for my tenant through the Security and Compliance Center, as you might do on a wet Sunday afternoon, I noticed a very odd “updated group” event (Figure 2). Seeing a user account called 00000002-0000-0ff1-ce00-000000000000 is enough to make the hairs rise on the head of anyone who cares about security, especially when there’s no logical reason why such an account exists or why it is updating a group (or doing anything else).
As it happens, there’s a perfectly rational explanation. The event was generated when I used the Outlook Groups for iOS app to edit the membership of a group. This app uses the REST-API for Groups to communicate with Office 365. Obviously the API impersonates the real user account that interacts with the group but fails to record that information. The odd user account is a system entity.
Much the same kind of impersonation appears to be at the root of the many audit events for SendAs operations generated by Office 365 Connectors.
In this case, I was able to reconcile an anomaly without much effort. However, you could imagine alarm bells going off if audit alarms sound to report that unknown user accounts are modifying objects. It’s never good when audit logs throw up data that is not easily explained. Microsoft needs to fix the Outlook Groups app to make sure that the correct audit information is recorded.
Inactive Mailboxes and Hybrid Deployments
I recently wrote about the usefulness of inactive mailboxes and made the point that they are a construct invented for the cloud to avoid the need for Office 365 customers to pay for unused mailboxes. The question then arose regarding whether you can use inactive mailboxes in hybrid deployments. In fact, the only difference is that the account associated with the mailbox is controlled on-premises in Active Directory. Assuming that the mailbox is placed on hold before an account is removed from Active Directory or moved to another organization unit that is not synchronized with the cloud, the mailbox will be deemed to be inactive and retained.
Because this is not a strictly supported scenario that is documented by Microsoft, it’s wise to test that your account management processes work with inactive mailboxes, including the steps that you take should the need arise to recover or restore data held in active mailboxes. It just makes sense.
On to Ignite
I’m heading to Atlanta on Sunday and have a busy week planned at Ignite and look forward to catching up with many friends and business acquaintances there. Stay tuned for all the news!
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.