Category: Managing Multiple Directories Page 1 of 2

In Deleting and Modifying Users, Exams of Microsoft AZ-104, Inviting Users, Managing Multiple Directories, Microsoft AZ-104 Certifications, Self-Service Password Reset, Users and Groups

As mentioned in the introduction of this chapter, Azure AD is Microsoft’s cloud-based identity and access management (IAM) solution. Azure AD is an especially useful solution for IT admins, developers, and subscribers of various Microsoft solutions (such as Microsoft 365, Dynamics 365, and Azure). Primarily, Azure AD deals with helping employees to sign-in to various resources such as O365, M365, Dynamics, Azure, etc. However, the integration does not stop here; you can integrate Azure AD as the IAM solution for third-party applications and your internal applications as well. Developers are constantly working on integrating Azure AD as the IAM solution because of the increased reliability it provides. Since this book is about Azure administration, we will focus on how Azure AD is intended to help IT admins.

Benefits

Let’s explore the different benefits of Azure AD and why organizations should consider Azure AD as the IAM solution.

SSO to Cloud and On-Premises Applications Having too many credentials for different applications increases the complexity and results in a higher chance of human error because an SSO solution will help users to sign in to all cloud applications, on-premises applications, and devices using their corporate credentials. Azure AD is not only meant for Microsoft Stack, but for thousands of SaaS applications such as Dropbox, ServiceNow, DocuSign, etc.

Easily Extend On-Premises Active Directory to the Cloud When organizations move from on-premises to the cloud, there is a need to synchronize the users with the cloud. Otherwise, users will end up with two credentials, one for on-premises and another one for the cloud. To avoid this scenario and to provide a seamless SSO experience, Azure AD allows administrators to synchronize users, groups, passwords, and devices across both on-premises and the cloud. This is accomplished using a tool called Azure AD Connect that needs to be installed on your on-premises domain controller or any other domain-joined server with Windows Server 2012 or later, and it will help with the synchronization.

Cross-Platform Support Regardless of what platform the user is using, be it iOS, Android, Windows, Linux, or macOS, the sign-in experience is going to be the same, and the users can sign-in to their applications using their work credentials.

Increase Security of Your On-Premises Applications You can use the Azure AD Application Proxy service to access your on-premises applications via a secured remote access. The best part is you do not have to expose any additional ports on your on-premises firewalls; the access is managed by application proxy endpoints. The access can be tightened using multifactor authentication and conditional access policies.

Better Monitoring and Data Protection Azure AD amplifies the overall security posture of your environment by providing unique identity protection features. Azure AD Identity Protection comprises several features including suspicious sign-in activity, risk alerts, etc. These triggers can be further integrated with conditional access policies to make business decisions. In addition to these capabilities, administrators can leverage security reports, sign-in activities, and potential vulnerability reports that are available off the shelf without the need to deploy any additional components.

Self-Service Capabilities If you have worked as an IT administrator, you know most of the calls to the help desk will be regarding password resets. Azure AD offers a feature called Self-Service Password Reset by which users can reset their own passwords with the help of an authentication method such as phone, email, security questions, or a combination of these. IT admins need to enroll users into the SSPR program before they can use this feature. Enrolling is also self-serve, and the user will be prompted to verify the authentication methods. Enabling SSPR in your environment can elevate the security and reduce help-desk engagements.

If you are using Office 365, Azure, or Dynamics 365 in your environment, knowingly or unknowingly you are interacting with Azure AD to complete the authentication process.

We have been talking about Azure AD for a while now, and it is time that we understand the concepts that are part of Azure AD.

Azure AD vs. Active Directory Domain Services – Identity: Azure Active Directory

By Pamela Craig

On 2024-06-06

In Exams of Microsoft AZ-104, Managing Multiple Directories, Microsoft AZ-104 Certifications

