100 Days of Cloud – Day 91: Azure Virtual Desktop Demo Part 1

Its Day 91 of my 100 Days of Cloud journey and as promised in todays post we’ll start our Demo build of an Azure Virtual Desktop environment!

In the last post, we looked at a high-level overview of the benefits and concepts of Azure Virtual Desktop, and the management responsibilities of both Microsoft and the Customer.

Lets dive straight into the Demo and set up our sample Azure Virtual Desktop environment.

Prerequisites

We need to set up our prerequisites and in this case there are only 2 that we need. Firstly lets set up a Log Analytics workspace which we can send all of our log data to. So we log onto the Portal, click “Create a resource” and search for Log Analytics Workspace. And click Create:

We’ll select our Subscription and create a new Resource Group. We’ll also give our Workpace and name and select a region where it will be stored. Once thats done, click “Review and Create”:

As you can see, we default to a “Pay-as-you-go” pricing tier. Click “Create” to create ourLog Analytics Workspace:

Once thats created, the next thing we need is Authentication. To deploy Azure Virtual Desktop environment, we need either:

  • Azure Active Directory
  • Active Directory Domain Services

I’m going to use Azure AD for the purposes of the lab, and have created some users already. Its always great to see Bruce, Clark and Tony ready for action:

And thats the prerequisistes done – we are now ready to create the host pool.

Create Host Pool

A Host Pool is a collection of Azure virtual machines that register to Azure Virtual Desktop as session hosts when you run the Azure Virtual Desktop agent. All session host virtual machines in a host pool should be sourced from the same image for a consistent user experience.

So what we’ll do in this section is as follows:

  • Create a Host Pool named MD-AVD-HP01 of personal type.
  • Register the default desktop application group from this hostpool to a new workspace named MD-AVD-WS01.

Lets go to the Azure portal and search for Azure Virtual Desktop. This will bring us into the Azure Virtual Desktop management window:

Now select Host pools under Manage blade and then click on “Create” to add new Host Pool:

We will provide the details required to create a Host Pool.

  • Project Details – Defines the Host Pool environment
    • Subscription: Choose the default subscription.
    • Resource Group: Select md-avd-demo from the drop down.
    • Host Pool Name: MD-AVD-HP01
    • Location: North Europe (this should be same as the region of your resource group).
    • Validation environment: Yes (Validation host pools let you monitor service updates before rolling them out to your production environment. This needs to be set to Yes here as we are joining this to an Azure AD environment).
    • Host Pool Type: Personal (I need to choose Personal for the demo as I’m using Azure AD. This is not currently supported for Pooled desktops).

Note – when you select “Pooled” as the host pool type, you have additional options. I’ve included a screenshot of what this looks like:

  • Load Balancing Algorithm: there are two types:
    • Breadth-first load balancing allows you to evenly distribute user sessions across the session hosts in a host pool.
    • Depth-first load balancing allows you to saturate a session host with user sessions in a host pool.)
  • Max Session Limit: limits the simultaneous number of users on the same session host.

Now we click next and go the the the Virtual machines tab. I’m going to leave this at “No” for now – because I am using Azure AD for authentication I habve some additional steps to do before creating my Session Hosts.

We click next and move on to the Workspace tab. Once we select “Yes” to “Register desktop app group”, we need to create a workspace called MD-AVD-WS01:

Finally in the Diagnostics tab, we enable diagnostic settings and choose to send these to our Log Analytics Workspace. As you can see, we can also choose to archive to a storage account or send the events to an Event Hub:

Now we can click on “Review and Create” and review the details in the Validation screen:

Once we are happy click on “Create” to create our Host Pool and we’ll get a screen similar to below to tell us the Deployment is completed:

And we can see that we have a Host Pool created in our Azure Virtual Desktop console:

Configure Azure AD Authentication

Because I’m using Azure AD for the demo, I need to assign my users permissions to access the desktop. Firstly, I need to go to my DAG object in the Application Group of the Host Pool and go to “Assignments”:

We then click on “Add” and select our users:

Azure AD Role Assignments

To allow users to log on to the Virtual Machines, we also need to add Role Assignments. There are 2 we need to add:

  • Virtual Machine Administrator Login
  • Virtual Machine User Login

We can ensure that these roles are assigned automatically by assigning this at the IAM level of our Resource Group:

RDP Properties

In order for the Host Pool to know that the session hosts are Azure AD joined, we need to add an advanced RDP property. So we go back to my Host Pool, choose “RDP Properties” from the settings menu and under Advanced we add the following string:

targetisaadjoined:i:1

Click on “Save” to save the changes.

Create Session Hosts

We’re now ready to create our Session Hosts. So we’ll go back to our Host Pool, select “Session Hosts” from the “Manage” menu and click on “Add”:

The “Basics” tab is already pre-populated with the information from our Host Pool:

This will give us the options to provide details for the VMs we need to add:

  • Resource Group: Select md-avd-demo from the drop down.
  • Name prefix: md-avd-sh0
  • Virtual machine location: North Europe (location should be same as location of your resource group).
  • Availability options: Select No infrastructure redundancy required from the drop down (again, this is being used for the purposes of the demo).
  • Image type: Gallery
  • Image: Windows 10 Enterprise, version 21H2
  • Virtual machine size: Standard B2s. (You can click on Change Size, then select the size you require and click on Select to choose the size)
  • Number of VMs: 2
  • OS Disk Type: Standard HDD (you can choose based on your requirements)

Next we scroll down to the “Network and security” section and specify the Virtual Network and Subnet that we wish to use:

Finally on this screen, we scroll down and specify whether we wish to join an Active Directory or Azure Active Directory. We also specify admin accounts for the Session Host VM’s we are creating:

Finally, on the “Advanced” tab we need to enable Diagnostic Settings and send the logs to our Log Analytics Workspace:

Once all of the info is correct and has been validated, we click Create to create our Session Hosts. Once thats created, we should see our Virtual Machines

And if we drill down into “Session hosts”, we should see both hosts set as available:

Note – this step may take up to 30 minutes to complete, and you may see errors on the Session Hosts. Don’t panic! If you’ve followed the steps above, the errors will eventually clear and the hosts will show as available.

Diagnostic Features

