Module 4 - Managing Virtual Machines

6/1/2017 Module 4: Managing virtual machines
Module 4: Managing virtual machines
Contents:
Module Overview
Lesson 1: Configuring Virtual Machines
Lesson 2: Configuring virtual machine disks
Lesson 3: Managing and Monitoring Azure virtual machines
Lesson 4: Managing IaaS v1 virtual machines
Lab: Managing Azure virtual machines
Module Review and Takeaways
Module Overview
Configuration, management, and monitoring of Azure infrastructureasaservice (IaaS) Virtual
Machines are essential in delivering secure, available, and scalable cloudbased solutions. In
this module, you will see some of the most common techniques that allow you to modify and
maintain Azure virtual machines and operating system characteristics in order to better suit
your custom requirements.
Objectives
After completing this module, you will be able to:
• Configure virtual machines.
• Configure virtual machine disks.
https://skillpipe.com/esES/Book/BookPrintView/221b0e25dc2b45f8a14fa19b7566e327?ChapterNumber=6 1/61
• Manage and monitor virtual machines.
Lesson 1: Configuring Virtual Machines
Virtual machines constitute one of the core components of Microsoft Azure IaaS deployments.
In this lesson, you will look at the different options that you can use to configure availability,
scalability, and performance of the Azure virtual machine environment.
Lesson Objectives
After completing this lesson, you will be able to:
• Describe how to configure virtual machine availability.
• Describe how to configure virtual machine scalability.
• Describe how to configure virtual machine security.
• Describe how to configure virtual machine availability sets.
Demonstration: Preparing the Azure environment
In this demonstration, you will see how to prepare the Azure environment.
Demonstration Steps
1. On the taskbar, rightclick Windows PowerShell, and then click Run as administrator.
In the User Account Control dialog box, click Yes.
2. Type the following command, and press Enter:
Setup-Azure
3. At the command prompt, type 4, and then press Enter.
4. Confirm your selection, and press Enter.
5. After the script completes running, close the Windows PowerShell command prompt
Configuring virtual machine availability
In general, you want your Azure virtual machine environment to be resilient to hardware
failures and maintenance events that might occur occasionally within the Azure infrastructure.
The primary mechanism provided by the Azure platform that helps you accomplish this
objective is the availability set feature. Availability sets are designed to gracefully handle two
event types that might result in downtime of individual Azure virtual machines.
• Planned outages. These outages occur because of planned system maintenance events that
require a temporary virtual machine downtime. In particular, while most Azure platform
updates are transparent to platform as a service (PaaS) and IaaS infrastructure, some of
them might involve reboots of HyperV hosts. To accommodate such types of events,
Azure implements update domains. Update domain is explained later in this topic.
• Unplanned outages. These outages can negatively affect availability of individual virtual
machines in an unexpected way, and potentially for longer than the time frame of a planned
HyperV host restart. While the Azure platform is designed to be highly resilient, there
might be cases where a hardware failure results in virtual machine downtime. In Azure,
unplanned outage events are mitigated by using fault domains. Fault domain is explained
later in this topic.
Understanding availability sets
To provide resiliency for your IaaSbased solutions, you should group two or more virtual
machines providing the same functionality in an availability set. An availability set is a logical
grouping of two or more virtual machines. By assigning virtual machines to the same
availability set, you automatically distribute them across separate fault domains and separate
update domains.
Update domains
An availability set consists of up to 20 update domains (you have the ability to increase this
number from its default of 5). Each update domain represents a set of physical hosts that
Azure Service Fabric can update and reboot at the same time without affecting overall
availability of virtual machines grouped in the same availability set.
When you assign more than five virtual machines to the same availability set (assuming the
default settings), the sixth virtual machine is placed into the same update domain as the first
virtual machine, the seventh in the same update domain as the second virtual machine, and so
on. During planned maintenance, only hosts in one of these five update domains are rebooted
concurrently, while hosts in the other four remain online.
Fault domains
Fault domains define a group of HyperV hosts that, due to their placement, could be affected
by a localized failure (such as servers installed in a rack serviced by the same power source or
networking switches). Azure Service Fabric distributes VMs in the same availability set across
either two (with Azure classic deployment) or up to three (when using Azure Resource
Manager) fault domains.
By placing application servers, such as web or database servers in functionbased availability
sets and then using load balancing (discussed in the next topic) or additional failover
mechanism, you can protect each service and enable traffic to be continuously served by at
least one instance of each service.
Configuring availability sets
Availability set configuration is mostly governed by the Azure Service Fabric, and, beyond the
initial setup and VM assignment, does not require user interaction. To add one or more virtual
machines to an availability set, simply assign the same availability set on their Settings blade.
The portal also allows you to create a new availability set by offering it as one of its Azure
Marketplace components in the Compute category.
Azure PowerShell provides an alternative approach to managing availability sets. The
following cmdlets handle creating, modifying, and removing availability sets respectively:
New-AzureRmAvailabilitySet
Set-AzureRmAvailabilitySet
Remove-AzureRmAvailabilitySet
Considerations for virtual machine availability
When configuring availability sets for Azure virtual machines:
• Configure two or more virtual machines in an availability set for redundancy. The primary
purpose of an availability set is to provide resiliency to failure of a single virtual machine. If
you do not use multiple virtual machines in an availability set, you gain no benefit from the
availability set. In addition, for Internet facing virtual machines to qualify for 99.95%
external connectivity Service Level Agreement (SLA), they must be part of the same
availability set (with two or more VMs per set).
Note: It is critical to understand that it is not possible to add an existing Azure
virtual machine to an availability set. You need to specify that a virtual machine will
be part of an availability set when you provision it.
• Configure each application tier as a separate availability sets. As long as virtual machines in
your deployment provide the same functionality, such as web service or database
management system, you should configure them as part of the same availability set to
ensure that at least one VM in each tier is always available.
• Wherever applicable, combine load balancing with availability sets. You can implement an
Azure load balancer in conjunction with an availability set to distribute incoming
connections among its virtual machines, as long as the application running on them supports
such configuration. In addition to distributing incoming connections, a load balancer is
capable of detecting a virtual machine or an application failure and redirect network traffic
to other nodes in the availability set.
Configuring virtual machine scalability
You can provide scalability of IaaS virtual machines in Azure by using Azure Virtual Machine
Scale Sets. A VM scale set consists of a group of automatically provisioned Windows or Linux
virtual machines that share identical configurations and deliver the same functionality to
support a service or application. With a VM scale set, it is possible to have the number of
virtual machines increase or decrease, adjusting dynamically to changes in demand for the
service or application. To implement on demand autoscaling, you combine VM Scale Sets
with Azure Insights Autoscale.
VM Scale Sets integrate with Azure load balancers to efficiently handle dynamic distribution of
network traffic across multiple virtual machines. It also supports Network Address Translation
(NAT) rules, allowing for connectivity to individual virtual machines in the same scale set.
It is important to note that this solution differs from the IaaS v1 horizontal scaling approach,
which required that you to preprovision any virtual machines you wanted to bring online to
accommodate increased demand.
Note: VM Scale Sets are available only when using the Azure Resource Manager
deployment model.
Implementing VM Scale Sets
You can implement VM scale sets by using an Azure Resource Manager template that
provides configuration details about their settings, including virtual machines, network
adapters, virtual machine extensions, load balancers, and Autoscale settings. To configure VM
Scale Setspecific functionality, reference the Microsoft.Compute/virtualMachineScaleSets
resource type in the template. This resource type implements a number of properties,
including:
• sku.tier. The size of the virtual machines in the VM scale set.
• sku.capacity. The number of virtual machine instances that the scale set will auto
provision.
• properties.virtualMachineProfile. The disk, operating system, and network settings of the
virtual machines in the scale set.
To configure Autoscale, reference the Microsoft.Insights/autoscaleSettings resource type in
an Azure Resource Manager template. Some of the more relevant properties that this resource
type implements include:
• metricName. The name of the performance metric that determines whether to trigger
horizontal scaling (for example, Percentage CPU).
• metricResourceUri. The resource identifier designating the virtual machine scale set to
monitor.
• timeGrain. The frequency with which performance metrics are collected (between 1
minute and 12 hours).
• Statistic. The method of calculating aggregate metrics from multiple virtual machines
(Average, Minimum, Maximum).
• timeWindow. Range of time for metrics calculation (between 5 minutes and 12 hours).
• timeAggregation. The method of calculating aggregate metrics over time (Average,
Minimum, Maximum, Last, Total, Count).
• Threshold. The value that triggers the scale action. For example, if you set it to 50 when
using the Percentage CPU metricName, the number of virtual machines in the set would
increase when the CPU usage exceeds 50 percent (specifics would depend on other
parameters, such as statistics, timeWindow, or timeAggregation).
• Operator. The criterion that determines the method of comparing collected metrics and the
threshold (Equals, NotEquals, GreaterThan, GreaterThanOrEqual, LessThan,
LessThanOrEqual).
• Direction. The type of horizontal scaling invoked as the result of reaching the threshold
(increase or decrease, representing, respectively, scaling out or scaling in).
• Value. The number of virtual machines added to or removed from the scale set (one or
more).
• Cooldown. The amount of time to wait since the most recent scaling event before the next
action occurs (from 1 minute to 1 week).
Additional Reading: For more information on virtual machine Scale sets, refer to
Automatically scale machines in a Virtual Machine Scale Set: http://aka.ms/C9gbgz
Configuring virtual machine security
Microsoft Azure offers a number of technologies that help to keep customer data secure in
use, in transit, and at rest. In this topic, you will learn about the additional security measures
that you can implement by leveraging encryption capabilities provided by Azure Key Vault that
apply to Azure IaaS virtual machine disk files at rest.
Additional Reading: For more information about Microsoft Azure general security
practices, refer to Security Features to help keep data safe: http://aka.ms/Guhssp
Understanding Key Vault
Key Vault serves as a store of cryptographic keys and secrets, such as storage account keys or
passwords. The vault maintains its content in encrypted form and offers the ability to further
secure it by applying hardware security module (HSM)based protection.
A secret is essentially a small data blob (of up to 10 KB in size) that authorized users and
applications can retrieve from the vault. To secure access to secrets, you create Azure Active
Directory objects representing these users or applications, which they subsequently use to
authenticate. Effectively, you avoid potential risk associated with users storing secrets in
nonsecure locations and eliminate the need to hardcode them into applications.
Unlike secrets, keys stored in a vault do not leave its boundaries. Instead, once you add a key
to the vault, users and applications must invoke cryptographic functions to perform any
operations that require its knowledge. On the other hand, the ability to complete such
invocation is also subject to a successful Azure Active Directorybased authentication. To
access keys and secrets, users and applications must possess valid Azure Active Directory
tokens representing security principal with sufficient permissions to the target vault.
Every object residing in an Azure Key Vault has a unique identifier, which you must reference
when attempting to retrieve it (secret) or accessing it via a cryptographic function (key). In
addition, you can assign several additional attributes to both secrets and keys, which help with
their retrieval and usage:
• exp. An expiration date of the secret, after which it is no longer possible to retrieve it from
the vault.
• nbf. A date at which the secret becomes accessible.
• enabled. A Boolean value that determines whether the secret is accessible (assuming that
the access attempt takes place between the dates set by the values of the nbf and exp
parameters).
Secrets also include the contentType attribute in the form of a string of up to 255 characters,
which you can use to describe their purpose.
Using Key Vault
You can use a RESTbased API or Azure PowerShell to retrieve secrets and public parts of
keys (in JSON format) from Key Vault. In addition to performing the GET operation, you also
have the ability to carry out other management tasks targeting keys (create, import, update,
delete, list, backup, or restore) and secrets (set, list, or delete). Similarly, either of these two
methods allow you to manage the vault and its properties. Some of the most commonly used
PowerShell cmdlets that facilitate interaction with an Azure Key Vault include:
• NewAzureRmKeyVault creates a new Key Vault.
• AddAzureKeyVaultKey creates a new—or imports an existing—key into a Key Vault.
• GetAzureKeyVaultKey retrieves a public part of a key from a Key Vault.
• GetAzureKeyVaultSecret retrieves a secret from a Key Vault.
• RemoveAzureKeyVaultKey remove a key from a Key Vault.
Additional Reading: For more information about Key Vault, refer to Get started with
Azure Key Vault: http://aka.ms/Wnz2hb
Using Azure Disk Encryption
Azure Disk Encryption is a capability built into the Azure platform that allows you to encrypt
file system volumes residing on Windows and Linux IaaS v2 virtual machine disks. Azure Disk
Encryption leverages existing file systembased encryption technologies already available in the
guest operating system (BitLocker in Windows and DMCrypt in Linux) to provide encryption
of volumes hosting the operating system and data. The solution integrates with Key Vault to
securely store volume encryption keys. Additionally, you also have the option to encrypt these
keys by utilizing Key Encryption Key (KEK) functionality of the vault. The combination of
these features enhances security of Azure virtual machine disks at rest by encrypting their
content.
Note: It is possible to encrypt the data (but not the operating system) volumes of
Azure IaaS virtual machines running the Windows operating system by using
BitLocker without relying on Azure Disk Encryption. You also have the option of
encrypting any volume (including the operating system one) by implementing third
party solutions offered on Azure Marketplace, such as CloudLink SecureVM.
There are three main scenarios in which you would use Azure Disk Encryption, all of them
are applicable to Azure Resource Manager deployments of standard A, D, and G series virtual
machines:
• Enable encryption on new IaaS v2 virtual machines created from customer encrypted VHD
and corresponding encryption keys.
• Enable encryption on new IaaS v2 virtual machines created from the Azure Gallery.
• Enable encryption on existing IaaS v2 virtual machines already running in Azure.
Azure Disk Encryption is not supported for:
• Basic tier virtual machines.
• DS and GS series virtual machines (due to their support for Premium Storage disks).
• IaaS v1 virtual machines.
• Integration with onpremises Key Management Service.
• Linux virtual machines running Red Hat Enterprise Linux.
• Content of Azure Files (Azure file share), Network file system (NFS), dynamic volumes,
and softwarebased RAID configurations.
Azure Disk Encryption requires additional changes to obtain access to the Azure Key Vault
where secrets and encryption keys will reside. In particular, you must set the
enabledForDiskEncryption property on the vault to allow Azure platform to read BitLocker
encryption keys and DMCrypt passphrases from it. When applying encryption to new or
existing volumes, you also have to set up an Azure Active Directory application with write
permissions to the vault. This application provides a security context for Azure platform,
allowing it to securely store newly generated cryptographic material. In addition, you need to
configure the vault access policy to allow the Microsoft.Compute resource provider and
Azure Resource Manager to retrieve its secrets during virtual machine deployments.
Finally, you need to enable encryption on new or existing IaaS v2 virtual machines. Specifics
of this last step depend on which of the three scenarios you are implementing and which
deployment methodology you are using.
Additional Reading: For more information on Azure Disk Encryption, including how
to integrate it with Key Vault and configure it for VM deployment, refer to Azure Disk
Encryption for Windows and Linux IaaS VMs Preview: http://aka.ms/Jvkb03
Demonstration: Configuring IaaS v2 virtual machine
availability sets
In this demonstration, you will see how to create virtual machines in an availability set.
Demonstration Steps
1. On MIACL1, open Internet Explorer, and navigate to the Azure portal.
2. When prompted, sign in with an account that is either a Service Administrator or Co
Admin in the subscription you are using for this demo.
3. From the Azure portal, create a new availability set with the following settings:
o Name: Demo4AVSet
o Fault domains: 3
Note: You can decrease the value to 2, but not increase it.
o Update domains: 5
Note: The number of update domains can vary between 5 and 20.
o Subscription: Your Azure subscription you intend to use for this demo.
o Resource group name: Demo4RG.
o Location: The Azure region closest to the location of your lab computer.
4. From the Azure portal, create a new virtual machine with the following settings:
o Name: Demo4VM1
o User name: Instructor
o Password: Pa$$w0rd
o Resource group: Demo4RG
o Location: The same location you chose for the availability set.
o Size: A1 Standard
o Disk type: Standard
o Storage account: Accept the default.
o Virtual network: Demo4RG
o Subnet: Accept the default.
o Public IP address: Demo4VM1
o Network security group: Demo4VM1
o Monitoring: Disabled
o Availability set: Demo4AVSet
o Name: Demo4VM2
o User name: Instructor
o Resource group: Demo4RG
o Size: A1 Standard
o Virtual network: Demo4RG
o Public IP address: Demo4VM2
o Network security group: Demo4VM2
o Availability set: Demo4AVSet
6. From the Azure portal, display the blade of the Demo4AVSet availability set. On the
Demo4AVSet blade, note that the availability set contains the two newly deployed
virtual machines (at this point, both of them will likely display the Creating status). Point
out that each VM has a unique fault domain and update domain.
Lesson 2: Configuring virtual machine disks
Azure virtual machines use disks for different purposes, including operating systems, data, and
temporary storage. In this lesson, you will learn about the types of disks used by virtual
machines, and how to manage and configure these disks. You will also learn how to attach
new and existing disks to virtual machines, and how to use Storage Spaces within a virtual
machine to configure multidisk volumes.
Lesson Objectives
• Describe virtual machine disks.
• Explain the different methods for managing virtual machine disks.
• Describe how to migrate virtual machine disks and images.
Overview of virtual machine disks
Disks that you attach to Azure virtual machines are stored as Virtual Hard Disk (VHD) files
within an Azure storage account. A storage account is a logical namespace capable of hosting
four types of objects: blobs, tables, queues, and files. You can create a storage account by
using variety of methods, including the Azure portal, and Azure PowerShell.
VHDs within storage accounts are stored as blobs. Azure hosts two types of blobs—block
blobs and page blobs. Block blobs are typically used for nonstructured, sequentially accessed
files (such as media content) of up to 200 gigabytes (GB). Page blobs take the form of files of
up to 1 terabyte (TB) that consist of 512byte pages and are optimized for random readwrite
access.
Azure offers two tiers of storage accounts capable of storing VHD files—Standard and
Premium.
Note: You will learn about Azure storage and its objects in details in Module 6:
Planning and implementing storage, backup, and recovery services of this course.
VHD files in an Azure storage account represent one of two object types—images or disks.
Images serve as templates from which you create new disks during provisioning of new virtual
machines. There are two types of images: operating system images and VM images. The
former represents a single disk containing a generalized installation of the Windows or Linux
operating system. The latter refers to an image that contains all disks attached to a VM during
its capture.
To identify images, Azure Resource Manager provides a number of parameters, including:
• Publisher name. For example, MicrosoftWindowsServer
• Offer. WindowsServer
• SKU. For example, 2012R2Datacenter
• Version. For example, 4.0.20150916
You can use these parameters to identify available images that match your requirements by
running the GetAzureRmVMImage cmdlet.
Azure supports three types of disks:
• Operating system disk:
o One per VM
o Maximum size of 1 TB
o Labeled as drive C
o Appears to VM as a SATA drive
• Temporary disk:
o One per VM
o The size varies depending on tier size used
o Labeled as drive D
o Provides temporary, nonpersistent storage (for example, page files)
• Data disks:
o Maximum number of disks is determined by the size of the VM
o Maximum size of 1 TB
o You can assign any available drive letter (starting with F:)
o Appears to VM as a SCSI drive
o Provides persistent storage for applications and data
Operating system and data disks are implemented as blob storage in a storage account. The
temporary disk is implemented as local storage on the HyperV host where the VM is running.
Using Storage accounts for virtual machine disks
Storage accounts provide the persistent store for virtual machine disks in Azure. When
planning for virtual machine disk configuration, you should note that charges related to the
usage of storage are calculated according to four criteria:
• Total amount of disk space represents the amount of storage you use (with Standard
storage) or allocate (with Premium storage).
• Replication topology determines how many copies of your data are concurrently
maintained and the number of Azure regions in which they are located.
• Transaction volume refers to the number of read and write operations performed against a
storage account.
• Data egress refers to data transferred out of an Azure region. When services or applications
and the storage account they are using are not located in the same Azure region, then
typically, you will incur charges for data egress. Note that this never applies to an Azure
VM and blobs hosting its VHDfiles, because the storage account hosting these blobs must
reside in the same region as the VM. However, you should consider the location of an
Azure VM in relation to other services that are part of your Azure environment.
Managing virtual machine disks
When creating a virtual machine based on an image, the Azure platform will automatically
provision a new operating system disk. Alternatively, you have the option of attaching an
existing disk containing an operating system to a newly created Azure virtual machine. This
typically happens when you migrate a virtual machine from your onpremises environment to
Azure. This is discussed in more detail in the next topic. Similarly, you can attach either new
(empty or imagebased) or existing data disks to any Azure virtual machine, up to the limit
determined by its size.
Attaching a virtual machine disk
To attach a disk to an Azure virtual machine, you can use the Azure portal or Azure
PowerShell.
When using the Azure portal, take the following steps:
1. Navigate to the settings page for the virtual machine to which you are attaching the disk.
2. On the Settings page, click Disks, and then, on the Disks blade, click Attach new to
create a new virtual disk and attach it to the virtual machine, or click Attach existing to
attach a .VHD file that is stored in an Azure Storage account.
To attach a new empty virtual machine data disk by using Azure PowerShell, you would use
the following command:
Add-AzureRmVMDataDisk –ResourceGroupName <Resource Group name> –

