Disable all phone and text options for MFA

Impact of Removing SMS As an MFA Method In Azure AD

Posted on 3 CommentsPosted in 2FA, Azure Active Directory, Azure AD, MFA, security, self-service password reset, smartphone, sms, text message

There are a number of general recommendations that SMS (text messages) as an MFA method is not a good idea (mainly to do with the ease of porting or moving devices the number is associated with). You should always be looking at MFA with an app (Microsoft Authenticator or other) or hardware device. But the default in Azure AD is to include SMS as an option – so if we turn off text messaging as a second factor what is the impact to our user base who might have already registered their phone number.

My previous article on MFA end user experiences covered the different options available for the different registration wizards (legacy and the new combined MFA/SSPR wizard), what happens if you have SSPR enabled (and what happens if you do not). Each of the scenarios in that article allowed the user to register a phone number and then to have a text message sent at login.

If the user registered with the legacy authentication wizard (which is the default setting as of the time of writing) then there are three options by default – authentication phone, office number (set by the admin and not by the user) and mobile app (and phone is the selected option). Using SMS for second factor is therefore automatically set up unless the user chooses “office number” or “mobile app” whilst registering. The registration page looks as follows:

Legacy Auth for MFA with Phone Selected

So in scenarios where the user followed the defaults they get an MFA prompt at login that looks like this:

MFA via Phonecall dialog

Notice that they have an option to “sign in another way” for scenarios where the user maybe cannot receive a phone call but would be able to receive a text message (if you are in a location where you can receive neither, then you need to register the app as well in advance). If the user clicks “sign in another way” then they see the following where they can choose to receive a text message as the second factor proof:

Second factor proof select phone or text

To disable SMS/text as an MFA method you need to be in the Azure AD portal > MFA > Additional cloud-based MFA settings (or click Multi-Factor Authentication in the Users page of the same portal). You will see the below once you click the Service Settings tab:

Classic MFA Service Settings

This dialog includes the “skip multi-factor authentication…” box which you only have if you have Azure AD P1 or P2 licence. The four options at the bottom include the “Text message to phone” – uncheck that to stop SMS as a second factor.

