Chapter 1. Deploy and configure infrastructure

If you already work as a Microsoft Azure cloud solutions architect (CSA), you might wonder why the AZ-300 certification exam requires that you demonstrate how to perform resource deployment and configuration tasks. After all, isn’t the CSA role normally associated with designing solutions and then handing them off to the professionals who will implement them?

Important

Have you read page xiv?

It contains valuable information regarding the skills you need to pass the Microsoft AZ-300 certification exam.

Although that may be the case in the real world, you still can expect to see performance-based lab items on your AZ-300 exam. These items involve making a Remote Desktop Protocol (RDP) connection to a Microsoftmanaged Azure subscription directly from within your exam session. In each lab, you’re required to complete a series of deployment or configuration tasks by using the Azure portal.

The goal for this chapter is to make sure you know how to do all the work that comprises this objective domain. Remember that the Azure Solution Architect certification is an expert-level title, so we expect that you already have at least intermediate-level Azure configuration abilities.

Skills covered in this chapter:

Skill 1.1: Analyze resource utilization and consumption

Skill 1.2: Create and configure storage accounts

Skill 1.3: Create and configure a virtual machine for Windows and Linux

Skill 1.4: Automate the deployment of virtual machines

Skill 1.5: Implement solutions that use virtual machines

Skill 1.6: Create connectivity between virtual networks

Skill 1.7: Implement and manage Azure virtual networking

Skill 1.8: Manage Azure Active Directory

Skill 1.9: Implement and manage hybrid identities

Skill 1.1: Analyze resource utilization and consumption

We’ll start by reviewing how to check your Azure resource utilization. Your customers will be nearly universally concerned with monitoring their monthly spend and finding opportunities for optimization. Troubleshooting is another great reason to enable diagnostic settings on all your resources.

This skill covers how to:

• Configure diagnostic settings on resources
• Create a baseline for resources
• Analyze metrics across subscriptions
• Create and analyze alerts across subscriptions
• Create action groups
• Monitor for unused resources
• Monitor and report on spend

Configure diagnostic settings on resources

As you know, Microsoft Azure has several different types of logs to generate unique data streams. The Activity log is Azure’s control-plane log, and it tracks all resource operations in your subscriptions. You can look at the Activity log as an audit log where you can determine, for example, who shut down a production virtual machine (VM) and when they shut it down.

By contrast, guest operating system-level logs are enabled for individual virtual machines, they require an agent, and they collect machine-specific data from the perspective of the guest operating system.

This exam objective is concerned with Azure resource diagnostic logs, which require no agent and pull their data directly from the Azure Resource Manager backplane.

We can export Azure diagnostic log data to any of these three destinations for storage and further analysis:

Azure storage Depending on the particular diagnostic log stream, Azure may use blog storage and/or table storage.

Event hub The Event hub is capable of high-velocity data aggregation; you can then subscribe to event data funneled into the hub.

Azure Monitor logs Use the Kusto Query Language (KQL) to run interactive queries against Azure diagnostic log data.

Imagine you need to configure diagnostic log collection for a public IP address resource. Follow these steps to enable diagnostic data collection for the resource:

1. Log into the Azure portal and browse to Monitor.
2. Select the Diagnostic settings option in the Settings menu.
3. Optionally, use the filter controls to drill into the target Azure subscription, resource group, resource type, and resource. In Figure 1-1, we’ve enabled diagnostics on a public IP address resource named vm1-ip.
4. Select the public IP address resource and then click Add DiagnosticSetting; the Diagnostic settings blade appears as shown in Figure 1-1.
5. Provide an informative name for the setting configuration.
6. Select one or more targets for the diagnostic data. As previouslymentioned, you can direct diagnostic data to a storage account, an Event hub, and/or to an Azure Log Analytics workspace.
7. Choose the logs and/or metrics for which you need to enable datacollection. These options are resource-specific. In the case of public IP address resources, you can collect Distributed Denial-of-Service (DDoS) logs and all available metrics. Typically, Azure writes the logs as blob objects, and metrics as tables.
8. Click Save to complete the configuration.

Note

Universal Procedures

The procedure given here applies to other Azure resources as well. Please keep in mind that the Azure portal is but one way to configure any Azure resource; other options include Azure PowerShell, Azure CLI, or the Resource Manager APIs directly.

Create a baseline for resources

In Azure a resource baseline is what you develop by studying resource metrics and diagnostics data. The baseline represents the ordinary, expected behavior of your Azure resources.

One truism of Azure architecture and administration is that it’s no use enabling diagnostics data collection if you don’t spend the time inspecting the data periodically.

To that point, the next section covers how to study Azure resource metrics and then configure alerts to be notified proactively when Azure resource usage goes beyond the bounds of your expected baseline.

Analyze metrics across subscriptions

Metrics in Azure Monitor are measured values and counts that represent a time series and ultimately form your baseline. You can plot multiple metrics on the same chart; the underlying Azure resources can even span multiple subscriptions. Here’s how:

1. In Azure Monitor, select the Metrics setting.
2. Change the chart title to something meaningful by clicking the pencilicon, typing the title, and pressing Enter.
3. In the first metric row, click Resource. In the Select A Resource blade,choose a subscription, resource group, resource type, and resource.
4. Choose a metric, namespace metric, and aggregation. These options areresource specific.
5. Note that you can change the chart type, create a new alert rule basedon the metric, and pin the resulting chart to the portal dashboard. Figure 1-2 shows the vm1 resource’s CPU performance over the past 24 hours.

Create and analyze alerts across subscriptions

Alerts are super powerful in Azure because they not only can save you from having to inspect diagnostic logs and metrics manually but you can create action groups that take action automatically when the alert condition is fired.

The following steps demonstrate that you can alert on disparate Azure resources that may span subscriptions. For instance, you may need to be notified when CPU utilization on several VMs exceeds your baseline threshold. Follow these steps to complete the configuration:

1. In Azure Monitor, select the Alerts setting.
2. Click New Alert Rule.
3. Under Resource, click Select. In the Select A Resource blade, choosethe Azure resource or resources that will be monitored against your alert condition. Note that you can make selections from more than one Azure subscription.
4. Under Condition, click Add. Your alert can be triggered by two typesof signal logic:

Metrics Create your alert signal logic by querying Azure resource metric data

Activity Log Create your alert signal logic by listening for particular control events in the Activity log

Depending on the Azure resource and specific metric, you specify the alert logic accordingly. For example, for a VM resource you might select the Percentage CPU metric and fire the alert when average CPU exceeds 80 percent over 5 minutes.

Under Actions, click Add. Here you create an action group thatdetermines precisely what happens when an alert is fired. There’s more about action groups later in this chapter; for now, understand your action group can take any combination of the following actions:

Send an email/SMS/push/voice message

Trigger an Azure Function App

Trigger an Azure Logic App

Send a webhook

Integrate with your IT Service Management (ITSM) platform

Start an Azure Automation runbook

Exam Tip

In Azure Monitor, you can have multiple resources targeted by one or more metrics signals, or you can target only one resource at a time with Activity log signals. Keep that in mind in your alert planning.

View alerts in Azure Monitor logs and utilize log search query functions

Of course, you can inspect and manage your Azure alert definitions from the Alerts page in Azure Monitor. However, you can also use KQL from the Logs blade in Azure Monitor to create simple to complex reports on Azure alert behavior.

For example, the following KQL query lists alerts raised during the past 24 hours, grouped by severity:

	
Alert | where SourceSystem == "OpsManager" and TimeRaised > ago(1d) | summarize Count =
count() by AlertSeverity
	

Another cool thing you can do with KQL queries is generate alerts based on them. From the Azure Monitor Logs pane, simply run your KQL query and then click New Alert Rule to generate a new alert that has a condition based on that query.

For instance, here is a sample KQL query that reports on average CPU utilization for all computes associated with your Log Analytics workspace; this query would serve as a nice CPU-related alert definition:

	
Perf | where ObjectName == "Processor" and CounterName == "% Processor Time" and
InstanceName == "_Total" | summarize AVGCPU = avg(CounterValue) by Comp
	

Note

Kusto Query Language Syntax Foundations

Microsoft developed KQL such that its syntax is immediately familiar to IT operations and development professionals. Its syntax takes as inspiration the Splunk query language, Structured Query Language (SQL), PowerShell, and bash shell scripting.

Create action groups

Action groups represent rich response logic to your Azure alerts. A good general architectural best practice is to create your action groups up front, and then reuse them in subsequent alert definitions. Let’s run through the deployment/configuration procedure:

1. 2. 3. Provide a friendly name, short name (no spaces, maximum 12characters), subscription, and resource group for the action group. 4. Under Actions, choose an action type from the list and configure itaccordingly. Figure 1-3 shows configuring multiple email and short message service (SMS) notification.

1. In Azure Monitor, navigate to the Alerts blade and click ManageActions.
2. In the Manage Actions blade, click Add Action Group.
3. Provide a friendly name, short name (no spaces, maximum 12characters), subscription, and resource group for the action group.
4. Under Actions, choose an action type from the list and configure itaccordingly. Figure 1-3 shows configuring multiple email and short message service (SMS) notification.

Monitor for unused resources

Perhaps the most straightforward way to identify lost, forgotten, or otherwise unused resources is by inspecting the Cost recommendations in Azure Advisor. As an Azure solution architect, I’ve found that many of my customers rarely if ever think of using Azure Advisor. Given its low cost (free), there’s no good reason why you and your customers shouldn’t avail yourselves of its benefits.

Not only can Azure Advisor give you a heads-up on unused resources but it can also prompt you to take optimization action on underutilized resources. In Figure 1-4, you see an Azure Advisor recommendation to right-size five underutilized Azure SQL databases.

Monitor and report on spend

The Usage And Estimated Costs blade in Azure Monitor presents a wonderful summary of your Azure consumption and spend over the past 31 days. If you’re in search of more historical data, then browse in the Azure portal to the Cost Management + Billing blade instead.

Here you can perform detailed cost analysis and forecasting for all your Azure subscriptions, and you even can take advantage of Cloudyn optimization advice. Figure 1-5 shows you the Cost analysis blade for a test subscription.

Skill 1.2: Create and configure storage accounts

The Azure storage account is a durable, highly available, scalable, and secure data store for just about any use case.

This skill covers how to:

• Create and configure a storage account
• Implement Azure storage replication
• Install and use Azure Storage Explorer
• Manage access keys
• Generate a shared access signature
• Monitor the Activity Log by using Log Analytics and Azure Monitor

Create and configure a storage account

As stated at the beginning of this chapter, exam AZ-300 presumes that you already have expertise with Azure services. You can use Azure CommandLine Interface (CLI) to create a new storage account.

Exam Tip

To be successful on all the Microsoft Azure exams, you need to have at least intermediate-level skills with both PowerShell and Azure CLI.

