Category Archives: Office365

Microsoft disables basic authentication in Office 365

I already wrote about Office 365 and Basic Authentication in two earlier blogposts:

The last update from Microsoft regarding basic authentication is published in June 2021:

https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-june-2021-update/ba-p/2454827

Microsoft has announced that it starts to disable basic authentication for customers that do not use basic authentication (for new Office 365 basic authentication is disabled by default).

I have disabled basic authentication is my tenant long ago and last week I got an email from Microsoft (MC274505, which can also be found in the admin portal) announcing basic authentication will be disabled in my tenant:

We’re making some changes to improve the security of your tenant. We announced in 2019 we would be retiring Basic Authentication for legacy protocols and in early 2021 we announced we would begin to retire Basic Authentication for protocols not being used in tenants.

30 days from today we’re going to turn off Basic Authentication for POP3, IMAP4, Remote PowerShell, Exchange Web Services, Offline Address Book, MAPI, RPC and Exchange ActiveSync protocol in your tenant, and will also disable SMTP AUTH completely.

Note: Based on our telemetry, no users in your tenant are currently using Basic Authentication with those protocols and so we expect there to be no impact to you.

If disabling basic authentication causes issues for your tenant, you can always re-enable basic authentication as outlined in the Microsoft link in the beginning of this blogpost. But please remember that basic authentication will be disabled permanently some day!

How to change MFA method for your Office 365 account

This might look like an easy blogpost (actually, it is) but every time I’m struggling with this, so I decided to write it down.

My default MFA authentication method was a text message (SMS) on my phone. This works fine, but it is not always easy to work with, especially not when using the native mail app on a mobile device. So, to change it, logon to OWA or the Microsoft Portal, click the initials in the upper right corner and click View account:

You can also navigate to https://myaccount.microsoft.com to get here directly. In the overview page click on Security Info to see the MFA methods available. To add a new method, click +Add Method.

In the pop-up window, select another method, for example the authenticator app and click Add. The first step is of course to download the authenticator app on your device, if it’s already installed click Next.

In the Setup your account pop-up box click next and a QR code will appear on your screen:

In the authenticatorapp, click the + icon in the upper right corner, select your account type and select Scan QR code. Approve the sign-in on your device, the security info will show Notification approved and you’re good to go.

The last step you have to do is to change the default sign-in method on the security info page by clicking Change next to Default sign-in method.

Microsoft Teams and Exchange 2016 connectivity

More than a year ago I wrote a blogpost regarding Teams calendaring and Exchange 2016 integration: https://jaapwesselius.com/2020/04/07/microsoft-teams-and-exchange-2016/.

