Can we prevent Cloud Repatriation in Azure?

I’ve seen a lot of articles in the last few months talking about Cloud Repatriation, so I’ve decided to look into this more and find out more about:

  • What is Cloud Repatriation?
  • Why is it suddenly a topic?
  • Why its not as easy as it sounds?
  • How did this happen in the first place?
  • Why it should never become an issue?

What is Cloud Repatriation?

Lets start with the easy question and look for the definition of what it is. Repatriation is a term that has been around for a while and is defined in its simplest form as:

“the process of returning a thing or a person to its place of origin”

So if we take that definition and apply it to technology, Cloud Repatriation is the process of companies moving their services out of Microsoft Azure (or other Public Cloud providers such as AWS or GCP) and relocating those services back to the On-Premises or Private Cloud environments that they originated from.

Why is it suddenly a topic?

One word – cost. The cost of running a Cloud Computing environment isn’t the same as running an On-Premises environment.

In an On-Premises environment, we work with predictable cost models when it comes to Equipment, Licensing and Staffing costs. The only variable is Power which is in a constant state of flux and change. This leads us down the CapEx route which forces companies into predicting the costs involved over a 3-5 year period. Finance people love this as it means they can safely predict future costs and budgets, and not have to worry about unexpected charges affecting their balance sheets.

The first part of that previous paragraph is ambiguous. Unless your company is static with zero growth projections (and lets be honest, no company is), its going to be difficult to predict costs or a period of years:

  • How many servers will you need to run your estate? If you order too little, you’ll need to buy more and your CFO won’t like that after you told them that these were the only costs needed for the next 3 years.
  • If you order too much, its overspend and equipment/license wastage and you may not be approved for additional equipment in your next Budget cycle (which leads you to use unsupported and out of warranty equipment that may lead to more costs to keep that operational).
  • You may have also hired either too few staff (leading to overwork and burnout) or too many staff (which leads to idleness and ultimately reducing the workforce).

Cloud Computing environments use the OpEx which works differently in that it uses a Pay-As-You-Use model. You use a Cloud Service and are billed monthly for the cost of using it. You have options to scale the service up or down as required, and you can also purchase Reserved Instances or Savings Plans over a 3/5 year period in order to reduce the costs and have that “CapEx-feel” to Cloud Computing.

The problem is that there is no clearly defined way of keeping those costs consistent, and Microsoft’s recent announcement on price increases for European Customers (and depending on your currency, this was as much as 15%) has meant that CFOs and CTOs are scrambling to look at alternative solutions to the Cloud.

And in some cases, the word “Repatriation” has been thrown about and the question being asked is “were we wrong to move to Azure/AWS/GCP, and should we look to move our servers and data back?”

Why its not as easy as it sounds?

So you want to move back? It sounds easy, and if your Cloud Migration involved only a “Lift And Shift” or Rehost (where you migrated your VMs as-is and made no modifications to them), then fire away! Buy your equipment, install your favourite hypervisor and off you go! There are 3rd party products (such as Carbon) on the market that will bring your VMs back to either VMware or Hyper-V.

You can also migrate Office365 mailboxes back to On-Premises Exchange Servers by setting up a migration batch in EAC, so that process is simple.

But what if you did more than just Rehost? Lets remind ourselves of the 5 R’s of Cloud Rationalization:

  • Rehost – also known and Lift and Shift.
  • Refactor – customizing your apps and infrastructure to align with the Cloud.
  • Rearchitect – divides your app into different parts or MicroServices.
  • Rebuild – completely rebuild and redevelop your app.
  • Replace – completely replace the app with a cloud-native SaaS application.

If you’ve done anything more than Rehost during your migration to Azure, then you have a bit of work on your hands getting it back. It’s not impossible by any means but as with all Cloud Services, it’s a lot easier to get them into the Cloud than it is to get them out. If you’ve redesigned your app to make it Cloud-Native using any of the other 4 “R’s”, then you need to realise that you need to recreate that environment on your On-Premises, and that may not be easy and cost a lot more than it is running the service in Azure in the first place!

How did this happen in the first place?

To work out why this should never have become an issue, we need to go back through the mists of time and work out why the migrations happened in the first place. It was most likely down to either:

  • Running old and unsupported hardware.
  • Complex systems that were difficult to manage and maintain.
  • Enhanced Security.
  • Easier Scalability of services.

And if you moved to Azure, its likely that you used either :

  • Azure Site Recovery (and were using Azure as a DR platform to initially test how your VMs would work).
  • Azure Migrate (where you ran a discovery assessment on the load of your VMs over a period of time up to 30 days, and used that assessment as a means of sizing your target Azure VMs).

The original version of Azure Migrate only supported migration of VMware VM workloads to Azure. The new version (released in November 2019) included Database and Web Server migration features, and Application Discovery.

In all likelihood, some companies went down the same route as the initial Office365 migrations (where they only migrated Email and never used any of the other underlying services included in their licenses), and in doing their Cloud Migrations to Azure decided to effectively “Rehost-only” and not use the additional benefits that were available. So instead of running Web Servers or Applications as part of an Azure App Service, they may have been left running on VMs with underlying Web or App Services.

Another good example here is the Finance or Warehouse Management Application that ran on a VM and also required a dedicated SQL backend (that also ran on a VM). Instead of refactoring that into an App Service or a Serverless SQL Database, it was left running on VMs in Azure. We all know that these VMs have spikes at certain times every month, so in that case the scalability that could have offered cost savings wasn’t implemented.

Why it should never have become an issue?

There are a number of contributing factors why Cloud Computing costs can spiral out of control. I’ve made the case for these below, and in some cases what can be done to address them:

  • Azure Reserved Instances – this is what Finance people love as they immediate savings and some semblance of how they can “CapEx their OpEx” costs over a longer period of time.
  • Azure Cost Management – Setting a budget or at least budget alerts on monthly spend can at least give you an indication of where you are each month. If you’re getting budget alerts emails on the 10th of each month, then you haven’t got either your budget or your Service SKU’s and Sizing right.
  • Azure Policy – have you set policies to say that you can only have certain VM SKUs, running on certain disk types, in certain regions?
  • RBAC Roles – this is the most important one and the biggest factor in “spend-creep”. Who can do what in your Azure Subscription? For example, have you granted developers Owner access in their own Resource Group so they can spin up what they want? Changing a SKU on a VM is single click operation, as is changing Disk type from HDD to SSD, redundancy from LRS to GRS etc. And do the policies you have set above apply across the subscription or have you exclusions set somewhere? Having control of your environemnt and assigning the correct roles.
  • Assessments – OK, this is a “after the horse has bolted” scenario, but its never too late to do it. Asking questions like why did you move in the first place, does it align with business goals, strategy and governance objectives.
  • Azure Advisor – its there, on every resource you are running in Azure and also as its own page in the portal, giving you recommendations based on over/under consumption and how you can address this.
  • Backup/DR- this has long been a bone of contention for some companies and I’ve experienced some who see Cloud-based backup solutions as either unnecessary or too expensive (because being in the cloud means we don’t need Backup or DR, right?).


I’ve based this article purely on costs and how you can utilize the various Tools, Policies and Governance tools available in Azure that can help make final decisions on whether Cloud Repatriation is the right choice for your business.

Hope you enjoyed this post, until next time!

Is it the (long overdue) end of the road for on-premises Exchange Servers?

A few weeks ago, I posted a article on my LinkedIn feed entitled “Your Microsoft Exchange Server Is a Security Liability” by Andy Greenburg.

Image Credit – Priasoft

