Unified audit log search available in the new Compliance center

The new “specialist” Compliance and (separate) Security consoles have been available for Microsoft/Office 365 customers for a while now, but even though they are in “GA” status, there’s a lot of functionality missing compared to the good old Security and Compliance Center. This should hardly come as a surprise, given the way most teams within Microsoft release features.

One such glaring example was the lack of the Audit log search functionality, which is just now made available in the Compliance center. There are some minimal changes in the UI that might be used as an excuse of why such important feature took that long to be ported, but on the positive side, it does give me something to write about. So let’s take a quick look at the Audit page (yes, that’s how it’s called now, just Audit).

To access the Audit page, open the Compliance Center, then on the left hand side click the “Show all” button on the bottom, then hit “Audit”, or use this direct link: https://compliance.microsoft.com/auditlogsearch. The UI will look familiar to anyone that has used the Audit log search feature in the SCC, with the controls simply rearranged in a different manner. For comparison, here are the corresponding looks for the “old” (SCC, top) and “new” (Compliance center, bottom) UI:

One of the differences is that while previously a yellow notification bar was displayed on top if audit log collection was not yet enabled for the tenant, now you will see the Start recording user and admin activity button. In addition, all the other UI elements will be disabled, whereas the SCC UI still allowed you to play with them, and generated errors upon executing any search.

The rest of the controls work in a similar way to that of their SCC counterparts, with some bits improved to use the “styling” of the new UI. For example, the date selection fields feature easier selection for the year, similar to that we’ve seen in other parts of the “modern” portal(s). Possibly the biggest change here is the Activities dropdown, which now lists everything in a single column, taking a little longer to scroll down to the events you need. The search functionality is still the preferred method to narrow them down, given the number of entries currently exposed, but in situations where you don’t know the actual event name, you still have to scroll the list.

In addition, selecting all event types for a specific workload by clicking the corresponding “workload name” entry is no longer possible from the dropdown. For such operations, you can rely on a newly introduced pane, surfaced by clicking the “View all activities” link. There, you can click the “Select all” entry under each group to include all events from a given workload, or search for/select individual entries as needed. The number of selected entries is shown next to each section, but you don’t get to see the total count, and yes, limitations still apply here. You can also use the “Expand all”/”Collapse all” toggles to quickly navigate the list of entries.

Hovering over the Activities dropdown will bring up a tooltip with all the currently selected events, which might be used to get them all at a glance and should be easier compared to scrolling the entire list.

Apart from the minor UI adjustments, the Audit (log search) functionality works in pretty much the same way as in the SCC. The list of matching events will be populated below the selection controls, and you can click each entry to get additional details (which brings forth the same pane used in the SCC). Up to 150 results will be loaded by default, with more populated as you scroll down the list. You can use the Export button to get a CSV file with the details for the currently displayed events, or get all matches for the selected criteria.

The Filters button which previously brought forth “client-side” filtering capabilities is replaced with a nav pane too. While it does look easier on the eyes, the downside is that results are no longer filtered client-side first and instead are refreshed from the service, making the Filter controls behave in the same manner as the selection controls above. In addition to the longer loading times caused by this, you can no longer do things like filter by say “Service Account” for the user entry, as the corresponding control only accepts entries that can be resolved against users within the tenant. Another example where this fails is for narrowing down events that are not listed in the selection dropdown, for example when you want to filter by given Exchange cmdlet, say Set-Mailbox. So you’re bound to export the results to CSV and filter them there, which is probably the better experience anyway.

Speaking of missing functionality, the ability to create an Alert policy directly from a selected event is not currently available. The same applies to the recently introduced audit retention policies, which control the retention duration for different event types as we covered in a previous article. But since this is the first iteration of the feature in the new Compliance console, we should expect Microsoft to address these shortcomings over the next weeks/months.

Posted in Office 365 | Leave a comment

Some thoughts around licensing for Microsoft’s cloud offerings

As Microsoft’s online services continue to expand in reach and branch in more and more areas, it has become increasingly difficult to keep track of just how many different SKUs, service plans, features and so on exist. Even within Microsoft, it is hard to find a single person that can make sense of this mess, and over the years we’ve relied on different blog posts, documentation articles and GitHub repos for information around this. Still, no single resource lists everything that’s available currently within Microsoft’s cloud offerings, and as new services are released on a regular cadence, whatever resource we have often become outdated.

No, I’m afraid I don’t have a complete list either. Even if I did, I would not be able to keep it up to date, or provide all the relevant details, as that would require someone with “internal” access. What I do have is a very long list of different SKUs/service plans that we have collected over a number of years as part of our reporting solutions. Since it has been some time since I last bothered looking into this, the sheer number of entries caught me by surprise. I don’t have the resources (or the desire) to maintain a complete list, so I’ve reached out to the maintainers of the above listed sites and offered them my findings. And I can spend some time offering generic details and remarks here 🙂