Currently I am working with a customer on this specific scenario, and to my surprise I ran into this Teams/Exchange connectivity test on the Microsoft Remote Connectivity Analyzer (https://aka.ms/exRCA). Open the Remote Connectivity Analyzer, select Microsoft Teams and click the Teams Calendar Tab button. Login with the account you want to test (in this example I have an on-premises mailbox on Exchange 2019, but works for Exchange 2016 as well) and click Perform Test.

Within seconds you will see if connectivity from Microsoft Teams to your Exchange server is working properly. Very nice!

Office 365 Groups not showing up in Outlook 2016

I have had this annoying issue with Office 365 Groups (Groups, not Teams). In our IT team we have several Office 365 Groups. Some users do see these groups in Outlook 2016 almost immediately, other users do not see anything (I’m in this group). When I select Browse Office 365 Groups in Outlook, I see an error message saying We can’t show you group right now. Make sure Outlook is connected and try again as shown in the following screenshot:

we cant show you right now

In Office 365 Teams there are the HiddenFromExchangeClients and HiddenFromAddressListsEnabled properties (see the Hiding Office 365 Groups Created by Teams from Exchange Clients article from Tony Redmond for more information) , but this is only Office 365 Groups and not an Office 365 Team. And both properties are set to FALSE, so this is not the case.

I am using Office 365 ProPlus Click-to-Run which checks Exchange Online first for Autodiscover purposes, but then I realized I had been experimenting with some registry keys to change Autodiscover behavior. When checking the registry, I found the ExcludeExplicitO365Endpoint DWORD set to 1 as shown in the following screenshot:

ExcludeExplicitO365Endpoint

So, Autodiscover checks on-premises Exchange server and is redirected to Office 365 for Exchange Online information. Unfortunately, this does not retrieve any information regarding Office 365 groups. After changing this value to ‘0’, Autodiscover starts with Office 365 and does retrieve the correct Office 365 Groups information.

Related to this, there are also scenarios where Outlook does not detect Office 365 groups using Autodiscover where the (primary) SMTP address of the Office 365 group is not correct. For example, where the SMTP address of the group is (for example) IT-Calendar@contoso.com. You can change the primary address of the group using the following command in Exchange Online PowerShell:

Set-UnifiedGroup Alias -PrimarySmtpAddress IT-Calendar@contoso.mail.onmicrosoft.com

Or when you want to add the SMTP address as a secondary address:

Set-UnifiedGroup IT-Calendar -EmailAddresses @{add="it-calendar@contoso.mail.onmicrosoft.com"}

This should also solve the problem.

ExoPrise Cloud Monitoring solution

When you are running an on-premises IT environment you most likely have some kind of monitoring solution. If something goes wrong in the infrastructure you are notified almost immediately, and you can take appropriate action.

Things are different when using cloud services. Your services are running in a datacenter somewhere else, controlled by another organization and with an internet connection (that sometimes can be unreliable).

For a customer I checked out ExoPrise, a SaaS (Software as a Service) based cloud monitoring solution. With surprising results.

ExoPrise private site

Exoprise is a cloud monitoring solution which is offered as a SaaS solution. This means Exoprise is running in a datacenter somewhere, and you have a subscription for using the services. Because it is a SaaS solution, installing and configuring the monitoring solution is just a matter of minutes.

Exoprise is running in a datacenter somewhere, but when using Exoprise you configure your own private site. A private site is a WIN32 service running on a Windows server in your own environment. From this private site, cloud services are monitored. From an end-user perspective, the private site has the same user experience as your local users have.

You can install and configure multiple sensors in your private site. Each service has its own sensor, there are sensors for Exchange Online, Microsoft Teams (Messages and A/V), Skype for Business, Free/Busy, ADFS, OneDrive, SSLCheck, Amazon, Google, Salesforce …. Tons of sensors are available.

When configured, a sensor performs synthetic transactions against the cloud service. For example, the Exchange Online sensor looks at the average logon time, message transfer speed and network latency. The results are shown graphically for your own sensor, but because it is a SaaS solution Exoprise can compare your results against the results of the rest of the world which they call ‘crowd’. This is shown in the following screenshot, the lower line is my own sensor, the upper (thinner) line is the crowd average.

With all this working from home due to the Covid-19 crisis a lot of organization have been implementing Microsoft Teams rapidly. As an admin you want to know you Teams is performing from your local environment. When configuring a Teams AV sensor it performs all kinds or synthetic transactions, very similar to the transactions a regular user is performing. The sensor is using a test identity in your Teams environment and it uses a bot in Exoprise to communicate with. This way it can measure the call quality of Teams and it measure logon time, A/V streams (audio jitter, packet loss, bitrate), frames per second etc.

When configuring a sensor, an alarm is automatically created. This alarm can be configured during creation:

When the sensor is triggered because of a transaction, an alarm is sent to the email address that is configured and this gives you an immediate overview that something is wrong with the service. And to be honest, I was a bit surprised how often alarms are generated and thus how often you will receive an email. The email will show which sensor is generating the alarm, some analysis information and alarm details as shown in the following screenshot.

Besides the alarm message you’ll also get a weekly overview with real user performance data that is gathered from ‘the crowd’ so it averages over all Exoprise sensors that are deployed. This will show overall trends for all cloud services, for example:

Summary

There are multiple cloud monitoring solutions available and I had the opportunity to have a look at the ExoPrise solution. I was surprised by the ease of configuration and ease of use. It is a cloud based service, pull your credit card and you’ll be working within 20 minutes. It is a great tool for monitoring your environment, but at the same time it is a great tool for troubleshooting purposes (when you are a consultant).

I was also surprised by the data that was gathered by the ExoPrise sensors. It shows immediately when something is wrong, and you are notified before your users start calling the servicedesk that something is not working. And that happened more often than I thought before.