Here’s Azure CLI command followed by descriptions of the most important options:

	
az storage account create --name tlwstor170 --resource-group Contoso --kind StorageV2
--access-tier Hot
	

--name Storage account names must be all lowercase, be 3 to 24 characters in length, contain alphanumeric characters, and be globally unique. (Yes, it’s a challenge to satisfy all these requirements.)

--kind This is the type of storage account. In the Azure CLI, valid options are BlobStorage, BlockBlobStorage, FileStorage, Storage, or StorageV2.

--access-tier This represents how often you plan to access the data. In the Azure CLI, valid options are Hot or Cool.

Although Azure CLI gives you five options for storage account kind, there really are only three kinds:

General purpose v2 This is the most recommended storage account kind. It gives access to the four storage account services: blob, table,

queue, and file.

General purpose v1 This kind is intended for backward compatibility with older deployments; v1 accounts do not support access tiers or zone-level replication.

Blob storage Like General purpose v1, this is a legacy storage account that is used only for businesses that still maintain them. This storage account type can store only VM virtual hard disks, and nowadays it’s best practice to place VM disks in managed disk storage instead of in traditional storage accounts.

Microsoft gives customers a price break depending on the access tier; remember that Microsoft charges you not only for the amount of data resident in a storage account but also for outbound (egress) data transfer and every underlying REST API transaction.

Set your blob storage to the Hot tier for frequently accessed data; you get a discount on transaction cost. Set your blob storage to the Cool tier for infrequently accessed data; here, Microsoft grants you a discount on data storage.

Set your blob storage to Archive if you truly don’t plan to access the data other than special occasions. Here you must “rehydrate” archived blobs and are charged to do so; make sure you flip the archive bit only if your business requirements mandate it.

The following command sets a new storage account to Cool storage instead of Hot:

	
az storage account update --name tlwstor170 --resource-group Contoso -
	

Need More Review?

Learning the Azure Cli

If you need some more education concerning the Azure CLI, including installation and configuration instructions, visit the Microsoft Azure docs article “Azure Command-Line Interface (CLI)"" https://docs.microsoft.com/en-us/cli/azure/?view=azure-cli-latest

Configure network access to a storage account

Azure general-purpose storage accounts have four internal services:

Blob Binary Large Object data; Intended for text and binary data, including log files, media files, database files, VM disks, and so forth

Table NoSQL data storage that is now part of Azure Cosmos DB product family

Queue Reliable messaging service to support a microservices application architecture

File Managed Server Message Block (SMB) file shares for cloud and on-premises servers

The reason why your storage account name needs to be globally unique is that each of those services is bound by default to a public Azure Resource

Manager API endpoint; the well-known URIs are

Blob http://<account-name>.blob.core.windows.net

Table http://<account-name>.table.core.windows.net

Queue http://<account-name>.queue.core.windows.net

File http://<account-name>.file.core.windows.net

Of course, unauthenticated access to any Azure storage account is prohibited by default, and you control access by using role-based access control (RBAC) in Azure Resource Manager.

That said, for greater control over access to storage accounts, you can associate them to a virtual network (VNet) in Azure. Because VNets provide an exceptionally strong isolation boundary in Azure, configuring network integration can give your customer more robust control over storage account access.

For example, you might want to ensure that only VMs resident on Contoso-vnet can interact with your storage account. Follow these steps to complete this configuration:

1. In the Azure portal, browse to the target storage account and select theFirewalls And Virtual Networks Settings blade.
2. Under Allow Access From, choose Selected Networks.
3. Click Add Existing Virtual Network and choose the VNet and subnetfrom which you want to limit access to this storage account.
4. Optionally, under Firewall add IP addresses/address ranges from otherclients outside the VNet that need access to the storage account. You can see the Firewalls And Virtual Networks interface in Figure 1-6.

Note

Allowing Trusted Microsoft Services to Access the Storage Account

The Firewalls And Virtual Networks blade has an option, enabled by default, called Allow Trusted Microsoft Services To Access This Storage Account. This option allows connectivity to the storage account from other Azure services, such as Azure Monitor, Azure Backup, and Azure Event Hubs.

If you don’t want to allow this extra traffic, untick this check box, but be aware you may have extra work to do if you find any existing storage account integrations suddenly broken or unresponsive.

Implement Azure storage replication

Azure storage replication is what makes your storage accounts highly available. The redundancy option you suggest to your customers depends on their own availability service-level agreements (SLAs) as well as how farreaching the high availability should be. Here are the storage account redundancy options:

Locally redundant storage (LRS) Azure makes three copies of the storage account and distributes them throughout a single datacenter in your home region. Here you have protection against the failure of a storage array.

Zone-redundant storage (ZRS) Azure makes three copies of the storage account and distributes them across multiple datacenters in your home region. Here you have protection against datacenter-level failures. Note that only General Purpose v2 storage accounts can use the ZRS replication option.

Geo-redundant storage (GRS) Azure makes three copies of the storage account in the home region, and three copies in a second, paired region. Paired regions are geographically close enough to have high-speed connectivity to reduce or eliminate latency. Here you have protection against regional failures.

Read-access geo-redundant storage (RA-GRS) Same as GRS with the exception that you can access the storage account in the secondary region; the base URL path is https://<account-name>secondary.<service>.windows.net.

Need More Review?

Azure Region Pairs

To learn more about what paired Azure regions are and how they work, visit the Microsoft Docs article “Business continuity and disaster recovery (BCDR): Azure Paired Regions” at https://docs.microsoft.com/en-us/azure/best-practices-availability-paired-regions

To illustrate, the following command for Azure PowerShell sets the stockkeeping unit (SKU) for a storage account to RA-GRS:

	Set-AzStorageAccount -Name tlwstor170 -ResourceGroupName contoso -SkuName

Install and use Azure Storage Explorer

Azure Storage Explorer is a free, cross-platform, closed-source desktop application designed by Microsoft. The tool makes it simple to interact with your Azure storage accounts. Storage Explorer is even built into the Azure portal�"simply browse to one of your storage accounts and select the Storage Explorer setting.

You can download Storage Explorer from the Microsoft website; the Windows, macOS, and Linux graphical installers take about 30 seconds to complete. Easy!

At first launch, you’re required to authenticate to Azure; connection to Azure public cloud as well as Azure Government is supported. Take a look at Figure 1-7, which demonstrates the Azure Storage Explorer interface. We explain each annotation immediately afterward:

A Switch between the Explorer and Accounts views.

B Browse your storage accounts and/or other local or remote Azure assets.

C View properties of selected item; the Actions window displays the same option as right-clicking an object.

D Multitab interface to view more than one storage object simultaneously.

E Robust toolbar with upload/download/query controls.

F Get into the habit of right-clicking objects to see which actions are possible.

You can use the toolbar or drag and drop to upload and download blob objects. The built-in query interface makes it easier to run queries against table storage.

Manage access keys

Each Azure storage account has two interchangeable, 512-bit access keys that you can use to gain programmatic access to your storage account. It’s considered best practice to rotate these keys regularly.

The following sample code shows how you can retrieve both keys programmatically by using Azure PowerShell:

	
Get-AzStorageAccountKey -name 'tlwstor170' -ResourceGroupName contoso
KeyName Value
------- -----
key1 3oDnt7cci/O4/z1ED/uAEwDsU
key2 OMvF4SytaytFJ+U2qh/NGNtC
	

Exam Tip

You may be asked to remember on the AZ-300 exam that you also can store your storage account access keys in Azure Key Vault to simplify key management. For more information on Key Vault-managed storage accounts, see the docs article “Azure Key Vault managed storage account PowerShell” at https://docs.microsoft.com/en-us/azure/key-vault/secrets/overview-storage-keys-powershell

Generate a shared access signature

Azure developers use Azure software development kits (SDKs), Azure PowerShell, or another method to programmatically retrieve access keys to gain authorized access to storage account resources.

But what if you’re unwilling to share an access key? A shared access signature (SAS) represents a way to grant limited, time-bound access to individual storage account objects or potentially entire blob service containers.

Specifically, a SAS is a URL that consists of the following components:

Protocol Will be HTTP or HTTPS; you can optionally require

HTTPS only.

Address Fully qualified path to the storage account object.

Permissions Standard CRUD (create, read, update, delete) operations.

Time interval As long as the time interval hasn’t expired, anybody on Earth can use the SAS URI. Therefore, you need to be careful in how you create and manage them.

Say you need to provide programmatic access to a JavaScript file named library.js that resides in a container named assets in an Azure storage account named contosostorage704. We can use the following procedure to complete SAS creation by using Storage Explorer:

1. In Storage Explorer, browse to the assets container and locate the targetfile.
2. Right-click Library.js and select Get Shared Access Signature from theshortcut menu.
3. Complete the Shared Access Signature dialog box as shown in Figure 1-8. Note that you specify start and end times that define the SAS token lifetime; you also add appropriate permissions.

An access policy is essentially a template that defines SAS properties; access policies make it easier to create multiple SAS URIs that share the same settings.

A container-level SAS URI can be dangerous because you open up access to all objects in the current blob container instead of only a single object.

In our case, the resulting SAS URI looks like this:

	
https://contosostorage704.blob.core.windows.net/assets/library.js?st=2019-06-07T18%3A54%
3A37Z&se=2019-06-07T19%3A54%3A00Z&sp=rl&sv=2018-03-28&sr=b&sig=8B7kWwmysPNu0ZDoHslAgBfFv
P5CT9PvCoxf0y5fXBs%3D
	

See that long value after the &sv query string parameter? That’s a digital signature. If you change a single character in an SAS URI, it breaks the signature and the SAS URI will no longer work.

Monitor the Activity Log by using Log Analytics and Azure Monitor

Earlier in this chapter, we reminded you that the Activity log is where Azure tracks control-plane actions—essentially, who took what action while in your Azure subscriptions. This exam objective lets you know you can collect and analyze Activity log data from multiple subscriptions by using a Log Analytics workspace in Azure Monitor.

Recall that a Log Analytics workspace is a data warehouse, to which you can link different Azure resources and configure the resources to send their data to the workspace. You then use KQL queries to generate reports on the aggregated data.

Although a single Activity log can be connected only to one workspace at a time, a single workspace can be connected to the Activity log from multiple subscriptions that trust the same Azure Active Directory tenant.

Here’s the high-level overview of the configuration:

1. In the Azure portal, browse to your chosen Log Analytics workspace,and select the Azure Activity log setting under Workspace Data Sources.
2. Use the Subscription filter to display an Azure subscription you want toassociate with the workspace.
3. In the subscription list, select the subscription and click Connect. Figure 1-9 shows two subscriptions that emit Activity log data into this workspace.

