Microsoft’s Name Change Game: Azure AD to Microsoft Entra ID Explained!

Featured

Entra ID

In the dynamic world of technology, change is the only constant. Microsoft, an industry leader, is known for its constant innovation. The most recent change in the company’s lineup is rebranding Azure Active Directory (Azure AD) to Microsoft Entra ID. This move is a shift in the company’s direction and, as with any change, has sparked questions and speculation. This blog post explores this change, its reasons, and what we can expect from Microsoft Entra ID.

Microsoft’s Name Change Game: Azure AD to Microsoft Entra ID

Microsoft has always had a flair for naming its products uniquely yet simplistically. Azure AD, the cloud-based identity and access management service, is now being rebranded as Microsoft Entra ID. This change is not just about a new name; it’s also about Microsoft’s vision for the future of its identity services. They want the name to reflect the product’s purpose and function. Azure AD has been a significant player in the Microsoft ecosystem, providing seamless access control and identity protection across various applications and services.

The change from Azure AD to Microsoft Entra ID is not a decision taken lightly. It represents a strategic shift in Microsoft’s identity services space. As Microsoft continues to make strides in the cloud computing, they have decided that rebranding Azure AD to Microsoft Entra ID will better align with their future roadmap. This shift also comes with an expanded vision for the product to provide a more secure and efficient identity management solution for Microsoft’s users.

Why is Microsoft changing the name of Azure AD to Microsoft Entra ID?

Microsoft’s decision to rebrand Azure AD to Microsoft Entra ID seems to stem from a desire to make the product’s function more evident in its name. Azure AD is often mistaken for a directory service in the cloud, which it is not. It is an identity and access management service. The new name, Microsoft Entra ID, is meant to reflect this better. Entra, derived from ‘entrance,’ and ID, short for ‘identity,’ gets straight to the point – it’s all about managing identities and access.

Moreover, Microsoft is also looking to restrict its identity services from Azure. Despite the name, Azure AD isn’t tied solely to Microsoft Azure but is used across many Microsoft services. The name change to Microsoft Entra ID is intended to remove this confusion and highlight that the service is a standalone product that functions across all Microsoft services, not just Azure.

Unveiling Microsoft Entra ID: What to expect from Microsoft’s rebranding

With the unveiling of Microsoft Entra ID, Microsoft is introducing a more intuitive, efficient, and secure identity management service. Microsoft promises that this rebranding comes with enhancements that will provide a seamless experience to its users. Microsoft Entra ID’s primary goal remains the same as Azure AD’s: to provide secure and reliable access control over various applications and services.

In addition, Microsoft is also planning to introduce new features and improvements in Microsoft Entra ID. While the details are still under wraps, we can expect a more streamlined identity management service designed to meet the changing needs of businesses and individuals. The essence of the tool remains the same, but with a fresh look, a clearer purpose, and hopefully, a more powerful punch.

Microsoft’s rebranding of Azure AD to Microsoft Entra ID represents an evolution in its identity and access management services. This change, whilst initially seeming simply cosmetic, is a strategic move that aligns with Microsoft’s vision for the future of its identity services. While change can sometimes be daunting, this shift from Azure AD to Microsoft Entra ID is much more than a mere name change. It is a promise of a better, more efficient, and more streamlined service that aims to meet the changing demands of identity management in the ever-evolving landscape of cloud computing. As I dive more into Entra ID and understand its roadmap, I will publish an updated post.

Until next time,

Rob

Azure Site Recovery – An overview

Featured

Azure Site RecoveryAzure Site Recovery (ASR) is a powerful disaster recovery and business continuity solution provided by Microsoft Azure. It enables businesses to keep their critical applications and services up and running in the event of unexpected downtime, disasters, or disruptions. With ASR, you can replicate your on-premises virtual machines, physical servers, and even entire data centers to Azure, and quickly restore them when needed.

In this blog post, we will dive deep into the capabilities, benefits, and use cases of Azure Site Recovery. We will also explore the key features, architecture, and pricing model of ASR.