It was a great article that was released on the back of the most recent Exchange security vulnerability: this time the ProxyNotShell Zero-Day which oddly enough took almost 2 months to patch correctly. This has been released as part of the November Patch Tuesday release, and there are a few pre-requisites required (basically, be at the latest CU version for your Exchange environments and then apply the patch).

Image Credit – Microsoft

Its the latest in a long line of Exchange Server vulnerabilities. And its interesting to note this line in the Microsoft Tech Community Article that states:

These vulnerabilities affect Exchange Server. Exchange Online customers are already protected from the vulnerabilities addressed in these SUs and do not need to take any action other than updating any Exchange servers in their environment.

Well, of course Exchange Online isn’t affected. And in his Wired article, Andy Greenburg makes the point that Microsoft are happy to put all of their security efforts into protecting their Exchange Online services and customers as that makes up the majority of their customer base.

A brief history of Exchange Online

If we look back on the history of Exchange Online, it all started with BPOS way back in 2008. At the time of release, Microsoft had been privately offering customers a hosted email service since early 2007. That was around the time that Exchange Server 2007 was released, and it was also the time when Exchange started to get really complicated as regards the amount of different server roles involved and the overhead involved in maintaining them.

Now lets just put one thing on record. I would never dream of believing that Microsoft would conspire to over-complicate an on-premises solution with the intention of pushing more customers towards a cloud offering. I mean, they wouldn’t, would they?

There was always an option for having a Front-End sever separate, and the solution could sometimes be integrated with the long gone but not forgotten ISA Server.

A look at the diagram below shows us the evolution of how Exchange roles have changed since 2000/2003 versions, and have pretty much rolled back into less complicated instances with the release of 2016/2019 versions:

Image Credit –

Whether Microsoft intended to make Exchange Server more complicated or not, segregation of those roles was was needed due to the evolution of security threats and the rate of attacks that were happening on Exchange Server installations. What it did though was make Exchange a monster to manage from an adminstration perspective. Almost to the point that it made the decision to migrate to Exchange Online easier, as it offset the cost for some organisations of hiring a full time Exchange Administrator to manage that environment.

So I should Migrate?

The easy answer to that is yes, you should migrate. There’s a number of factors to take into consideration in answering that question:

  • As we saw in the recent ProxyNotShell Zero-Day and the length of time it took to remediate, Microsoft really doesn’t care about on-premises Exchange anymore. From Andy’s Wired article, the quote from Microsoft states that: "We strongly recommend customers migrate to the cloud to take advantage of real-time security and instant updates to help keep their systems protected from the latest threats".
  • The recent announcement that the next CU release will only be for Exchange Server 2019 (CU13). Because 2013 (which goes EOL in April 2023) and 2016 are now in Extened support, there will only be Security Updates released as required (such as the patch for the Zero-Day). But in order to install that and to get support from Microsoft, you must be in the most recent (and last) CU version.
  • There hasn’t been an Exchange Server 2022 release yet. This was touted as being released in late 2021, and early indication were that this would be a subscription based service. The latest update on this was released in this post in June 2022, where the updated roadmap is to release the next Exchange Server version in 2025. Are we really prepared to wait that long if the vulnerabilities continue at this rate? Again, the interesting quote to take ouit of this release is: The next version will require Server and CAL licenses and will be accessible only to customers with Software Assurance, similar to the SharePoint Server and Project Server Subscription Editions.
  • If you decide to migrate to Exchange Online, what does your business want to get out of the migration? Its the question thats rarely asked but its the most important one for any migration scenario. Because unlike 15 years ago when it was hosted Email and SharePoint with Live Meetings thrown in, Microsoft 365 is an extensive offering of Apps, Services and Licencing options and can open a gateway to a full cloud migration if planned correctly.
  • You can go for the Basic plans such as Business Basic or Office 365 E1 and “just” have Email, Sharepoint and Teams if you want. But go a little further, you take Office licensing into the equation, and maybe Defender, and then maybe Azure Virtual Desktop rights. The opportunities are there, it’s not just about lifting and shifting the tech anymore. You can check out my previous post on the different licensing options here.

Why can’t everyone just migrate to Exchange Online?

The majority of companies have already migrated to Exchange – nearly 350 million Office365 users running over 7 billion (yes, billion) mailboxes running on 300,000 Exchange Online instances on servers running in Microsoft Datacenters across the world.

There are those special cases who still need Exchange Servers On-Premises, and those servers need to be hardened or have specialist teams supporting them.

Then there are those companies that have specific Data Residency requirements. And thats really all they say ….. "We're not moving our data into the Cloud". It shows a lack of understanding of how Data Residency in Exchange Online works. Depending on where you are in the world, you can find out on this site the different options for where your Microsoft 365 data would be stored post migration, depending on the options you select at tenant creation and also in what datacenters the services are available around the world (for example, Forms is not available in all datacenters, only some US ones).


Having your data secured by Microsoft is better than having your data potentially exposed because of a mistrust or misunderstanding of what the cloud can offer as regards data residency. You also have the admin overhead of managing and securing your Exchange environment.

I think its the end of the road for Exchange Server – while a migration amy sound painful to some, a compromised server is much worse.

Hope you enjoyed this post, until next time!

Microsoft Ignite 2022 – Highlights of the Announcements (with a few personal opinions thrown in)!

For this year’s Microsoft Ignite, in-person conferences were held in cities around the world after two years of being online and I was fortunate enough to attend the Manchester Spotlight event last week.

At the conference Microsoft had their usual presentations, ‘Ask the Expert’ sessions, exhibition areas and a Cloud Skills Challenge. But of course it’s the announcements that everyone looks forward to the most, where improvements, changes and updates to the various technologies in the Microsoft product portfolio are revealed.

I’ve picked out my top highlights below!

  • Azure Stack HCI

I’m on both sides of the fence about the Azure Stack HCI announcements.

I love the Azure Stack HCI product and have been using it since the days when it was called Storage Spaces Direct and ran on Hyper-Converged Infrastructure in on-premises datacenters. As it has evolved, Microsoft has invested heavily in the Azure Stack HCI product, which allows you to run Azure Managed Infrastructure in your own datacentres and combine on-premises infrastructure with Azure Cloud Services.

One of the big announcements was around licensing, and gives Enterprise Agreement customers with Software Assurance the ability to exchange their existing licensed cores of Windows Server Datacentre to get Azure Stack HCI at no additional cost. This includes the right to run unlimited Azure Kubernetes Service and unlimited Windows Server guest workloads on the Azure Stack HCI cluster.

Speaking of Kubernetes, support for Azure Kubernetes Service on Azure Stack HCI is now available, meaning you can deploy and manage containerised apps side-by-side with your VMs on the same physical server or cluster. You can also now make provisioning for hybrid AKS clusters directly from Azure onto your Azure Stack HCI using Azure Arc

On the hardware side, you could previously purchase validated hardware for multiple vendors but in early 2023, Microsoft will begin offering an Azure Stack HCI integrated system based on hardware that’s designed, shipped, and supported by Microsoft (in partnership with Dell). 

This will be available in several configurations:

I mentioned both sides of the fence above, and the licensing announcement is one of the worrying ones, because like the recent announcements that Defender for Servers requires an Azure Subscription (Microsoft Defender for Endpoint (Server Version) is no longer available on the EA price list), we’re now potentially going down the route of Microsoft only allowing Windows Server Datacenter to run on Azure Stack HCI accredited hardware. Or potentially getting rid of the Windows Server Datacenter SKU entirely and having it as a “cloud-connected only” product. Only time will tell.

  • Azure Savings Plan for Compute