VM <VM object> -Name <Disk name> -SourceImageUri <URI of the blob
representing the disk in the storage account> -CreateOption Empty
–DiskSizeInGB <Disk size in GB>
Update-AzureRmVM –ResourceGroupName <Resource Group name> -Name
<VM Name> -VM <VM object>
Detaching a virtual machine disk
To detach a virtual machine disk, you can use either the Azure portal or Azure PowerShell.
To detach a virtual machine disk using the Azure portal, use the following steps:
1. In the Azure portal, navigate to the Settings blade of the virtual machine from which you
will detach the disk, and then click Disks.
2. On the Disks blade, click the disk you want to remove and then, on the blade for that
disk, click Detach.
Note: You cannot detach the operating system disk.
To detach a disk using by using Azure PowerShell, use the following command:
Remove-AzureRmVMDataDisk –VM <VM object> -DataDiskNames <Disk

name>
Update-AzureRmVM –ResourceGroupName <name> -Name <VM Name> -VM
<VM object>
Note: You can use both Standard storage accounts and Premium storage accounts to
store virtual machine disks. However, only DS and GS series virtual machines can use
virtual machine disks that are stored in Premium storage accounts.
Modifying virtual machine disks
You can modify an existing Azure virtual machine disk configuration by:
• Changing caching mode of the disk.
• Increasing size of the disk (up to the 1 TB limit).
To modify a data disk, you should use the SetAzureRmVMDataDisk cmdlet, followed by
the UpdateAzureRmVM cmdlet.
Using Storage Spaces for Windows virtual machines
Starting with Windows Server 2012, you can use the Storage Spaces functionality to create
multidisk volumes. This capability offers several benefits:
• Improved performance, compared to individual disks or volumes configured by leveraging
dynamic disks (available in earlier versions of Windows).
• Threeway mirroring, offering higher resiliency than twoway mirror or parity
configurations. Considering that Azure storage is highly resilient by virtue of having three
synchronously replicated copies of the same content, this benefit does not offer a
meaningful advantage in case of Azure virtual machines.
• Support for volumes larger than 1 TB limit of a single disk size in Azure VMs.
To create a storage space in an Azure VM:
1. Create a new virtual machine running Windows Server 2012 or later. Avoid using lower
tier VMs, because they support fewer data disks.
2. Attach new, empty disks to the virtual machine.
3. Connect to the Windows operating system running in the virtual machine by using the
Remote Desktop Protocol (RDP) client.
4. Ensure that the File Server role service is installed.
5. Open the Server Manager, and navigate to File and Storage Services.
6. Click Storage Pools, and click Tasks.
7. Click New Storage Pool, and add the empty disks to the pool.
8. In File and Storage Services, select the pool, and then, in the Virtual Disks pane, click
New Virtual Disk.
9. Set the disk layout and size, and click Create.
10. The New Volume wizard appears. Select the virtual disk you created, chose a drive
letter, and then create the volume.
Migrating virtual machine disks and images
Azure offers a straightforward approach to integrating with your onpremises technologies.
One of the common scenarios that exemplify this integration is migration of virtual machine
disks and images between the two environments.
When performing such migrations, you can use the Azure PowerShell cmdlets Add
AzureVHD and SaveAzureVHD to, respectively, upload and download VHD files. In
addition to performing the data transfer, the cmdlets offer a number of extra advantages:
• AddAzureVHD will automatically convert dynamic disks to fixed format to account for
the fact that Azure does not support the former.
• AddAzureVHD and SaveAzureVHD can inspect the .VHD file format and will only
read/write actual disk content and skip empty bytes, providing a more efficient data transfer
experience.
• Both cmdlets support multithreading for increased throughput.
Migrating a virtual machine to Azure
The following code example illustrates how you can migrate a Windows Server 2012 R2
virtual machine from an onpremises HyperV environment to the cloud by uploading its
operating system disk and using it to provision a new Azure virtual machine.
In this example, you will use an operating system disk of an onpremises virtual machine
named VM1 running the Windows operating system. You will upload the .VHD file containing
the operating system to an Azure storage account and use it to provision a new Azure virtual
machine named VM1 residing in the RG1 resource group. The process will consist of the
following steps:
1.Create an Azure storage account and a new container (named vhds) intended for storing VHD
$StorageAccountName = ‘storageaccount1’
$replicationType = ‘Standard_LRS’
$regionName = ‘East US’
$containerName = ‘vhds’
$resoruceGroupName = ‘RG1’
$VMName = ‘VM1’
$VMSize = ‘Standard_A1’
$VHDName = ‘VM1OSDisk’
$storageAccount = New-AzureRmStorageAccount –ResourceGroupName