You are then free to write KQL queries in the Azure Monitor log search interface, or install the Activity Log Analytics management solution as your needs dictate. For example, the following KQL query shows the total number of Azure resources that write to the Activity logs and lists the top ten resources with record counts:

	
AzureActivity | summarize AggregatedValue = count() by Resource
	

Skill 1.3: Create and configure a virtual machine for Windows and Linux

Thus far, you’ve worked with Azure diagnostic data streams and Azure storage. Now it’s time to focus on what is likely the first cloud feature most businesses turn to first �"infrastructure as a service (IaaS), otherwise known as “virtual machines running in the cloud.”

This skill covers how to:

• Configure high availability
• Configure monitoring, networking, storage, and VM size
• Deploy and configure scale sets

Configure high availability

Azure solution architects must remember that availability is a different metric from uptime. Just because a server receives power and is in a started state does not mean that the services offered by the host are functional.

The next sections review ways you can provide various high-availability guarantees to your VM environment in Azure.

Availability sets

If you deploy two or more VM instances into the same availability set, Microsoft provides a 99.95 percent availability SLA. Normally the architectural pattern is to place VM instances of a particular class (for example, web servers) into their own availability set during VM deployment.

Warning

Availability Set Assignment

You can add VM instances to an availability set only during VM deployment. If you forget, you’ll need to redeploy the VM.

An availability set is a logical container that ensures that your VM instances reside on different hardware hosts on separate racks in your Azure regional datacenter. Availability sets provide protection against

Planned maintenance For instance, if Microsoft needs to restart the hardware host on which your VM resides or take the hardware host offline

Unplanned maintenance Top-of-rack switch failures, power failures

Because the availability set and its members reside in a single datacenter, this architecture can’t protect your VMs at the region level.

Availability zones

Availability zones are a newer entry to the Azure high-availability family. Here, you place your VM instances in separate datacenters within the same Azure region. Microsoft connects datacenters within the region with additional, redundant, high-speed network interconnects to ward against latency issues.

Note

Availability Sets and Availability Zones

You can’t combine availability sets and availability zones.

Availability zones aren’t available for every Azure region, so you need to perform due diligence research with your customers to choose an appropriate region if availability zones are a requirement.

Availability zones protect your VMs against host, switch, rack, and datacenter failures. They don’t protect against regional failures.

To provide regional high availability, you should consider deploying additional VM instances to a separate Azure region and using Azure Traffic Manager and Azure public load balancers to direct traffic interregionally.

You can see an example of this topology in Figure 1-10.

Single-instance SLA

If you’re willing to use high-speed premium storage for your VMs, then you can take advantage of Microsoft’s 99.9 percent availability guarantee with single-instance VMs. Here you don’t have to use availability sets to attain reasonable high availability.

Configure monitoring, networking, storage, and VM size

Monitoring your Windows and Linux VMs in Azure can take two directions:

Azure Diagnostics Here you deploy the VMDiagnosticsSettings agent to the VM and collect various guest operating system metrics

and log data.

Log Analytics Here you deploy the Microsoft Log Analytics agent and connect the VM to a Log Analytics workspace.

The advantage of the latter approach is that you can centrally query your VMs from the Azure Monitor log search interface using the previously described KQL. Follow these steps to connect your VM to an existing Log Analytics workspace:

1. In the Azure portal, browse to your Log Analytics workspace.
2. Under Workspace Data Sources, click the Virtual Machines setting.
3. Locate the VM you want to onboard to Log Analytics, and then selectthe VM. The VM should show a Not Connected status.
4. Click Connect. In Figure 1-11 you can see one VM that is connected to the workspace and one that is not.

With respect to VM networking, you can handle most configuration directly from the Networking blade inside the VM’s settings in the Azure portal, shown in Figure 1-12.

Recall that the networking-related VM elements include the following:

Virtual network interface card (vNIC) A VM can be associated with one or more network interfaces; the interfaces, in turn, can have one or more IP configurations.

Private IP address This IP address originates from the virtual network and subnet on which the VM resides.

Public IP address Optional, but this type of address makes the VM directly reachable from the public Internet.

Network security group (NSG) This software firewall defines inbound and outbound traffic rules. NSGs can be associated with both network interfaces and VNet subnets.

Concerning VM storage, you should recommend your customers use managed disk storage for their VMs and not use traditional storage accounts. Managed disk storage simplifies virtual hard disk management, backup, and security.

Managed disks can be used with standard or premium disk storage. All three VM disk types are also supported: operating system, temporary, and data.

Resizing a VM is a great way to save money and/or “right-size” your VM for its designated workloads. You can resize a VM in all the usual ways; let’s use Azure PowerShell in this example.

First, list the VM sizes that are available in the VM’s region:

	
Get-AzVMSize -ResourceGroupName 'Contoso' -VMName 'vm1'
	

Second, capture a reference to the target VM in a variable; set the VM’s VmSize property to the chosen new size; and update the VM’s configuration to “set” the change:

	
$vm = Get-AzVm -ResourceGroupName 'Contoso' -VMName 'vm1'
$vm.HardwareProfile.VmSize = 'Standard_D32s_v3'
Update-AzVM -VM $vm -ResourceGroupName 'Contoso'
	

Note

Vm Resize Operation

Note that Azure restarts your VM to perform the resize operation. Be sure to schedule the resize operation during a known, designated maintenance window.

Deploy and configure scale sets

One question to ask Azure architecture clients is, “Are you positive you want to run your workload in VMs?” As you know, IaaS isn’t the most horizontally scalable technology.

By contrast, Azure App Service applications can easily autoscale horizontally and potentially vertically; that’s one of the greatest benefits of platform as a service (PaaS).

The virtual machine scale set (VMSS) is a way to manually or

automatically scale a group of identically configured virtual machines.

Some businesses use scale sets to provide high availability; other companies use scale sets to grind through large batch jobs, taking advantage of both big compute and parallel processing.

Follow these steps for the high-level overview of creating a VM scale set in the Azure portal:

1. In the Azure portal, click Create A Resource and search the AzureMarketplace for the Virtual Machine Scale Set template.
2. In the Create Virtual Machine Scale Set dialog box, provide baselineproperties:

VM Scale Set Name; each node receives a host name based on the scale set name (for instance, vmss_0, vmss_1, and so forth).

OS disk image (Windows Server and Linux are supported).

Subscription.

Resource group.

Location.

Availability zone; a single scale set can span availability zones.

Administrator username and password.

3. Select a starting instance count and instance size. Remember you willbe charged the standard per-minute run time for each running instance in your scale set.
4. Decide whether low-priority VMs are an option. Microsoft gives you aprice break by running your workload using unused compute capacity in your Azure region. However, these VMs can be reclaimed by Microsoft at any time, so you need to be sure the workload your scale set processes is truly stateless.
5. Configure autoscale rules. Scale set autoscale has the followingconfigurable properties:

Minimum and maximum number of VMs

CPU percentage that defines the scale-out and scale-in thresholds

Choose a load balancer option. You need either an Azure public load balancer or an Azure application gateway to put in front of your scale set so you have a single entry point into the scale set.

With respect to configuring the scale set to run your workload, there are two factors to keep in mind:

Your workload should rely upon external storage and be stateless; the idea is that it shouldn’t matter which scale set node processes any particular task. You don’t want to have workload data permanently resident on your nodes.

You normally manage the scale set from a jump box VM that you place on the scale set’s virtual network.

Take a look at the architectural drawing in Figure 1-13. All the workload components reside in a storage account, and all scale set configuration/management takes place via the jump box VM.

Skill 1.4: Automate the deployment of virtual machines

Now it’s time to review how you can use infrastructure as code to automate VM deployment in Azure. Recall that every Azure Resource Manager (ARM) deployment is recorded in JavaScript Object Notation (JSON). In this section, you use ARM templates to make your VM deployments repeatable, dependable, and fast.

This skill covers how to:

• Deploy Windows and Linux VMs from a template
• Save a deployment as an ARM template
• Modify Azure Resource Manager templates

Deploy Windows and Linux VMs from a template

Visual Studio isn’t a tool intended only for developers. As long as you install the Azure workload, Visual Studio is a terrific ARM template editor. Here we use Visual Studio 2019 to create a simple VM by using a brand-new, built-in deployment template.

1. In Visual Studio 2019, click File > New > Project.
2. In the Create A New Project dialog box, search for resource group, and select the Azure Resource Group project template.
3. Give the template a meaningful name, choose a project storagelocation, and click Create.
4. In the Select Azure Template window, set the Show Templates FromThis Location filter to Visual Studio Templates, select the Windows Virtual Machine template, and click OK to set up the environment.
5. Open the WindowsVirtualMachine.json template file and fill in theparameter values. This template has the following parameters:

adminUsername Built-in administrator name

adminPassword Built-in administrator password

dnsNameForPublicIP Public IP address you use to connect to the

new VM after you deploy it

WindowsOSVersion Template that includes an allowedValues array that constrains the OS versions the administrator can select

To validate the template, right-click the template in Solution Explorerand select Validate from the shortcut menu.

Fill in the Validate To Resource Group dialog box. You need toauthenticate to Azure and choose a new or existing resource group to house the deployment.

Keep an eye on the Output window; if validation completes, you candeploy the VM to Azure by right-clicking the project in Solution Explorer and selecting Deploy from the shortcut menu.

In Figure 1-14 you can see the Validate To Resource Group dialog box as well as partial output from a previous validation in the Visual Studio Output window. I added annotation steps to make the template validation workflow clearer.

Specifically, in (1), you right-click the solution and select Validate from the shortcut menu. You then (2) fill out the deployment metadata, including clicking Edit Parameters to (3) specify deployment-specific input data.

Exam Tip

You need to have intermediate-level familiarity with JSON and the structure of ARM templates to be successful on your AZ-300 certification exam. You can expect to see JSON code on the test, and you’ll be asked to interpret it.

What’s so nice about ARM template deployment is that once you have your deployment correct, you can repeat the deployment with no additional debugging effort.

Save a deployment as an ARM template

The Azure portal makes it easy to save the underlying ARM template for any new or existing deployment.

Let’s say your customer needs to create 100 storage accounts. As an architect, you can save the customer lots of time by instructing them to create the first storage account, with all requisite properties, in the Azure portal.

However, you also need to instruct them to click Download A Template For Automation just prior to clicking Create on the Review + Create screen. This action opens the Template blade as shown in the annotated Figure 1-15.

The annotations in Figure 1-15 are important:

A Download the JSON template, parameter file, and deployment helper scripts as a single ZIP archive.

B Add this deployment template to an Azure portal-based library stored in your subscription.

C Deploy the template directly from within the Azure portal.

D Edit the underlying JSON.

E JSON outliner, making it easier to navigate the source code.

To save the underlying template for an existing Azure resource, open it in the Azure portal, locate the Export Template settings, and click Download.

