Microsoft to retire SCC’s eDiscovery experience after 30 October 2020

The Security and Compliance Center (also known by its old Protection Center name) in Office 365 has always been a strange beast, a hot mess that kept on growing for years without a clear idea. Different functionalities kept getting added, moved around, removed and at some point even Microsoft gave up on keeping a changelog and left us to explore the changes on our own.

Later on, at Ignite 2018 Microsoft announced a plan to “split” the SCC into two, specialized consoles – one for Compliance tasks and one focused on Security. While the intentions were good, the execution left a lot to be desired, as the initial versions of the two new consoles were pretty barren. This remains true for the Security center even year and a half after it reaching a “GA” status, and to date the new portal looks more like a project some intern put together and is miles away from being any real replacement of the related functionalities exposed within the SCC or other parts of the M365 suite.

But progress is progress, and Microsoft did made some significant improvements to the Compliance center, including the new Unified Audit log experience, Communication compliance, Insider Risk management, to name just a few. eDiscovery has also been a part of the new console, but hasn’t received much attention until now, with only minor improvements made to the “landing page” experience. Now, Microsoft decided it is time to move the eDiscovery experience over to its new home, as the following notice on top of the current experience informs:

In typical Microsoft fashion, the link included at the end of this notice actually redirects you to the same old Security and Compliance Center, whereas the corresponding link over at the Advanced eDiscovery page does redirect to the correct page over at the Compliance Center. But hey, why would you expect Microsoft to suddenly change their habits and start testing stuff pushed to production? 🙂

Anyway, as the notice above suggests, the redirect will happen in few days, namely October 30. A post over at the Message center (MC223174) gives a bit more info, assuring you that “there should be minimal impact to your organization”. I expect this to be the case, as the only thing that’s currently changed is the overall look and feel of the “landing” page. In all fairness, we do get better filtering capabilities, as well as option to Group cases based on status. We also get a Share functionality, which generates a deep link to a specific case, which you can share over email/Teams or copy directly. Lastly, you can also Export a list of all cases as a CSV file.

Working with the actual eDiscovery case, adding members to it, searches, holds, exports – it’s all powered by the same UI bits you’re familiar with from the SCC. Not only that, it even has the “old experience” bits from the initial release of the feature, which closely resembled the EAC UI. Overall, tons of legacy code is being carried over, and while this should ensure compatibility, it simply doesn’t “fit” within the new Compliance Center UI. But hey, that’s hardly the only such example, and if I know Microsoft, it will take them few more years to get rid of the old bits 🙂

On the positive side, this move should allow Microsoft to clean up the code and streamline the overall experience, as well as focus on providing new improvements. Whether the (standalone) Content search experience will follow suit is not clear from the notice/MCC post, but I would expect this to be the case.

Posted in Microsoft 365, Office 365 | Leave a comment

Listing all custom attributes in Office 365

While investigating a potential issue with one of our products, the question of whether any object within our AD/Azure AD has any of the customattributeXX populated popped up. Now, listing these for a given user/mailbox or a set of users is straightforward enough, but since we’re talking about a set of 15 attributes, each of which can potentially have a non-null value, and we want to cover all the relevant objects in the company, I was looking for a “quick” solution.

Well, coming up with one took an embarrassingly long time, but at the end I did manage to do what I want with a simple one-liner. At first, I tried various iterations of filtering and where-object clauses, none of which helped much. Then, I remembered the good old “hidden” PSObject object, which basically holds all the output information. More specifically, we can expand its Properties property (OK, these are getting annoying, but are not intended), then use a filter against both the Name of a given property, and its Value. This in turn gives us the ability to check any properties that match the “customattribute” string, while at the same time also checking if any of the attributes has an actual non-null value. Since we don’t care about which specific attribute has a value, as long as one of them has it, we can afford somewhat relaxed syntax.

Without further ado, one can use the cmdlet below to get a list of all the mailboxes within the organization, for which at least one of the CustomattributeXX has a non-null value.

Get-Mailbox -ResultSize Unlimited | ? {$_.PSObject.Properties | ? {$_.Name -like "CustomAttribute*" -and $_.Value} }

Since other objects can also make use of said attributes, an alternative approach would be to use the Get-Recipient cmdlet instead:

Get-Recipient -ResultSize Unlimited | ? {$_.PSObject.Properties | ? {$_.Name -like "CustomAttribute*" -and $_.Value} }

Get-User unfortunately does not expose the custom properties, so you cannot use it for this purpose.

