Different Multi-Factor Authentication (MFA) States with Conditional Access

I’ve been working with MFA on my recent projects where the clients want to leverage conditional access.  The objective was a to bypass MFA when the users are on corporate network or on any of the trusted IPs.  Pretty simple. Right?

I create a few Named locations to simplify trusted locations.

I create a conditional access policy with these settings:

  1. Assign to two specific users (initial testing – avoid impact on all users)
  2. Only Exchange Online is selected (once again – initial testing)
  3. Apply to Any location exclude Named locations
  4. Grant access – Require multi-factor authentication

I run through What if to validate the policy.  All is working as expected.


My two test users set up their MFA methods.

Test user 1: Megan – OneWaySMS (text message) as indicated by MethodType:5

Test user 2: Raul – TwoWayVoiceMobile (phone call) as indicated by MethodType:0


Both user are on the same corporate network.  Megan launches OWA – no MFA prompt.  This achieves the objective above.  However, when Raul launches OWA, he is prompted for MFA.

Why does the same conditional access policy apply to Megan but not Raul?

The difference is how a user is enabled for MFA.  Here you can see that Megan’s MFA status is set to disabled while Raul’s is set to enforced.



Enabling and enforcing MFA for users using this traditional method requires users to perform a two-step verification every time they sign in and overrides conditional access policies.


If you’re trying to bypass MFA while on corporate or a trusted network, let conditional access do the work for you – by prompting users for MFA to access your Office 365 applications when they are outside of your network, instead of enabling and enforcing MFA using the traditional method.

Thanks for reading!


SharePoint – Quick Edit – Missing Required Columns

Have you ever tried to perform a quick edit on a SharePoint list and get the “Sorry, you can’t create a new item with Quick Edit because this view is missing one or more required columns. To create a new item, please click “New Item” or add required columns to this view.”?


You checked and indeed, your list contains a required column.

One of the main offenders is the missing “Name” field in the view. I found a method to get rid of this error without needing to add the “Name” field to your view via PowerShell.


#Get the site

$Web = Get-SPWeb -Identity “http://<Your Portal>/<Your Site>”

#Get the list that you need to work with – In my example below my list is called “Assets”

$List = $Web.Lists[“My Custom List”]

#To see the “Name” field

$List.Fields | Select Title, InternalName, Required | Sort Title

#It should look similar to this


#Change the field to not required and update

$Field = $List.Fields[“Name”]

$Field.Required = $False


Here’s a screenshot of what worked for me.SetNameField

That’s it!

Thanks for reading!

SharePoint Online Quick Start Guide

I’m working on an Office 365 adoption project, specifically, helping end users adopt SharePoint. One of the objectives is to provide the end users with a quick one-page guide to SharePoint library / list navigation. I searched and could not find what I was looking for. So, I decided to create one myself.

Here’s a screenshot of what I created.

SharePoint Online Quick Start

You can download the SharePoint Online Quick Start Guide here.

Thanks for reading!

Create Office 365 Groups Naming Policy

As we see greater interest from our clients in Teams, I’ve turned my attention to Office 365 groups administration, specifically on groups naming policy.

To create a naming policy for groups in your Office 365 tenant, you’ll need to use PowerShell.

I followed these instructions to view the current naming policy settings in my tenant by typing the following command:

$Setting = Get-AzureADDirectorySetting -Id (Get-AzureADDirectorySetting | where -Property DisplayName -Value “Group.Unified” -EQ).id

I expected to get some values, but I got this wonderful error instead:


So, where did I go from here?

I started to breakdown the command above, by running just the Get-AzureDirectorySetting.

It returned nothing. This tells me that there are no settings currently in place.

So, I had to configure the groups settings in my Office 365 tenant.

To do that, I could get the available template IDs by typing Get-AzureAdDirectorySettingTemplate or use the DisplayName value for “Group.Unified”


To Create a Naming Policy

I followed these steps to complete the creation of my naming policy:

  1. Create a new settings object for the Group.Unified template
  2. Configure the object to allow guests access (You could apply additional settings or leave this step out completely.)
  3. Set my settings to the new object


I applied the groups naming policy as seen in the below screenshot.



In OWA, I could see the new settings in effect. Be sure to use an account not in these administrator roles: Global Admin, Partner Tier 1 and 2 Support, User Account Admin, or Directory Writers to test the policy.


In summary, creating a naming policy can help users identify and categorize groups in the address book and enforces a consistent naming standard for Office 365 groups in your organization.

The naming policy is applied to groups created in Outlook, Microsoft Teams, SharePoint, Planner, Microsoft Stream, Dynamics 365 for Customer Engagement, Power BI, and many others.

Azure Active Directory (Azure AD) attributes are used in the creation of this policy. The supported attributes are [Department], [Company], [Office], [StateOrProvince], [CountryOrRegion], and [Title].

If you include these attributes in your naming policy, keep in mind that the total length of these prefixes and suffixes is restricted to 53 characters.

Thanks for reading!

Prepare for GDPR – Protect Your Most Sensitive Data with Azure Information Protection

The main objective of General Data Protection Regulation (GDPR) is to protect all European Union (EU) citizens from privacy and data breaches. This regulation impacts every organization located in the EU and it also applies to organizations located outside of the EU if they offer goods or services to EU data subjects. To ensure that there is proper security of such data, you should consider implementing solutions and processes that enable you to identify, classify, and protect data regardless of where it resides.