You might have already worked or heard about Active Directory Domain Services (AD DS) in your on-premises environment. If you have not heard about AD DS, this is a deployment of the Active Directory service/role on Windows Server. The server can be a physical or virtualized one. The primary focus of AD DS is to work as a directory service. There are several other components of Active Directory that get installed along with the directory service such as Active Directory Lightweight Directory Service (AD LDS), Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS), and Active Directory Rights Management Service (AD RMS). You can also implement AD DS in Azure by installing the Active Directory Domain Services role on your Windows virtual machines deployed in Azure. This is not a recommended scenario unless you have a special scenario that requires AD DS deployment; for all other scenarios, Azure AD is recommended.

At first look, AD DS and Azure AD may look the same and both can be used for authentication and offer directory services; however, there are some differences in the way things work under the hood. The key point to understand here is if you install the AD DS role on an Azure Windows virtual machine, it is not equivalent to Azure AD. A lot of beginners have this misconception and assume both are the same. Well, that is wrong. The following are some of the key differences that make Azure AD different from AD DS:

Hierarchy A flat structure is used by Azure AD to represent or provision the users and groups. Therefore, organizational units (OUs) and Group Policy objects (GPOs), which exist in AD DS, do not exist in Azure AD.

Federation Services Azure AD supports Federation Services as an authentication method, and you can further integrate with third-party providers such as Twitter, Facebook, etc. On the other hand, in the case of AD DS, we can set up federation with another domain controller or forest only, and third-party integration is not supported.

Lack of LDAP In AD DS, we used a protocol called LDAP to query users, groups, or objects in Active Directory. In the case of Azure AD, since this is an HTTP/HTTPS-based service, we will be using the REST API for querying instead of LDAP.

Lack of Kerberos AD DS deployment uses Kerberos authentication; however, Azure AD uses HTTP/HTTPS protocols like SAML, OpenID Connect for authentication, OAuth for authorization, and SAML. Developers can choose any of these communication protocols while they design security for their applications.

Management Azure AD is a managed service, and it is an underlying infrastructure; the availability is managed by Microsoft. If AD DS is deployed on an Azure Windows virtual machine, the configuration, management, virtual machine patching, updates, upgrades, and other maintenance tasks should be taken care by the end customer.

Users and Groups – Identity: Azure Active Directory

By Pamela Craig

On 2024-01-02

In Deleting and Modifying Users, Exams of Microsoft AZ-104, Managing Multiple Directories, Microsoft AZ-104 Certifications

Users and groups are the primary objects of every IAM solution, and Azure AD also has a user and group management system, which is the backbone for access management. You have seen what an account is; just to refresh what we discussed; an account is an identity that has data associated to it. In Azure AD, you have user accounts and group accounts for managing users and groups. Let’s get started with user accounts and see the operations that are available for administrators.

User Accounts

As the name suggests, user accounts consist of user identities, which will be used by users to log in to services such as Azure, O365, Dynamics 365, SaaS applications, and other third-party applications that are integrated with Azure AD.

You should create a subscription for testing all labs in this book. You can create a Free Trial subscription. If you are using your personal email address to sign up for the subscription, a new tenant will be automatically provisioned for you. All operations can be performed on that tenant.

Now that you know what a user account is, it is time to see how you can see users in our directory.

Viewing User Accounts

If you are working on a new directory that was set up for testing the exercises in this book, then you won’t have any additional users apart from the account that you used to sign up for the subscription. However, in a production environment, there will be hundreds of users. As an administrator, you will be asked to verify if the account exists in Azure AD or get information about a particular user. Hence, knowing how to view user accounts is particularly important in an IT admin’s daily job. We will follow a step-by-step process to view the users in your directory, as shown in Exercise 1.1.

EXERCISE 1.1
Viewing Users in Your Directory

Open your browser (Microsoft recommends that you use the latest version of your favorite browser) and navigate to the Azure portal, which is available at https://portal.azure.com.
A sign-in screen will be presented to you. Sign in using the email address that you used to create the subscription. The data you enter (username and password) will be sent to Azure AD. If the credentials are correct, then you will be logged in.

3. Now that you are in the Azure portal, you can click the hamburger icon at the top-left corner and click Azure Active Directory.