And in case you care also about the ExtensionCustomAttributeX attributes/values, you can use the following:

Get-Mailbox | ? {$_.PSObject.Properties | ? {$_.Name -like "*CustomAttribute*" -and $_.Value} }

or if you want to only list the extension ones:

Get-Mailbox | ? {$_.PSObject.Properties | ? {$_.Name -like "ExtensionCustomAttribute*" -and $_.Value} }

That’s it for today’s tip 🙂

Posted in Exchange Online, Office 365, PowerShell | Leave a comment

Accessing audit events for Microsoft 365 Group mailboxes

As a follow up to one of my previous posts, here’s the *supported* method of querying audit events for Office 365/Microsoft 365 Group mailboxes. In a nutshell, you should use the unified audit log instead of the good old Search-MailboxAuditLog cmdlet, which for the record still only works for group mailboxes that have a primary SMTP address associated with the default domain.

Without further ado, here’s an example that will list all the audit events for a given group for the specified time period:

Search-UnifiedAuditLog -StartDate "01 Jul 2020" -EndDate "01 Sep 2020" -FreeText cf3b5ccf-5571-46bb-9032-a68011a99260

where the GUID value specified for the –FreeText parameter corresponds to the ExchangeGUID of the group’s object. While other identifiers might also work, this is the *supported* method to query the Unified audit log for any Exchange-specific audit entries. Note that using the –ObjectIds parameter will not work here, it will always result in zero events regardless of which specific identifier you’ve provided.

You might want to further scope down the results to just mailbox audit events, by specifying ExchangeItem as the RecordType. In my experience, using the ExchangeGUID value will return just Exchange-specific events, so for the purposes of the task at hand it should suffice. Using the group’s email address will return some AzureAD events as well, while using the ExternalDirectoryObjectId will return even more AzureAD associated events. And yes, if you need a full set of events across all services, you’ll probably need to run the query multiple times.

For the sake of completeness, here’s the output of the Get-MailboxFolderStatistics cmdlet for the given group mailbox, which reveals exactly three audit entries, as returned above:

Get-MailboxFolderStatistics cf3b5ccf-5571-46bb-9032-a68011a99260 -FolderScope Recover | ft Name,Items*

Name              ItemsInFolder ItemsInFolderAndSubfolders
----              ------------- --------------------------
Recoverable Items             0                          3
Audits                        3                          3
Calendar Logging              0                          0
Deletions                     0                          0
DiscoveryHolds                0                          0
MigratedMessages              0                          0
Purges                        0                          0
SubstrateHolds                0                          0
Versions                      0                          0

And the error you will get if you insist on using the good old Search-MailboxAuditLog cmdlet:

Posted in Exchange Online, Microsoft 365, Office 365, PowerShell | Leave a comment

Azure AD Sign-in logs for service principals and other recent improvements

The Azure AD sign-in logs are an indispensable tool for troubleshooting and investigating security-related incidents. For years they had a major flaw though – no records were being generated for any login made by using the client credentials grant flow. Well, Microsoft has finally delivered on this front, so rejoice!

To access the service principal login entries, you can use the Sign-ins tab in the Azure AD blade, then hit the Service principal sign-ins tab. Note the banner on top, it indicates that I’m using the new Preview experience, which you must switch to in order to get the SPN sign-in logs.

By default entries from past 24h will be displayed, but you can adjust the window to up to 30 days by using the Date selection dropdown. Other settings include the option to toggle between local and UTC timestamps, control how entries are being aggregated (you can choose between 1 hour, 6 hours, 1 day) and add optional filters, such as the Service principal ID or name, IP address, Resource, and more.

The entries themselves are represented in aggregated view, and you have to expand a given group in order to get additional details on a particular sign-in. Under the Details pane, you will see info as to the date the activity was performed, status, application, resource and service principal details, IP address and resolved geo-location. Comparing the details with a “regular” sign-in, you will note a lot of missing data, most notably the Conditional access details. Unfortunately, Conditional Access policies still do not apply to logins performed via the client credentials flow, making it that more important to be able to report on any and all activities performed via a given application.