Modify Azure Resource Manager templates

The Azure Quickstart Templates gallery (https://azure.microsoft.com/enus/resources/templates/) should be a regular stop for any Azure cloud solution architect. As of this writing, the gallery has 784 prebuilt templates, ranging from simple (deploying a single storage account) to the enormously complex (deploying a three-tier web application with load balancers, gateways, and custom routing).

Note

Caveat Emptor

The authors who publish to the Azure Quickstart Templates gallery include both Microsoft employees and general community members. Please be sure to read each template carefully prior to using them. Also, understand that Microsoft attaches no SLA or other support to these templates.

Follow these steps to edit an Azure Quickstart Template by using nothing other than your web browser and the Azure portal:

1. Make sure you have logged into the Azure portal with appropriatepermissions in the current browser session.
2. In another tab, browse to https://azure.microsoft.com/enus/resources/templates/, and in the Search box, type basic Windows web app, and press Enter.
3. Select the Deploy A Basic Windows Web App template.

The template page includes some interesting controls and metadata:

Deploy to Azure Launch a custom deployment in the Azure portal in the current browsing session.

Browse on GitHub All the templates are housed fundamentally in a GitHub repository.

Parameters Inspect the parameters the author included in the template.

Use the template Azure PowerShell and Azure CLI sample code show you how to deploy the template.

4. Click Deploy to Azure. This action should spawn another browser tab,

log you into the Azure portal under your current credential, and show the Custom Deployment blade.

Fill out the Basics and Settings areas. Basics represents thesubscription, resource group, and location; Settings lists the parameters defined in the underlying template.

Alternatively, you can click Edit Template or Edit Parameters to view and modify the template’s underlying source code. Be sure to save your changes!

Agree to the Microsoft terms and conditions (you may have to scrollthe Custom Deployment blade to the very bottom), and then click Purchase to validate and submit the deployment to Azure Resource Manager.

Configure the location of new VMs

Perhaps the most straightforward way to prevent deployment to disallowed

Azure regions is by means of an Azure Policy. Let’s say you want to bind an Azure Policy to your ‘lobapp’ resource group that requires deployments to occur only in the East US and East US 2 regions. Let’s accomplish this task with Azure PowerShell.

First, you will create a policy definition at the subscription scope. Here it makes sense to use the built-in Allowed Locations policy, which you fetch from its GitHub repository on the web:

	
$definition = New-AzPolicyDefinition -Name "allowed-locations" -DisplayName "Allowed
locations" -Policy 'https://raw.githubusercontent.com/Azure/azure-policy/master/samples/
built-in-policy/allowed-locations/azurepolicy.rules.json' -Parameter
'https://raw.githubusercontent.com/Azure/azure-policy/master/samples/built-in-policy/
allowed-locations/azurepolicy.parameters.json' -Mode Indexed
	

Next, you change your target scope to the lobapp resource group:

	
$scope = Get-AzResourceGroup -Name 'lobapp'
	

Then, you set the policy parameter:

	
$policyparam = '{ "listOfAllowedLocations:: { :value": [ "eastus", "eastus2
	

Finally, you create the policy assignment:

	
$assignment = New-AzPolicyAssignment -Name 'allowed-locations-assignment' -DisplayName
'Allowed locations Assignment' -Scope $scope.ResourceId -PolicyDefinition $definition
-PolicyParameter $policyparam
	

Configure VHD templates

You want to deploy a new virtual machine in Azure by using an ARM template, but instead of using an Azure Marketplace gallery image, you want to use a generalized VHD you have stored in your managed disk library or storage account.

Two ways to get your generalized VHD into Azure are

Use AzCopy and Azure Storage Explorer to upload your on-premises generalized VHD to the blob service of a storage account

Use the Azure portal to capture a generalized VM image and store the image in your managed disks library

Need More Review?

Uploading On-Premises VHDs to Azure

To learn more about the “hows and whys” of generalizing and uploading on-premises VHDs to Azure, visit the Azure docs article “Prepare a Windows VHD or VHDX to upload to Azure” at http://timw.info/vhdx.

In this example, imagine you have a Windows Server 2019 generalized

image in your Azure subscription’s managed disk library. Your goal is to make an ARM template to simplify deployment of new VMs based on the custom image template. Follow these steps:

1. Create a new Resource Group deployment in Visual Studio 2019.
2. In the Select Azure Template dialog box, set the Show Templates FromThis Location filter to Azure QuickStart, and load the template 201vm-specialized-vhd-new-or-existing-vnet.
3. As shown in Figure 1-16, find the parameter osDiskVhdUri. This string value accepts the full URI of the VHD template. You can fetch your image URL from the Images blade in the Azure portal or the blob container as appropriate.
4. How you populate the osDiskVhdUri parameter is up to you; you couldtake any of the following actions:

Add a DefaultValue key-value pair to the main template file

Populate the parameter and its value in the template parameter file

Specify the parameter value at deployment time

Speaking of deployment time, you should quickly review how to use Azure PowerShell to deploy an ARM template. Assuming your template and parameter files exist on your local computer, you can use the following PowerShell command to validate and then deploy the template to Azure by using an existing resource group:

	
New-AzResourceGroupDeployment -Name 'CustomVMDeployment' -TemplateFile '.azuredeploy.
json' -TemplateParameterFile '.azuredeploy.parameters.json' -Mode Incremen
	

Exam Tip

Remember that ARM templates can have any name. The file names azuredeploy.json and azuredeploy.parameters.json are simply Microsoft’s common convention. On the AZ-300 exam, you will likely see templates with different names.

Skill 1.5: Implement solutions that use virtual machines

This section continues the ARM template discussion and also reviews how to apply whole-disk encryption to your VMs running in Azure.

This skill covers how to:

• Provision VMs with a new ARM template
• Configure disk encryption for VMs

Provision VMs with a new ARM template

You can always do Azure deployment work from scratch. Let’s finish this section by buzzing through how to get started with an ARM template “from scratch” by using Visual Studio Code.

Visual Studio Code is a free, open-source, cross-platform code editor. Download the software from https://code.visualstudio.com and install it on your development workstation; then use VSCode’s Extensions tool to add the following extensions:

PowerShell Unlocks PowerShell language and debugging support

Azure Resource Manager Tools Unlocks IntelliSense and debugging support for Resource Manager templates

Azure Account Simplifies VSCode Azure authentication and session management

Azure Resource Manager Snippets Contains a library of handy JSON code segments to make your ARM template development easier

In this example, you use VSCode to create a new ARM template that deploys a storage account.

1. In VSCode, open the Command Palette and type Azure: Sign in to authenticate to your Azure subscription.
2. In the Command Palette, type Azure: Select Subscriptions and ensure your target subscription is enabled.
3. Click File > New File, and save the file using a meaningful name (forinstance, new-storage-account.json).
4. Place your cursor in the first row of the file and type arm. You should see a list of ARM snippets. Select the snippet arm! to create a new “skeleton” template.
5. Modify the template to make it more flexible. Edit its source code tomatch the following:

	
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/
deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountType": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS",
"Standard_GRS",
"Standard_ZRS",
"Premium_LRS"
],
"metadata": {
"description": "Storage Account type"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {
"storageAccountName": "[concat('store', uniquestring(resourceGroup().id))]"
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[variables('storageAccountName')]",
"location": "[parameters('location')]",
"apiVersion": "2018-07-01",
"sku": {
"name": "[parameters('storageAccountType')]"
},
"kind": "StorageV2",
"properties": {}
}
],
"outputs": {
"storageAccountName": {
"type": "string",
"value": "[variables('storageAccountName')]"
}
}
}
	

At this point your VSCode environment should match Figure 1-17.

Here’s an explanation of the preceding code in case you need any additional elucidation:

$schema Required. Defines the location of the underlying schema against which you validate this template.

contentVersion Required, but not used by Azure. This is for your own use in versioning the file over its lifecycle.

parameters Optional, but extremely useful to make the template portable.

variables Optional, but useful to simplify resource naming.

resources Required because this is where you deploy the Azure resources to be deployed.

outputs Optional, but useful at times to display post-deployment metadata to the script runner.

Figure 1-17 ARM template development in Visual Studio Code

Check the Problems pane in the VSCode terminal to see whether any ARM template validation errors exist. In this particular template, you’re likely to see one problem: “String is longer than the maximum length of 24.”

You can ignore this error because if you check the source code, the storage account name is derived from a call to the storageAccountName variable, which will be less than the storage account’s maximum name length of 24 characters.

6. When you’re ready to deploy, run New-AzResourceGroupDeployment in the terminal as shown previously.

Need More Review?

Arm Template Structure Help

If you need to brush up on ARM template structure, visit the Azure docs article “Understand the structure and syntax of Azure Resource Manager templates” at http://timw.info/arms.

Configure disk encryption for VMs

To satisfy your organizational security policies, you can apply whole-disk encryption, called Azure Disk Encryption (ADE), to your Windows Server or Linux VMs running in Azure. You can encrypt the OS disk as well as any data disks.

The encryption technology depends on the guest operating system: Windows VM disks are encrypted with BitLocker Drive Encryption, whereas Linux VM disks are encrypted with the open-source DM-Crypt library.

You need to provision an Azure Key Vault before using ADE because Azure needs a secure location for the disk encryption keys. The key vault needs to reside in the same region as your target VMs.

Encrypt the operating system and data disks of a running VM by running the following Azure CLI command:

	
az vm encryption enable --resource-group "Contoso" --name "vm1" --disk-encryptionkeyvault "CorpVault" --volume-type All
	

Skill 1.6: Create connectivity between virtual networks

Virtual networks (VNets) in Microsoft Azure represent strong security boundaries for your Azure resources. By default, VMs running in one VNet have no routing path to VMs running in another VNet. This is by design.

So what do you recommend to a customer who has a business need to connect VNets? Well, Microsoft provides two options:

VNet peering

VNet-to-VNet virtual private network (VPN) This section looks at each option in turn.

This skill covers how to:

• Create and configure virtual network peering
• Create and configure VNet-to-VNet VPN
• Verify virtual network connectivity

Create and configure virtual network peering

Azure global VNet peering allows you to connect two virtual networks without the overhead and cost associated with a VPN gateway. Peering is a good choice when a business needs to link VNets and has no requirement for end-to-end encryption.

The “global” part of this feature name signifies that the two VNets to be peered can exist in the same region, different regions, or even across subscriptions. All network traffic occurring over the peer relationship is private and takes place strictly on the Microsoft Azure network backbone.

If VNet Spoke 1 is peered with VNet Hub, and then VNet Hub is peered with VNet Spoke 2, resources in VNet Spoke 1 cannot communicate directly with resources in VNet Spoke 2 because VNet peerings are nontransitive. Transitivity can become an issue with hub-and-spoke VNet architectures, as shown in Figure 1-18. You can force transitivity by linking user-defined routes (UDRs) to each spoke VNet and forcing traffic through a network virtual appliance (NVA) located in the hub VNet.