We now need to check and ensure diagnostic features for both the host pool and workspace to allow us to analyse monitoring data. We set this up when creating the host pool and session hosts, but lets make sure its set up and also we can see what we’re going to monitor.

Lets go to our host pool first and we go to Diagnostic Settings in the Monitoring menu:

We do the same check for Workspace to ensure that this is configured correctly:

Lets also enable this for our Session Hosts – we need to do that directly on the VMs in the Resource Group. So we go to the Monitoring menu, select Insights, and then click on “Enable”:

We’ll get a prompt telling us that the VM is not connected to a workspace. We select the Subscription and Workspace that we wish and click “Enable”:

Give that a few minutes and you’ll then go back in and see some data in the Insights page:

Conclusion

Thats where we’ll pause for breath! Lots of information there, so just to recap:

  • We created our Log Analytics Workspace for logging our monitoring data
  • Created our Test Users in Azure AD
  • Created the Host Pool
  • Created the Assignments to allow users to access the desktops
  • Created the Service Hosts
  • Verified that Diagnostic Settings are working
  • Added our Session Hosts into Monitoring

We’ll continue the demo in the next post where we’ll create our Application Groups for both Desktop and Remote App, connect to our AVD resources using the different methods available. We’ll also look at our monitoring data that being collected.

Hope you enjoyed this post, until next time!



100 Days of Cloud – Day 90: Azure Virtual Desktop Core Concepts

Its Day 90 of my 100 Days of Cloud journey and in this post I’ll be taking a looks at the benefits and architecture of Azure Virtual Desktop.

In the last post we touched briefly on Azure Virtual Desktop in comparison to Windows 365 Cloud PC. Both solutions allow you to easily support accessibility for users, on any device, from anywhere. However while Windows 365 Cloud PC can be easily deployed and managed, Azure Virtual Desktop has greater flexibility which leads to a greater management overhead for administrators.

In the next 2-3 posts after this one, we’ll demo how to set up an Azure Virtual Desktop deployment, but first let familiarize ourselves with the benefits, core concepts and architecture.

Benefits of Azure Virtual Desktop

With Azure Virtual Desktop you can:

  • Set up a multi-session Windows 10 deployment that delivers a full Windows 10 with scalability.
  • Virtualize Microsoft 365 Apps for enterprise and optimize it to run in multi-user virtual scenarios.
  • Provide Windows 7 virtual desktops with free Extended Security Updates.
  • Bring your existing Remote Desktop Services (RDS) and Windows Server desktops and apps to any computer.
  • Virtualize both desktops and apps.
  • Manage Windows 10, Windows Server, and Windows 7 desktops and apps with a unified management experience.
  • Bring your own image for production workloads.
  • Use autoscale to automatically increase or decrease capacity based on time of day, specific days of the week, or as demand changes, helping to manage cost.

Core Concepts and Hierarchy

Before we jump into the Demo, lets take a quick look at some of the key concepts of Azure Virtual Desktop and where they each sit in the hierarchy of an Azure Virtual Desktop architecture.

Host Pools

Host pools are a collection of one or more identical virtual machines within Azure Virtual Desktop tenant environments. Each host pool can be associated with multiple RemoteApp groups, one desktop app group, and multiple session hosts. Host Pools can be one of two types:

  • Personal, where each session host is assigned to individual users.
  • Pooled, where session hosts can accept connections from any user authorized to an application group within the host pool. You can set additional properties on the host pool to change its load-balancing behavior, how many sessions each session host can take, and what the user can do to session hosts in the host pool while signed in to their Azure Virtual Desktop sessions. You control the resources published to users through application groups.

There is no limit to the number of pools, and these can be easily scaled either manually or automatically allowing you to add or reduce capacity based on demand which can help manage costs.

Application Groups

An Application group is a logical grouping of applications installed on session hosts in the host pool. An application group can be one of two types:

  • RemoteApp, where users access the RemoteApps you individually select and publish to the application group.
  • Desktop, where users access the full desktop By default, a desktop application group (named “Desktop Application Group”) is automatically created whenever you create a host pool. You can remove this application group at any time. However, you can’t create another desktop application group in the host pool while a desktop application group already exists. To publish RemoteApps, you must create a RemoteApp application group. You can create multiple RemoteApp application groups to accommodate different worker scenarios. Different RemoteApp application groups can also contain overlapping RemoteApps.

Workspaces

A workspace is a logical grouping of application groups in Azure Virtual Desktop. Each Azure Virtual Desktop application group must be associated with a workspace for users to see the remote apps and desktops published to them.

End users

After you’ve assigned users to their application groups, they can connect to a Azure Virtual Desktop deployment with any of the Azure Virtual Desktop clients.

The diagram below is a typical Azure Virtual Desktop Architecture:

Image Credit – Microsoft

Components – Microsoft Managed versus Customer Managed

We’ve all seen the “as a service” model which is used sometimes to explain what services Microsoft manages versus what a customer managed across IAAS, PAAS and SAAS offerings.

Image Credit – Microsoft

Azure Virtual Desktop is no different in that some of the components of the service are managed by Microsoft and some are required be be managed by the customer. Lets do a quick breakdown of these.

Microsoft Managed

Microsoft manages the following Azure Virtual Desktop services, as part of Azure:

  • Web Access Service: allows users access virtual desktops and remote apps through a web browser from anywhere on any device. You can secure Web Access using multifactor authentication in Azure Active Directory.
  • Remote Connection Gateway Service: allows remote users to connect to Azure Virtual Desktop apps and desktops from any internet-connected device that can run an Azure Virtual Desktop client. The client connects to a gateway, which then orchestrates a connection from a VM back to the same gateway.
  • Connection Broker Service: service manages user connections to virtual desktops and remote apps. The Connection Broker provides load balancing and reconnection to existing sessions.
  • Remote Desktop Diagnostics: event-based aggregator that marks each user or administrator action on the Azure Virtual Desktop deployment as a success or failure. Administrators can query the event aggregation to identify failing components.
  • Extensibility or Management: Azure Virtual Desktop includes several extensibility components. You can manage Azure Virtual Desktop using Windows PowerShell or with the provided REST APIs, which also enable support from third-party tools.

Customer Managed