Capabilities of Azure Site Recovery

Azure Site Recovery provides a range of capabilities that can help businesses ensure high availability, data protection, and disaster recovery. Here are some of the key capabilities of ASR:

  1. Replication: ASR can replicate virtual machines, physical servers, and even entire data centers to Azure. This enables businesses to keep their critical applications and services up and running in the event of unexpected downtime, disasters, or disruptions.
  2. Orchestration: ASR can orchestrate the failover and failback of replicated virtual machines and servers. This ensures that the entire failover process is automated, orchestrated, and monitored.
  3. Testing: ASR provides a non-disruptive way to test disaster recovery scenarios without impacting the production environment. This enables businesses to validate their disaster recovery plans and ensure that they are working as expected.
  4. Integration: ASR integrates with a range of Azure services, including Azure Backup, Azure Monitor, Azure Automation, and Azure Security Center. This enables businesses to have a holistic view of their disaster recovery and business continuity operations.

Benefits of Azure Site Recovery

Azure Site Recovery provides a range of benefits to businesses of all sizes and industries. Here are some of the key benefits of ASR:

  1. High availability: ASR enables businesses to achieve high availability of their critical applications and services. This ensures that their customers and employees have access to the applications and services they need, even in the event of unexpected downtime, disasters, or disruptions.
  2. Data protection: ASR ensures that data is protected and can be recovered in the event of data loss or corruption. This is essential for businesses that handle sensitive data or have compliance requirements.
  3. Reduced downtime: ASR can help businesses reduce downtime by providing a fast and efficient way to recover from disasters or disruptions. This can save businesses a significant amount of time, money, and resources.
  4. Simplified disaster recovery: ASR simplifies the disaster recovery process by automating failover and failback operations. This reduces the risk of human error and ensures that the entire process is orchestrated and monitored.
  5. Lower costs: ASR can help businesses reduce their disaster recovery costs by eliminating the need for expensive hardware and infrastructure. This is because businesses can replicate their virtual machines and servers to Azure, which provides a cost-effective disaster recovery solution.

Use cases for Azure Site Recovery

  • Business Continuity: ASR can help businesses ensure business continuity by providing a way to keep their critical applications and services up and running in the event of unexpected downtime, disasters, or disruptions. With ASR, businesses can replicate their on-premises virtual machines and servers to Azure and failover to them in the event of a disaster.
  • Data Protection: ASR can help businesses protect their data by replicating it to Azure and providing a way to recover it in the event of data loss or corruption. With ASR, businesses can set up a replication policy to replicate data to Azure and configure recovery points to restore data to a specific point in time.
  • Migration: ASR can be used to migrate virtual machines and servers from on-premises to Azure. With ASR, businesses can replicate their on-premises workloads to Azure and then failover to the replicated virtual machines in Azure. This can help businesses move their workloads to Azure in a seamless and efficient manner.
  • Testing: ASR provides a non-disruptive way to test disaster recovery scenarios without impacting the production environment. With ASR, businesses can test their disaster recovery plans and ensure that they are working as expected without interrupting their production environment.
  • DevOps: ASR can be used in DevOps scenarios to replicate development and test environments to Azure. This can help businesses reduce the time and cost of setting up and managing these environments. With ASR, businesses can replicate their development and test environments to Azure and then failover to them when needed.
  • Compliance: ASR can help businesses meet compliance requirements by ensuring that their data is protected and can be recovered in the event of data loss or corruption. With ASR, businesses can replicate their data to Azure and then configure recovery points to ensure that their data can be restored to a specific point in time.
  • Hybrid Cloud: ASR can be used in hybrid cloud scenarios to ensure high availability and disaster recovery across on-premises and Azure environments. With ASR, businesses can replicate their on-premises workloads to Azure and then failover to them in the event of a disaster.
  • Multi-Site Disaster Recovery: ASR can be used to provide disaster recovery across multiple sites. With ASR, businesses can replicate their virtual machines and servers to multiple Azure regions and then failover to the replicated virtual machines in the event of a disaster.