Follow this procedure in the Azure portal to create a peering between two VNets in Azure:

1. Locate the first of the two VNets you want to peer. The sequence heredoesn’t matter; what’s important is that you need to configure the peering for both VNets.
2. In the first VNet’s Settings blade, click Peerings, and then Add.
3. In the Add Peering blade, shown in Figure 1-19, complete the form:

Name Choose a descriptive name, preferably that defines the peering directionality (for instance, hub-to-spoke1).

PeerDetails Specify the deployment model, and whether you want to use a resource identifier (ID) to locate the other VNet. This option is necessary if you don’t have read access to the destination VNet.

Subscription Recall that global VNet peering works across Azure subscriptions and regions.

Virtual Network Choose the VNet that will reside on the other side of the peering.

Allow Virtual Network Access From The VNet names will be specific to your environment, of course. This option needs to be enabled for VNet peering to work. Disable the option when you need to pause peering, typically for troubleshooting or security response purposes.

Allow Forwarded Traffic From Enable this option to allow traffic forwarded to your current VNet to be forwarded to the VNet peer.

Allow Gateway Transit Enable this option to allow the peered VNet to allow the current VNet’s VPN gateway. In other words, enable this option only on your hub VNet.

Use Remote Gateways This option is mutually exclusive from Allow Gateway Transit. You enable this option when you need to allow the local spoke VNet to forward traffic through a hub VNet, typically across a site-to-site VPN to an on-premises network.

4. Click OK to complete the configuration.

Please don’t forget that you need to configure the peering on the other VNet as well! Once Azure completes the configuration, you can see it on each VNet’s Peerings blade. The Peering Status property should show as Connected.

Create and configure VNet-to-VNet VPN

Before Microsoft announced global VNet peering in Fall 2018, the only option Azure architects and administrators had for cross-region VNet peering was the VNet-to-VNet VPN.

Now, Azure solution architects can recommend the VNet-to-VNet VPN only when it is feasible to do so. The Azure VPN Gateway is a softwaredefined networking virtual device that forms one side of an Internet Protocol Security (IPSec) VPN tunnel.

As you can see in Figure 1-20, VNet-to-VNet VPN connections fit “hand in glove” with site-to-site VPNs in a hybrid cloud environment. Although VNet-to-VNet VPNs are significantly more expensive than VNet peerings, your organizational security and compliance requirements may require you to configure an environment this way.

Follow these steps to configure a VNet-to-VNet VPN in the Azure portal:

1. In the Subnets blade in each VNet’s Settings, click Gateway Subnet todefine a gateway subnet in each VNet. This empty subnet contains private IP addresses used by the Azure VPN Gateway. Microsoft recommends you use a Common Inter-Domain Routing (CIDR) block of /27 or /28.

2. Open the Virtual Network Gateways blade and click Add.
3. In the Create Virtual Network Gateway blade, complete the form. Some of your key architectural choices include the following:

Gateway Type An Azure VPN Gateway is used to create either a VPN or an ExpressRoute connection.

VPN Type You have two routing types to choose from:

Route-Based Uses routing tables to make traffic routing and encryption decisions. This VPN type is more widely supported in Azure and with on-premises hardware.

Policy-Based Uses static routes. This VPN type is intended for compatibility with older on-premises VPN concentrator hardware. Accordingly, its feature set is much smaller than route-based gateways.

SKU Higher SKU values denote higher service level (and, accordingly, cost):

Basic Intended for proof of concept (POC) or development workloads.

VpnGw1-3 Supports BGP, up to 30 site-to-site VPN connections and up to 1.25 gigabits per second (Gbps) throughput for the Gw3 SKU.

VpnGw1-3AZ These SKUs have the same feature set as VPNGw1-3 but are availability-zone aware.

Enable Active-Active mode This setting is used when you configure high-availability failover for an Azure VPN Gateway.

Virtual Network This is the VNet to which the Azure VPN Gateway will reside; Azure will place the gateway in the gateway subnet you created earlier.

Public IP Address This is the public-facing endpoint for your Azure VPN Gateway.

Configure BGP ASN You need to assign a Border Gateway

Protocol Autonomous System Number (BGP ASN) for advanced configurations; we do not need it for a VNet-to-VNet VPN.

Click Create to complete the configuration. Note that Azure VPN Gateway deployment can take quite a while (up to 1 hour on average).

Remember also to repeat these steps to deploy another Azure VPN Gateway on the other VNet.

Need More Review?

Highly Available VPN Gateways

To learn more about configuring high-availability failover for

Azure VPNs, read the Microsoft Docs article “Highly Available Cross-Premises and VNet-to-VNet Connectivity” at https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gatewayhighlyavailable.

Define connections

Simply deploying the Azure VPN Gateways is only step 1 of 2 in our VNetto-VNet VPN configuration journey. Next, you have to define your connections:

1. Open the first gateway’s Settings in the Azure portal, selectConnections, and click Add.
2. Fill out the Add Connection form:

Connection Type Choices include VNet-to-VNet, Site-to-site (IPSec), and ExpressRoute.

Second Virtual Network Gateway Select the other VNet’s gateway. Note that the First Virtual Network Gateway property points to the local device and is read-only.

Shared Key (PSK) This is a (hopefully) strong passphrase you attach to each gateway to serve as a basic mutual authentication method.

3. Click OK to complete the configuration.

After you’ve configured the connection, your work is finished. You do not need to define a second connection resource for the other VNet. The connection status should appear as Connected in the Connections blade for both Azure virtual network gateways.

Verify virtual network connectivity

A common misconception among newer Azure architects and administrators is that simply defining a peering between two Azure VNets means instant connectivity between them. Not so fast!

Remember that you should have network security groups (NSGs) protecting ingress (incoming) and egress (outbound) traffic through each subnet. Recall, also, that your VMs may have software, host-level firewalls enabled that filter inbound and potentially outbound traffic as well.

Note

Be Mindful of Default NSG Security Rules

If you enable default security rules for your NSG, you need to remember that two of these rules (AllowVNetInBound and AllowVnetOutBound) explicitly allow inter-VNet traffic. In the name of least-privilege security, you must work to ensure only required traffic flows are authorized in your Azure design.

Finally, be aware that only VNet-to-VNet VPNs support name resolution for VMs on either side of a connection. If you’re doing peering, you need to take additional steps to support name resolution because Azure-provided name resolution can’t function across a peering. You can configure the following:

A private Azure DNS zone This is a nonroutable Domain Name system (DNS) zone you can attach to both VNets.

DNS servers Here you deploy a DNS server VM in each VNet, and configure each to forward name resolution requests to the other VNet’s name server. If you go this route (so to speak), make sure to update each VNet’s DNS server list accordingly.

Network Watcher

Network Watcher is a tremendously useful tool for testing connectivity between virtual networks in Azure. First enable Network Watcher for your target Azure regions by browsing to the Network Watcher Overview blade, right-clicking a region, and selecting Enable Network Watcher from the shortcut menu.

You can then use IP flow verify in Network Watcher to test connectivity between any two IP addresses. As a solution architect you will find Network Watcher in general and IP flow verify in particular to be invaluable in tracking down inter-VM connectivity issues.

Figure 1-21 illustrates a network test we conducted with two VMs in two peered VNets. Here are some of the key IP flow verify options:

Virtual Machine In the environment, vm1 resides on the local VNet; we want to test connectivity on Transmission Control Protocol (TCP) port 3389 (Remote Desktop Protocol) between vm1 and vm2, which resides on a peered VNet.

Network Interface Remember that in Azure, IP addresses are associated with virtual network interface cards, not virtual machines.

Direction Outbound tests connectivity from the local system to the remote; inbound tests the opposite flow.

Remote IP Address This is the remote node’s public or private IP address. In our environment, 10.2.0.4 is the private IPv4 address of vm2, which resides in a peered VNet.

Access Allowed In Figure 1-21, access is allowed by virtue of the AllowVnetOutBound NSG rule in the routing path.

Skill 1.7: Implement and manage Azure virtual networking

It’s time to take a step back from VNet peering and examine virtual networks more generally in Azure. An AZ-300 exam objective is concerned with configuring already created VNets, so that’s a good place to begin.

This skill covers how to:

• Configure virtual networks
• Configure network interfaces and IP addresses
• Configure network routes

Configure virtual networks

As an architect, one of your job tasks is to help customers determine how many VNets they require to serve their business, technical, and security requirements. For instance, I have customers who maintain two identically configured VNets: one for production and the other for dev/testing.

Alternatively, a business may want a hub-spoke design pattern to save money and create stronger administrative boundaries among workloads. The following sections describe some of the more common virtual network configuration settings.

Address space and subnets

A customer can have up to 1,000 virtual networks per Azure region, per subscription. A virtual network can have more than one top-level Internet Protocol version 4 (IPv4) address space (useful when transitioning between address spaces, for example). However, once defined, you can’t edit an existing address space.

Exam Tip

The Microsoft Azure certification exams won’t require that you recite specific service limit numbers. From what Microsoft Learning has said, their exam writers want to test your knowledge at a higher degree of sophistication.

That said, a worthwhile page for any Azure cloud solution architect’s reference is the Microsoft Docs article “Azure subscription and service limits, quotas, and constraints” at https://docs.microsoft.com/en-us/azure/azure-subscriptionservice-limits.

On the other hand, you can have up to 3,000 subnets per virtual network. That seems like an absurdly high number, but at the least, you should consider spreading each workload tier into its own subnet for better organization and traffic routing.

DNS servers

Azure-provided name resolution enables you to resolve DNS hostnames for all resources within a single VNet. However, to facilitate other name resolution scenarios, such as

Active Directory communications, either within a VNet, between VNets, or between a VNet and on-premises

Ordinary DNS resolution for VMs spread across different VNets you need to configure your VNet properties with the IP address(es) of additional DNS servers.

Note

Don’t Configure VM Networking From within the VM

An all-too-common rookie mistake with TCP/IP configuration of Azure VMs is attempting to set TCP/IP properties such as IP address, subnet mask, default gateway, and DNS server addresses from within the VM.

If you attempt this, you will almost certainly lock yourself out of the VM. The guiding rule is to configure the networking stack of your VMs from outside the VM session. Use Azure portal, Azure PowerShell, Azure CLI, or the ARM REST APIs instead.

Go to your VNet’s Settings list, click DNS servers, and change the DNS Servers property from Default (Azure-provided) to Custom. Next, populate the list with the IP addresses of your custom DNS servers, as shown in Figure 1-22. Please note that Azure-provided DNS will continue to function alongside the custom DNS server addresses you specify here. Specifically, you can configure your custom DNS servers to forward resolution requests to the Azure-provided name servers.