Customers manage these components of Azure Virtual Desktop solutions:

  • Azure Virtual Network: allows Azure resources like VMs communicate privately with each other and with the internet. You can enforce your organizations policies by connecting Azure Virtual Desktop host pools to an Active Directory domain. You can connect an Azure Virtual Desktop to an on-premises network using a virtual private network (VPN), or use Azure ExpressRoute to extend the on-premises network into the Azure cloud over a private connection.
  • Identity – there are 2 options for authentication against Azure Virtual Desktop:
    • Azure Active Directory: Azure Virtual Desktop uses Azure AD for identity and access management. Azure AD integration applies Azure AD security features like conditional access, multi-factor authentication, and the Intelligent Security Graph, and helps maintain app compatibility in domain-joined VMs.
    • Active Directory Domain Services: Azure Virtual Desktop VMs must domain-join an AD DS service, and the AD DS must be in sync with Azure AD to associate users between the two services. You can use Azure AD Connect to associate AD DS with Azure AD.
  • Azure Virtual Desktop session hosts: A host pool can run the following operating systems:
    • Windows 7 Enterprise
    • Windows 10 Enterprise
    • Windows 10 Enterprise Multi-session
    • Windows Server 2012 R2 and above
    • Custom Windows system images with pre-loaded apps, group policies, or other customizations
  • Azure Virtual Desktop Workspace: this is used to manage and publish host pool resources.

As I also touched briefly on in the last post, you also have the option to host your Azure Virtual Desktop environment locally on an on-premises Azure Stack HCI infrastructure. This however is still in preview, and you can find more details here.

Conclusion

Thats a high-level overview of the benefits and concepts of Azure Virtual Desktop. You can find the full details of how it works in the official Microsoft Documentation here. In the next post, we’ll start our Demo build of an AVD environment!

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 89: Windows 365 Cloud PC or Azure Virtual Desktop?

Its Day 89 of my 100 Days of Cloud journey, and todays post is going to give a quick comparison between Windows 365 Cloud PC and Azure Virtual Desktop.

The global Covid-19 pandemic has accelerated the demand for cloud-based solutions. Businesses and Educational Institutions have needed to quickly adapt to remote work and distance learning in a hybrid world.

While we’ve all seen or heard of Windows Remote Desktop Services, Citrix would to most of us be more recognizable as the leader in the VDI and Remote Desktop space down through the years. However, Microsoft are playing catch-up and given the integration offerings that are available across the multitude of Cloud Services, they have 2 offerings in Windows 365 Cloud PC and Azure Virtual Desktop. Both solutions allow you to easily support accessibility for users, on any device, from anywhere.

So they both sound like they do the same thing, and when logging on both look the same, but they’re not really. Lets take a closer look at the differences between then, the difference in costs and licencing, and try to determine which one is the best fit for your business.

Windows 365 Cloud PC

Windows 365 is a cloud-based service that automatically creates a new type of Windows virtual machine (Cloud PCs) for your end users. Each Cloud PC is assigned to an individual user and is their dedicated Windows device. Licences are purchased either through the Microsoft 365 Admin center or through the Windows Products site (if you do not have a Microsoft 365 Subscription), and are assigned directly to the user. When you assign a licence, the Cloud PC is automatically provisioned for you.

There are 2 subscription levels to choose from which each have a number of size options:

  • Business: this is for smaller organizations (up to 300 users) that want a simple way to buy, deploy, and manage Cloud PCs. The 3 size options are:
    • Basic (approx €35 per month): Recommended for light productivity and web browsers. Comes with 2 vCPU, 4GB RAM and 128GB of Storage. Supports Desktop versions of Office Apps, Teams and OneDrive
    • Standard (approx $40 per month): Recommended for full productivity and line of business apps. Comes with 2 vCPU, 8GB RAM and 128GB of Storage. Supports Desktop versions of Office Apps, Teams and OneDrive
    • Premium (approx $65 per month): Recommended for high performance workloads and heavy data processing. Comes with 4 vCPU, 16GB RAM and 128GB of Storage. Supports Desktop versions of Office Apps, Teams and OneDrive and also Dynamics 365, PowerBI and Visual Studio.
  • Enterprise: this is for organizations that want to manage their Cloud PCs with Microsoft Endpoint Manager and take advantage of integrations with other Microsoft services. There is no user limit on the Enterprise tier. The 3 size options are:
    • Basic (approx €35 per month): Integrated with Microsoft Endpoint Manager. Recommended for light productivity and web browsers. Comes with 2 vCPU, 4GB RAM and 128GB of Storage. Supports Desktop versions of Office Apps, Teams and OneDrive
    • Standard (approx $40 per month): Integrated with Microsoft Endpoint Manager. Recommended for full productivity and line of business apps. Comes with 2 vCPU, 8GB RAM and 128GB of Storage. Supports Desktop versions of Office Apps, Teams and OneDrive
    • Premium (approx $65 per month): Integrated with Microsoft Endpoint Manager. Recommended for high performance workloads and heavy data processing. Comes with 4 vCPU, 16GB RAM and 128GB of Storage. Supports Desktop versions of Office Apps, Teams and OneDrive and also Dynamics 365, PowerBI and Visual Studio.

So as we can see, there is no difference in the performance levels between the tiers, the only difference is the Microsoft Endpoint Manager integration on the Enterprise tier.

The big differences and advantage that Enterprise offers is:

  • Cloud PCs can be joined to your enterprise Active Directory domain and synced to Azure AD, or Azure AD joined.
  • the ability to connect your Cloud PC to your on-premises resources.
  • allows you to use custom images that you can build yourself as the base images for your Cloud PCs.

If you are not sure which option is best for you, Microsoft provides a Cloud PC Chooser website where you can fill in a number of questions to determine which Windows 365 Cloud PC is the right option for your business.

Azure Virtual Desktop

While Azure Virtual Desktop is similar in many ways to Windows 365 Cloud PC, these are really only on the surface. It also provides a virtual desktop to the user, but there is more flexibility in how this is delivered. However that flexibility comes with a greater need for administration and a larger workload for IT professionals.

One of the major benefits of Azure Virtual Desktop is that it can be delivered as either a personal desktop in the same way as Windows 365 Cloud PC or a pooled desktop where multiple users can access a pool of desktops.

