Office 365

Azure ADOffice 365

For Heaven’s Sake, Just Turn on MFA Already


It’s time for some real talk: not enough of us are using multi-factor authentication. For example, Twitter estimates that only about 2% of their users have MFA enabled for their Twitter accounts—which is terrible, but at least they release their usage data.

I’d expect similarly low uptake for other consumer services—after all, most consumers aren’t security experts—but we really should expect and demand better for enterprise accounts. And yet a rather shocking number of cyberattacks are publicly attributed to account compromises linked to a lack of MFA: in 2020, Microsoft’s Alex Weinert said that 99.9% of successfully attacked Microsoft 365 accounts had MFA disabled.

Security vendor Yubico released a report that makes for some interesting reading about what enterprises say they’re going to do (hint: they’re going to spend more money, especially on tokens from Yubico), but a mediocre plan executed now is better than a great plan executed later—so let’s get started and get MFA turned on in your tenant.

Two ways to get started

Microsoft, much to their credit, has done a ton of work to improve the capability and resiliency of multi-factor authentication in Azure AD. There are four ways you can take advantage of MFA in your Microsoft 365 estate.

First, you could just enable it manually and selectively for individual accounts. Don’t do this. It’s conceptually simple, but it’s also far too easy to leave out accounts, and it will require too much ongoing maintenance in the future as users come and go. Because this is a bad suggestion, I won’t officially count it as a way to get started.

Second: if you’re using Microsoft 365 Business, E3, or E5, MFA will either be on for everyone or off for everyone. So I suppose that’s a second way to get started, but perhaps not what you had in mind.

The first real way to get started is to use the “security defaults” feature that Microsoft introduced in 2019. If your tenant was created after then, good news: this is already enabled for you, and you probably don’t need to do anything. If not, as the linked article explains, it’s simple and easy to set up. Microsoft even says “If you are an organization that wants to increase your security posture but you don’t know how or where to start, security defaults are for you.” It’s easy enough to do this that I won’t cover it further here.

The other real way to get started is to use Azure AD Conditional Access (CA). This can be much more complex than security defaults, and it requires Azure AD Premium P1 or P2 licenses, but it gives you a great deal more flexibility and control.

Read more: Achieving Passwordless Authentication in Azure AD

Conditional access basics

The idea behind CA policies is straightforward: every time a user or device requests access to a resource in Microsoft 365, the endpoint they’re talking to expects to see an authentication token. If there’s no token, or the token is expired or invalid, the endpoint will force the client to authenticate.

In the simplest possible scenario, that means that the user sees a logon dialog and enters her credentials, which Azure AD then checks, issuing a token if they’re valid. CA extends this process by letting you add conditions and exceptions—you can think of these as if-then rules. For example, you could create a rule that says “if a user is signing in to the Azure management portal from a location I don’t trust, require MFA” or “don’t require MFA for users who sign in to Teams from inside our corporate network.”

Conditional Access is incredibly capable and flexible; for example, you can easily create policies that block older versions of Android and iOS (possibly a good idea given the rate at which zero-day vulnerabilities have been coming to light) without affecting access from other clients.

To manage CA policies, you’ll need to log in either to the Azure portal (then go to Azure Active Directory > Security > Conditional access) or the Microsoft Endpoint Manager portal (Endpoint security > Conditional access). Although there are a ton of things you can do with policies, we’re going to focus on a simple policy to require MFA for your users.

Creating an MFA policy

The basics of creating a policy are pretty easy; where you can get into trouble is in choosing the right mix of options from the many choices that Azure AD CA policies support. I always like to suggest starting with a written-language description of what the policy is supposed to do, using a simple template:

This policy will [allow or deny] access for [which users] when using [which applications?] but only when [conditions]

In this case, “This policy will allow access for all ‘real’ users in all applications but only when they authenticate with MFA.” You can see that the template approach makes it easy to see what the desired end result is—that sample is going to obviously require different policy settings than a template that says “This policy will block access for global admins but only when they are connecting from Pyongyang.”

Start with the basics:

  1. Log in to using an account that has Global admin, then navigate to Azure Active Directory > Security > Conditional access.
  2. Click + New policy.
  3. Give your policy a name, ideally one that will make sense to you when you look at it a year from now and wonder “what did I create that for?”

Who gets the policy?

Next you need to decide which users will be affected by this policy. The users and groups control in the left nav bar allows you to both include and exclude users. You can choose to apply this inclusion or exclusion to several categories: no one, all users, or selected users, where the selection is based on their guest status, the directory role they hold, or the group membership you specify. Examples of problems you can solve using these controls include:

  • Including all guest users
  • Including all users except for users in the “Sales” security group
  • Excluding all users except for users who hold the “Azure DevOps administrator” role

Most admins will be tempted to use these controls in combination to make fine-grained policies. While you certainly can do this, it’s always a better idea to start simply. In our case, we want to require MFA for ‘real’ users—which just means “users who are actually humans and not service accounts, etc”.

This is a little harder than it sounds, because Azure AD doesn’t have a way to separate real-human accounts from service accounts; you’ll need to put them in their own groups. In my small tenant, I only have two service accounts, so I just picked them separately on the “exclude” tab. The “include” tab, not shown, has the “all company” group I created. The result is something like this:

For Heaven’s Sake, Just Turn on MFA Already

What apps does it apply to?

You may decide that certain apps are more sensitive or important than others; conversely, you may find that users complain more about being required to occasionally authenticate with MFA in some workloads.

The Cloud apps or actions lets you fill in the “when using” clause of your template. As with user selection, you can include and exclude all apps or choose them individually. If you choose to include or exclude specific apps, you’ll find that the app list includes every app that’s registered in your Azure AD tenant, so you can apply CA policies to third-party apps and your own line-of-business apps, not just Microsoft 365 apps. For our sample policy, we’ll choose to include “All cloud apps.”

Setting conditions: “only when…”

Now we get to the fun part. Right now, there are six categories of conditions you can use, some of which require additional Azure AD licenses: user risk, sign-in risk, device platform (Android, iOS, Windows Phone, Windows, and macOS), locations, client apps, or device filters. If we want to apply the broadest possible requirement for MFA, the simple way to do this is to set a Client apps condition by selecting the Configure control and then enabling Browser and Mobile apps and desktop clients.

You could also enable the condition for legacy Exchange ActiveSync clients and other historical oddities, but those clients typically won’t have a facility for using MFA so you shouldn’t expect them to work properly. Choosing these options will give you something like the following example:

For Heaven’s Sake, Just Turn on MFA Already

The most important part!

Lurking at the bottom of the new-policy page is a small control that looks like this. It’s easy to miss, especially on screens that don’t have a lot of vertical resolution, but you’ll sort of be forced to see it because it’s right next to the Create button.

For Heaven’s Sake, Just Turn on MFA Already