Exam Tip

Know to which Azure resources you can supply custom DNS server IP addresses. The answer is the virtual network and the virtual network interface.

Service endpoints

Service endpoints enable you to secure certain Azure resources to particular virtual networks. This is an architectural trend Microsoft has been focusing on for some time. Because the VNet represents such a strong isolation boundary, and its infrastructure remains on the Azure network backbone, why not make use of the VNet in other contexts?

As of this writing, the following Azure products can be integrated into a virtual network via service endpoints:

Azure Storage

Azure SQL Database

Azure SQL Data Warehouse

Azure Database for PostgreSQL

Azure Database for MySQL

Azure Cosmos DB

Azure Key Vault

Azure Service Bus

Azure Event Hub

Azure Data Lake Store Gen 1

Follow these steps to integrate a general purpose v2 storage account with a virtual network:

1. Find the storage account in question, and click the Firewalls AndVirtual Networks setting.
2. In the Configuration blade, change the Allow Access From option fromAll Networks to Selected Networks.
3. Click Add Existing Virtual Network and select the VNet to which youwant to integrate the storage account. Note that you need to specify a subnet on that VNet before you can click Enable and Add.
4. Click Save to save your configuration. Figure 1-23 shows a completed service endpoint.

Enable the exception Allow Trusted Microsoft Services To Access This Storage Account to whitelist all Microsoft-owned IP addresses. Disable this exception and use the Firewall feature to strictly control access to the storage account from (a) VNet resources; and (b) selected additional IP addresses or IP address ranges.

Note

Allowing Microsoft Services Access

Be careful with the firewall exception Allow Trusted Microsoft Services To Access This Storage Account when you create a service endpoint for a storage account (or for any service endpointenabled resource, actually). You may not want to whitelist all Microsoft-owned IP address ranges in the name of least-privilege security. Instead, use the firewall to create granular IP address rules.

Figure 1-24 summarizes the concepts we’ve been dealing with in this chapter section. Note the following elements in the diagram:

The application is broken into three subnets along tiered lines. This is probably the most common VNet design pattern.

In this deployment, Azure-provided name resolution ensures that all VMs within the virtual network can resolve one another’s DNS hostnames.

We created a storage account service endpoint, which limits access to this storage account from VMs on the VNet.

Configure network interfaces and IP addresses

We mentioned previously that you should teach your customers to perform all VM TCP/IP configuration from outside the VM session itself. To that point, this section reviews how to assign a virtual machine’s network interface public and/or private IP addresses.

1. Locate the network interface that is associated with the VM you wantto configure. You can find the interface from the Network interfaces blade, or by navigating to the Networking blade of the VM resource.
2. In the network interface’s Settings list, click IP Configurations (step 1in Figure 1-25).

By default, every network interface has an initial configuration called ipconfig1. In some cases, you may want to assign a network interface more than one public and/or private IP address; you do this by adding IP configurations.

3. Select the ipconfig1 configuration (step 2 in Figure 1-25); the IP Configurations blade appears.
4. Complete the form (step 3 in Figure 1-25). The options include:

Public IP Address The Azure architecture best practice is to assign a public IP address (called a PIP for short) only when the VM has a legitimate use case to do so. The reason for this is that any VM with a public IP address becomes a potential target of a brute-force access attack.

IP Address Public IPv4 addresses are tracked as separate resources. These public IP addresses can either be reserved (static) or dynamic. If you choose dynamic, remember you can bind a public DNS name to the network interface to make access easier in the event public IP address changes.

Virtual Network/Subnet Recall that a VM’s private IP address comes from its associated VNet address space and subnet ID.

Assignment Dynamic uses Azure-provided Dynamic Host Configuration Protocol (DHCP); Static gives you control over the interface’s private IP address.

Private IP Address It’s up to you to choose a valid, nonconflicting private IP address.

Configure network routes

Earlier in this chapter, we mentioned that VNet peerings are intransitive. This means that, by default, two spoke VNets are unable to communicate through a hub (transit) virtual network.

Remember when we told you that Azure-provided DNS handles name resolution for VMs within a virtual network? Well, Azure system routes are responsible for automatically routing traffic among VMs on different subnets within a VNet.

Azure gives you the ability to create custom route tables that define your own routing paths. Azure route tables are associated at the subnet level.

You can define the following next hop types in an Azure route table:

Virtual network gateway Use this type when you need to force traffic through an Azure virtual network gateway.

Virtual network Use this type when you need greater control of traffic between subnets in a VNet.

Internet Use this type when you need to control Internet-bound traffic.

Virtual appliance Use this type when you need to route traffic

through a central network virtual appliance (NVA), such as an enterprise firewall VM deployed from Azure Marketplace. Figure 1-26 shows the route table route creation workflow.

Need More Review?

Custom Routing in Azure

To learn more about using route tables to customize Azure routing paths, visit the Microsoft Docs article “Virtual network traffic routing” at https://docs.microsoft.com/en-us/azure/virtualnetwork/virtual-networks-udr-overview.

Skill 1.8: Manage Azure Active Directory

Azure Active Directory (Azure AD) is Microsoft Azure’s default cloud- based, multitenant identity platform. In this skill, you make sure you understand the “hows and whys” of several key Azure AD architectural and management tasks.

This skill covers how to:

• Add custom domains
• Manage multiple directories
• Configure self-service password reset
• Implement conditional access policies
• Perform an access review
• Configure Azure AD Identity Protection
• Configure Azure AD Join
• Configure Enterprise State Roaming

Add custom domains

When you create a new Azure subscription, you receive a default Azure AD instance that has the public DNS name tenantname.onmicrosoft.com, where tenantname is a globally unique identifier the subscription owner defines.

You can never get rid of the onmicrosoft.com hostname because this is an attribute Azure uses to identify your tenant. However, for ease of use and compatibility with your identity and access use cases, you can and should bind at least one public DNS name you own to your tenant.

Note

About the Word “Tenant”

By the way, an Azure AD tenant is simply one instance of the Azure AD service. Azure AD is called multitenant because more than one Azure subscription can trust a single Azure AD tenant. By contrast, a single subscription can be associated with only one Azure AD instance at a time.

Follow these steps to associate a public DNS domain with your Azure AD tenant:

1. Browse to your Azure AD tenant, and navigate to the Custom DomainNames setting (step 1 in Figure 1-27).
2. Click Add Custom Domain (step 2 in Figure 1-27).
3. Type your public DNS name. This needs to be a domain that you own,which will become clear in the next step.
4. In your DNS registrar, add a verification mail exchanger (MX) or text (TXT) resource record to your zone file, using the Microsoft-provided values. Don’t worry about causing a denial of service at your domain registrar; after Microsoft verifies you own the domain, you can delete the verification record.
5. 5. Check that the added domain shows as Verified in the Custom DomainNames blade.

You can use a custom domain with Azure AD at any pricing tier, even the Free tier. Once you verified a custom domain, you can use that domain name as a user account suffix. Specifically, some businesses prefer to identify Azure AD cloud users by a naming format that matches their users’ Simple Mail Transfer Protocol (SMTP) email address.

Manage multiple directories

As I mentioned a moment ago, a single Azure AD tenant has a one-to-many relationship with Azure subscriptions. In addition, you can deploy additional Azure AD tenants to suit use cases where complete user/service principal isolation is desired.

When you create a new, stand-alone Azure AD instance, the tenant has limited capability unless and until you associate an Azure subscription with it. To do this, open the Subscriptions blade in the Azure portal, select the subscription that is to be associated with the new Azure AD tenant, and click Change Directory.

In the Change The Directory blade, select the target Azure AD directory, and click Change. Note that changing the directory removes access for all role-based access control (RBAC) users.

To switch your administrative user context to a different directory, open the user menu in the Azure portal and select Switch Directory. The Directory + Subscription blade allows you to perform many time-saving tasks, including

Setting a global subscription filter so that you see data from selected Azure subscriptions

Setting your default Azure AD directory

Setting favorite directories to make them easier to find if you manage multiple Azure AD tenants

Configure self-service password reset

Hosting line-of-business web applications that rely on Azure AD authentication can pose challenges for the Azure solutions architect. For example, you may deploy Azure AD Connect to synchronize on-premises Active Directory user identities to an Azure AD tenant.

The benefit here is that your users can log into your cloud apps by using the same credentials they use on-premises. However, what if you need to give the user the ability to change his or her password in the cloud application?

Self-service password reset (SSPR) is supported in all Azure AD editions. To enable SSPR, follow these steps:

1. In the Azure portal, navigate to your Azure AD blade.
2. Select the Password Reset setting.
3. Choose the desired self-service password reset option. Your choicesare None, Selected, or All.

If you choose Selected, you can enable SSPR for individual Azure AD groups. Otherwise, if you choose All, SSPR is enabled for all Azure AD users in your tenant.

Exam Tip

Keep role-based access control (RBAC) in mind as we work together through this chapter. For instance, to accomplish Azure AD administrative tasks, your Azure AD account should be associated with the Global Administrator Azure AD role.

Give your users the following instructions to reset their Azure AD password:

1. Navigate to the My Apps (https://myapps.microsoft.com) and authenticate if necessary.
2. Open the user menu and choose Profile.
3. On the Profile page (shown in Figure 1-28), click Change Password and follow the instructions.

Password writeback

Self-service password reset affects the Azure AD representation of the user account, but what happens to the on-premises version if you’re in a hybrid cloud environment? This question falls squarely within the Azure solution architect’s wheelhouse.

The solution here is an Azure AD feature called password writeback. Password writeback requires Azure AD Premium P1 or P2 licenses. We cover this subject in more detail later in this chapter.

Implement conditional access policies

Conditional access policy is an Azure AD Premium P1 or P2 feature that allows you to completely shape your Azure AD user’s authentication environment. For example, you might create a policy that allows user login to selected Azure cloud apps based on

Sign-in risk Azure AD Identity Protection assigns each enabled user a risk level based on their past and present logon behavior.

Network location You may require authentication only from whitelisted geographic locations.

Device management You may restrict cloud app access from mobile devices or noncompany issued devices.

Note

How to Upgrade your Azure AD Licensing

Somewhat counterintuitively, you cannot purchase Azure AD licenses from the Azure AD tenant settings, or even the Azure portal itself. Instead, log into the Microsoft 365 Admin Center (https://portal.office.com) using an Azure AD Global Administrator account, select Billing > Purchase Services, locate the appropriate Azure AD SKU, and then click Buy Now.

Follow these general steps to deploy a conditional access policy in your subscription:

1. In the Azure portal, navigate to the Conditional Access blade, and clickNew Policy.
2. In the New blade, complete the form:

Users and groups Scope the policy to particular Azure AD user and/or group accounts.

Cloud apps Enable or deny authentication to specific Azure ADbacked apps in your subscription.

Conditions Here you can shape the authentication environment according to sign-in risk, device platforms, locations, client apps (browser, mobile, and/or desktop clients), or device state (whether the client device is Azure AD-joined).

Grant or block access if all other conditional access policy requirements are true.

Session For Exchange Online and SharePoint Online, use appenforced additional restrictions.

In your practice, you doubtless noticed that conditional access policies work on exclusions and inclusions. For example, you may have a conditional access policy that allows authentication to your Cloud App Users Azure AD group but denies access to the Cloud Interns group, as shown in Figure 1-29.

Exam Tip

You’re highly likely to be asked on your AZ-300 exam about Microsoft’s preferred way to enable Multi-Factor Authentication (MFA) for your Azure AD users. The answer to this is, naturally, via conditional access policy. Specifically, you need to enable the Require Multi-Factor Authentication property in the Access Controls > Grant Section of your policy.

Perform an access review

Access review is part of Azure AD Privileged Identity Management (PIM). Azure AD PIM requires Azure AD Premium P2, and allows you to enforce least-privilege security for your Azure AD and Azure subscription resources.

Note

Azure AD License Assignment

Please remember that Azure AD editions are licensed per-user. That means that to use features like Azure AD PIM or password writeback, all involved users and administrators must be assigned the appropriate Azure AD license. You can assign licenses in many ways; one of the most straightforward is to navigate to the Licenses blade in your Azure AD tenant.

For instance, you use PIM to give administrators just-in-time, timerestricted administrative access to Azure AD and/or Azure resource groups. Outside of these elevation windows, Azure admins run as standard users.

Specifically, the access review process simplifies the process of reviewing Azure AD group membership and privileged role assignments for your team. For example, you may want to work with your peers to determine precisely who should be given access to the Global Administrators or Owners roles in your subscription. Here is the high-level configuration workflow:

1. Open the Access Reviews blade in the Azure portal.
2. If this is the first time you’ve used Access Reviews, then click Onboardto enable access reviews in the current directory.
3. From Settings, choose Access Reviews, and then click New AccessReview.
4. Fill out the Create An Access Review form. Some of the majorconfiguration properties of an access review include

Start/End Date Put a “time fence” around the review period.

Users To Review These are the Azure AD users or groups whose role membership and resource access we want to scrutinize.

Reviewers These are the access review participants.

Completion Settings Whether the access review results should be implemented by Azure.

Azure sends each access review member a notification email, similar to what’s shown in Figure 1-30. The reviewers then take action on the review by visiting a special Access Review interface (shown in Figure 1-31). The reviewer can scan who belongs to the given Azure AD group or role and approve or deny their membership.

In the previous example, we showed you how to perform an access review to audit Azure AD group membership or access to an Azure AD application. It’s a bit confusing, but you configure access reviews in two different Azure portal locations, depending on what exactly you’re reviewing:

For Azure AD groups or applications Use the Access Reviews blade.

For Azure AD or Azure resource roles Use the Azure AD Privileged Identity Management blade.

Configure Azure AD Identity Protection

Azure AD Identity Protection (IdP) is an Azure AD Premium P2 feature that enables you to detect potential vulnerabilities affecting your Azure AD identities and potentially configure automatic remediation for suspicious events (for example, attempted logons for the same user account from two geographical locations simultaneously).

As you can see in Figure 1-32, Azure AD IdP gives you a real-time headsup on vulnerable Azure AD user accounts. For instance, Azure IdP can tell you if it thinks you have too many Azure AD and/or resource administrators, where Multi-Factor Authentication (MFA) is not required, and which user accounts aren’t using their assigned high-privilege roles.

With respect to Azure AD IdP configuration, you can configure three policy types:

MFA registration policy Require your users to specify additional

authentication methods to protect their accounts.

User risk policy Set a minimum user behavior risk threshold that triggers the policy; the policy result either blocks or allows sign-in to your Azure AD-backed apps.

Sign-in risk policy Set a minimum sign-in risk level to trigger the policy that, in turn, blocks or allows sign-in.

In case you wondered, Azure uses a lot of machine learning and telemetry to calculate risk values for Azure AD users and sign-ins. Microsoft calls this vast artificial intelligence engine the Intelligent Security Graph, or ISG.

Microsoft tells us in their documentation that we should allow Azure an initial learning period of at least 14 days to get a handle on your users’ signin and application access behaviors.

Configure Azure AD Join

Azure AD Join is what it sounds like to you: the capacity of joining Windows 10 endpoint devices to your Azure AD tenant. You can join Windows 10 devices to Azure AD with any Azure AD SKU; however, advanced features such as mobile device management (MDM) auto-enrollment require Azure AD Premium P1 or P2 licensing.

It’s crucial you understand Microsoft’s positioning of Azure AD Join and related technologies such as Microsoft Intune. These are mechanisms for endpoint management, not server management.

Azure AD Joined devices may or may not be connected to an on-premises Active Directory Domain Services (AD DS) domain; in any case, Group Policy is not supported in Azure.

Anyway, the high-level Azure AD Join configuration workflow involves the following planning points:

Whether you will manage the endpoint devices exclusively using cloud products like Intune (this scenario is called MDM-only), or if you plan to split management between Intune and on-premises

System Center Configuration Manager (SCCM)

How you will handle authentication to on-premises and Azure resources

Which provisioning option makes the most sense for your business

(self-service, Windows Autopilot, or bulk enrollment)

Which MDM provider you’ll use to manage Azure AD-joined devices (options include Intune, VMware AirWatch, ManageEngine, and other partners)

Whether you need conditional access policy for managed devices and users

What need the business has for enterprise state roaming

Configure Enterprise State Roaming

Speaking of enterprise state roaming, let’s consider this feature now. I think of Enterprise State Roaming (an Azure AD Premium P1 or P2 feature) roughly as a public cloud equivalent of roaming user profiles in on-premises Active Directory.

The idea here is your users with their Windows 10 Azure AD–joined devices can synchronize their user and application settings data to the cloud, and have the data be available to all their Windows devices.

Follow these steps to understand the Enterprise State Roaming “big picture”:

1. In your Azure AD tenant, browse to Devices, and then click EnterpriseState Roaming.
2. Set the Users May Sync Settings And App Data Across Devicesproperty to either All or Selected, depending on whether you want to enable Enterprise State Roaming for all or selected Azure AD users.
3. Click Save to complete the configuration.

Skill 1.9: Implement and manage hybrid identities

For some Azure solution architects, the subject of “hybrid identity” may lead them to think along ExpressRoute or site-to-site VPN lines. Not so fast! With Azure AD Connect, we can link our on-premises Active Directory user accounts with an Azure AD tenant and support single sign-on (SSO) to cloud apps that rely on Azure AD for authentication.

Take a look at Figure 1-33. Your company might have an Office 365 subscription or line-of-business software as a service (SaaS) apps that use Azure AD for authentication.

The last thing you want as an Azure solutions architect is to force your users to have to memorize multiple credential sets. By leveraging Azure AD Connect, you can synchronize on-premises Active Directory identities to your Azure AD tenant, and then instruct your users to use their on-premises credentials to authenticate to the cloud-based apps.

This skill covers how to:

• Install and configure Azure AD Connect
• Manage Azure AD Connect

Install and configure Azure AD Connect

Azure AD Connect is a free Microsoft utility that facilitates single sign-on between on-premises Active Directory and Azure AD. You don’t need ExpressRoute or a site-to-site VPN to use Azure AD Connect; all communications occur over TCP 443.

Download Azure AD Connect and install on a domain member server. Here are the steps:

1. Start Azure AD Connect, agree to the license terms, and clickContinue.
2. Choose the express settings or Customize Installation option. Here’sthe distinction between the two installation paths:

Express settings Choosing this path synchronizes all identities and attributes in the current Active Directory forest to Azure AD by using password hash synchronization.

Customize Choosing this path gives you complete control over the hybrid identity scenario, including choosing another identity synchronization method.

In this example, we choose Customize.

3. On the Install required components screen, click Install. You canoptionally specify a custom Azure AD Connect installation location, use an existing SQL Server, or use an existing service account.

The Azure Active Directory Connect Wizard automatically downloads and installs Microsoft SQL Server Express LocalDB for use as a backend data store. At this point the utility installs the synchronization service; this is the “engine” that powers hybrid identity with Azure AD.

4. On the User sign-in page, choose a sign-on method, as shown in Figure 1-34. This is probably the most important architectural choice you have to make. The sign-on methods are

Password Hash Synchronization This is the simplest option; each on-premises AD identity has an Azure AD representation, and Azure AD Connect keeps the passwords in sync. Specifically, Azure AD Connect maintains user account password hashes both in local AD and Azure AD.

Pass-Through Authentication This method is an alternative to password hash synchronization. With pass-through authentication, no password hashes are kept in Azure AD; this suits businesses whose security requirements prevent cloud-based password hash storage. Note that this sign-on method requires the deployment of agent software on-premises.

Federation With AD FS Azure AD Connect can largely automate the deployment of an Active Directory Federation Services (AD FS) farm to support token-based SSO.

Federation With PingFederate is a third-party alternative to AD FS; this option is aimed at businesses that already use PingFederate for token-based SSO.

You can optionally combine your preferred sync method with what Microsoft calls Seamless Single Sign-On (it’s the Enable Single Sign-On option you see in Figure 1-34). Seamless SSO creates a computer account named AZUREADSSOACC in your on-premises AD domain. This allows Seamless SSO to use local Kerberos for authentication; only Kerberos tickets, never password hashes, travel between your on-premises and Azure AD environments.

In this example, we choose Password Hash Synchronization and then clic Next to continue.

5. In the Connect to Azure AD screen, type your Azure AD GlobalAdministrator credentials, and then click Next.

Exam Tip

The exam may test your knowledge of the account privileges required to set up Azure AD Connect. Remember that you must have both Azure AD Global Administrator and local AD Enterprise Administrator credentials to complete the configuration.

6. In the Connect Your Directories screen, verify that Azure AD Connectshows the correct Active Directory forest, and click Add Directory. You’re prompted to authenticate as an Enterprise Administrator. Note that the account must be a member of the Enterprise Administrators universal group; Domain Admins will not be sufficient.
7. In the Azure AD sign-in configuration screen, verify your on-premisesActive Directory user principal name (UPN) suffix matches your Azure AD domain name. A couple points to note:

You must have a custom DNS domain attached to your Azure AD tenant. You’re not allowed to configure hybrid identity by using your tenant’s default *.onmicrosoft.com domain name.

You may need to add a UPN suffix to your forest and modify the UPN attributes of your synchronized users if your goal is to simulate their SMTP email address (this is perhaps the most common pattern). For example, your local domain may be called contoso.local, and your email and Azure AD domains may be contoso.com.

8. In the Domain and OU filtering screen, choose Sync Selected DomainsAnd OUs and use the filter controls to manage which identities you want to synchronize to Azure AD. This is an important step for two reasons:

You don’t want to waste expensive Azure AD licenses on nonuser accounts.

You don’t want to synchronize high-privilege accounts or service accounts to Azure AD unless absolutely necessary.

In Figure 1-35, you see that we chose to synchronize only the user accounts within our PILOT organizational unit (OU).

9. On the Uniquely Identifying Your Users screen, click Next to continue By default, Azure AD Connect uses the UPN attribute to identify your local AD accounts individually. In larger organizations that plan to synchronize users across AD domains and forests, you may need to choose another AD schema attribute to resolve account name conflicts
10. In the Filter User And Devices screen, click Next. By default, wesynchronize all identities within our PILOT OU.
11. In the Optional Features screen, decide whether you need advancedfunctionality. In this case, we click Next to continue. Later in this section, we show you how to opt-in to any of these features after synchronization has begun.
12. Ensure that the Start The Synchronization Process When ConfiguratioCompletes option is enabled, and then click Install to complete the installation.

When account synchronization completes, you can visit the Users blade in your Azure AD tenant to confirm that the on-premises identities show up properly. Take a look at Figure 1-36, which shows a partial user list from my timw.info Azure AD tenant.

In Figure 1-36, pay attention to the Source column. Here’s what the different source IDs mean:

Azure Active Directory This is a cloud-native identity that was created directly in the Azure AD tenant.

External Azure Active Directory This is an identity from another Azure AD tenant who was invited to the local directory via Active Directory Business-to-Business collaboration (Azure AD B2B).

Invited User This is an Azure AD B2B guest user who has not yet accepted the invitation to join the local directory.

Microsoft Account External Azure AD B2B guests become Microsoft accounts after they redeem their invitation.

Windows Server AD This is a local Active Directory identity that has been synchronized to the Azure AD tenant.

Exam Tip

Don’t forget to assign your synchronized local AD users appropriate Azure AD licenses! Synchronized identities behave exactly the same as cloud-native identities from Azure AD’s perspective.

Manage password sync and writeback

One advantage to Password Hash Synchronization is that it’s fast and easy to deploy. One disadvantage is that unless you enable password writeback, your users may change their passwords in the cloud and have their passwords fall out of sync.

First off, understand that password writeback to on-premises AD is supported only in Azure AD Premium P1 and P2. Second, you can enable password writeback after you deploy Azure AD Connect. Here’s how:

1. Start Azure AD Connect, and in the Welcome To Azure AD Connectscreen, click Configure.
2. In the Additional tasks window, select Customize SynchronizationOptions and click Next.
3. In the Connect To Azure AD screen, authenticate with a GlobalAdministrator role holder account.
4. In the Connect To Directories screen, confirm your AD forest anddirectory and then click Next.
5. In the Domain And OU filtering screen, click Next to continue.
6. In the Optional Features screen, shown in Figure 1-37, select Password writeback, and then click Next.
7. Click Configure to complete the environment change.

Note

Configure Azure AD Connect High Availability

The Azure AD Connect Additional Tasks screen has an option called Configure Staging Mode. To provide some redundancy to your Azure AD Connect deployment, install Azure AD Connect on at least one other domain member server, but configure it for staging mode. The secondary Azure AD Connect instance remains in “standby”; if the primary Azure AD Connect server goes offline, bring the standby out of staging mode to have it resume identity synchronization as usual.

Manage the scheduler

By default, the Azure AD Sync scheduler runs every 30 minutes. You can find the scheduler service in the Service Control Manager list under Microsoft Azure AD Sync (short name: ADSync). Open an elevated PowerShell session on your Azure AD Connect server and run GetADSyncScheduler to view current sync metadata.

To disable the scheduler, run the following PowerShell command:

	
Set-ADSyncScheduler -SyncCycleEnabled $false
	

Configure federation and single sign-on

As an alternative to password hash synchronization or pass-through authentication, you can enable “true” SSO by implementing Active Directory Federation Services (AD FS). What does “true” SSO mean?

Well, honestly, password hash sync is not really “single sign-on” in the true sense of the word. You see, while your on-premises users authenticate to your cloud apps with what they think are their local AD credentials, the app authentication relies strictly on the synchronized Azure AD identities instead.

What I call “true” SSO is an authentication system that uses vendorneutral tokens (typically in Security Assertion Markup Language (SAML) format) for trusted authentication between two different identity stores.

When you use Azure AD Connect to install or configure a local AD FS farm, a trust relationship is defined between local AD and your Azure AD tenant. Here is a super high-level overview of the authentication flow:

1. A user accesses an Azure AD-based application and types his or heremail address (which we know, behind the scenes, represents the user’s on-premises AD UPN).
2. Because a federated trust exists, Azure AD redirects the user to thelocal AD FS farm, where the user may or may not be prompted for their password depending on the environment specifics.
3. User authentication happens strictly locally within AD; the AD FSsecurity token service generates a vendor-neutral token that makes claims about the user’s identity, group memberships, and possibly other metadata.
4. The AD FS farm presents the token to Azure AD. Azure AD trustslocal AD via the federation, so the user is granted access to the application.

Do you see how that works? At most, all the user needs to provide to the Azure AD application is the username; no password hashes or Kerberos tickets are exchanged over the network connection.

Let’s run through the Azure AD Connect federation setup workflow. In keeping with the work we’ve performed thus far, we will rerun the Azure AD Connect wizard to change from password hash authentication to federated authentication.

1. In the Azure AD Connect Additional tasks screen, choose Change UserSign-In and click Next.
2. In the Connect To Azure AD screen, authenticate as a GlobalAdministrator.
3. In the User Sign-In screen, select Federation With AD FS and clickNext.
4. In the Domain Administrator credentials, authenticate to local AD witha domain administrator identity.
5. In the AD FS farm screen, decide whether you want to use an existingAD FS farm or configure a new AD FS farm.
6. Complete the wizard according to your choice in step 5.

Need More Review?

Deploying and Configuring AD FS

Setting up AD FS is beyond the scope of this book. To learn more about AD FS in general, visit the Active Directory Federation

Services documentation at https://docs.microsoft.com/en-

Manage Azure AD Connect

Besides the ADSync service and the Azure AD Connect wizard itself, Azure AD Connect provides three other graphical utilities to help you manage and customize your hybrid identity environment:

Synchronization Service Manager View and configure synchronization service properties.

Synchronization Service Web Service Configuration Tool Control the web services connection between local AD and Azure AD.

Synchronization Rules Editor Customize the mapping between local AD schema attributes and Azure AD user and group account attributes.

I show you Synchronization Service Manager in Figure 1-38. As you can see, you can force a synchronization run by right-clicking inside the window and choosing Run from the shortcut menu.

Verifying synchronization status in the Azure porta

Lastly, navigate to the Azure AD Connect blade in your Azure AD tenant, a depicted in Figure 1-39. The Azure portal shows you sync status and which user sign-in options you have enabled. In Figure 1-39, the environment uses pass-through authentication and Seamless SSO.

Chapter summary

Configure diagnostics for Azure resources to create performance baselines and to analyze your consumption.

Azure Log Analytics provides a centralized analysis engine for all your Azure resources.

Global VNet peering means the peered VNets can exist in different Azure regions or even different subscriptions.

Consider a VNet-to-VNet VPN when security needs require the communications.

You assign public and private IP addresses to VMs through their associated virtual network interface, not the VM resource itself.

A virtual network (VNet) consists of one or more top-level IPv4

address spaces; the most common design pattern is to create a subnet for each application tier.

Azure AD Identity Protection is an Azure AD Premium P2 feature that uses Microsoft’s Intelligent Security Graph to detect potential vulnerabilities with your user identities.

Azure AD Join enables you to join Windows 10 devices to your

Azure AD tenant and optionally manage them by using Microsoft Intune or another mobile device management (MDM) platform.

Thought experiment

In this thought experiment, demonstrate your skills and knowledge of the topics covered in this chapter. You can find answers to this thought experiment in the next section.

You are an Azure solutions architect hired by Fabrikam, Inc. to help them plan their move to the Microsoft Cloud Platform. Currently, Fabrikam is organized as a single Active Directory domain, with all IT infrastructure located in an on-premises datacenter at corporate headquarters in Sacramento, California.

In your consultation with Fabrikam, you identify the following business requirements:

Fabrikam leadership wants to make more robust use of its existing Office 365 subscription. Specifically, users should be able to sign into Office 365 by using their fabrikam.com email IDs.

The Fabrikam compliance department needs to know which IT staff members have administrative privilege in Azure Active AD and in the corporate Azure subscription.

Fabrikam IT wants to migrate its core infrastructure to Azure and decommission most of their on-premises environment. The onpremises network backbone consists of multiple virtual LANs (VLANs) with no clear management boundary among them.

Fabrikam IT also needs to be able to manage the cloud VMs from onpremises AD; AD will eventually be migrated to Azure, but that initiative isn’t on the near-term roadmap.

With this information in mind, answer the following questions:

1. What solution would you recommend to solve the single-sign on issueto Office 365?
2. How can Fabrikam meet the goal of reporting Azure AD and Azuresubscription management access to their compliance department?
3. What kind of network topology would you recommend to FabrikamIT?

Thought experiment answers

This section contains the solution to the thought experiment. Each answer explains why the answer choice is correct.

1. The reference to Office 365 is a bit of a red herring. It’s important foryou to understand that many Microsoft cloud products use Azure AD as an identity store, including, of course, Office 365. You should start by teaching Fabrikam how to associate their fabrikam.com DNS domain with the Office 365 Azure AD tenant, after which you can implement Azure AD Connect to facilitate SSO to Office 365. Which account synchronization strategy, or whether AD FS federation is appropriate, will require additional interviews to learn more about Fabrikam’s security requirements.
2. We now know that Azure AD PIM has the central use case of reporting on high-privilege access to Azure AD and Azure resources. Thus, you should guide Fabrikam to upgrade their Azure AD licenses as necessary and then show them how to work with Azure AD PIM, particularly access reviews. The reviewers can then send reports to the compliance department to meet their regulatory requirements.
3. The pitfall here that some businesses fall into is the mistaken belief thatthey must by definition replicate their on-premises network topology to Azure 1:1. Absolutely not! In many cases it’s better to consider the

Azure environment a “greenfield” deployment, and design the virtual

network topology from scratch, keeping in mind security, performance, and availability.

In this scenario, you might consider either ExpressRoute or a site-tosite VPN to facilitate central management of both on-premises and Azure resources. Depending on business and technical requirements, you might deploy only a single VNet, or you may determine a hub-andspoke topology makes the most sense.