Personal Desktops functions in the same way as Windows 365 Cloud PC but runs in a “pay as you use” pricing model and also allows for multiple user sessions on a single Windows 10 or 11 desktop.

Pooled desktops or personal host pools are a collection of nodes that runs a “user to desktop” relationship. You can create a pool of nodes to whatever sizing specification you require and assign them to users, so for example you could create a pool of 8 nodes and assign 40 users to those nodes. The user settings, profile and data changes are still present after logout as these are abstracted away from the OS Drives of each node to an FSLogix Profile container which holds the user profiles and is mounted transparently at logon to integrate with the User Session.

There is no limit to the number of pools, and these can be easily scaled either manually or automatically allowing you to add or reduce capacity based on demand which can help manage costs.

There is also an option (currently in preview) to run Azure Virtual Desktop on your on-premises Azure Stack HCI infrastructure which can further reduce costs and meet data locality requirements.

Conclusion

So thats an in-depth look and Windows 365 Cloud PC and a brief look at the differences in Azure Virtual Desktop, which I’m going to cover in more detail in the next few posts.

So which is the right choice? Depends on your requirements, Windows 365 Cloud PC gives you recurring monthly costs with very little administration or overheads, while Azure Virtual Desktop gives you more flexibility and a “pay as you use” model, but the administration effort is higher. There are plenty of 3rd party integrators out there to help with this administration load, and Nerdio is premier player in the market at present.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 88: Azure Kubernetes Service

Its Day 88 of my 100 Days of Cloud journey and as promised, in todays post I’ve finally gotten to Azure Kubernetes Service.

On Day 86, we introduced the components that make up Kubernetes, tools used to manage the environment and also some considerations you need to be aware of when using Kubernetes, and in the last post we installed a local Kubernetes Cluster using Minikube.

Today we move on to Azure Kubernetes Service and we’ll look first at how this differs in architecture from an on-premises installation of Kubernetes.

Azure Kubernetes Service

As always lets start with the definition – Azure Kubernetes Service (AKS) is a managed Kubernetes service that lets you quickly deploy and manage clusters. The operational overhead is offloaded to Azure, and it handles critical tasks such as health monitoring and maintenance.

When you create an AKS cluster, a control plane or master node is automatically created and configured, and provided at no cost as a managed Azure resource. You only pay for the nodes attached to the AKS cluster. The control plane and its resources reside only on the region where you created the cluster.

Image Credit: Microsoft

AKS Cluster Nodes are run on Azure Virtual Machines (which can be either Linux or Windows Server 2019), so you can size your nodes based on the storage, CPU, memory and type that you require for your workloads. These are billed as standard VMs so any discounts (including reservations) are automatically applied.

Its important to note though that VM sizes with less than 2 CPUs may not be used with AKS – this is to ensure that the required system required pods and applications can run reliably.

When you scale out the number of nodes, Azure automatically creates and configures the requested number of VMs. Nodes of the same configuration are known as Node Pools and you define the number of nodes required in a pool during initial setup (which we’ll see below).

Azure has the following limits:

  • Maximum of 5000 Clusters per subscription
  • Maximum of 100 Nodes per cluster with Virtual Machine Availability Sets and Basic Load Balancer SKU
  • Maximum of 1000 Nodes per cluster with Virtual Machine Scale Sets and Standard Load Balancer SKU
  • Maximum of 100 Node Pools per cluster
  • Maximum of 250 Pods per node

When you create a cluster using the Azure portal, you can choose a preset configuration to quickly customize based on your scenario. You can modify any of the preset values at any time.

  • Standard – Works well with most applications.
  • Dev/Test – Use this if experimenting with AKS or deploying a test application.
  • Cost-optimized – reduces costs on production workloads that can tolerate interruptions.
  • Batch processing – Best for machine learning, compute-intensive, and graphics-intensive workloads. Suited for applications requiring fast scale-up and scale-out of the cluster.
  • Hardened access – Best for large enterprises that need full control of security and stability.

If we go into the Portal and “Create a Resource”, select “Containers” frm the categories and click on “Create” under Kubernetes Service:

As we can see this throws us into our screen for creating our Cluster. As always, we need to select a Subscription and Resource Group. Down below this is where it gets interesting, and we can see the preset configurations that we described above:

We can see that “Standard ($$)” is selected by default, and if we click on “Learn more and compare presets”, we get a screen showing us details of each option:

I’m going to select “Dev/Test ($)” and click apply to come back to the Basics screen. I now give the Cluster a name and select a region. We can also see that I can select different Kubernetes versions from the dropdown:

Finally on this screen, we select the Node Pool options and can select Node size (you can change the size and select whatever VM size that you need to meet your needs), manual or auto scaling and the Node Count:

We click next and move on to the “Node Pools” screen, where we can add other Node Pools and select encryption options:

The next screen is “Access” where we can specify RBAC access and also AKS-managed Azure AD which controls access using Azure AD Group membership. Note that this option cannot be disabled after it is enabled:

The next screen is Networking and this is where things get interesting – we can use kubenet to create a VNet using default values, or Azure CNI (Container Networking Interface) which allows you to specify a subnet from your own managed Vnets. We can also specify Network policies to define rules for ingress and egress traffic in and out of the cluster.

The next screen is Integrations, where we can integrate with Azure Container Registry and also enable Azure Monitor and Azure Policy.

At this point, we can click Review and Create and go make a cup of tea while thats being created.

And once thats done (the deployment, not the tea….), we can see the Cluster has been created:

One interesting thing to note – the cluster has been created in my “MD-AKS-Test” Resource Group, however a second RG has been created that containes the NSG, Route Table, VNet, Load Balancer, Managed Identity and Scale Set, so its separating the underlying management components from the main cluster resource.

So at thsi point, we need to jump into Cloud Shell and manage the cluster from there. When we launch Cloud Shell and the prompt appears, run:

az aks get-credentials --resource-group MD-AKS-Test --name MD-AKS-Test-Cluster

This sets our cluster as the current context in the Cloud Shell and allows us to run kubectl commands against it. We can now run kubectl get nodes to show us the status of the nodes in our node pool:

At this point, you are ready to deploy an application into your Cluster! You can use the process as described here to create your YAML file and deploy and test the sample Azure Voting App. Once this is deployed, you can check the “Workloads” menu from your cluster in the Portal to see that this is running:

If we click into either of the “azure-vote” deployments, we can see the underlying Pod in place with its internal IP and the node its assigned to:

To delete the cluster, run az aks delete --resource-group MD-AKS-Test --name MD-AKS-Test-Cluster --yes --no-wait.

Azure Kubernetes Service or run your own Kubernetes Cluster?

So this is the million dollar question and there really is no correct answer – it really does depend on your own particular use case.

Lets try to break it down this way – Deploying and operating your own Kubernetes cluster is complex and will require more work to get the underlying technology set up, such as networking, monitoring, identity management and storage.

The flip side is that if you go with AKS its a much faster way to get up and running with Kubernetes and you have full access to technologies such as Azure AD and Azure Key Vault, but you don’t have access to your control plane or master nodes. There is also the cost element to think of as Kubernets can get expensive running in the cloud depending on how much you decide to scale.

Conclusion

So thats a look at Azure Kubernetes Service and also the benefits of running Kubernetes in Azure versus On-Premises.

The last few posts have only really scratched the surface on Kubernetes – there is a lot to learn about the technology and a steep learning curve. One thing for sure is that Kubernetes is a really hot technology right now and there is huge demand for people who have it as a skill.

If you want to follow some folks who know their Kubernetes inside out, the people I would recommend are:

  • Chad Crowell who you can follow on Twitter or his blog. Chad also has an excellent Kubernetes from Scratch course over at CloudSkills.io containing over 30 real world projects to help you ramp up on Kubernetes.
  • Michael Levan who you can follow from all his socials on Linktree and who has published multiple content pieces on his social channels.
  • Richard Hooper (aka Pixel Robots and Microsoft Azure MVP) who you can follow on Twitter or his blog which contains in-depth blog posts and scenarios for AKS. Richard also co-hosts the Azure Cloud Native user group which you can find on Meetup.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 87: Installing and Configuring Kubernetes

Its Day 87 of my 100 Days of Cloud journey and as promised, in todays post I’m going to install and configure Kubernetes locally using Minikube.

In the last post, we listed out all of the components that make up Kubernetes, tools used to manage the environment and also some considerations you need to be aware of when using Kubernetes.

Local Kubernetes – Minikube

We’re going to install Minikube on my Windows Laptop, however you can also install for both Linux and MacOS if thats your preference. These are the requirements to install Minikube:

  • 2 CPUs or more
  • 2GB of free memory
  • 20GB of free disk space
  • Internet connection
  • Container or virtual machine manager, such as: Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware Fusion/Workstation

So we download the latest stable release of Minikube from here. The installer is a simple install, and will display this screen once completed:

Now, we run an administrative PowerShell session, and run minikube start in order to start our cluster. Note that because I’m running on this on Windows 10, minikube automatically tried to create the cluster in Hyper-V. Therefore, I needed to run minikube start --driver=docker in order to force minikube to use docker to create the cluster.

So we can see from the output above that the cluster has been created successfully. And the eagle-eyed will also notice that we are using Kubernetes version 1.23.3, which is not the latest version. This is because Kubernetes no longer supports Docker as of version 1.24. Full support will be provided up to April 2023 for all versions up to 1.23 that run Docker. I’ve decided to base this build around Docker as I know it, but you can read more about the changes here and how they affect existing deployments here.

So we move on, and the first thing we need to do is install kubectl. You can download this directly by running minikube kubectl -- get po -A which will go off and install the appropriate version for your OS.

We can see that this has listed all of the Cluster services. We can also run minikube dashboard to launch a graphical view of all aspects of our Cluster:

Now that we’re up and running, lets do a sample webserver deployment. So we run the following commands (as we can see, the image is coming from gcr.io which is the Google Container Registry):

kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.4
kubectl expose deployment hello-minikube --type=NodePort --port=8080

Now lets run kubectl get services hello-minikube to check if the deployment is running:

And if we now look in the Dashboard, we can see that the deployment is running:

Now we can use kubectl port-forward service/hello-minikube 7080:8080 to expose the service on http://localhost:7080/, and when we browse to that we can see the metadata values returned:

And thats effectively it – your local cluster is running. You can try running another image from the Google Container Registry also, the full list of images can be found at the link here.

There are also a number of useful commands listed below that are useful to know when running minikube:

minikube pause – Pause Kubernetes without impacting deployed applications
minikube unpause – Unpause a paused instance
minikube stop – Halt the cluster
minikube config set memory 16384 – Increase the default memory limit (requires a restart)
minikube addons list – Browse the catalog of easily installed Kubernetes services
minikube start -p aged --kubernetes-version=v1.16.1 – Create a second cluster running an older Kubernetes release (this is potentially useful given Docker is no longer supported)
minikube delete --all – Delete all of the minikube clusters

You can find all of the information you need on Minikube including documentation and tutorials here at the official site.

Conclusion

So thats how we can run Kubernetes locally using Minikube. Slight change of plan, I’m going to do the Azure Kubernetes Service install in the next post, as we’ll go in-depth with that and look at the differences in architecture between running Kubernetes locally and in a Cloud Service.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 86: Introduction to Kubernetes

Its Day 86 of my 100 Days of Cloud journey, and in todays post I’m going to give an introduction to Kubernetes.

We introduced Containers on Day 81 and gave an overview of how they work and how they differ in architecture when compared to traditional Bare Metal Physical or Virtual Infrastructure. A container is a lightweight environment that can be used to build and securely run applications and their dependencies. We need container management tools such as Docker to run commands and manage our containers.

Image Credit – Jenny Fong/Docker

Containers Recap

We saw how easy it is to deploy and manage containers during the series where I built a monitoring system using a telegraf agent to pull data into an InfluxDB docker container, and then used a Grafana Container to display metrics from the time series database.

So lets get back to that for a minute and understand a few points about that system:

  • The Docker Host was an Ubuntu Server VM, so we can assume that it ran in a highly available environment – either an on-premises Virtual Cluster such as Hyper-V or VMware or on a Public Cloud VM such as an Azure Virtual Machine or an Amazon EC2 Instance.
  • It took data in from a single datasource, which was brought into a single time series database, which then was presented on a single dashboard.
  • So altogether we had 1 host VM and 2 containers. Because the containers and datasource were static, there was no need for scaling or complex management tasks. The containers were run with persistent storage configured, the underlying apps were configured and after that the system just happily ran.