4. Selecting Azure Active Directory will take you to the Overview blade of Azure Active Directory. This blade gives you some idea about certain aspects of your Azure AD such as the tenant ID, tenant name, primary domain associated to your tenant, edition of Azure AD, and number of users, groups, applications, and devices. If you scroll down, you will see more information such as your account, Azure AD connect, secure score, etc. The graphic here shows the overview of the tenant that is used for the demonstration.

If you take a close look at the graphic, you can see at the top the option that will let you create, manage, and delete tenants. These options are quite useful if you are managing a multi-tenant environment. One thing to note here is that deleting a tenant requires you to cancel all active Azure subscriptions that are part of the tenant. You cannot delete a tenant when there is an active Azure subscription associated with that tenant. Since we are working on user management, let’s shift our focus to the Users blade under the Manage section.

5. Once you click the Users blade, you will be presented with the All Users view. Your view might be different from what is shown here as it is displaying the users in the demo tenant.

6. If you click any user, you will be presented with the details of the user such as name, user principal name, job title, department, manager, etc., along with the creation date and last sign-in date.

In this section you saw how to view the existing users in the directory and find the details of a user. Now that you know how to find a user in the directory, let’s see how to add a new user to the directory.

Deleting and Modifying Users – Identity: Azure Active Directory

By Pamela Craig

On 2023-05-20

In Exams of Microsoft AZ-104, Inviting Users, Managing Multiple Directories, Microsoft AZ-104 Certifications

As mentioned in the previous section, whenever someone gets promoted, moves to a different department, or changes their work location, these details need to be updated on the user profile. Though these fields are not mandatory, they will be important in understanding more details about the user. Assume that there are two John Does in your organization—one works for HR and the other one works for IT. Adding department details here will help the administrator to perform the operations on the right user. In Exercise 1.3, we are going to modify the user we created in Exercise 1.2 and then delete the user.

EXERCISE 1.3
Modifying and Deleting Users

Let’s perform the update process on the user we created in Exercise 1.2. The tasks we have here are as follows:

Reset the password of the user to a new password.
Change the department of the user to HR.
Add the employee ID as 1322.
Verify the user details.
Delete the user.

The first step here is to navigate to the All Users blade as we have done in Exercise 1.1; you can follow these steps to update the user attributes:

From the All Users blade, select the user John Doe by clicking the name; that will take you to a screen similar to the following one.

2. Since our first task here is to reset the password, you can click Reset Password, and you will be asked to confirm whether you want to proceed with the reset process. You must click again the Reset Password option, which will be visible in the right corner of the screen. To reset a user’s password, you need to be the Global Administrator. User Administrators, Helpdesk Administrators, and Password Administrators can also reset the passwords of non-administrative accounts. However, User Administrators, Helpdesk Administrators, and Password Administrators cannot reset the password of a Global Administrator. Password reset of the Global Administrator can be done only by another Global Administrator.

Confirming the reset password option will display a temporary password on the screen. This needs to be changed on the first sign-in after the reset as this is a temporary password and an administrator is responsible for sending this password securely to the user.
Now that you have reset the password, the next task is to update the department and employee ID. If you recall, we skipped these optional fields while creating the user, and it is time now to update them. To edit the user details, you can click the Edit button, which is on the left side of the Reset Password button.
Clicking the Edit button will enable all the text boxes. Once you have updated the information, you can click Save. You can update all information except the object ID, which is a unique ID assigned to every identity by Azure AD.

6. After saving the details, if you go back to user profile, you will be able to see that all the data you entered is populated to the user profile.

7. From this graphic, we confirmed that the department details and employee ID have been added to the user profile. The next task is to delete the user. Assume that John Doe is leaving the organization and you have to deprovision his account. In the graphic, you can see that there is a Delete button next to the Reset Password button. Clicking Delete will ask for your confirmation.

8. Click Yes, and John Doe’s profile will be deleted. However, this is not a permanent delete action. All deleted users can be viewed from the Deleted Users blade.

9. You will have 30 days from the deletion date if you want to restore the user, using the Restore option. You can also delete the user immediately by selecting the Delete Permanently option instead of waiting for 30 days.

All these actions can be also performed from the Office 365 Admin panel, PowerShell, or CLI if required.