If needed, you can Download the data in CSV or JSON format. For the former, the file name will resemble something like “ApplicationSignIns_2020-09-26_2020-10-03”. You can also Export the data to a Log analytics workspace, which is Microsoft’s preferred method of working with the sign-in logs. At this time, the service principal sign-in logs do not flow into the Unified Audit Log within Office 365, aren’t consumed by MCAS and cannot be accessed via the Graph API, making the Azure AD blade and Log analytics your only choices. Support for Graph API should be coming fairly soon, as evident from the method used inside the portal, namely querying an Azure AD Graph endpoint like the below one:’1d’)?$filter=(createdDateTime ge 2020-09-29T10:45:04.987Z and createdDateTime lt 2020-09-30T10:45:04.987Z)&$top=50&$orderby=createdDateTime desc&source=kd

It’s also interesting to note that no “first-party” service principal sign-ins are being exposed, which is probably for the best, given the number of entries this will result in. Most organizations will likely only care about any entries corresponding to applications they own, and third-party integrations.

Some other interesting news below, you can skip the rest of the article if you only care about the SPN Sign-in logs.

First, an updated consent dialog can be seen below:

Next, we have updated branding controls, including the option to specify dark-theme images. More importantly, we can now use basic markdown-style formatting for the text control, including bold, italics, underline and hyperlink formatting:

  • Hyperlink: (link)
  • Bold: **text** or __text__
  • Italics: *text* or _text_
  • Underline: ++text++

The hyperlink controls in particular might bring some unease, as for years we have been training users not to click anything on login pages, but on the other hand can be useful for redirecting people to your helpdesk page and such. Below is an example of how the response looks like in code and on the page:

{“Username”:””,”Display”:””,”IfExistsResult”:0,”ThrottleStatus”:0,”Credentials”:{“PrefCredential”:1,”HasPassword”:true,”RemoteNgcParams”:null,”FidoParams”:null,”SasParams”:null,”CertAuthParams”:null,”GoogleParams”:null},”EstsProperties”:{“UserTenantBranding”:[{“Locale”:0,”BannerLogo”:”″,”BoilerPlateText”:”<p>Bla bla bla bla\n<a href=\”\” rel=\”noopener noreferrer\” target=\”_blank\”></a></p>\n”,”KeepMeSignedInDisabled”:false,”UseTransparentLightBox”:false}],”DomainType”:3}…}

In addition, we should soon be getting mobile-specific customizations.

On PIM’s side of things, new Alerting experience has been made available, as well as a preview of Discovery & Insights. This includes a new wizard-driven interface to help you reduce the number of permanent role assignments, including support for service principal assignments. Make sure to check this Ignite session for additional details on this:

Posted in Azure AD, Microsoft 365, Office 365 | Leave a comment

New reports layout and new Forms report in the Microsoft 365 Admin Center

While doing some fact-checking against the reports page within the Microsoft 365 Admin Center earlier today, I noticed that we now have a new layout for it, as showcased below:

Front and center, we have the Active users report in Graph form, showing activities across the different workloads for the past 30 days. While you can change the reporting interval using the dropdown in the top right corner, if you want to perform any other modifications or export the data, you should head over to the details page. Incidentally, there seems to be no way for doing so for the Active users report, apart from having to click on the View more button under any of the other report entries presented on the page and using the “switcher” there.

Speaking of which, the other tiles correspond to the following reports:

  • Microsoft 365 active users (per service)
  • Microsoft 365 App usage
  • Email activity
  • Microsoft Teams activity
  • OneDrive files
  • SharePoint files
  • Office activations
  • Yammer activity
  • Forms activity
  • Skype for Business activity

Lastly, a link to the Microsoft 365 usage analytics solution for PowerBI is presented.

Clicking the View more button under any of the above mentioned entries will take you to the corresponding “standalone” report page, which has the old look and feel. Nothing is changed in terms of functionality here it seems, so you can get all the familiar controls, including the “switcher” on top.

In other news, a new Microsoft Forms activity report has been added, which as the name suggests covers activities in Forms. The chart on top of the report page will show the number of users that have created or responded to a Form, while the activity tab should cover the total number of created and filled in forms, including those by anonymous users. The data seems to be a bit off though, as the table representation doesn’t match the graph above. For example, while I do have several forms created over the past few months, mostly for collecting questions for our V2 Exchange PowerShell webinars, my user is shown with last active date of 18 December 2019, and a count of zero for the number of forms created field.

On the other hand, the graph representation seems to match the actual activities performed in Forms, including the number of responses by anonymous users. Since I haven’t seen any official announcement for this report yet, and there doesn’t seem to be a matching Graph API endpoint for it either, one can assume that this is still in beta/preview, so over time these issues should be addressed.

Posted in Microsoft 365 | Leave a comment