So in effect, that was a static system that required very little or no management after creation. But we also had no means of scaling it if required.

What if we wanted to build something more complex, like a an application with multiple layers where there is a requirement to scale out apps, and respond to increased demand by deploying more container instances, and to scale back if demand is decreasing?

This is where container orchestration technologies are useful because they can handle this for you. A container orchestrator is a system that automatically deploys and manages containerized apps. It can dynamically respond to changes in the environment to increase or decrease the deployed instances of the managed app. Or, it can ensure all deployed container instances get updated if a new version of a service is released.

And this is where Kubernetes comes in!

Kubernetes Overview

Kubernetes is an open-source platform created by Google for managing and orchestrating containerized workloads. Kubernetes is also known as “K8s”, and can run any Linux container across private, public, and hybrid cloud environments. Kubernetes allows you to build application services that span multiple containers, schedule those containers across a cluster, scale those containers, and manage the health of those containers over time.

The benefits of using Kubernetes are:

Its important to note though that all of these tasks require configuration and a good understanding of the underlying technologies. You need to understand concepts such as virtual networks, load balancers, and reverse proxies to configure Kubernetes networking.

Kubernetes Components

Image Credit – Microsoft

A Kubernetes cluster consists of:

  • A set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
  • A master node or control plane manages the worker nodes and the Pods in the cluster

Lets take a look at the components that are contained in each of these components

Control Plane or Master Node

Image Credit – Microsoft

The following services make up the control plane for a Kubernetes cluster:

  • API server – the front end to the control plane in your Kubernetes cluster. All the communication between the components in Kubernetes is done through this API.
  • Backing store – used by Kubernetes to save the complete configuration of a Kubernetes cluster. A key-value store called etcd stores the current state and the desired state of all objects within your cluster.
  • Scheduler – responsible for the assignment of workloads across all nodes. The scheduler monitors the cluster for newly created containers, and assigns them to nodes.
  • Controller manager – tracks the state of objects in the cluster. There are controllers to monitor nodes, containers, and endpoints.
  • Cloud controller manage – integrates with the underlying cloud technologies in your cluster when the cluster is running in a cloud environment. These services can be load balancers, queues, and storage.

Worker Machines or Nodes

Image Credit – Microsoft

The following services run on the Kubernetes node:

  • Kubelet – The kubelet is the agent that runs on each node in the cluster, and monitors work requests from the API server. It monitors the nodes and makes sure that the containers scheduled on each node run, as expected.
  • Kube-proxy – The kube-proxy component is responsible for local cluster networking, and runs on each node. It ensures that each node has a unique IP address.
  • Container runtime – the underlying software that runs containers on a Kubernetes cluster. The runtime is responsible for fetching, starting, and stopping container images.

Pods

Image Credit – Microsoft

Unlike in a Docker environment, you can’t run containers directly on Kubernetes. You package the container into a Kubernetes object called a pod, which is effectively a container with all of the management overhead stripped away and passed back to the Kubernetes Cluster.

A pod can contain multiple containers that make up part of or all of your application, however in general a pod will never contain multiple instances of the same application. So for example, if running a website that requires a database back-end, both of those containers would be packaged into a pod.

A pod also includes information about the shared storage and network configuration, and yaml coded tempates which define how to run the containers in the pod.

Managing your Kubernetes environment

You have a number of options for managing your Kubernetes environment:

  • kubectl – You can use kubectl to deploy applications, inspect and manage cluster resources, and view logs. kubectl can be installed on Linux, macOS and Windows platforms.
  • kind – this is used for running Kubernetes on your local device.
  • minikube – similar to kind in that it allows you to run Kubernetes locally.
  • kubeadm – this is used to create and manage kubernetes clusters in a user friendly way.

kubectl is by far the most used in enterprise Kubernetes environments, and you can find more details in the documentation here.

Important Considerations

While Kubernetes provides an orchestration platform that means you can run your clusters and scale as required, there are certain things you need to be aware that it cannot do, such as:

  • Deployment, scaling, load balancing, logging, and monitoring are all optional. You need to configure these and fit these into your specific solution requirements.
  • There is no limit to the tyes of apps that can run – if it can run in a container, it can run on Kubernetes.
  • Kubernetes doesn’t provide middleware, data-processing frameworks, databases, caches, or cluster storage systems.
  • A container runtime such as Docker is required for managing containers.
  • You need to manage the underlying environment that Kubernetes runs on (memory, networking, storage etc), and also manage upgrades to the Kubernetes platform itself.

Azure Kubernetes Service

All of the above considerations and indeed all of the sections we’ve covered in this post require detailed knowledge of both Kubernetes and also the underlying dependencies. This overhead is removed in some part by cloud services such Azure Kubernetes Service (AKS) which reduces these challenges by providing a hosted Kubernetes environment. 

As a hosted Kubernetes service, Azure handles critical tasks, like health monitoring and maintenance. Since Kubernetes masters are managed by Azure, you only manage and maintain the agent nodes.

You can create an AKS cluster using:

  • The Azure CLI
  • The Azure portal
  • Azure PowerShell
  • Using template-driven deployment options, like Azure Resource Manager templates, Bicep and Terraform.

When you deploy an AKS cluster, the Kubernetes master and all nodes are deployed and configured for you. Advanced networking, Azure Active Directory (Azure AD) integration, monitoring, and other features can be configured during the deployment process.

Conclusion

And thats a description of Kubernetes, how it works, why its useful and the components that are contained within it. In the next post, we’re going to put all that theory into practice and set up both a local Kubernetes Cluster using minikube, and also look at deploying cluster onto Azure Kubernetes Service.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 85: Security for Azure Containers

Its Day 85 of my 100 Days of Cloud journey, and in todays post I’m looking at the options for Container Security in Azure.

Image Credit: Docker Saigon Github

We looked at an overview of Containers on Day 81, how they work like a virtual machines in that they utilize the underlying resources offered by the Container Host, but instead of packaging your code with an Operating System, each container only contains the code and dependencies needed to run the application and runs as a process inside the OS Kernel. This means that containers are smaller and more portable, and much faster to deploy and run.