In Exercises 1.1, 1.2, and 1.3 you have seen how an administrator can view, add, modify, or delete users. Performing these tasks one by one from the portal is not a great idea if you have a large user base. All the actions that you have seen in the previous exercises can be performed in bulk. In the next section, you will learn how administrators can leverage bulk operations available for user accounts.

Viewing Groups – Identity: Azure Active Directory

By Pamela Craig

On 2022-11-10

In Exams of Microsoft AZ-104, Managing Multiple Directories, Microsoft AZ-104 Certifications, Self-Service Password Reset

In Exercise 1.5, you will see how you can view groups in Azure AD.
If you are using a new setup, chances are you might not see any groups in your environment. This is fine; the purpose of the exercise is to make you understand how you can reach the Groups blade.

EXERCISE 1.5
Viewing Groups in Azure AD

At this point, you should be familiar with the navigation in the Azure portal and how to reach the Azure Active Directory blade. Right below the Users option that you used earlier, you will be able to see Groups. Clicking Groups will take you to All Groups.

If you take a close look at the graphic, you can see that this list provides a lot of insights about the listed groups. For example, you can see the group type (Security Group or Microsoft 365 Group), membership type (Dynamic or Assigned), group email (shown only for Microsoft 365 as there will be a shared mailbox), and source (synchronized from Windows Server AD or the cloud). These details are extremely useful in managing the groups and in understanding the properties of a group.
Clicking any of the groups (you can skip this step if you do not have any groups in your environment) will give you a plethora of details about the group such as how many members are there, list of owners, group membership, device membership, etc.

Now that you know how to navigate to the Groups blade and find a group, let’s move on and see how you can add a new group.

Adding Groups
In this section, we will cover how you can add a new security group and Microsoft 365 group. In addition, you will see how you can work with dynamic rules and direct membership to these groups. Especially in Exercise 1.6, you will create a security group called Avengers and add the users we created in Exercise 1.4 via direct membership.

EXERCISE 1.6
Adding Security Groups to Azure AD

Navigate to the Groups blade by following the steps mentioned in Exercise 1.5, and you will be able to see New Groups option.

Since our first task is to create a security group, you can see that we have selected the following options:
a. Group type: Security (as we need to create a security group).
b. Group name: Avengers (as we are going to add the Avengers users here).
c. Group description: This field is optional; if you need to add a description about the group, feel free to add it.
d. Azure AD roles can be assigned to this group: Yes, this setting needs to be enabled if you plan to assign roles to this group from an access management perspective.
e. Membership type: Assigned (as we are going to perform direct assignment).

f. Owners: You can select the owners for the group. This set of users will manage the group such as adding or removing users. You can search users, and add once you are done, click Select.

g. Members: This is the set of users who will be part of the group; we will select all users that we need in the group. Once they are selected, click Select to add members to the group.

The new group window will now show the number of users you selected as owners and members. The next step is to click Create and create the group.

4. Navigate to All Groups and search for Avengers; you will be able to see the new group you created for our Avengers. Clicking the group name will reveal the properties of the group.

If you have followed these steps, then you have successfully completed the exercise to create a security group. Now let’s focus on Microsoft 365 groups and dynamic users in Exercise 1.7.

Security groups can also be created with dynamic memberships supporting both dynamic users and devices; we are going to use Microsoft 365 and dynamic users for demonstration purposes only. You can apply the same logic with security groups and dynamic users, if needed.

Adding Microsoft 365 Groups in Azure AD – Identity: Azure Active Directory

By Pamela Craig

On 2022-09-08

In Exams of Microsoft AZ-104, Managing Multiple Directories, Microsoft AZ-104 Certifications, Users and Groups

In the previous exercise, we created security groups. It is time that we take the exercise to the next level by creating a Microsoft 365 group and adding users dynamically based on rules.

Before you create the group, you need to add some new users using the bulk create method. If you cannot recall the process, perform the steps in Exercise 1.4 to accomplish bulk creation. The following is a sample file used for creation and note that here we are using the usageLocation and department headers to add the usage location and department of the users. These attributes will later be used to build our dynamic rules. Upload the file and create the users before you create the group.