Azure Savings Plan for Compute is based on consumption, and allows you to by a one- or three-year savings plan and commit to a spend of $5 per hour per virtual machine (VM). This is based on Azure Advisor Recommendations in the Cost Management and Billing section of the Azure Portal.

Once purchased, this is applied on a hourly basis based on consumption and even if you go above the $5 spend, the initial commitment is still billed at the lower rate and any additional consumption is billed at a Pay-As-You-Go rate.

The main difference between this and Reserved Instances is that Reserved Instances is an up-front commitment whether the VM is powered on or not. Azure Savings Plan for Compute unlocks those lower savings based on consumption.

You can find more details in this article on the Microsoft Community Hub.

  • Azure Virtual Machine Scale Sets – Mixing Standard and Spot instances

Staying on the Cost Savings topic, you can now specify a % of Spot Instance VMs that you wish to run in a VM Scale Set.

This feature (which is in Preview) allows you to reduce compute infrastructure costs by leveraging the deep discounts that Spot VMs can provide while maintaining the compute capacity your workload needs. 

More information can be found here.

  • Microsoft 365 updates

A huge number of announcements were made about Microsoft 365 at this year’s Ignite, most notably:

  • The release of the Microsoft 365 app, which will replace the Office Mobile and Office for Windows App for all Microsoft 365 customers who use this as part of their subscriptions.
  • Teams Premium, which will be available to E5 subscriptions and will bring enhanced meeting features such as insights and live translation in more than 40 languages so that participants can read captions in their own language.
  • Microsoft Places, which will assist with the hybrid working model and let everyone know who will be in the office at what times, where colleagues are sitting, what meetings to attend in person; and how to book space on the days your team is planning to go into the office.

The Teams announcements are great, in particular the live translation option. For us as a multi-national and multi-language organisation, this is a massive step in fostering the inclusion of all users. There is an assumption in the world that spoken English is the native language of Tech, but it’s not everyone’s first language.

  • Microsoft Intune

Microsoft Endpoint Manager is being renamed to Microsoft Intune, which is what it was called before it was renamed to Endpoint Manager. This effectively bundles all Endpoint Management tools under a single brand, including Microsoft Configuration Manager. Some of the main features announced were:

  • ServiceNow Integration
  • Cloud LAPS for Azure Virtual Machines
  • Update Policies or MacOS and Linux Support
  • Endpoint Privileged Management – no more permanent admin permissions on devices!

For me, Endpoint Privileged Management is huge addition which removes the need for any permanent administrative permissions on devices. Cloud LAPS is also a huge security step.

  • Security

Finally on to Security, which was a big focus this year. This year’s updates to the Microsoft Security portfolio coincided with the announcement that Microsoft is now recognised as a leader in the Gartner Magic Quadrant for Security Information and Event Management.

First and foremost is Microsoft’s announcement of a limited-time sale of 50% off Defender for Endpoint Plan 1 and Plan 2 licenses, allowing organisations to do more and spend less by modernising their security with a leading endpoint protection platform. The offer runs until June 2023.

Microsoft 365 Defender now automatically disrupts ransomware attacks. This is possible because Microsoft 365 Defender collects and correlates signals across endpoints, identities, emails, documents and cloud apps into unified incidents and uses the breadth of signal to identify attacks early with a high level of confidence. Microsoft 365 Defender can automatically contain affected assets, such as endpoints or user identities. This helps stop ransomware from spreading laterally.

A number of new capabilities have been announced for Defender for Cloud:

  • Microsoft Defender for DevOps: A new solution that will provide visibility across multiple DevOps environments to centrally manage DevOps security, strengthen cloud resource configurations in code and help prioritise remediation of critical issues in code across multi-pipeline and multicloud environments. With this preview, leading platforms like GitHub and Azure DevOps are supported and other major DevOps platforms will be supported shortly.
  • Microsoft Defender Cloud Security Posture Management (CSPM): This solution, available in preview, will build on existing capabilities to deliver integrated insights across cloud resources, including DevOps, runtime infrastructure and external attack surfaces, and will provide contextual risk-based information to security teams. Defender CSPM provides proactive attack path analysis, built on the new cloud security graph, to help identify the most exploitable resources across connected workloads to help reduce recommendation noise by 99%.
  • Microsoft cloud security benchmark: A comprehensive multicloud security framework is now generally available with Microsoft Defender for Cloud as part of the free Cloud Security Posture Management experience. This built-in benchmark maps best practices across clouds and industry frameworks, enabling security teams to drive multicloud security compliance.
  • Expanded workload protection capabilities: Microsoft Defender for Servers will support agentless scanning, in addition to an agent-based approach to VMs in Azure and AWS. Defender for Servers P2 will provide Microsoft Defender Vulnerability Management premium capabilities.

If you’d like to read more about Microsoft’s Ignite announcements from the conference, then go to Microsoft’s Book of News here.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 84: MS-220 Exam Review and Study Guide

Its Day 84 of my 100 Days of Cloud Journey, and last week I sat Exam MS-220: Troubleshooting Microsoft Exchange Online (beta).

The reason I chose to take this exam was that I have a number of years of experience in Exchange Online, both migrating from on-premises Exchange environments, working in hybrid environments and managing full Exchange Online deployments from licensing in Microsoft/Office365 (and BPOS back in the old days!!) right up to mailbox management and compliance.

In this post, I’ll attempt to give an NDA-friendly exam review, and also provide a study guide and useful links to enhance your chances of success in this exam.

Exam Overview

According to the official release article on the Microsoft Learn Blog, the MS-220 exam is aimed at:

Support engineers are professionals who have the energy and expertise to resolve difficult technical issues. They also drive the resolution of highly complex support incidents related to solution-specific development and deployment. In addition to collaborating with other technical specialists on case reviews, troubleshooting, and effective customer interaction, support engineers also:

  • Own, troubleshoot, and solve technical issues, using collaboration, best practices, and transparency within and across teams.
  • Identify technical or strategic cases that require escalation.
  • Create and maintain incident management requests for the product group or engineering group.
  • Contribute to case deflection initiatives, automation, and other digital self-help assets to improve customer and engineer experience.

So lets say this straightaway and simplify the statement above – this is a technical exam. It is difficult, and having worked with these technologies for a number of years I can tell you that I found it challenging! Also, because I took it in beta, I don’t know if I’ve passed it yet and like all exams you are never really certain until the screen at the end gives you the result or confirmation email comes in with the beta results.

An NDA-friendly review

I had already tweeted an NDA-friendly thread here, but lets just cover off the highlights and my thoughts on the exam:

  • Firstly, the exam is challenging and is true to the exam objectives and learning paths covered by Microsoft Learn. This is not an exam for beginners – I have over 10 years of experience in managing Exchange On-Prem, Online and Hybrid environments and I found this challenging.
  • Despite the recent “shift to cloud” that happened last year with the cancellation of Server (MCSE) and Exchange certs, Microsoft clearly feels that there is enough merit to introduce certs that cover hybrid scenarios and follows on from the addition of the AZ800/801 certs.
  • The skills measured is fully covered and nicely weighted across the exam.
  • The PowerShell on the exam was complicated and it tests your ability to understand the correct command structure to use, while also testing your real-world experience of using PowerShell commands to diagnose the issues presented in the question set.

Study Guide

So lets put together a Study Guide. The first port of call when studying for this exam should be the Microsoft Learn Modules for Troubleshoot Microsoft Exchange Online.