Microsoft defaults the Enable policy setting to Report-only. This is an excellent choice, and you should keep it that way until you’re confident that the policy does only what you want. If you’ve ever accidentally deployed an Active Directory group policy or Exchange retention policy that did something undesirable, you know the sinking feeling that comes when you realize that your incorrect instructions are being cheerfully, and destructively, carried out by the policy engine. Intune will happily give you that same feeling if you let it.

Next steps

Once you’ve tested that the policy applies only to the users and applications you meant for it to, you can flip the enable toggle to On and start enjoying some extra security. That’s really just the first tiptoe step into the world of what Intune can do, though; you can create policies to manage many other aspects of how your users, applications, and devices are allowed to interact with, and through, Azure AD and the other Microsoft 365 workloads.

Source Practical365

read more
Active DirectoryAzure ADAzure App ServiceAzure BackupAzure MediaAzure NetworkAzure SQLOffice 365Sharepoint

Attend TEC 2021 and Learn from the Very Best


TEC 2021 (The Experts Conference) takes place as a free virtual event on September 1-2. has a close relationship with TEC as many of our writers are TEC speakers, so I thought that I’d highlight some of the sessions I am looking forward to. Many other sessions covering different topics are on the TEC agenda, so you’re sure to find something interesting to attend.

Please register for TEC to access the sessions. Even if you can’t attend on the day, you’ll be able to use your registration link to access recordings afterwards. Of course, attending live is best because you’ll then have the chance to participate in the live Q&A following the recorded segment of each session. Be nice to the presenters and don’t throw too many curve balls… With that said, here’s my curated list of TEC 2021 sessions. All times are in U.S. eastern time.

Artificial Intelligence and Microsoft 365

Some excellent Microsoft speakers are going to share their unique perspectives on different aspects of Microsoft 365 technology. At 10:30AM on September 2, Jeffrey Snover, the CTO for Modern Workplace Transformation (a fancy name for making stuff work across Microsoft 365) will deliver a keynote covering the use of artificial intelligence within Microsoft 365. Sometimes people get worried about the use of machine learning and AI within Microsoft 365 as they see features like insights and suggested responses turn up in email and meeting requests. I’m more focused on the use of AI in applications like Viva Topics. Jeffrey says that AI will make features more intelligent and easier to use. Turn up and see what you think!

Protecting Office 365 Against Attack

Practical365 traffic spiked in March when the Hafnium attack exploded and many Exchange on-premises administrators discovered just how exposed their servers were to attack. Alex Weinert, Director of Identity Security, is going to improve our knowledge about how attacks develop, the techniques used to penetrate systems, and how Microsoft and other security companies work to mitigate and close off vulnerabilities. Specifically, he’s going to analyze the Nobelium (SolarWinds) attack in December 2020 during his 1:30PM session on September 1.

Using Sensitivity Labels with SharePoint Online

Sensitivity labels are a great way to apply rights management-based encryption to Office documents. They can also be used to protect containers (Teams, Groups, and Sites). I can’t think of a better person to come along and talk about how to protect SharePoint Online and OneDrive for Business with sensitivity labels than Sanjoyan Mustafi, a Principal Product Manager who’s one of my go-to people whenever I have a question about the inner workings of sensitivity labels for SharePoint content. Sanjoyan speaks at 1:30PM on September 2. Apparently, he might even drop some hints about some new features due to appear soon.

Collaborating Teams Channels

A conference would be a pretty bland affair if only Microsoft people spoke, so TEC has many other experts come along to talk about different aspects of technology. MVP Curtis Johnstone talks at 12:45PM on September 1 about the different types of channels used in Teams, including the new shared channels first revealed in March and now getting close to public preview. Curtis plans to cover how shared channels work, differences with private channels, and how organizations can govern channel use.

Power Automate and Teams

