Recover or Delete Office 365 Groups via the Exchange Admin Center

Last week, Microsoft started rolling a small update through the service, allowing us to restore (and delete) Office 365 Groups via the Exchange Admin Center. In case you have missed it, here’s the Message center post (MC125402):

and the corresponding Roadmap item:

The new functionality integrates seamlessly with the EAC and is very easy to use. Simply open the EAC and navigate to Recipients, then Groups, select the Office 365 Group in question and perform the necessary action. The below screenshot illustrates the important elements:

Behind the scenes, the EAC seems to be calling the Remove-UnifiedGroup cmdlet when pressing the delete button and the UndoSoftDeletedUnifiedGroup cmdlet when trying to restore the Group, as shown below:

Probably due to the expected delay in synchronizing the Office 365 Group status between Azure AD and ExODS, in my case I am being presented with an error message every time I perform a delete/restore operation in the EAC:

Remember that Office 365 Groups are “special” in this regard, with “notifications” being responsible to keep the object properties in sync across the different workloads.

Apart from the error message though, the action is performed successfully. If you check the Group status via the Office 365 admin center or the Azure AD PowerShell cmdlets, it will be correctly reflected. EAC will eventually “catch up” on it as well, so try few refreshes.

Additional details on the new feature and the Group recovery process in general can be found here:

Posted in Exchange Online, Office 365 | Leave a comment

Early look at the new Message Trace UI in Office 365

Ignite 2017 is long over, yet I’m still finding some interesting bits of information or feature announcements that I have somehow missed. One of the best examples is the session Carolyn Liu and Khushru Irani did on “Office 365 mail flow insights“.

In this session, among lots of other useful things, a short demo of the new Message trace UI was shown. The Message trace functionality is now homed in the Security and Compliance Center it seems, and thus it uses the same design elements. As the feature is still in development, no link is exposed on the left navigation menu, however some tenants seem to already have access to it via the following link:

For those of you that do not have access, here’s how the “landing page” for the new Message trace UI looks like:

Now, what you see on that page is basically some predefined “reports” as well as any custom ones you have “saved” and a list of the 10 most recently run Message trace reports (“auto-saved”). In addition, if you have requested a detailed message trace report, any queued/completed downloads will show up in the first section.

To run a new Message trace, press the New button and simply enter the criteria. Not much has changed here and we pretty much have the exact same options as exposed by the Get-MessageTrace cmdlet. It’s all packaged with a new look and feel, and in general it’s a lot more intuitive. If you want to get the list of all the messages, simply press the Search button without entering any criteria.

Once you get the list of results, you can click on any message to get the “detailed” message trace, i.e. the info that you would get by running the Get-MessageTraceDetails cmdlet against the message in question. It’s all available in the UI now and prettified with the new “joyous NDR” look and feel, which makes it that much easier to understand what’s going on. Additional insights as to forwarding, spam processing or mailbox rules that affected the message are all shown here.

Some other UI improvements are immediately visible. Color coding based on the message status is used, making it easier to spot any failed or delayed messages. The Export button allows you to export a list of all or selected messages to a CSV file. To help you select just the right messages, a new client-side filtering functionality is exposed, via the Filter results button. The Find related button makes it very easy to run a trace based on specific messageID – select the message in question and press the button to return all other messages with the same ID. Another improvement is the option to select the timezone in which to display the results, you can configure that by using the “custom” Time range control.

For additional details make sure to watch the hands on demo here:

Posted in Exchange Online, Office 365 | Leave a comment

Say goodbye to PhoneFactor, meet the new Azure MFA Server blade

A long time has passed since Microsoft purchased PhoneFactor back in 2012, but it seems like the days of the old “pfweb” portal are finally over. The new “MFA Server” blade in the Azure RM portal is now in Preview and you can find it under the Security section of the Azure AD Directory blade.

As you can see from the screenshot below, most of the settings have been migrated and get their own separate tabs in the MFA Server blade now. The biggest reorganization is with the Reports section, which now features a single Activity report tab. The Bypassed or Blocked users reports are not available and neither is the Fraud Alerts report. The email-notification feature for Fraud Alerts, Account Lockout and One-time Bypass is replaced with a global Notifications list, without the granular controls.

Some of the settings configurable form the blade apply across *both* Azure MFA and MFA Server, the selection is controlled via the Replication group dropdown where available. As a reminder, the Replication group selection was shown on the left navigation menu in the old portal, but only for tenants that use both modalities.

And that’s pretty much it. The changes are minimal, just with a fresh new look. The lack of a generic audit log for changes performed in the blade is unfortunate though, but I’m sure this will arrive once the MFA blade is in GA.

For the time being, the PhoneFactor portal is still active and you can continue using it. Getting to it however is becoming more and more challenging, now that almost all Azure resources are using the RM portal.

  • From the O365 portal, select Users, click More, Setup Multi-factor authentication. Once the “User portal” loads, click the Service settings tab and scroll down to the end, then click the Go to the portal link.
  • As an alternative to the above, you can also access the “User portal” via the classic Azure portal – select the AAD instance in question, go to the Configure tab and press Manage service settings under the MFA group.
  • From the classic Azure portal, by selecting the AAD instance in question, going to the MFA providers tab and clicking the Manage button. This is basically a smart link to your PFWeb instance, and it will look something like this:

Lastly, remember that some MFA settings are only configurable via the MFA section in the “User portal” we have in Azure AD. Those include Trusted IPs or controlling app passwords creation. The first two options mentioned above can get you to that part of the service.

Posted in Office 365 | Leave a comment

Filtering users and groups with the Azure AD (Graph) ODATA syntax

Regardless of the fact that the Azure AD PowerShell module hasn’t gotten any love from Microsoft in the past few months, Office 365 administrators should start embracing it and replacing their old MSOL-based scripts. It is the only module Microsoft will support in the future, so there’s no way going around that.

One of the biggest issues with the Azure AD module however is it’s poor ‘usability’ or ‘friendliness’. The module is not designed with the regular Joe in mind, it’s more of a simple exercise of wrapping up some Graph API queries with PowerShell syntax. Thus, we are forced to live with GUIDs, JSON formatting and most importantly, the lack of  proper filter syntax.

Yes, the Graph does offer filtering capabilities. Yes, they suck. No other way of putting that. Still, they do exist and can be used in some cases, with mixed results. In this article I will provide few examples, for future references.

First of all, there is some documentation on the filtering syntax here. Only a handful of examples are provided however, and no detailed explanations are given.

Let’s start with some simple examples. To list all users from a particular department or country, use the following syntax:

Get-AzureADUser -Filter "Department eq 'HP'"
Get-AzureADUser -Filter "Country eq 'BG'"

The eq operator was used for string comparison, and the corresponding string was enclosed in single quotes. If you want to compare against a Boolean property, no quotes should be specified, instead use true or false. For example, to list all disabled accounts:

Get-AzureADUser -Filter "AccountEnabled eq false"


Note that while property names (such as AccountEnabled) and string values are NOT case-sensitive, the Booleans are, so make sure to enter them exactly as lowercase true or false. Null values are NOT supported, which is a very unfortunate limitation. Neither is the not equal statement. All those lovely limitations make impossible to simply filter out any synchronized accounts or similar. Annoying!

But wait, it gets even better. The startswith operator can be used to do a wildcard searches, so for example list all accounts that have Vasil in their display name:

Get-AzureADUser -Filter "startswith(displayName,'vasil')"

Cool. Now try any of the below:

Get-AzureADUser -Filter "startswith(DisplayName,'vasil')"
Get-AzureADUser -Filter "Startswith(displayName,'vasil')"

Yes, now things are starting to get case-sensitive. Don’t you just LOVE programmers? 🙂 Oh, and moreover, endswith is NOT supported.

Anyway, off to some more useful examples. We can combine filters using the and and or operators. For example, list all groups that are both mail-enabled and security-enabled:

Get-AzureADGroup -Filter "SecurityEnabled eq true and MailEnabled eq true"
Get-AzureADUser -Filter "Department eq 'Finance' or Department eq 'Marketing'"

Lastly, there’s the any of operator, which is used to compare against multi-valued properties. For example, if I want to check which user has a particular proxyaddress configured, I could use:

Get-AzureADUser -Filter "proxyAddresses/any(c:c eq '')"

In case you are wondering about the funky capitalization of proxyAddresses – you’ve guessed it, it’s the only way it will actually work. As another example, we can list any proxy addresses starting with particular string:

Get-AzureADUser -Filter "proxyAddresses/any(y:startswith(y,'smtp:gosho'))"

This query will return all users that have any of their proxyaddresses starting with ‘gosho’. The next logical thing to try is to filter them by domain. Not possible sadly, as we don’t yet have support for the endswith operator…

While the “lambda” operators any/all are certainly useful, there are other limitations of the Graph that make them irrelevant:

Code: Request_UnsupportedQuery
Message: Complex query on property provisionedPlans is not supported.
Message: Complex query on property assignedPlans is not supported.

Anyway, I think I had enough of crappy syntaxes for now. Let me know if this was useful and if you have worked out some fancier examples.

Additional information about the OData syntax can be found here.

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

Access Reviews for group membership and assigned applications in Azure AD

The Access Reviews feature was recently introduced over at the EMS blog, and is now available in Preview. It’s an easy to use feature that allows for self-service management of group membership across distribution groups, security groups and Office 365 Groups, as well as application access. Well, self-service perhaps isn’t the correct word here, as the review needs to be triggered and the results applied by an administrator, but still, major parts of the process can be offloaded to the actual members of the group, thus there is no need for the admin to chase each of them individually.

In the future, Microsoft is planning to expand this feature to cover the full Guest user lifecycle, provide scheduling capabilities and programmatic access. Perhaps they might also address some of the shortcomings of the feature, such as the lack of support for dynamic groups and some of the “first-party” apps, and most importantly, the heavy price tag of the Azure AD Premium P2 license.

Read the full article here.

Posted in Azure AD, Office 365 | Leave a comment