Now, lets look at the skills measured list to see how the exam objectives are weighted:

  • Troubleshoot mail flow issues (20–25%)
  • Troubleshoot compliance and retention issues (25–30%)
  • Troubleshoot mail client issues (20–25%)
  • Troubleshoot Exchange Online configuration issues (15–20%)
  • Troubleshoot hybrid and migration issues (10–15%)

Lets break down the content in each of these sections and provide links for each of the skills being assessed under each heading:

  • Troubleshoot mail flow issues (20–25%)
  • Troubleshoot compliance and retention issues (25–30%)

  • Troubleshoot mail client issues (20–25%)

  • Troubleshoot Exchange Online configuration issues (15–20%)
  • Troubleshoot hybrid and migration issues (10–15%)


MS-220 is not a beginners exam, you need to have a lot of experience in Exchange Hybrid, On-Premises and Online and in all areas covered in the Skills Measured.

Hope you enjoyed this post and found it useful, until next time!

100 Days of Cloud – Day 80 – Microsoft 365 Admin Center

Its Day 80 of my 100 Days of Cloud journey, and todays post is taking a quick look at how to administer your Microsoft 365 tenancy.

Over the previous posts, we’ve looked at how to migrate our users from our on-premises environment into Microsoft 365, and along the way we’ve chosen identity models and a suitable licensing model for our organisation.

So thats it, the hard work is done! Time for a coffee, put the feet up and read the news. Maybe do the crossword, or even todays Wordle…..

Not so fast. You now have your users in Microsoft 365, you need to manage and administer your environment. Don’t forget that Microsoft 365 is a SaaS service, so you still need to manage it using Microsoft 365 Admin Center.

Admin Center overview

The admin center can be used to manage user accounts and mailboxes, configure the Office 365 cloud environment, monitor statistics, and so on.

When you log on to the Admin Center, there are 2 main panels down the left hand side:

  • Tenant and User Management panel – this is where you will manage the following:
    • Users – the most common task for administrators is managing user accounts. You can perform tasks such as manage users (add, edit, delete, export users), reset passwords, assign or remove user licenses.
    • Groups – manage Office 365 groups, security groups, distribution lists and shared mailboxes in your organization. You will also see groups that have been synchronized from our on-premises environment.
    • Roles – when you sign up for a Microsoft 365 trial, the user who you sign up up with becomes a Global Admin and has full access over all aspects of the tenant. Roles allows you to assign different admin roles for other users (administrators). This is useful if you want to delegate some authority to other administrators who should be focused on Exchange management, license management or SharePoint management, without giving those users the full Global Admin role.
    • Resources – allows you to create and manage resources, such as SharePoint sites and conference rooms for conference purposes.
    • Billing – view your subscription status, purchase additional Microsoft cloud services, check billing and payments, and configure payment methods.
    • Support – allows you to create support requests to Microsoft if needed and view recent service requests and their status.
    • Settings – allows you to manage global settings including authentication settings, email settings, calendar, external sharing, password policy, Azure Active Directory integration.
    • Setup – details for your subscription, assign or manage software licenses, manage domains and data migration.
    • Reports – gives detailed reports showing how users inside your company use Microsoft 365 applications. You can monitor which applications are favorite among users and compare dynamics for the selected period (7, 30, 90 or 180 days).
    • Health – used to check the health of your Office 365 services.
  • Admin Centers panel – this is where you will access the individual Admin centers for each of the Microsoft 365 services in your tenancy, including:
    • Security – Get visibility into your security state, investigate and protect against threats, get recommendations on how to increase your security, and more.
    • Compliance – Manage your compliance needs using integrated solutions for data governance, encryption, access control, eDiscovery, and more.
    • Azure Active Directory – Allows you to configure Azure AD for Office 365 and synchronization with Windows Server Active Directory; to manage users, groups and policies; and to set access parameters for third-party applications that interact with Office 365 via Microsoft APIs.
    • Exchange – manage Office 365 user accounts and mailboxes. Configure group mailboxes, anti-spam protection, mail flow rules, and so on.
    • SharePoint – configure the Microsoft cloud environment so that users in the organization can collaborate.
    • Teams – allows you to schedule meetings for teams by using Skype for business, manage teams, set policies, view reports, and so on.
    • All admin centers – Opens a page with a full list of Office 365 admin centers, including admin centers for OneDrive, Yammer Enterprise, Dynamics 365, Power Apps, Skype for business, and other services.

So what happens next?

The answer to that is really up to your organisation and how you want to benefit from the range of services available in Microsoft 365. As I’ve stated previously, the main reason why companies migrate their workloads is to remove the overhead of managing and maintaining an on-premises Exchange environment, and the underlying Operating Systems, Storage, Networking, Security and Patch Management that goes along with it.

Of course, how you develop and use these services this depends on what licensing level you have chosen (and if you missed that, take a look back at Day 78), but effectively the main options that organisations will end up using are:

  • Teams – this allows instant messaging, user-to-user voice calling, team collaboration and file repostories (backed by SharePoint), and an optional full VOIP service where you can migrate your PABX to Teams Voice.
  • SharePoint – we looked at this on Day 72 where we compared migrating file data to SharePoint or Azure Files.
  • Azure Active Directory – this allows conditional acces and multi-factor authentication to be built into your tenant identify, as we looked at on Day 56.


And thats a quick look at the different options available in the Microsoft 365 admin center.

There is lots of great information out there on Microsoft 365 that goes into far more detail that I have, and a great startng point is Microsoft Docs here.

If you want to follow someone in the community to get a full overview of Microsoft/Office365 and all of the services and updates, there is no one better than Tony Redmond, who you can follow on Twitter here or you can read his updates on here. He’s also the principal author of Office 365 for IT Pros books and blog.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 78: Microsoft 365 Licensing Options

Its Day 78 of my 100 Days of Cloud journey, and as promised todays post is all about the wide range of different licensing options available in Microsoft 365.

The migration planning is going well, and at this point we’ve decided the following:

  • Migration has been signed off, so tenancy created!
  • We know how we’re going to authenticate users!
  • We know how we’re going to synchronize our users identities!
  • We know what migration strategy we’re going to use!
  • Now all we need to decide on is what applications and services our users need once they migrate. So ……

We need to decide what licenses we need …..


Anyone who has dealt with Microsoft licensing knows that its a potential minefield due to the depth of options available. I mean, does anyone really understand how many OS and SQL Core License Packs you need to run your on-premise SCVMM Server with underlying SQL Server Enterprise Edition installed on a Windows Server DataCenter OS thats running on a VM in a 4-Node AzureStack HCI Cluster?

Nope, neither do I.

While an initial look at the Microsoft 365 plans would suggest that this is no different, its important to understand how the plans are structured. Lets start with the basics and what these plans are called. You can either have a Microsoft 365 Business Plan or an Office 365 Enterprise Plan, so lets explore the options in both and why you would choose one over the other.

Microsoft 365 Business Plans

Microsoft 365 Business Plans are recomended for companies with less that 300 users, and provide a cost effective way to migrate your users.

All Microsoft 365 Business Plans comes with the following features included:

  • 50GB Mailbox per user.
  • 50GB Archive Mailbox per user.
  • Office Online (web versions of Outlook, Excel, Word, PowerPoint and OneNote).
  • Maximum of 1TB OneDrive personal storage for each user (this can be reduced depending on your requirements).
  • 1 TB SharePoint Storage per tenancy, plus 10GB for each additional user (this can be increased with Storage Add-Ons if required).
  • Microsoft Teams.
  • Yammer.
  • Active Directory SSO for synchronized users.
  • Content Search and Basic Auditing.