Microsoft spends a lot of time banging the publicity drum for Teams and Power Automate. MVP Christina Wheeler brings some practical advice (always appreciated at at 1:30PM on September 1 to show how to connect the two technologies to get real work done by exploring how to launch a flow from a Teams bot.

Go to OneDrive

At 12:45PM on September 2, MVP Andy Huneycutt dives into the topic of moving people off network drives to OneDrive for Business. Many good business and technology reasons exist for this transition. Better data governance, more stable infrastructure, more visibility over content, better sharing, and so on. And of course, the simple fact that Office 365 and Microsoft 365 apps are built to use OneDrive for Business (Stream and Whiteboard are both moving their storage to OneDrive for Business). Why anyone would stay on old-fashioned network drives is beyond me…

Manage Exchange Online at Massive Scale

SAP is a very large software company that also uses Exchange at massive scale. MVP Ingo Gegenwarth gets lots of practice running PowerShell scripts to process tens of thousands of objects, and he’s going to share his experience and give some tips and techniques for how to approach the problem of dealing with so many objects at 2:30PM on September 1. I suspect Ingo might even say that it’s a good idea to use the Microsoft Graph API with PowerShell to get data about service incidents or interrogate Azure AD.

Removing the last Exchange On-Premises Server

After the Hafnium exploit in March, some organizations started to look more closely at the question of removing the last Exchange on-premises server. This has been a hotly debated topic for years, with some people saying that it’s easy to do (by performing brain surgery with ADSIEdit) and Microsoft continually saying that they are seeking a more graceful solution. Steve Goodman takes on the challenge of reporting the current situation at 12:45PM on September 2.

Group Policies Are Dead: Long Live Intune

I hate Group Policy Objects (GPOs). For years, they’ve been a necessary evil to enable workstation and server management. Intune is a better solution, especially in the world of Microsoft 365 where the PC is not the sole focus. Paul Robichaux covers this topic at 11:45AM on September 2 with a real focus on making management easier for your Microsoft 365 tenant.

Leveraging the Graph to Manage Microsoft 365

Finally, if you have time, you could attend my session at 11:45AM on September 1 where I’ll discuss how to use the Microsoft Graph APIs to manage Microsoft 365 tenants and applications. This is not a session for programmers. It’s focused on tenant administrators who automate processes with PowerShell today and want (or need) to use some Graph APIs with PowerShell. Maybe it’s just to get work done faster (like when you need to process thousands of mailboxes) or it’s because a Graph API is the only way to change a tenant setting.

Many articles cover different aspects of using the Graph APIs from reporting the storage used by Teams channels to updating tenant privacy controls. It should be a fun session (for me anyway!).

Enjoy TEC 2021. I plan to and hope that you’ll come along and have a terrific time sharing knowledge with some excellent speakers.

Source Practical365

read more
Office 365

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default

185-07_1-1-300×162 (1)

For many organizations, Exchange Online (EXO) will be their first access point into Microsoft 365. While there are many similarities in how the cloud service is managed compared to an on-premises Exchange deployment, there are also many new concepts and risks introduced. The responsibilities of a traditional Exchange Administrator after moving to EXO are vastly different from what they were previously used to.

In this article, I will outline the most important steps an Exchange Online Administrator needs to take to make EXO secure by default. While there are a lot of nifty security tools we can leverage with the appropriate licensing, all the steps outlined in this article can be achieved with basic licenses.

Disable Legacy Authentication

This one should be no surprise to anyone. The first step that should be taken to make your Exchange Online environment secure by default is to disable Legacy Authentication. In the context of Microsoft 365, Legacy Authentication is not a single protocol, more an umbrella term used to describe any protocol that uses Basic Authentication. Steve Goodman wrote a great article on how to do this which I strongly recommend you review.

For tenants with Azure Active Directory Premium, Conditional Access can be used to block Legacy Authentication at a tenant, app, or user level. But as Conditional Access only applies after the initial authentication occurs, Legacy Authentication should still be turned off at a service level in Exchange.

Microsoft is pushing to disable Legacy Authentication and has recently announced that they will be retiring it from any tenant that is not currently using it. Owners of these tenants will be notified by a Message Center Notification.

Implement Multi-Factor Authentication

Multi-Factor Authentication (MFA) is an extremely effective method to provide additional verification for user sign-ins. With the abundance of Phishing attempts that occur daily for large organizations, it can often be the last line of defense against an attacker gaining access to confidential data. It is also extremely easy to implement.

For tenants with Azure Active Directory Premium, Conditional Access can be implemented to allow for some cool scenarios such as bypassing MFA on trusted devices, from trusted networks and even reassess the requirement based on user state changes with the continuous evaluation feature.

If you don’t have Azure AD Premium though, you can still protect your tenancy with Azure AD Security Defaults. This will allow you to enforce MFA for all users very easily, although the flexibility of Conditional Access is lost here.

Understand and Secure Exchange Online Mail Connectors

Out of the box, Exchange Online has default send and receive connectors and unlike Exchange On-Prem, you can’t see or modify them. Exchange Online has some top-class mail protection available through Microsoft Defender for Office 365 but that requires additional licensing to leverage. Some organizations will opt to maintain a third-party service instead of fully moving inbound and outbound mail protection to Microsoft, and that’s fully supported in Exchange Online however there are some considerations to this configuration.

The most important consideration is the default connectors I mentioned above. When you set your MX records to route inbound mail via a third-party gateway, it’s important to remember that MX records are not an enforced mail route, they are simply letting other mail systems know the advertised/preferred public mail route. By default, nothing is stopping external systems from sending mail directly to Exchange Online, bypassing your third-party protections.

To protect against this, a new connector is required in Exchange Online to ensure that mail from external domains is only accepted from your designated sources. This connector needs to specify “*” as the domain to catch all inbound mail and can be set up like the example shown in Figure 1:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 1: Connector enforcing secure inbound mail route.

My recommendation is that for any mail connectors you set up, to use certificate validation wherever possible and to enforce TLS. IP-based restrictions are available but not as secure as using a public certificate and enforcing TLS.

With this connector set up, when a mail is sent directly to Exchange Online for your organization, it will be denied with a delivery status notification 5.7.1:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 2: Mail is rejected with DSN 5.7.1 if it has not routed through your specified endpoint.

Implement SPF, DKIM, and DMARC

Sender Policy Framework (SPF), DomainKeys Identified Mail Standard (DKIM), and Domain-Based Message Authentication, Reporting & Conformance (DMARC) are email security controls that protect public mail domain reputation. They are used to ensure that your outbound mails can be verified while helping to ensure spoofed mails from your domains are blocked by recipients.

While you can’t control the protection standards of other organizations’ mail systems, you can help them to determine if mails received from your domains are legitimate and be informed when your domain is being spoofed.

Let’s look at a brief description of each control:

  • SPF uses a public DNS TXT record to inform organizations about the authorized source mail systems for your domain. It does this by publishing source IP addresses/ranges for your domain. It also has a lookup functionality to allow you to specify A records or MX records as authorized sources.
  • DKIM does a similar job to SPF by allowing you to verify the source of your emails but can be more effective in complex scenarios as it uses certificate signing for outbound mails. An encrypted header is added to outbound mail using a DKIM signing certificate, which can be validated against a public key that is advertised via a public DNS CNAME record.

For a detailed breakdown of SPF and DKIM setup, check out Alan Byrne’s article here.

  • DMARC is a little different in that it’s not a specific control, rather a set of instructions that external mail servers should honor when validating SPF and DKIM from your domain. DMARC works by publishing these “instructions” in public DNS for receiving servers to follow when they get an email from your domains. This record is a TXT record that can specify the following values:
    • v – What version of DMARC is being used? (Currently, the only version is version 1)
    • aspf – Should SPF be verified?
    • adkim – Should DKIM be verified?
    • p / fo – What should happen if SPF and/or DKIM fail? (Nothing, Quarantine, Reject)
    • rua – Should aggregate reports be sent back you your mail system and to what address?
    • ruf – Should individual failure / forensic reports be sent back to your mail system and to what address?
    • sp – Should there be a separate policy for subdomains?
    • pct – *What percentage of mails should DMARC apply to?

*When rolling out DMARC, you can specify a percentage of mail to apply it to, gradually working towards 100%

A fully implemented DMARC TXT record will look like this:

With each of these controls in place, you aren’t just helping to protect your domain against spoofing, but also minimizing the likelihood that your legitimate mails will be seen as spam on the recipient side. This doesn’t replace having appropriate outbound mail filtering in place but goes a long way to protecting your public domain and gaining insights into potential issues.

Enable Admin Consent for Azure AD Apps

Securing user authentication is an effective step in preventing unauthorized access to data within your organization but there are other means that attackers can use to get control of a user’s account. One of these methods is by creating an application which requests users to grant permissions to aspects (scopes) of their data / profile. This can be very useful for application developers who need to access services on behalf of the user, say for example, allowing a scheduling app access to a user’s mailbox / calendar.

The risk with this type of access is that we don’t (by default) predefine which applications can access our tenancy and a user may end up consenting to access from a malicious app. Once the application is granted permissions on the defined scopes, it doesn’t need the users password or MFA to access data on behalf of the user. The user will be prompted to consent when they sign up for the app, similar to Figure 3:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 3: Request for consent from Graph Explorer.

To combat this risk, you can configure Admin Consent in Azure AD. This prevents users from directly granting consent to applications and instead will allow an administrator to approve it after ensuring it’s safe. I recommend checking out this article for a detailed breakdown of how to implement admin consent in Azure AD.

Implement External Email Tagging

Helping users to easily identify external mail can go a long way towards protecting against phishing/spoofing attempts. Adding a tag to mail as it comes in makes it clear to end-users that they should be extra vigilant if the mail contains sensitive content. There are a few ways to implement tagging for external mail, each delivering a similar result, so whichever one you use is up to you.

The first way to accomplish this is to implement a transport rule to prepend a disclaimer to emails that originate externally such as the one shown in Figure 5:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 4: Prepend a disclaimer to external mails.

This rule can even add HTML content to draw the user’s attention, an example of this is shown in Figure 5:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 5: HTML Disclaimer.

The drawback to this method is it tends to break any message preview function in mail clients as the first few lines of text will always be the disclaimer.

Another way this can be implemented is simply prepending some text to the subject. This can also be done with a transport rule. To stop this rule triggering every time there is a reply to a message trail, make sure to add an exception to the rule as shown in Figure 6:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 6: Prepend a tag to the message subject.

For organizations who solely use Outlook to access Exchange Online from different platforms, there is also the built in external email tag functionality which can be enabled organization wide. This tag (Shown in Figure 7) will only show up in Outlook / Outlook Web so the mail apps in your organization will need to be considered.

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 7: External tag in Outlook.

Turning on this feature is as simple as running a single command in Exchange Online PowerShell as shown in Figure 8:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 8: Enabling external email tagging in Outlook.

Mobile Application Management

Microsoft Endpoint Manager (MEM) / Intune – if you are licensed for it – can provide some powerful features to ensure that when users connect to data in your organization, that the data can be protected from export to an untrusted device or location. By implementing Mobile Application Management Policies, export of data from corporate applications (such as Outlook Mobile) can be restricted. This unlocks a lot of BYOD scenarios without putting corporate data at risk. It’s important to note that Mobile Application Management will only work with supported applications so if enabling MAM, make sure to also restrict mobile access to these applications using Conditional Access as shown in Figure 9:

The Most Important Steps an Administrator Can Take to Make Exchange Online Secure by Default
Figure 9: Enforcing supported MAM apps on mobile via Conditional Access.

Configure Microsoft Defender for Office 365

Microsoft Defender for Office 365 (formerly Office 365 ATP) is a powerful tool for protecting Exchange Online from all types of malicious email traffic such as Phishing, Malware and regular Spam. While it does require some premium licensing, the feature-set and protection available provides a lot of value for money by making available a lengthy list of features.

Getting started with Defender for Office 365 doesn’t need to be a pain either, and you can read more on that here.

Define Data Loss Prevention Policies

Data Loss Prevention (DLP) policies can allow organizations to secure and control data as it leaves the organization. By defining DLP policies particular patterns (or Sensitive Information Types) can be detected within content as it is shared externally, and a set of rules are applied to determine if the data is allowed to exit the tenancy.

For example, an email with a list of credit card numbers can be blocked due to the contents, while a single credit card number can be sent but with Office Message Encryption applied. It’s important to note that DLP should be used alongside user vigilance and training, it isn’t designed to replace good practice when it comes to protecting data.

Once defined, DLP can then be extended to SharePoint Online, OneDrive and even Microsoft Teams. To make sure you can extend the policies, they need to be configured as Unified Policies within the Microsoft 365 Compliance Center. Having a single set of rules in the tenant for what can (or can’t) be shared externally via any method, will avoid “Loopholes” in the controls.

For an in-depth look at DLP Policies in Office 365 I highly recommend checking out this article by Paul Cunningham.

Note: DLP for Exchange requires a minimum of Exchange Online Plan 2 licensing


There are a lot of methods you can implement to improve the security of your Exchange Online environment, and even more tools out there made by Microsoft and third-party companies that can assist with security initiatives.

And while there are many advanced features and settings to consider down the road, in this article I’ve detailed some of the most important steps that can immediately be implemented out-of-the-box to align your Exchange Online tenant with a good security baseline and posture.

Source Practical365

read more
Office 365

Microsoft Insists on Office 365 E5 for Automatic Decryption of Protected Documents in eDiscovery Searches


Feature Should be in Core eDiscovery

Sources inside Microsoft tell me that approximately 10% of eligible Office 365 tenants use sensitivity labels to protect information with encryption. Reflecting Microsoft’s recent efforts to increase coverage of sensitivity labels, notably through native support in the Office desktop apps and much better support in SharePoint Online, the number of tenants using sensitivity labels for both information protection and container management is steadily growing.

To apply sensitivity labels to messages and documents, users need at least the Office 365 E3 plan; to auto-apply sensitivity labels, they need Office 365 E5. Users with lower plans can read protected files, but they can’t apply labels. We know that Microsoft has sold just under 300 million Office 365 seats. Assuming that the enterprise section is roughly two-thirds of this number, maybe 20 million people are using sensitivity labels, which adds up to a lot of protection.

Protected Content and eDiscovery

All of which brings me to Microsoft’s documentation for how to handle protected content exported for eDiscovery cases. We’re talking about email and comments protected using sensitivity labels (Microsoft Information Protection) or the older Azure Rights Management technologies. In a nutshell, the situation is this:

  • After you enable sensitivity labels for Office files in SharePoint Online, Microsoft Search can index the encrypted content and make it available for eDiscovery. Encrypted email is always indexed and discoverable.
  • When you use a Core eDiscovery case or content search to find protected content, the export feature decrypts protected messages and attachments but does not decrypt protected files stored in SharePoint Online or OneDrive for Business.
  • To get automatic decryption of exported files (some exceptions exist, like sensitivity labels with user-defined permissions), you need the export capability built into Advanced eDiscovery. And to use Advanced eDiscovery, you need Office 365 E5 licenses for every account covered by the eDiscovery case.

It’s possible to decrypt protected content before export by removing sensitivity labels from files using the Microsoft Graph. Another solution is to assign rights management super-user permission to an account and use the account to run the PowerShell Set-AIPFileLabel cmdlet to remove labels from files. Although these solutions are available to Office 365 E3 tenants, the process of extracting and decrypting content is intensely manual and unsuitable for dealing with large numbers of files. It’s so much easier when Office 365 does all the heavy lifting to find, decrypt, and export content.

Decryption Should be a Core Capability

If Office 365 E3 users can apply sensitivity labels to protect content, their tenant administrators should be able to search for and decrypt files retrieved by core eDiscovery. Although I can understand why Microsoft wants to emphasize the benefits of Advanced eDiscovery by stuffing as much functionality as it can into it, there are enough features (like the ability to display complete Teams conversation threads) in Advanced eDiscovery already. And if Exchange Online is happy to decrypt protected messages and attachments for Core eDiscovery, there’s no good reason for Advanced eDiscovery not to do the same for files found in SharePoint Online and OneDrive for Business.

Source Practical365

read more
Office 365

Configuring Microsoft Defender for Office 365


Microsoft Defender for Office 365 (Previously Office 365 Advanced Threat Protection) is a suite of tools/policies that provides powerful protection for your Office 365 environment.

Using tools such as Safe-Links or Safe-Attachments, you can protect your Exchange Online, Teams, SharePoint Online, and OneDrive against malicious content in documents or hyperlinks. You can also use Advanced Anti-Phishing Policies to detect and prevent phishing in Exchange Online. This is all available under the Defender for Office 365 Plan 1 license.

With the enhanced Plan 2 licensing, you can unlock an in-depth solution by leveraging tools like Threat Tracker and Explorer to hunt and report on the potential issues in the environment. You can also leverage Attack Simulations to perform Malware / Phishing Campaigns to help users to stay vigilant.

Note: For a full breakdown of features available under different licensing SKUs, check out the table in this article.

Getting Started

Defender for Office 365 provides a lot of configuration options and thresholds that can be customized to suit your organizational policies and requirements. When getting started, it’s easy to get lost in the sea of checkboxes and buttons.

Luckily, Microsoft has provided some great guidance on this through the Recommendations for EOP and Defender for Office 365. You’ll want to use this page as a guide for your initial setup to make sure you can align with Microsoft recommended practices.

That being said, there is a lot of manual work involved in going through the documentation and updating your configuration in line with the guidance provided. A nice way to get a quick report on the configuration status of Defender for Office 365 is to run the Office 365 Advanced Threat Protection Recommended Configuration Analyzer (ORCA).


Tony Akers has published a great article on using the ORCA tool here which I highly recommend reviewing sooner than later.

The ORCA tool aims to help administrators compare their configuration against the recommendations and perform a gap analysis against their live settings. Microsoft has now made this even easier by directly integrating the ORCA functionality into the Microsoft 365 Security Portal.

This integration comes in two forms, Preset Security Policies, and Configuration Analyzer. Later in this article, I’ll review how to use each of these tools to make configuring Defender for Office 365 an easier process.

Preset Security Policies

Preset Security Policies are useful for organizations that don’t want to spend a whole lot of time and effort tweaking settings and are happy enough to comply with the recommendations provided. The policies can be found in the “Threat Policies” section of the Microsoft 365 Security Portal and offer two “flavors” of protection: Standard and Strict.

The policies align with the Standard and Strict levels defined in the Microsoft recommendation documentation and once configured, there is no customization involved.

The policies can be assigned to users, groups, or mail domains, similar to any Defender for Office 365 Policies. Simply select the baseline you want to apply as shown in Figure 1, select the assignment for EOP and Defender for Office 365 settings, and you’re done!

*It’s important to note that the Strict Policies will always take precedence over the Standard ones, and custom Defender policies will take precedence over the pre-set ones.

Configuring Microsoft Defender for Office 365
Figure 1: Defender for Office 365 Preset Security Policies

Configuration Analyzer

Configuration Analyzer integrates the functionality of the ORCA tool directly into the Microsoft 365 Security Portal. Found in the same location as the Present Security Policies, the Configuration Analyzer takes the concept of the PowerShell-based ORCA and expands on it. The Analyzer page is split into two sections:

  • Setting and recommendations
  • Configuration drift analysis and history

The “Settings and Recommendations” page gives a view of any policy item that doesn’t align with a particular baseline. Here you’ll see the policy item, policy type, current setting, and recommended setting, as shown in Figure 2:

Configuring Microsoft Defender for Office 365
Figure 2: Configuration Analyzer – Settings and recommendations.

For any items that skew from the baseline, there is also a handy “Adopt” option that can be used to remediate any setting listed to bring it in line with recommendations. Clicking this will prompt you to confirm the policy change and once confirmed, the setting will be automatically changed as shown in Figure 3:

Configuring Microsoft Defender for Office 365
Figure 3: Adopting Baseline Configuration Items.

Along with the Configuration Analyzer allowing remediation and comparison, the “Configuration drift analysis and history” section allows you to view changes that have been made to the configuration over time. This analysis shows what settings have been changed, by who, and when.

We can also see how the changes affected the comparison to baselines. In Figure 4, the change I made in the above section can be seen logged and the “Configuration Drift” column is showing an increase, which means it moved the configuration closer to the baselines. This data can also be exported as a CSV file for long-term storage or documentation:

Configuring Microsoft Defender for Office 365
Figure 4: Historical changes are available in the Configuration Drift Analysis and History section.


Defender for Office 365 allows a lot of room for customization based on customer requirements; however, not every organization will need to stray too far from the Microsoft recommendations.

That’s where Preset Policies and Configuration Analyzer steps in and can help you to very quickly align with the guidance provided, allowing you to focus on the settings that matter the most in your environment.

Source Practical365

read more
Exchange ServerOffice 365

Microsoft 365 E3 License vs. Microsoft 365 E5 License


There is little debate over whether the Microsoft 365 E5 license is a fantastic product. However, over the past two years, the E5 license offering has matured greatly, and it seems like Microsoft customers would be even more receptive to the upgraded license. If anything, customers will see major benefits from a one-stop-shop approach that replaces the need for third-party endpoint protection and mail hygiene solutions with Microsoft 365 E5 services like Microsoft 365 Defender for Endpoint and Microsoft 365 Defender for Office 365.

But does everything residing only in Microsoft 365 E5 truly belong there?  I’ve been pondering this question for a while now and believe that there is a compelling case for certain premium features to make the journey over to Microsoft 365 E3.

Pros vs. Cons

The benefits are two-fold in my opinion: First, it makes important security features that are no longer simply “nice to have” more accessible to a wider customer base.  It also gives Microsoft the incentive to stay at the leading edge of innovation and bring new and exciting features to their premium offering. While this rationale definitely made sense to me, I was curious as to what my colleagues thought, so I decided to pose the question on my Twitter feed:

Figure 1: Opening a can of worms on social media around the Microsoft 365 E5 debate.

The responses were numerous and quite varied, with many opinions on the matter. Before we examine the responses, it should be noted this licensing discussion revolves around Microsoft 365, not Office 365 – two very different things. For example, basic Microsoft 365 E3 security capabilities are not included within the Office 365 E5 license. For more information on how Microsoft 365 and Office 365 differ, you can also refer to this Microsoft page.

Which Features are the Most Wanted in Microsoft 365 E3?

After tallying up the responses, most of those voting for Microsoft 365 E5 were only voting for those specific E5 features.  However, there were two clear favorites in Privileged Identity Management and Auto labelling (Table 1):

Microsoft 365 E3 License vs. Microsoft 365 E5 License
Table 1: Twitter survey responses.

Other non-feature specific responses included:

  • Eliminate add-on licenses such as Viva and SharePoint Syntex, and add these to Microsoft 365 E5
  • Custom license bundles with competitive pricing
  • A new SKU for Power BI read-only included in Microsoft 365 E3
  • Eliminate Microsoft 365 E3 entirely, and change Microsoft 365 Business to no user limit
  • Make tenant wide license feature activation less confusing
  • Custom search indexes

So, some quite interesting responses indeed, and overall, a wider range of answers than I anticipated.  What, if anything, can we derive from this straw poll? Let’s examine some of the key takeaways.

Privileged Identity Management and Auto Labeling – an Expensive Luxury

Privileged Identity Management (PIM) enables just-in-time and approval-based access to privileged roles within Microsoft 365.  This means that users who require occasional access to elevated roles do not need to have them permanently assigned to their accounts.  They instead activate the roles on-demand for a limited period of time.

The benefits of this are self-evident – the attack surface is reduced when there are less privileged accounts.  Without PIM available, powerful admin roles will inevitably be granted to users and then forgotten about, which creates a potential vulnerability.

Auto labeling with Microsoft Information Protection provides the means to automatically assign a sensitivity label to Microsoft 365 content based on matches to built-in sensitive information types.  This is an important feature as it reduces the burden on the end-user, who oftentimes do not realize when it’s appropriate and important to apply a label to their emails and documents.

So, what would the impact on Microsoft be if these features were included in Microsoft 365 E3?  It’s difficult to speculate, but these are only two features of Microsoft 365 E5. Their inclusion in the more affordable licensing tier would demonstrate that Microsoft is committed to making important security and compliance features accessible to their wider customer base, and not just those who can afford the cost of a Microsoft 365 E5 subscription.

This is also unlikely to significantly affect subscriptions to Microsoft 365 E5.  Many Microsoft 365 E5 features are justifiably included in the premium subscription, and Cloud App Security and Advanced eDiscovery are two good examples of this.  We have also seen recent innovations with Microsoft 365 E5, such as Insider Risk Management and Communication Compliance.  Therefore, it seems there will still be plenty of exclusive features for Microsoft 365 E5 subscribers.

Questions to Consider

An important question that may provide somewhat of an answer to this debate is, “Where should you start with your Microsoft 365 Security and Compliance posture?”  In this article, Microsoft recently provided updated Security and Compliance guidance aimed specifically at the UK public sector.

They separate their Security and Compliance control capabilities into three categories – Good, Better, and Best.  Microsoft recommends “starting with Better“, which does require some Microsoft 365 E5 functionality.

If “Better” is the minimum recommendation for a Security and Compliance posture for Microsoft 365 public sector customers, then there’s also an argument to be made that even the lowest SKUs (e.g., Office 365 E1) should have at least “Good” security controls.

If you’re surveying Microsoft customers, they will of course answer that they would like the most useful parts of Microsoft 365 E5 as part of Microsoft 365 E3. But If “Better” is the recommended and essential starting point from Microsoft, then why sell products that don’t include these key features?

Playing Devil’s Advocate

Whilst this survey clearly shows there is an appetite for more choice when it comes to Microsoft 365 licensing, there are some other perspectives to consider.

For example, if Microsoft Defender for Office 365 were to be included in Microsoft 365 E3, this could lead to protests from third-party vendors from a competition law standpoint. There are many widely adopted third-party security products used with Microsoft 365 and if a premium feature like Defender became more widely accessible, then many customers may be tempted to discontinue such third-party subscriptions.

We should also consider that some of the premium features of Microsoft 365 E5 may have a clear ongoing cost to Microsoft to run, and these couldn’t simply be thrown into Microsoft 365 E3.  This may be the case for Auto-labelling, for example.

Teams Phone System is a difficult one. Customers must bring their own SIP trunk or purchase calling plans.  On that basis, should they also have to purchase Microsoft 365 E5?  There may be ongoing costs to Microsoft for Teams Phone System that justify this, but we can’t say for sure.

That being said – there is one glaring offender within Microsoft 365 E5 that I find impossible to defend.

Teams DLP Does Not Belong in Microsoft 365 E5!

The presence of Data Loss Prevention for Teams within Microsoft 365 E5 only, is baffling to me.  The arguments above on adding PIM, Auto labeling, or any other Microsoft 365 E5 feature to Microsoft 365 E3 can be debated and counter-argued, as can the need for more customization within license SKU’s.

If I’m going to stick my neck out on one opinion though, it’s that I genuinely don’t feel that DLP for Teams is correctly allocated when it comes to licensing.  How can it be fair for DLP to apply to the other key services within Microsoft 365 within the Microsoft 365 E3 subscription, but not the most relevant product in Microsoft’s recent history – Teams? It’s difficult for me to wrap my head around this decision.


Licensing is often a confusing and divisive subject, and at the end of the day, it’s all about opinions – of which there will be many.  Whilst no one could expect Microsoft to “give away the farm,” there is always a balance that can be struck or a compromise to be made.

What is clear is that there’s a common view from customers and partners that unless some of the premium features are added to Microsoft 365 E3, these customers will need to either consider buying Microsoft 365 E5 licenses; uplift current licenses for some or all users; or continue to rely on third-party alternative solutions.

Source Practical365

read more
Office 365

Microsoft 365 and Office 365: Microsoft’s Confusing Branding


The recent 10th anniversary of the launch of Office 365 brought some questions about the demarcation between Office 365 and Microsoft 365. For instance, do I have an Office 365 tenant or is it a Microsoft 365 tenant? Is a feature part of Microsoft 365 or does it belong to Office 365? And why does Microsoft insist on calling its desktop Office apps Microsoft 365 Apps for enterprise? Welcome to the bizarre world of branding, and that’s before throwing Windows 365 into the mix.

Like any other publication which covers Microsoft productivity and collaboration technology (a wide enough spectrum), we struggle with when to say Office 365 and when it’s time to switch to Microsoft 365. To begin, we can say:

  • Office 365 is the cloud ecosystem for Microsoft Office servers (Exchange Online, SharePoint Online, and Skype for Business Online), including components like Azure AD and Teams, all included in the Office 365 license plans like Office 365 E3 and E5. Microsoft targets these plans at enterprise customers.
  • Microsoft 365 is the wider ecosystem for Microsoft cloud productivity which includes areas like Information Governance, Information Protection, Compliance, and Viva. Although some Microsoft 365 functionality is covered by the Office 365 E5 plan, many features need additional licenses. For instance, Viva Topics is based on SharePoint Online, but to use Topics, you need additional per-user licenses.

For the purpose of accounting, Microsoft divides Office 365 into commercial (the enterprise services) and consumer (subscription versions of Office desktop) and reports separate numbers for revenue and user base for each segment (see the transcript of Microsoft’s Q4 FY21 results).

Muddy Waters

Microsoft muddies the water by selling a range of Microsoft 365 plans tailored for small to medium organizations that include elements of the Office 365 plans. The range of Office 365 plans designed for consumer use (covering the desktop Office applications) were redesignated as Microsoft 365 in April 2020.

The problem didn’t exist when Microsoft launched Microsoft 365 in July 2017. At that time, Microsoft 365 was a bundle to allow enterprise customers to buy:

  • Office 365 Enterprise (E3 and E5).
  • Enterprise Mobility and Security.
  • Windows 10 Enterprise.

The packaging provided popular, and many customers moved from Office 365 plans to Microsoft 365 plans. The success encouraged Microsoft to apply the Microsoft 365 brand more liberally, including changing the Office Pro Plus subscription desktop applications to become Microsoft 365 Apps for enterprise. At times, it seemed like any new product ended up with a Microsoft 365 prefix. Such is the nature of a broad-brush rebranding exercise.

Lines of Demarcation

After that leadup, here’s the current situation boiled down into a bulleted list:

  • Office 365 is a license plan chiefly sold to enterprise customers.
  • Office 365 enterprise services like Exchange Online, SharePoint Online, Teams, Planner, and OneDrive for Business run inside a Microsoft 365 tenant.
  • Tenants using Office 365 enterprise services can license optional Microsoft 365 capabilities like Information Governance and Information Protection.
  • Tenants can also license other Microsoft cloud services not branded as Microsoft 365, such as Viva Topics, SharePoint Syntex, and Microsoft Cloud App Security.
  • Office 365 enterprise services consume many other parts of the Microsoft cloud infrastructure like Azure Key Vault and Azure Active Directory. In fact, Teams consumes many Azure microservices.
  • Apart from being a branding strategy, Microsoft 365 is also a licensing strategy spanning plans targeted at consumer, SMB, and enterprise accounts.

All of which means that when we mention Office 365 in an article, we’re usually talking about the capabilities covered by the Office 365 E3 and E5 plans. When we discuss optional components not covered (or partially covered) in those plans, we are specific as in Microsoft 365 Compliance or Microsoft Information Protection.

This is probably clear as muck, but it’s as close to clarity and precision as you’re going to get in a situation where Microsoft applies the Microsoft 365 moniker so liberally in so many ways while leaving the Office 365 plans intact.

Source Practical365

read more
Office 365

Ten Years On, Office 365 Backup is More Challenging Than Ever Before


I’m not known to be an avid supporter of backup for Office 365 data. ISVs operating in this space do a reasonable job with Exchange Online and SharePoint Online, largely based on years of experience gained with on-premises servers, but struggle with applications like Teams and Planner. These applications have no on-premises counterpart, connect components drawn from across Microsoft 365, and don’t have an API suitable for backup and restore, which is not a great foundation for any backup product. And the surprising thing is that the problem of backup and restore for Office 365 has worsened since its launch ten years ago.

Issues with Restoring Office 365 Data

Leaving backup aside, the restore side of the equation is even more problematic. Among the issues I see are:

  • The amount of data which might need to be restored is typically larger in the cloud than with on-premises servers. An Exchange Online enterprise mailbox with an archive might span 250 GB (or more). OneDrive for Business accounts can grow to 25 TB, and so on. Remember, Microsoft likes tenants to have all their data in Office 365. The more data in Microsoft’s datacenters, the harder it is to move to another cloud service.
  • The challenge of restoring data into applications where no programmatic access is available. How, for instance, can you restore tasks into a Planner plan?
  • The difficulty of restoring integrated applications. Is restoring Teams just a matter of restoring channel conversations, including private channels and soon shared channels? What about the SharePoint sites belonging to teams and private channels, personal and group chats, plans, and apps?
  • The big question is finding a suitable restore target. If Office 365 is unavailable, what is a valid target to put the restored data? On-premises servers might be able to handle some mailbox and document data, but how quickly can these servers be brought online to deliver service to users, including linking an on-premises directory to these objects? Restoring to on-premises servers isn’t possible for cloud-only apps like Yammer, Teams, and Planner. And it’s hard to see how you could move the data to a different cloud service.

The Need for an Online Restore Target

Practically speaking, tenants need Office 365 and Azure AD to be online to restore data. And if a tenant is online, the instances when data needs to be restored include scenarios like:

  • Cyberattack (ransomware) encrypts user data.
  • Malicious or accidental deletion of user data which cannot be recovered using the methods built into Office 365.

Looking at how attacks have developed, it seems clear that documents and email are the most likely data ransomware seeks to encrypt. With that in mind, given that backup for documents and email is well covered, perhaps the attention of anyone concerned about ransomware should focus on these workloads. Not only are there many backup products available which can process this information, documents and email are the easiest to restore if a problem erupts.

The ransomware scenario is a real concern, but tenants can make sure that they’re not an easy target for attack by eliminating basic authentication wherever feasible, using multi-factor authentication for as many accounts as possible, and educating users how to recognize phishing and malware which gets through mail hygiene services. I don’t know of any Office 365 tenants that have been victims of a ransomware attack, but the fact that Microsoft publishes advice to help tenants recover from an attack indicates that this has happened.

Stopping Rogues

Malicious removal of user data is often referred to as the “rogue administrator” problem, when someone who has permissions deletes data because they are disaffected for some reason (like they’ve just been fired). I don’t doubt that some become very annoyed and want to hurt a company, but I don’t know of many instances where this happened. Perhaps the extensive auditing of actions within Office 365 (which proves who did what and when) is enough to dissuade potential rogues from carrying out their plans. Or maybe it’s because tenants can use tools like Privileged Access Management and Privileged Identity Management to limit administrator access to data.

Accidental Deletion

Out-of-the-box tools available in some Office 365 applications can help with the data removed accidently problem. For instance:

  • The recover deleted items (email) feature available in Outlook clients. Exchange Online administrators can also recover deleted items for users through the new EAC or with PowerShell.
  • The restore library feature available for SharePoint Online and OneDrive for Business allows the retrieval of deleted files for up to 30 days.
  • Administrators can recover deleted items in mailboxes and sites if retention policies cover the locations or the items had retention labels. A content search can find and export copies of deleted items. Although you can use retention policies and labels to stop the permanent removal of data, these are tools for information governance and not backup. However, because policies retain data for set periods, a good chance exists that it will be possible to retrieve items deleted in error, assuming that the data are in locations covered by retention processing and the retention period does not expire.

User-centric features don’t handle large-scale recovery well. If you need to retrieve 100,000 documents or 100 mailboxes, restoring data from a backup is usually faster. That is, if you have a backup. If you don’t, you can still use the out-of-the-box tools in the knowledge that retrieval will be slower.

Gaps in Restore

Which brings us back to the issue that backup tools can handle Exchange Online and SharePoint Online but struggle with other Office 365 workloads. If someone deletes a bunch of tasks in a plan, you won’t get them back because Planner doesn’t have a recycle bin or other intermediate deletion point. If someone deletes a bunch of messages in a group chat, you might be able to retrieve the compliance records for those messages but won’t be able to insert them back into the chat. And anyway, some of the content in the messages will be missing (like reactions). If someone deletes all the registered app details from Azure AD, any app which had consent to use the Graph APIs to access Office 365 data is nullified.

The point is that restoring all the connections which constitute an Office 365 tenant and its active workloads is a devilishly complex undertaking. So much so that I doubt that the complete restoration of a tenant, its configuration, and all its data can be done automatically. It might be possible to demonstrate such a feat with a test tenant with a small amount of data. But once the imperfections of operational life take hold (evident in symptoms like group sprawl), the difficulties facing any restore operation mounts. This doesn’t mean that an imperfect restore has no value. If your tenant is dead in the water, any restore is better than none.

Ten Years On

Office 365 is approaching its tenth anniversary. It’s odd that a situation exists where comprehensive tenant-wide backup and recovery spanning all workloads is impossible. This is especially true given that it was possible to contemplate such an operation for the original applications included in Office 365 in June 2011. The introduction of cloud-only applications and the massive growth in data since has created the challenges we now face. Microsoft has remained oddly passive in this area and left the running to ISVs, who are handicapped by the lack of suitable APIs. Let’s hope the situation improves over the next decade.

Source Practical 365

read more
Office 365Sharepoint

Office 365 10-Year Anniversary Series: SharePoint Online Reflections


The Beginning of My Journey into the Cloud

In June 2011, I was a consultant with EMC Consulting focused on migrating customers’ legacy Notes applications to SharePoint and moving SharePoint 2003, 2007, and 2010 customers to SharePoint 2013. That same month, Office 365 reached general availability, and I wondered how long it would be until there was an offering for SharePoint to be included in Microsoft’s cloud offering.

In July of 2012, a public beta of SharePoint Online was made available, and in February 2013, Office 365 SharePoint Online was released, adding a whole new dynamic for SharePoint migration planning.

I looked at this release as being the first of many releases. This was an online version of what was available in the on-premises product – with some limitations. While the feature set in the online version lagged the on-premises version, I knew this would change over time.

Changing the Conversation

Most of my conversations with customers with regards to Office 365 centered around SharePoint migrations and custom applications. Third-party application providers were quickly moving to provide SharePoint Online migration tools. As a result, all the conversations that I had with customers and other consultants changed.

I started to pitch SharePoint Online as a new and better target for migrations. It was an easy pitch, too:

  • Migrate once to the cloud and stay there
  • No hardware purchases
  • Sell or repurpose your existing hardware
  • Lower administration costs
  • No planning for upgrades or installing fixes
  • Keep on-premises any applications that are complex and cannot run in SharePoint Online

With regards to custom applications, this was a big concern for customers and consultants looking to maximize their SharePoint investment. These concerns extended even more to SharePoint Online. But I saw an opportunity to standardize and simplify most of the applications, and there were some good third-party form and workflow applications available to support my view.

Pitching to Cloud-Weary Skeptics

Of course, in those early days, there were still a lot of customers not ready to buy into the cloud. I explained that they may be able to justify staying on-premises this year. But the argument for going to the cloud would get stronger every year until they would eventually not be able to refute it. Eventually, I believed, changes would happen faster in the cloud than on-premises.

There were usually three types of customers who were ready to make the move:

  1. Moving content from a legacy platform (e.g., Lotus Notes) and starting over on SharePoint Online
  2. Ready to move from SharePoint 2007 or 2010 to the cloud – at least with some of their collaboration applications
  3. Introducing SharePoint Online as the new collaboration solution

The first and second sets of customers had a better chance at adopting SharePoint Online as their users were forced to use it. Both sets struggled with migrating custom applications. The third set of customers managed adoption issues with their users.

Fast Forward to the Present!

In an amazing and fortunate turn of events, I now manage the same migration products I used to recommend as a consultant in my role at Quest! We’ve seen tremendous growth in the number of Microsoft 365 users over the past ten years. We’ve all seen the SharePoint Online platform add many new and amazing features over the past ten years. One of the most popular Office applications ever (Microsoft Teams) uses SharePoint Online for storing most of its content.

10 years later and instead of an on-premises migration, you now have a tenant-to-tenant Office 365 migration. Check out this e-book to learn the Top Five Ways to Prepare for Your Next Office 365 Tenant Migration.

Source Practical 365

read more
Office 365

Office 365 10-Year Anniversary Series: The Arrival of Cloud Voice


My first exposure to cloud-hosted Exchange came when I was invited to join Microsoft’s “Exchange Labs” dogfood program that Microsoft. (Editor’s note: “dogfood” refers to the Microsoft Exchange development group’s servers running the latest internal build of the software; “eating your own dogfood” means that you run your software to find bugs. Sometimes the theory worked, sometimes it didn’t.)

At the time, there were a few efforts inside Microsoft to develop what was then known as “hosted Exchange,” mostly for telcos and other large service providers. But Exchange was far in the vanguard of this effort—everyone else, including Office Communications Server and SharePoint, were firmly grounded in the on-premises world.

Better Together

A big part of my job at the time was working with, and teaching about, the integration between Exchange and OCS (later Lync) for voice. Let’s call this the “better together” phase of my work with the BackOffice suite. It revolved around features such as Exchange Unified Messaging, which I used to call “the champagne of server roles.”

Microsoft had come up with the UM feature set as a way to sell Exchange by offering lower TCO and better features than traditional on-premises (or PBX) voicemail systems, and it was pretty successful—so they then wanted to use Exchange UM as a way to sell OCS and Lync to replace the phone systems themselves.

This was a big stretch at the time, because enterprise phone systems typically had legendary reliability and uptime, and on-premises Microsoft products couldn’t necessarily match that in lots of environments. A big part of my work was helping customers plan and design more reliable Exchange implementations that were good enough to match their SLAs for voice services.

Voice and BPOS

As Microsoft made the journey from Exchange Labs to BPOS to Office 365, the playing field for voice and IM integration started shifting. Customers who moved their mailboxes to the cloud but wanted to keep unified messaging or Lync/Skype for Business integration had to keep Exchange UM servers on-premises, for one thing, which made it hard to move completely to the cloud, but when Microsoft created Cloud Voicemail to work with Exchange Online, the writing was on the wall.

As the overall Office 365 service got more reliable, my work shifted away from “better together” and more towards “get me to the cloud.” Microsoft’s own success at getting Lync, and then Skype for Business, to replace enterprise phone systems held them back though, because a customer who deployed SfB in, say, 2016 wasn’t eager to rip it out and move to Skype for Business Online in 2017…. And then came Teams!

The Advent of Teams

Teams changed my focus to something like the process required to open a box of flat-pack furniture: first, you cut the obvious tape and straps and so forth, then you start removing each piece and its individual packing material, lay it all out, and try to figure out the right layout to get the parts close to where you want them so you can start assembling.

Like many other people swept up in the transition to the cloud, my focus has steadily moved to larger and more abstract requirements. I used to tell people how many disks they needed in each server to get the right Database Availability Group performance; then I moved on to advising people how to move to the cloud; and now I help them understand the larger issues around capability, cost, and compliance that come from moving to the cloud.

Source Practical 365

read more
1 2 3 4 5 10
Page 3 of 10