The current list we have has around 650 entries in total, most of them missing details such as the GUID representing the unique SKU/service plan, which makes it hard to filter out duplicate values. There’s also the question on what represent a “duplicate”, as we can have  multiple variations of the same service targeted for different markets. Take for example Exchange Online Plan 1, which can be found in its “vanilla” flavor, variations for students, alumni and faculty staff for EDU SKUs, variations for Government SKUs, and so on:

EXCHANGESTANDARD
EXCHANGESTANDARD_ALUMNI
EXCHANGESTANDARD_FACULTY
EXCHANGESTANDARD_GOV
EXCHANGESTANDARD_STUDENT

And that’s just one example, additional suffixed you might see across different SKUs/service plans include: _STANDALONE,  _EDU, _ADDON (with all of the former), _VIRAL (for “viral” subscriptions), _GCCHIGH and _DOD for the USGOV ones, and few others I’m probably missing. Sometimes, they don’t differ in terms of actual functionality, other times this is not true. Then we have region-specific services such as the PSTN ones:

PSTN1_DE
PSTN1_GB
PSTN2_GB
PSTN2_US
PSTN5_GB

Then, we have services that have changed their licensing models numerous times, contributing to the mess. I’m looking at you, Power platform! Here are the Flow (“Power Automate”)  entries for example:

FLOW_CCI_BOTS
FLOW_CUSTOMER_SERVICE_PRO
FLOW_DYN_APPS
FLOW_DYN_P2
FLOW_DYN_TEAM
FLOW_FORMS_PRO
FLOW_FOR_PROJECT
FLOW_FREE
FLOW_O365_P1
FLOW_O365_P2
FLOW_O365_P3
FLOW_O365_S1
FLOW_P1
FLOW_P2
FLOW_P2_VIRAL
FLOW_P2_VIRAL_REAL
Flow_Per_APP_IWTRIAL
FLOW_PER_USER
FLOW_PER_USER_DEPT
Flow_PowerApps_PerUser
FLOW_SALES_PRO

22! Just! for! Flow! And that’s with the GOV and similar variations removed from the table! Similar findings can be made around the other components of the Power platform.

As an exercise, I tried to trim the list of all the “duplicate” service plans, hoping it will shrink down to a more manageable size. Unfortunately, even with the most liberal use of the term “duplicate” I couldn’t get it to less than 300 entries. Insane, right? And it will only grow.

Now, it’s easy to blame Microsoft and say they release more and more SKUs/services just to get more cash out of their customers. That might be partly true, but there’s another aspect of this – controlling access to features/services. For the majority of features/services within M365, access is granted by licensing the user, and similarly, access is blocked by toggling the corresponding service plan entry off. This is not universally true across all features/services, as Microsoft doesn’t enforce licensing requirements in code for many of its products. But, it illustrates the need for having all those individual service plan entries listed under a given SKU or as standalone plans.

Are you convinced yet that licensing is a science on its own? 🙂

Posted in Office 365 | Leave a comment

Microsoft to retire New-MoveRequest for local mailbox moves in Office 365

In a short announcement posted over at the MTC, Microsoft announced plans to retire the self-service mailbox move functionality in Exchange Online. Said feature, made available via the New-MoveRequest cmdlet few years back, was initially launched as a tool to allow admins to initiate go-local moves.

Its use however quickly spread beyond that scenario, as moving the mailbox to a different database has the side effect of restamping some properties and fixing some rather common issues. It also helps in situations when the MRM processing of the mailbox fails, say due to some issue with the underlying hardware, which Microsoft’s monitoring failed to capture in a timely manner.

Personally, I’ve used the cmdlet several times in my own small tenant, mostly as troubleshooting tools for such minor problems. As I keep my PowerShell transcripts, I can see that the first such use was around the end of 2016, so the cmdlet has been useful to me for at least three good years. It’s biggest benefit is probably the fact that it allowed you to avoid raising a support issue and dealing with the not-so-competent agents.

As pointed by an observant user over at the MTC, even Microsoft’s own documentation articles recommend the use of this cmdlet as troubleshooting tool. So there is definitely some demand for it. But unless Microsoft steps back on their plans, you can expect the cmdlet to stop functioning in little more than a month’s time.

P.S. None of this affects the on-/off-boarding mailbox moves, just “in-service” ones.

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

PowerShell 7 is out, compatibility mode saves most Office 365 modules

Two years ago, the first major version of PowerShell Core got released. At that time, the product was quite crippled, as the move from .NET to .NET Core broke almost every non-bundled module out there. In turn, this resulted in quite disappointing adoption numbers, as Microsoft noted a year later. I mean, who would have thought that breaking compatibility with modules/APIs that have been used for years across every Microsoft product would actually affect people. Go figure!