In effect, the above list is what you get with the Microsoft 365 Business Basic plan, which is the lowest offering at $5.00 per month. As you can see, lots of great features, but the one thing thats missing is Desktop versions of the Office Apps.

For that, we need to go up to the next level of plan which is Microsoft 365 Business Standard, which at $12.50 per month is the most worthwhile plan to go for in your initial migration stage. As well as what’s listed above, this gives you the following add-ons:

  • Desktop versions of Outlook, Word, Excel, PowerPoint and OneNote.
  • Desktop versions of Access and Publisher.
  • Install apps on up to 5 devices across all platforms.

And thats all you get as an extra. Just apps. But bear in mind, there is also a separate Microsoft 365 Apps for Business plan which is just Desktop versions of the apps and comes in a $8.25 per month.

Lets go up to the top level which is Microsoft 365 Business Premium, which comes in at $22.00 per month. Pricey, but on top of all of the above, you also get the following:

  • Microsoft Endpoint Manager.
  • Mobile Application Management.
  • Intune.
  • Windows Autopilot.
  • Shared Computer Activation (Use Office apps on Remote Desktop Services or Citrix).
  • Defender for Endpoint.
  • Defender for Office 365.
  • Windows Defender.
  • Azure Active Directory Premium P1.
  • Conditional Access.
  • Azure Information Protection.
  • Sensitivity Labels.
  • Office365 Data Loss Prevention.
  • Office Message Encryption.
  • Litigation Hold.

As you can see from from this list, Business Premium goes deep into the realm of data security, compliance and governance.

You can find more details on Microsoft 365 Business Plans here.

Office 365 Enterprise Plans

Office 365 Enterprise plans are designed for companies with more than 300 users who need more advanced features such as eDiscovery.

The plans structures are effectively the same as above with some subtle differences. Lets run through these quickly, and start with Office 365 E1 which comes in at $10.00 per month and gives you the following:

  • 50GB Mailbox per user.
  • 50GB Archive Mailbox per user.
  • Office Online (web versions of Outlook, Excel, Word, PowerPoint and OneNote).
  • Maximum of 1TB OneDrive personal storage for each user (this can be reduced depending on your requirements).
  • 1 TB SharePoint Storage per tenancy, plus 10GB for each additional user (this can be increased with Storage Add-Ons if required).
  • Microsoft Teams.
  • Yammer.
  • Active Directory SSO for synchronized users.
  • Content Search and Basic Auditing.

So in effect, the same as Microsoft 365 Business Basic above. When we move up to Office 365 E3 for $23.00 per month, we get the following add-ons:

  • 100GB mailbox per user.
  • Unlimited archive mailbox per user.
  • Desktop versions of apps.
  • 5TB of OneDrive Storage per user.
  • Shared Computer Activation (Use Office apps on Remote Desktop Services or Citrix).
  • Azure Information Protection for Office 365.
  • Office365 Data Loss Prevention.
  • Office Message Encryption.
  • eDiscovery.
  • Litigation Hold.

The top level plan is Office 365 E5 which is $38.00 per month. There are only a few add-ons provided here, but as you can see they are big ones:

  • PowerBI Pro for Data Analyics.
  • Phone System and Audio Conferencing.
  • Defender for Office365 Plan 2.
  • Advanced eDiscovery and Audit.

You cna find out more about Office 365 Enterprise Plans here.

Which one to choose?

As you can see, plenty of choice there. Just to clarify, you can use Office 365 Enterprise licenses in organisations with under 300 users as well if you feel this is a better option for your business.

For smaller business, the recommendation is to stick with the Microsoft 365 Business plans as they provide more of an “all-in-one” solution given the amount of features that are bundled into the licenses. Larger companies and those with specific regulatory requirements will make more use of the Group Policy, DLP, Compliance and Information Protection offerings available in the Office 365 Enterprise plans.

The key here is to use your 30-day trial wisely and roadtest each of the plans available to see which one is the best fit for your business.

The license plans I’ve described above cover the majority of companies, however its good to be aware that there is a also a set of Microsoft 365 plans specifically designed for Frontline workers. You can find more details on those here.


And thats a look at the different licensing plans available in Microsoft 365 and Office 365! Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 77: Migration Options from On-Premise to Microsoft 365

Its Day 77 of my 100 Days of Cloud journey, and as promised todays post is taking a closer look at the different migration options available to you for moving your on-premise Email workloads to Microsoft 365.

In the last post, we saw the first of those options where we discovered how Exchange Hybrid configuration works. However, this also ties you into keeping an Exchange Server active in your on-premise environment, which for the majority of businesses is costly and negates one of the main drivers of migration: removing the management and cost overhead of maintaining an on-premise email environment.

Migration Options

You can migrate all email, calendar items, tasks and contacts from user mailboxes to Office 365 from an existing on-premises Exchange Server environment.

The available methods are cutover, staged, and Exchange Hybrid migrations. These migration methods copy over all mail data, including contacts, calendar items, and tasks.

You can also use (IMAP) migration from Exchange servers, and if your Exchange server is older than Exchange 2003, or if your on-premise email system is a non-Exchange system. However, you need to be aware that an IMAP migration will copy over only email data.

We’ve already see how Exchange Hybrid works, lets take a look at the other 2 options.

Cutover Migration

A cutover migration moves all of your mailboxes at one time in a single batch. This sort of Office 365 migration process can be used if the email infrastructure runs on Exchange versions from 2003 to 2013.

  • You can move your entire email organization to Microsoft 365 or Office 365 over a few days and manage user accounts in Microsoft 365 or Office 365.
  • A maximum of 2,000 mailboxes can be migrated to Microsoft 365 or Office 365 using a cutover Exchange migration. However, it is recommended that you only migrate 150 mailboxes at a time.
  • The primary domain name used for your on-premises Exchange organization must be an accepted domain owned by you in your Microsoft 365 or Office 365 organization.
  • After the migration is complete, each user who has an on-premises Exchange mailbox also will be a new user in Microsoft 365 or Office 365. However, you must still assign licenses to users whose mailboxes are migrated.

After your on-premises and Microsoft 365 or Office 365 organizations are set up for a cutover migration, post-setup tasks could impact your users.

  • Administrators or users must configure desktop computers to ensure these are set up for use with Microsoft 365 or Office 365.
  • Potential delay in email routing until the MX record is changed from on-premise to Microsoft 365.

The steps needed to run a cutover migration are shown in the image below:

Image Credit: Microsoft
  1. The administrator communicates upcoming changes to users and verifies domain ownership with the domain registrar.
  2. The administrator prepares the servers for a cutover migration and creates empty mail-enabled security groups in Microsoft 365 or Office 365.
  3. The administrator connects Microsoft 365 or Office 365 to the on-premises email system (this is called creating a migration endpoint).
  4. The administrator migrates the mailboxes and then verifies the migration.
  5. Grant Microsoft 365 or Office 365 licenses to your users.
  6. The administrator configures the domain to begin routing email directly to Microsoft 365 or Office 365.
  7. The administrator verifies that routing has changed, and then deletes the cutover migration batch.
  8. The administrator completes post-migration tasks in Microsoft 365 or Office 365 (assigns licenses to users and creates an Autodiscover Domain Name System (DNS) record), and optionally decommissions the on-premises Exchange servers.
  9. The administrator sends a welcome letter to users to tell them about Microsoft 365 or Office 365 and to describe how to sign in to their new mailboxes.

Further detail on how Cutover Migration works can be found here.

Staged Migration