2. As you performed in Exercise 1.6, you need to reach the New Group window and add properties as follows:
a. Group type: Microsoft 365 (as we need to create a Microsoft 365 group).
b. Group name: All HR (a group for all users whose department is HR).
c. Group email address: This is a required field as all Microsoft 365 groups should have an email address. You can add something like “all-hr” and the domain will be auto populated based on your tenant domain.
d. Group description: This field is optional; if you need to add a description about the group, feel free to add it.
e. Membership type: Dynamic User (as we are going to use dynamic queries to add users).

f. Owners can be selected in the same fashion as we did in the case of security groups (refer to Exercise 1.6 step 2.f).
g. The next option is to define the dynamic query for the user. If you take a closer look at the previous graphic, at the bottom you can see there is an option to add a dynamic query. Click that, and you will be taken to the dynamic membership rules editor.
h. Based on the properties you are selecting, corresponding rules are created. In our example, we are adding the property “department” EQUALS “HR.” We can add more expressions by clicking Add Expression.
i. Azure Portal will automatically generate the rule syntax based on our selection. The rule syntax for what we selected here is user.department -eq “HR”. Once you have verified the rules, click Save to save the rule.

Wait for a couple of minutes, and the members of the group will be automatically added based on the rule you configured.

4. Let’s try to create another group called India Marketing where we will set up the rule using an additional expression. The final syntax will be (user.department -eq “Marketing”) and (user.usageLocation -eq “IN”), as shown here.

5. You will see that the members matching the rule are added to the Members blade

If you completed both the exercises, by now you know how to create security groups and Microsoft 365 groups. Now let’s see how to delete or modify the existing groups.

Azure AD Join – Identity: Azure Active Directory

By Pamela Craig

On 2022-05-20

In Deleting and Modifying Users, Exams of Microsoft AZ-104, Inviting Users, Managing Multiple Directories, Microsoft AZ-104 Certifications

Single sign-on is one of the features offered by Azure AD. You can use SSO on devices, apps, and services from anywhere in the world. Joining devices to Azure AD assures the corporate devices are protected and that they follow the compliance standards set by the organization. Users can bring their own devices and join them to Azure AD, and administrators can make sure that these devices also follow the standards of your organization. Now, we will look at the benefits of Azure AD Join.

Benefits

Azure AD Join has the following benefits:

Single Sign-On This is the primary feature of AD Join; you can sign-in to any of your applications and services without a username and password prompt. The best part is it is not necessary to connect to the domain network to use SSO.

Enterprise Client Roaming The settings are synchronized across devices that are joined to Azure AD.

Microsoft Store for Business Joining your device and signing-in to the store with work or school accounts gives you a customized catalog of applications that are shared by your organization.

Windows Hello This provides you with biometric authentication using facial recognition or fingerprints to access corporate resources and sign-in to devices. The devices should have hardware that supports Windows Hello to use this feature.

Block Access Administrators can enforce policies and devices that do not meet the requirements can be easily blocked.

Let’s see what connection options are offered by Azure AD Join.

Connection Options

You can connect your devices to Azure AD using the following options:

Register to Azure AD Registration creates an identity for the device, and this identity can be used for authentication. Whenever a user signs in, the identity of the device can be used for authentication. Administrators have the right to enable or disable this identity.

Join to Azure AD Joining to Azure AD provides the same features as registration and additionally changes the local state of the device. With a change of local state, users can sign in to their device using their work or school account. Joining is more like an extension to the registration process.

Combining the registration process with Microsoft Intune (it is a mobile device management [MDM] solution) will help you create conditional policies using the device attribute. Using this combo, you can block devices that do not follow the organizational compliance standards. For example, you could block all devices that are using Windows XP or Windows 7 and make Windows 10 the prerequisite for accessing corporate resources.

You could join your device to Azure AD by going to your Windows 10 Settings ➢ Accounts ➢ Access To Work Or School. Signing in with your work or school account will connect your device to the Azure AD domain, and you can sign in to corporate resources using SSO. Figure 1.7 shows how a connected device looks.

FIGURE 1.7 Connecting a device to Azure AD