$resourceGroupName –AccountName $storageAccountName –Location $regionName
$replicationType
$StorageAccountKey = Get-AzureStorageKey -StorageAccountName
$StorageAccountName
$context = New-AzureStorageContext –StorageAccountName $StorageAccountName
StorageAccountKey
New-AzureStorageContainer –Name $containerName –Context $context
2.Upload the VHD file to the storage account.
$sourceVHD = “D:\VHDs\$VHDName.vhd”
$destVHD =
“https://$storageAccountName.blob.core.windows.net/$containerName/$VHDName.
Add-AzureVHD –LocalFilePath $sourceVHD –Destination $destVHD
3.Create a new VM based on the VHD file uploaded to the Azure storage account.
$vm = New-AzureRmVMConfig –VMName $VMName -VMSize $VMSize

$vm = Set-AzureRmVMOSDisk –VM $vm -Name “$VHDName.vhd” –VhdUri
$destVHD –CreateOption Attach –Windows
NewAzureRmVM –ResourceGroupName $resourceGroupName –Location
$regionName –VM $vm
Understanding the Azure import/export service
In addition to facilitating upload and download of VHD files, Azure also offers the
Import/Export service. The service accommodates transfers of larger amounts of data between
onpremises locations and Azure storage accounts, whenever its size makes it too expensive or
not feasible to rely on network connectivity.
The process involves creating either import or export jobs, depending on the direction of
transfer:
• You create an import job to copy data from your onpremises infrastructure onto hard
drives that you subsequently ship to the Azure datacenter that is hosting the target storage
account.
• You create an export job to request that data currently held in an Azure storage account be
copied to hard drives that you ship to the Azure datacenter. Once the drives arrive at the
destination, the Azure datacenter operations team completes the request and ships the
drives back to you.
Lesson 3: Managing and Monitoring Azure virtual
machines
Microsoft offers a number of different methods that simplify and enhance management of
both Windows and Linux operating systems hosted on Azure virtual machines. In this lesson,
you will become familiar with the most popular of these methods.
Lesson Objectives
• Identify configuration management options in Azure.
• Describe the VM Agent Custom Script extension.
• Describe the VM Agent Desired State Configuration extension.
• Explain how to monitor Azure virtual machines.
• Describe how to configure Desired State Configuration for an Azure IaaS v2 virtual
machine.
Configuration management options
In general, you can categorize management options for Azure VMs depending on the operating
system support they provide. While the implementation details differ between the Windows
and Linux operating systems, some of these options are (at least conceptually and, for the
most part, functionally) consistent across both platforms.
Crossplatform management options
The first category of these options, crossplatform management, is available across both
Windows and Linux platforms.
VM Agent and VM Agent Extensions
The VM Agent is a set of lightweight software components running within the operating
system of an Azure VM. Their primary purpose is to load additional programs and services
known as VM Agent Extensions, offered both by Microsoft and by its partners. VM Agent
Extensions enhance Azure VM functionality and manageability. In the Windows operating
system, the agent takes the form of several processes (WindowsAzureGuestAgent.exe,
WaAppAgent.exe, and WindowsAzureTelemetryService.exe) that collectively provide
management, monitoring, and telemetry functionality. In the Linux operating system, the agent
is implemented as a waagent binary (/usr/sbin/waagent).
VM Agent is automatically included when you deploy an Azure VM by using the Image
Gallery via the Azure portal (according to the state of the Install the VM Agent check box,
which is selected by default). When using Azure PowerShell, you can control the VM Agent
installation by leveraging the –ProvisionVMAgent parameter of the Set
AzureRmVMOperatingSystem cmdlet. When using custom images or disks, you have the
option of installing the agent manually. Both the Windows and Linux operating system
versions of the VM Agent are available for download, from the Microsoft Downloads and
Github, respectively. After the installation completes, you also need to set the
ProvisionGuestAgent property of the virtual machine via Azure PowerShell or a REST API
call.
VM Agent Extensions are covered in more details later in this lesson.
Azure crossplatform commandline interface
The Azure crossplatform commandline interface (Azure CLI) is an open source
implementation of a set of shellbased commands allowing you to manage a variety of Azure
resources. You can install it on Windows, Linux, and Macintosh platforms, and run against
both Linuxand Windows based Azure VMs.
Azure PowerShell
Azure PowerShell is an open source Windows PowerShell module that provides management
capabilities equivalent to those offered by Azure CLI. Just like Azure CLI, it allows you to
interact with Azure virtual machines running both the Windows and Linux operating systems,
however, you have to install it on and run it from a computer running the Windows operating
system. The two command line management interfaces (Azure PowerShell and Azure CLI)
offer, for the most part, feature parity, although occasionally you might find one of them
providing more functionality than the other.
Platformspecific management options
Some of the management options are operating systemspecific.
RDP
RDP allows for establishing a graphical user interface session to an Azure virtual machine
running the Windows operating system. When viewing a Windows virtual machine in the
Azure portal, you will have access to the Connect action. This action automatically provisions
an .rdp file, which you can either open or download, and save for later use. Opening the file
initiates an RDP connection to the corresponding VM. The Azure PowerShell Get
AzureRemoteDesktopFile cmdlet delivers the same outcome when you invoke it via a
command line.
Secure Shell
When creating a Linux VM, you have the option to enable Secure Shell (SSH). At that point,
you can establish a connection to this VM by using the SSH protocol from a terminal
emulator, such as PuTTY (available for both Windows and Linux operating systems).
Note: While it is possible to install a thirdparty SSH server on the Windows operating
system (effectively allowing connecting to it from an SSH client, such as PuTTY), this
option is not available directly when deploying Azure virtual machines.
What is the VM Agent Custom Script extension?
The Custom Script extension for Azure virtual machines enables you to invoke local execution
of scripts within a Windows or Linux Azure virtual machine. On the Windows operating
system, you can implement scripts by using Windows PowerShell. The extension for the
Linux operating system allows running code written in any scripting language supported by the
operating system, such as Python or Bash.
The most common use of Custom Script extension involves applying custom configuration
settings during VM provisioning; however, it is also possible to use it to perform any scriptable
action after the initial deployment. The script can reside in an Azure storage account or a
Github location.
Configuring the Custom Script extension
To configure the functionality described in this topic, you need to install the Customs Script
extension in the operating system hosted on an Azure VM that you intend to manage, and
assign the script that you want the extension to execute. You can accomplish this either during
VM provisioning or afterwards by running the SetAzureRmVMCustomScriptExtension
PowerShell cmdlet.
Set-AzureRmVMCustomScriptExtension -ResourceGroupName <Resource