For Exchange server versions running either 2003 or 2007, the only supported migration method to Microsoft O365 is Staged Migration. With this migration type, you can move your entire email infrastructure in batches. This method is beneficial for legacy Exchange servers if you have more than 2000 seats; however, for a successful migration, some critical factors need to be taken into consideration:

  • You must synchronize accounts between your on-premises Active Directory domain and Microsoft 365 or Office 365 by using Azure Active Directory sync for a staged migration to work.
  • The primary domain name used for your on-premises Exchange organization must be a domain verified to your Microsoft 365 or Office 365 organization.
  • You can migrate only user mailboxes and resource mailboxes. Other recipient types, such as distribution groups, contacts, and mail-enabled users are migrated to Microsoft 365 or Office 365 through the process of directory synchronization.
  • Out of Office messages aren’t migrated with user mailboxes. The user needs to recreate the Out of Office message after the mailbox is migrated.
  • If you limited the connections to your source email system, it’s a good idea to increase them to improve migration performance.

The steps needed to run a staged migration are shown in the image below:

Image Credit: Microsoft
  1. The administrator synchronizes the list of users between their on-premises environment and Microsoft 365 or Office 365.
  2. The administrator creates a comma-separated value (CSV) file that contains a row for each user whose on-premises mailbox will be migrated in the migration batch.
  3. The administrator creates and runs a staged migration batch by using the migration dashboard in the Exchange admin center.After the administrator starts the migration batch, Exchange Online does the following:
    • Verifies that directory synchronization is enabled.
    • Checks that a mail-enabled user exists in the Microsoft 365 or Office 365 organization for each user listed in the CSV file. Mail-enabled users are created in Microsoft 365 or Office 365 as a result of the directory synchronization process.
    • Converts the Microsoft 365 or Office 365 mail-enabled user to an Exchange Online mailbox for each user in the migration batch.
    • Begins initial synchronization. Exchange Online processes up to N migration requests at one time. N represents the maximum number of concurrent migrations that the administrator specified when creating the migration endpoint used for the migration batch. By default, initial synchronization is performed on 20 mailboxes at a time until all mailboxes in the migration batch are migrated.
    • Configures mail forwarding. The TargetAddress property on the on-premises mailbox is configured with the email address of the Exchange Online mailbox. This process means that mail sent to the on-premises mailbox is forwarded to the corresponding Exchange Online mailbox.
  4. After it creates the Exchange Online mailbox and configures mail forwarding for each user in the CSV file, Exchange Online sends a status email message to the administrator. This status message lists the number of mailboxes that were successfully migrated and how many couldn’t be migrated. The message also includes links to migration statistics and error reports that contain more detailed information. At this point, users can start using their Exchange Online mailboxes.
  5. As part of initial synchronization, Exchange Online then migrates all email messages, contacts, and calendar items from the on-premises mailboxes to Exchange Online mailboxes. Exchange Online sends a final migration report when the data migration is complete.
  6. After a migration batch is complete and the administrator verifies that all mailboxes in the batch are successfully migrated, the administrator can convert the on-premises mailboxes to mail-enabled users.
  7. If a user opens their mailbox with Outlook, the Autodiscover service tries to connect to the on-premises mailbox. After you convert on-premises mailboxes to mail-enabled users, the Autodiscover service uses the mail-enabled user to connect Outlook to the Exchange Online mailbox after the user creates a new Outlook profile.
  8. The administrator creates additional migration batches, submitting a CSV file for each one.
  9. The administrator runs additional migration batches.
  10. The administrator resolves any issues. After all on-premises mailboxes in a batch are successfully migrated, the administrator deletes the migration batch.
  11. Users can use their Exchange Online mailboxes.
  12. The administrator, to complete the transition to Exchange Online and Microsoft 365 or Office 365, performs post-configuration tasks such as:
    • Assign licenses to Microsoft 365 or Office 365 users.
    • Configure the MX record to point to your Microsoft 365 or Office 365 organization so that email is delivered directly to Exchange Online mailboxes.
    • Create an Autodiscover Domain Name System (DNS) record for your Microsoft 365 or Office 365 organization.

Further detail on how Cutover Migration works can be found here.


So thats a look at the different migration options available to migrate your on-premise Exchange environment to Microsoft 365 tenant.

In the next post, we’ll look at the myriad of different licensing options available. Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 76: Exchange Hybrid

Its Day 76 of my 100 Days of Cloud journey, and as promised todays post is taking a closer look at how Exchange Hybrid configuration works.

In the last 2 posts, we’ve looked at the following:

  • The different authentication methods available.
  • Ways to protect both our administrator and user accounts.
  • Preparing the key attributes in our Active Directory for synchronization.
  • Created our Microsoft 365 Trial tenant.
  • Added our production domain and saw how DNS records could be added.
  • Installed and configured Azure AD Connect and looked at the different options for user synchronization and authentication.

While looking at our DNS records, we decided not to implement them as we wanted to configure an Exchange Hybrid environment. This is one of the options available to you once you start to plan your cloud migration journey.

Lets take a look at what the benefits are, and how it works.

Exchange Hybrid explained

There is a saying I’ve heard in the IT industry for years – “Its easy to get your Data into the Cloud, but its not easy to get it out”.

I’ll take a further look at the different migration options available to you in the next post, however all of these option will be “on-board” only, which means that you can only migrate your on-premise mailboxes to Microsoft 365, but cannot migrate them out.

Exchange Hybrid is the only option available were you have the option to both “on-board” and “off-board” users. You maintain at least one of your on-premise Exchange Servers, and install the Hybrid Agent which allows communication between your on-premise environment and Microsoft 365.

The key features offered in a Hybrid deployment are:

  • Secure mail routing between on-premises and Exchange Online organizations.
  • Both on-premises and Exchange Online organizations use the same shared domain namespace or SMTP domain.
  • A unified global address list (GAL), also called a “shared address book.”
  • Free/busy and calendar sharing between on-premises and Exchange Online organizations.
  • Centralized control of inbound and outbound mail flow. All inbound and outbound Exchange Online messages to be routed through the on-premises Exchange organization.
  • A single Outlook on the web URL for both the on-premises and Exchange Online organizations.
  • The ability to move existing on-premises mailboxes to the Exchange Online organization. Exchange Online mailboxes can also be moved back to the on-premises organization if needed.
  • Centralized mailbox management using the on-premises Exchange admin center (EAC).
  • Message tracking, MailTips, and multi-mailbox search between on-premises and Exchange Online organizations.
  • Cloud-based message archiving for on-premises Exchange mailboxes. Exchange Online Archiving can be used with a hybrid deployment.

An example of how a typical Exchange Hybrid deployment works is shown in the diagram below:

Image Credit: Microsoft


The following prerequisites need to be in place before creating your Hybrid Deployment:

  • Exchange Server Roles:
    • 2016 and newer: Mailbox Server Role.
    • 2013: At least one instance of Mailbox and Client Access Server roles (preferably on one server).
    • 2010: At least on instance of Mailbox, Hub Transport Client Access Server roles (preferably on one server).
  • Microsoft 365 or Office 365 plan that support Directory Synchronization.
  • Active Directory synchronization: Deploy the Azure Active Directory Connect tool to enable Active Directory synchronization with your on-premises organization.
  • Autodiscover DNS records.
  • Valid digital Certificates from a trusted public CA.
  • EdgeSync is required if you’ve deployed Edge Transport servers in your on-premises organization and want to configure the Edge Transport servers for hybrid secure mail transport.