We need to secure Containers in the same way as we would any other services running on the Public Cloud. Lets take a look at the different options that are available to us for securing Containers.

Use a Private registry

Containers are built from images that are stored in either public repositories such as Docker Hub, a private registry such as Docker Trusted Registry, which can be installed on-premises or in a virtual private cloud, or a cloud-based private registry such as Azure Container Registry.

Like all software that is publicly available on the internet, a publicly available container image does not guarantee security. Container images consist of multiple software layers, and each software layer might have vulnerabilities.

To help reduce the threat of attacks, you should store and retrieve images from a private registry, such as Azure Container Registry or Docker Trusted Registry. In addition to providing a managed private registry, Azure Container Registry supports service principal-based authentication through Azure Active Directory for basic authentication flows. This authentication includes role-based access for read-only (pull), write (push), and other permissions.

Ensure that only approved images are used in your environment

Allow only approved container images. Have tools and processes in place to monitor for and prevent the use of unapproved container images. One option is to control the flow of container images into your development environment. For example, you only allow a single approved Linux distribution as a base image in order to minimize the surface for potential attacks.

Another option is to utilize Azure Container Registry support for Docker’s content trust model, which allows image publishers to sign images that are pushed to a registry, and image consumers to pull only signed images.

Monitoring and Scanning Images

Use solutions that have the ability to scan container images in a private registry and identify potential vulnerabilities. Azure Container Registry optionally integrates with Microsoft Defender for Cloud to automatically scan all Linux images pushed to a registry to detect image vulnerabilities, classify them, and provide remediation guidance.

Credentials

Credential management is one of the most basic tyes of security. Because containers can spread across several clusters and Azure regions, you need to ensure that you have secure credentials required for logins or API access, such as passwords or tokens.

Using tools such as TLS encryption for secrets data in transit, least-privilege Azure role-based access control (Azure RBAC), and Azure Key Vault to securely store encryption keys and secrets (such as certificates, connection strings, and passwords) for containerized applications.

Removing unneeded privileges from Containers

You can also minimize the potential attack surface by removing any unused or unnecessary processes or privileges from the container runtime. Privileged containers run as root. If a malicious user or workload escapes in a privileged container, the container will then run as root on that system.

Enable Auditing Logging for all Container administrative user access

Use native Azure Solutions to maintain an accurate audit trail of administrative access to your container ecosystem. These logs might be necessary for auditing purposes and will be useful as forensic evidence after any security incident. Azure solutions include:

  • Integration of Azure Kubernetes Service with Microsoft Defender for Cloud to monitor the security configuration of the cluster environment and generate security recommendations
  • Azure Container Monitoring solution
  • Resource logs for Azure Container Instances and Azure Container Registry

Conclusion

So thats a brief overview of how we can secure containers running in Azure and ensure that we are only using approved images that have been scanned for vulnerabilities.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 82: Options for Managing Containers in Azure

Its Day 82 of my 100 Days of Cloud journey, and in todays post I’m going to look at options for managing Containers in Azure.

In the last post, we looked at the comparison between Bare Metal or Physical Servers, Virtual Servers and Containers and the pros and cons of each.

We also introducted Docker, which is the best known method of managing containers using the Docker Engine and built-in Docker CLI for command management.

The one thing we didn’t show was how to install Docker or use any of the commands to manage our containers. This is because I’ve previously blogged about this and you can find all of the details as part of my series about Monitoring with Grafana and InfluxDB using Docker Containers. Part 1 shows how you can create your Docker Host running on an Ubuntu Server VM (this could also run on a Bare Metal Physical Server), and Part 2 shows the setup and configuration of Docker Containers that have been pulled from Docker Hub. So head over there and check that out, but don’t forget to come back here!

Docker Context

By default when running any Docker commands from the CLI, Docker automatically assumes that you wish to use the local Docker Host for storing and running your containers. However, you can manage multiple Docker or Kubernetes hosts or nodes by specifying contexts. A single Docker CLI can have multiple contexts. Each context contains all of the endpoint and security information required to manage a different cluster or node. The docker context command makes it easy to configure these contexts and switch between them.

In short, this means that you can manage container instances that are installed on multiple hosts and/or multiple cloud providers from a single Docker CLI.

Let take a look at the different options for managing containers in Azure.

The Docker CLI Method

In order to use containers in Azure using Docker, we first need to log on to Azure using the docker login azure command, which will prompt us for Azure credentials. Once entered, this will return “login succeeded”:

We then need to create a context by running the docker context create aci command. This will associate Docker with an Azure subscription and resource group that you can use to create and manage container instances. So we would run docker context create aci myacicontext to create a context called myacicontext.

This will select your Azure subscription ID, then prompt to select an existing resource group or create a new resource group. If you choose a new resource group, it’s created with a system-generated name. Like all Azure resources, Azure container instances must be deployed into a resource group

Once thats completed, we then run docker context use myacicontext – this ensures that any subsequent commands will run in this context. We can now use docker run to deploy containers into our Azure resource group and manage these using the Azure CLI. So lets run the following command to deploy a quickstart container runing Node.js that will give us a static website:

docker run -p 80:80 mcr.microsoft.com/azuredocs/aci-helloworld

We can now run docker ps to see the running container and get the Public IP that we can use to browse to it:

And if we log onto the Portal, we can see our running container:

So as we’ve always done, lets remember to remove the container by running docker stop sweet-chatterjee, and then docker rm sweet-chatterjee. These commands stops and deletes the Azure Container Instance:

Finally, run docker ps to ensure the container has stopped and is no longer running.

The Azure Portal Method

There are multiple ways to create and manage containers natively in Azure. We’ll look at the portal method in this post, and reference the remaining options at the end of the page.

To create the container, log on to the Portal and select Container Instances from the Marketplace:

Once we select create, we are brought into the now familiar screen for creating resources in Azure:

One important thing to note on this screen is the “Image Source” option – we can select container images from either:

  • The quickstarts that are available in Azure.
  • Images stored in your Azure Container Registry.
  • Other registry – this can be Docker or other public or private container registry.

On the “Networking” screen, we need to specify a public DNS name for our container, and also the ports we wish to expose across the Public Internet