All the devices that are connected to Azure AD can be explored from the Azure Active Directory ➢ Devices blade. This blade will show OS information, OS version, join type, and owner of the devices that are joined (refer to Figure 1.8).

FIGURE 1.8 Listing all devices connected to Azure AD

Now we will talk about a lifesaver for administrators: self-service password reset. Using self-serve options reduces the incoming requests to the IT help desk so administrators can utilize their time for more productive work.

Self-Service Password Reset – Identity: Azure Active Directory

By Pamela Craig

On 2022-03-15

In Deleting and Modifying Users, Exams of Microsoft AZ-104, Managing Multiple Directories, Microsoft AZ-104 Certifications, Self-Service Password Reset

If you have worked at an IT help desk, you know most of the calls are for user password reset. Self-service password reset (SSPR) allows users to reset their passwords using a set of authentication methods set by the cloud administrators. Self-service password reset is always enabled to administrators to avoid lock-out scenarios. Admins need to use two authentication methods for password reset.

Enabling SSPR

Cloud administrators need to enable SSPR options for users or groups as this option is not enabled by default. To enable this feature, you need to have the Global Administrator role in the tenant.

SSPR can be enabled from Azure Portal ➢ Azure Active Directory ➢ Password Reset. SSPR provides three options (refer Figure 1.9).

None: SSPR is not enabled.
Selected: SSPR is enabled for selected groups.
All: SSPR is enabled for all users in the tenant.

Once SSPR is enabled, users need to register for SSPR. Azure will automatically redirect users to the registration page on first sign-in after SSPR is enabled. Users can always navigate to https://aka.ms/ssprsetup to set up their authentication methods or to change them in the future. For example, you might have registered with one phone number when you enrolled for SSPR, but you changed your phone number. In this case, you can change it by going to the SSPR setup page.

FIGURE 1.9 Enabling SSPR

Registered users can always reset the password from the sign-in page by clicking “Can’t access your account?” as shown in the Figure 1.10.

It is not necessary that you navigate to Azure Portal to click “Can’t access your account?”; you can navigate to any sign-in page that uses Azure AD login like Office 365, Dynamic 365, SharePoint, etc.

Users can also navigate to the reset page directly by going to https://aka.ms/sspr. This is an alias for the following:

https://passwordreset.microsoftonline.com

Now that you are familiar with SSPR setup, let’s see what authentication methods are available for the users and how administrators can control these methods.

Authentication Methods

The administrator can choose the number of authentication methods required to reset the password and the number of methods available for users.

FIGURE 1.10 Initiating password reset

For a successful reset operation, you require at least one authentication method. Nevertheless, it is always better to have a secondary method. For example, if you set up SSPR with an email method, and if the user has no email access, then the user will not be able to reset the password. Here, it is better to have a second option like a mobile phone so that the user can receive the code as a text message and complete the authentication.

Methods available include the following:

Email notification
Text message to mobile phone
Text message to office phone
Mobile app notification
Mobile app code
Security questions

In the case of security questions, the administrator can decide how many questions need to be registered and how many of them need to be answered to reset the password. Nonetheless, security questions are considered less secure as the answers to these questions can be guessed if the intruder or hacker knows the user personally. Attackers can also collect answers for these questions via social engineering.

Authentication methods can be configured from Azure Portal ➢ Azure Active Directory ➢ Password Reset ➢ Authentication Methods (refer to Figure 1.11).

FIGURE 1.11 Configuring SSPR authentication methods

So far, we concentrated on a single-tenant environment; in real-world scenarios there will be different tenants, and admins are responsible for the management of these tenants. Let’s see why we need multiple directories and what benefits it provides.

Azure Regions – Compliance and Cloud Governance

By Pamela Craig

On 2021-10-20

In Exams of Microsoft AZ-104, Inviting Users, Managing Multiple Directories, Microsoft AZ-104 Certifications, Self-Service Password Reset