In summary, Azure Site Recovery provides a range of capabilities that can help businesses ensure high availability, data protection, and disaster recovery. It can be used in a wide range of use cases across different industries to provide a cost-effective and efficient disaster recovery solution.

Until next time,

Rob

Azure Sentinel: The Future of Security Information and Event Management

Azure SentinelIn today’s digital world, protecting an organization’s information and assets from cyber threats has never been more critical. The rise in cyber attacks and security breaches has made it crucial for organizations to have a centralized platform to manage their security operations and respond to incidents promptly and effectively. That’s where Azure Sentinel comes in.

Azure Sentinel is a cloud-native Security Information and Event Management (SIEM) solution provided by Microsoft Azure. It provides a comprehensive security solution that integrates with existing security tools and cloud services to provide a complete view of an organization’s security landscape. Azure Sentinel is designed to help organizations quickly detect, investigate and respond to security threats and streamline their security operations.

Azure Sentinel Core

One of the key benefits of Azure Sentinel is its ability to provide a unified view of security events from various sources. It can collect data from on-premises, cloud, and hybrid environments and a wide range of security tools and services. This data is then aggregated and analyzed in real-time to provide organizations with a complete picture of their security posture. Azure Sentinel also uses machine learning algorithms to identify patterns and anomalies and to detect threats that might have gone unnoticed.

Another essential feature of Azure Sentinel is its ability to automate security workflows. It provides a flexible and powerful security automation and orchestration platform that enables organizations to respond to incidents quickly and effectively. Azure Sentinel provides built-in playbooks and pre-configured security workflows that specific events or conditions can trigger. Organizations can also create custom playbooks to automate their security operations.

In addition to its capabilities, Azure Sentinel is highly scalable, allowing organizations to manage security operations at any scale. It is built on Microsoft Azure, which provides a highly scalable, secure, and reliable platform for security operations. Azure Sentinel is also designed to be cost-effective, providing organizations with a cost-effective solution for managing their security operations without significant investments in hardware or software.

In conclusion, Azure Sentinel provides organizations with a comprehensive and centralized security solution that integrates with existing security tools and cloud services to provide a complete view of an organization’s security landscape. With its ability to detect and respond to threats quickly and effectively, automate security workflows, and provide a cost-effective solution, Azure Sentinel is the future of SIEM. Azure Sentinel is a solution worth considering if you’re looking to enhance your security posture and streamline your security operations.

Until next time, Rob

Azure Powershell – How to Build and Deploy Azure IaaS VMs

Throughout my career, my primary role has always been to make things more efficient and automated.  And now more than ever, automation is needed to manage and deploy IT services at scale to support our ever-changing needs.

In my opinion, one of the most convenient aspects of public cloud-based services is the ability to host virtual machines (VMs). Hosting VMs in the cloud doesn’t just mean putting your VMs in someone else’s datacenter. It’s a way to achieve a scalable, low-cost and resilient infrastructure in a matter of minutes.

What once required hardware purchases, layers of management approval and weeks of work now can be done with no hardware and in a fraction of the time. We still probably have those management layers though 🙁

Microsoft Azure is in the lead pack along with Google (GCP) and Amazon (AWS). Azure has made great strides over the past few years on in its Infrastructure as a Service (IaaS) service which allows you to host VMs in their cloud.

Azure provides a few different ways to build and deploy VMs in Azure.

  • You could choose to use the Azure portal, build VMs through Azure Resource Manager(ARM) templates and some PowerShell
  • Or you could simply use a set of PowerShell cmdlets to provision a VM and all its components from scratch.

Each has its advantages and drawbacks. However, the main reason to use PowerShell is for automation tasks. If you’re working on automated VM provisioning for various purposes, PowerShell is the way to go 😉

Let’s look at how we can use PowerShell to build all of the various components that a particular VM requires in Azure to eventually come up with a fully-functioning Azure VM.