My most recent work has provided me with an opportunity to work with Microsoft Azure Information Protection (AIP) in Office 365. This technology provides persistent data protection, by classifying, labeling, and protecting documents and emails. In my previous posts, Classifying Data with Azure Information (AIP) – Introduction and Classifying and Protecting Data in Office 365, I provided an overview of AIP including descriptions of labels, how they are created, and how to classify your documents and emails. Additionally, Azure Rights Management (Azure RMS), the protection technology used by AIP, allows for encryption and authorization, ensuring users must successfully authenticate to access the documents and emails.

What are labels?

In AIP, a classification label is used to identify data based on its level of sensitivity and the impact to your business.  Most common sensitivity levels are categorized as restricted, confidential, official use, and public.

Unified Labeling and Protection

If you’ve worked with Office 365 and Azure Information Protection in the past, you may have noticed that there are two different technologies where labels can be created in Security and Compliance Center and Azure portal; this caused quite a bit of confusion of when to use which technology. Microsoft has been working towards providing a more consistent classification, labeling, and protection model that will be used across Office 365 and AIP.

The consistent protection model Private Preview will start soon, no announcement has been made as to when this will be generally available. The consistent labeling model will help ensure that sensitivity labels are recognized across Azure Information Protection, Office 365 Advanced Data Governance, Office 365 DLP and Microsoft Cloud App Security.

The following images show one central location where a label can be created, protection can be configured, and a retention policy can be applied.

Automatic Labeling (Classification)

The ability to automatically classify data is a critical part of helping organizations achieve GDPR goals. Azure Information Protection has 80+ built-in sensitive information types that can be used to detect and classify your data. Microsoft is working on releasing a GDPR template which will include additional information types such as addresses, telephone numbers, and medical information to help detect and classify personal data relevant to GDPR. This new sensitive information template will make it simpler to detect, classify, and protect GDPR related personal data.


The European Union’s General Data Protection Regulation (GDPR) will be enforced on May 25, 2018. Organizations can be fined up to 4% of annual global turnover or €20 million for breaching GDPR. If your organization collects, hosts, or analyzes personal data of EU residents, you should not delay in implementing solutions to ensure compliance with GDPR.

Back Up All Azure Rights Management Templates via PowerShell

I need to update properties of several custom templates in my tenant. After reading the warning in Set-AadrmTemplateProperty (see excerpt below), I want to ensure that I have at least a last-known-good set of these templates.

Excerpt from article:

Important: When you update properties of a custom template, the existing settings for those properties will be overwritten (not supplemented) without warning, so be sure to specify all the settings that you need for the properties that you are updating.

As a best practice, back up the existing template before you run this cmdlet, by using the Export-AadrmTemplate cmdlet. Then, if you need to revert to the original configuration, you can use the Import-AadrmTemplate cmdlet to restore the template.

The Export-AadrmTemplate article provides an example of how to export (back up) one template. Well, I don’t want to do this (one at a time) for all the templates I have in my tenant. So, I wrote the following script to export all templates that I need.

$ShortDate = Get-Date -Format yyyyMMdd

$OutPath = “C:\Azure RMS\Backup\”

$OutFolder = New-Item -ItemType Directory -Force -Path $OutPath$ShortDate

Foreach ($Template in ($Templates = Get-AadrmTemplate))


    $TemplateName = $Template.Names[0]

    $TemplateStatus = $Template.Status

    If ($TemplateName -match “1033” -and $TemplateStatus -match “Published”)


        $RMSTemplateFileName = ($TemplateName.Value.Substring(0) -replace ” “,“” -replace “\\”,“” -replace “-“,“”)

        $OutFile = $($OutFolder)\$($RMSTemplateFileName).xml”

        Export-AadrmTemplate -TemplateId $Template.TemplateId -Path $OutFile -Force



Get-Variable | Remove-Variable -EA 0

Get-PSSession | Remove-PSSession


The script creates a new directory and writes the export files to it in case I need to run this frequently.

Obviously, the If statement and any of the variables can be changed to meet your needs.

This script works well for me.

Thanks for reading!

Password-protected and Azure Information Protection

As you read Azure Information Protection client administrator guide on file types supported section, it is clearly stated that ‘Any file that is password-protected cannot be natively protected by the Azure Information Protection client. It lists a workaround by changing the default protection level via registry keys. If you’re not onboard with changing the default protection level and changing everyone’s registry keys, perhaps you would consider the following as a workaround.

Before I get to the workaround, it is necessary that I provide a bit of background on how I got here.

I classify an Excel file with RMS (Co-Author) rights, encrypt it with a password, and attach it to an email.

The recipient opens the attachment and sees this error:

“Excel cannot open the file <FileName>.xlsx because the file format or file extension is not valid. Verify that the file has not been corrupted and that the file extension matches the format of the file.”


Here’s the workaround I came up with.

  1. I classify the document with RMS enabled (same as before)
  2. I rename the file to <FileName>.pxlsx
  3. I attach the file to an email
  4. The recipient saves the file locally
  5. The recipient opens Excel, then opens the <FileName>.pxlsx
  6. The recipient provides the password to the file


7. The recipient selects ‘Yes’ in the dialog box


8. The file opens successfully

This is my workaround on this issue. I’m hoping that Microsoft will include password-protected files as one of the supported file formats in the near future.

Thanks for reading!