Group name> -Location <Azure region> -VMName <VM name> -Name
<Custom Script extension name> -TypeHandlerVersion "1.4" -
StorageAccountName <Storage account name> -StorageAccountKey
<Storage account key> -FileName <PowerShell script name> -
ContainerName <Storage account container name> -Run <command to
execute>
The cmdlet references the fully qualified location of the script file by using the combination of
the StorageAccountName, ContainerName, and FileName parameters. To obtain access
to the storage account, you need to provide the value of the storage account key (
StorageAccontKey). To specify the command and parameters of the script, respectively, use
the Run and Argument parameters (the value of Run would typically match the value of
FileName). TypeHandlerVersion represents the version of the extension to use (which you
can determine by running the GetAzureRmVMExtensionImage cmdlet with the value of
Microsoft.Compute as the PublisherName parameter and the value of VMAccessAgent as
the Type parameter). ResourceGroupName, Location, and VMName uniquely identify
the target Azure virtual machine.
Alternatively, you can use the SetAzureRMVMExtension Azure PowerShell cmdlet and
specify CustomScriptExtension as the value of its ExtensionType parameter. Note that this
cmdlet supports the use of hash tables to assign values to its Settings and ProtectedSettings
parameters.
$settings = @{“fileUris” = “[]”; “commandToExecute” = “”};
$protectedSettings = @{“storageAccountName = <Storage account

name>; “storageAccountKey” = <Storage account key>};
Set-AzureRmVMExtension -ResourceGroupName <Resource Group name> -