To get started, you’ll first obviously need an Azure subscription. If you don’t, you can sign up for a free trial to start playing around. Once you have a subscription, I’m also going to be assuming you’re using at least Windows 10 with PowerShell version 6. Even though the commands I’ll be showing you might work fine on older versions of PowerShell, it’s always a good idea to work alongside me with the same version, if possible.

You’ll also need to have the Azure PowerShell module installed. This module contains hundreds of various cmdlets and sub-modules. The one we’ll be focusing on is called Azure.RM. This contains all of the cmdlets we’ll need to provision a VM in Azure.

Building a VM in Azure isn’t quite as simple as New-AzureVM; far from it actually. Granted, you might already have much of the underlying infrastructure required for a VM, but how do you build it out, I’ll be going over how to build every component necessary and will be assuming you’re beginning to work from a blank Azure subscription.

At its most basic, an ARM VM requires eight individual components

  1. A resource group
  2. A virtual network (VNET)
  3. A storage account
  4. A network interface with private IP on VNET
  5. A public IP address (if you need to access it from the Internet)
  6. An operating system
  7. An operating system disk
  8. The VM itself (compute)

In order to build any components between numbers 2 and 7, they must all reside in a resource group so we’ll need to build this first. We can then use it to place all the other components in. To create a resource group, we’ll use the New-AzureRmResourceGroup cmdlet. You can see below that I’m creating a resource group called NetWatchRG and placing it in the East US datacenter.

New-AzureRmResourceGroup -Name 'NetWatchRG' -Location 'East US'

Next, I’ll build the networking that is required for our VM. This requires both creating a virtual subnet and adding that to a virtual network. I’ll first build the subnet where I’ll assign my VM an IP address dynamically in the 10.0.1.0/24 network when it gets built.

$newSubnetParams = @{
'Name' = 'NetWatchSubnet'
'AddressPrefix' = '10.0.1.0/24'
}
$subnet = New-AzureRmVirtualNetworkSubnetConfig @newSubnetParams

Next, I’ll create my virtual network and place it in the resource group I just built. You’ll notice that the subnet’s network is a slice of the virtual network (my virtual network is a /16 while my subnet is a /24). This allows me to segment out my VMs

$newVNetParams = @{
'Name' = 'NetWatchNetwork'
'ResourceGroupName' = 'MyResourceGroup'
'Location' = 'West US'
'AddressPrefix' = '10.0.0.0/16'
'Subnet' = $subnet
}
$vNet = New-AzureRmVirtualNetwork @newVNetParams

Next, we’ll need somewhere to store the VM so we’ll need to build a storage account. You can see below that I’m building a storage account called NetWatchSA.

$newStorageAcctParams = @{
'Name' = 'NetWatchSA'
'ResourceGroupName' = 'NetWatchRG'
'Type' = 'Standard_LRS'
'Location' = 'East US'
}
$storageAccount = New-AzureRmStorageAccount @newStorageAcctParams

Once the storage account is built, I’ll now focus on building the public IP address. This is not required but if you’re just testing things out now it’s probably easiest to simply access your VM over the Internet rather than having to worry about setting up a VPN.

Here I’m calling it NetWatchPublicIP and I’m ensuring that it’s dynamic since I don’t care what the public IP address is. I’m using many of the same parameters as the other objects as well.