Microsoft Azure comprises datacenters that are located across the globe. At the time of authoring this book, Azure has more than 60 regions, and there are more in the pipeline. This global presence makes Azure the cloud provider with the highest number of regions. Also, this omnipresence gives customers the ability to choose the regions that are right for them. If you are wondering what an Azure region is, a region is a geographical area on the planet comprising at least one datacenter, but usually multiple. The datacenters are isolated from each other in close proximity and connected to each other via low-latency networks, enabling faster and seamless communication.

East US, Brazil South, UK South, India West, and Australia Central are some examples of Azure regions. Figure 2.1 shows the list of public regions available for Azure at the time of authoring this book.

FIGURE 2.1 Azure regions

Let’s understand some key points about regions.

Facts

The following are some of the facts related to regions:

Regions offer flexibility for customers to deploy resources to regions that are close to their customers.
Regions ensure data residency for customers.
Regions offer compliance and resiliency options.
When you deploy a resource in Azure, in most cases you will be asked to choose a region.
Certain services are region specific, and the availability is limited to some regions when they are launched. Gradually, Microsoft will expand the service to other regions.
Services like Azure AD, Azure Traffic Manager, and Azure DNS do not require a region. The region for these resources will be shown as Global in the Azure portal.
Each Azure region is paired with another region within the same geography to form regional pairs.

Understanding these facts will help you plan your resource deployment, choose a region, and understand why you are not able to find a specific service in a region. Let’s shift our focus to regional pairs, which is an important concept in Azure.

Regional Pairs – Compliance and Cloud Governance

By Pamela Craig

On 2021-08-20

In Exams of Microsoft AZ-104, Inviting Users, Managing Multiple Directories, Microsoft AZ-104 Certifications, Users and Groups

As you already know, each region consists of one or more datacenters that are in close proximity and connected via a low-latency network. Now, an Azure geography is defined as an area of the world that consists of one or more Azure regions. Some examples are United States, India, Asia Pacific, United Kingdom, etc. If we take the United States geography, it consists of several regions such as East US, West US, Central US, etc. So, an Azure geography ensures the data residency and compliance requirements are met. If you are an organization working with a US government organization, then you cannot store data outside of the United States. Similarly, the European Union has the General Data Protection Regulation (GDPR) where organizations cannot store personal data of the EU citizens outside EU member states. As an administrator, if your organization is GDPR compliant, you can pick a geography that is within the EU and stay compliant.

Azure pairs one region with another region within the same geography. Regional pairs play a vital role in business continuity and disaster recovery (BCDR). Whenever there is a planned update on the Azure platform, Azure rolls out the update sequentially across regional pairs. This guarantees that only one region in the regional pair is updated at a time and the other one can be leveraged for the recovery of the services if something goes wrong.

Figure 2.2 shows a graphical representation of regional pairs in Azure.

FIGURE 2.2 Graphical representation of Azure regional pairs

The following are some of the focus points about Azure regional pairs:

Physical Separation Three hundred miles is the preferred distance between datacenters that are part of the regional pair; however, this might not be feasible in certain geographies. This isolation will diminish the probability of both regions being affected at the same time due to outages caused by natural disasters, power outages, etc.

Replication Services like storage accounts provide georedundant storage (GRS). Using GRS, your data will be replicated to the paired region and thus provide reliability.

Recovery Order If a mass outage happens, Microsoft will prioritize the recovery of one region out of every regional pair.

Serialized Updates Azure planned updates are rolled out sequentially to the regions in a region pair. As the update is not done simultaneously, even if something goes wrong, one of the regions in the region pair can be used for recovery.

Data Residency As the regions in a regional pair are part of the same geography, customers can get the benefit of regional pairs without breaking any of the data residency policies.

All region pairs have regions from the same geography; the only exception is Brazil South, and the paired region for Brazil South is South Central US. South Central US is part of the United States geography. However, the South Central US paired region is not Brazil South.
All region pairs are paired in both directions. One exception here is West India. West India’s pair is South India; however, South India’s secondary region is Central India.

Understanding regional pairs and incorporating them into your infrastructure will help you architect highly available solutions with business continuity in Azure. The complete list of Azure region pairs and how services can leverage regional pairs is available here:

https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions

With that, we will move on to Azure accounts and subscriptions.