The .NET switch problems applied to any module related to Office 365 as well. Such modules either failed to load altogether or threw errors upon executing specific cmdlets, as I covered at length in this article. Using the Exchange Online remote PowerShell cmdlets was pretty much the only thing that did work, which comes as no surprise as those are effectively proxied by the client and run on the server, with any input/output getting deserialized.

So, after reversing their stance and prioritizing compatibility for the next release, did Microsoft solve all those issues with PowerShell 7 and Office 365? While there is a definite improvement in the “core” PowerShell functionality, most Office 365 related modules will still fail to work *natively* as they simply don’t support PowerShell Core. But, Microsoft introduced some compatibility improvements, which allow such modules to run in a local Windows PowerShell instance, to which PowerShell 7 proxies all input/output. Which adds some overhead, but in most cases works quite acceptable.

The TL;DR version is that compatibility mode saves the day, albeit I would have preferred if the corresponding teams within Microsoft actually released versions of their respective modules that natively support PowerShell Core. Oh well, beggars cannot be choosers. So let’s go over the individual modules.

The good old MSOnline module will immediately be imported in compatibility and didn’t throw any issues with the few tests I performed. Using the Connect-MsolService cmdlet without any parameter produced the standard ADAL credentials prompt (yay Forms!) and voila:

Funnily enough, the Azure AD module, which is much more recent release compared to the MSOnline module, threw an error immediately. Even using the “pass token” trick that helped me connect last time failed:

Which is very puzzling, considering the module has been supported in Azure Cloud Shell for a while now. The good news is that loading the module in compatibility mode works:

Next, we move on to Exchange Online PowerShell. As mentioned already, the good old “remoting” method works just fine on PowerShell Core/7, yay. What about the new, V2 module? Well there’s good news, and bad news. The bad news is that the module has a dependency on a binary not ported to .NET Core yet and in turn throws an error when trying to connect. The good news is that this only affects the “old-style” cmdlets, and you can use the new REST-based ones just fine:

For the “old-style” cmdlets, use the –UseWindowsPowerShell switch or you can just use the good old PS remoting method. Of course modern auth support will soon be required and this will no longer be possible, but until then I can take advantage of the CA policy I’ve configured with my home PC excluded and run my “O365 connectivity” script:

Just to be clear, I’m not recommending you folks to use the “old” connectivity method, in this day and age protecting your accounts with MFA is a must. But boy, it’s convenient… 🙂

Moving on, the Microsoft Teams module will happily authenticate you (via the device code flow, which is far from ideal), but will then fail with another dependency:

So, back to using the compatibility mode:

Lastly, the SharePoint Online module also fails with ADAL dependency, but works OK if you import it via the compatibility switch.

At this point I got bored and skipped testing all the remaining modules 🙂

Do note that whatever remarks I made above are all said with respect to Office 365. PowerShell 7 is a major release with important compatibility and performance improvements, tons of functionality added, and the .NET Core 3.1 support brings support for Windows Forms among other things. Better error handling, support for Files on demand, parallel ForEch-Object, very useful new operators and more awaits you.

Go update now: https://github.com/PowerShell/PowerShell/releases

Posted in Office 365, PowerShell | Leave a comment

Windows update changes the way we work with files downloaded from the internet

So most of you are probably familiar with the Attachment Manager feature in Windows, which “stamps” files downloaded from the internet and works together with the SmartScreen feature to protect you from opening them accidentally. I wont go into much details on how it all works together, but for our purposes I will mention the generic steps of the process: you download a file (say .reg or .ps1 from the internet), some metadata is added to the file’s Alternate Data Stream, and when you try to open it Windows will display a window such as the below:

 

 

 

 

 

 

 

 

(If you are interested in more details around this process, read for example this article.)

To my surprise, when earlier today I downloaded a PowerShell script file I needed, I was greeted with a Windows Store window instead, telling me that I’m trying to install some app?!

My initial thought was that the association of the .ps1 file was changed to some new app, downloadable from the Store (Windows Terminal should eventually get out of preview). Why would anyone do that is beyond me, but nevertheless I went and checked the current file association for .ps1 files on my machine. It was unchanged – Notepad (you definitely don’t want to change it to something that directly executes .ps1 files!). Yet, when I double-clicked the file it still generated a Store window.

Right-click -> Open resulted in same behavior. Right-click -> Edit opened the file in the PowerShell ISE, as expected, so obviously there was nothing wrong with the file itself. Remembering that I just downloaded the file, I went and manually unblocked it via the properties dialog (ISE bypasses that process btw), and then it opened just fine in Notepad. Go figure.

So apparently, the latest set of Windows updates have changed the process and forced yet another metro-driven crappy experience. Neither the message itself, nor the controls surfaced (one opens the Store, another one the Apps & features Settings page)  are of any help. Typical Microsoft Genius at work!

So there, I got this off my chest 🙂

Posted in Uncategorized | Leave a comment