$newPublicIpParams = @{'Name' = 'NetWatchPublicIP''ResourceGroupName' = 'NetWatchRG''AllocationMethod' = 'Dynamic' ## Dynamic or Static'DomainNameLabel' = 'NETWATCHVM1''Location' = 'East US'}$publicIp = New-AzureRmPublicIpAddress @newPublicIpParams
Once the public IP address is created, I then need somehow to get connected to my virtual network and ultimately the Internet. I’ll create a network interface again using the same resource group and location again. You can also see how I’m slowly building all of the objects I need as I go along. Here I’m specifying the subnet ID I created earlier and the public IP address I just created. Each step requires objects from the previous steps.
$newVNicParams = @{
'Name' = 'NetWatchNic1'
'ResourceGroupName' = 'NetWatchRG'
'Location' = 'East US'
'SubnetId' = $vNet.Subnets[0].Id
'PublicIpAddressId' = $publicIp.Id
}
$vNic = New-AzureRmNetworkInterface @newVNicParams
Once we’ve got the underlying infrastructure defined, it’s now time to build the VM.
First, you’ll need to define the performance of the VM. Here I’m choosing the lowest performance option (and the cheapest) with a Standard A3. This is great for testing but might not be enough performance for your production environment.
$newConfigParams = @{
'VMName' = 'NETWATCHVM1'
'VMSize' = 'Standard_A3'
}
$vmConfig = New-AzureRmVMConfig @newConfigParams
Next, we need to create the OS itself. Here I’m specifying that I need a Windows VM, the name it will be, the password for the local administrator account and a couple of other Azure-specific parameters. However, by default, an Azure VM agent is installed anyway but does not automatically update itself. You don’t explicitly need a VM agent but it will come in handy if you begin to need more advanced automation capabilities down the road.
$newVmOsParams = @{
'Windows' = $true
'ComputerName' = 'NETWATCHVM1'
'Credential' = (Get-Credential -Message 'Type the name and password of the local administrator account.')
'ProvisionVMAgent' = $true
'EnableAutoUpdate' = $true
}
$vm = Set-AzureRmVMOperatingSystem @newVmOsParams -VM $vmConfig
Next, we need to pick what image our OS will come from. Here I’m picking Windows Server 2016 Datacenter with the latest patches. This will pick an image from the Azure image gallery to be used for our VM.
$newSourceImageParams = @{
'PublisherName' = 'MicrosoftWindowsServer'
'Version' = 'latest'
'Skus' = '2016-Datacenter'
'VM' = $vm
}$offer = Get-AzureRmVMImageOffer -Location 'East US' -PublisherName 'MicrosoftWindowsServer'
$vm = Set-AzureRmVMSourceImage @newSourceImageParams -Offer $offer.Offer
Next, we’ll attach the NIC we’ve built earlier to the VM and specify the NIC ID on the VM that we’d like to add it as in case we need to add more NICs later.
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $vNic.Id
At this point, Azure still doesn’t know how you’d like the disk configuration on your VM. To define where the operating system will be stored, you’ll need to create an OS disk. The OS disk is a VHD that’s stored in your storage account. Here I’m putting the VHD in a VHDs storage container (folder) in Azure. This step gets a little convoluted since we must specify the VhdUri. This is the URI to the storage account we created earlier.
$osDiskUri = $storageAcct.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName + $osDiskName + ".vhd"

$newOsDiskParams = @{
'Name' = 'OSDisk'
'CreateOption' = 'fromImage'
'VM' = $vm
'VhdUri' = $osDiskUri
}

$vm = Set-AzureRmVMOSDisk @newOsDiskParams
Ok, Whew! We now have all the components required to finally bring up our VM. To build the actual VM, we’ll use the New-AzureRmVM cmdlet. Since we’ve already done all of the hard work ahead of time, at this point, I simply need to pass the resource group name, the location, and the VM object which contains all of the configurations we just applied to it.
$newVmParams = @{
'ResourceGroupName' = 'NetWatchRG'
'Location' = 'East US'
'VM' = $vm
}
New-AzureRmVM @newVmParams

Your VM should now be showing up under the Virtual Machines section in the Azure portal. If you’d like to check on the VM from PowerShell you can also use the Get-AzureRmVM cmdlet.

Now that you’ve got all the basic code required to build a VM in Azure, I suggest you go and build a PowerShell script from this tutorial. Once you’re able to bring this code together into a script, building your second, third or tenth VM will be a breeze!

One final tip, in addition to managing Azure Portal through a browser, there are mobile apps for IOS and Android and now the new Azure portal app (Currently in Preview).  It gives you the same experience as the Azure Portal, without the need of a browser, like Microsoft Edge or Google Chrome.  Great for environments that have restrictions on browsing.

Until next time, Rob…

Azure Active Directory, Active Directory Domain Services – What’s the difference?

Here is a subject I hear and get asked over and over again.  Is Azure Active Directory (AAD) the same as Active Directory Domain Services (AD DS).

Let me be very clear.  Azure Active Directory is NOT a cloud version of Active Directory Domain Services, and in fact, it bears minimal resemblance to its on-premises names at all.

The number one question I get asked: “How do I join my servers to Azure AD?”. IT admins expect (not unexpectedly) to be able to use Azure AD just like they have always used Active Directory Domain Services. So let’s compare AD DS (and particularly the domain services part of AD DS) to AAD.  Let me educate you 🙂

What is Active Directory?

Most of us have probably worked with it for years, and now you’re looking to move to the cloud and understand what AAD is. Let’s start with a recap of what AD DS is. 

Active Directory Domain Services was introduced as a hierarchical authentication and authorization database system to replace the flat file Domain system in use on NT4 and previous servers.

The NT4 domain model in 2000 was straining at the seams to keep up with evolving corporate structures, hampered by some quite severe limitations – maximum of 26,000 objects in a flat file “bucket”, only 5 kinds of fixed objects whose structure (properties etc.) could not be changed, maximum size of the database of 40Mb etc. NT4 Domains also primarily used NetBIOS (another flat file, Microsoft specific system) for its name resolution.

For a lot of larger organizations, this necessitated multiple domain databases with very limited and complicated interactions between those domains. Active Directory Domain Services (just called Active Directory in those days) was released with Windows Server 2000 and was based upon the X.500 hierarchical network standard that companies such as Novel’s NDS and Banyan Vines were using at the time.

AD DS also used DNS as its name resolution system and the TCP/IP communication protocols in use on the internet. It brought in the idea of a directory system which contained a “schema” database (the set of “rules” that define the properties or attributes of objects created in the “domain” database) which could be added to or “extended” to create either entirely new objects or new properties of existing objects.

Size limitations were also thrown out the window, with Microsoft creating directory systems in the billions of objects (given enough storage!) in their test labs.

Here is a list of the essential functions that make up AD DS:

  • Secure Object store, including Users, Computers and Groups
  • Object organization use OU’s, Domains and Forests
  • Common Authentication and Authorization provider
  • LDAP, NTLM, Kerberos
  • Group Policy
  • Customizable Schema

Along with Domain Services, there are also components like Certificate Services, Federation Services, and Privileged Access Management.

From its inception, AD DS quickly became the defacto directory system in most organizations, even today.

What is Azure Active Directory

So if you know what Active Directory Domain Services is, then how does this compare to Azure Active Directory? The answer to this is, not very closely. The decision to name AAD after AD, in my opinion, was more of a marketing decision than a technical one. This has lead to years of confusion. In many ways, AAD was designed for a world where PaaS and SaaS services were the default choice, not for IaaS in the cloud.

Azure Active Directory is a secure authentication store, which can contain users and groups, but that is about where the similarities end. AAD is a cloud-based identity management store for modern applications. AAD is designed to allow you to create users, groups, and applications that work with modern authentication mechanisms like SAML and OAuth.

Applications are an object that exists in AAD but not in AD DS. Applications allow you to create an identity for your applications that you can grant access for users to, and to allow you to grant your users access to applications owned by others.

What AAD does not provide is any AD DS service beyond user management.

  • You can’t join computers to an Azure AD domain in the way you would with AD DS. There is something called Azure AD Join, but this is a different animal that I’ll address below. This means there are no computer objects in your AAD to apply things like GPOs to, and no centralized control of user rights on those machines.
  • There is no Group Policy. AAD has some policy tools like conditional access, but it is more focused on access to applications.
  • No support for LDAP, directory queries all use the REST API, Graph or PowerShell/CLI
  • There’s no support for NTLM or Kerberos. AAD is modern authentication protocols only
  • There’s no schema you have access to or can modify
  • Flat structure, no OU’s, Domains or Forests

So, at this point, it’s obvious now that Azure AD is a very different thing to AD DS. AAD is for user, group and application management in the cloud. If your building all new services using PaaS or SaaS and using modern authentication protocols then you should be all set with AAD, it’s what it was designed for.

However, if your running IaaS in Azure and want AD DS to domain join machines and create GPO’s, then AAD won’t cut it for you (and that is by design).

Active Directory on Azure

Hopefully, now it’s clear what AAD is and isn’t, and if your building modern apps and AAD does what you need, then you can stop here.

However, if you are going down the IaaS route in Azure and you feel you still need the services of an AD domain, what alternatives are there?

Azure AD Join

I mentioned this briefly earlier; it is possible to join devices directly to Azure AD. AAD Join is limited to Windows 10 machines only and provides limited functionality, certainly nothing like a full AD join.

When Azure AD joined, it is then possible to login to machines using Azure AD user accounts. You can apply conditional access policies that require machines to be AAD joined before accessing resources or applications. If you’re looking for a way to provide common user account management across Windows 10 machines, then this may work for you.

Azure AD Domain Services

If you need more than just user management, then it is possible to extend Azure AD to offer more AD based services using Azure AD Domain Services. AAD DS is an Azure product that you enable on your virtual network which deploys two domain controllers. They are managed by Microsoft and synchronized with your Azure AD tenant. This allows admins to grant machine access to users in your AAD tenant, but also to implement things like custom OU’s, group policy, LDAP queries, NTLM and Kerberos.

This is a domain managed by Microsoft, so you do not have to worry about patching your domain controllers or ensuring they are up. However, it also means you do not have full control of the domain. For example, you do not have domain admin rights, only enough rights to undertake the tasks Microsoft allows. You can see a full breakdown of AAD DS limitations here.

AD Domain Controllers on Azure

Nothing is stopping you just deploying some virtual machines in Azure and turning them into domain controllers. This is a support configuration and is in use by many people who need the full suite of services provided by AD inside Azure.

The downside to this approach is that you need to manage this yourself. You need to take care of patching and updating your servers, backing up your domain and any other maintenance you require. You are also in charge of making sure it is highly available and implementing a DR strategy if you require it. If you need all that AD DS has to offer then, this can be a great option, but if all you want is a common user store for machine login, it might be overkill.

Access your On-Premises AD Domain

Finally, you can also extend your existing on-premises domain into Azure. Using ExpressRoute or VPN, you can connect your on-premises network to your Azure vNet and allow access to domain controllers. You can even deploy IaaS domain controllers in Azure that are joined to your on-premises domain. This then adds a dependency to your infrastructure of connectivity back to the on-premises network, so this connectivity becomes a key point of failure. You need to ensure that resiliency is built in.

Summary

If your new to Azure and especially identity in Azure, I hope clears things up. This is a new, modern authentication provider and is not Active Directory Domain Services in the cloud. AAD does not behave like the AD DS you know and love and really shouldn’t be compared to it, it is a different service.

If you need AD DS in your cloud environment, then there are options to achieve this, but AAD is not going to give you that. Take a look at the options listed in this blog post and see what meets your needs.

Until next time, Rob

Windows Virtual Desktop now in the Wild – Public Preview Now Available

The Windows Virtual Desktop (WVD) product and strategy announced last September is finally here in public preview.  Something near and dear to my heart for the last 6 months.  I’ve been in private preview and had to keep a lid on it 🙂 Yea!!

What is it?

Simply put, it’s multi-session Windows 10 experience with optimizations for Office 365 ProPlus, and support for Windows Server Remote Desktop Services (RDS) desktops. It means users can deploy and scale Windows desktops on Azure and on-premise quickly.

The service brings together single-user Windows 7 VDI and multi-user Windows 10 and Windows Server RDS and is hosted on any of Azure’s virtual machine tiers or what you could call DaaS (Desktop as a Service) in a way.

Licensing

Microsoft is pricing WVD aggressively by charging only for the virtual machine costs; the license requirements for the Windows 7 and Windows 10 based services will be fulfilled by Microsoft 365 F1/E3/E, Windows 10 Enterprise E3/E5, and Windows VDA subscriptions. The Windows Server-based services are similarly fulfilled by existing RDS client access licenses. This means that for many Microsoft customers, there will be no additional licensing cost for provisioning desktop computing in the cloud.

The virtual machine costs can be further reduced by using Reserved Instances that commit to purchasing certain amounts of VM time in return for lower pricing.  All of this just means simpler licensing for Office and Windows as opposed to the crazy license models of the past.  I am not saying that crazy licensing models are gone but have gotten much simpler.

What’s the deal with Windows 7 and Support?

The new service will be available to the production environments in the by June before Windows 7 support ends in January 2020.

But, there is a big incentive, Windows 7 users will receive all three years of Extended Security Updates (ESU) at no extra cost. This should ease the cost of migration to the service; this is in contrast to on-premises deployments that will cost either $25/$50/$100 for the three years of ESU availability or $50/$100/$200, depending on the precise Windows license being used.

WVD and O365

WVD will also provide particular benefits for Office 365 users. In November last year, Microsoft bought a company called FSLogix that develops software to streamline application provisioning in virtualized environments.

Outlook (with its offline data store) and OneDrive (with its synchronized file system) represent particular challenges for virtual desktops, as both applications store large amounts of data on the client machine.  This data is expected to persist across VM reboots and redeployments. FSLogix’s software allows these things to be stored on separate disk images that are seamlessly grafted onto the deployed virtual machine. WVD will use this software for clients running Office 365, but this can be optional.

Liquidware and WVD

The technology of ProfileUnity and FlexApp only complement what Microsoft includes with FSLogix.  But do understand, if you need a simple soution for Profile Disk, then FSlogix is the way to go and save yourself some money. Over my next few blog posts, I plan to show how to set up WVD and a full walk-through of FSLogix running with WVD.

Sizing WVD?

Liquidware has a product called Stratusphere UX. It’s an EUC monitoring tool that allows you to properly size your Azure environment for WVD. This helps make smart decisions on migrations to WVD.  It doesn’t stop there, Stratusphere provides ongoing metrics and alerting that help IT Pro’s to continue to maintain a high performing WVD environment into the future.

How do I get it?

Azure Market Place 🙂 The preview is available in the US East 2 and US Central Azure regions; When GA is announced, it will be available in all regions.

In Microsoft’s eyes, its time to kickass and take names 😉

Check out my next post on WVD and FSLogix.

Until next time, Rob

MVPITPro Podcast – Ep5 – A Talk with Mike Bender from the Azure Cloud Ops Advocate Team

Join us for episode 3 of the new MVPIT Pro Podcast, featuring your hosts Andy Syrewicze from Altaro Software and myself    Jeffrey Snover @jsnover 

In this episode Andy and Rob Talk about:

  • Windows Server 2019 TP Build 17666
  • GDPR
  • Microsoft Loves Linux!
  • Steps that IT Pros can take today to become Microsoft MVPs
  • and much, much more!

Our special guest interview this episode features The one and only Jeffrey Snover, Microsoft Technical Fellow and Creator of PowerShell!

Enjoy 🙂 !!!

YouTube player

The Microsoft Cloud: A Complete Picture

If you’re looking to learn more about Microsoft cloud, including how your organization could benefit from it, you’re in the right place. This comprehensive guide covers the basics and beyond, from “What is Microsoft cloud?”, to services and security.

Feel free to skip to the parts you’re most interested in by using the table of contents below. If you have any questions after reading, don’t hesitate to get in touch—I’m happy to provide clarification and answer any of your questions.

Continue reading