How to add your custom domain name in Azure Active Directory

In this post would discuss about the use of a custom domain name in Azure AD and how we can add one.

Before going into that, first talk about what is Azure Tenant. It's a dedicated and trusted instance of Azure AD that's automatically created when you or your organization signs up for a Microsoft cloud service subscription, such as Microsoft Azure, Microsoft Intune, or Microsoft 365. An Azure tenant represents a single organization.

Now what is Azure AD, it is Microsoft’s cloud-based identity and access management service, which helps your employees sign in and access resources in:

• External resources, such as Microsoft 365, the Azure portal, and thousands of other SaaS applications.
• Internal resources, such as apps on your corporate network and intranet, along with any cloud apps developed by your own organization.

Every new Azure AD tenant comes with an initial domain name as given, <domain-name>.onmicrosoft.com. We can't change or delete this initial domain name, however can add a custom domain aligned and reflecting ones organization's name. Adding custom domain names helps you to create user names that are familiar to your users, such as abc@vCloudClass.com, where vCloudClass.com is a custom domain.

Please note that, Only a Global Administrator can manage domains in Azure AD.

This role is automatically assigned to whomever created the Azure AD tenant. Global administrators can do all of the administrative functions for Azure AD and any services that federate to Azure AD, such as Exchange Online, SharePoint Online, and Skype for Business Online. You can have multiple Global administrators, but only Global administrators can assign administrator roles (including assigning other Global administrators) to users.

Now I assume that you have already created a domain name with a domain registrar such as godaddy etc. and logged in to your Azure Account with as Global administrator.

The process of adding a custom domain consists these three tasks, 

1. Add your custom domain name to Azure AD                                     

Login to Azure Portal using a account having Global Administrator Role assigned => Select Custom domain names => Add your domain on this page using add domain button => once the unverified domain is added => Click on the unverified domain and note down the TXT record 

2. Add your DNS information to the domain registrar                            

Go back to your domain registrar and create a new TXT record for your domain based on your noted DNS information. Set the time to live (TTL) to 3600 seconds (60 minutes), and then save the record. 

Note: You can register as many domain names as you want. However, each domain gets its own TXT record from Azure AD.

3. Verify your custom domain name                               

Note: DNS records must propagate before Azure AD can verify the domain. This process can take an hour or more.

After you've verified your custom domain name, now make it your primary domain.

The primary domain is the default domain name for a new user when you create a new user. Setting a primary domain name streamlines the process for an administrator to create new users in your AD.

You can make your domain primary by completing the following steps,

1. Sign in to the Azure Portal with an account that's a Global Administrator for the organization.
2. Now select Azure Active Directory => Select Custom domain names => Select the name of the domain that you want to be the primary domain => Select the Make primary command, confirm.

You can change the primary domain name for your organization to be any verified custom domain that isn't federated. Changing the primary domain for your organization won't change the user name for any existing users.

Demo:

Related reads:

Azure Active Directory features, license types, and terminology

Managing custom domain names in Azure AD

That's it...Thanks :)

How to Re-deploy an Azure VM from Portal/PowerShell or Azure CLI

In some circumstances, as part of troubleshooting, where you are having a connectivity-related issue or agent/extension status related issue and think that this could be related to the underlying host on which this VM is running we use VM redeployment option. This VM redeployment is nothing but a process of changing the physical host where your VM is currently running.

When you redeploy a VM, Azure will shut down the VM, move the VM to a new host within the Azure infrastructure, and then power it back on, retaining all your configuration options and associated resources.

If you are coming from VMware background then this might surprise you as there you can simply vMotion a running VM from one Esxi host to another however here this is the only option to so.

The Azure redeploy operation does not impact any settings or configuration of the affected VM. However, you may lose the data on the temp drive and if using Dynamic IP then the same would also change. To avoid the IP change you can mark the assigned IP as static from vNIC settings. 

You can re-deploy a VM either directly from with VM blade on the Azure portal or using PowerShell and Azure CLI.

Azure Portal:

1. Go to affected VM
2. on VM blade look for VM redeploy option under Support & Troubleshooting
3. Redeploy the VM using the re-deploy option

PowerShell: Use the following to re-deploy a VM.

#first you need to connect to your Azure account

Connect-AzAccount

#Get the list of Subscriptions availabe in your Azure account

Get-AzSubscription 

#Set the desired subscription as default

Select-AzSubscription -Subscription "Subscription name"

#Set the required variable to make this scriprt reusable

$rgName = read-host "Enter the resourceGroup name where this VM reside"

$vmName = read-host "Enter the VM name"

Set-AzVM -Name $vmName ResourceGroupName $rgName -redeploy

Azure CLI: First connect to your account, set the respective subscription as default,

#first you need to connect to your Azure account

az login

#List Subscription in your Azure account

az account list --output table

#to set your Subscription as default for this session

az account set --subscription "Name of your Subscription

az vm redeploy -name "name of the VM" -group "resource group name"

During VM redeployment operation the Status of the VM changes to Updating as the VM prepares to redeploy and then changes to Starting as the VM boots up on a new Azure host.

Related demo: 

That's it...Thanks :)

Azure recovery Services Vault overview and how to create one

In this blog post I would talk about Azure Recovery Services vault; this is the central component for backup or DR planning in Azure or even for on-prem if you are planning to use Azure Site recovery (ASR) for DR or Azure Backup.

A Recovery Services vault is a storage entity in Azure that houses data it stores the backups and recovery points created over time. The Recovery Services vault also contains the backup policies that are associated with the protected virtual machines. You can use Recovery Services vaults to hold backup data for various Azure services such as IaaS VMs (Linux or Windows) and Azure SQL databases. Recovery Services vaults support System Center DPM, Windows Server, Azure Backup Server, and more. Recovery Services vaults make it easy to organize your backup data, while minimizing management overhead.

We can have up-to 500 vaults in a subscription and 1000 Azure VMs can be backed up in a single vault with the frequency of once a day. Here you need to keep one thing in mind that this Vault should be in the same region as your VMs (for backup only).

 Recovery Services vaults are based on the Azure Resource Manager model of Azure, which provides features such as:

• Enhanced capabilities to help secure backup data: Enhanced security features for backup that allow for data recovery even if production and backup servers are compromised

• Central monitoring for your hybrid IT environment: With Recovery Services vaults, you can monitor not only your Azure IaaS VMs but also your on-premises asset backups (if configured) from a central portal.
  

• Azure role-based access control (Azure RBAC): Recovery Services vaults are compatible with Azure RBAC, which restricts backup and restore access to the defined set of user roles. 

• Soft Delete: With soft delete, even if a malicious actor deletes a backup (or backup data is accidentally deleted), the backup data is retained for 14 additional days, allowing the recovery of that backup item with no data loss. The additional 14 days of retention for backup data in the "soft delete" state don't incur any cost to you.

• Cross Region Restore: Cross Region Restore (CRR) allows you to restore Azure VMs in a secondary region, which is an Azure paired region. If Azure declares a disaster in the primary region, the data replicated in the secondary region is available to restore in the secondary region to mitigate real downtime disaster in the primary region for their environment.

Storage settings in the Recovery Services vault: Within Recovery Services Vault Azure Backup automatically handles storage for the vault how as per our availability requirement we can choose the storage redundancy as one of the following, local, geo or zonal redundancy. As of now zonal is not available in all regions.

• Locally redundant storage (LRS) copies your data synchronously three times within a single physical location in the primary region. LRS is the least expensive replication option but is not recommended for applications requiring high availability.
• Zone-redundant storage (ZRS) copies your data synchronously across three Azure availability zones in the primary region. For applications requiring high availability, Microsoft recommends using ZRS in the primary region, and also replicating to a secondary region.
• Geo-redundant storage (GRS) copies your data synchronously three times within a single physical location in the primary region using LRS. It then copies your data asynchronously to a single physical location in the secondary region.