So if SMS/text is removed as an option – what changes for the users who has already got a phone number stored as a MFA method? First change is that “sign in another way” message is now missing. A user who previously got a phone call with the option to change to another option will find that they cannot change options anymore (unless they have also registered a different method such as office number or mobile app:

MFA by Phone with SMS disabled

Therefore if there is not enough mobile signal to manage a call (and there might be for a text message) then the user cannot authenticate.

What about users who when they registered for MFA set SMS as their default? Setting text message as a default is not a obvious setting – but the default is whatever you initially choose to register with – so in the registration wizard if you select “send me a code by text message” then your default is SMS:

SMS as default MFA method

Once the admin disables SMS as a valid second factor, those users with phone as their default (or app) are not impacted – but users who set text message as their default are required to re-register. In the registration they are told their organization needs further information, that “call me” is the only available option, but their previously registered telephone number is shown in the registration wizard. This is shown in the following series of images:

More information required
Registration for MFA - Call only as a phone option
Registration for MFA steps
Registration for MFA steps 2

Once the users settings are saved, the user clicks Finish and their registration for phone authentication is updated to remove text message as a valid option. Enabling texts again in the admin portal does not allow this user to use texts again unless they register again or they update their additional security verification settings (Office 365 browser app > click photo > My account > Manage security & privacy > Additional security verification > Update your phone numbers used for account security (go to https://aka.ms/mfasetup as a shortcut to avoid all these steps)

If you remove both phone and text as a registration option as shown then users who previously only had phone and/or text registered will be required to register again.

Disable all phone and text options for MFA

This time registration will default to “mobile app” – where the user can select “code” or “notification” as their new default:

MFA Registration - phone and text disabled

In scenarios where you have enabled the new registration wizard (see my previous article on MFA end user experiences for more on this) then the default registration option is to use the app and not phone or text, though phone numbers are collected if you also turn on two or more options for requiring a password reset with SSPR. So in these scenarios you will probably find that the user has lots of registered options and so turning off SMS is not an issue.

So to disable SMS is only a problem in Azure AD for the user – as it means that at the next login they need to register again (so not a real problem). I had previously seen in 2018 that if the admin disabled text messages then users could not login if this was their only method! So that issue is clearly fixed now.

So as a call to action from this article – consider turning off text messages as a second factor and noting that the only impact is some users will either need to register again or you can ask them to go to https://aka.ms/mfasetup beforehand to change their default setting.

MFA and End User Impacts

Posted on 6 CommentsPosted in app password, ATP, Authentication, Azure, Azure Active Directory, Azure AD, Azure Information Protection, AzureAD, conditional access, EM+S, email, enterprise mobility + security, management, mcm, mcsm, MFA, microsoft, modern authentication, multi-factor auth, Multi-Factor Authentication, sspr

This article will look at the various different MFA settings found in Azure AD (which controls MFA for Office 365 and other SaaS services) and how those decisions impact users.

There is lots on the internet on enabling MFA, and lots on what that looks like for the user – but nothing I could see that directly laid out all the options and the impact of each option.

The options that the admin can set that I will cover in this article are:

  • Default settings for the MFA registration service
  • The enhanced registration service (now depreciated)
  • The refreshed enhanced registration service (MFA and Self-Service Password Reset registration combined)

The general impact to the user is that the user needs to provide a second factor to login. In this article I will not detail the above registration for each of the second factors and only cover the general process of registration – your exact experience on registration will depend upon what second factors (app notifications, app code, phone call and text message) you choose to implement.

This article will look mainly at the different between having no MFA and what happens from the users perspective as the admin turns on a requirement to have MFA. The various options that the admin can use to enable MFA are as follows:

  • Office 365 MFA (aka the legacy method) that is available to all users with or without a licence
  • Azure AD Conditional Access and setting a rule that requires MFA (when the user is not registered)
  • Azure AD Premium 2 licence and MFA Registration (register without requiring MFA to be enabled)
  • Azure AD Free fixed Conditional Access rules (MFA for all users) which is in preview at the time of writing (Aug 2019)

Terminology and Settings

This article refers back to a series of different settings in each of the following sections. To make the article avoid repeating itself, this section outlines each of the general settings, what I mean by the description I use and where I turn that setting on or off.

Office 365 MFA – This is the legacy MFA options set via https://admin.microsoft.com > User Management > Multi-Factor Authentication. This user experience turns on or off MFA for users regardless of app or location (unlike Conditional Access) and has settings for the different second factor methods (for example you can disable SMS from here).

Legacy MFA Admin Page

Conditional Access Based MFA – This is where you set rules for accessing cloud apps based on the user, the location, the risk (P2 licence required), the device (domain joined or compliant), the location (IP), the device risk (MDATP licence required), compliance (Intune required) etc. If you rule requires MFA and the logging in user passes the requirements for this rule (and is not otherwise blocked) then this is what I call Conditional Access Based MFA. This is set in https://portal.azure.com > Azure Active Directory > Enterprise Applications > Conditional Access

Conditional Access Based MFA

Azure AD Premium 2 MFA Registration – This is where you can get users to register before you turn on MFA via either of the above routes. Without the P2 licence you turn on MFA and at the next login the user needs to register. With P2 you can turn on registration at login without forcing MFA. You would then enable MFA later or you can have registration at next login (and defer that by 14 days) so that the user registers even if they never hit an endpoint that the need to do MFA on. For example, MFA when external and the user never works remotely. Therefore they will never have to do MFA and therefore never be required to register – which P2 licence you can get them to register independent of the requirement to do MFA. You access these settings via https://portal.azure.com > Azure AD Identity Protection > MFA Registration

Azure AD P2 MFA Registration

Self Service Password Reset Registration – This is shown if the user is in scope for SSPR and SSPR is enabled. This is not MFA registration – but if the user is in scope they will be asked to register for this as well. This therefore can result in two registrations at next login – one for SSPR and one for MFA. We will show this below, but it is best if you move to the combined MFA/SSPR registration wizard mentioned below.

SSPR Enablement

Enhanced Registration (Depreciated) – This was the new registration wizard in 2018 and have been replaced by the next option. If you still have users on this option you will see it, otherwise the option to enable this older wizard is now removed. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview

MFA Registration Wizard

Combined MFA and SSPR Registration – This is the current recommended MFA registration process and it includes self-service password reset registration as well. You should aim to move your settings to this. All the new MFA reporting and insights are based on this process. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview. Note that if you still have users on the previous “Enhanced Registration” shown above then this one is listed as “enhanced”. If not – if only one slider is shown – it is the new registration process. You can enable this for a group of users (for pilot) or all users:

Combined MFA and SSPR Registration Wizard

Office 365 MFA + Original Registration

This is not recommended to be used any more – use the Azure AD Free Conditional Access rules for all users or all admins instead. But for completion of the process to show all the options, you select a user(s) in the Office 365 MFA page and click Enable. In the below screenshot we can see that Cameron White is enabled for MFA. This means that it has been turned on for him, but he has not yet gone through the registration wizard:

Office 365 MFA for Single User

The video below shows the first run experience of this user – they login and are prompted to register for MFA. They register using the legacy experience and are then granted access to the application.

OFFICE 365 MFA + LEGACY REGISTRATION

Office 365 MFA + Enhanced Registration

For this scenario I have a user called Brian Johnson. He has been enabled for MFA as above (Office 365 method) but additionally has been added to a group that is configured to support the new MFA+SSPR combined registration process. Brian is not enabled for SSPR. The video shows the user experience. Note that the user needs a valid licence to be able to use this experience. If they do not have any licences they will get the old experience:

VIDEO OFFICE 365 MFA + ENHANCED REGISTRATION

Conditional Access MFA

The following video looks at the experience of two users who are enforced for MFA via Conditional Access. The login will trigger the registration for MFA as neither user is already registered. The first user (Christie) gets the old registration wizard and the second (Debra) gets the new registration wizard. The Conditional Access settings are basic – MFA in all circumstances for our two users:

Conditional Access Two Users
Conditional Access MFA Enabled
CONDITIONAL ACCESS WITH OLD AND NEW REGISTRATION

Impact of SSPR on MFA Registration and User Sign-In

When users are set up to register their password reset security methods and MFA, but using the old registration wizard the user needs to do two sets of registration. Again, it is recommended that the combined registration process is used instead of this process.

For this demostration, we are enabling SSPR for our test users. One with the old registration wizard and one with the new one:

SSPR WITH AND WITHOUT COMBINED REGISTRATION

Adding SSPR To Already Registered Users

Once a user has registered for MFA (old or new registration) it might come a time where you enable SSPR for them after that (and not at the time of original registration). In this scenario the users that registered with the old registration wizard are asked to register for SSPR, but users who went through the new wizard – though they did not specifically register for SSPR – there is enough details already available for them to use the service (as long as app notifications and codes is enabled for SSPR). If SSPR is left on the default of SMS and Email, then the new registration wizard does not have your alternative email and so SSPR is unavailable to you. The user process and flow is shown in the next video:

ENABLE SSPR AFTER REGISTRATION

Azure AD Identity Protection and MFA Registration

The Azure AD Premium 2 licensed feature called Identity Protection contains the ability to request that the user registers for MFA (and SSPR if via the new combined registration wizard) even if the user is not required to perform MFA for login – all our previous registrations only required registration because the user needed to do MFA. You can ask users to pre-register via https://aka.ms/mfasetup but Identity Protection adds this functionality with a 14 day option to defer. The video shows the settings and the user experience:

Azure AD IDENTITY PROTECTION WITH AND WITHOUT NEW REGISTRATION

Azure AD Free Conditional Access for All Users

Early Q2 2019 Microsoft rolled out new baseline policies for Azure AD Conditional Access. These are available even without the Azure AD P1 licence needed for Conditional Access – but as they are licence free they are heavily restricted – they apply to all users and need MFA if sign-in is risky. So though they do not require MFA on all logins (unlike the O365 MFA legacy settings) they do require registration. But they offer a 14 day deferral process if the user is not ready to register. But unlike Azure AD Identity Protection mentioned above, you cannot do this for some users – it is enabled for all users upon enabling the rule. Lets see the settings and the user experience in the video. The video will also enable the “all admins” baseline policy as well, as that should always be turned on.

BASELINE POLICY FOR ALL USERS WITH REGISTRATION

Making Your Office 365 Meeting Rooms Accessible

Posted on 2 CommentsPosted in booking, calendar, exchange online, Outlook, places, room

Or How to Use Set-Place to Configure Your Meeting Rooms or How Wheelchair Users Can Find The Best Meeting Rooms In Your Organization etc. – there are many different titles I can think of for this blog post. They are all to do with setting useful properties against your meeting rooms so that your users can find the best rooms.

As of the time of writing, “Outlook Places” service exposes a client-side UX only in Outlook on the web (OWA). Given Microsoft’s previous behaviour of flighting Exchange Online features for one client initially before rolling them out to other clients, this is likely to hit Office 365 ProPlus and Outlook mobile etc. at some point after that. Therefore I recommend that you update all your room properties now using the PowerShell cmdlet Set-Place so that your users are able to find meeting rooms and other resources upon the functionality appearing in their client.

The Exchange Online Management Shell cmdlet Set-Place allows you to configure properties such as if the room is accessible for wheelchair users (hence the title of this blog post), or what AV equipment it holds or indeed how many people the room can hold (comfortably!). As this information, especially in a large organization, is probably known by many different people and requires the input of these different users to maintain a master list, this blog post will look at the process of creating this list and then importing it back into Exchange Online when updated.

Creating A Master Room Metadata List

From Exchange Online Management Shell run the following:

Get-Mailbox -RecipientTypeDetails RoomMailbox -ResultSize Unlimited | Get-Place | Export-CSV OrganizationRooms.csv -NoClobber -NoTypeInformation

Open the file, here called OrganizationRooms.csv in Excel. I removed the first three columns (PSComputerName,RunspaceId,PSShowComputerName) as well as Type, ResourceDelegates, IsManaged, BookingType and Localities and the last two columns (IsValid and ObjectState) from this file and then save it as an Excel file to OneDrive for Business or SharePoint Online and shared it with the relevant facilities management and other interested parties (don’t share it as a CSV file, as multiple users cannot edit a csv file in real time). We wait for this information to be updated. If you wish you could lock out cells from being edited such as Identity and maybe DisplayName so that future updating of existing rooms is easy to do.

Specifically we are looking at information such as location (physical street/city address, building name [for campus type organizations], floor number and GeoCoordinates), AV equipment (such as audio, video, display devices and room phone number), accessibility for wheelchair users, and miscellaneous tags (in the form of a comma separated list such as “Conference Room”,Lecture,“Tiered Seating”) that users could use in their room search. There are tools to generate geo-coordinates from addresses that you can find online and they are required as latitude;longitude;altitude (where altitude is optional)

Updating Room Metadata in Exchange Online

To upload the new data, save the shared Excel spreadsheet as a CSV file again and run the following Exchange Online Management Shell script:

$OrganizationRooms = Import-Csv .\OrganizationRooms.csv
ForEach ($Room in $OrganizationRooms) {
    [Boolean]$IsWheelChairAccessible = [System.Convert]::ToBoolean($Room.IsWheelChairAccessible)
     Set-Place -Identity $Room.Identity -Street $Room.Street -City $Room.City -State $Room.State -PostalCode $Room.PostalCode -CountryOrRegion $Room.CountryOrRegion -GeoCoordinates $Room.GeoCoordinates -Phone $Room.Phone -Capacity $Room.Capacity -Building $Room.Building -Label $Room.Label -AudioDeviceName $Room.AudioDeviceName -VideoDeviceName $Room.VideoDeviceName -DisplayDeviceName $Room.DisplayDeviceName -IsWheelChairAccessible $IsWheelChairAccessible -Floor $Room.Floor -Tags $Room.Tags
     Set-Mailbox $Room.Identity -DisplayName $Room.DisplayName
}

In the above code I have not included attributes from Get-Place that I cannot write back such as IsManaged, BookingType and Localities – I am interested though in knowing what they are used for as they are undocumented?

The above code just replaces the current values in Exchange Online with the values in the spreadsheet, so the spreadsheet becomes your master.

Note that values with spaces need to be quoted in the CSV – such as tags and various display names. Also it is worth being aware that with conference bridges and Teams meetings, room “capacity” is not always as important as it might sound – a room with a capacity of 3 people will work fine if everyone is remote! Booking multiple rooms for a single meeting is also planned.

If the room object is synced from on-premises Active Directory then you can still use Set-Place to update the object in the cloud. The previous way of setting some of these properties (i.e. City) used Set-User and that needed to be run against the source of the object (that is, if synced you needed to run Set-User on-premises against Active Directory).

Set-Place can be viewed at https://docs.microsoft.com/en-us/powershell/module/exchange/mailboxes/set-place?view=exchange-ps

All rooms and resources that you manage via the steps in the blog post need to be Exchange Online resources. If the mailbox is still on Exchange Server and not moved to Exchange Online in a hybrid scenario, you are not able to set the below settings.

User Room Search Experience

At the time of writing (Aug 2019) this experience is rolling out to Outlook on the web (OWA). The new experience will use the “Outlook Places” backend service, which Set-Place we used above populates.

To view and search for rooms based on these settings you need (for now) to wait 24 hours from using Set-Place before the property can be searched. You then create a new event in OWA calendar and click “Search for a room or location” and then click “+ Browse more rooms”.

The suggested rooms listed are those you have used or attended meetings at recently, but if you click in the “Search for a city or room list” box you can either enter a city or room list name (suggest naming your room lists after buildings) and click “Show all rooms” or click the City or Room List name:

Browse rooms dialog
Browse Rooms by City

This allows the “Filters” option to become available, where you can filter for capacity (rooms larger than) or properties such as audio/video or accessible rooms.

Browse rooms with filter dialog

Once you have set the features you need, click Apply and select the room you need for the meeting. Being able to book multiple rooms for a single meeting is coming to Office 365 in the next few weeks from writing this article as well – imagine booking a meeting where people attend remotely but the remote location is another office.

Call To Action

Even though this “places” functionality does not reach all the Office email/calendaring clients (yet), this should not be a reason not to do this categorization work. Its quite easy to generate a list of all the rooms and their current settings (see above) as a spreadsheet. Its more work to update that list, but if you have a list then you can start. Rooms don’t often change their status regarding accessibility etc. but if you start cataloguing your rooms now or add this work to an Exchange Server migration project, then your users will benefit as the functionality reaches the client they use.

If you don’t update your places metadata, then clients will be unable to successfully find meeting rooms.

Getting Rid of Passwords in Azure AD / Office 365

Posted on 3 CommentsPosted in Authentication, Azure Active Directory, Azure AD, AzureAD, FIDO, modern authentication, Multi-Factor Authentication, password, yubikey

This article is based on the public preview of the use of hardware tokens/Microsoft Authenticator to do sign-in without passwords released in July 2019

Using Microsoft Authenticator for Passwordless Sign-in

You used to be able to do this by running the following in PowerShell for the last few years

New-AzureADPolicy -Type AuthenticatorAppSignInPolicy -Definition ‘{“AuthenticatorAppSignInPolicy”:{“Enabled”:true}}’ -isOrganizationDefault $true -DisplayName AuthenticatorAppSignIn

Interestingly, if you have done this in the past, the new Azure AD portal settings for doing this do not take this into consideration. So first, if you have run the above then you need to remove it with Remove-AzureADPolicy –Id <get the ID using Get-AzureADPolicy> before you implement the below, otherwise it is turned on for everyone even though Azure AD Portal says it is not enabled:

image

So to start, visit the Azure AD Portal at https://portal.azure.com and select Azure Active Directory. Then select Authentication Methods (under Security) and then Authentication Method Policy (Preview) or go directly there with https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/AuthenticationMethods.

Click Microsoft Authenticator passwordless sign-in and choose Enable and to pilot choose Select Users and the group you want to pilot with. Otherwise if you want to turn it on for all users, just leave the default. Note that nothing changes for the user – they need to do stuff before it works for them.

image which results in image

As the notice says, also ensure that you have MFA with push notifications enabled. This option has been available for a year or so now, and you will find it on Password Reset > Authentication Methods (or directly with https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/PasswordReset). This is not the same setting as the blue bar at the top of the page you are currently on.

For the user, from within Microsoft Authenticator, they need to go to the settings and register the device with their login. This is a one time process and once you have done the above and they have registered the device, they can choose to do password-less sign-in.

From a login perspective, it looks like this:

  1. Enter your username to an Azure AD login
  2. image
  3. On your phone, in the notification from the Microsoft Authenticator app, you select the displayed number (which changes number, and the position of the number each time)
  4. Screenshot_20190711-212252

Hardware Tokens Instead of Passwords (FIDO2)

This is the second option made available in Azure AD in July 2019. This allows the use of hardware tokens such as Windows Hello and FIDO2 devices (i.e. Yubikey and others) to authenticate to the platform. Note that this is not MFA – you have one factor, the hardware token. There is no requirement to implement a second factor with the hardware token as this replaces the password and is not storing a password. That is, if you do not have the token you do not have access – you cannot guess or intercept the token exchange.

To turn on this feature select the FIDO2 Security Key option under Authentication Methods (under Security) and then Authentication Method Policy (Preview).

As with the Microsoft Authenticator option above, Enable the feature and select All Users or Select Users.

Unlike the Microsoft Authenticator option, you now have the choice of Self Service and Key Restrictions

Self Service is useful when you have All Users selected, as the user registers their own security key. Without Self Service you need to configure a key for each user. Self Service requires the new registration service which is mentioned above and linked to at the top of the configuration page in Azure AD portal.

Enforce Attestation allows you to ensure that a specific model / device of hardware security key is used. Enforce Key Restrictions requires that you add the key by its AAGUID as shown:

image

From here you can also Restrict Specific Keys to only allow keys you have issued to be used. Block would allow you to have any key.

Enhanced Registration Preview

This preview has been available since early 2019, but now supports passwordless and security token as authentication methods. Click the link in the blue bar and ensure everyone whom you have enabled the new authentication policy for is included for the new registration preview. In the graphic below, this is the lower of the two options – your tenant might show only the lower option.

image

To direct users to the new preview experience visit http://aka.ms/mfasetup or if you have a Conditional Access login but you have not registered, you will be directed here anyway.

On the security info page, if you have already registered for MFA you will be shown your current authentication methods:

image

If you have not registered before you will be asked to register – either way, you get to pick the methods you want to use for authentication. These need to be:

image

  • Authenticator App – you can add up to five of these
  • Security Key

To add a new Security Key select this and follow the steps but make sure you are running Microsoft Edge on Windows 10 1903 or later or Firefox. On Chrome (which supports FIDO2 for Google Services) you get the below:

image

On a supported browser, you will see the following series of prompts:

image

image

The above is for a USB key. NFC keys and readers will have different prompts along the lines of holding the device near to the reader.

image

image

image

Then you need to name your key:

image

image

Signing In With A Security Key

Login to Office or your selected cloud app and enter your username and click next.

SNAGHTML2a9bd15

Now you can click “Sign in with Windows Hello or a security key”

image

As with registration, you now need to enter your PIN and press the button on the USB device, scan your fingerprint, look at your camera or hold your NFC device next to the reader – whatever your device requires you to do.

On your MFA registration page at https://aka.ms/mfasetup your security device is listed:

SNAGHTML2ac1742

Your login did not require a password – yippee!

Exchange Transport Rules Corrupt On Installing New Exchange Server Version

Posted on Leave a commentPosted in 2013, 2016, Exchange Server, ndr, rules, transport

When you install Exchange Server into an existing Exchange organization, your existing configuration typically remains intact and associated with the previous servers and some configuration, that is global in nature, also works across both versions.

I can across a scenario where this does not work the other day. The scenario was the installation of Exchange Server 2016 CU12 as a brand new Exchange installation into an existing Exchange Server 2013 deployment. This AD forest has previously seen Exchange 2003 and Exchange 2010, but these server versions are now long gone.

The issue was that the transport rules all appeared in Exchange Server 2016 as disabled, but where all enabled in Exchange Server 2013. The Exchange Admin Center could not open the rules and an error was displayed at the bottom which when expanded showed that the RejectEnhancedStatus was invalid, along with lots of the settings of the rule – they all are missing in the right-hand side of the EAC view.

image

RejectEnhancedStatus is the error code returned when you write a rule that rejects messages with notification. In Exchange Server 2016 only 5.7.1 and 5.7.900 through 5.7.999 are allowed for the RejectMessageEnhancedStatusCode parameter, but the Exchange Server 2013 deployment at CU21 does not block the creation of other status codes. Therefore, if you have transport rules with codes other than the ones allowed in Exchange Server 2016 you get corrupted transport rules:

image

So – how to fix. Well you cannot set the RejectMessageEnhancedStatusCode to a new value in Exchange Server 2016, because this server says you also need to set the RejectMessageReasonText value as that is also an empty string and also shows that a lot of the rule properties are also empty. So you need to fix it in the older version of Exchange.

In Exchange Server 2016 running Get-TransportRule “name of rule” results in:

WARNING: The object transport rule name has been corrupted or isn’t compatible with Microsoft support requirements, and it’s in an inconsistent state. The following validation errors happened:

WARNING: Rule ‘transport rule name’ is corrupt. The specified enhanced status code ‘5.7.x’ is invalid or isn’t compatible with Transport Rule policy requirement. Valid values are 5.7.1, or a value in the range between 5.7.900 and 5.7.999. The code must contain no spaces or other characters.

Parameter name: RejectEnhancedStatus

But running the same on Exchange Server 2013 is successful:

image

Run the following Exchange Management Shell cmdlets in Exchange 2013:

Get-TransportRule “name of rule” | FL Name,RejectMessage*

This will return the configuration of the current rule regarding the RejectMessageEnhancedStatusCode (which is wrong for 2016) and the RejectMessageReasonText.

Then run the cmdlet to change the code to a supported value as shown:

image

Set-TransportRule “name of rule” -RejectMessageEnhancedStatusCode 5.7.1 –RejectMessageReasonText “copy the reason from the output of the above cmdlet”

You need to set the code to 5.7.1 and provide the text again, or Exchange will replace the text with its own text or you need to create a New-SystemMessage for the status codes .900 and above and then use that code in the transport rule.

Once the change has been made on Exchange Server 2013, and this change is written to the configuration partition of Active Directory, that change will replicate around AD. Once the change reaches the DC used by Exchange Server 2016 the error will disappear and Exchange Control Panel can be refreshed to remove the error.

image or image

Register For Azure AD MFA From On-Premises Or Known Networks Only

Posted on 8 CommentsPosted in Azure Active Directory, Azure AD, conditional access, enterprise mobility + security, Office 365, security, self-service password reset, sspr

A long request within Azure AD/Office 365 has been the request to be able to register your security info from a known location or only on certain other conditions. Well it looks like this has appeared in Azure AD in the last few days!!

Its visible under Azure AD > Conditional Access > New/Existing Policy > Cloud Apps or Actions:

image

So, what does this look like in practice? Lets put this preview to the test.

Create the Conditional Access Policy for User Actions

Open the Azure AD portal at https://aad.portal.azure.com and click Enterprise Applications

From here click Conditional Access (this is also accessible under Azure AD > Security as well)

Click Add Policy and give the policy a name. I have chosen “Register Security Information On-Premises” for here

Click Users and Groups. I have selected “Users and Groups” rather than “All Users” as I plan to test this out first! I have picked the group that I use for testing Conditional Access changes. Eventually I will change this to All Users so that no-one can register security info apart from when on a trusted location. Note that this would also I think include guest users – I need to test that! Guest users are by their very nature not on my network but I might have MFA required for them – so they need to register, but I don’t want to apply the below to them

image

Select Cloud Apps or Actions (this was recently renamed to support this functionality we are describing here)

Select User Actions in the slider and check the option for Register Security Information (Preview)

Select Conditions and select the conditions you want to apply when users are registering security information. Its probably location based, so I will set that up here.

Select Locations, click Yes under Configure and select Any Location under Include and then under Exclude select Trusted Locations. Note that you need to have set up trusted locations in Conditional Access as well – I’m going to assume the public IP of all your offices is added and marked as trusted.

This setting will ensure that all locations other than trusted locations cannot register security information – note that this is the reverse of what you might expect. We need to block the locations we don’t want to access the MFA/SSPR registration process rather than the reverse. This is because we are required to add a control to the rules

image

With Azure AD P2 licences you could user a sign-in risk condition, ensuring that registration does not happen on medium or high risk sign-ins!

Click Done to bring you back to the first blade of settings and set Enable Policy to On to turn on this feature

Under Access Controls, click Grant and choose Block Access – be very careful here – don’t block all your access to everything!

image

Click Done

This takes us back to the first blade in the Conditional Access settings.

Click On in the Enable Policy slider

Now the Create button is available – this is not available if you do not create the reverse of what you might expect to do – block unknown locations rather than allow trusted locations!

image

Click Create

You will get your notification – you can test this in a few minutes:

image

Enable The New Combined MFA/SSPR Registration Page

Though I noticed that this conditional access restriction works against the older MFA registration page, Microsoft have said in their release blog article for this feature that it will only work against the new MFA/SSPR combined registration page. Therefore you should turn this on for your users impacted by the above policy – initially for your pilot users and then for all users.

See https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Cool-enhancements-to-the-Azure-AD-combined-MFA-and-password/ba-p/354271 for more on setting up the combined MFA/SSPR registration page.

Testing Register Security Information (Preview)

In an in-private browser session on the Wi-Fi of your favourite coffee company, browse to https://aka.ms/mfasetup (as this is not a trusted location!)

After logging in you would expect to be take to the registration page for MFA and SSPR – but you are not!

image

Repeat your test from on-premises, and you will get the MFA and SSPR registration pages (or both if you have the new combined MFA+SSPR wizard enabled):

Note that for a brand new user where you have SSPR enabled, they are required to register by default every 180 days. This will mean they have to register at first login – therefore first login needs to be from a trusted network (in this example) – you could use Trusted Device as the only place to register from, but adding a user to a trusted device requires MFA by default, so watch out for an issue here and if you want to do this, test it very well.

I have not had the opportunity to test this with the 180 day refresh of your settings – presumably that should work from any location and only changing them would be blocked, but this is something that needs to be tried out.

Review and Audit Offensive Language in Office 365 Communications

Posted on Leave a commentPosted in cyber bullying, exchange, exchange online, Exchange Server, offensive, Office 365, supervision

A new feature as of May 2018 in Office 365 is to filter communications based upon the offensive language machine learning filter. This is part of the Supervision settings that have been available for a number of years. The Offensive Language model uses a combination of machine learning, artificial intelligence, and keywords to identify inappropriate email messages as part of anti-harassment and cyber bullying monitoring requirements.

Here we will walk through the process of setting up the offensive language filter and testing it out (without offending anyone)!

Setting Up Offensive Language Supervision

Open the Compliance Center at https://compliance.microsoft.com and select Supervision on the left as shown:

image

At the time of writing, the Compliance Center is new and not everything is visible here. By the time you read this article it might be possible to create your supervision reviews from this portal, but for now we need to go to the Security and Compliance Center – so click the link at the top of the page. You will see this:

image

If you cannot see this then you do not have the right permissions. Add yourself to the Supervisory Review role group so you can set up policies. Anyone who has this role assigned can access the Supervision page in the Compliance Center.

Click Create to create a supervision review. Enter a name and a description. You cannot change the name later on.

image

In the next page, select the users to supervise. Start with a test group before editing this policy to add a group that contains everyone.

image

You can also select users who are in the group and specifically exclude them if needed. Communications via Exchange and Teams are included by default. Third party sources can be added as well.

Click Next and move to the Choose communications to review tab. Here select Internal communications (which is not selected by default) and choose Use match data model condition. There is only one model, and that is the Offensive Language model – so that gets selected by default.

image

If you want to scope the filter a bit more then you can select Add a condition and set up rules – for example you could exclude a specific domain inbound.

Click Next and get to the Specify percentage to review tab

image

Here you get to set the percentage of communications to review. The default is 10%. This means that only 10% of all communications are reviewed, and the results you see are based on what was found in that 10%. In large organizations, 10% could be a lot of communications, and therefore could be a fair amount of offensive content. Therefore ensure both your reviewers are able to manage the review process without undue impact and understand that whatever you find – there is 10 times more of it happening. Smaller organizations might want to increase the percentage to review, or at least consider increasing the percentage to review.

Click Next and enter the email addresses of the reviewers. They need to have an Exchange Online mailbox to be able to do this, but the content for review does not go into the reviewers mailbox.

image

Click Next and get to the Review your settings tab. Check everything is okay and click Finish.

image

Your policy will be listed so that you can update it, apart from the name, in the future.

The policy is also displayed in a pop-out as shown:

image

In this pop-out you can see the name of the mailbox that the content for review will go into – therefore those users who are reviewers will need to have access to this mailbox if they want to use Outlook to do their review process. If the reviewers have access to the Compliance Center then review can be done there instead of in Outlook/OWA. Permissions need to be granted to the mailbox using PowerShell. The two cmdlets are, using your supervisory review mailbox as listed in the policy results.

Add-MailboxPermission "SupervisoryReview{GUID}@domain.onmicrosoft.com" -User "alias or email address of the account that has reviewer permissions to the supervision mailbox" -AccessRights FullAccess
Set-Mailbox "SupervisoryReview{GUID}@domain.onmicrosoft.com" -HiddenFromAddressListsEnabled: $false

You can add “-AutoMapping $false” to the Add-MailboxPermission if you want the review mailbox not always to appear as an additional mailbox in Outlook.

To Review Your Supervision Policy

In the Supervision Review pop-out (which you can get back by clicking on the policy name), click Open at the top.

This takes you to:

image

Here I can see I have nothing to review or pending items to look at. If you want to test this, think of something offensive and send it to yourself! It might turn up in the review portal, or it might not – remember only 10% of communications are subject to review.

Note: Emails subject to defined policies are processed in near real-time and can be tested immediately after the policy is configured. Chats in Microsoft Teams can take up to 24 hours to fully process in a policy.

I’m not going to send anything, but I will take a look back here later and I might update this blog if I ever get any hits!

To review the content, the menu across the top for Review and Resolved Items will show you the items and those that have been resolved. The actual HR and discipline process is obviously not covered by anything in this review process. Once resolved in the company, mark it as resolved here.

In OWA, you can open an additional mailbox and enter “super” and the supervisoryreview{GUID} mailbox appears:

image

Inside the supervisory review mailbox, there is a folder for the policy you just created and inside that are subfolders that indicate review (Non-Compliant and Questionable) and Resolved:

image

Blocking Offensive Language

This is just a review process. If you want to block content, then create a DLP policy that uses a dictionary of words to block. For more on the dictionary creation see https://docs.microsoft.com/en-us/office365/securitycompliance/create-a-keyword-dictionary

Teams Calendar Fails To On-Premises Mailbox

Posted on 1 CommentPosted in 2016, 2019, autodiscover, autodiscover v2, calendar, exchange, exchange online, Exchange Server, Microsoft Teams, Teams

In Microsoft Teams, you have a calendar  (previously called meetings) icon in the main display that shows your diary and meetings etc. – except it does not work if your mailbox is not either in Exchange Online or, if if your mailbox is on-premises, you are not using Exchange Server 2016 CU3 or later.

The reason for this is that the Teams calendar uses AutoDiscover v2, which is only supported by Exchange Server 2016 CU3 and Exchange Online (note that CU3 is not the current version of Exchange Server 2016 and versions later than CU3 also support AutoDiscover v2).

This means that if you have an earlier version of Exchange Server on-premises then the calendar in Teams is not functional. This raises IT support calls as users expect it to be available, and this impacts your deployment of Teams as it appears broken.

So how can we fix this. Well clearly migrating to Exchange Online or installing the 2016 or later version of Exchange Server is the obvious option from the above, but there is another option to work around this issue. The “fix” is to remove the calendar icon from Teams. This does not stop you booking meetings, as you can still do that in Outlook with the Teams add-in or in the Outlook mobile client, where Teams meeting support is rolling out as I write this blog. If I remove the calendar icon, then the source of the errors disappears, but Teams is not really adversely impacted.

So this is what we start with:

image

And we remove the icon by creating a new App Setup Policy in the Teams Admin centre and then deploying that policy to all your users (with on-premises mailboxes on older versions of Exchange, or those not using Exchange for calendaring). You can easily roll this out as a test, though its about 24 hours for the effect to be seen, and then roll it out in bulk for all your impacted users. We will cover all this below:

 

1. Creating App Setup Policy

In the Teams Admin centre (https://admin.teams.microsoft.com) expand Teams Apps > Setup Policies and create a new policy. This policy is based on your current Global policy.

Select the Calendar app and remove it from this new policy. You should see something like this:

SNAGHTML31beae7d

Here I have created an app policy called “With OnPrem Mailboxes” and removed the Calendar app from it.

2. Applying App Setup Policy To A Test User

Once you have the policy ready, its time to test it. Policy changes will take 24 hours to apply (so say the docs) and I found on my testing it was 18 hours when I ran through these steps – so this is not quick!

To make sure your changes work, the plan here is to deploy this new policy to a few selected individuals in the Teams admin centre.

Find the first user and click on their name. In the details page you will see the policies applied to the lower left:

image

Click Edit at the top right of this section and change the App setup policy to your new policy:

image

And click Save:

image

You will see your new policy in the list.

Repeat for the rest of your test pool of users using the portal. We will not use the portal for deploying it to all users though, that will take too long!

Next day, these users should see something like this – no calendar:

image

3. Applying App Setup Policy To All Users

To apply this change to all users once your test users are happy we will use PowerShell, and we will use the Skype for Business Online PowerShell cmdlets (not the Teams PowerShell!).

The following one-line PowerShell, once you have connected to your tenant, is:

Get-CSOnlineUser | ForEach-Object { Grant-CsTeamsAppSetupPolicy -PolicyName "With OnPrem Mailboxes" -Identity $_.WindowsEmailAddress }

This gets all your users and applies a new Teams App Setup Policy to each of them. This works initially with this problem, as we assume all users are affected. If only a subset of your users are on-premises, then do not use this cmdlet to apply the initial change, but use the below to be more selective.

Within 24 hours the Calendar app will disappear from Teams for your users and they will not be phoning the help desk with issues that none of you can easily fix!

4. Applying App Setup Policy To Selected Users

The above cmdlet is a single run – it does not affect later and new users, nor is there a concept of a default policy that you can set as the one each new users gets. So every so often depending upon how often new users start employment you will want to run the below:

Get-CsOnlineUser -Filter { TeamsAppSetupPolicy -ne "With OnPrem Mailboxes" } | Grant-CsTeamsAppSetupPolicy -PolicyName "With OnPrem Mailboxes"

This gets all users where they do not have the selected App Policy already set and sets this just for these users. This is quicker than setting it for all users regardless.

You can use other filters to select users – for example, you could look for users without an on-premises mailbox and then run the ForEach against each of these users instead – this would work in a hybrid deployment.

When you are in a hybrid deployment and you move mailboxes to Exchange Online from on-premises, you will want to set those users just moved back to a policy that includes the calendar app. The same would go for organizations migrating to Exchange Server 2016 with inbound AutoDiscover from Office 365. Here you could use something like importing a CSV file of mailboxes being migrated (the same list you used to build the migration batches in the first place would do) and then run the ForEach for each item on the CSV file.

Read Only And Document Download Restrictions in SharePoint Online

Posted on Leave a commentPosted in AADConnect, AADSync, active directory, Azure Active Directory, Azure AD, compliance, conditional access, device, download, enterprise mobility + security, exchange online, microsoft, Office 365, OneDrive, OneDrive For Business, sharepoint, Uncategorized

Read Only And Document Download Restrictions in SharePoint Online

Both SharePoint Online (including OneDrive for Business) and Exchange Online allow a read only mode to be implemented based on certain user or device or network conditions.

For these settings in Exchange Online see my other post at https://c7solutions.com/2018/12/read-only-and-attachment-download-restrictions-in-exchange-online.

When this is enabled documents can be viewed in the browser only and not downloaded. So how to do this.

Step 1: Create a Conditional Access Policy in Azure AD

You need an Azure AD Premium P1 licence for this feature.

Here I created a policy that applied to one user and no other policy settings. This would mean this user is always in ReadOnly mode.

In real world scenarios you would more likely create a policy that applied to a group and not individual users and forced ReadOnly only when other conditions such as non-compliant device (i.e. home computer) where in use. The steps for this are:

imageimageimageimage

The pictures, as you cannot create the policies in the cmdline, are as follows:

  1. New policy with a name. Here it is “Limited View for ZacharyP”
  2. Under “Users and Groups” I selected my one test user. Here you are more likely to pick the users for whom data leakage is an issue
  3. Under “Cloud apps” select Office 365 SharePoint Online. I have also selected Exchange Online, as the same idea exists in that service as well
  4. Under Session, and this is the important one, select “Use app enforced restrictions”.

SharePoint Online will then implement read only viewing for all users that fall into this policy you have just created.

Step 3: View the results

Ensure the user is licensed for SharePoint Online (and a mailbox if you are testing Exchange Online) and an Azure AD Premium P1 licence and ensure there is a document library with documents in it for testing!

Login as the user under the conditions you have set in the policy (in my example, the conditions where for the specific user only, but you could do network or device conditions as well.

SharePoint and OneDrive Wizard Driven Setup

For reference, in the SharePoint Admin Centre and Policies > Access Control > Unmanaged Devices, here you turn on “Allow limited web-only access” or “Block access” to do the above process of creating the conditional access rule for you, but with pre-canned conditions:

image

In the classic SharePoint Admin Center it is found under that Access Control menu, and in SharePoint PowerShell use Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess

Turning the settings on in SharePoint creates the Conditional Access policies for you, so for my demo I disabled those as the one I made for had different conditions and included SharePoint as well as a service. This is as shown for SharePoint – the banner is across the top and the Download link on the ribbon is missing:

image

And for OneDrive, which is automatic when you turn it on for SharePoint:

image

Save Time! Have All Your Meetings End Early

Posted on 4 CommentsPosted in calendar, exchange online, Exchange Server, monthly channel, Office 365, Office 365 ProPlus, Outlook, semi-annual channel

I am sure you have been in a meeting, where the meeting end time rolls around and there is a knock at the door from the people who want the meeting room now, as their meeting time has started and yours has finished.

What if you could recover five, eight, ten or more minutes per meeting so that the next meeting party can get into the room on time, and you have time to get out and get to your next meeting, and be on time.

Well since the beginning of 2019, Microsoft have come to your rescue.

image

The above are the new calendar “End appointments and meetings early” option. It is available in Outlook for Windows that is part of Office 365 ProPlus and you need to have a version of the software released new in 2019 for the feature to be available – more on the version and what to do in the technical section below.

The above option is found from File > Options > Calendar and then looking under Calendar Options as shown.

Check the option ”End appointments and meetings early” and then choose the time that a meeting under 1 hour will end early, and you can choose 5, 8 or 10 minutes, and then a second option for meetings over 1 hour – these can end 5, 10 or 15 minutes early. You can also enter your own preferred end early time.

Click OK and go create a new meeting. It should not matter how you create the meeting.

As you can see from my options above, my default meeting is 30 minutes – so on creating a new meeting I see the following:

image 

I’ve highlighted the new end time – its 25 minutes after the meeting starts! The adjustment applies to the default meeting length and shortens it for me.

If for this meeting I want it to be the full 30 minutes, I can just write in the new time – all Outlook is doing is setting a new adjustable default for me.

For meetings where you drag out a custom duration in your calendar – it works here as well:

image

As you can see I have dragged out 1pm to 4pm on Thursday. Look what happens when I enter some text for the meeting subject:

image

The meeting is created with an end time ten minutes early (my preferred time saving duration for meetings over one hour). As with the above, I can adjust the time of this meeting to the full hour if I want to very easily – just drag the meeting block to the full hour and it is kept. Its just the default time when I first create the meeting that is adjusted.

Note that existing meetings are not changed – but if you go into an existing meeting and look at the end time drop down, you will see suggestions for the duration that take the early end time into consideration:

image

So, that’s how you can save time on your meetings (or at least one way, being prepared for them is another and technology cannot help there – yet!)

Changing The Defaults For Everyone

But what if you are the HR department or the representative of the department for digital change – what if you want to try and improve company culture and change these defaults across the board – well this is a job for IT, but they can easily roll out a setting to all your computers that set a end early time for both short and longer meeting durations.

They need to deploy a group policy setting that changes the registry at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Calendar and updates both EndEarlyShort and EndEarlyLong values as well as the EndEventsEarly key. EndEarlyShort is of course the value that affects meetings under one hour – and you do not need to accept the Microsoft suggested durations of 5, 8 and 10 minutes. For example if I edit this DWORD registry key and set the value to 3, upon restarting Outlook my new meetings under one hour end three minutes early:

image

The EndEventsEarly value is the setting that turns the feature on. So as well as setting the end early times, you need to set this value to 1 as well.

If you want to roll out this change centrally and ensure that the end user cannot set their own custom end early time then you can change the registry key policy settings via HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Calendar. Changes in this registry location mean the user cannot adjust the end early times.

image

You can disable this option centrally as well by setting EndEventsEarly DWORD value to 0 – this has the effect of disabling the check box and so users cannot turn the option on.

All these three settings are included in the latest update to the Office365 Administrative Templates, available on Microsoft Download Center: https://www.microsoft.com/en-us/download/details.aspx?id=49030 as well.

Checking Your Outlook Version

Version 1812 or later in use on the Monthly Channel is required before you can use this feature. In most businesses you are probably using the Semi-Annual channel, and this has features deferred by at least six months. So to check, click File > Office Account in any Office application (shown below). To the right hand side you will see the below. You need to check you are running the Subscription Product and that under About Outlook (or whatever Office app you are checking), it reads Version 1812 or later and Monthly Channel. The Semi-Annual Channel is released in January and July each year and is deferred by at least six months, so as this feature was released in Dec 2018, this feature will not appear in the Semi-Annual Channel until at least July 2019 – build 1812 of the Semi-Annual Channel (and possibly not until build 1907). More on this release cycle can be found at https://docs.microsoft.com/en-us/deployoffice/overview-of-update-channels-for-office-365-proplus

image

Too Many Folders To Successfully Migrate To Exchange Online

Posted on 1 CommentPosted in activesync, android, email, exchange, exchange online, Exchange Server, iPad, iPhone

Exchange Online has a limit of 10,000 folders within a mailbox. If you try and migrate a mailbox with more than this number of folders then it will fail – and that would be expected. But what happens if you have a mailbox with less than this number of folders and it still fails for this same reason? This is the problem, with resolution, I outline below.

I was moving some mailboxes to Exchange Online when I came across the following error in the migration batch results:

Data migrated: 18.18 MB ‎(19,060,890 bytes)‎
Migration rate: 0 B ‎(0 bytes)‎
Error: MigrationMRSPermanentException: Error: Could not create folder 2288. –> MapiExceptionFolderHierarchyChildrenCountQuotaExceeded: Unable to create folder. ‎(hr=0x80004005, ec=1253)‎ Diagnostic context: Lid: 55847 EMSMDBPOOL.EcPoolSessionDoRpc called [length=204] Lid: 43559 EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=468][latency=1] Lid: 52176 ClientVersion: 15.20.1730.17 Lid: 50032 ServerVersion: 15.20.1730.6019 Lid: 35180 Lid: 23226 — ROP Parse Start — Lid: 27962 ROP: ropCreateFolder [28] Lid: 17082 ROP Error: 0x4E5 Lid: 25953 Lid: 21921 StoreEc: 0x4E5 Lid: 27962 ROP: ropExtendedError [250] Lid: 1494 —- Remote Context Beg —- Lid: 38698 Lid: 29818 dwParam: 0x0 Msg: f28f1e21-62aa-4999-977f-ce310efea309-61f0997f-74d5-4421-9050-64f8272e5ac2[9]-28A06 Lid: 29920 dwParam: 0xB Lid: 29828 qdwParam: 0x2711 Lid: 29832 qdwParam: 0x2710 Lid: 45884 StoreEc: 0x4E5 Lid: 29876 StoreEc: 0x4E5 Lid: 30344 StoreEc: 0x4E5 Lid: 54080 StoreEc: 0x4E5 Lid: 56384 StoreEc: 0x4E5 Lid: 38201 StoreEc: 0x4E5 Lid: 35904 Lid: 45434 Guid: f12f3e45-67aa-89012-345f-ce678efea901 Lid: 10786 dwParam: 0x0 Msg: 15.20.1730.017:VI1PR0502MB2975:145a3769-3902-4e6b-9fe4-6db564e4eb92 Lid: 1750 —- Remote Context End —- Lid: 31418 — ROP Parse Done — Lid: 22417 Lid: 30609 StoreEc: 0x4E5 Lid: 29073 Lid: 20369 StoreEc: 0x4E5 Lid: 64464 Lid: 64624 StoreEc: 0x4E5

In the above I have highlighted some of the errors I was seeing – with the “could not create folder” message, the first indicator is that I have too many folders to migrate or I have a corrupt mailbox. Running Get-MoveRequestStatistics and including a full report (with -IncludeReport) shows in part the below. This was run to get more info on the move request. This was run from Exchange Online:

​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​26/03/2019 17:10:09 [VI1PR0502MB3855] ‘MigrationService (on behalf of ‘Brian.Reid@domain.co.uk’)’ created move request.
26/03/2019 17:10:15 [DB8PR05MB6025] The Microsoft Exchange Mailbox Replication service ‘DB8PR05MB6025.eurprd05.prod.outlook.com’ (15.20.1730.17 ServerCaps:01FFFFFF, ProxyCaps:07FFFFC7FD6DFDBF5FFFFFCB07EFFF, MailboxCaps:, legacyCaps:01FFFFFF) is examining the request.
26/03/2019 17:10:15 [DB8PR05MB6025] Content from the Shard mailbox (Mailbox Guid: f12f3e45-67aa-89012-345f-ce678efea901, Database: cc980daf-4402-4645-b26c-2a83760b161c) will be merged into the target mailbox.
26/03/2019 17:10:15 [DB8PR05MB6025] Connected to target mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘EURPR05DG090-db014’, Mailbox server ‘DB8PR05MB6025.eurprd05.prod.outlook.com’ Version 15.20 (Build 1730.0).
26/03/2019 17:10:20 [DB8PR05MB6025] Connected to source mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’, database ‘DB’, Mailbox server ‘onprem.server.domain.com’ Version 15.0 (Build 847.0), proxy server ‘onprem.server.domain.com’ 15.0.847.40 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:1FFFCB07FFFF.
26/03/2019 17:10:21 [DB8PR05MB6025] Request processing started.
26/03/2019 17:10:21 [DB8PR05MB6025] Source mailbox information:
Regular Items: 8443, 905.4 MB (949,422,345 bytes)
Regular Deleted Items: 1149, 189.9 MB (199,115,692 bytes)
FAI Items: 4651, 11.72 MB (12,285,701 bytes)
FAI Deleted Items: 9, 19.26 KB (19,721 bytes)
26/03/2019 17:10:21 [DB8PR05MB6025] Cleared sync state for request 2c065e32-3bd5-4524-9aac-03880fa8e961 due to ‘CleanupOrphanedMailbox’.
26/03/2019 17:10:21 [DB8PR05MB6025] Mailbox signature will not be preserved for mailbox ‘tenant.onmicrosoft.com\f12f3e45-67aa-89012-345f-ce678efea901 (Primary)’. Outlook clients will need to restart to access the moved mailbox.
26/03/2019 17:11:20 [DB8PR05MB6025] Stage: CreatingFolderHierarchy. Percent complete: 10.
26/03/2019 17:12:38 [DB8PR05MB6025] Initializing folder hierarchy from mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’: 29048 folders total.
26/03/2019 17:21:21 [DB8PR05MB6025] Folder creation progress: 1102 folders created in mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:31:22 [DB8PR05MB6025] Folder creation progress: 2730 folders created in mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:41:22 [DB8PR05MB6025] Folder creation progress: 4535 folders created in mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 17:51:23 [DB8PR05MB6025] Folder creation progress: 6257 folders created in mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:01:23 [DB8PR05MB6025] Folder creation progress: 7919 folders created in mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:11:23 [DB8PR05MB6025] Folder creation progress: 9570 folders created in mailbox ‘tenant.onmicrosoft.com\2c065e32-3bd5-4524-9aac-03880fa8e961 (Primary)’.
26/03/2019 18:14:15 [DB8PR05MB6025] Fatal error StoragePermanentException has occurred

The move request logs show an increasing folder count, and when this exceeds 10,000 a storage error occurs.

So the next thing to do is to check what I have on-premises. I have generally two options to try and fix a mailbox I am moving to Exchange Online. One is to move the mailbox elsewhere on-premises (on the basis that I discard errors on-premises and then move a cleaner mailbox to the cloud) or run repairs on the mailbox. Note that running repairs on-premises is part of the move to the cloud anyway as Exchange Server does this as part of the move.

But this revealed nothing! The move request logs on-premises showed the same – there was over 10,000 folders (indeed some of my mailboxes had over 20,000 folders) and this was enumerated in the move request logs. A New-MailboxRepairRequest did nothing either. But interestingly, Get-MailboxFolderStatistics | Measure showed only 200 folders! Each of my failing mailboxes had between 150 and 263 folders – nothing like the +10,000 that the move request was finding!

So I opened the mailbox in Outlook having granted myself permissions to it – again nothing.

So I opened MFCMapi and had a look at the folders. Now MFCMapi shows everything in the mailbox, and not just items under the “top of the information store” folder. I went about expanding each subfolder I could find and I came across a subfolder that everytime i expanded it, MFCMapi would hang. I would close and restart MFCMapi and the same thing!

image

I had found my suspect folder – its a iPhone device that had created the +10,000 folders. Now that I had a good candidate for my issue, the fix was easy. I listed the active-sync devices using Get-MobileDevice -Mailbox “Richard Redmond” | FL Identity and then removed the suspect device using Remove-ActiveSyncDevice “domain.co.uk/OU/Richard Redmond/ExchangeActiveSyncDevices/iPhone§A9BCDE7FG57HIJ81KL1M08NOPQ” -Confirm:$false where the device identity was returned in the Get-MobileDevice cmdlet run just before.

This Remove-ActiveSyncDevice (or Remove-MobileDevice) cleans up this mailbox and deletes the partnership with the device.

Once this was done, I moved the mailbox again and it was ~200 folders and moved to Exchange Online without further issue.

Where I tested the move to Exchange Server rather than Exchange Online, I found that looking in the move request report (I had prestaged the move and then removed the corrupt mobile device), the move report showed information like the following and all I had done was removed one mobile device from the mailbox!

26/03/2019 17:41:22 [servername] Folder hierarchy changes reported in source ‘Primary (a8c13a2f-535b-d996-908e-ff84b1484a7)’: 200 changed folders, 24080 deleted folders.

From the users perspective, if the phone is an active device and is syncing email, then removing the phone causes it to create a new partnership. If the server allows any device then this is seamless to the user. If the server requires authorization to add a new device, then the user will be told this and service desk/admin will need to approve the device again. So if Allow/Block/Quarantine (ABQ) is not enabled on the server, one wonders if deleting all active sync partnerships before migrating any mailbox is an idea worth considering – there could be mailboxes I have moved that are <10,000 folders but not far from that number and therefore storing up issues for the future!

Exchange Move Requests | Large Items | And Setting TCP KeepAliveTime To A Large Value

Posted on Leave a commentPosted in exchange online, Exchange Server, mailbox, move, networking

I have seen this situation a number of times. A large mailbox (or mailbox and archive) wont move to the target because the process of checking what the changes are in the mailbox take too long, the network or Exchange Server times out the users move and then reports the mailbox is locked.

The fix for this is counter though to everything else you read online about this. Often you will see to reduce the TCP KeepAliveTime and reboot the server. This is the opposite – increase the value and do not reboot the server. Here is why:

First make sure no bad items in your failed moves – this is not a fix for bad items, this is a fix where things timeout:

Get-MoveRequest -MoveStatus failed | Get-MoveRequestStatistics | fl badite*

View the Move Request Statistics log for one of your failed mailbox moves:

Get-MoveRequestStatistics "&lt;name&gt;" -IncludeReport | fl | Out-File movereport.txt

Search the report that you have saved in the above cmdlet and search for “Error” in the text file. If you get the following then the mailbox is probably too large for a successful move, which means the source server or network has not got the resources. What can happen is the move is progressing and a check happens for changes to the source mailbox – this takes a long time to complete and something times out. When target Exchange tries to connect again, the source has lost the TCP port and so a new move is started, but the mailbox is still locked for the old move. Therefore the move cannot continue.

I have found that by increasing TCP KeepAliveTime (contrary to all the advise online) that this solves the issue. Now I need to be clear here – all I am doing is changing the registry key for this setting and restarting the MRS service on the source Exchange Server. I am NOT restarting Windows, and so I am not changing the KeepAliveTime for the entire network stack. I think MRS checks the registry key to see the KeepAliveTime and sets this to the lock time on the mailbox during the move. If I can lock the mailbox for longer, moves don’t timeout and fail is the theory behind why this happens

The error I get in the MailboxStatistics report (see above for cmdlet) reads:

Message                                : Error: Couldn’t switch the mailbox into Sync Source mode.
                                          This could be because of one of the following reasons:
                                            Another administrator is currently moving the mailbox.
                                            The mailbox is locked.
                                            The Microsoft Exchange Mailbox Replication service (MRS) doesn’t have the correct permissions.
                                            Network errors are preventing MRS from cleanly closing its session with the Mailbox server. If this is the case, MRS may continue to encounter this error for up to 2 hours – this duration is controlled by the TCP KeepAlive settings on the Mailbox server.
                                          Wait for the mailbox to be released before attempting to move this mailbox again. –> An error occurred while saving the changes on the folder “FolderID/”. Error details: Failed, Property: [0x66180003]
                                          InTransitStatus, PropertyErrorCode: AccessDenied, PropertyErrorDescription: .
                                          –> Property: [0x66180003] InTransitStatus, PropertyErrorCode: AccessDenied,
                                          PropertyErrorDescription: .

Of interest in the error is the point that says “MRS may continue to encounter this error for up to 2 hours ”. This time value matches the default TCP KeepAliveTime value. Raising this in the registry and restarting the MRS service (not the server) changes the lock timout, which means that when the long job that is happening on the target finishes (and takes longer than two hours), the source server is still waiting for the connection and does not throw the above error.

Once you have your mailboxes moved, delete the registry value (to put it back to the default of two hours) and avoid rebooting the server when this key is set to a different value. If you started with a different value return to that one instead of deleting the registry value.

The KeepAliveTime setting is found at \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, and its a DWORD value called KeepAliveTime. The value is in milliseconds, so 7200000 is two hours and 86400000 is 24 hours (which is the value I tend to use to resolve this issue). This change is made on the mailbox server and the service restarted on that server (or servers if you have more than one).

bin/ExSMIME.dll Copy Error During Exchange Patching

Posted on Leave a commentPosted in 2013, 2016, exchange, Exchange Server, update, upgrade

I have seen a lot of this, and there are some documents online but none that described what I was seeing. I was getting the following on an upgrade of Exchange 2013 CU10 to CU22 (yes, a big difference in versions):

     The following error was generated when “$error.Clear();
           $dllFile = join-path $RoleInstallPath “bin\ExSMIME.dll”;
           $regsvr = join-path (join-path $env:SystemRoot system32) regsvr32.exe;
          start-SetupProcess -Name:”$regsvr” -Args:”/s `”$dllFile`”” -Timeout:120000;
         ” was run: “Microsoft.Exchange.Configuration.Tasks.TaskException: Process execution failed with exit code 3.
    at Microsoft.Exchange.Management.Tasks.RunProcessBase.InternalProcessRecord()
   at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__b()
    at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)”.

The Exchange Server setup operation didn’t complete. More details can be found
in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.

In this error the file ExSMIME.dll fails to copy. You can find the correct copy of this file in the CU source files at …\CU22\setup\serverroles\common. I copy the ExSMIME.dll file from here directly into the \Program Files\Microsoft\Exchange Server\v15\bin folder and then restart the upgrade.

I have found that the upgrade fails again here if it things there is a pending reboot due to other installations and I have also seen at this point the detection for the VC++ runtime fails. I have documented this elsewhere, and the workaround for the is found at https://c7solutions.com/2019/02/exchange-server-dependency-on-visual-c-failing-detection.

A reboot later and the installation is successful. The error somehow seems to think that the file is not where it is looking for it. In the ExchangeSetup.log file it records the issue as “Error 3”, which generally means “not found”!

Decommission ADFS When Moving To Azure AD Based Authentication

Posted on Leave a commentPosted in ADFS, ADFS 3.0, Azure, Azure Active Directory, Azure AD, AzureAD

I am doing a number of ADFS to Azure AD based authentication projects, where authentication is moved to Password Hash Sync + SSO or Pass Through Auth + SSO. Once that part of the project is complete it is time to decommission the ADFS and WAP servers. This guide is for Windows 2012 R2 installations of ADFS. There are guides for the other versions online.

This guide assumes you were using ADFS for one relying party trust, that is Office 365, and now that you have moved authentication to Azure AD you do not need to maintain your ADFS and WAP server farms.

Compile a list of server names

So first check that these conditions are true. Login to the primary node in your ADFS farm. If you don’t know which is the primary, try this on any one of them and it will tell you the primary node! Run Get-ADFSSyncProperties and you will either get back a list of properties where LastSyncFromPrimaryComputerName reads the name of the primary computer or it says PrimaryComputer.

If you don’t know all your ADFS Server Farm members then you can use tools such as found at this blog for querying AD for service account usage as ADFS is stateless and does not record the servers in the farm directly.

There is no list of the WAP servers in the farm – so you need to know this server names already, but looking in the Event Viewer on an ADFS server should show you who have connected recently in terms of WAP servers.

Get CertificateSharingContainer

On the primary ADFS server run (Get-ADFSProperties).CertificateSharingContainer. Keep a note of this DN, as you will need to delete it near the end of the installtion (after a few reboots and when it is not available any more)

Check no authentication is happening and no additional relying party trusts

Login to each ADFS box and check the event logs (Application). If any service is still using ADFS there will be logs for invalid logins. Successful logins are not recorded by default, but failures are – so if you have failures to login currently happening then something is still using ADFS and so you will not be wanting to uninstall it until you have discovered that.

On the primary ADFS farm member open the ADFS admin console and navigate to Trust Relationships >Relying Party Trusts

image

If all you can see if Microsoft Office 365 Identity Platform (though it has an different name if you initially configured it years and years ago). Device Registration Service is built into ADFS, so ignore that. If you have any others, you need to work on decommissioning these before you decommission ADFS. If you have done the Azure AD authentication migration then the Office 365 Relying Party Trust will no longer be in use. Run Get-MSOLDomain from Azure AD PowerShell and check that no domain is listed as Federated. If all domains are Managed, then you can delete the relying party trust.

Uninstall Additional Connectors etc.

If you have added connectors into ADFS, for example MFA Server tools, then uninstall these first. For example if you have Microsoft MFA Server ADFS Connector or even the full MFA Server installed, then you have this and IIS to uninstall. MFA Server is removed from the control panel (there are a few different things to remove, such as MFA Mobile Web App Service, MFA User Portal etc. Remove the MFA Server piece last. IIS is removed with Remove-WindowsFeature Web-Server. If you uninstall MFA Server, remember to go and remove the servers from the Azure AD Portal > MFA > Server Status area at https://aad.portal.azure.com/ ds

Uninstall the WAP Servers

Login to each WAP server, open the Remote Access Management Console and look for published web applications. Remove any related to ADFS that are not being used any more. Look up Azure App Proxy as a replacement technology for this service. Make a note of the URL that you are removing – its very likely that this means you can remove the same name from public and private DNS as well once the service is no longer needed.

When all the published web applications are removed, uninstall WAP with the following Remove-WindowsFeature Web-Application-Proxy,CMAK,RSAT-RemoteAccess. You might not have CMAK installed, but the other two features need removing.

Reboot the box to complete the removal and then process the server for your decommissioning steps if it is not used for anything else.

Uninstall the ADFS Servers

Starting with the secondary nodes, uninstall ADFS with Remove-WindowsFeature ADFS-Federation,Windows-Internal-Database. After this run del C:\Windows\WID\data\adfs* to delete the database files that you have just uninstalled.

Remove Other Stuff

Your ADFS Service account can now be deleted, as can:

Your DNS entry, internal and external for the ADFS Service, as can:

The firewall rules for TCP 443 to WAP (from the internet), and between WAP and ADFS, as well as:

Any load balancer configuration you have. Finally, you can:

Remove the certificate entries in Active Directory for ADFS. If you have removed ALL the ADFS instances in your organization, delete the ADFS node under CN=Microsoft,CN=Program Data,DC=domain,DC=local. If you have only removed one ADFS farm and you have others, then the value you recorded at the top for the certificate is the specific tree of items that you can delete rather than deleting the entire ADFS node.

Hardware Tokens for Office 365 and Azure AD Services Without Azure AD P1 Licences

Posted on 4 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, Multi-Factor Authentication, token2

A recent update to Azure AD Premium 1 (P1) licence has been the use of hardware tokens for multi-factor authentication (MFA). This is excellent news if your MFA deployment is stuck because users cannot use phones on the shop floor or work environment or they do not want to use personal devices for work activities. But it requires a P1 licence for each user. Now a P1 licence gives lots of stuff in addition to hardware token support for MFA, such as (but not exclusively) Conditional Access, which is a better way to implement MFA than when used without P1, which requires MFA in all circumstances and for all apps from all locations.

But if you want MFA in all circumstances and for all apps from all locations, and also need hardware tokens, this is where programable tokens come into play. I recently purchased a miniOTP-2 token from Token 2 (www.token2.com) and they provided me with a C300 token as well so that I could write this blog post.

In the scenario that I am going to describe here, I have two different programable tokens and I will walk through the MFA registration process for a user (using the new user interface for this service that was released end of Feb 2019).

IMG_20190226_095155

Enabling the new MFA Registration Process

Open the Azure AD Portal from https://aad.portal.azure.com, click Azure Active Directory from the primary menu and then select User settings from the sub-menu. Under Access panel, click Manage settings for access panel preview features. You will see the following:

image

In this I have previously turned on the preview features for registering and managing security info that was rollout out early 2018 and now I can see a second option for the same, but called refresh.

Set both of these options to All (or a selected group if you want to preview for a subset of users initially). Click Save.

For what follows, it will work even if you have None set for both options, just the screenshots will look different and the latest refresh of this feature is much easier for users to work with – so I recommend it is turned on for both options.

Configure MFA Settings for your Tenant

In the Azure AD portal sub-menu click MFA under Manage MFA Server and click Additional cloud-based MFA settings under Configure. This opens another tab in your browser where you will see the Multi-Factor Authentication / Service Settings.

Under Verification Options ensure that Verification code from mobile app or hardware token is enabled. Other options such as “app passwords”, “skip for federated users”, “trusted IPs” (available if you ever once had the AAD P1 licence on your tenant even if you do not have it now) and “remember multi-factor authentication” can be set to your requirements.

Register a Programable MFA Token for a User

Once you have MFA settings configured you can enable the service for a user and have the token registered for the user. If you have a P1 licence you upload the token serial number to Azure AD, but if you do not have a P1 licence then you need to use a programable token as these appear to act just like authenticator apps you get on your phone.

In Azure AD you can register a user’s token by logging in as the user (they would do this for you) by visiting https://aka.ms/mfasetup. End to end this process takes about 10 seconds – so its very possible to add this process into new user joining procedures or have help desk visit the user or the other way around. This process needs an NFC burner app and device (Android phone is good), but don’t require the user to do this themselves using their phone – burn the token for them using a help desk PC or phone. If you get the end user to walk through all these steps you will confuse them totally!

The new UI for end user security settings:

image

As mentioned above, the UI you see is based upon the User settings options in Azure AD. If you have just the original refresh enabled, you will see the following instead:

image

In the first of the above two screenshots I have already registered some MFA devices. If the user has never registered a device before then they will see the following when browsing to https://aka.ms/mfasetup from the initial login and then the MFA registration page, with the registration process ready to start:

image image

If you have already registered some security info, then you will be able to add a hardware token from the + Add Method button and selecting Authenticator App and clicking Next.

image

The initial steps will show you the following dialog, depending upon if you are a new user (on the left) or adding a new MFA method (on the right):

image image

You are walked through the process of installing the Microsoft Authenticator app on your phone. In this case though, we have a hardware token instead of the app, and so you need to click I want to use a different authenticator app instead. The Microsoft Authenticator App supports push notifications, which hardware tokens do not, and so the QR code provided for the Microsoft Authenticator app will not work for hardware or other authenticator apps.

image image (QR code intentionally blurred)

Now you need to scan the QR code using the Token 2 Android app or click Can’t scan image and copy and paste the secret key into the Token 2 Windows app. Links to the apps are available from the Token 2 website software page (with the Windows app shown below):

image

Click the QR button (or Scan QR button if using the NFC Burner 2 software) and scan the QR code on the screen. This enters the seed in HEX into the app. If you need to enter the QR code by hand, click enter Base32 and type in the secret key value that you get under the Can’t scan image link.

Next, turn the hardware token on (it will remain on for 30 seconds) and hold it to the NFC reader on your Android device (usually next to the camera) or plugged into your PC.

IMG_20190302_160227

Click the Connect button (or Connect Token depending upon the app you are using) – one of the Android apps are shown below:

Screenshot_20190302-173645

Then finally click burn seed.

Screenshot_20190302-173653

Turn off the token and turn it back on again – this displays the next valid code. The code that was displayed when the token was first turned on and before the new secret was burned to the device is not valid.

Click Next on the registration wizard on the computer screen. You are asked to enter the code displayed on the token. Azure AD has a 900 second range for codes, so any code displayed in the last 7 or so minutes should be valid to use

image

Success – if not, turn the token off and on again and try again. If not, go back, scan the code again and burn to the device another time – you are not restricted on the number of times you do this (though doing this wipes previous users of the token from using it again).

image

Click Done and see your first method of providing MFA shown to the user.

image

I recommend you add the users phone (for a call or text) as a second method at this point (in case they loose the token, they have a second route in). The user experience for when adding a phone looks as follows:

image

It is a shame we cannot rename the MFA method – that would be useful, as we could indicate the token name/type and then login to Azure AD could ask for this token by name.

If you were adding a new token to a user with existing MFA methods already in place, you end up in a very similar place:

image

Success – a new “app” added:

image

Then at next login when going to the MFA registration page, you need to enter your code:

image

Note that you don’t need the code yet for logging into Office 365 and Azure AD generally – you have to enable MFA for that and that is the next step.

Enforcing MFA for User

For all other logins apart from the MFA registration page, you need to finish by enforcing MFA for the user. If you have a P1 licence and Conditional Access then this will happen based on the rules, but where you don’t have AAD P1 licence, then you need to enforce MFA for all logins. Do this by browsing to the multi-factor authentication and users page via the Office 365 admin portal > active users > ellipses button > setup multifactor authentication:

Search for your user:

image

Once you have found the user to enable, select the user and then click the Enable hyperlink:

image

Followed by enable multi-factor authentication

image

The comment about “regularly sign in through the browser” is not valid for modern authentication supporting apps such as Microsoft Teams or where you have enabled Modern Authentication for Skype for Business Online and Exchange Online (you need to do this if your tenant exists from before August 2017)

image

Finally for completion, there is an MFA setting called Enforce. Enforce requires MFA for all logins including rich client applications that do not support MFA – therefore if you have modern authentication enabled and are using Outlook 2013 (with the Modern Auth settings for Outlook 2013 turned on) or Outlook 2016 and later then having the end user remain in Enable mode is fine. If you are using older clients that do not support MFA then Enforce mode will force them to use App Passwords for non-browser apps, and you want to try and avoid that.

Therefore we need to take the user to a minimum of Enable mode in Office 365 MFA so that MFA is triggered for all logins. This step is probably done after hardware token registration as when we set up the token for the user or when we sent the user through the registration workflow we did not first enabling MFA for the user – therefore the user is registered for MFA but not required to use it to login.

Set the user to Enable mode to trigger MFA for all logins:

image

Convert Office 365 Group to Microsoft Team Totally Failing

Posted on Leave a commentPosted in groups, Microsoft Teams, Office 365, Office 365 Groups, Teams

This one has been annoying me for a while – I had an Office 365 Group that I created many years ago in Office 365 that I cannot convert to a Microsoft Team.

This is what I see in Teams to do this process. First, click “Create a team”

image

Followed by “Create a team from an existing Office 365 group” which is found at the bottom of the creation dialog in the Teams app:

image

I get a list of Office 365 Groups but not the one I want. In my example I see six groups:

image

The rules for converting an Office 365 Group to a Team is the following:

  • Must be private
  • Must have an owner

Both of these are true for the group I want to convert, but the group still does not appear in the Teams conversion page shown above:

So I resort to PowerShell:

Get-UnifiedGroup returns all my groups and shows that the group exists (I know it does – its got content in it!)

image

So I get the Group ID using Get-UnifiedGroup <name> | FL *id*

image

Specifically I am after the ExternalDirectoryObjectID value

Then I try to make a new Team using PowerShell using the ExternalDirectoryObjectID. This is New-Team -Group <ExternalDirectoryObjectID>

image

I get back a lot of red text. In this is reads “Message: Team owner not found”. This is odd, as the Team does have an owner – I can see this in OWA for the Office 365 Group

image

And I can see this using Get-UnifiedGroupLinks as well:

image

So I decide to set the owner back to the owner again using Add-UnifiedGroupLinks PowerShell cmdlet (Add-UnifiedGroupLinks <group_name> -Links <myemailaddress> -LinkType Owner)

image

This returns nothing, so I presume nothing has changed.

I take a look in New Team > Convert Group option – and as if by magic, I can see the Office 365 Group I want to make into a Team

image

Its the one at the top in all these redacted images – the logo matches the group above, and I now have seven Office 365 Groups that are candidates for Teams.

Conversion then happens seamlessly!