And once thats done, we click “Review and Create” to deploy our container:

Once thats done, we can see the FQDN or Public IP that we can use to browse to the container:

As always, make sure to stop and delete the container instance once finished if you are running these in a test environment.

There are a total of four other options in Azuire for creating and managing containers:

Conclusion

So thats a look at how we can create and manage Azure Container Instances using both Docker CLI and the wide range of options available in Azure.

Azure Container Instances is a great solution for any scenario that can operate in isolated containers, including simple applications, task automation, and build jobs. You can find all of the documentation on Azure Container Instances here.

Hope you enjoyed this post, until next time!

100 Days of Cloud – Day 81: Introduction to Containers

Its Day 81 of my 100 Days of Cloud journey, and in todays post I’m going to attempt to give an introduction to containers.

Containers. But not the sort we’re going to talk about…..

I’m building up to look at Kubernetes in later posts but as the saying goes “we need to walk before we can run”, so its important before we dive into container orchestration that we understand the fundamentals of containers.

Containers v Virtualization

Lets start with the comparison that we all make and compare the differences between containers and virtualization. Before that though, lets reverse even further into the mists of time……

  • Bare Metal or Physical Servers
Image Credit – Rick Vanover/Veeam Software

Back in the “good old days” (were they really that good?), you needed a Physical Server to run each one of your applications (or if you were really brave, you ran multiple applictions on a single server). These were normally large noisy beasts that took up half a rack in your datacenter. You had a single operating system per machine, and any recovery in general took time as the system needed to be rebuilt in full up to the application layer before any data recovery was performed.

  • Virtualization
Image Credit – Rick Vanover/Veeam Software

As processing power and capacity increased, applications running on physical servers were unable to utilise the increased resources available, which left a lot of wasted resources left unused. At this point, Virtualization enabled us to install a hypervisor which ran on the physical servers. This allowed us to create Virtual Machines that ran alongside each other on the physical hardware.

Each VM can run its own unique guest operating system, and different VMs running on the same hypervisor can run different OS versions and versions. The hypervisor assigns resources to that VM from the underlying Physical resource pool based on either static values or dynamic values which would scale up or down based on the resource demands.

The main benefits that virtualization gives:

  1. The ability to consolidate applications onto a single system, which gave huge cost savings.
  2. Reduced datacenter footprint.
  3. Faster Server provisioning and improved backup and disaster recovery timelines.
  4. In the development lifecycle, where as opposed to another monster server being purchased and configured, a VM could be quickly spun up which mirrored the Production environment and could be used for the different stages of the development process (Dev/QA/Testing etc).

There are drawbacks though, and the main ones are:

  1. Each VM has separate OS, Memory and CPU resources assigned which adds to resource overhead and storage footprint. So all of that spare capacity we talked about above gets used very quickly.
  2. Although we talked about the advantage of having separate environments for the development lifecycle, the portability of these applications between the different stages of the lifecycle is limited in most cases to the backup and restore method.
  • Containers
Image Credit – Jenny Fong/Docker

Finally, we get to the latest evolution of compute which is Containers. A container is a lightweight environment that can be used to build and securely run applications and their dependencies.

A container works like a virtual machine in that it utilizes the underlying resources offered by the Container Host, but instead of packaging your code with an Operating System, each container only contains the code and dependencies needed to run the application and runs as a process inside the OS Kernel. This means that containers are smaller and more portable, and much faster to deploy and run.

So how do I run Containers?

In On-Premise and test environments, Windows Containers ships on the majority of Windows Client and Server Operating Systems as a built-in feature that is available to use. However, for the majority of people who use containers, Docker is the platform of choice.

Docker is a containerization platform used to develop, ship, and run containers. It doesn’t use a hypervisor, and you can run Docker on your desktop or laptop if you’re developing and testing applications.

The desktop version of Docker supports Linux, Windows, and macOS. For production systems, Docker is available for server environments, including many variants of Linux and Microsoft Windows Server 2016 and above.

When you install Docker on either your Linux or Windows environment, this installs the Docker Engine which contains:

  • Docker client – command-line application named docker that provides us with a CLI to interact with a Docker server. The docker command uses the Docker REST API to send instructions to either a local or remote server and functions as the primary interface we use to manage our containers.
  • Docker server – The dockerd daemon responds to requests from the client via the Docker REST API and can interact with other daemons. The Docker server is also responsible for tracking the lifecycle of our containers.
  • Docker objects – there are several objects that you’ll create and configure to support your container deployments. These include networks, storage volumes, plugins, and other service objects. We’ll take a look at these in the next post when we demo the setup of Docker.

So where do I get the Containers from?

Docker provides the worlds largest respository of container images called Docker Hub. This is a public repository and contains ready made containers from both official vendors (such as WordPress, MongoDB, MariaDB, InfluxDB, Grafana, Jenkins, Tomcat, Apache Server) and also bespoke containers that have been been contributed by developers all over the world.

So there is effectively a Docker Container for every available scenario. And if you need to create one for your own scenario, you just pull the version from the Docker Hub, make your changes and push it back up to Docker Hub and mark it as public and available for use.

But what if I don’t want to store my container images in a public registry?

Thats where the Private Container Registry option comes in. Your organization or team can have access to a private registry where you can store images that are in use in your environment. This is particularly useful when you want to have version control and governance over what images you want to use in your environment.

For example, if you want to run InfluxDB and run the command to pull the InfluxDB container from the Docker Hub, by default you will get the latest stable version (which is 2.2). However, your application may need to use or only support version 1.8, so you need to specify that when pulling from the registry.

Because images are pulled from the Docker Hub by default, you need to specify the location of your Private Container Registry (in https notation) when pulling images.

There are a number of different options for where to store your Private Container Registry:

  • Docker Hub allows companies to host directly
  • Azure Container Registry
  • Amazon Elastic Container Registry
  • Google Container Registry
  • IBM Container Registry

Conclusion

So thats a brief overview of containers and how Docker is the proprietary software in use for managing them. In the next post, we’ll look at setting up a Docker Host machine and creating an Azure Container Registry to house our private Docker Images.

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 https://admin.microsoft.com/ 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 2.1.1.0 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.

Conclusion

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!