Encryption settings in the Recovery Services vault: By default, all your data is encrypted using platform-managed keys. You don't need to take any explicit action from your end to enable this encryption. It applies to all workloads being backed up to your Recovery Services vault.

You can choose to encrypt your data using encryption keys owned and managed by you.

Azure Site Recovery: Site Recovery contributes to your business continuity and disaster recovery (BCDR) strategy, by orchestrating and automating replication of Azure VMs between regions, on-premises virtual machines and physical servers to Azure, and on-premises machines to a secondary datacenter.

This Recovery service vault blade would become the central point to configure enable and initiate the VM failover and fail back.

Note: You can also use the VM blade to configure replication for an individual VM however here you can create recovery plan to orchestrate the failover of multiple VMs part of a single application environment.

When you enable replication for a VM to set up disaster recovery, the Site Recovery Mobility service extension installs on the VM and registers it with Azure Site Recovery. During replication, VM disk writes are sent to a cache storage account in the source region. Data is sent from there to the target region, and recovery points are generated from the data. When you failover a VM during disaster recovery, a recovery point is used to restore the VM in the target region.

Demo:  

Related Reads:

Azure Recovery Service Vault Overview

Backup Support Matrix

Azure Site recovery Documentation, Azure to Azure or On-prem to Azure Scenario (AWS or any other Cloud to Azure would also fall in this category).

Also read the Backup and Site recovery FAQs.

That's it for today....Thanks :)

Azure Resource Hierarchy and how to manage them effectively

In this blog post, we would discuss about the Azure resource hierarchy and how you can organize and manage them effectively from the point of Security, management, and tracking the cost.

As we know that one needs to have an active Azure Subscription to create any resource in Azure account and once you have that then need to create a Resource Groups (RG) and then can create all other resources by putting them in RGs.

Now think from the perspective of an Org having multiple subscriptions, that is where you need a Scope above subscription to efficiently manage them and that is where can use Azure Management Groups. Here we can manage Access Policies & Compliance for these subscriptions as a single entity and whatever access, policy, or compliance you would configure would get inherited top-down.

How the four management-scope levels relate to each other

·        Management groups: These groups are containers that help you manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group.

·        Subscriptions: A subscription logically associates user accounts and the resources that were created by those user accounts. Each subscription has limits or quotas on the amount of resources you can create and use. Organizations can use subscriptions to manage costs and the resources that are created by users, teams, or projects.

·        Resource groups: A a resource group is a logical container into which Azure resources like web apps, databases and storage accounts are deployed and managed.

·        Resources: Resources are instances of services that you create, like virtual machines, storage, or SQL databases.

Note: All Subscriptions within a single MG must the same AAD Tenant.

This was a simple example of Management group hierarchy; you can create multiple Management Groups under Root Management Group for Azure Actively Directory. The creation of other Management groups could be part of your resource’s management planning to achieve one of the following,

·        Group your subscriptions: Easily manage your Azure subscriptions by grouping them together and taking actions in bulk

·        Mirror your organization’s structure: Create a hierarchy of Azure management groups tailored to your organization to efficiently manage your subscriptions and resources

·        Apply policies or access control to any service Use full platform integration to apply governance conditions such as policies, access controls, or full-fledged blueprints to any Azure service

Each Directory is given a single top-level management group called the “Root Management group”. This Root management group is built into the hierarchy to have all subscriptions part of that directory fold into it. This is used to assign the global policies and Azure role assignment at the directory level. To mange access at this scope the Azure AD Global administrator need to elevate themselves to have User Access Administrator role of this root group initially. Once you have the permission then can assign any Azure role to other directory users or Groups to manage the access, compliance and related aspects.

A management group tree can support up to six levels of depth however this limit doesn’t include root or subscription level. Keep in mind that each MG or subscription can have only one parent, and all these are within a single hierarchy in each directory.

Related Demo: How-to Create and manage Azure Management Groups and related hierarchy.

Related reads:

Azure Management Groups And Hierarchy

Azure management groups

That’s It….Thanks 😊