Location <Azure region> -VMName <VM name> -Name <Custom Script
extension name> –Publisher “Microsoft.Compute” –ExtensionType
“CustomScriptExtension” -TypeHandlerVersion "1.4" –Settings
$settings –ProtectedSettings $protectedSettings
The cmdlet is in many aspects similar to SetAzureRmVMCustomScriptExtension. For
example, it also uniquely identifies the target Azure virtual machine by using the combination
of ResourceGroupName, Location, and VMName. On the other hand, it relies on the
two hashtables to point to the location and execution settings of the custom script. Due to its
more generic purpose, it also includes direct references to the extension that you intend to
apply in the form of the Publisher, ExtensionType, and TypeHandlerVersion parameters.
Note: When applying scripts to Azure virtual machines running the Linux operating
system, you would set the Publisher parameter to Microsoft.OSTCExtension and the
ExtensionType parameter to CustomScriptForLinux.
Using Custom Script extension with Resource Manager templates
Another approach to deploying Custom Script extension leverages Resource Manager
templates. The imperative (based on the SetAzureRmExtension cmdlet) and declarative
(based on the Azure Resource Manager template presented here) methods are compatible with
each other, allowing you to deploy the same types of scripts and supporting the same set of
parameters (although with templates, you have to specify the exact version of the handler,
while with scripts, you have the option to use the majorversion.* format). The following
template illustrates this premise, showing you how to apply a script named script1.ps1 to an
Azure virtual machine identified by the vmName and location parameters :
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "MyCustomScriptExtension",
"apiVersion": "2015-05-01-preview",
"location": "[parameters('location')]",
"dependsOn": [
"
[concat('Microsoft.Compute/virtualMachines/',parameters('vmName')
)]"
],
"properties": {
"publisher": "Microsoft.Compute",
"type": "CustomScriptExtension",
"typeHandlerVersion": "1.4",
"settings": {
"fileUris": [
"http://storageaccountname.blob.core.windows.net/customscriptfile
s/script.ps1"
],
"commandToExecute": "powershell.exe -ExecutionPolicy

Unrestricted -File script.ps1"
Additional Reading: For more information on using Custom script extensions with
Azure virtual machines, refer to Using Custom Script extension with Azure Resource
Manager templates: http://aka.ms/Azasu4
What is the VM Agent Desired State Configuration
extension?
PowerShell Desired State Configuration (DSC) is a technology introduced in Windows
Management Framework 4.0 that implements templatebased configuration of Windows and
Linux operating systems, both onpremises and in the cloud. Due to its declarative nature, it
bears some resemblance to Azure Resource Manager, however, while Azure Resource
Manager templates deploy Azure resources such as VMs, DSC targets operating systems
running within these VMs.
In general, DSC leverages functionality incorporated into Windows Management Framework,
however, in case of Azure VMs, this functionality is implemented as a dedicated VM Agent
extension, known as Desired State Configuration extension. When managing Azure IaaS v2
VMs, you can use Azure Resource Manager templates to apply DSC to Azure VMs by
referencing this extension.
DSC relies on the component known as Local Configuration Manager (LCM), which serves as
the execution engine of the DSC PowerShell scripts. LCM is responsible for coordinating
implementation of DSC settings and monitoring their ongoing status. LCM (just as DSC) is an
integral part of Windows Server 2012 R2 and Windows Server 2016. It is also available for
Windows Server 2008 R2 as part of the Windows Management Framework download. The
DSC LCM ConfigurationMode property takes on one of three possible values, which
determine how LCM handles DSC PowerShell scripts:
• ApplyOnly. LCM executes the script only once.
• ApplyAndMonitor. LCM executes the script only once, but monitors the resulting
configuration afterwards and records any configuration drift in logs.
• ApplyAndAutoCorrect. LCM executes the script in regular intervals, automatically
correcting any configuration drift.
DSC relies on small, dedicated pieces of code known as DSC resources to handle resource
specific implementation details. In this context, the term “resource” means any configurable
software component, such as a file, folder, registry, service, or an operating system feature.
DSC includes with a number of builtin resources, but it is extensible, making its management
scope virtually unlimited.
You can deploy DSC configuration in one of two modes, push mode, and pull mode. The
push mode involves invoking deployment from a management computer against one or more
managed computers. In the pull mode managed computers act independently by obtaining
configuration data from a designated location (referred to as a Pull Server). You will focus
here on the push mode. You will revisit the pull mode in the Implementing Azurebased
management and automation module of this course, when describing its role in the context of
Azure Automation.
Creating Windows DSC Configuration scripts
DSC scripts utilize syntax (enclosed in the configuration construct) introduced in Windows
PowerShell v 4.0 (included in Windows Management Framework 4.0) to define the intended
operating system configuration.
Note: In general, it is necessary to convert Windows PowerShell DSC scripts into the
Management Object Format (MOF) node configuration files by compiling them using
Windows PowerShell cmdlets. However, Azure PowerShell handles the compilation
automatically when deploying DSC extensions to Azure VMs running the Windows
operating system.
For example, the following .ps1 file instructs the LCM running on the local computer to install
the Internet Information Services (IIS) server role, the .NET ASP 4.5 feature, and disable the
default website. Note that the task to disable the default website is facilitated by a custom
DCS resource, which you import by adding the ImportDscResource cmdlet. In addition, as
you can easily deduct from the presence of the DependsOn element, you have the ability to
control the sequence of task execution by defining dependencies between them.
configuration IISConfig{ Import-DscResource –Module

xWebAdministration
node ("localhost") {
WindowsFeature IIS {
Ensure = "Present" Name = "Web-Server"

}
WindowsFeature AspNet45 { Ensure = "Present"

Name = "Web-Asp-Net45" }
xWebsite DefaultSite { Ensure = "Present"

Name = "Default Web Site" State =
"Stopped" PhysicalPath = “C:\inetpub\wwwroot"
DependsOn = "[WindowsFeature]IIS" }
}}
Implementing DSC in Azure IaaS v2 Windows VMs
Applying Desired State Configuration to an Azure IaaS v2 virtual machine running Windows
involves a sequence of the following steps:
1. Sign in to your Azure subscription by using the AddAzureRmAccount cmdlet. If you
have multiple subscriptions associated with the same account, ensure you select the
target one by using the SetAzureRmContext cmdlet.
Add-AzureRmAccount
2. Publish Azure DSC configuration to an Azure storage account by running the Publish
AzureRmVMDscConfiguration cmdlet. The configuration (the ConfigurationPath
parameter) takes the form of a Windows PowerShell script (a .ps1 file, like the one listed
in the previous section), a PowerShell module (a .psm1 file), or an archive containing a
combination of scripts, modules, and resources (a .zip file). The
ResourceGroupName, StorageAccountName, and ContainerName parameters
designate the storage account blob container where the configuration will reside.
$moduleURL = Publish-AzureRmVMDscConfiguration -
ConfigurationPath <File system path of the configuration
script> -ResourceGroupName <Name of resource group hosting
the storage account> -StorageAccountName <Storage account
name> –ContainerName <Blob container name >
The publishing process will first generate a .zip file containing all scripts, modules, and
resources referenced by the configuration and then upload this archive into the Azure
storage location you specified.
3. Create a shared access signature token that will provide access to the archive
configuration file residing in the Azure storage account. A shared access signature is a
digitallysigned string that identifies an Azure storage objects and determines access
permissions to that object. In this case, Read permissions will suffice. To create a shared
access signature token, you first need to establish the security context for access to the
target Azure storage account. To establish such context, you need to provide the storage
account name and storage account key (which you can retrieve from the Azure portal or
by using Azure PowerShell).
$storageContext = New-AzureStorageContext –StorageAccountName

<Storage account name> -StorageAccountKey <Storage account
key>
$sasToken = New-AzureStorageContainerSASToken –Name <Blob
container name> –Context $storageContext –Permission r
Note: You will learn about Shared Access Signature and other Azure storage
related topics in more details in the Planning and implementing storage, backup,
and recovery services module of this course.
4. Create a variable that takes the form of a hash table or a string, and contains settings
identifying the location of the DSC archive, DSC configuration function, and the newly
generated shared access signature token.
$settingsHashTable = @{
"ModulesUrl" = "$moduleURL";
"ConfigurationFunction" = <Name of DSC configuration
file>\<Name of DSC configuration>";
"SasToken" = "$sasToken"
}
5. Enable and configure the Azure VM Agent DSC extension by running the Set
AzureRmVMExtension cmdlet. The ResourceGroupName, VMName, and
Location parameters identify the target Azure virtual machine. The Name, Publisher,
ExtensionType, and TypeHandlerVersion parameters designate the intended VM
Agent extension.
Set-AzureRmVMExtension -ResourceGroupName <Resource group name> -

VMName `
<VM name> -Location <Azure region> -Name ‘DSC’ -Publisher
‘Microsoft.PowerShell’ `
-ExtensionType ‘DSC’ -TypeHandlerVersion ‘2.0’ -Settings
$settingsHashTable
Alternatively, as with Custom Script extension, you have the option of using the extension
specific Azure PowerShell cmdlet SetAzureRmVMDscExtension.
Additional Reading: For more information, refer to SetAzureRmVMDscExtension:
http://aka.ms/Cyyypz
Note: As with Custom Script extension scripts, you can reference DSC configuration
files residing either in an Azure storage account or a Github location.
Alternatively, you have the option of deploying the DSC configuration by using the Azure
Resource Manager templates.
Additional Reading: For more information on deploying DSC configuration by using
Azure Resource Manager templates, refer to Developing DSC scripts for the Azure
Resource Manager DSC Extension: http://aka.ms/Er0zdg
Implementing the AzureDSCForLinux extension
Just like the Azure VM Agent, DSC extension extends functionality of DSC to Azure VMs
running the Windows operating system. Azure DSCForLinux Extension provides the ability to
implement desired state configuration for Azure VMs running the Linux operating system.
However, the latter does not rely on Windows Management Framework, but instead delivers
its capabilities based on Open Management Infrastructure (OMI) open source software
packages.
Yet, despite obvious differences resulting from separate operating system platforms, both
technologies are quite similar, at least from the architectural and procedural standpoint. They
both rely on DSC resources to handle resourcespecific implementation details.
AzureDSCForLinux also requires creating a configuration document that follows the same
syntax as its Windows operating system equivalent, including the Configuration keyword.
Similarly, to push configurations to computers running the Linux operating system, you can
use the same Windows PowerShell cmdlets, or you can use Azure CLI if preferred.
The same applies to a comparison between Azure VM Agent DSC extension (for Windows
Azure VMs) and AzureDSCForLinux extension (for Linux Azure VMs). Here as well, the
deployment starts with the creation of a configuration document file, which you need to
subsequently copy to either an Azure storage account or a Github location.
Next, you can use Azure PowerShell or Azure CLI to deploy the configuration to target Azure
VMs in the manner closely resembling the process described in the previous section. Note that
you will need to adjust the Publisher, ExtensionType, and TypeHandlerVersion
parameters accordingly. Alternatively, it is also possible to use an Azure Resource Manager
template to accomplish the same outcome. A description of the first of these two methods
follows:
1. Sign in to your Azure subscription by running the LoginAzureRmAccount cmdlet. If
you have multiple subscriptions associated with the same account, make sure to select
the target subscription by using the SetAzureRmContext cmdlet.
Login-AzureRmAccount
2. Copy the configuration file to an Azure storage account container. For this purpose, you
can use Azure PowerShell, Azure CLI, or any Azure storage tools. Alternatively, you
have the option of storing the file on Github.
3.
Take a note of the storage account name and its key. You can obtain this information
from the Azure portal or by using Azure PowerShell. You will need it to facilitate
retrieval of the configuration file when implementing DSC configuration.
4. Create variables that will contain values necessary to configure the AzureDSCForLinux
extension. As with Azure VM Agent DSC extension for Windows, they include two hash
tables, which you can also implement as strings, as described in the following example.
You will assign them to the SettingString and ProtectedSettingString (or Settings
and ProtectedSettings if you opt to use hash tables) parameters of the Set
AzureRmVMExtension cmdlet. $protectedSettingString stores the information that
facilitates access to the MOF configuration file residing in the Azure storage account.
$SettingString specifies the deployment mode (push mode, in this case).
$protectedSettings = '{
"StorageAccountName": "<Storage account name>",
"StorageAccountKey": "<Storage account key>",
"ContainerName": "<container-name>",
"MofFileName": "<mof-file-name>"
}'
$settings = '{
"Mode": "Push"
}'
5. Deploy the configuration by running the NewAzureRmVMExtension cmdlet. The
ResourceGroupName, VMName, and Location parameters identify the target Azure
virtual machine. The Name, Publisher, ExtensionType, and TypeHandlerVersion
parameters designate the intended VM Agent extension.
Set-AzureRmVMExtension -ResourceGroupName <Resource group name -