To install and configure the Exchange Hybrid deployment, you need to firstly go to the Exchange Online admin center, go to the “hybrid” menu and select the option to configure an Exchange Hybrid deployment:

This will redirect you to download the Hybrid Configuration Wizard. The wizard will run through each screen and present you with the options required.

While all of teh options and screens are important during the setup, the main ones to look for are:

  • Choosing a Minimal or Full Hybrid deployment: this provides the option to use the deployment woth minimal configuration for migration purposes only, or else to maximise the full features of the deployment.
  • Bi-directional Transport Configuration for Client Access and Mailbox Servers, and also Edge Servers for secure transport:

Once the wizard completes, you will be able to log onto Exchange Online and complete a migration of an on-premise user by selecting them from the Global Address list. You can also migrate the users back to the on-premise Exchange.

There are some excellent “how-to” articles on how this process works, this article at Azure365Pro is worth a read to see how the process works in full.

Is it worth doing?

And so we come to the main question.

A lot of people either haven’t heard of Hybrid deployments because the assumption is that any migration to Microsoft 365 will be done by the traditional methods (Cutover/Staged/IMAP), or else don’t want to invest in a Hybrid deployent because of the complexity of the environment and also the costs involved in maintaining infrastructure.

We have to remember that one of the drivers for moving to Microsoft 365 is removing the overhead of maintaining an on-premise email environment.

The other point that needs to be made is that when you have migrated all of your mailboxes to Microsoft 365 and want to decommission the Hybrid deployment, all of your mailboxes then need to become fully cloud managed identities. There is also a consideration around 3rd-party services that use Exchange for SMTP communications.


So thats a look at how you can use Hybrid Configuration to enable your on-premise Exchange environment to co-exist with your Microsoft 365 tenant during the migration process.

In the next post, we’ll look at the different mailbox migration options available. Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 75: Create your Microsoft 365 tenant and configure Azure AD Connect

Its Day 75 of my 100 Days of Cloud journey, and today I’m looking at how Azure AD Connect is configured and how it synchronizes your on-premise identities to the Azure AD Tenant for use in Microsoft 365.

But first up, lets take a look at how we can create our Microsoft 365 tenancy and get it configured for use with our domains so its ready for use.

Create your Microsoft 365 Tenant

To create your tenant, you need to browse to the Office 365 E3 product page and click on the “Free Trial” option. E3 is the default trial option as it gives you the best experience of all the tools available for 30 days:

Clicking on “Free Trial” brings you into the registration screen. You need to enter the first email address you want to use with the tenant. This won’t configure anything, its just checking that the domain isn’t already configured for Microsoft 365.

We can also see on the right of the screen whats included with the E3 license, plus the benefits. We are allowed up to 25 users for the trial, this is a good number for testing.

Click on “Create New Account”:

This brings you into the “Tell us about yourself” screen where you need to answer some questions about your organisation:

When you click next, you are asked to verify your identity via SMS or Call:

Once you get verified, you are then prompted to add your domain name. Add the domain name. Try to use the same domain name as the primary email domain that you want to use with the tenant.

Click “Next” and this will create your account. Once that completes, the screen below will appear and you can click on “Manage your subscription” to log in

And now you are logged into the Microsoft 365 admin center and can manage your subscription! This is always available to log on to at using the credentials you created above.

NOTEThe tenant I have set up above is a trial and I’m only going to use it for testing and for the purposes of the blog. So at some point in the next 30 days, I’m going to delete it as I’ve done with Azure resources in previous blog posts and I would advise you to do so as well (unless you really want to pay for your own Microsoft 365 tenant). The article here shows how to do this from within the Microsoft 365 Services and subscriptions page.

Add your Domain to your tenant

So lets fast forward 30 days – the trial has ended, your users are happy and you’ve decided as a business to migrate your existing workloads to Microsoft 365. The next step is to add your production domain and verify it.

So in the Microsoft 365 admin center, go to the “Settings” menu and select “Domains”. You have the option here to buy a domain which will redirect you to a 3rd party provider, and you can only use this option once your trial period has ended. This is useful if you need

However, we’re going to add our existing domain, so click on “Add Domain”

This brings us into the “Add Domain” screen. Enter the domain name you want to use and click on the “Use this Domain” button at the bottom of the screen:

The next screen provides a list of options for verifying the domain. Now, because the blog is on WordPress, its giving me the option to sign in to WordPress to verify. Unless your Website is hosted on WordPress, you’re not going to see this option, but wil see the 3 options below that.

The most common is the option to “Add a TXT record to the domain’s DNS records”, so we’ll select that and click “Continue”:

This detects who the hosting provider is, and provides you with the TXT record you need to add to your public DNS Records, so I’ll do that in the background and click “Verify” (this may take up to 30 minutes after you add the TXT to work):

Once thats verified, we get a screen asking us to connect our domain and set up DNS records. Again, I’m seeing the option to let Microsoft add the records for me automatically to WordPress (and this may also work depending on who your hosting provider is), however I’m going to choose the second option to add my own DNS records so we can take a look at whats provided:

The next screen gives me the MX Records I need to get set up with email initially, and there are also options for Skype for Business and Intune MDM at the bottom of the screen if required.

I wanted to show you this page to ensure you understand the process and how it works. However at this stage, I’m going to go back to the previous screen and click “Skip and do this later”. The reason is that this will impact mailflow, and our configuration doesn’t have a Hybrid configuration in place yet to support the mailflow.

Once we finish, we get a screen to say the setup is complete, and we can see our domain listed in the admin center.

Azure AD Connect Installation

Once your domain is registered in the portal, you should now be in a position to synchronise your user accounts so its time to install and configure Azure AD Connect.

To do this, we go to the “Users” menu and select “Active Users”. Once that screen appears, we click on the “ellipses” and select “Directory synchronization”:

This brings us to a screen with an external link to download the Azure AD Connect tool:

At the time of writing this post, the current Azure AD Connect version is and is only supported on Windows Server 2016 and Windows Server 2019. There are a number of other prerequisistes that need to be satisfied before installing Azure AD Connect:

  • Azure AD Tenant: this is created for you when you sign up for the Microsoft 365 Trial.
  • Domain needs to be verified: we’ve done this above.
  • The on-premise Active Directory forest and domain functional levels must be Windows Server 2003 or later. The domain controllers can run any level as long as this condition is met. This also means that you don’t need to install Azure AD Connect on a Domain Controller.
  • The Domain Controller used by Azure AD during the setup must be writable and not a read-only domain controller (RODC). Even though you may have other writable domain controllers in your environment, Azure AD doesn’t support write redirects.
  • Enabling the Active Directory recycle bin is recommended.
  • The PowerShell execution policy neds to be set to “RemoteSigned” on the Server that Azure AD Connect is installed on.
  • Installing on Windows Server Core is not supported.
  • Finally as discussed in the last post, this is a good time to ensure the UPN and proxyAddress attributes are set correctly on your on-premise environment.

So now you can go ahead and install Azure AD Connect. As per the previous post, there are different authentication methods to choose from and these are available as install options in the Azure AD Connect installation wizard:

  • Password Hash Synchronization (PHS) – this can be run as express installation and assumes the following:
    • You have a single Active Directory forest on-premises.
    • You have an enterprise administrator account you can use for the installation.
    • You have less than 100,000 objects in your on-premises Active Directory.

With an Express installation, you get:

  • Password hash synchronization from on-premises to Azure AD for single sign-on.
  • A configuration that synchronizes users, groups, contacts, and Windows 10 computers.
  • Synchronization of all eligible objects in all domains and all OUs. At the end of the installation, you can run the installation wizard again and choose to filter domains or OU’s.
  • Automatic upgrade is enabled to make sure you always use the latest available version.

The other option is Pass-through authentication (PTA). If you have already run an express installation, all you need to do is select the “Change user sign-in” task from the Azure AD Connect application, select next and pick PTA as the sign-in method. Once successful, this will install the PTA agent on the same server as Azure AD Connect is installed on.

What you then need to do is ensure that Pass-through authentication is enabled on your tenant in the Azure AD Connect blade in your Azure AD tenant.

NOTE if you turn this feature on, it will affect all users in your managed domain, and not just for signing on to Microsoft 365, but other services such as Azure or Dynamics that you may be using the tenant for. So you need to be very aware of the effects of making this change.

Your on-premise users and computers will now synchronize to your Microsoft 365 tenant.


So thats the quick tour of setting up your tenant, adding domains and confirming DNS settings, and installing and configuring Azure AD Connect.

In the next post, we’ll look at setting up the Hybrid Configuration to enable your on-premise Exchange environment to co-exist with your Microsoft 365 tenant during the migration process. Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 74: Preparing your Active Directory to Sync with Azure AD Connect

Its Day 74 of my 100 Days of Cloud journey, and today I’m jumping back into the Microsoft 365 ecosystem and taking a look at the steps needed to prepare your on-premise Active Directory environment.

We touched on Microsoft 365 briefly on Day 72 when we looked at whether migrating your on-premise File Server to Azure Files or SharePoint was the best option for your business. We also commented that a migration to Microsoft 365 hosted email was traditionally the first step that the majority of companies have taken or will take in their journey to Public Cloud environemnts.

I’ve decided to step back and look at Microsoft 365 as a whole and the services offered in the next few posts where we can see how each service can provide a benefit to your business. But before we do that, lets take a look at the preparation needed to decide on which identity models to use, and the preparation needed on your on-premise Active Directory environment if using the Hybrid identity model.

Authentication Methods

But before that happens or you decide on any migration strategy, you need to decide how your users will authenticate to those Cloud Services. For this we have 2 options

  1. Cloud-only identity: A cloud-only identity uses user accounts that exist only in Azure AD. Cloud-only identity is typically used by small organizations that do not have on-premises servers or do not use AD DS to manage local identities. All management of these identities is performed using the Microsoft 365 admin center and Windows PowerShell with the Microsoft Azure Active Directory Module.
  2. Hybrid identity: Hybrid identity uses accounts that originate in an on-premises AD DS and have a copy in the Azure AD tenant of a Microsoft 365 subscription. Most changes, with the exception of specific account attributes, only flow one way. Changes that you make to AD DS user accounts are synchronized to their copy in Azure AD. Azure AD Connect runs on an on-premises server, provides ongoing account synchronization, checks for changes in the AD DS, and forwards those changes to Azure AD

So that all makes sense! Now lets introduce another layer of complexity and choice. If you choose a Cloud-only identity model, things are straightforward. However, if you choose a Hybrid model, you have 2 authentication options:

  1. Managed Authentication: this is where Azure AD handles the authentication process. And nested within this, you have 2 options:
    • Password hash synchronization (PHS): this is where Azure AD performs the authentication using a hash of the password that has been syncronized from your on-premise Active Directory.
Image Credit: Microsoft
  • Pass-through authentication (PTA): this is where Azure AD redirects the authentication request back to your on-premise Active Directory.
Image Credit: Microsoft

2. Federated authentication: this is is primarily for large enterprise organizations with more complex authentication requirements. AD DS identities are synchronized with Microsoft 365 and users accounts are managed on-premises. With federated authentication, users have the same password on-premises and in the cloud and they do not have to sign in again to use Microsoft 365.

Managing and Protecting Privileged Accounts and Administrator Roles

The general rule of thumb is that we should never assign administrator roles to everyday user accounts, especially accounts that have been synchronized from on-premise.

You should assign dedicated Cloud-only identities for administrator roles, and protects these accounts with Multi-Factor Authentication, and/or Azure AD Priveleged Identity Management for on-demand, just-in-time assignment of adminstrator roles. You should also consider using a privileged access workstation (PAW). A PAW is a dedicated computer that is only used for sensitive configuration tasks, such as Microsoft 365 configuration that requires a privileged account.

Managing and Protecting User Accounts

While administrator accounts are the first ones to get protected, sometimes we forget about protecting our user accounts. While we have recommended MFA for administrator accounts, we need to be enabling and enforcing MFA for all users.

We can also enabled other advanced features (depending on our license levels):

  1. Security Defaults: this feature requires all of your users to use MFA with the Microsoft Authenticator app. Users have 14 days to register for MFA with the Microsoft Authenticator app from their smart phones, which begins from the first time they sign in after security defaults has been enabled. After 14 days have passed, the user won’t be able to sign in until MFA registration is completed.
  2. Azure AD Password Protection: detects and blocks known weak passwords and their variants and can also block additional weak terms that are specific to your organization. Default global banned password lists are automatically applied to all users in an Azure AD tenant. You can define additional entries in a custom banned password list. When users change or reset their passwords, these banned password lists are checked to enforce the use of strong passwords.
  3. Conditional Access policies: a set of rules that specify the conditions under which sign-ins are evaluated and access is granted. We looked at this in detail on Day 57.

Keep the following in mind:

  • You cannot enable security defaults if you have any Conditional Access policies enabled.
  • You cannot enable any Conditional Access policies if you have security defaults enabled.

Active Directory Domain Services Preparation

Before you synchronize your AD DS to your Azure AD tenant, you need to clean up your AD DS. This is an important step as if its not performed correctly, it can lead to a significant negative impact on the deployment process. It might take days, or even weeks, to go through the cycle of directory synchronization, identifying errors, and re-synchronization.

While there are a number of attributes you need to prepare for synchronization, the most important ones are:

  1. userPrincipalName (UPN): this needs to be a valid and unique value for each user object, as the AD DS UPN matches the Azure AD UPN. This is what users will use to authenticate, and is required to be in the Internet-style sign-in format, for example “”.
    • A note on this – Active Directory use the sAMAccountName attribute to authenticate. It recommended that prior to syncing your identities, this should match the userPrincipalName to avoid confustion for both users and administrators, however this is not necessary.
    • Another note – if you are using multiple mail domains, you can add multiple UPN suffixes. The article here shows how to add these and also how to change the UPN for each or multiple users.
  2. mail: This is the users Primary email address, and needs to be unique for each user. This can only contain a single value.
  3. proxyAddress: This is the users email addresses, again it needs to be unique for each user object. It cannot contain any spaces or invalid characters. This can have multiple entries if you have multiple mail domains in use.
    • A note here – The Primary address will be same as the mail attribute, and will be in the format “”. Additional addresses will be in the format “” (note the uppercase and lowercase).
  4. displayName: This is how your name will be displayed in the Global Address list, and is a combination of the givenName and surname attributes. Its not necessary to be unique, however it is recommended to avoid confusion.

For optimal use of the Global Address List, its recommended that these attributes are populated and correct for each account:

  • givenName
  • surname
  • displayName
  • Job Title
  • Department
  • Office
  • Office Phone
  • Mobile Phone
  • Fax Number
  • Street Address
  • City
  • State or Province
  • Zip or Postal Code
  • Country or Region


In this post, we looked at the steps required to prepare for synchronization for choosing an identity model, administrator and user security, and finally user account and attribute preparation.

In the next post, we’ll look at the steps to install Azure AD Connect to synchroniuze your identities. Hope you enjoyed this post, until next time!