VMName <VM name> `
-Location <Azure region> -Name ‘DSCForLinux’ -Publisher
'Microsoft.OSTCExtensions'`
-ExtensionType ‘DSCForLinux’ -TypeHandlerVersion ‘1.0’ -
SettingString $settings `
-ProtectedSettingString $protectedSettings
Monitoring Azure virtual machines
Azure IaaS virtual machines, just like the majority of Azure services, provide the ability to
track their performance, availability, usage, and health. This functionality is exposed directly in
the Azure portal. In addition, it is also possible to manage monitoring programmatically via the
REST API and .NET SDK.
Enabling metrics and diagnostics
You can enable and configure a collection of metrics and diagnostics for an Azure IaaS VM
from its Monitoring lens in the Azure portal By clicking any of the tiles, you will be
automatically redirected to the Diagnostics blade. From here, you need to specify an Azure
storage account that will host collected data, and then decide which metrics and diagnostics
you intend to collect. Below is a list of metrics and diagnostics that you can collect:
• Basic metrics
• Network metrics
• .NET metrics
• ASP.NET metrics
• SQL metrics
• Windows event system logs (including type of events and their verbosity level)
• Windows event security logs (including type of events and their verbosity level)
• Windows event application logs (including type of events and their verbosity level)
• Diagnostics infrastructure logs (including type of events and their verbosity level)
• IIS logs
• Boot diagnostics (providing console output and screenshot support for Azure IaaS v2 VMs)
The ability to collect diagnostics requires presence of VM Agent Diagnostics extension
(IaaSDiagnostics), available for IaaS VMs running either the Windows or the Linux operating
systems.
Working with metrics and diagnostics data
The Azure portal displays charts of the metrics representing performance and usage for each
monitored VM. You can edit and modify any of these charts by rightclicking them and
clicking Edit Chart in the contextsensitive menu. This opens the Edit Chart blade where you
have the option of modifying the time range and the chart type, as well as adding other
metrics.
To view and analyze diagnostics and logs not available directly from the portal, you can use
any tools that provide access to tables and blobs in the Azure storage account hosting collected
data. You have the option to export it into Excel or any Business intelligence application (such
as Azure BI) for further analysis.
Alerts
Alert rules allow you to trigger notifications according to metricsbased criteria you specify.
Each rule includes a metric, condition, threshold, and time period that collectively determine
when to raise an alert. You have the option of sending an email containing the alert notification
to any email address. In addition, it is also possible to route alerts to an arbitrary HTTP or
HTTPS endpoint (which the Azure portal interface references as a Webhook). You should
keep in mind that there is a limit of 250 alerts per subscription.
Demonstration: Configuring IaaS v2 Windows virtual
machines with DSC
In this demonstration, you will see how to apply DSC to an Azure virtual machine running the
Windows operating system.
Demonstration Steps
1. On MIACL1, start File Explorer and browse to D:\Demofiles\Mod04.
2. In the D:\Demofiles\Mod04 folder, rightclick on the IISInstall.ps1 file and select Edit
from the rightclick menu. This will open the file in the Windows PowerShell ISE.
3. Review the content of the file. Note that this is a DSC configuration that controls the
installation of the Windows Server 2012 R2 WebServer role.
4. Close the PowerShell ISE window.
5. In the File Explorer, right click on the D:\Demofiles\Mod04\DeployAzureDSC.ps1 file
and select Edit from the rightclick menu. This will open the file in the Windows
PowerShell ISE.
6. Review the content of the script. Note the variables it uses, including the storage account
and its key. Note that it first publishes the DSC configuration defined in the Install.ps1
file to the same storage account hosting the VHD files of the two virtual machines
(placing it in the default DSC container named windowspowershelldsc), stores the
resulting module URL in a variable, and then sets the Azure Agent VM DSC extension
on two virtual machines deployed in the previous demonstration by referencing that
URL. The script generates a shared access signature token that provides read only access
to the blob representing the DSC configuration archive.
7. Start the execution of the script. When prompted, sign in with the username and the
password of an account that is either a Service Administrator or a CoAdmin of your
Azure subscription. Wait until the script completes.
8. On MIACL1, open Internet Explorer, and then navigate to the Azure portal.
9. Initiate a Remote Desktop session to Demo4VM1 from the Azure portal.
10. When prompted to enter credentials to connect, type Instructor as the user name, and
Pa$$w0rd as the password.
11. After you establish Remote Desktop session to the VM, in the Server Manager window,
verify that IIS appears in the left pane, indicating that the Web Server (IIS) server role
is installed.
12. Repeat steps 7 through 9 for the Demo4VM2 virtual machine.
13. Open Windows PowerShell as an administrator.
14. At the Windows PowerShell command prompt, run the following command:
Reset-Azure
15. When prompted (twice), sign in by using the Microsoft account that is associated with
your Azure subscription.
16. If you have multiple Azure subscriptions, select the one that you want to target with the
script.
17. When prompted for confirmation, press Y.
Note: This script will remove Azure services in your subscription. We therefore
recommended that you use an Azure trial pass that was provisioned specifically for
this course, and not your own Azure account.
The script will take 510 minutes to reset your Azure environment, ready for the next
lab.
The script removes all storage, virtual machines, virtual networks, cloud services, and
resource groups.
Important: The script might not be able to access a storage account to delete it (if this
occurs, you will see an error). If you find objects remaining after the reset script is
complete, you can rerun the ResetAzure script, or you can use the Azure portal and
the Azure classic portal to delete all the objects in your Azure subscription manually—
with the exception of the default directory.
Lesson 4: Managing IaaS v1 virtual machines
The first three lessons of this module focused on managing and monitoring IaaS v2 virtual
machines. However, it is likely that your future experiences with Azure services will involve
administering IaaS v1 virtual machines as well. While they share a number of common
characteristics, there are also some important differences between them of which you should
be aware. In this lesson, you will learn about some of these differences.
Lesson Objectives
• Identify the primary differences in configuring Azure IaaS v1 and IaaS v2 virtual machines.
• Describe how to managing disks and images of IaaS v1 virtual machines.
• Explain how to monitor IaaS v1 virtual machines.
Configuring IaaS v1 virtual machines
One of the main distinguishing characteristics of IaaS v1 virtual machines—in comparison with
IaaS v2—is their inherent dependency on cloud services. Any VM you create by using the
Service Management deployment model becomes part of a new or an existing cloud service. A
cloud service constitutes a logical boundary for virtual machines it contains, offering a number
of additional features, including:
• A public IP address and associated Domain Name System (DNS) name in the cloudapp.net
DNS namespace.
• Support for endpoints, which you can use to expose individual ports of VMs within the
cloud service for external access (from the Internet or other Azure services).
• Automatic name resolution and direct communication between its VMs without the need to
use their fully qualified domain names (FQDNs).
• Automatic assignment of private IP addresses to its VMs.
In addition to being part of a cloud service—which is mandatory in the Service Management
model— a virtual machine can also belong to a virtual network. By implementing this
approach, you allow for direct communication between VMs in different cloud services, as
long as they are on the same virtual network or on virtual networks connected to each other.
To deploy an IaaS v1 VM into a virtual network, you must implement that virtual network by
using Service Management. In other words, IaaS v1 VMs require an IaaS v1 VNet and,
conversely, IaaS v1 VNets support only IaaS v1 VMs.
While the network model changed significantly in Azure Resource Manager, the VNet IP
addressing rules remain the same. This means that you can follow the VNet design guidelines
provided in earlier modules of this course. On the other hand, remember that network
implementation rules have changed in Azure Resource Manager (for a detailed discussion,
refer to the Implementing and managing Azure networking module).
In addition, note that external connectivity to IaaS v1 VMs generally (with the exception of
instancelevel IP addresses, which are described next) relies on cloud service endpoints.
Because IaaS v2 does not support cloud services, you will not be able to leverage topics
applicable to Azure Resource Manager–based implementations, but instead, follow the
information provided here.
An endpoint allows access to a VM residing in a cloud service via its public IP address, either
TCP or UDP protocol, and an arbitrary public port, which maps to a designated internal port
of the VM. By default, provisioning a WindowsIaaS v1 VM automatically creates a Remote
Desktop Protocol (RDP) and a Windows Remote Management (WinRM) endpoint. Similarly,
provisioning a Linux VM results in the creation of a Secure Shell (SSH) endpoint. You have
the option of disabling any of them at the time of deploying the virtual machine or at any point
afterwards. Keep in mind that disabling the endpoint affects only external connectivity, still
allowing you to connect to the virtual machine from within the same cloud service or virtual
network.
You can also create arbitrary endpoints for VMs. Endpoint can be configured as part of a load
balanced set, to provide traffic distribution across multiple VMs. It can also be configured for
direct server return. This provides the VM endpoint the floating IP capability necessary to set
up a SQL AlwaysOn Availability Group.
Instancelevel Public IP Addresses
If you want to be able to connect to a VM from outside the cloud service by an IP address
assigned directly to it, rather than by using the cloud service VIP:<portnumber>, you can
use instancelevel Public IP (PIP) addressing.
Typical usage scenarios for PIPs include:
• Passive FTP. Using a PIP, the VM can receive traffic on any port. This enables scenarios
such as passive FTP where the ports are chosen dynamically.
• Outbound IP. Outbound traffic originating from the VM uses PIP as the source, which
uniquely identifies the VM to external entities.
Azure Load Balancing
Azure Load Balancing for IaaS v1 virtual machines also relies on the capabilities inherent to
cloud services. To configure Azure load balancing across VMs in a cloud service, you must
create the loadbalanced set, and in this set include all of the VMs (within the same cloud
service) that you want to respond to external requests to a particular public IP address and
port number. These VMs listen on their private IP address and private port; the Azure Load
Balancer, therefore, maps the public IP address and port number of the cloud service to the
private IP address and port number of one VM in the set, and reverses this for the response
traffic from the VM.
Direct Server Return
One potential issue with Azure load balancing is the possibility of the load balancer to become
a bottleneck if the volume of traffic is high. To remediate this issue, you can configure a load
balanced set to provide Direct Server Return. This feature allows the VM that is servicing a
client request to respond directly to the client. Effectively, the load balancer is free to handle
new requests, rather than keep processing responses. Direct Server Return is commonly
implemented for video or audio, which are susceptible to network delays.
Availability sets
Another IaaS v1 VM feature that relies on the existence of cloud services is the availability set.
In this context, an availability set represents a logical grouping of virtual machines that belong
to the same cloud service. Just as with IaaS v2 VM–based availability set, each virtual
machine in the same availability set is automatically assigned a distinct Update Domain (up to
two) and a Fault Domain (up to five).
Access Control List
A cloud service facilitates protection of its endpoints by allowing you to associate them with
Access Control Lists (ACLs). An ACL contains a range of external IP addresses for which the
access should be either explicitly permitted or denied. However, the functionality provided by
ACLs has been superseded by Network Security Group, which you can use to control not
only external but also internal (within a virtual network) traffic, so at this point, there is no
compelling reason to use them anymore.
Managing and configuring IaaS v1 VM storage
In general, the concepts applicable to managing disks and images of IaaS v1 virtual machines
have not changed significantly with transition to the Azure Resource Manager model.
However, there are a few important differences that you must consider:
IaaS v1 VMs require an IaaS v1 Azure storage account to host their disks. Similarly, you
cannot deploy an IaaS v1 VM by using an image hosted in an IaaS v2 Azure storage
account.
• To identify IaaS v1 VM images, you need to reference them by the name of the
corresponding VHD file. This changed with the Azure Resource Manager model (for
details, refer to the second lesson of this module).
Command line management of IaaS v1 VM disks also differs from managing their IaaS v2
counterparts, because they use a different set of Azure PowerShell cmdlets. Starting with
Azure PowerShell 1.0, Azure Resource Managercmdlets use the AzureRm substring in place
of the Azure substring present in the Service Management cmdlets. For example, to add a
data disk to an IaaS v1 VM, you would use AddAzureVMDataDisk, but to apply the same
change to an IaaS v2 VM, you would run AddAzureRmVMDataDisk.
Monitoring and managing IaaS v1 VMs
Monitoring options of IaaS v1 VMs do not differ significantly from the functionality available
to IaaS v2 VMs. The same capabilities are exposed in the Azure portal, including metrics,
diagnostics, and alerting. The only exception is support for boot diagnostics (providing console
output and screenshot support) that depend on Azure Resource Manager.
As far as operating system management is concerned, while both Azure Resource Manager
and Service Management provide matching features in this area, the implementation details of
each are different. This is primarily due to the different set of supporting Windows PowerShell
cmdlets and lack of support for templatebased deployments for IaaS v1 VMs. In addition,
Service Managementbased Azure PowerShell scripts are relatively simpler, allowing you, for
example, to leverage default storage account of your Azure subscription for storing Custom
Script extension scripts or DSC configuration archives.
It is important to note that, just as with IaaS v2 VMs, both Custom Script extension and
Desired State Configuration–based management are available for IaaS v1 VMs running both
the Windows and Linux operating systems.
Additional Reading: For more information on implementing custom script extension
in the classic deployment model, refer to Custom Script extension for Windows virtual
machines: http://aka.ms/Pcv1if
Lab: Managing Azure virtual machines
Scenario
Now that you identified basic deployment options of IaaS v2 VMs, you need to start testing
more advanced configuration features. As part of these tests, you need to place the two web
servers, which will host the A. Datum ResDev application, in a loadbalanced availability set.
You will also install IIS on these virtual machines by using the VM Agent DSC extension. In
addition, to enhance Azure IaaS virtual machine storage, you will set up Storage Spaces–based
volumes.
Objectives
After completing this lab, you will be able to:
• Configure Azure virtual machine availability.
• Implement desired state configuration in Azure virtual machines.
• Implement Storage Space–based simple volumes in Azure virtual machines.
Lab Setup
Estimated Time: 60 minutes
Virtual Machine: 20533CMIACL1
User name: Student
Password: Pa$$w0rd
Exercise 1: Configuring availability
Scenario
You need to redeploy the ResDev app to leverage Azure availability capabilities. You will start
by provisioning ResDevWebVM1 and ResDevWebVM2 Azure IaaS v2 VMs into an
availability set named ResDevWebAS. Next, you will create an Azure load balancer and add
both virtual machines to its backend pool.
The main tasks for this exercise are as follows:
1. Create virtual machines in an availability set
2. Configure the Azure Load Balancer
Task 1: Create virtual machines in an availability set
1. On MIACL1, open Internet Explorer and navigate to the Azure portal.
2. When prompted, sign in with an account that is either a Service Administrator or CoAdmin in the
subscription you are using for this lab.
3. From the Azure portal, create a new availability set with the following settings:
o Name: ResDevWebAS
o Fault domains: 3
Note: You can decrease the value to 2, but not increase it.
o Update domains: 5
Note: The number of update domains can vary between 5 and 20.
o Resource group name: ResDevWebAS
o Location: The Azure region closest to the location of your lab computer.
o Name: ResDevWebVM1
o User name: Student
o Resource group: ResDevWebAS
o Size: A1 Standard
o Virtual network: ResDevWebAS
o Public IP address: ResDevWebVM1
o Network security group: ResDevWebVM1
o Availability set: ResDevWebAS
o Name: ResDevWebVM2
o User name: Student
o Size: A1 Standard
o Virtual network: ResDevWebAS
o Public IP address: ResDevWebVM2
o Network security group: ResDevWebVM2
o Availability set: ResDevWebAS
6. From the Azure portal, display the blade of the ResDevWebAS availability set. On the
Demo4AVSet blade, note that the availability set contains the two newly deployed virtual machines
(at this point, both of them will likely display the Creating status). Point out that each VM has a
unique fault domain and update domain.
7. Leave the instance of Internet Explorer with the Azure portal open.
Task 2: Configure the Azure Load Balancer
1. On MIACL1, in the Azure portal within the Internet Explorer window, create a new load balancer
with the following settings:
o Name: ResDevWebLB
o Scheme: Public
o Public IP address: Create a new dynamic address named ResDevWebLBIP.
o Subscription: Your subscription.
o Pin to dashboard: Unchecked
2. Wait for the deployment to complete. This should take a few seconds.
3. From the Azure portal, add a backend pool named ResDevWebLBPool to the newly created load
balancer consisting of the ResDevWebAS availability set and both virtual machines that are part of
it (ResDevWebVM1 and ResDevWebVM2).
4. Add a probe to the load balancer with the following settings:
o Name: ResDevWebProbe80
o Protocol: HTTP
o Port: 80
o Path: /
o Interval: 5
o Unhealthy threshold: 2
5. Add a load balancer rule to the newly created load balancer with the following settings:
o Name: ResDevWebLBRule80
o Protocol: TCP
o Port: 80
o Backend Pool: ResDevWebPool
o Probe: ResDevWebProbe
o Backend port: 80
o Session persistence: None
o Idle timeout: 4
o Floating IP: Disabled
6. Refresh the Azure portal. In the Setting blade of ResDevWebLB, you should be able to identify its
public IP address. Note that at this point you will not be able to connect to the two virtual machines
in the backend pool, because they are not running a web server and the connectivity is additionally
restricted by default network security group settings. You will change these settings later in this lab.
Result: After completing this exercise, you should have created an availability set for Azure
IaaS v2 virtual machines and configured them up as a load balanced pair.
Exercise 2: Implementing DSC
Scenario
You need to test the implementation of the desired state configuration in Azure by using VM
Agent DSC extension to install the default IIS Web site on both virtual machines that will host
the A. Datum ResDev application. Once the installation is complete, you must test the
availability of this setup by verifying that load balanced access to the default Web site is not
affected by shutting down one of the virtual machines.
1. Install and configure IIS by using DSC and Windows PowerShell
2. Test the DSC configuration and virtual machine availability
Task 1: Install and configure IIS by using DSC and Windows PowerShell
1. On MIACL1, start File Explorer and browse to the D:\Labfiles\Lab04\Starter folder.
2. In the D:\Labofiles\Lab04 folder, rightclick on the IISInstall.ps1 file and select Edit from the right
click menu. This will open the file in the Windows PowerShell ISE.
3. Review the content of the file. Note that this is a DSC configuration that controls the installation of
the Windows Server 2012 R2 WebServer role.
4. Close the Windows PowerShell ISE window.
5. In the File Explorer, right click on the D:\Labfiles\Lab04\Starter\DeployAzureDSC.ps1 file and
select Edit from the rightclick menu. This will open the file in the Windows PowerShell ISE
window
6. Review the content of the script. Note the variables that it uses, including the storage account and
its key. The script first publishes the DSC configuration defined in the Install.ps1 file to the same
storage account hosting the VHD files of the two virtual machines (placing it in the default DSC
container named windowspowershelldsc), stores the resulting module URL in a variable, and
then sets the Azure Agent VM DSC extension on two virtual machines deployed in the previous lab
by referencing that URL. The script generates a shared access signature token that provides read
only access to the blob representing the DSC configuration archive.
7. Start the execution of the script. When prompted, sign in with the username and the password of
an account that is either a Service Administrator or a CoAdmin of your Azure subscription. Wait
until the script completes.
8. On MIACL1, open Internet Explorer and navigate to the Azure portal.
9. Initiate a Remote Desktop session to ResDevWebVM1 from the Azure portal.
10. When prompted to enter credentials to connect, type Student as the user name and Pa$$w0rd as
the password.
11. Once you establish a Remote Desktop session to the VM, in the Server Manager window, verify
that IIS appears in the left pane, indicating that the Web Server (IIS) server role is installed.
12. Repeat steps 7 through 9 for the other virtual machine, ResDevWebVM2.
13. After completing the tasks, switch back to your lab computer MIACL1. Leave both Remote Desktop
sessions open.
Task 2: Test the DSC configuration and virtual machine availability
1. From the Azure portal within the Internet Explorer window on MIACL1, create a new inbound
security rule for the ResDevWebVM1 security group with the following settings:
o Name: allowhttp
o Priority: 1100
o Source: Any
o Protocol: TCP
o Source port range: *
o Destination: Any
o Destination port range: 80
o Action: Allow
2. From the Azure portal within the Internet Explorer window on MIACL1, create a new inbound
security rule for the ResDevWebVM2 security group with the following settings:
o Name: allowhttp
o Priority: 1100
o Source: Any
o Protocol: TCP
o Source port range: *
o Destination: Any
o Destination port range: 80
o Action: Allow
3. From the Azure portal, identify the IP address of the ResDevWebLB load balancer.
4. From MIACL1, open a new InPrivate Browsing Internet Explorer session and browse to this IP
address.
5. Verify that you can access the default IIS webpage and close the InPrivate Browsing session.
6. From the Remote Desktop session window, stop the World Wide Web Publishing Service
service on both ResDevWebVM1 and ResDevWebVM2.
7. From MIACL1, open a new InPrivate Browsing Internet Explorer session.
8. In the new InPrivate Browsing window, delete browsing history.
9. Browse to the IP address of the ResDevWebLB load balancer again and verify that you can no
longer access the default IIS webpage.
10. From the Remote Desktop session window, start the World Wide Web Publishing Service
service on ResDevWebVM1.
11. Once the service is running, switch back to MIACL1 and refresh the InPrivate Browsing Internet
Explorer window. Verify that you can again access the default the default IIS webpage.
Note: Optionally you can repeat this sequence, but this time stopping the World Wide Web
Publishing Service on ResDevWebVM1 and starting it on ResDevWebVM2. As long as the
service is running on at least one of the two virtual machines, you should be able to access the
webpage.
Result: After completing this exercise, you should have implemented DSC.
Exercise 3: Implementing Storage Space–based volumes
Scenario
To test enhanced storage configuration of the virtual machines that will host the A. Datum
ResDev application, you need to create three new virtual machine disks, attach them to one of
the virtual machines, and create a Storage Spaces volume on the virtual machine.
1. Attach VHDs to an Azure VM
2. Configure a Storage Spaces simple volume
3. Reset the environment
Task 1: Attach VHDs to an Azure VM
1. On MIACL1, from the Azure portal in the Internet Explorer window, attach two data disks to the
ResDevWebVM1 virtual machine with the following settings:
o Name: Accept the default
o Type: Standard
o Size: 1023
o Location: Note that this cannot be changed since the location of the VM determines the
location of its disks.
o Host caching: None
2. Note that with current VM size (Standard A1), there is a limit of 2 data disks per VM.
Task 2: Configure a Storage Spaces simple volume
1. On MIACL1, switch to the Remote Desktop session to ResDevWebVM1.
2. While connected to ResDevWebVM1, from the Server Manager window, create a storage pool
named StoragePool1 consisting of two newly attached disks.
3. From the Server Manager window, create a new virtual disk named VirtualDisk1 using
StoragePool1 with the Simple storage layout, the Fixed provisioning type, and the maximum size.
4. From the Server Manager window, create a new 2 TB volume as drive F formatted with NTFS and a
default allocation unit.
5. From the desktop of ResDevWebVM1, open File Explorer and verify that there is a new drive F with
2 TB of available disk space.
6. Close the Remote Desktop session to ResDevWebVM1.
Task 3: Reset the environment
1. Launch Windows PowerShell as Administrator.
2. From the Windows PowerShell prompt, run:
Reset-Azure
3. When prompted (twice), sign in using the Microsoft account associated with your Azure
subscription.
4. If you have multiple Azure subscriptions, select the one you want to target by the script.
Note: This script will remove Azure services in your subscription. We, therefore,
recommend that you use an Azure trial pass that was provisioned specifically for this
course, and not your own Azure account.
The script will take 5 to 10 minutes to reset your Microsoft Azure environment, before it is
ready for the next lab.
The script removes all storage, VMs, virtual networks, cloud services, and resource
groups.
5. When prompted for confirmation, type y.
Result: After completing this exercise, you should have implemented Storage Spaces based
volumes.
Review Information
Review Question(s)
Module Review and Takeaways
Review Question(s)

Module 4 - Managing Virtual Machines

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Module 4 - Managing Virtual Machines

Hochgeladen von

Copyright:

Verfügbare Formate

6/1/2017 Module 4: Managing virtual machines

Add-AzureRmVMDataDisk –ResourceGroupName <Resource Group name> –

Remove-AzureRmVMDataDisk –VM <VM object> -DataDiskNames <Disk

$storageAccount = New-AzureRmStorageAccount –ResourceGroupName

$vm = New-AzureRmVMConfig –VMName $VMName -VMSize $VMSize

Set-AzureRmVMCustomScriptExtension -ResourceGroupName <Resource

$settings = @{“fileUris” = “[]”; “commandToExecute” = “”};

$protectedSettings = @{“storageAccountName = <Storage account

Set-AzureRmVMExtension -ResourceGroupName <Resource Group name> -

"commandToExecute": "powershell.exe -ExecutionPolicy

configuration IISConfig{ Import-DscResource –Module

Ensure = "Present" Name = "Web-Server"

WindowsFeature AspNet45 { Ensure = "Present"

xWebsite DefaultSite { Ensure = "Present"

$storageContext = New-AzureStorageContext –StorageAccountName

Set-AzureRmVMExtension -ResourceGroupName <Resource group name> -

Set-AzureRmVMExtension -ResourceGroupName <Resource group name -

Das könnte Ihnen auch gefallen