20533D ENU TrainerHandbook PDF

MCT USE ONLY.
STUDENT USE PROHIBITED

O F F I C I A L M I C R O S O F T L E A R N I N G P R O D U C T
20533D
Implementing Microsoft Azure
Infrastructure Solutions
MCT USE ONLY. STUDENT USE PROHIBITED
ii Implementing Microsoft Azure Infrastructure Solutions
Information in this document, including URL and other Internet Web site references, is subject to change
without notice. Unless otherwise noted, the example companies, organizations, products, domain names,
e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with
any real company, organization, product, domain name, e-mail address, logo, person, place or event is
intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the
user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in
or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
The names of manufacturers, products, or URLs are provided for informational purposes only and
Microsoft makes no representations and warranties, either expressed, implied, or statutory, regarding
these manufacturers or the use of the products with any Microsoft technologies. The inclusion of a
manufacturer or product does not imply endorsement of Microsoft of the manufacturer or product. Links
may be provided to third party sites. Such sites are not under the control of Microsoft and Microsoft is not
responsible for the contents of any linked site or any link contained in a linked site, or any changes or
updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission
received from any linked site. Microsoft is providing these links to you only as a convenience, and the
inclusion of any link does not imply endorsement of Microsoft of the site or the products contained
therein.
© 2017 Microsoft Corporation. All rights reserved.
Microsoft and the trademarks listed at https://www.microsoft.com/en-us/legal/intellectualproperty

/Trademarks/Usage/General.aspx are trademarks of the Microsoft group of companies. All other
trademarks are property of their respective owners.
Product Number: 20533D
Part Number: X21-56544

MICROSOFT LICENSE TERMS
MICROSOFT INSTRUCTOR-LED COURSEWARE
These license terms are an agreement between Microsoft Corporation (or based on where you live, one of its
affiliates) and you. Please read them. They apply to your use of the content accompanying this agreement which
includes the media on which you received it, if any. These license terms also apply to Trainer Content and any
updates and supplements for the Licensed Content unless other terms accompany those items. If so, those terms
apply.
BY ACCESSING, DOWNLOADING OR USING THE LICENSED CONTENT, YOU ACCEPT THESE TERMS.
IF YOU DO NOT ACCEPT THEM, DO NOT ACCESS, DOWNLOAD OR USE THE LICENSED CONTENT.
If you comply with these license terms, you have the rights below for each license you acquire.
1. DEFINITIONS.
a. “Authorized Learning Center” means a Microsoft IT Academy Program Member, Microsoft Learning
Competency Member, or such other entity as Microsoft may designate from time to time.
b. “Authorized Training Session” means the instructor-led training class using Microsoft Instructor-Led
Courseware conducted by a Trainer at or through an Authorized Learning Center.
c. “Classroom Device” means one (1) dedicated, secure computer that an Authorized Learning Center owns
or controls that is located at an Authorized Learning Center’s training facilities that meets or exceeds the
hardware level specified for the particular Microsoft Instructor-Led Courseware.
d. “End User” means an individual who is (i) duly enrolled in and attending an Authorized Training Session
or Private Training Session, (ii) an employee of a MPN Member, or (iii) a Microsoft full-time employee.
e. “Licensed Content” means the content accompanying this agreement which may include the Microsoft
Instructor-Led Courseware or Trainer Content.
f. “Microsoft Certified Trainer” or “MCT” means an individual who is (i) engaged to teach a training session
to End Users on behalf of an Authorized Learning Center or MPN Member, and (ii) currently certified as a
Microsoft Certified Trainer under the Microsoft Certification Program.
g. “Microsoft Instructor-Led Courseware” means the Microsoft-branded instructor-led training course that
educates IT professionals and developers on Microsoft technologies. A Microsoft Instructor-Led
Courseware title may be branded as MOC, Microsoft Dynamics or Microsoft Business Group courseware.
h. “Microsoft IT Academy Program Member” means an active member of the Microsoft IT Academy
Program.
i. “Microsoft Learning Competency Member” means an active member of the Microsoft Partner Network
program in good standing that currently holds the Learning Competency status.
j. “MOC” means the “Official Microsoft Learning Product” instructor-led courseware known as Microsoft
Official Course that educates IT professionals and developers on Microsoft technologies.
k. “MPN Member” means an active Microsoft Partner Network program member in good standing.
l. “Personal Device” means one (1) personal computer, device, workstation or other digital electronic device
that you personally own or control that meets or exceeds the hardware level specified for the particular
Microsoft Instructor-Led Courseware.
m. “Private Training Session” means the instructor-led training classes provided by MPN Members for
corporate customers to teach a predefined learning objective using Microsoft Instructor-Led Courseware.
These classes are not advertised or promoted to the general public and class attendance is restricted to
individuals employed by or contracted by the corporate customer.
n. “Trainer” means (i) an academically accredited educator engaged by a Microsoft IT Academy Program
Member to teach an Authorized Training Session, and/or (ii) a MCT.
o. “Trainer Content” means the trainer version of the Microsoft Instructor-Led Courseware and additional
supplemental content designated solely for Trainers’ use to teach a training session using the Microsoft
Instructor-Led Courseware. Trainer Content may include Microsoft PowerPoint presentations, trainer
preparation guide, train the trainer materials, Microsoft One Note packs, classroom setup guide and Pre-
release course feedback form. To clarify, Trainer Content does not include any software, virtual hard
disks or virtual machines.
2. USE RIGHTS. The Licensed Content is licensed not sold. The Licensed Content is licensed on a one copy
per user basis, such that you must acquire a license for each individual that accesses or uses the Licensed
Content.
2.1 Below are five separate sets of use rights. Only one set of rights apply to you.
a. If you are a Microsoft IT Academy Program Member:

i. Each license acquired on behalf of yourself may only be used to review one (1) copy of the Microsoft
Instructor-Led Courseware in the form provided to you. If the Microsoft Instructor-Led Courseware is
in digital format, you may install one (1) copy on up to three (3) Personal Devices. You may not
install the Microsoft Instructor-Led Courseware on a device you do not own or control.
ii. For each license you acquire on behalf of an End User or Trainer, you may either:
1. distribute one (1) hard copy version of the Microsoft Instructor-Led Courseware to one (1) End
User who is enrolled in the Authorized Training Session, and only immediately prior to the
commencement of the Authorized Training Session that is the subject matter of the Microsoft
Instructor-Led Courseware being provided, or
2. provide one (1) End User with the unique redemption code and instructions on how they can
access one (1) digital version of the Microsoft Instructor-Led Courseware, or
3. provide one (1) Trainer with the unique redemption code and instructions on how they can
access one (1) Trainer Content,
provided you comply with the following:
iii. you will only provide access to the Licensed Content to those individuals who have acquired a valid
license to the Licensed Content,
iv. you will ensure each End User attending an Authorized Training Session has their own valid licensed
copy of the Microsoft Instructor-Led Courseware that is the subject of the Authorized Training
Session,
v. you will ensure that each End User provided with the hard-copy version of the Microsoft Instructor-
Led Courseware will be presented with a copy of this agreement and each End User will agree that
their use of the Microsoft Instructor-Led Courseware will be subject to the terms in this agreement
prior to providing them with the Microsoft Instructor-Led Courseware. Each individual will be required
to denote their acceptance of this agreement in a manner that is enforceable under local law prior to
their accessing the Microsoft Instructor-Led Courseware,
vi. you will ensure that each Trainer teaching an Authorized Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Authorized Training Session,
vii. you will only use qualified Trainers who have in-depth knowledge of and experience with the
Microsoft technology that is the subject of the Microsoft Instructor-Led Courseware being taught for
all your Authorized Training Sessions,
viii. you will only deliver a maximum of 15 hours of training per week for each Authorized Training
Session that uses a MOC title, and
ix. you acknowledge that Trainers that are not MCTs will not have access to all of the trainer resources
for the Microsoft Instructor-Led Courseware.
b. If you are a Microsoft Learning Competency Member:

User attending the Authorized Training Session and only immediately prior to the
commencement of the Authorized Training Session that is the subject matter of the Microsoft
Instructor-Led Courseware provided, or
2. provide one (1) End User attending the Authorized Training Session with the unique redemption
code and instructions on how they can access one (1) digital version of the Microsoft Instructor-
Led Courseware, or
3. you will provide one (1) Trainer with the unique redemption code and instructions on how they
can access one (1) Trainer Content,
iv. you will ensure that each End User attending an Authorized Training Session has their own valid
licensed copy of the Microsoft Instructor-Led Courseware that is the subject of the Authorized
Training Session,
v. you will ensure that each End User provided with a hard-copy version of the Microsoft Instructor-Led
Courseware will be presented with a copy of this agreement and each End User will agree that their
use of the Microsoft Instructor-Led Courseware will be subject to the terms in this agreement prior to
providing them with the Microsoft Instructor-Led Courseware. Each individual will be required to
denote their acceptance of this agreement in a manner that is enforceable under local law prior to
vi. you will ensure that each Trainer teaching an Authorized Training Session has their own valid
licensed copy of the Trainer Content that is the subject of the Authorized Training Session,
vii. you will only use qualified Trainers who hold the applicable Microsoft Certification credential that is
the subject of the Microsoft Instructor-Led Courseware being taught for your Authorized Training
Sessions,
viii. you will only use qualified MCTs who also hold the applicable Microsoft Certification credential that is
the subject of the MOC title being taught for all your Authorized Training Sessions using MOC,
ix. you will only provide access to the Microsoft Instructor-Led Courseware to End Users, and
x. you will only provide access to the Trainer Content to Trainers.
c. If you are a MPN Member:
User attending the Private Training Session, and only immediately prior to the commencement
of the Private Training Session that is the subject matter of the Microsoft Instructor-Led
Courseware being provided, or
2. provide one (1) End User who is attending the Private Training Session with the unique
redemption code and instructions on how they can access one (1) digital version of the
Microsoft Instructor-Led Courseware, or
3. you will provide one (1) Trainer who is teaching the Private Training Session with the unique
redemption code and instructions on how they can access one (1) Trainer Content,
iv. you will ensure that each End User attending an Private Training Session has their own valid licensed
copy of the Microsoft Instructor-Led Courseware that is the subject of the Private Training Session,
v. you will ensure that each End User provided with a hard copy version of the Microsoft Instructor-Led
Courseware will be presented with a copy of this agreement and each End User will agree that their
use of the Microsoft Instructor-Led Courseware will be subject to the terms in this agreement prior to
providing them with the Microsoft Instructor-Led Courseware. Each individual will be required to
denote their acceptance of this agreement in a manner that is enforceable under local law prior to
vi. you will ensure that each Trainer teaching an Private Training Session has their own valid licensed
copy of the Trainer Content that is the subject of the Private Training Session,
vii. you will only use qualified Trainers who hold the applicable Microsoft Certification credential that is
the subject of the Microsoft Instructor-Led Courseware being taught for all your Private Training
Sessions,
viii. you will only use qualified MCTs who hold the applicable Microsoft Certification credential that is the
subject of the MOC title being taught for all your Private Training Sessions using MOC,
ix. you will only provide access to the Microsoft Instructor-Led Courseware to End Users, and
x. you will only provide access to the Trainer Content to Trainers.
d. If you are an End User:

For each license you acquire, you may use the Microsoft Instructor-Led Courseware solely for your
personal training use. If the Microsoft Instructor-Led Courseware is in digital format, you may access the
Microsoft Instructor-Led Courseware online using the unique redemption code provided to you by the
training provider and install and use one (1) copy of the Microsoft Instructor-Led Courseware on up to
three (3) Personal Devices. You may also print one (1) copy of the Microsoft Instructor-Led Courseware.
You may not install the Microsoft Instructor-Led Courseware on a device you do not own or control.
e. If you are a Trainer.

i. For each license you acquire, you may install and use one (1) copy of the Trainer Content in the
form provided to you on one (1) Personal Device solely to prepare and deliver an Authorized
Training Session or Private Training Session, and install one (1) additional copy on another Personal
Device as a backup copy, which may be used only to reinstall the Trainer Content. You may not
install or use a copy of the Trainer Content on a device you do not own or control. You may also
print one (1) copy of the Trainer Content solely to prepare for and deliver an Authorized Training
Session or Private Training Session.
ii. You may customize the written portions of the Trainer Content that are logically associated with
instruction of a training session in accordance with the most recent version of the MCT agreement.
If you elect to exercise the foregoing rights, you agree to comply with the following: (i)
customizations may only be used for teaching Authorized Training Sessions and Private Training
Sessions, and (ii) all customizations will comply with this agreement. For clarity, any use of
“customize” refers only to changing the order of slides and content, and/or not using all the slides or
content, it does not mean changing or modifying any slide or content.
2.2 Separation of Components. The Licensed Content is licensed as a single unit and you may not
separate their components and install them on different devices.
2.3 Redistribution of Licensed Content. Except as expressly provided in the use rights above, you may
not distribute any Licensed Content or any portion thereof (including any permitted modifications) to any
third parties without the express written permission of Microsoft.
2.4 Third Party Notices. The Licensed Content may include third party code tent that Microsoft, not the
third party, licenses to you under this agreement. Notices, if any, for the third party code ntent are included
for your information only.
2.5 Additional Terms. Some Licensed Content may contain components with additional terms,
conditions, and licenses regarding its use. Any non-conflicting terms in those conditions and licenses also
apply to your use of that respective component and supplements the terms described in this agreement.
3. LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Content’s subject

matter is based on a pre-release version of Microsoft technology (“Pre-release”), then in addition to the
other provisions in this agreement, these terms also apply:
a. Pre-Release Licensed Content. This Licensed Content subject matter is on the Pre-release version of
the Microsoft technology. The technology may not work the way a final version of the technology will
and we may change the technology for the final version. We also may not release a final version.
Licensed Content based on the final version of the technology may not contain the same information as
the Licensed Content based on the Pre-release version. Microsoft is under no obligation to provide you
with any further content, including any Licensed Content based on the final version of the technology.
b. Feedback. If you agree to give feedback about the Licensed Content to Microsoft, either directly or
through its third party designee, you give to Microsoft without charge, the right to use, share and
commercialize your feedback in any way and for any purpose. You also give to third parties, without
charge, any patent rights needed for their products, technologies and services to use or interface with
any specific parts of a Microsoft technology, Microsoft product, or service that includes the feedback.
You will not give feedback that is subject to a license that requires Microsoft to license its technology,
technologies, or products to third parties because we include your feedback in them. These rights
survive this agreement.
c. Pre-release Term. If you are an Microsoft IT Academy Program Member, Microsoft Learning
Competency Member, MPN Member or Trainer, you will cease using all copies of the Licensed Content on
the Pre-release technology upon (i) the date which Microsoft informs you is the end date for using the
Licensed Content on the Pre-release technology, or (ii) sixty (60) days after the commercial release of the
technology that is the subject of the Licensed Content, whichever is earliest (“Pre-release term”).
Upon expiration or termination of the Pre-release term, you will irretrievably delete and destroy all copies
of the Licensed Content in your possession or under your control.
4. SCOPE OF LICENSE. The Licensed Content is licensed, not sold. This agreement only gives you some
rights to use the Licensed Content. Microsoft reserves all other rights. Unless applicable law gives you more
rights despite this limitation, you may use the Licensed Content only as expressly permitted in this
agreement. In doing so, you must comply with any technical limitations in the Licensed Content that only
allows you to use it in certain ways. Except as expressly permitted in this agreement, you may not:
• access or allow any individual to access the Licensed Content if they have not acquired a valid license
for the Licensed Content,
• alter, remove or obscure any copyright or other protective notices (including watermarks), branding
or identifications contained in the Licensed Content,
• modify or create a derivative work of any Licensed Content,
• publicly display, or make the Licensed Content available for others to access or use,
• copy, print, install, sell, publish, transmit, lend, adapt, reuse, link to or post, make available or
distribute the Licensed Content to any third party,
• work around any technical limitations in the Licensed Content, or
• reverse engineer, decompile, remove or otherwise thwart any protections or disassemble the
Licensed Content except and only to the extent that applicable law expressly permits, despite this
limitation.
5. RESERVATION OF RIGHTS AND OWNERSHIP. Microsoft reserves all rights not expressly granted to
you in this agreement. The Licensed Content is protected by copyright and other intellectual property laws
and treaties. Microsoft or its suppliers own the title, copyright, and other intellectual property rights in the
Licensed Content.
6. EXPORT RESTRICTIONS. The Licensed Content is subject to United States export laws and regulations.
You must comply with all domestic and international export laws and regulations that apply to the Licensed
Content. These laws include restrictions on destinations, end users and end use. For additional information,
see www.microsoft.com/exporting.
7. SUPPORT SERVICES. Because the Licensed Content is “as is”, we may not provide support services for it.
8. TERMINATION. Without prejudice to any other rights, Microsoft may terminate this agreement if you fail
to comply with the terms and conditions of this agreement. Upon termination of this agreement for any
reason, you will immediately stop all use of and delete and destroy all copies of the Licensed Content in
your possession or under your control.
9. LINKS TO THIRD PARTY SITES. You may link to third party sites through the use of the Licensed
Content. The third party sites are not under the control of Microsoft, and Microsoft is not responsible for
the contents of any third party sites, any links contained in third party sites, or any changes or updates to
third party sites. Microsoft is not responsible for webcasting or any other form of transmission received
from any third party sites. Microsoft is providing these links to third party sites to you only as a
convenience, and the inclusion of any link does not imply an endorsement by Microsoft of the third party
site.
10. ENTIRE AGREEMENT. This agreement, and any additional terms for the Trainer Content, updates and
supplements are the entire agreement for the Licensed Content, updates and supplements.
11. APPLICABLE LAW.

a. United States. If you acquired the Licensed Content in the United States, Washington state law governs
the interpretation of this agreement and applies to claims for breach of it, regardless of conflict of laws
principles. The laws of the state where you live govern all other claims, including claims under state
consumer protection laws, unfair competition laws, and in tort.
b. Outside the United States. If you acquired the Licensed Content in any other country, the laws of that
country apply.
12. LEGAL EFFECT. This agreement describes certain legal rights. You may have other rights under the laws
of your country. You may also have rights with respect to the party from whom you acquired the Licensed
Content. This agreement does not change your rights under the laws of your country if the laws of your
country do not permit it to do so.
13. DISCLAIMER OF WARRANTY. THE LICENSED CONTENT IS LICENSED "AS-IS" AND "AS
AVAILABLE." YOU BEAR THE RISK OF USING IT. MICROSOFT AND ITS RESPECTIVE
AFFILIATES GIVES NO EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS. YOU MAY
HAVE ADDITIONAL CONSUMER RIGHTS UNDER YOUR LOCAL LAWS WHICH THIS AGREEMENT
CANNOT CHANGE. TO THE EXTENT PERMITTED UNDER YOUR LOCAL LAWS, MICROSOFT AND
ITS RESPECTIVE AFFILIATES EXCLUDES ANY IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
14. LIMITATION ON AND EXCLUSION OF REMEDIES AND DAMAGES. YOU CAN RECOVER FROM
MICROSOFT, ITS RESPECTIVE AFFILIATES AND ITS SUPPLIERS ONLY DIRECT DAMAGES UP
TO US$5.00. YOU CANNOT RECOVER ANY OTHER DAMAGES, INCLUDING CONSEQUENTIAL,
LOST PROFITS, SPECIAL, INDIRECT OR INCIDENTAL DAMAGES.
This limitation applies to

o anything related to the Licensed Content, services, content (including code) on third party Internet
sites or third-party programs; and
o claims for breach of contract, breach of warranty, guarantee or condition, strict liability, negligence,
or other tort to the extent permitted by applicable law.
It also applies even if Microsoft knew or should have known about the possibility of the damages. The
above limitation or exclusion may not apply to you because your country may not allow the exclusion or
limitation of incidental, consequential or other damages.
Please note: As this Licensed Content is distributed in Quebec, Canada, some of the clauses in this
agreement are provided below in French.
Remarque : Ce le contenu sous licence étant distribué au Québec, Canada, certaines des clauses
dans ce contrat sont fournies ci-dessous en français.
EXONÉRATION DE GARANTIE. Le contenu sous licence visé par une licence est offert « tel quel ». Toute
utilisation de ce contenu sous licence est à votre seule risque et péril. Microsoft n’accorde aucune autre garantie
expresse. Vous pouvez bénéficier de droits additionnels en vertu du droit local sur la protection dues
consommateurs, que ce contrat ne peut modifier. La ou elles sont permises par le droit locale, les garanties
implicites de qualité marchande, d’adéquation à un usage particulier et d’absence de contrefaçon sont exclues.
LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES

DOMMAGES. Vous pouvez obtenir de Microsoft et de ses fournisseurs une indemnisation en cas de dommages
directs uniquement à hauteur de 5,00 $ US. Vous ne pouvez prétendre à aucune indemnisation pour les autres
dommages, y compris les dommages spéciaux, indirects ou accessoires et pertes de bénéfices.
Cette limitation concerne:
• tout ce qui est relié au le contenu sous licence, aux services ou au contenu (y compris le code)
figurant sur des sites Internet tiers ou dans des programmes tiers; et.
• les réclamations au titre de violation de contrat ou de garantie, ou au titre de responsabilité
stricte, de négligence ou d’une autre faute dans la limite autorisée par la loi en vigueur.
Elle s’applique également, même si Microsoft connaissait ou devrait connaître l’éventualité d’un tel dommage. Si
votre pays n’autorise pas l’exclusion ou la limitation de responsabilité pour les dommages indirects, accessoires
ou de quelque nature que ce soit, il se peut que la limitation ou l’exclusion ci-dessus ne s’appliquera pas à votre
égard.
EFFET JURIDIQUE. Le présent contrat décrit certains droits juridiques. Vous pourriez avoir d’autres droits
prévus par les lois de votre pays. Le présent contrat ne modifie pas les droits que vous confèrent les lois de votre
pays si celles-ci ne le permettent pas.
Revised July 2013

Implementing Microsoft Azure Infrastructure Solutions xi
xii Implementing Microsoft Azure Infrastructure Solutions
Acknowledgments
Microsoft Learning would like to acknowledge and thank the following for their contributions in this title’s
development. Their effort at various stages of development has ensured that you have a good classroom
experience.
Marcin Policht: Content Developer

Marcin Policht obtained his Masters of Computer Science degree 18 years ago, and since then has worked
in the Information Technology (IT) field, focusing primarily on directory services, virtualization, system
management, and database management. Marcin authored the first book dedicated to Windows
Management Instrumentation, and co-wrote several others on topics ranging from core operating system
features to high-availability solutions. His articles have been published on ServerWatch.com and
DatabaseJournal.com. Marcin has been a Microsoft Most Valuable Professional (MVP) for the last seven
years.
Telmo Sampaio: Technical Reviewer

Telmo Sampaio is a Sr. Program Manager for the Azure CAT group at Microsoft, where he specializes in
identifying patterns and creating guidance for Azure customers. He is a trainer, architect, developer,
consultant, author, and speaker at events such as Ignite, Build, TechEd, MMS, and PASS. Telmo is very
active in the MCT community, being one of the first MCT Regional Leads.
Implementing Microsoft Azure Infrastructure Solutions xiii
Contents
Module 1: Introduction to Microsoft Azure
Module Overview 1-1
Lesson 1: Cloud technology overview 1-2
Lesson 2: Overview of Azure 1-6
Lesson 3: Managing Azure with the Azure portal 1-22

Lesson 4: Managing Azure with Windows PowerShell 1-26
Lesson 5: Managing Azure with Azure CLI 1-33
Lesson 6: Overview of Azure deployment models 1-37

Lesson 7: Managing and monitoring Azure resources 1-51
Lab: Managing Microsoft Azure 1-55
Module Review and Takeaways 1-56
Module 2: Implementing and managing Azure networking

Module Overview 2-1
Lesson 1: Overview of Azure networking 2-2
Lesson 2: Implementing and managing virtual networks 2-21
Lab A: Using a deployment template and Azure PowerShell to implement

Azure virtual networks 2-28
Lesson 3: Configuring an Azure virtual network 2-29
Lesson 4: Configuring virtual network connectivity 2-39
Lesson 5: Overview of Azure classic networking 2-58
Lab B: Configuring VNet peering 2-66
Module 3: Implementing virtual machines

Module Overview 3-1
Lesson 1: Overview of Azure VMs 3-2
Lesson 2: Planning deployment of Azure VMs 3-7
Lesson 3: Deploying Azure VMs 3-18
Lab A: Deploying Azure VMs 3-30
Lesson 4: Overview of classic VMs 3-31
Lab B: Deploying Azure VMs by using Azure Resource Manager templates 3-34

xiv Implementing Microsoft Azure Infrastructure Solutions
Module 4: Managing Azure VMs

Module Overview 4-1
Lesson 1: Configuring Azure VMs 4-2

Lesson 2: Managing disks of Azure VMs 4-10
Lesson 3: Managing and monitoring Azure VMs 4-17
Lesson 4: Managing classic Azure VMs 4-28

Lab: Managing Azure VMs 4-32
Module 5: Implementing Azure App Service

Module Overview 5-1
Lesson 1: Introduction to App Service 5-2
Lesson 2: Planning app deployment in App Service 5-12
Lesson 3: Implementing and maintaining web apps 5-16
Lesson 4: Configuring web apps 5-24
Lesson 5: Monitoring web apps and WebJobs 5-32
Lesson 6: Implementing mobile apps 5-37
Lesson 7: Implementing Traffic Manager 5-42
Lab: Implementing web apps 5-47
Module 6: Planning and implementing storage, backup, and recovery services

Module Overview 6-1
Lesson 1: Planning storage 6-2
Lesson 2: Implementing and managing Azure Storage 6-12
Lesson 3: Implementing Azure CDNs 6-25
Lesson 4: Implementing Azure Backup 6-31
Lesson 5: Planning and implementing Azure Site Recovery 6-38
Lab: Planning and implementing Azure Storage 6-46
Module 7: Implementing containers in Azure

Module Overview 7-1
Lesson 1: Implementing Windows and Linux containers in Azure 7-2
Lab A: Implementing containers on Azure VMs 7-14
Lesson 2: Implementing ACS 7-15

Lab B: Implementing Azure Container Service 7-28

Implementing Microsoft Azure Infrastructure Solutions xv
Module 8: Implementing Azure Cloud Services

Module Overview 8-1
Lesson 1: Planning and deploying Azure Cloud Services 8-2

Lesson 2: Managing and maintaining Azure Cloud Services 8-10
Lab: Implementing Azure Cloud Services 8-18
Module 9: Implementing Azure Active Directory

Module Overview 9-1
Lesson 1: Creating and managing Azure AD tenants 9-2
Lesson 2: Configuring application and resource access with Azure AD 9-16

Lesson 3: Overview of Azure AD Premium 9-23
Lab: Implementing Azure AD 9-30
Module 10: Managing an Active Directory infrastructure in a hybrid environment

Module Overview 10-1
Lesson 1: Extending an on-premises Active Directory domain to Azure IaaS 10-2
Lesson 2: Implementing directory synchronization by using Azure AD Connect 10-8
Lesson 3: Implementing SSO in hybrid scenarios 10-27
Lab: Implementing and managing Azure AD synchronization 10-36
Module 11: Implementing Azure-based management and automation

Lesson 1: Implementing OMS 11-2
Lesson 2: Implementing Azure Automation 11-9

Lesson 3: Implementing Automation runbooks 11-15
Lesson 4: Implementing Azure Automation–based management 11-22
Lab: Implementing Automation 11-26

About This Course xvii
About This Course

This section provides a brief description of your course, including information about the intended
audience, suggested prerequisites, and course objectives.
Course Description
This course teaches information technology (IT) professionals how to provision and manage services in
Microsoft Azure. Students will learn how to implement infrastructure components such as virtual
networks, virtual machines (VMs), web and mobile apps, and storage in Azure. Students also will learn how
to plan for and manage Azure Active Directory (Azure AD), and configure Azure AD integration with the
on-premises Active Directory domains.
Audience
This course is intended for IT professionals who are familiar with managing on-premises IT deployments
that include Active Directory Domain Services (AD DS), virtualization technologies, and applications.
Students typically work for organizations that are planning to locate some or all of their infrastructure
services on Azure. This course also is intended for IT professionals who want to take the Microsoft
Certification Exam 70-533: Implementing Microsoft Azure Infrastructure Solutions.
Student Prerequisites
In addition to their professional experience, students who attend this training should have the following
technical knowledge:
• Completed the Microsoft Certified Systems Administrator (MCSA) certification in Windows Server
2012 or Windows Server 2016.
• Understanding of on-premises virtualization technologies, including: VMs, virtual networking, and

virtual hard disks.
• Understanding of network configuration, including: TCP/IP, Domain Name System (DNS), virtual
private networks (VPNs), firewalls, and encryption technologies.
• Understanding of websites, including: how to create, configure, monitor and deploy a website on
Internet Information Services (IIS).
• Understanding of Active Directory concepts, including: domains, forests, domain controllers,

replication, Kerberos protocol, and Lightweight Directory Access Protocol (LDAP).
• Understanding of resilience and disaster recovery, including backup and restore operations.
Course Objectives
After completing this course, students will be able to:
• Describe Azure architecture components, including infrastructure, tools, and portals.
• Implement and manage virtual networking within Azure and configure cross-premises connectivity.
• Plan and create Azure VMs.
• Configure, manage, and monitor Azure VMs to optimize availability and reliability.
• Implement Azure App Service.
• Plan and implement storage, backup, and recovery services.
• Implement container-based workloads in Azure.
• Deploy, configure, monitor, and diagnose cloud services.

xviii About This Course
• Implement Azure AD.
• Manage an Active Directory infrastructure in a hybrid environment.
• Automate operations in Azure by using Azure Automation runbooks.
Course Outline
The course outline is as follows:
• Module 1, “Introduction to Microsoft Azure” introduces cloud solutions in general and then focuses
on the services that Azure offers. The module goes on to describe the portals that you can use to
manage Azure subscriptions and services before introducing the Azure PowerShell modules and
Azure Command Line Interface (CLI) as scripting technologies for managing Azure. Finally, the
module provides explanations and guidance for the use of the classic and Azure Resource Manager
deployment models.
• Module 2, “Implementing and managing Azure networking” explains how to plan virtual networks in
Azure and implement and manage virtual networks. It also explains how to configure cross-premises
connectivity and connectivity between virtual networks in Azure. Additionally, it explains how to
configure an Azure virtual network and provides an overview of Azure classic networking.
• Module 3, “Implementing virtual machines” introduces the fundamentals of Azure VMs and discusses
the different ways in which you can deploy and manage them.
• Module 4, “Managing Azure VMs” explains how to configure and manage Azure VMs, including
configuring virtual machine disks and monitoring Azure VMs.
• Module 5, “Implementing Azure App Service” explains the different types of apps that you can create
by using the Azure App Service, and how you can select an App Service plan and deployment method
for apps in Azure. It also explains how to use Microsoft Visual Studio, File Transfer Protocol (FTP)
clients, and Azure PowerShell, and Azure CLI to deploy Azure web and mobile apps. Additionally, the
module explains how to configure web apps and use the Azure WebJobs feature to run custom tasks.
It also explains how to monitor the performance of web apps and create and configure mobile apps.
Lastly, this module explains how to use Azure Traffic Manager to distribute requests between two or
more app services.
• Module 6, “Planning and implementing storage, backup, and recovery services” explains how to plan
and implement storage, backup, and recovery services. It explains how to choose appropriate Azure
Storage options to address business needs and how to implement and manage Azure Storage. It also
explains how to improve web-application performance by implementing Azure Content Delivery
Networks (CDNs). Lastly, this module explains how to protect cloud-resident and on-premises
workloads by using Azure Backup and Azure Site Recovery.
• Module 7, “Implementing containers in Azure” explains how to implement containers in Azure. It

starts by introducing the concept of containers and presents different options for implementing
containers on Windows and Linux Azure VMs. Next, it explains container orchestration in the context
of Azure Container Service (ACS) and describes how to use ACS to deploy Docker Swarm, Kubernetes,
and DC/OS clusters.
• Module 8, “Implementing Azure Cloud Services” explains how to plan and deploy Azure Cloud
Services. It also explains how to manage and maintain Azure Cloud Services.
• Module 9, “Implementing Azure Active Directory” explains how to implement Azure AD. It explains
how to create and manage Azure AD tenants. It also explains how to configure single sign-on (SSO)
for cloud applications and resources, and implement Azure Role-Based Access Control (RBAC) for
cloud resources. Lastly, this module explains the functionality of Azure AD Premium, and how to
implement Azure Multi-Factor Authentication.
About This Course xix
• Module 10, “Managing an Active Directory infrastructure in a hybrid environment” explains how to
manage Active Directory in a hybrid environment. It explains how to extend an on-premises Active
Directory domain to Azure infrastructure as a service (IaaS) environments and synchronize user,
group, and computer accounts between on-premises AD DS and Azure AD. This module also explains
how to set up SSO by using federation and pass-through authentication between on-premises Active
Directory and Azure AD.
• Module 11, “Implementing Azure-based management and automation” explains how to implement
Azure-based management and automation. It explains how to implement Microsoft Operations
Management Suite (OMS) solutions and Azure Automation. This module also describes how to create
different types of Azure Automation runbooks and implement Azure Automation-based management
by using runbooks.
xx About This Course
Course Materials
Your kit includes several pieces, including the:
• Course Handbook: This is a succinct classroom learning guide that provides the critical technical
information in a crisp, tightly-focused format, which is essential for an effective in-class learning
experience. It includes the following sections:
o Lessons: These guide you through the learning objectives and provide the key points that are
critical to the success of the in-class learning experience.
o Labs: These provide a real-world, hands-on platform on which you can apply the knowledge and
skills that you have learned in the module.
o Module Reviews and Takeaways: These provide on-the-job reference material to boost
knowledge and skills retention.
o Lab Answer Keys: These provide step-by-step lab-solution guidance.
Additional Reading: Course companion content on the http://www.microsoft.com

/learning/en/us/companion-moc.aspx site: This is searchable, easy-to-browse digital content
with integrated premium online resources that supplement the Course Handbook.
• Modules: These include companion content for each lesson, including questions and answers,
detailed demonstration steps, and additional reading links. Additionally, they include Lab Review
questions and answers, and Module Reviews and Takeaways sections, which contain the review
questions and answers, best practices, common issues and troubleshooting tips with answers, and
real-world issues and scenarios with answers.
• Resources: These include well-categorized additional resources that give you immediate access to
the most current premium content on TechNet, MSDN, or Microsoft Press.
• Course evaluation: This is at the end of the course, and provides you with the opportunity to
complete an online evaluation that provides feedback on the course, training facility, and instructor.
o To provide additional comments or feedback on the course, send an email to

mcspprt@microsoft.com. To inquire about the Microsoft Certification Program, send an
email to mcphelp@microsoft.com.
About This Course xxi
Virtual Machine Environment

This section provides the information for setting up the classroom environment to support this course’s
business scenario.
Virtual Machine Configuration

• Student will be provided with an Azure Learning Pass before the course starts.
• Classroom PC (Hardware Level 7, dual monitors) with a student Hyper-V classroom image based on
Windows 10 Enterprise Anniversary Edition. The virtual machine includes the software and lab files
required to complete all the labs.
To prepare for each lab, students run provisioning scripts. The beginning of each lab lists the scripts that
students must run. Students will execute deprovisioning scripts at the end of each lab, to remove all
changes that they have made. In this way, scripts ensure that each lab does not depend on the students
correctly executing previous labs.
This course will be delivered worldwide, and instructors should be able to choose regions close to their
physical location. Two regions must be selected: an HQ Region and a Branch Region. Every provisioning
script must request, from the user, the regions in which to configure Azure objects. The lab instructions
use the HQ Region and Branch Region placeholders.
The following table shows the role of each virtual machine that this course uses.
Virtual machine Role
20533D-MIA-CL1 Windows 10 standalone client with the Microsoft Azure

management tools installed
MT17B-WS2016-NAT Internet gateway
Software Configuration
The following software is installed on each VM:
• Microsoft SQL Server 2016 SP1 Express
• SQL Server Management Studio
• Microsoft Visual Studio Community 2015Azure Cross Platform Command Line Tools
Course Files
The files associated with the labs in this course are located in the C:\Labfiles\LabXX folder on the student
computers.
Classroom Setup
Each classroom computer will have the same virtual machine with the same configuration.
xxii About This Course
Course Hardware Level

To ensure a satisfactory student experience, Microsoft Learning requires a minimum equipment
configuration for trainer and student computers in all Microsoft Certified Partner for Learning Solutions
(CPLS) classrooms in which Official Microsoft Learning Product courseware is taught.
• Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) processor
• Dual 120-gigabyte (GB) hard disks 7200 RM Serial ATA (SATA) or better*
• 16 GB of random access memory (RAM)
• DVD drive
• Network adapter
• Super VGA (SVGA) 17-inch monitor
• Microsoft mouse or compatible pointing device
• Sound card with amplified speakers
• Striped
Additionally, the instructor’s computer must be connected to a projection display device that supports
SVGA 1024×768 pixels, 16-bit colors.
1-1
Module 1
Introduction to Microsoft Azure
Contents:
Module Overview 1-1
Lesson 1: Cloud technology overview 1-2
Lesson 2: Overview of Azure 1-6
Lesson 3: Managing Azure with the Azure portal 1-22

Lesson 4: Managing Azure with Windows PowerShell 1-26
Lesson 5: Managing Azure with Azure CLI 1-33
Lesson 6: Overview of Azure deployment models 1-37
Lesson 7: Managing and monitoring Azure resources 1-51
Lab: Managing Microsoft Azure 1-55
Module Overview
Organizations are increasingly moving IT workloads to the cloud, so IT professionals must understand the
principles of cloud solutions. They must also learn how to deploy and manage cloud apps, services, and
infrastructure. IT professionals who are planning to use Microsoft Azure must learn about the services that
Azure provides and how to manage them.
This module introduces cloud solutions in general and then focuses on the services that Azure offers. The
module goes on to describe the portals that you can use to manage Azure subscriptions and services,
before introducing the Azure PowerShell modules and Azure Command-Line Interface (CLI) as scripting
technologies for managing Azure. Finally, the module explains the use of Azure Resource Manager and
presents an overview of Azure management services.
Objectives
After completing this module, you will be able to:
• Identify suitable apps for the cloud.
• Identify the services and capabilities that Azure provides.
• Use Azure portals to manage Azure services and subscriptions.
• Use Azure PowerShell to manage Azure services and subscriptions.
• Use Azure CLI to manage Azure services and subscriptions.
• Use Azure Resource Manager to manage Azure resources.
• Use Azure services to enhance management and monitoring of Azure.

1-2 Introduction to Microsoft Azure
Lesson 1
Cloud technology overview
Cloud computing plays an increasingly important role in IT infrastructure, and IT professionals need to be
aware of fundamental cloud principles and techniques. This lesson introduces the cloud and describes
considerations for implementing cloud-based infrastructure services.
Lesson Objectives
After completing this lesson, you will be able to:
• Prepare the Azure environment for the demonstrations and labs in this module.
• Describe the key principles of cloud computing.

• Identify common types of cloud services.
Demonstration: Preparing the lab environment for the remainder of this

module
Perform the tasks in this demonstration to prepare the lab environment. The environment will be
configured while you progress through this module.
Important: The scripts used in this course might delete objects that you have in your
subscription. Therefore, you should complete this course by using a new Azure subscription. You
should have received sign-up details and instructions for creating an Azure learning pass for this
reason. Alternatively, you can create a new Azure trial subscription. In both cases, use a new
Microsoft account that has not been associated with any other Azure subscription. This will
eliminate the possibility of any potential confusion when running setup scripts.
This course relies on custom Azure PowerShell modules, including Add-20533DEnvironment to prepare
the lab environment for demonstrations and labs, and Remove-20533DEnvironment to perform clean-
up tasks at the end of the module.
Introduction to cloud computing

Cloud computing, or the cloud, has become a
leading trend in IT. However, its definition is
ambiguous, and some of the terminology related
to it is confusing. Trying to define the cloud in
purely technological terms is difficult—it is best to
think of it an abstract concept that encapsulates
techniques used to provide computing services
from a pool of shared resources.
Implementing Microsoft Azure Infrastructure Solutions 1-3
Most cloud solutions use virtualization technology, which abstracts physical hardware as a layer of
virtualized resources for processing, memory, storage, and networking. Many cloud solutions add further
layers of abstraction to define specific services that you can provision and use.
As the National Institute of Standards and Technology has identified, cloud computing solutions exhibit
the following five characteristics, regardless of the specific technologies that organizations use to
implement them:
• On-demand self-service. Cloud services are generally provisioned as they are required and they need
minimal infrastructure configuration by the consumer. Therefore, cloud services users can quickly set
up the resources they want, typically without having to involve IT specialists.
• Broad network access. Consumers access cloud services over a network connection from different
locations, usually either a corporate network or the internet.
• Resource pooling. Cloud services use a pool of hardware resources that consumers share. A hardware
pool consists of hardware from multiple servers that are arranged as a single logical entity.
• Rapid elasticity. Cloud services scale dynamically to obtain additional resources from the pool as
workloads intensify, and they release resources automatically when no need for them exists.
• Measured service. Cloud services include metering capabilities, which allow you to track resource
usage by consumers. This facilitates the usage-based billing model, where service cost reflects
utilization levels.
Advantages of cloud computing

Cloud computing has several advantages over traditional, datacenter-based computing, including the
following:
• A managed datacenter. With cloud computing, your service provider can manage your datacenter.
This obviates the need for you to manage your own IT infrastructure. With cloud computing, you can
also access computing services irrespective of your location and the hardware that you use to access
those services. Although the datacenter remains a key element in cloud computing, the emphasis is
on virtualization technologies that focus on delivering apps rather than on infrastructure.
• Reduced or even eliminate capital expenditure. With cloud providers owning and managing
datacenters, organizations no longer require their own infrastructure for deploying and managing
virtualized workloads.
• Lower operational costs. Cloud computing provides pooled resources, elasticity, and virtualization
technology. These factors help you to alleviate issues such as low system use, inconsistent availability,
and high operational costs. It is important to remember that with cloud computing, you pay for only
the services that you use; this can mean substantial savings on operational costs for most
organizations.
• Server consolidation. You can consolidate servers across the datacenter by using the cloud computing
model, because it can host multiple virtual machines on a virtualization host.
• Better flexibility and speed. You can address changing business needs efficiently by rapidly scaling
your workloads, both horizontally and vertically, and deploying new solutions without infrastructure
constraints.
Public, private, and hybrid clouds

Cloud computing uses three main deployment models:
• Public cloud. Public clouds are infrastructure, platform, or application services that a cloud service
provider delivers for access and consumption by multiple organizations. With public cloud services,
the organization that signs up for the service does not have the management overhead that the
private cloud model requires. However, this also means that the organization has less control of the
infrastructure and services, because the service provider manages them for the organization. In
addition, the public cloud hosts the infrastructure and services for multiple organizations
(multitenant), so you should consider the potential data sovereignty implications of this model.
• Private cloud. Individual organizations privately own and manage private clouds. Private clouds offer
benefits similar to those of public clouds, but are designed and security-enhanced for a single
organization’s use. The organization manages and maintains the infrastructure for the private cloud in
its datacenter. One of the key benefits of this approach is that the organization has complete control
over the cloud infrastructure and services that it provides. However, this model requires additional
management and increases costs for the organization.
• Hybrid cloud. In a hybrid cloud, a technology binds two separate clouds (public and private) together
for the specific purpose of obtaining resources from both. You decide which elements of your services
and infrastructure to host privately and which to host in the public cloud.
Many organizations use a hybrid model when extending to the cloud; that is, when they begin to shift
some elements of their apps and infrastructure to the cloud. Sometimes, an organization shifts an app
and its supporting infrastructure to the cloud while maintaining the underlying database within its
own infrastructure. This approach might help keep that database more secure.
Types of cloud services

Cloud services generally fall into one of the
following three categories:
• Software as a service (SaaS)
• Platform as a service (PaaS)
• Infrastructure as a service (IaaS)
SaaS
SaaS offerings consist of fully formed software
apps that are delivered as cloud-based services.
Users can subscribe to the service and use the
app, normally through a web browser or by
installing a client-side app. Examples of Microsoft SaaS services include Microsoft Office 365, Skype for
Business, and Microsoft Dynamics CRM Online. The primary advantage of SaaS services is that they enable
users to access apps without having to install and maintain them. Typically, users do not have to worry
about updating apps and maintaining compliance, because the service provider handles tasks such as
these.
PaaS
PaaS offerings consist of cloud-based services that provide resources on which developers can build their
own solutions. Typically, PaaS encapsulates fundamental operating system capabilities, including storage
and compute, in addition to functional services for custom apps. Usually, PaaS offerings provide
application programming interfaces (APIs), in addition to configuration and management user interfaces.
With PaaS, developers and organizations can create highly scalable custom apps without having to
provision and maintain hardware and operating system resources. Examples of PaaS services include
Azure App Service, which provides a runtime environment for a web app or mobile app that your
development team creates.
IaaS
IaaS offerings provide virtualized server and network infrastructure components that can be easily
provisioned and decommissioned as required. Typically, you manage IaaS facilities as you would manage
on-premises infrastructures. IaaS facilities provide an easy migration path for moving existing apps to the
cloud.
Note that an infrastructure service might be a single IT resource—such as a virtual server with a default
installation of Windows Server 2016 and Microsoft SQL Server 2016, or a Linux server with MySQL Server
installed to provide database services—or it might be a complete infrastructure environment for a specific
app or business process. For example, a retail organization might empower departments to provision their
own database servers to use as data stores for custom apps. Alternatively, the organization might define a
set of virtual machine and network templates that can be provisioned as a single unit. These templates
would implement a complete, preconfigured infrastructure solution for a branch or store, including all the
required apps and settings.
Other “as a service” offerings

As cloud services continue to evolve, other IT functions are being presented as packaged cloud services.
Some examples of these include:
• Identity as a service (IDaaS). IDaaS provides identity management services in a packaged product,
usually for resale to customers. For example, in Azure, Azure Active Directory (Azure AD) provides
identity and access management that integrate with Azure services and apps, whereas Azure AD
Business-to-Consumer (B2C) provides consumer identity management.
• Disaster recovery as a service (DRaaS). DRaaS provides cloud-based backup and recovery services that
are consumable on a pay-per-use model, highly available, and scalable to meet demand. The most
prominent example of this type of service in Azure is Azure Site Recovery.
Question: What advantages does a hybrid cloud model present to an organization that is
new to Azure?
Lesson 2
Overview of Azure
Azure is a cloud offering from Microsoft that individuals and organizations can use to create, deploy, and
operate cloud-based apps and infrastructure services. This lesson provides an overview of Azure and
describes the datacenter infrastructure that supports it, before discussing the services, resources, and tools
that are available in Azure.
Lesson Objectives
• Describe the key characteristics of Azure datacenters.
• Identify and describe the available Azure services.
• Explain the compute hosting options that Azure provides.
• Explain the Azure service model.

• Describe Azure resources.
• Use Azure resources.
• Identify Azure management tools.
Understanding Azure datacenters

Datacenters managed by Microsoft host Azure
services throughout the world. Whenever you
create a new Azure service, you must select an
Azure region to determine the datacenter where
the service will run. When you select an Azure
region, you should consider the location of the
service’s users and place the service as close to
them as possible. Some services enable you to
serve content from more than one Azure region.
In this way, you can serve content to a global
audience while helping to ensure that a local
response gives them the highest possible
performance. At the time of authoring this course, these datacenters, including the newly announced
ones, are in the following geographic areas:
• Americas
o East US
o East US 2
o Central US
o North Central US
o South Central US
o West Central US
o West US
o West US 2
o US Gov Virginia
o US Gov Iowa
o US Gov Arizona
o US Gov Texas
o US DoD East
o US DoD Central
o Canada East
o Canada Central
o Brazil South
• Europe
o North Europe
o West Europe
o Germany Central
o Germany Northeast
o UK South
o UK West
o France Central
o France South
• Asia Pacific
o Southeast Asia
o East Asia
o Australia East
o Australia Southeast
o China East
o China North
o Central India
o South India
o West India
o Japan East
o Japan West
o Korea Central
o Korea South
• Africa
o South Africa West
o South Africa North
Datacenter placement follows the principle of pairing, by which each datacenter has its counterpart in the
same geographical area. The exception is the Brazil South region, which pairs with the South Central US
region. The primary purpose of this pairing arrangement is to allow you to design and implement cloud-
based disaster-recovery solutions, while retaining all services in the same geographical location.
Governments and regional organizations often require this to comply with their regulatory, compliance,
and data-sovereignty rules. Additionally, Azure datacenter disaster-recovery and maintenance procedures
include this pairing to minimize the potential impact of an incident that affects multiple regions. As you
decide where to deploy your Azure services, you should consider datacenter pairing.
The basis of these datacenters is an evolving range of architectures that span several generations. The
latest generation of datacenters is based on a fully modular design that includes the following features:
• Microsoft packages clusters of servers into preassembled units enclosed in shipping containers,
enabling clusters that contain thousands of servers to be rapidly provisioned and swapped out.
• The datacenters include uninterruptable power supplies and alternate power supplies for all
components, in addition to backup power that can keep the datacenter running in the event of a
localized disaster.
• Redundant high-speed networks connect the clusters within datacenters.
• High-speed optical networks connect the datacenters to each another and to the internet.
• The data within a single datacenter can be replicated to three redundant storage clusters for high
availability and between pairs of datacenters in the same geographic region for disaster recovery.
• The physical and network security for Azure datacenters meets a wide range of industry and
government standards.
The datacenters minimize power and water usage for maximum efficiency. These reductions apply to
servers and networking hardware, cooling equipment, and other infrastructure facilities.
The servers in each datacenter are provisioned in clusters, and each cluster includes multiple racks of
servers. A distributed management service built into the platform handles provisioning, dynamic scaling,
and hardware fault management for the virtual servers that host cloud services on the physical servers in
the clusters.
Additional Reading: For more information, refer to: “Azure Regions” at:
http://aka.ms/Ym4ryz
Understanding the Azure service model

Multitenancy within a scalable and highly
available cloud-based infrastructure forms the
basis of the Azure service model. Two factors
define a subscriber’s access to Access services: a
subscription model that dictates the level of
access a subscriber must have, and the billing
structure in place for the subscriber. Azure services
are primarily pay-per-use, with subscribers paying
for the cloud resources that the different services
and functionalities that they are using consume.
Accounts and subscriptions

An Azure account represents a collection of one
or more subscriptions. An Azure account determines how and to whom Azure reports subscription usage.
A subscription constitutes the administrative and billing boundary within an account, which means that:
• From the management standpoint, you can delegate privileges up to the subscription level.
• From the billing standpoint, the cost of individual Azure services rolls up to the subscription level.
Each subscription also is subject to quotas, which determine the maximum quantity of services and
resources that can reside in the same subscription. These limits typically apply on per-subscription and
per-region levels.
Additional Reading: For a comprehensive and up-to-date listing of Azure subscription

limits and quotas, refer to: “Azure subscription and service limits, quotas, and constraints” at:
https://aka.ms/lxo0an
To implement Azure services, you must have a subscription. You can sign up for a subscription as an
individual or as an organization. The sign-up process creates an Azure account, if you do not have one,
and it creates a subscription within that account. If you have an existing account, you can add multiple
subscriptions to it.
Signing in to Azure
To manage Azure resources within a subscription, you first need to authenticate successfully. The most
common authentication methods involve using either of the following types of accounts:
• A Microsoft Account
• A work or school account (formerly referred to as an organizational account)
Work or school accounts differ from Microsoft accounts because they are defined in Azure AD. Every
Azure subscription is associated with an Azure AD tenant that can host these accounts.
Administrative roles and role-based access control (RBAC)

Azure provides three built-in account and subscription-level administrative roles:
1. Account Administrator. There is one Account Administrator for each Azure account. The Account
Administrator can access the web portal referred to as the Azure Account Center. This enables the
Account Administrator to perform several billing and administrative tasks, such as creating
subscriptions, canceling subscriptions, changing the billing method for a subscription, or changing
the designated, subscription-level administrative account known as Service Administrator.
Note: Only the person with the Account Administrator role can access the corresponding
account in the Account Center. However, the Account Administrator does not have access to
resources in any subscriptions in the account.
Additional Reading: The Account Center is accessible from http://aka.ms/Cbnltm
2. Service Administrator. There is one Service Administrator for each Azure subscription. Initially, the
Service Administrator is the only account that can create and manage resources within the
subscription. By default, the user account associated with this role is the same as the Account
Administrator if you create a new subscription in a new account by using a Microsoft account.
3. Co-Administrator. The Service Administrator can create up to 200 Co-Administrators for each Azure
subscription. Co-Administrators have full permissions to create and manage Azure resources in the
same subscription, but they cannot revoke Service Administrator privileges or grant Co-Administrator
privileges to others. They also cannot change the association of the current subscription to its Azure
AD tenant. Such changes require Service Administrator privileges.
Note: You must be either the Service Administrator or a Co-Administrator to access the
Azure classic portal.
To comply with the principle of least privilege, you should avoid relying on Co-Administrators for
delegation of access to your subscription. Instead, you should grant a minimum required set of
permissions by using the role-based access control (RBAC) mechanism.
RBAC allows you to provide granular access to perform specific actions on Azure resources, down to an
individual-resource level. You can specify which actions to perform by using either a predefined or a
custom role. Once you have decided which role to use, you assign it to an Azure AD object representing
the user, group, or application that should be able to carry out the role’s associated actions.
Pricing and billing

There are several basic pricing and billing options for Azure:
• Pay-As-You-Go. Choose this option if you want a flexible pricing plan. You pay only for the services
that you use. You can cancel this subscription at any time. You can make payments by using credit or
debit cards, or via invoicing, if approved.
Additional Reading: For more information, refer to: “Pay-As-You-Go” at:

http://aka.ms/Uis9fx
• Buying from a Microsoft reseller. Select this option to work with the same resellers from whom you
currently purchase Microsoft software under the Microsoft Open License program. Start by
purchasing Azure in Open credits. You can then use these credits to activate your subscription and
apply them toward any Azure service that is eligible for monetary commitments when purchased
online. Services that do not belong to this category include Azure Rights Management Services and
Azure AD Premium.
Additional Reading: For more information, refer to: “Get Started with Azure in Open
Licensing” at: http://aka.ms/Mq0oy5
• Enterprise Agreement. This option is best suited to large organizations that sign an Enterprise
Agreement and make an upfront commitment to purchase Azure services. Customers who select this
option rely on the Azure Enterprise Portal to administer their subscription. Microsoft bills these
customers annually, based on their service usage. This option makes it easier to accommodate
unplanned growth.
Additional Reading: For more information, refer to: “Licensing Azure for the Enterprise” at:
http://aka.ms/Br93cj
• Azure Compute Pre-Purchase Plan. This plan involves an up-front purchase of 12 months of an Azure
virtual machine (VM) instance, including instance family, size, region, and operating system. It offers a
significant discount of up to 63 percent compared with standard rates. It is available for Enterprise
Agreement customers only.
Additional Reading: For more information about Microsoft Azure FAQs, refer to: “Azure for
Microsoft software FAQ” at: https://aka.ms/vkz5xg
• Azure Hybrid Use benefit. Customers with Software Assurance qualify for discounts on Windows
Server virtual-machine instances that they migrate from their on-premises environments.
Additional Reading: For more information about Microsoft Azure pricing, refer to: “Azure
pricing” at: https://aka.ms/pc0s73
Microsoft also provides several benefits to members of specific programs, such as Microsoft Developers
Network (MSDN), the Microsoft Partner network, and BizSpark:
• MSDN. Members receive monthly credits toward their Azure subscription for services that they use for
development purposes.
• Partner. Partners receive monthly credits toward their Azure subscription and receive access to
resources to help expand their cloud practice.
• BizSpark. Members receive monthly credits toward their Azure subscription.
Additional Reading: For more information about members’ benefits, refer to: “Member
Offers” at: http://aka.ms/Nse6tf
Support plans
You can also purchase support plans from Microsoft that provide varying levels of support for your Azure
environment. You can choose from one of four support plans:
• Developer. The Developer plan is designed for test or nonproduction environments. It includes
technical support for Azure during business hours with an initial response time of less than eight
hours.
• Standard. The Standard plan offers the same features as the Developer plan, and the initial response
time is less than two hours.
• Professional Direct. This plan is designed for organizations that depend on Azure for business-critical
apps or services. It includes the same features as the Standard plan in addition to basic advisory
services, pooled support account management, escalation management, and an initial response time
of less than one hour.
• Premier. This is the highest level of support, and it extends to all Microsoft products, including Azure.
With Premier, you receive customer-specific advisory services, a dedicated support account manager
and a response time of less than 15 minutes, in addition to all the Professional Direct features.
Additional Reading: For more information, refer to: “Azure support plans” at:
http://aka.ms/N613e7
In general, cloud technologies enable you to minimize or eliminate capital expenditures. They can also
help lower your operational costs. Azure is no exception, and its pricing model reflects this.
Azure resource pricing

Azure compute-related charges are usually calculated on a per-minute basis, and they reflect actual
usage. For example, when you deploy Azure virtual machines, the corresponding cost reflects the time
during which they are online. These charges apply whenever a virtual machine is running, but terminate as
soon as you stop it and let the platform deallocate its compute resources. Another, smaller part of virtual-
machine cost reflects the usage of Azure Storage for virtual machine disk files. Charges for storage
allocated to the virtual machine disk files apply regardless of the state of the virtual machine.
Microsoft offers most Azure services in several pricing tiers, to accommodate different customer needs
and facilitate vertical scaling. By implementing vertical scaling, customers can increase or decrease
processing power and service capacity. They can also implement horizontal scaling to meet fluctuating
demand. In either case, customers can minimize usage charges by adjusting service levels dynamically.
Pricing also might vary depending on the region in which your services will be hosted. In addition, for
licensed products, pricing depends on the licensing model that is applicable when you implement them in
a public cloud.
Additional Reading: For more information, refer to: “Azure pricing” at: http://aka.ms/Svvfpj
To estimate the cost of Azure services that you plan to provision, you can use the Azure pricing calculator.
This web-based tool allows you to pick several types of Azure services, specify their total projected usage
(in hours, weeks, or months), pricing tier, target Azure region, and support options. Then, based on this
information, you can determine the overall cost of a solution that meets your needs.
Additional Reading: Azure pricing calculator is available at: https://aka.ms/lyvi3b

Locating Azure-related information and resources

Microsoft provides several resources that facilitate
implementation and management of your Azure
environment:
• Azure Marketplace. The Azure Marketplace

contains thousands of certified, open-source,
and community-provided resources. You can
use it to deploy preconfigured virtual
machines, download developer tools, and
provision a wide variety of apps and APIs.
• GitHub. GitHub contains APIs, software
development kits (SDKs), and open-source
projects. This includes content that Microsoft
and the Azure community have curated. Developers can leverage GitHub resources in their projects
to save time and effort and upload their own code for others to reuse.
• Azure Trust Center. The Azure Trust Center provides information and guidance around security,
privacy, and compliance in Azure.
• Microsoft Docs. The Microsoft-managed website hosts the most comprehensive and continuously
updated repository of documentation describing Microsoft technologies, including Azure.
Demonstration: Locating Azure-related resources

In this demonstration, you will see how to:
• Use the Azure Marketplace.
• Use GitHub.
• Use the Azure Trust Center.
Understanding Azure services

Azure provides a wide range of cloud-based
services that you can use to design and
implement your customized cloud solutions and
infrastructure. Those services include:
• Compute, which provides the following
options:
o Virtual Machines. Create Windows and

Linux virtual machines from predefined
templates, or deploy your own custom
server images in the cloud.
o Azure Virtual Machine Scale Sets.

Provision highly available and automatically scalable groups of Windows and Linux virtual
machines.
o Azure Cloud Services. Define multitier PaaS cloud services that you can deploy and manage on
Azure.
o Azure Batch. Run high-volume, large-scale parallel and high-performance computing apps on a
scaled and managed set of virtual machines.
o Azure Service Fabric. Build and manage distributed applications by using small, specialized
software components, or microservices.
o Azure Container Service. Deploy and manage clusters of containers.
o Azure Functions. Process events with serverless code.

• Web & Mobile, which provides the following options:
o Azure App Service. Integrate and manage web and mobile app solutions by using:
 Logic Apps. Automate running business processes and workflows.
 Web Apps. Deploy web apps to the cloud.
 Mobile Apps. Develop and provision highly scalable, globally available mobile apps.
 API Apps. Provide building blocks for integrating and building new apps.
o Azure Notification Hubs. Implement push notifications for apps and services.
• Data & Storage, which provides the following options:
o Azure CosmosDB. Implement a globally distributed, schema-agnostic, multimodel data store.

o Azure SQL Database. Implement relational databases for your apps without having to provision
and maintain a database server.
o Azure SQL Data Warehouse. Provision a data warehouse as a service.
o Azure Redis Cache. Implement high-performance caching solutions for your apps.
o Storage. Store data in files, binary large objects (BLOBs), tables, and queues.
o Microsoft Azure StorSimple. Provision a multitier storage solution that provides cloud hosting for
on-premises data.
o Azure Search. Provide a fully managed search service.
o SQL Data Warehouse. Store and access large-scale, distributed data.
• Intelligence, which provides the following options:
o Cortana Intelligence. Implement big data and advanced analytics.
o Microsoft Cognitive Services. Incorporate smart API capabilities into your apps.
• Analytics, which provides the following options:

o Azure Bot Service. Run intelligent, autoscaling, serverless bot service.
o Azure Data Lake Analytics. Run large-scale data-analysis jobs.
o Data Lake Store. Create hyperscale repositories for big data analytics.
o HDInsight. Provision Apache Hadoop clusters in the cloud.
o Azure Machine Learning. Run predictive analytics and forecasting based on existing data sets.
o Azure Stream Analytics. Set up real-time data analysis from a variety of sources.
o Azure Data Factory. Create data pipelines by using data storage, data-processing services, and
data movement.
o Azure Data Catalog. Implement the registration and discovery of enterprise data sources.
• Internet of Things (IoT), which provides the following options:
o Azure IoT Suite and Azure IoT Hub. Process massive amounts of telemetry data that connected
devices and apps generate.
o Azure Event Hubs. Collect telemetry data from connected devices and apps.
o Azure Stream Analytics. Process real-time data from connected devices and apps.
• Networking, which provides the following options:
o Azure Virtual Network. Connect and segment the cloud infrastructure components.
o Azure ExpressRoute. Extend your on-premises network to Azure and Microsoft cloud services
through a dedicated private connection.
o Azure Traffic Manager. Configure global load balancing, based on Domain Name System (DNS).
o Azure Load Balancer. Implement an automatically scalable transport-layer and network-layer load
balancing.
o Azure Application Gateway. Build application-layer load balancing, with support for such features
as Secure Sockets Layer (SSL) offloading, cookie affinity, and URL-based routing.
o Azure DNS. Host and manage your DNS domains and records for use with Azure services.
o Azure VPN Gateway. Create network connections between Azure and on-premises networks over
the internet.
• Media & Azure Content Delivery Network, which provides the following options:
o Azure Media Services. Deliver multimedia content, such as video and audio.
o Azure Content Delivery Network. Speed up delivery of web content to users throughout the
world.
• Hybrid Integration, which provides the following options:
o Azure BizTalk Services. Build integrated business-orchestration solutions that integrate enterprise
apps with cloud services.
o Azure Service Bus. Connect apps across on-premises and cloud environments.
o Azure Backup. Provide retention and recovery by backing up your on-premises and cloud-based
Windows and Linux systems to Azure.
o Azure Site Recovery. Design and implement disaster-recovery solutions for failover to a
secondary on-premises datacenter or to Azure.
• Identity and Access Management, which provides the following options:
o Azure Active Directory. Integrate your on-premises Active Directory Domain Services (AD DS)
with the cloud-based Identity and Access Management solution, and provide single sign-on
(SSO) capabilities for cloud-based and on-premises applications and services.
o Azure Multi-Factor Authentication. Implement additional security measures in your apps to verify
user identity.
o Azure Active Directory Domain Services (Azure AD DS). Deploy managed domain controllers in
the cloud.
o Azure Active Directory B2C. Provide scalable identity and access management solutions for
customer-facing apps.
o Azure Key Vault. Store and manage cryptographic artifacts, such as keys and passwords.
• Developer Services, which provides the following options:
o Azure Application Insights. Provide cloud-based analytics and diagnostics of app usage.
o Azure DevTest Labs. Create, monitor, and manage virtual machines in a dedicated test
environment.
• Management, which provides the following options:
o Azure Automation. Automate long-running, frequently repeating, and time-consuming tasks.
o Azure Operational Insights. Build operational intelligence by using data collected from your cloud
and on-premises environments.
o Azure Security Center. Monitor and manage control of and access to Azure resources.
o Azure Network Watcher. Monitor and diagnose networking functionality and performance.
Note: Microsoft is continually improving Azure and adding new services on a regular basis.
Additional Reading: For more information on newly announced Azure geographies and
regions, including planned regional datacenter deployments, refer to: “Azure Regions” at:
http://aka.ms/Tzcz4g
Understanding Azure compute-hosting options

Azure includes several options to provide apps
and compute-based services from the cloud.
These options include:
• Azure App Service and App Service
Environment
• Cloud Services
• Service Fabric
• Virtual Machines
• Containers
• Container Service
• Functions
App Service and App Service Environment

You can use App Service to quickly provision and create web, mobile, logic, or API apps in Azure. App
Service is a PaaS solution, so the platform automatically provisions and manages the underlying
infrastructure and operating system. You can create App Service solutions by using Microsoft ASP.NET,
PHP, Node.js, Python, and, with Azure Web App on Linux, Ruby. Web apps that use App Service can
integrate with other Azure services, including SQL Database, Service Bus, Storage, and Azure Active
Directory. By using multiple copies of an app hosted on separate virtual machines, you can rapidly
provision and scale App Service–based apps. You can publish code for App Service apps by using the
Microsoft Web Deployment Tool (Web Deploy), Microsoft Visual Studio, Git, GitHub, File Transfer Protocol
(FTP), Bitbucket, CodePlex, Mercurial, Dropbox, Microsoft Team Foundation Server, and the cloud-based
Visual Studio Team Services. For the most demanding workloads, you can use App Service Environment,
which allows you to create a multitier, dedicated environment capable of hosting web apps, mobile apps,
and logic apps. App Service Environment delivers an extra performance advantage by supporting direct
virtual network connectivity.
Cloud Services
Azure Cloud Services offers multitier scalability for Windows-based web apps and greater control over the
hosting environment. When using Azure Cloud Services, you can connect to your virtual machines and
interactively perform management tasks such as registry modifications and Windows Installer–based
installations. You typically use Azure Cloud Services to deploy more complex solutions than an App
Service can provide. Azure Cloud Services is best suited for:
• Multitiered web apps.

• Web apps that require a highly scalable, high-performance environment.
• Web apps that have additional application dependencies or require minor operating system
modifications.
Virtual Machines
Of the available compute options, Azure Virtual Machines provides the greatest flexibility and control. As
an IaaS solution, Azure Virtual Machines operates like Microsoft Hyper-V virtual machines on Windows
Server 2016. You have complete control over the virtual machine at the operating system level, but, as a
result, you are also responsible for maintaining that operating system, including installation of updates.
Unlike with Web Apps or Cloud Services, you are not limited to the operating systems available in Azure
Marketplace, but can also use custom operating system images uploaded from your on-premises
virtualization infrastructure. Virtual Machines is best suited for:
• Highly customized apps that have complex infrastructure or operating system requirements.
• Hosting Windows Server or Linux apps and infrastructure services, such as AD DS, DNS, or a database
management system (DBMS).
Service Fabric
Service Fabric is a cloud-based platform for developing, provisioning, and managing distributed, highly
scalable, and highly available services and applications. Its unique approach to service and application
architecture involves dividing their functionality into individual components called microservices. Common
examples of such microservices include shopping carts or user profiles of commercial websites and
queues, gateways, and caches that provide infrastructure services. Multiple instances of these
microservices run concurrently on a cluster of virtual machines.
This is similar to the multitier architecture of Cloud Services, which supports independent scaling of web
and worker tiers. However, Service Fabric operates on a much more granular level, as the term
microservices suggests. This allows more efficient resource utilization while scaling to potentially
thousands of virtual machines. Additionally, it allows developers to introduce gradual changes in the code
of individual application components without having to upgrade the entire application.
Another feature that distinguishes Service Fabric from traditional PaaS services is support for both
stateless and stateful components. Cloud Services are stateless by design. To save the state information,
they must rely on other Azure services, such as Storage or SQL Database. Service Fabric, on the other
hand, offers built-in support for maintaining state information. This minimizes or even eliminates the need
for back-end storage. It also decreases the latency when accessing application data.
Containers
Containers are the next stage in virtualizing computing resources. Virtualization reduced the constraints
that physical hardware imposes. It enabled running multiple isolated instances of operating systems
concurrently on the same physical hardware. Container-based virtualization virtualizes the operating
system, allowing you to run multiple applications within the same operating system instance while
maintaining isolation between them. Containers within a virtual machine provide functionality similar to
that of virtual machines on a physical server. However, there are some important differences between
virtual machines and containers, as listed in the following table.
Feature Virtual machines Containers
Isolation Built into the hypervisor. Relies on operating system support.

mechanism
Required amount Includes operating system and Includes requirements for the containerized
of memory app requirements. apps only.
Startup time Includes operating system boot Includes only start of apps and app
and start of services, apps, and dependencies. The operating system is
app dependencies. already running.
Portability Portable, but the image is larger More portable because the image includes
because it includes the operating only apps and their dependencies.
system.
Image automation Depends on the operating Based on the container registry.

system and apps.
Compared with virtual machines, containers offer several benefits, including:
• Increased speed for developing and sharing application code.

• An improved lifecycle for testing applications.
• An improved deployment process for applications.
• An increase in the density of your workloads, resulting in improved resource utilization.

The most popular containerization technology, at the time of writing this course, is available from Docker.
Docker uses Linux built-in support for containers. Windows Server 2016 includes support for containers
that delivers equivalent functionality.
Container Service
Container Service allows you to administer clusters of multiple Docker hosts running containerized apps.
Container Service manages the provisioning of cloud infrastructure components, including Azure virtual
machines and virtual machine scale sets, Azure Storage, virtual networks, and load balancers. Additionally,
it enables you to manage and scale containerized apps to tens of thousands of containers via integration
with the following orchestration engines:
• The Mesosphere Datacenter Operating System (DC/OS). A distributed operating system from the
Apache Software Foundation.
• Docker Swarm. A clustering software from Docker.

• Kubernetes. An open-source orchestration solution.
Based on this integration, you can manage Container Service clusters by relying on the same tools you use
to manage your existing containerized workflows.
Functions
Functions are a relatively recent addition to the arsenal of compute options in Azure. They provide the
optimal method of running custom code in the cloud by eliminating any infrastructure considerations,
while minimizing the corresponding cost. To implement functions, customers must provide their code
written in C#, F#, Node.js, Python, or PHP and specify a trigger that will initiate code execution. The Azure
platform handles the provisioning and scaling of underlying compute resources, when necessary. The
charges reflect only the time during which the code is running.
Functions support integration with several Azure and non-Microsoft services, including Storage, Mobile
Apps, Notification Hubs, Event Hubs, and cloud-based and on-premises resident instances of Service Bus.
These services can serve as triggers and provide input or output for functions.
Azure deployment models

Azure supports two deployment models–Azure
Resource Manager and classic. The deployment
model you choose determines how you provision
and manage Azure resources. It also affects the
properties and methods that these resources
support and the actions that you can apply to
them.
Until recently, the classic (or Service Management,

as it was originally called) deployment model was
the primary method for provisioning Azure
services. The model had a corresponding API,
which was available not only via programming
means but also through scripting and a web-based portal, currently referred to as the Azure classic portal.
As Microsoft cloud technologies evolved and matured, the original deployment model required a major
redesign. Its successor, Azure Resource Manager, introduced an innovative approach to administering
Azure services, focusing on the concepts of resources and resource groups. Resources represented
individual building blocks of Azure-based solutions, and resource groups provided a way to group these
resources into logical containers.
Azure Resource Manager has its own API, which is available through programming and scripting methods.
Microsoft also developed a new web-based portal, the Azure portal, which provides access to both Azure
Resource Manager and classic resources.
Note: You will learn more about Azure Resource Manager later in this module.
Azure management tools

You can use several techniques to manage the
Azure environment. While using programming
methods or calling REST API offers the most
functionality and flexibility, both approaches
require development skills. Fortunately, there are
simpler ways to accomplish the same objective,
which include graphical browser–based consoles,
command shells, and plug-ins. The following list
summarizes the available choices:
• The Azure portal accessible from

https://aka.ms/hi4myh. This is the current
version of the portal. You can use it to
administer Azure from most web browsers.
• The Azure classic portal accessible from https://aka.ms/r6hw9m. This is a legacy portal that supports
only classic resources.
• Azure PowerShell. You can use Windows PowerShell and the associated open-source Azure
PowerShell modules to manage your Azure environment. All versions of the Azure PowerShell
modules are available from GitHub for Windows, Linux, and Mac OS platforms.
• Azure CLI. The Azure Command-Line Interface (CLI) provides a set of open-source, cross-platform
commands for working with the Azure platform. All versions of the Azure CLI are available from
GitHub for Windows, Linux, and Mac OS platforms.
• Azure Cloud Shell. Azure Cloud Shell offers a command prompt window accessible directly from the
Azure portal, from which you can run Azure CLI commands.
Note: At the time of authoring this course, Azure Cloud Shell is in preview. It provides the
ability to run Linux shell interpreters, Azure CLI, and several popular Azure command line utilities.
Microsoft will likely extend its support to include Windows PowerShell.
• Visual Studio. You can use Azure SDK to facilitate management of Azure resources from the Visual
Studio integrated development environment (IDE). Azure Tools, which are part of Azure SDK, provide
an extension to the Server Explorer interface within Visual Studio, allowing you to work with Azure
resources without relying on programming methods.
Check Your Knowledge

Question
Which of the following services does Azure not offer directly?
Select the correct answer.
Virtual Machines
Web Apps
Storage Spaces
Container Services
DNS
Lesson 3
Managing Azure with the Azure portal
Azure provides web-based portals that allow you to provision and manage Azure resources. The portals
serve as the initial and the most popular working environment for most Azure customers. Being familiar
with their navigational features and the functionality they support will benefit your productivity and
simplify your administrative tasks.
Lesson Objectives
• Explain the Azure portal.
• Explain the Azure classic portal.
• Describe how to manage subscriptions with the Azure portal and the Azure Account Center.
• Use the Azure portals to manage Azure.
Using the Azure portal

The Azure portal, at https://aka.ms/hi4myh, is the
current portal for browser-based administration in
Azure. The portal offers an interface that simplifies
administrative tasks in Azure.
Portal elements and concepts

The Azure portal graphical interface contains the
following elements:
• Dashboard. The dashboard is a customizable

webpage that is the starting point of your
interaction with the Azure environment. You
can customize it by populating it with
resizable tiles that represent shortcuts to Azure resources and other items accessible via the portal. By
default, the dashboard includes several precreated tiles, including a global Azure service health tile, a
tile providing a shortcut to a list of all provisioned resources, and the Marketplace and Help +
support tiles. You can create multiple dashboards, switching between them based on your
preferences, and sharing them with others.
• Blades. Blades are scrollable panes in which you can view and configure details of a selected item. As
you select items in the current blade, new blades open on the right side of it, automatically scrolling
your current view horizontally in the same direction. You can maximize and minimize blades to
optimize screen space and simplify navigation.
• Hub menu. The Hub menu is a customizable, vertical bar on the left side of the page. At a minimum,
it contains the New and More services entries. The New entry serves as an entry point for creating
new services in your Azure environment. Service provisioning occurs asynchronously. You can monitor
the provisioning status by clicking the notification (bell) icon in the upper part of the portal page. The
More services entry allows you to explore existing services based on the service type or their names.
Other navigational features that enhance user experience include the:
• Microsoft Azure label in the upper-left corner, which displays the dashboard.
• Menu button underneath the Microsoft Azure label, which controls the hub menu’s size.
• Breadcrumb bar on the upper left side of the portal, which allows you to return to any open blades
without having to scroll horizontally.
• Search resources text box in the toolbar at the top of the portal interface, which includes a listing of
recently accessed resources, in addition to providing search capabilities.
• Support for keyboard shortcuts, a list of which you can display by accessing the Help drop-down
menu in the upper-right corner of the portal.
The Azure portal supports deployment and management of both Azure Resource Manager and classic
resources. You can easily distinguish between them since the portal includes the word “classic” in the
interface elements that reference classic resources. For example, the Hub menu contains both Virtual
machines and Virtual machines (classic) entries.
Using the Azure classic portal

The Azure classic portal is the original graphical
interface for provisioning and managing Azure
services. It is implemented as a web app at
https://aka.ms/r6hw9m.
The Azure classic portal does not offer any

customization. Instead, it presents a separate page
for each Azure classic service type. The portal also
includes an ALL ITEMS page, where you can view
all the provisioned classic services in your
subscriptions, and a SETTINGS page, where you
can configure subscription-wide settings.
Provisioning services
You can provision a new instance of a service by clicking the NEW option appearing at the bottom of the
portal, referred to as the command bar. Most services provide a dialog box in which you can enter the
user-definable settings for the service before creating it. Service provisioning happens asynchronously,
and the bottom of the page displays an indicator to show the current activity. You can expand this
indicator to show a list of completed and in-process tasks.
Managing services
You can see a list of provisioned services on the ALL ITEMS page and on each service-specific page. The
list shows the name, status, and service-specific settings for each service. You can click a service name in
the list to view the dashboard for that service instance, where you can use multiple tabbed subpages to
view and configure the service-specific settings. In most cases, you make changes to a service by using the
command bar containing context-specific icons.
The Azure classic portal supports only the classic deployment model. You will not find any references to
resource groups and you will not be able to view or manage services or resources that you deployed by
using Azure Resource Manager.
Note: You should avoid using the Azure classic portal unless the services you need to
manage are not yet available in the Azure portal.
Additional Reading: For the list of services that still require the use of the Azure classic
portal, refer to: “Azure portal availability chart” at: https://aka.ms/ianie6
Managing account subscriptions with the Azure portals

As the Account Administrator, you can view and
manage most settings for your Azure
subscriptions and their billing from the Azure
portal. The Billing blade allows you to view the
contact information, billing address, payment
methods, and invoices. The Overview pane of this
blade provides access to billing history and
subscription costs. It displays a list of subscriptions
to which you have Account Administrator
privileges. From the list of subscriptions listed on
the Billing blade, you can navigate to their
respective blades. Alternatively, you can also
access the list of subscriptions from the Subscriptions blade. Either of these methods allows you to view
charts that summarize the cost by resource type and burn rate on the subscription level. The Cost
analysis blade provides detailed charges for individual resources.
To manage payment methods, navigate to the Azure Account Center by using the following link:
https://aka.ms/ss8yrc (an Azure account is required). In the Azure Account Center, from the subscriptions
page, you can also access the following options:
• Download usage details

• Contact Microsoft support
• Edit subscription details
• Change subscription address

• View partner information
• Cancel your subscription
Note: Customers with an Enterprise Agreement with Microsoft have access to the Azure
Enterprise Portal, which simplifies management of multiple accounts and subscriptions.
Additional Reading: For more information regarding the Azure Enterprise Portal, refer to:
http://aka.ms/V91c9h
Additional Reading: Rather than relying on the Azure portals, you can calculate estimated
consumption data programmatically by using the Azure Resource Usage API. Similarly, you can
use Azure Resource RateCard API to obtain estimated pricing information for each Azure
resource. For more information, refer to: https://aka.ms/ab675f
Demonstration: Using the Azure portals

• Use the new Azure portal.
• Use the Azure classic portal.

• Use the Azure Account Center.
Question: What are some of the advantages of the Azure portal over the Azure classic
portal?
Lesson 4
Managing Azure with Windows PowerShell
The Azure portals provide a graphical user interface (GUI) for managing Azure subscriptions and services.
In many cases, they are the primary management tools for service provisioning and operations. However,
many organizations strive to automate their IT processes by creating reusable scripts or by combining
Azure resource management with the management of other network and infrastructure services. Windows
PowerShell provides a scripting platform for managing a wide range of environments, including Azure.
This lesson explores how you can use Windows PowerShell to connect to an Azure subscription and to
provision and manage Azure services.
Lesson Objectives
• Identify the Azure modules for Windows PowerShell.

• Explain the differences between Azure AD Authentication and certificate authentication.
• Identify the Windows PowerShell cmdlets used for the classic deployment model and for Azure
Resource Manager.
• Use Windows PowerShell to manage Azure.
Azure PowerShell modules

The primary strength of Windows PowerShell is its
extensibility, which relies on its ability to
dynamically load software modules that contain
cmdlets and functions. You can run these
functions and cmdlets interactively from the
Windows PowerShell console prompt and the
Windows PowerShell Integrated Scripting
Environment (Windows PowerShell ISE) console
pane. Alternatively, you can incorporate them into
custom scripts. Most management tasks that
target Microsoft Azure resources rely on Azure
PowerShell modules.
Azure PowerShell
To manage Azure resources by using Windows PowerShell, you first must install the Azure PowerShell
modules that provide this functionality. In this course, you will work mainly with the AzureRM modules,
which include cmdlets that implement features of Azure Resource Manager resource providers. For
example, cmdlets of the Compute provider, which facilitates the deployment and management of Azure
Virtual Machines, reside in the AzureRM.Compute module.
You should note that deploying and managing Azure resources and services might require using other
modules. For example, to work with classic resources, you should rely on the Azure PowerShell Service
Management module called Azure. Similarly, there are separate modules that allow you to manage
Azure AD, Azure Information Protection, Azure Service Fabric, and Azure ElasticDB, for example.
Additional Reading: For the list of Azure PowerShell modules, refer to: “Azure Active
Directory PowerShell Module Reference” at: https://aka.ms/urrgkq
Azure PowerShell is managed as an open-source project, with the repository hosted on GitHub at
https://aka.ms/gaoe3s. Currently, Windows, Linux, and Mac OS support Azure PowerShell.
The three primary methods of installing the latest versions of the Azure PowerShell modules are:
• The Web Platform Installer (Web PI). This installation method is available directly from the Azure
Downloads page. It simplifies the setup process by relying on Web PI capabilities, which include
obtaining the most recent version of the installation files and automatically deploying and
configuring any prerequisites.
Additional Reading: For more information, refer to: “Downloads” at: https://aka.ms/vgz7tb
• The PowerShell Gallery. This method relies on the capabilities built into the PowerShellGet module,
which facilitates discovery, installation, and updates of a variety of PowerShell artifacts, including
other Windows PowerShell modules. PowerShellGet relies on the functionality built into Windows
Management Framework, which is part of the operating system, starting with Windows 10 and
Windows Server 2016. The same version of Windows Management Framework is also available at
https://aka.ms/r3meci. You can download and install it on any supported version of Windows, starting
with Windows 7 Service Pack 1 and Windows Server 2008 R2. Note, however, that this will
automatically upgrade Windows PowerShell to the matching version. If you want to enable the
PowerShellGet functionality on systems running Windows PowerShell 3.0 or Windows PowerShell
4.0, you must install the PackageManagement module available at https://aka.ms/xdrgnc.
To perform the installation based on PowerShellGet, run the Install-Module cmdlet from an elevated
session within the Windows PowerShell console or from the Windows PowerShell ISE console pane. To
install the Azure PowerShell modules from the PowerShell Gallery, run the following commands at the
Windows PowerShell command prompt:
Install-Module AzureRM
Install-Module Azure
Additional Reading: For more information, refer to: “Windows Management Framework
5.1” at: https://aka.ms/r3meci
• Microsoft Windows Installer (MSI) packages. This method allows you to install the current or any
previously released version of Azure PowerShell by using MSI packages available on GitHub. The
installation will automatically remove any existing Azure PowerShell modules.
Additional Reading: For more information, refer to: “Azure/azure-powershell” at:

http://aka.ms/Vep7fj
Note: Web PI installs Azure PowerShell modules within the %ProgramFiles%

\Microsoft SDKs\Azure\PowerShell directory structure. PowerShell Gallery–based installations
use the %ProgramFiles%\WindowsPowerShell\Modules version-specific directory structure.
MSI packages also install into %ProgramFiles%\WindowsPowerShell\Modules; however, they
do not use version-specific subfolders. PowerShell Gallery–based installation allows you to install
multiple versions of the Azure PowerShell module on the same operating system by supporting
the –RequiredVersion parameter of the Import-Module cmdlet.
Each installation method automatically updates the $env:PSModulePath variable. If you decide
to install multiple versions of the Azure PowerShell module, you can import a specific version by
adding the –RequiredVersion parameter when running the Import-Module cmdlet.
Azure AD module for Windows PowerShell

If you plan to manage users, groups, and other aspects of Azure AD from Windows PowerShell, you
should install the Azure Active Directory PowerShell module version 2. The module is available from the
PowerShell Gallery and you can install it by running the following cmdlet from a Windows PowerShell
prompt:
Install-Module -Name AzureAD
Additional Reading: For more information, refer to: “Azure Active Directory PowerShell
Module Reference” at: https://aka.ms/urrgkq
Azure Active Directory PowerShell module has two versions: The General Availability version and the
Public Preview version. The Public Preview version, which offers some additional features, is not intended
for production environments. If you want to explore its capabilities, you can install it from the PowerShell
Gallery by running the following cmdlet from a Windows PowerShell prompt:
Install-Module -Name AzureADPreview
Alternatively, you can use the Azure Active Directory PowerShell module version 1. At the time of writing
this course, this module offers some extra functionality not yet implemented in version 2. This module is
also available from the PowerShell Gallery. To install it, run the following cmdlet from a Windows
PowerShell prompt:
Install-Module -Name MSOnline
Additional Reading: For more information, refer to: “Azure ActiveDirectory (MSOnline)” at:
https://aka.ms/rqcbd9
Azure Automation Authoring Toolkit

You can use the Azure Automation service to run Windows PowerShell workflows and scripts as runbooks
directly in Azure, either on demand or based on a schedule. While it is possible to develop Azure
Automation runbooks directly in the Azure portal, you can also use the Windows PowerShell ISE for this
purpose. To simplify the process of developing runbooks in Windows PowerShell ISE, install the Azure
Automation Authoring Toolkit and its ISE add-on from the PowerShell Gallery by running the following
cmdlets:
Install-Module AzureAutomationAuthoringToolkit -Scope CurrentUser

Install-AzureAutomationIseAddOn
Authenticating to Azure by using Windows PowerShell

After you install the Azure PowerShell module,
you must first authenticate successfully to access
your Azure subscription. There are two basic
authentication methods: Azure AD Authentication
and certificate-based authentication.
Azure AD Authentication
You can use Azure AD Authentication to access an
Azure subscription by using one of the following
types of credentials:
• A Microsoft account
• A Work or School account
• An Azure AD security principal

An Azure AD security principal is an identity that you can associate with an application or a script that you
want to execute in its own, dedicated security context. An ApplicationId attribute uniquely identifies each
service principal. You can configure a security principal to authenticate either by using either a password
or a certificate.
To authenticate when using the Azure Resource Manager PowerShell module, use the Add-
AzureRmAccount cmdlet. This triggers an interactive sign-in, displaying a browser window in which you
must enter valid Azure AD credentials. Azure AD Authentication is token-based, and after you sign in, the
credentials associated with the Windows PowerShell session persist until the authentication token expires.
Additional Reading: The expiration time for an Azure AD Authentication token depends on
several factors. For more information, refer to: “Configurable token lifetimes in Azure Active
Directory (Public Preview)” at: https://aka.ms/dyy43e
After you authenticate, you can use the Get-AzureRmContext cmdlet to view the user account, the
corresponding Azure AD tenant, and the Azure subscriptions associated with the current Windows
PowerShell session. The Get-AzureRmSubscription cmdlet provides a subscription-specific subset of
this information. If you have multiple subscriptions, you can set the current subscription by using the
Set-AzureRmContext cmdlet with the name or ID of the subscription that you want to use. To save
the current authentication information to reuse it in another Windows PowerShell session, use
Save-AzureRmProfile. Then you can retrieve the authentication information later by running
Select-AzureRmProfile.
Additional Reading: For information, refer to: “Using AAD Credentials with Azure
PowerShell Cmdlets” at: https://aka.ms/kcsefe
Certificate-based authentication
Most tools that you use to manage Azure support Azure AD Authentication. Generally, we recommend
using Azure AD Authentication as the primary authentication mechanism. However, in some cases, it
might be more appropriate to authenticate by using certificates. For example, this allows you to run your
scripts unattended by eliminating interactive authentication prompts.
How you implement certificate-based authentication depends on whether you intend to interact with
Azure Resource Manager or classic resources. With Azure Resource Manager, the process involves the
following steps:
1. Obtaining a certificate. You can use either a self-signed certificate or a certificate issued by a
certificate authority.
2. Creating an Azure AD service principal and associating it with the certificate.
3. Granting the service principal appropriate permissions to resources within the Azure subscription. The
level of permissions should reflect the scope of tasks that the script or application must be able to
carry out.
Additional Reading: For more information, refer to: “Use Azure PowerShell to create a
service principal to access resources” at: http://aka.ms/Yym3a7
Classic cmdlets support the use of management certificates. Once you generate such a certificate, you
must store its private key in the certificate store within the profile of the user or computer account. You
also need to upload the public key of the management certificate into the target Azure subscription. At
that point, you will be able to run your scripts from within the security context of the designated account.
When implementing certificate-based authentication in the classic deployment model, you can use an
Azure-generated certificate or an existing certificate. The existing certificate can be self-signed or issued
by a certificate Authority.
Using an Azure-generated certificate in the classic deployment model

An Azure management certificate is an X.509 version 3 (v3) certificate that associates a client app or
service with an Azure subscription. You can use an Azure-generated management certificate, or you can
generate your own by using your organization’s public key infrastructure solution or a tool such as
MakeCert.
To use an Azure-generated certificate in Windows PowerShell, run the Get-PublishSettingsFile cmdlet,

which opens a web browser where you can sign in to your Azure account and then download a certificate
file. After the file downloads, use the Import-PublishSettingsFile cmdlet to store the certificate securely
in the local certificate store.
Important: The downloaded certificate file, which has the default file name extension
.publishsettings, contains sensitive information. You should download this to a security-enhanced
location and delete it after you import the certificate.
After you import the certificate, you can run the Get-AzureSubscription cmdlet to verify that the
subscription from which you downloaded the certificate file is available in Windows PowerShell. You can
then use the Set-AzureSubscription cmdlet to make it the default subscription.
Note: Using a .publishsettings file works only in the classic model. Azure Resource Manager
cmdlets will not work with a .publishsettings file.
Using your own certificate in the classic deployment model

When you use your own certificate, you should store the certificate in the personal certificate store for the
user account which will make requests to Azure. You should then export the certificate to a .cer file that
does not include the private key. You can then upload the certificate to your Azure subscription in the
Azure portal.
To authenticate by using the certificate in Windows PowerShell, you can use the Set-AzureSubscription
cmdlet, specifying the subscription name, subscription ID, and certificate. You can obtain the subscription
ID from the Azure portal, and you can reference the certificate in Windows PowerShell by using the
Get-Item cmdlet.
The following code example shows how to set the current subscription by using a specific certificate:
Using a specific certificate

$subName = "<the subscription name">
$subID = "<copy the subscription ID from the Azure portal>"
$thumbprint = "<the thumbprint of the certificate you want to use>"
$cert = Get-Item cert:\\currentuser\my\$thumbprint
Set-AzureSubscription -SubscriptionName $subName, -SubscriptionId $subId -Certificate
$cert
To obtain the certificate thumbprint, you can either view the certificate in Certificate Manager or use the
Windows PowerShell command Get-Item cert:\\currentuser\my\* to obtain a list of all the personal
certificates and their thumbprints.
Azure PowerShell cmdlets for Azure classic deployment model and Azure
Resource Manager
After you authenticate from a Windows
PowerShell session to your Azure subscription, you
can use Azure PowerShell cmdlets to view,
provision, and manage Azure resources. The
cmdlets you will use depend on the deployment
model used to provision the resources. The Azure
classic deployment model uses the Azure module
for Windows PowerShell, whereas the Azure
Resource Manager model uses the AzureRM
module for Windows PowerShell.
You can easily distinguish between Azure

Resource Manager and Service Management
cmdlets because they use slightly different formats. Both types of cmdlets use the verb-noun syntax, but
while the noun portions of Azure Resource Manager cmdlets start with AzureRm, the Service Management
cmdlets include only Azure (without the Rm string). For example, to deploy a new Azure virtual machine
by using Azure Resource Manager, you run the New-AzureRmVM cmdlet. To accomplish the same task
in the classic deployment model, you use the New-AzureVM cmdlet. In addition, the noun portion might
differ due to service name changes that the Azure Resource Manager model introduced.
The following table illustrates some of the differences between the two sets of Windows PowerShell
cmdlets.
Functionality or Azure classic deployment

Azure Resource Manager
command model
Sign in to Azure Add-AzureAccount Add-AzureRmAccount
Create a virtual New-AzureVM New-AzureRmVM

machine
Create a web app New-AzureWebsite New-AzureRmWebapp
Demonstration: Using Azure PowerShell

In this demonstration, you will see how to use Azure PowerShell to:
• Create a resource group.
• Create a storage account.

• Delete a resource group with its resources.
Question: How can you differentiate between classic model cmdlets and Azure Resource
Manager cmdlets?
Lesson 5
Managing Azure with Azure CLI
While the Azure PowerShell module is available on Linux and Mac OS, in addition to Windows, its primary
users tend to work mostly with Microsoft technologies. Those operating in the open-source environments
favor scripting tools that resemble UNIX and Linux shell interfaces. Azure CLI provides this type of
interface. In this lesson, you will learn about the basic characteristics of Azure CLI, its installation methods,
and a few basic commands that allow you to access your Azure subscription.
Lesson Objectives
• Distinguish between Azure CLI 1.0 and Azure CLI 2.0.
• Install Azure CLI.
• Use Azure CLI to access an Azure subscription.
Azure CLI versions

The Azure CLI provides a command-line, shell-
based interface that you can use to interact with
your Azure subscriptions. The Azure CLI offers a
similar set of features as the Azure PowerShell
modules. Its primary advantage is close
integration with shell scripting, including support
for popular tools such as grep, awk, sed, jq, and
cut, thereby allowing Linux administrators to
leverage their existing skills when managing Azure
resources.
At the time of authoring this course, there are two
versions of Azure CLI:
• Azure CLI 1.0 (sometimes referred to as Azure Cross-Platform Command-Line Interface or XPlat-CLI).
This version is written in Node.js to provide cross-platform support. Its open-source repository resides
at https://aka.ms/qxp7e4.
• Azure CLI 2.0. This version, written in Python, offers several improvements and new features
compared to its predecessor. These features include the ability to build pipelines consisting of Azure
CLI commands and shell tools, tab completion for commands and parameter names, support for
asynchronous command execution, and enhanced in-tool help. Its open-source repository resides at
https://aka.ms/jddotl.
Azure CLI 2.0 supports the Azure Resource Manager deployment model exclusively. If you still manage
any classic resources, you can run both versions side-by-side. In fact, both CLIs share credentials that you
provide and the Azure subscriptions that you select by default, simplifying your management experience
in a mixed environment. You can easily distinguish commands that belong to each version. Azure CLI 1.0
commands start with the keyword azure, while Azure CLI 2.0 commands start with the keyword az.
Both versions of Azure CLI are available on Windows, Linux, and Mac OS. You can install Azure CLI 2.0
directly on Windows or within a Bash environment on Windows. The second method offers a user
experience that is closest to running Azure CLI directly on Linux. This, in turn, facilitates running most
Linux command-line tools without any modifications. Both are also available in the Cloud Shell
environment accessible directly from the Azure portal.
Note: Bash on Windows is in preview at the time of authoring this course.
Note: In this course, you will be using Azure CLI 2.0 predominantly, resorting to Azure CLI
1.0 only when managing Azure classic resources.
Installing Azure CLI

The installation process for the Azure CLI depends
on its version and, to some extent, on the target
operating system. Because Azure CLI 1.0 was
developed by using Node.js, you must install
Node.js before installing Azure CLI 1.0. You can
obtain Node.js installers and binaries for Windows,
Linux, and Mac OS operating systems from
https://aka.ms/i7hw4o. Similarly, Python is a
prerequisite for installing Azure CLI 2.0. Python
installers are available at https://aka.ms/wfus7d.
Installing Azure CLI 1.0

After you install Node.js, you can use the Node
package manager npm command-line tool to install the Azure CLI 1.0 package by running the following
command:
npm install –g azure-cli
You can also deploy a Docker container running Azure CLI 1.0 onto a Docker host. To do so, use the
docker command-line tool and run the following command:
docker run it microsoft/azure-cli
Alternatively, you can download precompiled installers from the Azure CLI 1.0 GitHub repository. The
installers are available for Windows, Linux, and Mac OS.
Additional Reading: For more information about installing Azure CLI 1.0, refer to: “Azure
Xplat-CLI for Windows, Mac and Linux” at: https://aka.ms/qxp7e4
Installing Azure CLI 2.0

You can use precompiled installers for Windows, Linux, and Mac OS to install Azure CLI 2.0. If you
implement Azure CLI 2.0 in a Bash environment on Windows, you can use the apt-get tool. You can use
the same tool when running Debian and Ubuntu Linux distributions. Both Linux and Mac OS also support
installation of Azure CLI 2.0 via the curl command referencing the http://aka.ms/InstallAzureCli URL.
Additional Reading: For more information about installing Azure CLI 2.0, refer to: “Install
Azure CLI 2.0” at: https://aka.ms/ng96x1
The installation modifies the Path system environment variable. This allows you to run Azure CLI
commands directly from a command prompt window on Windows or command shell on Linux or Mac OS.
Using Azure CLI to access your Azure subscription

Installing Azure CLI gives you a set of tools to
manage Azure resources. However, just as with
Azure PowerShell modules, to access the target
subscription containing these resources, you must
first authenticate. You can do so by using a
Microsoft account, a work or school account, or a
security principal that exists in the Azure AD
tenant associated with that subscription.
To initiate the authentication process, run one of

following commands (depending on the Azure CLI
version) from a command shell or a command
prompt:
azure login
az login
In response, the shell displays a message prompting you to start a browser and browse to the Device
Login page at http://aka.ms/devicelogin. There you must enter the code provided as part of the message
that the shell generated. This step verifies the Azure CLI as the application publisher and allows you to
enter your user credentials to authenticate to the Azure subscription.
Azure AD Authentication is token-based, and after you sign in, the credentials associated with the Azure
CLI session persist until the authentication tokens expire.
Additional Reading: Just as Windows PowerShell, the expiration time for an Azure AD
authentication token depends on several factors. For more information, refer to: “Configurable
token lifetimes in Azure Active Directory (Public Preview)” at: https://aka.ms/dyy43e
After you authenticate, you can use the azure account list (Azure CLI 1.0) or az account list (Azure CLI
2.0) command to view a list of subscriptions associated with your account. If you have multiple
subscriptions, you can specify the one you want to manage by using the azure account set or az
account set command, and providing either the subscription name or its ID.
Note: You can identify the subscription name and ID by reviewing the output of the azure
account list or az account list command.
Azure CLI 1.0 supports both Azure Resource Manager and classic deployment models, but uses separate
modes for working with each. To switch between them, you must use the azure config mode command.
To switch to the Azure Resource Manager mode, run the following command:
azure config mode arm
To switch to the classic deployment mode, run the following command:
azure config mode asm
Demonstration: Using Azure CLI

• Create a resource group.
• Delete a resource group with its resources.
Question: What would you consider to be primary strengths of Azure CLI 2.0?
Lesson 6
Overview of Azure deployment models
As mentioned earlier in this module, there are two methods of deploying Azure resources. The traditional
approach, referred to as the Azure classic deployment model, relies on the Service Management API.
While classic deployments still exist, you should use the newer Azure Resource Manager deployment
model for any new deployments.
This lesson covers both deployment models, including the differences between them. This lesson also
discusses scenarios that involve interaction between their respective resources. However, this course
emphasizes the Azure Resource Manager model because this is the prevailing deployment methodology.
Lesson Objectives
• Explain core concepts of Azure Resource Manager deployment model.

• Identify tasks involved in managing resources and resource groups.
• Describe the Azure Resource Manager deployment methodologies.
• Explain the basic structure of Azure Resource Manager templates.

• Describe the syntax of individual components of Azure Resource Manager templates.
• Deploy an Azure Quickstart template.
• Explain core concepts of the Azure classic deployment model.
Core concepts of Azure Resource Manager deployment model

The concept of the resource is fundamental in
Azure Resource Manager. A resource is an
elementary building block of services and
solutions that you deploy into Azure. You can
manage each resource by interacting with its
resource provider, which implements actions that
you invoke through any of the available
administrative interfaces, such as the Azure portal,
Azure PowerShell, Azure CLI, or REST API.
Every resource exists in one, and only one,

resource group. A resource group is a logical
container that simplifies managing multiple
resources. Resources in the same resource group typically share the same lifecycle, although you can
customize your choice of criteria for grouping resources. By using resource groups, you can manage
resources as a group, rather than individually. This allows you to delegate permissions on the resource
group level, obtain estimated costs, audit events, and utilize data for all resources within the groups.
When you no longer need the resources in a resource group, you can remove them all in a single step.
Azure Resource Manager supports very granular delegation of administration based on the role-based
access control (RBAC) model. The delegation relies on predefined and custom-defined roles within the
target Azure subscription. Each role represents a collection of actions and the corresponding resources.
For example, you can create a role that will grant the ability to stop and start an Azure virtual machine.
Alternatively, you can use the predefined Virtual Machine Contributor role that grants the ability to carry
out a more extensive set of virtual machine management actions. Once you create a new group or
identify an existing one, you associate it with the scope of delegation, such as an entire subscription, a
resource group, or even an individual resource. Finally, you assign a group to a user, group, or security
principal in the Azure AD tenant associated with the Azure subscription hosting the resources you
manage.
Note: When assigning permissions via RBAC, you must choose users and groups from the
Azure AD tenant that is associated with your subscription. However, you can change this
association to use the same Azure AD tenant across multiple subscriptions.
Tagging is another benefit of the Azure Resource Manager deployment model. Tags are custom labels
that you can assign to resources, resource groups, and subscriptions. You can utilize this functionality to
describe your cloud environment. For example, you can specify the ownership of individual resources,
assign them to the appropriate cost center, or designate them as production, test, or development. Tags
appear in the billing data available to the Account Administrator. This simplifies identifying costs
associated with tagged resources for chargeback purposes.
Azure Resource Manager offers a distinct deployment methodology, not available in the classic
deployment model. This methodology leverages deployment templates. A template is a JavaScript Object
Notation (JSON)–formatted file that defines a collection of resources that you intend to create and
configure. During a deployment, you provide the template, specify its parameters, and specify the
resource group where the deployment should take place. Once the deployment completes, the target
resource group contains resources created and configured according to the template’s content.
Templates constitute an example of the declarative deployment model, which defines the desired end
state, rather than describing the deployment process. This is different from a script-based deployment,
which implements the imperative approach, explicitly dictating the sequence in which to provision
different resources. Templates rely on intelligence that is built into the Azure platform to carry out
deployment in the most optimal way, typically resulting in minimized deployment time.
Azure Resource Manager also includes support for policies and locks that enhance resource deployment
and management capabilities. Policies allow you to define conditions that, if satisfied, affect the outcome
of a deployment. For example, you can prevent users from creating resources without assigning to them a
specific tag. You can also restrict the sizes of VMs that users can provision, or restrict locations to which
users can deploy such VMs.
Policies take the form of JSON-formatted policy definition files with a relatively straightforward syntax.
The following shows a sample policy that restricts all deployments to the East US region:
{
"if" : {
"not" : {
"field" : "location",
"in" : ["eastus"]
}
},
"then" : {
"effect" : "deny"
}
}
Once you have a JSON file containing the intended policy, you must create a policy definition object. To
accomplish this, you can use the Azure PowerShell New-AzureRmPolicyDefinition cmdlet or Azure CLI
az policy definition create command. After you create a policy definition, you must assign it to a scope
where the policy will apply, such as a resource group or an entire subscription. You can use the Azure
PowerShell New-AzureRmPolicyAssignment cmdlet or Azure CLI az policy assignment create
command for this purpose.
The primary purpose of locks is to prevent accidental modification or deletion of resources. There are two
types of locks:
• Read-only. This lock prevents modification within the scope where the lock is assigned.
• Delete. This lock prevents deletion within the scope where the lock is assigned.
You can assign a lock on a resource, a resource group, or a subscription. The most straightforward way to
create and assign a lock is directly from the Azure portal. You will find the Lock entry on the blade of each
resource, resource group, and subscription. After clicking it, you will need to specify the lock’s name and
type. Optionally, you can add notes to document your configuration change. You can also apply locks via
Azure PowerShell, Azure CLI, an Azure Resource Manager template, or REST API.
Managing resources and resource groups

Every Azure resource belongs to a resource group.
When provisioning a resource via the Azure
portal, you can create a new resource group or
use an existing resource group.
When you deploy a solution that consists of a few

resources working together, you should create a
dedicated resource group to help manage the
lifecycle of all the related assets. You can add or
remove additional resources from the resource
group as your solution evolves.
Creating resource groups and adding resources to resource groups

You can add resources to a resource group at any time. The Azure portal has an Add option for this
purpose. Deleting a resource group will delete all the resources that it contains. The Azure Resource
Manager Azure PowerShell module allows you to manage resource groups in your Azure subscription.
You can create resource groups by using the New-AzureRmResourceGroup cmdlet. You can then use
resource type–specific cmdlets to create resources in that resource group. You can also use a deployment
template to add resources to a resource group. Azure CLI offers equivalent capabilities with the az group
create command and resource-specific commands.
Moving resources and resource groups

You can move resources between resource groups in the same or different Azure subscriptions. This might
be necessary for several reasons:
• A resource needs to be in a different logical grouping or Azure subscription.
• A resource does not share the same lifecycle with other resources that were in its group.
You should consider the following factors when moving a resource:
• You cannot change a resource’s location. After you create a resource, it must remain in the same
Azure region.
• You should use the latest version of the Azure PowerShell module if you are using it to move
resources.
• Both the source and destination resource groups are blocked for deletion while the move operation
takes place.
There are additional considerations when moving resources between subscriptions, including the
following:
• Both subscriptions must be associated with the same Azure AD tenant.

• You must move all dependent resources at the same time. For example, when moving a virtual
machine, you must include in the scope of the move the storage account hosting its virtual disk files
and the virtual network to which its network interface cards are attached.
• You must ensure that the target subscription is registered for the provider of each resource type that
you intend to move.
Additional Reading: For more information regarding registering resource providers, refer
to: “Resource providers and types” at: https://aka.ms/mc7vuj
Additional Reading: Not every resource type supports the move operation. For more
information, refer to: “Move resources to new resource group or subscription” at:
http://aka.ms/Ry0sqz
Azure Resource Manager deployment methodologies

In the past, deploying Azure-based solutions
relied on the imperative approach. The
provisioning process consisted of a sequence of
steps, each creating individual components of the
solution.
The new programming interface of Azure
Resource Manager supports a new, declarative
deployment methodology, based on Azure
Resource Manager deployment templates. A
template is a JSON-formatted file that defines a
collection of resources that you intend to
provision together in the same resource group.
The resulting deployment populates the target resource group according to the template’s content.
While traditional deployment methods that rely on the GUI or scripting and programming languages are
still available, templates offer additional benefits. Like scripts, they facilitate deployment of
multicomponent solutions in an automated manner. However, unlike scripts, they do not explicitly specify
individual steps required to provision these solutions. Instead, they simply define their intended end state.
This way, they rely on the intelligence built into the Azure platform to deploy all necessary resources in
the most optimal way. This results in minimized deployment time and reduces the potential for errors.
You can define dependencies between resources to control the resource-provisioning sequence.
Deployment templates are ideal if you need to provision multiple solutions with the same general design.
For example, you can deploy the same template to separate resource groups, representing development,
test, quality assurance, and production environments. To account for any potential differences between
them, you can replace specific values in the template with parameters, and then assign values to these
parameters at the deployment time.
Templates are idempotent, which means that you can deploy them multiple times to the same resource
group with the same outcome. This is useful when you want to recreate an original deployment or
remediate any issues resulting from post-deployment changes.
Templates support VM extensions, which allow you to configure operating systems within Azure VMs as
part of their deployment. These extensions include several configuration management services, such as
Windows PowerShell Desired State Configuration, Chef, or Puppet.
Note: Visual Studio with Azure SDK simplifies authoring and editing deployment templates.
Introduction to Azure Resource Manager templates

An Azure Resource Manager template contains a
JSON-formatted definition of one or more Azure
resources, along with parameters and variables
that facilitate customizing their configuration.
When creating and working with resource
templates, you should consider:
• Which resources you are going to deploy.
• Where your resources will be located.

• Which version of the resource provider API
you will use.
• Whether there are dependencies between

resources.
• When you will specify values of resource properties. While you can include these values in the
template, it is generally preferable to specify them during deployment via corresponding parameters.
Understanding the structure of a resource template

A resource template consists of the following sections:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "",
"parameters": { },
"variables": { },
"resources": [ ],
"outputs": { }
}
The following table describes the sections in the code sample above.
Element name Required Description
$schema Yes This is a URL identifying the location of the JSON

schema file, which describes the template syntax.
contentVersion Yes A custom value that you define to keep track of

changes to template content.
parameters No You can provide parameters during deployment,

either interactively or via a parameter file, to
customize properties of deployed resources.
variables No Variables are typically used to convert values of

parameters to the format that is required to set
resource property values.
resources Yes These are resources that you want to create or

modify as the result of the deployment.
outputs No These values are returned by the deployment.
The next topic discusses these sections in more detail.
The following code is an example of a complete template that deploys a web app and uses code from a
.zip file to provision the app:
{
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"siteName": {
"type": "string"
},
"hostingPlanName": {
"type": "string"
},
"hostingPlanSku": {
"type": "string",
"allowedValues": [
"Free",
"Shared",
"Basic",
"Standard",
"Premium"
],
"defaultValue": "Free"
}
},
"resources": [
{
"apiVersion": "2014-06-01",
"type": "Microsoft.Web/serverfarms",
"name": "[parameters('hostingPlanName')]",
"location": "[resourceGroup().location]",
"properties": {
"sku": "[parameters('hostingPlanSku')]",
"workerSize": "0",
"numberOfWorkers": 1
}
},
{
"apiVersion": "2014-06-01",
"type": "Microsoft.Web/sites",
"name": "[parameters('siteName')]",
"tags": {
"environment": "test",
"team": "ARM"
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"
],
"properties": {
"serverFarm": "[parameters('hostingPlanName')]"
},
"resources": [
{
"apiVersion": "2014-06-01",
"type": "Extensions",
"name": "MSDeploy",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('siteName'))]"
],
"properties": {
"packageUri":
"https://auxmktplceprod.blob.core.windows.net/packages/StarterSite-modified.zip",
"dbType": "None",
"connectionString": "",
"setParameters": {
"Application Path": "[parameters('siteName')]"
}
}
}
]
}
],
"outputs": {
"siteUri": {
"type": "string",
"value": "[concat('http://',reference(resourceId('Microsoft.Web/sites',
parameters('siteName'))).hostNames[0])]"
}
}
}
Additional Reading: For more information on Azure Resource Manager template structure,
refer to: “Understand the structure and syntax of Azure Resource Manager templates” at:
http://aka.ms/Yxslmx
Exploring the syntax of Azure Resource Manager templates

Azure Resource Manager template syntax can be
complex, especially in a large-scale deployment.
Each section of the template has its own structure
and syntax, and you can use numerous functions
and operators to define your deployment
configuration.
Understanding template sections

Template sections include parameters, variables,
resources, and outputs. This topic provides specific
information about each template section and the
type of code it contains.
Parameters
Parameters represent the values that you can specify when performing a deployment. With parameters,
you can customize the deployment process, which makes a template more flexible, accounting for
potential differences between target environments. For example, you might declare a parameter that
allows you to specify an Azure region. Without this parameter, you must specify the region directly in the
template, limiting its flexibility.
You can define each parameter by using any of the following elements.
parameterName Yes This is the parameter’s name.
type Yes This is the parameter type, such as a string, integer,

Boolean, object, or array.
defaultValue No This value is assigned automatically to the parameter if

you do not assign one explicitly during deployment
time.
allowedValues No This is an array or list of values that the parameter can

contain.
minValue No This is the minimum value for integer parameters.
maxValue No This is the maximum value for integer parameters.
minLength No This is the minimum length for string and array

parameters.
maxLength No This is the maximum length for string and array

parameters.
Description No This is description of the parameter that appears when

deploying the template from the Azure portal.
The following code provides examples of parameters:
"parameters": {
"siteName": {
"type": "string",
"minLength": 2,
"maxLength": 60
},
"siteLocation": {
"type": "string",
"minLength": 2
},
"hostingPlanName": {
"type": "string"
},
"hostingPlanSku": {
"type": "string",
"allowedValues": [
"Free",
"Shared",
"Basic",
"Standard",
"Premium"
],
"defaultValue": "Free"
Variables
Variables contain values which are typically calculated based on values that you provide via parameters.
The following code provides examples of variables:
"variables": {
"environmentSettings": {
"test": {
"instancesSize": "Small",
"instancesCount": 1
},
"prod": {
"instancesSize": "Large",
"instancesCount": 4
}
},
"currentEnvironmentSettings":
"[variables('environmentSettings')[parameters('environmentName')]]",
"instancesSize": "[variables('currentEnvironmentSettings').instancesSize",
"instancesCount": "[variables('currentEnvironmentSettings').instancesCount"
}
Resources
The resources section includes a list of resources that the template will deploy, including their properties,
which might reference parameters and variables to set property values. Describing each resource can be
complex. Authoring this section of your template requires knowledge of the resource types that you are
deploying.
You define resources by using the elements in the following table.
apiVersion Yes This is the version of the REST API that the resource
provider will use to create the resource.
type Yes This is a string consisting of the resource provider name

and the resource type.
name Yes This is the resource name.
location No This is the name of the Azure region where the resource
will be deployed.
tags No These are tags that are associated with the resource.
dependsOn No This is a list of resources on which the current resource

depends. The dependsOn element and the resources
element determine the order in which resources are
deployed. If you do not include these elements in the
template, the resource providers determine the order of
deployment.
properties No These are resource-specific settings.
resources No These are child resources that depend on the current

resource for their functionality. You must include this
element and the dependsOn element to express the
parent-child relationship.
The following code contains an example of resources definition:
"resources": [
{
"apiVersion": "2014-06-01",
"type": "Microsoft.Web/serverfarms",
"properties": {
"sku": "[parameters('hostingPlanSku')]",
"workerSize": "0",
"numberOfWorkers": 1
}
},
{
"apiVersion": "2014-06-01",
"type": "Microsoft.Web/sites",
"tags": {
"environment": "test",
"team": "ARM"
},
"dependsOn": [
"[resourceId('Microsoft.Web/serverfarms', parameters('hostingPlanName'))]"
],
"properties": {
"serverFarm": "[parameters('hostingPlanName')]"
},
"resources": [
{
"apiVersion": "2014-06-01",
"type": "Extensions",
"name": "MSDeploy",
"dependsOn": [
"[resourceId('Microsoft.Web/sites', parameters('siteName'))]"
],
"properties": {
"packageUri":
"https://auxmktplceprod.blob.core.windows.net/packages/StarterSite-modified.zip",
"dbType": "None",
"connectionString": "",
"setParameters": {
"Application Path": "[parameters('siteName')]"
}
}
}
]
}
]
Outputs
The outputs section allows you to specify values that the deployment returns. For example, the
deployment could return the uniform resource identifier (URI) value of a resource that was deployed in
the template. The following table describes the elements included in the outputs section of an Azure
Resource Manager template.
outputName Yes Name of the output value. This must be a valid JavaScript
identifier.
Type Yes Type of the output value. The types supported are the
same as those supported by parameters.
value Yes Expression that provides the returned output value.
The following example shows a value that is returned in the Outputs section:
"outputs": {
"siteUri" : {
"type" : "string",
"value": "[concat('http://',reference(resourceId('Microsoft.Web/sites',
parameters('siteName'))).hostNames[0])]"
}
}
Additional Reading: For more information about Azure Resource Manager template
sections, refer to: “Understand the structure and syntax of Azure Resource Manager templates” at:
http://aka.ms/Yxslmx
Understanding template functions

The following table details the function types that you can use in a template to customize its content.
Function group Description
Numeric These functions work with integer variable types.
String These functions work with string variable types.
Array These functions work with arrays and array values.
Deployment value These functions retrieve values from sections of the template or values
related to deployment.
Resource These functions retrieve values related to resources.
The following list contains some examples of template functions:

• add(): This function returns the sum of two integers. For example, add(2,5) returns an integer value
of 7.
• concat(): This function combines two or more string or array values into a single string or array value.
For example, concat(‘Hello,’World’) returns a string value of ‘HelloWorld’.
• toLower(): This function converts all characters of a string to lower-case. For example,
toLower(‘Adatum’) returns a string value of ‘adatum’.
• parameters(): This function returns the value of a parameter that has been defined in the template.
For example, parameters(‘locName’) returns the value that the template user specified for the
locName parameter.
Additional Reading: For more information about Azure Resource Manager template
functions, refer to: “Azure Resource Manager template functions” at: http://aka.ms/Jcr7f7
Additional Reading: You can find hundreds of sample Azure Resource Manager templates
in the Azure Quickstart Templates repository on GitHub at: https://aka.ms/vvn2op
Demonstration: Viewing and deploying a GitHub Azure Quickstart

template
• Visualize an Azure Resource Manager template.
• Deploy an Azure Resource Manager template from GitHub.

Core concepts of the Azure classic deployment model

The Azure classic deployment model was
originally referred to as the Service Management
model. Introduced in 2009, this model served as
the primary method of deploying and managing
Azure services until the introduction of Azure
Resource Manager.
While there are numerous differences between

the two models, this lesson focuses on IaaS-
related differences. In this context, the primary
concept that distinguishes Service Management
from Azure Resource Manager is cloud service. A
cloud service is a logical container hosting one or
more VMs. Besides enabling the VMs to communicate directly with each other, it also allows for access to
them over the internet. This is possible because each cloud service automatically receives a public IP
address and a corresponding, publicly resolvable DNS name.
Typically, to access a VM in the classic deployment model, you create an endpoint by modifying the cloud
service where this VM resides. Each VM exists within the boundaries of a cloud service. Cloud service also
allows for grouping VMs into availability sets, thereby providing resiliency against hardware failures and
continuity of service during occasional maintenance events in Azure datacenters. Hardware failure
resiliency relies on placing VMs into two distinct fault domains, with each fault domain representing
separate server racks. Continuity of service involves placing VMs into five update domains. The platform
ensures that separate fault domains are never updated at the same time.
Cloud service also provides load-balancing functionality. By using a load-balanced endpoint, Cloud
service distributes incoming traffic and targets a specific port across VMs within the same availability set.
In addition, Cloud service handles network address translation (NAT), allowing for connectivity to
individual VMs via its endpoints.
Optionally, you can also create a virtual network in Azure and deploy VMs in the classic deployment
model into the virtual network. This arrangement allows you to provide direct connectivity between VMs
that do not reside within the same cloud service. Creating a virtual network and deploying VMs into it is
also necessary if you want to establish direct connectivity between Azure VMs and on-premises networks.
Although all services that you provision by using the Azure classic deployment model belong to a
resource group, you cannot directly assign them to a specific group at the time of provisioning. In some
cases, it is possible to move classic resources across resource groups. For example, you can move a classic
VM to another resource group, if you move it along with its cloud service and all other VMs that are part
of the same cloud service. At the time of authoring this course, there is no support for moving classic
virtual networks between resource groups.
Azure classic deployment model does not support several Azure Resource Manager–specific mechanisms,
such as tags, policies, or locks. However, it is possible to use RBAC to control access to classic resources.
Additional Reading: You can use an automated process in Azure PowerShell to facilitate
migration of Azure VMs, virtual networks, and storage accounts from the classic deployment
model to the Resource Manager deployment model. For more information, refer to: “Migrate
IaaS resources from classic to Azure Resource Manager by using Azure PowerShell” at:
https://aka.ms/ovhdg9
Question: What criteria would you use when defining resource groups in your environment?
Lesson 7
Managing and monitoring Azure resources
You can manage and monitor your Azure environment by using the built-in Azure utilities in addition to
other management products not designed specifically for the public cloud, such as Microsoft System
Center. This lesson outlines the primary management services and methods available for Azure and
explains how you can use them in your environment.
Lesson Objectives
• Describe the Microsoft Operations Management Suite (OMS).
• Explain how to track events and collect diagnostics in Azure.
Logs Analytics (Operations Management Suite)

Log Analytics (Operations Management Suite) is a
Microsoft cloud-based service that delivers
enterprise-wide monitoring and management
functionality for on-premises and cloud-based
resources from a single console. While its core
functionality relies on the powerful log search and
analysis functionality, its capabilities span several
functional groups, including:
• Operational visibility and management:

o Proactive smart alerts
o Operations dashboard and reporting
o Real-time, customizable reporting
• Security:
o Security log collection
o Breach and threat detection
o Forensic analysis
• Performance monitoring and analytics:
o Resource monitoring for Windows and Linux
o On-premises server performance monitoring
o Azure server performance monitoring
o Storage area network (SAN) storage analytics
• Log management:
o Universal log collection and analysis
o Virtually unlimited data retention
o A dashboard powered by search queries

• Capacity planning:
o Forecasts of resource utilization trends
o Virtual machine placement optimization
o The identification of storage bottlenecks
• Automation:
o Virtual machine provisioning
o App deployment
o A runbook gallery
o A graphical designer
• Configuration and change tracking:
o Detection of configuration issues
o Identification of deviations from best practices
o Monitoring of software, Windows services, and the registry
o Tracking of group policies and file changes

• Site recovery:
o Automated protection and replication of virtual machines
o Customizable recovery plans

o Support for the replication and recovery of physical and virtual machines
o Orchestrated recovery
• Backup:
o Support for app, server, and data backups, including geo-replication capabilities.
Activity logging and resource monitoring in Azure

In addition to using Log Analytics (OMS), you can
use the following built-in platform capabilities to
monitor administrative operations and resource
status in Azure:
• Activity Log. Azure records all write

operations, which include PUT, POST, and
DELETE actions targeting each Azure
Resource Manager resource in every
subscription. The log provides a variety of
information, including the following:
o The level of the event. For example, it

might be just something to track
(Informational) or something that has gone wrong that you need to know about (Error).
o The status. The final status is typically Succeeded or Failed, but it also might be In Progress for
long-running operations.
o The timestamp of the event.
o The user or service that initiated the operation.
o The Correlation ID of the event. This is the unique identifier of the operation.
You can access the log from the Azure portal by clicking the Activity log entry from the blade of
your subscription, each of its resource groups, or individual resources within each resource group. For
a more thorough analysis, you can also:
o Query events via Azure PowerShell, Azure CLI, or REST API.
o Save events to an Azure Storage account.
o Use Microsoft PowerBI content pack to analyze logs in PowerBI.
o Stream logs to an event hub for ingestion by a non-Microsoft service or custom analytics solution
such as PowerBI.
It is also possible to trigger an email notification or a webhook call in response to a specific event.
When exporting logs into an Azure Storage account or an event hub, you define the scope of
activities and export destination by using Log Profiles. As part of that definition, you can specify such
scope criteria as the Azure regions or event categories. When targeting Azure Storage accounts, you
can also specify retention time beyond the 90 days that applies by default to activity logs.
• Azure Diagnostics. Azure helps collect data representing events and logs generated by components
that individual resources are hosting. You can store such data in an Azure Storage account and use it
for debugging and troubleshooting, measuring performance, monitoring resource usage, analyzing
traffic, capacity planning, and auditing.
Azure Diagnostics capabilities differ depending on the resource type. In the case of Azure virtual
machines, once you enable Azure Diagnostics, you will be able to collect such operating system data
as:
o Microsoft Internet Information Services (IIS) logs. Information about IIS websites.
o Azure Diagnostics infrastructure logs. Information about Azure Diagnostics.
o IIS failed request logs. Information about failed requests to an IIS site or app.
o Windows event logs. Information sent to the Windows event logging system.
o Performance counters. Operating system and custom performance counters.
o Crash dumps. Information about the state of the process in the event of an app crash.
o Custom error logs. Logs that your app or service create.
o .NET EventSource logs. Events generated by your code by using the .NET EventSource class.
Additional Reading: You can further extend the scope of diagnostics and customize its
location by modifying the Azure Diagnostics schema configuration. For more information, refer
to “Azure Diagnostics extension configuration schema versions and history” at
https://aka.ms/misqu2
• Metrics. Metrics represent the status of individual Azure resources on the platform level. The type of
metrics that Azure collects depends primarily on the resource type. For example, in the case of Azure
VMs, metrics include Disk IO, Network IO, and CPU utilization, and they are collected for each VM by
default. The platform collects metrics with one-minute frequency and maintains their history for 30
days. If desired, you can archive metrics in an Azure Storage account for long-term storage. If you
want to analyze them, you can also redirect them to Log Analytics (OMS) or stream them to an event
hub and then route them to Azure Stream Analytics.
• Azure Monitor. This service provides a single interface from which you can view and manage data
available from a variety of sources, including the Activity Log, diagnostics logs, and metrics. It
incorporates the log search functionality across all data sources. It also allows you to configure alerts
in response to specific entries appearing in the Activity Log or changes in metric values. In addition,
Azure Monitor helps with configuring alert notifications, by letting you define action groups. Each
action group consists of up to 10 email addresses, webhooks, and SMS numbers that represent
intended recipients of alert notifications. When defining alerts, you can reference these groups, rather
than specifying the same set of recipients multiple times.
• Application Insights. This service complements infrastructure monitoring by providing developers

with extensible Application Performance Monitoring (APM). Its primary purpose is to facilitate
monitoring of web applications residing at any publicly available location, including Azure, on-
premises locations, internet-facing websites, and non-Microsoft cloud providers.
• Azure Security Center. This security-oriented service actively monitors your Azure resources, detects
any security-related issues or threats, and responds to them through prioritized reports and alerts. It
also provides suggestions about remediating actions and assists you with implementing them. For
example, it might recommend setting up network-level security by using a network-level firewall or a
security appliance. It leverages global threat intelligence, collecting and analyzing data from the
Microsoft Digital Crimes Unit, the Microsoft Security Response Center, and non-Microsoft providers of
security services.
Question: What monitoring solution do you intend to use for your Azure environment?
Lab: Managing Microsoft Azure

Scenario
A. Datum Corporation wants to expand their cloud presence by taking advantage of the benefits of Azure.
Your task is to explore and compare the available IaaS features by using the Azure portal, Windows
PowerShell, and Azure CLI.
Objectives
After completing this lab, you will be able to:
• Use the Azure portals.
• Use Azure Resource Manager features via the Azure portal.
• Use Azure PowerShell.

• Use Azure CLI
Note: The lab steps for this course change frequently due to updates to Microsoft Azure.
Microsoft Learning updates the lab steps frequently, so they are not available in this manual. Your
instructor will provide you with the lab documentation.
Lab Setup
Estimated Time: 50 minutes
Virtual machine: 20533D-MIA-CL1

User name: Student
Password: Pa55w.rd
Before you begin this lab, ensure that you have performed the “Preparing the lab environment for this
module” demonstration tasks at the beginning of this module’s first lesson, and that the setup script is
complete.
Question: Why did you use Azure PowerShell cmdlets that contained Rm in the lab?
Module Review and Takeaways

Real-world Issues and Scenarios
• You can use the Azure module for Windows PowerShell and Azure CLI to create simple and easy-to-
use provisioning scripts that enable you to create complex, cloud-based solutions and infrastructure
components on demand.
Tools
The following table lists the tools that this module references.
Tool Use to Where to find it
The Azure portal Manage Azure Resource Refer to the Azure portal at:
Manager and classic resources https://aka.ms/hi4myh
The Azure classic Manage the few remaining Azure Refer to Microsoft Azure at:
portal classic resources that are not https://aka.ms/r6hw9m
available in the Azure portal
The Azure Manage multiple Azure Refer to: http://aka.ms/V91c9h

Enterprise Portal subscriptions under an Enterprise
Agreement
Azure PowerShell Manage Azure from Windows Install by using either the Microsoft Web
modules PowerShell Platform Installer (on Windows) or
standalone installers, or from the PowerShell
Gallery.
Azure CLI Manage Azure resources from a Install by using the Web Platform Installer
shell interface (on Windows), standalone installers, apt-get
(Bash shell on Windows, Ubuntu, and
Debian), or curl on Mac OS.
2-1
Module 2
Implementing and managing Azure networking
Contents:
Module Overview 2-1
Lesson 1: Overview of Azure networking 2-2
Lesson 2: Implementing and managing virtual networks 2-21

Lab A: Using a deployment template and Azure PowerShell to implement
Azure virtual networks 2-28
Lesson 3: Configuring an Azure virtual network 2-29
Lesson 4: Configuring virtual network connectivity 2-39
Lesson 5: Overview of Azure classic networking 2-58
Lab B: Configuring VNet peering 2-66
Module Overview
Networking is one of the primary building blocks of infrastructure solutions in Microsoft Azure. Therefore,
having a clear understanding of how to configure Azure networking components is an essential part of
practically every IaaS-based deployment. In this module, you will learn how to provision and manage
Azure networking to facilitate connectivity between the compute resources residing in Azure, and to
enable you to connect to them from your on-premises environment.
Objectives
• Plan virtual networks in Azure.
• Implement and manage virtual networks.
• Configure cross-premises connectivity and connectivity between virtual networks in Azure.

• Configure an Azure virtual network.
• Describe Azure classic networking.

2-2 Implementing and managing Azure networking
Lesson 1
Overview of Azure networking
Azure networking components allow customers create and manage virtual private networks in Azure and
securely link them to other virtual networks or their own on-premises networking infrastructure.
Fundamental principles of Azure networking match those applicable to traditional, on-premises networks.
However, there are also several unique networking characteristics specific to Azure that you must take
into account when planning and deploying virtual networks in Azure. In this lesson, you will learn about
similarities and differences between on-premises networks and Azure virtual networks.
Lesson Objectives
• Describe the functionality of Microsoft Azure networking components.
• List features of Azure virtual networks.

• Configure virtual network interfaces of Azure VMs
• Design IP address space and subnet ranges in Azure virtual networks.
• Configure Azure Load Balancer.
• Plan for and implement name resolution in Azure virtual networks.
Demonstration: Preparing the lab environment for the remainder in this

module
Perform the tasks in this demonstration to prepare the lab environment. The Azure services you will use in
the lab will be described in this module while the environment is being configured.
Microsoft account that is not associated with any other Azure subscription. This will eliminate the
possibility of any potential confusion when running setup scripts.
This course relies on custom Azure PowerShell modules including Add-20533DEnvironment to prepare
the lab environment for demos and labs, and Remove-20533DEnvironment to perform clean-up tasks
at the end of the module.
Azure networking components

A major incentive for adopting cloud solutions
such as Azure is the ability to move on-premises
workloads to the cloud. This can save
organizations money and simplify operations by
removing the need to maintain their own server
and network infrastructure. The most
straightforward method of moving such
workloads involves deploying Azure virtual
machines (VMs) and configuring them in the same
manner as their on-premises counterparts.
Because every Azure VM must reside on an Azure
virtual network, you should first consider
implementing all necessary networking components.
Virtual networks
When you deploy computers in your on-premises environment, you typically connect them to a network
to allow them to communicate directly with each other. Azure virtual networks serve the same basic
purpose. By placing a virtual machine on the same virtual network as other virtual machines, you
effectively provide direct IP connectivity between them. You also have the option of connecting different
virtual networks together, if your intention is to provide direct IP connectivity across them. It is also
possible to connect virtual networks in Azure to your on-premises networks, effectively making Azure an
extension of your own datacenter.
Azure virtual networks support TCP, UDP, and Internet Control Message Protocol (ICMP). At the time of
authoring this course, there is no support for broadcasts, multicasts, IP-in-IP encapsulated packets, and
Generic Route Encapsulation (GRE) packets.
Subnets
Every virtual network in Azure consists of one or more subnets. Subnets facilitate segmentation of
networks, providing a means of controlling communication between network resources. Each subnet
contains a range of IP addresses that constitute a subset of the virtual network address space.
Network interface card

VMs use a virtual network interface card (NIC) to attach to a subnet to communicate with other VMs and
other networked resources, such as load balancers or gateways. VMs can have more than one NIC for
different network configurations. The maximum number of NICs you can attach to a VM depends on its
size.
IP addresses
When you connect Azure VMs, Azure load balancers, and application gateways to a virtual network, the
Azure platform will ensure that each of them has a unique IP address, just as servers connected to on-
premises networks do. The Azure platform allocates two types of IP addresses to Azure resources
connected to a virtual network:
• Private IP addresses. A private IP address is mandatory. It is allocated to a NIC of a VM, an internal

load balancer, or an application gateway from the IP address range of the subnet to which they are
connected. This address is used for communication within the same virtual network, across multiple,
connected virtual networks, or with on-premises networks via a virtual private network (VPN) tunnel
or a private connection known as an ExpressRoute.
• Public IP addresses. A public IP address is optional. Public IP addresses allow Azure resources to
become reachable via the internet. To facilitate this, you can assign a public IP address to either the
NIC of an Azure VM or a load balancer in front of that VM.
Note: At the time of authoring this course, Azure virtual networks do not support
connectivity between IPv6 private addresses. They do, however, provide support connectivity via
a public IPv6 address assigned to an internet-facing load balancer.
Virtual network-based DNS

The Domain Name System (DNS) provides resolution of user-friendly fully qualified domain names
(FQDNs), such as www.adatum.com, to the corresponding IP addresses. Azure provides built-in DNS
support as part of the virtual network configuration to support many name resolution scenarios. However,
in some cases, such as cross-premises connectivity, you might need to configure your own custom DNS
system.
Azure DNS
Azure DNS provides hosting of DNS zones, facilitating resolution of internet names by relying on the
global infrastructure that Microsoft owns and manages. Azure DNS uses anycast networking, which
delivers the quickest response to name queries by identifying the closest DNS server that is the authority
for the zone containing that name.
Azure Load Balancer

You can use an Azure Load Balancer to enhance availability and scalability of virtual machines by
configuring them as a load-balanced set. Azure Load Balancer provides functionality similar to hardware
load balancers by eliminating single points of failure (application or hardware), increasing uptime during
planned maintenance or upgrades, and distributing workloads across multiple, identically configured
compute nodes. Azure Load Balancer can handle traffic originating from within the same Azure virtual
network, from any directly connected network, or from the internet. In addition, it provides the network
address translation (NAT) capability, facilitating connections to individual virtual machines in the load-
balanced set.
Azure Application Gateway

Application Gateway provides load-balancing services at the application layer. Application Gateway
supports several more advanced features, including Secure Sockets Layer (SSL) offload, cookie-based
affinity, URL path–based routing, and a web application firewall.
Azure Traffic Manager

Traffic Manager is a DNS-based load-balancing solution available in Azure. Its primary strength is the
ability to load balance between endpoints in different Azure regions, non-Microsoft clouds, or your on-
premises datacenters. You can configure load balancing to support failover or to ensure that users
connect to an endpoint that is closest to their physical location.
Note: Traffic Manager is described in more detail in module 5 of this course.
Network security groups

Network Security Groups (NSGs) are collections of network-level firewalls rules that you can associate with
virtual network subnets. A NSG consists of rules that allow or deny inbound and outbound traffic based
on a combination of IP address prefixes and ports. As a result, you can configure Azure virtual network
isolation as you would with an on-premises perimeter network. If you need more granular control, you
can assign NSGs to individual NICs of Azure VMs.
Routing
Azure implements a default routing configuration that facilitates basic connectivity, including the ability
to reach the internet and to communicate with other resources on the same or directly connected virtual
networks. You can modify this default configuration in two ways:
• User-defined routes involve creating custom static routes with one or more rules altering the default
routing behavior and associating them with virtual network subnets. These rules apply to any traffic
leaving these subnets and targeting IP address ranges that you referenced in your custom routes.
• Border Gateway Protocol (BGP) routes facilitate dynamic route exchange between on-premises
networks and Azure virtual networks in hybrid scenarios.
Forced tunneling
Forced tunneling is a special use case of a user-defined route. You define a default route, which directs all
internet-bound traffic originating from one or more subnets on an Azure virtual network via a connection
to your on-premises network. Forced tunneling is common in scenarios where organizations want to
perform packet inspection and auditing of internet-bound traffic by using their existing on-premises
infrastructure.
Virtual network connectivity

It is possible to allow connectivity to Azure VMs hosted on an Azure virtual network via their private IP
addresses from computers that are not connected directly to the same virtual network. If these computers
reside outside Azure, you can use one of the following methods:
• A point-to-site VPN
• A site-to-site VPN
• Azure ExpressRoute
If these computers reside on another Azure virtual network, you can use one of the following methods:
• VNet peering
• VNet-to-VNet connection
You will learn more about these methods in Lesson 4 of this module, “Configuring virtual network
connectivity.”
Azure virtual network gateway

Scenarios that involve connectivity between virtual networks in different Azure regions or cross-premises
VPN connectivity require the use of a VPN gateway. Similarly, cross-premises connectivity via
ExpressRoute requires the use of an ExpressRoute gateway. Both types of gateways handle routing of
network traffic in and out of the virtual network.
Overview of Azure virtual networks

An Azure virtual network constitutes a logical
boundary defined by a private IP address space
that you designate. You divide this IP address
space into one or more subnets. The process
closely resembles the design process for an on-
premises networks. However, in this case, you do
not have to manage the underlying infrastructure.
Instead, the networking features, such as routing
between subnets on the same virtual network and
to the internet and DNS-based name resolution,
are automatically available. As a result, every
virtual machine can access the internet by default.
Note: You can alter the default routing and name resolution functionality within Azure
virtual networks. You can also control network connectivity by allowing or blocking
communication on the subnet or the VM network–interface level. You will learn more about
these capabilities later in this module.
Each virtual network resides in a specific Azure region (referred to as Location in the Azure portal
interface). The region dictates the location of the Azure VMs that you subsequently deploy into the virtual
network. After you create a virtual network, you cannot change its associated region.
Note: Azure virtual networks cannot span multiple Azure regions.
In addition to choosing the Azure region, you must also specify the scope of the IP addresses that will be
automatically assigned to virtual machines that you deploy into that virtual network. Although the scope
can include public IPv4 ranges, almost all Azure virtual networks use the same set of private IPv4 spaces as
most on-premises network implementations. These IP address spaces are defined by RFC 1918 and
include the following:
• 10.x.x.x
• 172.16.x.x – 172.31.x.x
• 192.168.x.x
Note: You should avoid overlapping address spaces across your Azure virtual networks and
your on-premises networks. Overlapping address spaces will prevent you from connecting these
networks later.
The Azure platform uses the Dynamic Host Configuration Protocol (DHCP) service to allocate IP addresses
from the ranges you assign to virtual network subnets. Each IP address lease has an infinite duration, but
the lease is released if you deallocate (stop) the virtual machine to which the IP address is assigned. To
avoid IP address changes regardless of the state of the virtual machine, you can configure a static private
IP address from the range of IPv4 addresses associated with the virtual network.
Note: A static private IP address in Azure corresponds to a DHCP reservation in the on-
premises networking terms. In on-premises scenarios, assigning a static IP address implies
modifying the configuration of the network interface within the operating system. You must not
use this method with Azure virtual machines because it results in connectivity failures. Instead,
you must modify the properties of the network interface attached to the virtual machine via the
Azure management interface. To do so, use the Azure portal, Azure command line interface (CLI)
command az network nic ip-config update, or the Windows PowerShell cmdlet Set-
AzureRmNetworkInterface.
For an Azure VM to be accessible from the internet, you must associate it with either a static or dynamic
public IP address. To accomplish this, you can assign an IP address directly to a NIC of the Azure VM or to
an internet-facing load balancer in front of that Azure VM. You can configure a load balancer to distribute
inbound traffic from the internet across multiple virtual machines in a load-balanced manner. In addition,
you can configure NAT on the load balancer and redirect incoming traffic on a specific TCP port to an
individual virtual machine behind it. This way you can share the same public IP address across multiple
virtual machines.
A public IP address constitutes a separate object in the Azure Resource Manager deployment model. This
means you can manage it independently of both the load balancer and an Azure VM’s NIC. For example,
you can use the following command to create a public IP address by using the static allocation method:
$publicIP = New-AzureRmPublicIpAddress -Name PublicIP -ResourceGroupName AdatumRG -

Location centralus –AllocationMethod Static -DomainNameLabel loadbalancernrp
Subnets
To assign IP addresses from the IP address space of a virtual network to Azure VMs, you must first create
one or more virtual network subnets. Subnets divide your virtual network into smaller IP ranges so that
the resources organized within these subnets can be logically separated. Each subnet contains a range of
IP addresses that fall within the virtual network address space.
The use of multiple subnets is common when implementing multi-tier applications, with one subnet per
tier. This makes it straightforward to use network security groups to prevent unauthorized
communications between tiers. If each tier resides on a separate subnet, you can assign a dedicated
network security group to each subnet.
Note: You will learn more about network security groups later in this module in Lesson 3,
“Configuring an Azure virtual network,” in the topic, “Configuring network security groups.”
Virtual network–based DNS

Names of resources created in Azure can be resolved by using the Azure-provided DNS service or a
customer-provided DNS server. The Azure-provided DNS service is available by default and is sufficient in
most scenarios. For example, the client DNS resolver on an Azure virtual machine can use the Azure-
provided DNS service to resolve the internet-based names. The same DNS service allows for automatic
name resolution between virtual machines that reside on the same virtual network.
There are, however, situations in which you must implement a custom DNS server. This applies, for
example, when implementing hybrid connectivity between an Azure virtual network and an on-premises
network. Another common scenario involves deploying your own Active Directory domain environment in
Azure. In both cases, you must configure an operating system of each Azure virtual machine to use your
own DNS server. Typically, you accomplish this by modifying the properties of the Azure virtual network.
You can also override the virtual network setting by assigning a DNS server directly to a NIC of a VM. In
either case, you must restart the operating system for the new assignment to take effect. This is different
from the way DHCP operates in on-premises networks, where such changes take place dynamically
following the renewal of a DHCP lease.
Virtual network connectivity

As mentioned in the previous topic, it is possible to allow connectivity to Azure VMs hosted on an Azure
virtual network via their private IP addresses from computers that are not connected directly to the same
virtual network. If these computers reside outside Azure, then you can use one of the following methods:
• A point-to-site VPN that connects individual computers to an Azure virtual network via a Secure
Socket Tunneling Protocol (SSTP) tunnel over the internet.
• A site-to-site VPN that connects an on-premises network to an Azure virtual network via an IPsec
tunnel over the internet.
• Azure ExpressRoute that connects an on-premises network via a private connection. ExpressRoute
provides more predictable performance, offering higher bandwidth and lower latency than VPN
connections.
If these computers reside on another Azure virtual network, you can use one of the following methods:
• VNet peering that connects Azure virtual networks within the same Azure region.
• VNet-to-VNet that connects Azure virtual networks in the same Azure region or in different Azure
regions. Using VNet-to-VNet is similar to a site-to-site VPN. However, in this case, cross-region traffic
doesn’t traverse the internet but is routed over a Microsoft Azure backbone network.
Cross-premises connectivity
Each of the cross-premises connectivity methods has unique benefits and was created for specific
scenarios. However, the methods share the same basic purpose. By creating a cross-premises connection
to an Azure virtual network, you allow users to connect to cloud-based resources the same way that they
connect to local resources.
Point-to-site
Use point-to-site connections when you have up to 128 client computers that you want to connect to an
Azure virtual network. Computers with a point-to-site VPN can use that connection from any location
with internet access. There is no need for dedicated hardware or software. You have the option of
leveraging a VPN client built directly into the Windows operating system. However, you must deploy a
VPN gateway in Azure. The throughput of the VPN gateway determines the available bandwidth, which is
shared by all incoming VPN connections. The throughput varies depending on the VPN gateway stock
keeping unit (SKU), with support of up to 1.25 gigabits per second (Gbps). This type of solution offers a
convenient option for connecting individual computers to one or more Azure virtual networks, without
having to invest into an on-premises VPN infrastructure or a private circuit.
Site-to-site
A site-to-site VPN connects an on-premises network to an Azure virtual network via an IPSec VPN tunnel.
This requires an on-premises VPN infrastructure that routes traffic to and from the Azure virtual network.
For this purpose, you can use either a hardware VPN device or a software-based VPN service such as the
Routing and Remote Access Service (RRAS) running on a Windows server or the Linux-based Openswan.
In addition, you need to modify the on-premises routing configuration to ensure that the traffic targeting
Azure virtual networks reaches its destination.
Use site-to-site connections when you need to connect multiple on-premises network computers to one
or more Azure virtual networks. Note that computers must have a direct connection to the on-premises
network to use site-to-site VPN, which is not the case when you use point-to-site VPN. You can facilitate
both types of connectivity by configuring a virtual network with site-to-site VPN and point-to-site VPN.
However, if you do so, the bandwidth (up to 1.25 Gbps) is shared across all connections.
Site-to-site VPN is common in development, test, and lab environments that rely on connectivity to an
on-premises infrastructure. It is also sufficient when dealing with hybrid production workloads. In this
case, performance is subject to the bandwidth and latency of your on-premises internet connection.
Additional Reading: You can determine the latency to the nearest Azure datacenters by
using “Azure Speed Test” at: https://aka.ms/ywzt2s
It is possible to connect multiple Azure virtual networks and multiple on-premises networks via a
combination of site-to-site VPN, VNet-to-VNet, and VNet peering connections. This effectively allows for
sharing resources residing on the same Azure virtual network across multiple on-premises locations.
ExpressRoute
The ExpressRoute service relies on a private connection between your datacenter and an Azure datacenter
via a non-Microsoft connectivity provider. The connection supports links to multiple Azure virtual
networks (potentially in different Azure regions) via their respective gateways. By eliminating the
dependency on internet connectivity, you can ensure consistent, reliable performance levels. The expected
latency is a few milliseconds and you can increase the maximum bandwidth beyond what the VPN-based
methods offer. As with site-to-site VPN, connectivity via ExpressRoute requires that clients reside on-
premises.
ExpressRoute provides other unique benefits compared to the two VPN-based solutions. With
ExpressRoute, you can directly connect—without crossing the public internet—to most public Azure
services that are not part of Azure virtual networks; Azure Storage or Azure Web apps, for example.
ExpressRoute also supports direct connectivity to Microsoft Office 365 services.
Note: ExpressRoute-based Azure virtual network connectivity relies on the routing

functionality referred to as private peering. Similarly, connectivity to Azure public services and
Microsoft Office 365 relies on public peering and Microsoft peering, respectively.
ExpressRoute offers per-circuit throughput of up to 10 gigabits per second (Gbps), with the per-gateway
throughput of up to 9000 megabits per second (Mbps). These capabilities make ExpressRoute the
preferred choice for enterprise and mission-critical workloads. ExpressRoute also might be worth
considering when implementing an Azure region as a disaster recovery site or as the backup destination
for on-premises systems. Other common scenarios that involve ExpressRoute include hybrid big data and
big compute solutions.
Connectivity between virtual networks

There are two methods to connect two Azure virtual networks directly: VNet-to-VNet and VNet peering.
VNet-to-VNet
To connect virtual networks residing in two different Azure regions, you can establish a VPN tunnel in a
manner equivalent to setting up a Site-to-Site VPN between Azure virtual networks and an on-premises
location.
VNet peering
If two virtual networks reside in the same Azure region, you can connect them directly by leveraging the
VNet peering capability. This allows for direct connectivity between them without having to deploy VPN
gateways, eliminating extra cost and performance impact. At least one of the virtual networks in a peering
arrangement must be an Azure Resource Manager resource; it is not possible to use VNet peering to
connect two classic virtual networks.
Note: Although you can use either VNet peering or VNet-to-VNet connection when
connecting two Azure virtual networks in the same Azure region, we recommend using VNet
peering. This method delivers better performance and does not require provisioning VPN
gateways. In addition, in scenarios where both virtual networks must be accessible from your on-
premises locations, this method supports routing cross-premises traffic via a VPN gateway on a
peered virtual network. This allows you to use a single VPN gateway on one of the virtual
networks instead of both.
Virtual gateways
For connectivity between Azure virtual networks in different regions or between an Azure virtual network
and an on-premises location, you have to provision a virtual gateway on each Azure virtual network.
Characteristics of the gateway depend on a few of factors:
• Gateway type determines supported connectivity type:
o VPN. This type indicates that the gateway supports point-to-site, site-to-site, and VNet-to-VNet.
o ExpressRoute. This type indicates that the gateway supports linking a virtual network to an
ExpressRoute circuit.
A virtual network can contain one VPN gateway of each type, which facilitates using Site-to-Site VPN
as a failback for ExpressRoute.
• VPN device type determines routing capabilities of the VPN gateway along with a number of
additional functional implications (covered in the next paragraph). There are two VPN device types
available:
o Policy-based (formerly known as static). Policy-based VPN devices operate according to local
IPSec policies that you define. The policies determine whether to encrypt and direct traffic that
reaches an IPSec tunnel interface based on the source and target IP address prefixes.
o Route-based (formerly known as dynamic). Route-based VPN devices rely on routes in the local
routing table that you define to deliver traffic to a specific IPSec tunnel interface, which, at that
point, performs encryption and forwards the encrypted network packets. In this case, any traffic
reaching the interface is encrypted automatically and forwarded to the Azure VPN gateway on
the other end of the tunnel.
• The Azure resource SKU determines the capacity and performance characteristics of the gateway. In
addition, its choice might affect the routing capabilities of the VPN gateway. For example, policy-
based gateways are supported only with the Basic SKU.
Azure VPN gateway is available in the following four SKUs:
o Basic SKU offers up to 100 Mbps of throughput and supports both policy-based and route-based
VPN gateways. However, it does not support BGP routing. As a result, it does not allow you to set
up active-active Site-to-Site VPN gateway connections to the same on-premises site. With route-
based VPN gateways, you can establish up to 10 VPN tunnels per VPN gateway to different on-
premises sites and Azure virtual networks.
o VpnGw1 SKU offers up to 500 Mbps of throughput and supports route-based VPN gateways. It
allows you to configure BGP routing with route-based gateway and active-active Site-to-Site VPN
gateway connections to the same on-premises site. It allows you to establish up to 30 VPN
tunnels per VPN gateway to on-premises sites and Azure virtual networks.
o VpnGw2 SKU offers up to 1 Gbps of throughput and supports route-based VPN gateways. It
gateway connections to the same on-premises site. You can establish up to 30 VPN tunnels per
VPN gateway to on-premises sites and Azure virtual networks.
o VpnGw3 SKU offers up to 1.25 Gbps of throughput and supports route-based VPN gateways. It
gateway connections to the same on-premises site. You can establish up to 30 VPN tunnels per
VPN gateway to on-premises sites and Azure virtual networks.
ExpressRoute gateway is available in the following four SKUs:
o Basic SKU offers up to 500 Mbps of throughput. It does not support coexistence of the VPN
gateway on the same virtual network.
o Standard SKU offers up to 1000 Mbps of throughput. It supports coexistence of the VPN gateway
on the same virtual network.
o HighPerformance SKU offers up to 2000 Mbps of throughput. It supports coexistence of the VPN
o UltraPerformance SKU offers up to 9000 Mbps of throughput. It supports coexistence of the VPN
Note: At the time of authoring this course, ExpressRoute Basic SKU is deprecated.
Note: You can increase or decrease the SKU of a VPN gateway between VpnGw1, VpnGw2,
and VpnGw3 as needed. You also can resize the ExpressRoute gateways between the Standard
and High Performance SKUs. To change the remaining types of SKUs, you must recreate the
gateway.
The throughput of ExpressRoute virtual gateway SKUs listed above represents the bandwidth between
your on-premises locations and the virtual network hosting the gateway. An ExpressRoute circuit can
accommodate links to multiple virtual networks. By default, a single circuit supports up to 10 virtual
network links. You can increase the number of virtual network links per circuit by purchasing the
ExpressRoute Premium add-on. At that point, the maximum number of links per circuit depends on the
circuit size, with up to 20 links for the smallest circuit size of 50 Mbps and up to 100 links for the largest
circuit size of 10 Gbps.
Additional Reading: For details regarding the ExpressRoute capacity limits, refer to:
“ExpressRoute FAQ” at: https://aka.ms/fnysfp
The choice of the VPN device type has a number of additional implications:
• Policy-based VPN devices support only a single site-to-site connection. With route-based VPN
devices, that number depends on the Azure VPN gateway SKU, with up to 10 connections in case of
the Basic and Standard SKUs and up to 30 connections in case of the High Performance SKU.
Additional Reading: It is possible to connect multiple policy-based on-premises devices to

a single route-based Azure VPN gateway by leveraging custom IPSec/Internet Key Exchange (IKE)
policies. For more information, refer to: “Connect Azure VPN gateways to multiple on-premises
policy-based VPN devices using PowerShell” at: https://aka.ms/tg19xx
• Policy-based VPN devices do not support point-to-site VPNs. This becomes an important factor if you
want to provide shared access to an Azure virtual network to clients connecting via a site-to-site VPN
and a point-to-site VPN. Effectively, to implement this functionality, you would have to use a route-
based VPN gateway in Azure, which implies having the matching VPN device type on-premises.
• From the encryption standpoint, policy-based VPN devices support the Internet Key Exchange
version 1 (IKEv1), AES256 (Advanced Encryption Standard), and AES128 3DES (Data Encryption
Standard) encryption algorithms, as well as the SHA1(SHA128) (Secure Hash Algorithm) hashing
algorithm. Route-based VPN devices offer support for the IKEv2 and AES256 3DES encryption
algorithm (during IKE Phase 1 setup) as well as both the SHA1(SHA128) and the SHA2(SHA256)
hashing algorithms (again, during IKE Phase 1 setup). They also support perfect forward secrecy
(DH Group1, 2, 5, 14, and 24).
Overview of network interfaces

An Azure VM connects to a subnet of an Azure
virtual network via its NICs, which can number
between one and eight. The Azure platform
requires that you attach at least one NIC to each
VM. This becomes the primary NIC. Any additional
NICs are referred to as secondary NICs. Each NIC
should reside on a different subnet, but they must
all be connected to the same virtual network.
Note: The Azure platform assigns the default

gateway to the primary NIC of an Azure VM. As a
result, by default, that VM’s secondary NICs can
communicate only with resources residing on the same subnet to which they are connected. If
you want to allow traffic to other subnets, you can define a custom routing table within the
operating system of the Azure VM. In addition, you should create user-defined routes that direct
the traffic from those subnets back to the same NIC.
Additional Reading: For more information, refer to: “Create a VM (Classic) with multiple
NICs” at: http://aka.ms/Yseiy5
By default, each NIC receives a single private IP address from the subnet’s range of IP addresses. That IP
address becomes part of the primary IP configuration of the NIC. You can create multiple secondary
configurations with their own IP addresses, up to the limit that the platform imposes. You can provide
direct inbound connectivity from the internet to the same VM by adding one or more public IP addresses
to IP configurations, within the platform-imposed limits. Another way to provide inbound connectivity
from the internet to an Azure VM is by deploying an internet-facing load balancer and adding the VM to
its back-end pool.
Note: At the time of authoring this course, a single NIC has the default limit of 50 private IP
addresses. An internet-facing load balancer has the default limit of 10 public IP addresses. If you
need to increase these limits, contact Azure support.
Azure Resource Manager defines the NIC as a separate networking resource that is associated with a VM.
Each NIC has several properties that allow for customizing its configuration. Some of the most important
properties are:
• virtualmachine. Specifies the current VM that is associated with that NIC.
• macaddress. Presents the media access control (MAC) address for the NIC.
• networksecuritygroup. Provides reference to the network security group resource associated with
the NIC.
• dnsSettings. Provides DNS settings for the NIC.
• ipconfigurations. Contains IP address configurations of the NIC.

IP address configuration is bound to a NIC by using the ipConfigurations child object. You can use the
NewAzureRMNetworkInterface Azure PowerShell cmdlet with the -PublicIpAddress switch or az
network nic create with the –public-ip-address parameter to create a NIC with a public IP address. To
assign a public IP address to an existing NIC, run the Set-AzureRmNetworkInterface Windows
PowerShell cmdlet or the az network nic ip-config update Azure CLI command.
Overview of private IP addresses

Private IP addresses are required for Azure
resources such as VMs, internal load balancers, or
web application gateways. This facilitates
communication within the virtual network, with
resources on any other virtual network connected
to it, and, potentially, with on-premises resources,
if you configured hybrid connectivity.
Azure uses DHCP to assign dynamic and static

private IP addresses. The addresses belong to the
IP address ranges that you allocated when
creating virtual network subnets. The DHCP lease
is infinite, which means that IP addresses remain
allocated as long as the VM is in use. If you place the VM in the stopped (deallocated) state, then the
platform will release its IP address, returning it back to a pool maintained by DHCP. As a result, DHCP
might assign that IP address to another resource on the same subnet. To prevent this situation—for
example, if a VM hosts a DNS service —you can designate its IP address as static. Static private IP
addresses are also needed when you control network access by using a firewall with rules referencing a
source or target IP address.
You can assign a static private IP addresses either during VM creation or at any point afterwards. The
address assignment takes place on the NIC level. You can use for this purpose the Azure portal, Azure
PowerShell, Azure CLI, or an Azure Resource Manager template. Note that setting a static IP address
might trigger a reboot of the operating system within the Azure VM.
The following commands retrieve references to a virtual network and its subnet, and then save these
references in the variables $vnet and $subnet:
$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName AdatumRG -Name AdatumVNet

$subnet = $vnet.Subnets[0].Id
Once you have these references, you can use the New-AzureRmNetworkInterface cmdlet with the
PrivateIpAddress switch to create a NIC with a static private IP address. For example, the following
Windows PowerShell command configures the NIC with the name AdatumNic and the private IP address
192.168.0.10, from the first subnet of the virtual network named AdatumVnet:
$nic = New-AzureRmNetworkInterface -Name AdatumNIC -ResourceGroupName AdatumRG -Location

centralus -SubnetId $vnet.Subnets[0].Id -PrivateIpAddress 192.168.0.10
To add this NIC with a static private IP address during VM creation you use the following Azure
PowerShell cmdlet:
Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
This cmdlet references configuration parameters for the VM stored in the $vm variable, and network-
related configuration parameters for the NIC stored in the $nic variable.
To add a static private IP address to an existing VM you can use the following cmdlet:
Set-AzureRmNetworkInterface -NetworkInterface $nic
To create a new NIC with a static private IP address by using Azure CLI, you would run:
az network nic create \

--resource-group AdatumRG \
--name AdatumNIC \
--location centralus \
--subnet default \
--private-ip-address 192.168.0.10 \
--vnet-name AdatumVNet
Once you created a new NIC, you can attach it to a new VM during its deployment by running the az vm
create command with the –nics switch.
Overview of load balancers

You can use an Azure load balancer to provide
availability and scalability for the VMs that are
part of the load-balanced set. You can load-
balance traffic that targets specific IP addresses
and specific TCP or UDP ports.
There are two types of Azure Load Balancer:

• Internal load balancer. The internal load
balancer enables you to load-balance traffic
from the same virtual network, other directly
connected virtual networks, or an on-
premises location connected via Site-to-Site
VPN or ExpressRoute. You might use internal
load balancers for the following types of connections:
o Between on-premises computers and VMs in a cross-premises virtual network
o Between multi-tier applications with back-end tiers that are not on the internet, but require load-
balanced traffic from the internet-facing tier
• Internet-facing load balancer. The internet-facing load balancer enables you to load balance traffic
from the internet. It also supports NAT, allowing connectivity to a specific Azure VM in a load-
balanced set via a designated port that you configure.
Both load balancers control the flow of traffic targeting an IP address and a port assigned to their front-
end configuration across a set of virtual machines residing within a virtual network. Incoming traffic is
subject to load balancer rules and inbound NAT rules that you define. The outcome of rule processing
determines which virtual machine behind the load balancer becomes the recipient of that traffic.
To configure a load balancer in Azure Resource Manager, provide the following details:
• Front-end IP configuration. Identifies one or more IP addresses that are accepting incoming traffic
that needs to be load balanced.
• Back-end address pool. Designates the virtual machines that receive network traffic from the load
balancer.
• Load-balancing rules. Determine how to distribute incoming traffic across virtual machines in the
back-end address pool.
• Probes. Verify the health and availability of virtual machines in the back-end pool.
• Inbound NAT rules. Determine the types of traffic that should be redirected to individual VMs in the
back-end pool rather than being distributed across the VMs.
You can use the Azure portal, Azure PowerShell, Azure CLI, Azure Resource Manager templates, or REST
API to create a load balancer. For example, to create a virtual network, a virtual network subnet, and an
external load balancer that will balance incoming network traffic on port 443 and provide connectivity on
port 3389 to two back-end VMs, you would use the following procedure:
Create a resource group and virtual network

1. Create a new resource group:
New-AzureRMResourceGroup –Name AdatumRG –Location centralus
2. Create a new virtual network with the name AdatumVnet and an address space, (in this example
192.168.0.0/16) and store a reference to the virtual network in the $vnet variable:
$vnet = New-AzureRMVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVnet –

AddressPrefix 192.168.0.0/16 –Location centralus
3. Add a virtual network subnet:
$backendSubnet = Add-AzureRmVirtualNetworkSubnetConfig -Name AdatumSubnet -

VirtualNetwork $vnet -AddressPrefix 192.168.0.0/24
4. Update the configuration in the virtual network:
Set-AzureRMVirtualNetwork –VirtualNetwork $vnet
Create a Public IP address

• Create an Azure Public IP address (PIP) resource named PublicIP, to be used by a front-end IP pool:
$publicIP = New-AzureRmPublicIpAddress -Name PublicIP -ResourceGroupName AdatumRG -

Location centralus –AllocationMethod Static -DomainNameLabel adatumlb
Create front-end and back-end IP Address Pool

1. Create a front-end IP configuration named LB-Frontend, that uses the Public IP address, and then
store the value in the variable $frontendIP:
$frontendIP = New-AzureRmLoadBalancerFrontendIpConfig -Name LB-Frontend -

PublicIpAddress $publicIP
2. Create a back-end address pool named LB-backend, and then store the value in the variable
$beIPPool:
$beIPPool = New-AzureRmLoadBalancerBackendAddressPoolConfig -Name LB-backend

Create a load-balancer rule, a NAT rules, a probe, and a load balancer

1. Create the NAT rules that will redirect all incoming traffic on port 3441 and 3442 to port 3389 on
back-end VMs:
$inboundNATRule1 = New-AzureRmLoadBalancerInboundNatRuleConfig -Name RDP1 -

FrontendIpConfiguration $frontendIP -Protocol TCP -FrontendPort 3441 -BackendPort
3389
$inboundNATRule2= New-AzureRmLoadBalancerInboundNatRuleConfig -Name RDP2 -
FrontendIpConfiguration $frontendIP -Protocol TCP -FrontendPort 3442 -BackendPort
3389
2. Create a health probe that will check the health status on a page named HealthDemo.aspx:
$healthProbe = New-AzureRmLoadBalancerProbeConfig -Name HealthProbe -RequestPath

'HealthDemo.aspx' -Protocol http -Port 80 -IntervalInSeconds 15 -ProbeCount 2
3. Create the load-balancer rule to balance all incoming traffic on port 443 to the back-end port 443 on
the addresses in the back-end pool:
$lbrule = New-AzureRmLoadBalancerRuleConfig -Name HTTP -FrontendIpConfiguration

$frontendIP -BackendAddressPool $beIPPool -Probe $healthProbe -Protocol Tcp -
FrontendPort 443 -BackendPort 443
4. Create load balancer named AdatumLB that will use previously configured rules:
$lb = New-AzureRmLoadBalancer -ResourceGroupName AdatumRG -Name AdatumLB -Location

centralus -FrontendIpConfiguration $frontendIP -InboundNatRule
$inboundNATRule1,$inboundNATRule2 -LoadBalancingRule $lbrule -BackendAddressPool
$beIPPool -Probe $healthProbe
Create NICs and configure a back-end IP address pool

1. Create NICs:
$backendnic1= New-AzureRmNetworkInterface -ResourceGroupName AdatumRG -Name nic1 -

Location centralus -PrivateIpAddress 192.168.0.11 -Subnet $backendSubnet -
LoadBalancerBackendAddressPool $lb.BackendAddressPools[0] -LoadBalancerInboundNatRule
$lb.InboundNatRules[0]
$backendnic2= New-AzureRmNetworkInterface -ResourceGroupName AdatumRG -Name nic2 -
Location centralus -PrivateIpAddress 192.168.0.12 -Subnet $backendSubnet -
LoadBalancerBackendAddressPool $lb.BackendAddressPools[0] -LoadBalancerInboundNatRule
$lb.InboundNatRules[1]
2. Update the existing NIC configuration with a back-end IP address pool:
$backednic1.IpConfigurations[0].LoadBalancerBackendAddressPool=$beIPPool
$backednic2.IpConfigurations[0].LoadBalancerBackendAddressPool=$beIPPool
Set-AzureRmNetworkInterface –NetworkInterface $backednic1
Set-AzureRmNetworkInterface –NetworkInterface $backednic2
Additional Reading: To use Azure CLI to create an internet-facing balancer, refer to:
“Creating an internet load balancer using the Azure CLI” at: https://aka.ms/mh30m8
Additional Reading: To use the Azure portal to create a load balancer, refer to: “Creating an
internet-facing load balancer using the Azure portal” at: https://aka.ms/pe9pw4
Application Gateway
As mentioned earlier, Application Gateway provides routing and load-balancing services at the application
layer. You can use application gateways in scenarios that require the following features that Azure Load
Balancer does not support:
• SSL offload. After uploading a server certificate and creating a listener on port 443, you can configure
an application gateway with routing rules that terminate an SSL session at the gateway. This
eliminates the need to decrypt incoming traffic on the load-balanced Azure VMs, thereby improving
their performance.
• Cookie-based affinity. An application gateway consistently redirects requests from a given client to
the same Azure VM in the load-balanced set.
• URL-based routing. An application gateway directs incoming requests to different pools of load-
balanced servers depending on the URL path within these requests.
• Web application firewall. The firewall implements a set of customizable rules that protect a load-
balanced set of VMs from common web-based exploits, such as Structured Query Language (SQL)
injection or cross-site scripting.
You can configure an application gateway as internet-facing or run it entirely within an Azure virtual
network. Its endpoints can consist of public IP addresses or Azure internal IP addresses representing Azure
VMs and Azure Cloud Services instances.
Note: At the time of authoring this course, there is no support for static assignment for an
internet-facing application gateway’s public IP address.
Traffic Manager
Traffic Manager is a DNS-based load-balancing solution available in Azure. Rather than redirecting
incoming traffic like Azure Load Balancer or Application Gateway, Traffic Manager relies on customizable
DNS name resolution to ensure that these requests reach the most suitable load-balanced endpoint. That
endpoint represents a web application or service and can reside in any internet-accessible location.
Effectively, it is possible to use Traffic Manager to load-balance across the entire globe, targeting different
Azure regions, other cloud providers, or on-premises datacenters. You can use Traffic Manager’s load-
balancing algorithms to customize load-balancing behavior. For example, you can minimize the response
time by redirecting traffic to the endpoint closest to the request’s origin. Alternatively, you can distribute
incoming requests across multiple endpoints according to custom-defined weight values that you assign
to each endpoint.
Note: Module 5, “Implementing Azure web app services,” will describe Traffic Manager in
more detail.
You can combine load-balancing solutions to leverage their complementary strengths. An example of
such design relies on Traffic Manager to provide global load balancing, with its endpoints representing
internet-facing instances of Application Gateway. In turn, each Application Gateway instance points to
load-balanced sets of Azure VMs behind multiple Azure load balancers, with URL-based routing
distributing the traffic between them.
Overview of Azure DNS

Azure DNS is a managed service that hosts
internet-facing DNS zones to provide name
resolution by using the Microsoft global DNS
infrastructure. Azure DNS implements anycast
networking, which returns the fastest response to
name queries by directing them to the DNS server
closest to their origin. You can designate Azure
DNS servers as authoritative for a new DNS
domain name, or you can add them as
authoritative servers for your existing DNS zones.
Note: At the time of authoring this course,

Azure DNS does not support purchasing and registering new domains. After you register a new
domain with a non-Microsoft registrar, you can use Azure DNS to host it.
In either case, delegation for your zone at your registration authority should include the Azure DNS name
servers that host your DNS zone. Name servers in Azure DNS are allocated automatically from the pool
during zone creation. You can view currently allocated name servers for your zone by running the
following Azure PowerShell cmdlet:
Get-AzureRmDnsRecordSet –Name “@” –RecordType NS –Zone $zone
The $zone variable should reference your Azure DNS-hosted zone.
You can create and manage zones by using the Azure portal, Azure PowerShell, and Azure CLI.
To create an Azure DNS zone by using Azure PowerShell, perform the following steps:
1. After authenticating to your Azure subscription, create a new resource group:
2. Create a DNS zone:
New-AzureRmDnsZone -Name adatum.com -ResourceGroupName AdatumRG
3. Retrieve the SOA and the NS record for the zone:
Get-AzureRmDnsRecordSet -ZoneName adatum.com -ResourceGroupName AdatumRG
Additional Reading: For information regarding using Azure CLI to manage DNS zones, refer
to: “How to manage DNS Zones in Azure DNS using the Azure CLI 2.0” at: https://aka.ms/qbejgi
Additional Reading: For information regarding using the Azure portal to manage DNS
zones, refer to: “How to manage DNS Zones in the Azure portal” at: https://aka.ms/uh0eth
After you create the zone, you can manage all common DNS record types, such as A, AAAA, CNAME, MX,
NS, SOA, SRV and TXT. The following table describes the function of each type of record.
Record type Full name Function
A (IPv4) Address Maps a host name such as www.adatum.com to

AAAA (IPv6) an IP address, such as 131.107.10.10.
CNAME Canonical name Assigns a custom name, such as

ftp.adatum.com, to a host record, such as
host1.adatum.com.
MX Mail exchange Points to the host that accepts email for the
domain. MX records must point to an A record,
and not to a CNAME record.
NS Name server Contains the name of a server hosting a copy of

the DNS zone.
SOA Start of Authority Provides information about the writable copy of

the DNS zone, including its location and version
number.
SRV Service Points to hosts that are providing specific

services, such as the Session Initiation Protocol
(SIP) or Active Directory Domain Services
(AD DS).
TXT Text Contains custom text.
Records in Azure DNS are created as a record set, which is a collection of DNS records with the same name
and same type. Creating a record set that contains resource records with specific values in the Azure DNS
zone is a two-step process:
1. Create a record set by using the command New-AzureDnsRecordSet with the values for record
type, zone name, resource group, and Time-to-Live (TTL). For example, the following commands
create a record set for the relative name www in the zone adatum.com, and with the TTL value of 60
seconds. The output of the command is stored in the variable $AdatumRs:
$AdatumRs = New-AzureRmDnsRecordSet -Name "www" -RecordType "A" -ZoneName

"adatum.com" -ResourceGroupName "AdatumRG" -Ttl 60
2. Add the value (record) to the record set by using the command Add-AzureDnsRecordConfig, which
specifies the record that will be added to the record set. For example, the following command adds
the value 110.15.15.110 to the record set variable $AdatumRs, which contains the www.adatum.com
record that you created in the previous step:
Add-AzureRmDnsRecordConfig -RecordSet $AdatumRs -Ipv4Address 110.15.15.110


Question
You want to implement load balancing across Azure VMs with support for SSL offloading. What
Azure networking component should you use?
Azure internal load balancer
Forced Tunneling
Azure internet-facing load balancer
Azure Application Gateway

Lesson 2
Implementing and managing virtual networks
Azure virtual networks constitute the core component of Azure networking. They represent customer
networks in the cloud. You follow similar principles when designing them as when designing on-premises
networks. Choosing the right address space in the planning stage is critical, especially if you intend to
integrate Azure networks with on-premises networks. In this lesson, you will review how to create virtual
networks, and how to manage them.
Lesson Objectives
• Describe how to plan Azure virtual networks.
• Create and configure virtual networks by using the Azure portal.
• Create and configure virtual networks by using Azure PowerShell.

• Create and configure virtual networks by using Azure CLI.
• Create and configure virtual networks by using deployment templates.
Planning for Azure virtual networks

You control the private IP addresses that are
assigned to VMs and cloud services within an
Azure virtual network by specifying an IP
addressing scheme. Planning an IP addressing
scheme within an Azure virtual network is similar
to planning an on-premises IP addressing scheme.
You often use the same ranges, following the
same set of rules. However, some considerations
are unique to Azure virtual networks.
Selecting private address spaces

As mentioned in the previous lesson, you can use
both private and public IP address spaces for
defining the IP addresses that will be used in Azure virtual networks. RFC 1918 defines three standard
private address spaces:
• 10.0.0.0/8. Includes all addresses from 10.0.0.1 to 10.0.0.255
When you assign an address space for a virtual network, you typically specify a smaller range within one
of the private address spaces. For example, if you specify the address space 10.1.1.0/24, it means that only
addresses from 10.1.1.1 to 10.1.1.255 will be allocated to your virtual network. You can allocate multiple,
non-adjacent IP address spaces to the same virtual network. You can also add one or more IP address
spaces to an existing virtual network, if that virtual network is not part of a VNet peering configuration.
If you plan to connect to another virtual network or an on-premises network, you must ensure that their
IP address spaces do not overlap. Always consider using an IP address space that is not in use in your
organization, whether on-premises or in other virtual networks. Even if you initially plan for an isolated
virtual network, you might need to establish connectivity later. If there is any overlap in address spaces,
you will have to recreate the virtual network.
Note: At the time of authoring this course, most Azure virtual network–related resources—
such as internal load balancers, user-defined routes, or network security groups—are not IPv6-
capable. Azure provides IPv6 support for internet-facing Azure load balancers. For this reason,
any subsequent references to IP imply the use of IPv4, unless explicitly stated otherwise.
Additional Reading: For more information about Azure support for IPv6 in its internet-
facing Azure load balancer, refer to: “Overview of IPv6 for Azure Load Balancer” at:
https://aka.ms/p75q4e
Choosing subnets
To attach Azure VMs to a virtual network, you must configure the network by dividing its IP address space
into one or more subnets. The range you specify for a subnet must be contained entirely within the virtual
network’s address space. Within each subnet, the first three IP addresses and the last IP address are
reserved, and you cannot use them for virtual machines or cloud services. Effectively, the smallest subnet
that you can implement in Azure has the 29-bit subnet mask, which leaves you with three usable IP
addresses.
IP addresses within a subnet are allocated sequentially in the order of provisioning or bringing online
virtual machines on that subnet. For example, the first virtual machine deployed into the subnet
192.168.0.0/24 would, by default, have the IP address of 192.168.0.4. As mentioned earlier, you can
change this behavior by assigning a static IP address to that virtual machine.
Note: It is relatively easy to move Azure virtual machines across subnets within the same
virtual network. However, it is not possible to move a virtual machine across subnets on different
virtual networks. If you must relocate a virtual machine to another virtual network, you have to
delete it while preserving its disks, and then redeploy it to the target network using the existing
disks.
Using the Azure portal to create virtual networks

To create a virtual network in the Azure portal,
perform the following procedure:
1. Sign in into the Azure portal.
2. In the navigation menu on the left, click New,

select Networking, and then click Virtual
network.
3. On the Create virtual network blade, in the

Name text box, type a descriptive name for
the virtual network.
4. In the Address space text box, specify the IP address space by using Classless Interdomain Routing
(CIDR) notation.
5. In the Subnet name text box, type a descriptive name for the first subnet on the virtual network.
6. In the Subnet address range box, choose the IP address range for the subnet by using CIDR
notation.
7. In the Subscription drop-down box, select the Azure subscription in which you want to create a
virtual network.
8. In the Resource group box, either create a new resource group or select an existing one.
9. In the Location drop-down box, select the Azure region in which you want to create a virtual network
and then click Create.
After the virtual network provisioning is complete, you can configure it further by creating additional
subnets or setting up a DNS server address.
To modify virtual network setting in the Azure portal, perform the following procedure:
1. Select your newly created virtual network. On the Virtual network blade, you can configure
additional virtual network properties.
2. Click the Properties link and identify the Resources ID of the virtual network, the Azure region, the
subscription name, and the subscription ID.
3. Click the Address space link and provide additional IP address spaces that you want to include in
that virtual network.
4. To create an additional subnet, click the Subnets link.

5. To add a new subnet, on the Subnets blade, click +Subnet.
6. On the Add Subnet blade, in the Name text box, type a descriptive name. In the Address range
(CIDR block) box, type the IP address range for the subnet by using CIDR notation, and then, to
create the subnet, click OK.
7. To configure DNS server settings for the virtual network, click the DNS servers link.
8. On the DNS servers blade, click Custom. In the Add DNS server text box, type the IP address of your
custom DNS server and then click Save.
9. To modify the Role Based Access Control settings for this resource, click the Access control (IAM)
link.
10. To add a custom tag to the virtual network, click the Tags link.
Note: This topic describes how to create a virtual network in an Azure Resource Manager
deployment model.
Using Azure PowerShell to create virtual networks

You can use the Azure PowerShell module to
create Azure virtual networks. To use Azure
PowerShell module to create a virtual network,
perform the following steps.
1. Start Microsoft Azure PowerShell and sign in

to your subscription:
Login-AzureRmAccount
2. If there are multiple subscriptions associated

with your account, select the target
subscription in which you are going to create
a virtual network:
Select-AzureRmSubscription –SubscriptionName <Name of your subscription>
4. Create a new VNet named AdatumVnet, assign an IP address space (in this example 192.168.0.0/16),
and store a reference to the new virtual network in the $vnet variable:
$vnet = New-AzureRMVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVnet –

5. Add a subnet to the new virtual network:
Add-AzureRmVirtualNetworkSubnetConfig -Name FrontEnd -VirtualNetwork $vnet -

AddressPrefix 192.168.0.0/24
Using Azure CLI to create virtual networks

You can use the Azure CLI to create Azure virtual
networks. To use Azure CLI to create a virtual
network, perform the following steps.
1. Start an Azure CLI session and sign in to your

subscription:
az login
2. If there are multiple subscriptions associated

with your account, select the target
subscription in which you are going to create
a virtual network:
az account set -–subscription <Name of your subscription>

az group create --name AdatumRG --location centralus
4. Create a new VNet named AdatumVnet, assign an IP address space (in this example 192.168.0.0/16),
and add a subnet to the new virtual network:
az network vnet create \

--name AdatumVNet \
--resource-group AdatumRG \
--location centralus \
--address-prefix 192.168.0.0/16 \
--subnet-name FrontEnd \
--subnet-prefix 192.168.0.0/24
Using Azure PowerShell to create a virtual network based on an Azure

Resource Manager template
You can download one of existing Azure Resource
Manager templates for creating a virtual network
from GitHub at https://aka.ms/iih1md. In addition
to the sample templates, you will find there Azure
related APIs, software development kits (SDKs),
and open source projects.
To create a virtual network based on a template,
identify template parameters and specify their
values interactively during a deployment.
Alternatively, you can store these values in a
parameters file that you reference during a
deployment. You can initiate a template-based
deployment by using Azure PowerShell, Azure CLI, Visual Studio, or directly from the Azure portal.
The following describes the procedure of deploying an Azure virtual network by using the Azure
Quickstart template named Virtual Network with two Subnets available from GitHub at
http://aka.ms/Mt32e4:
1. Download the azuredeploy.json file in RAW format, and then open it in any text editor. You should
consider using an editor that supports JSON editing features. Such capabilities are automatically
available in Visual Studio and Visual Studio Code.
2. Identify the parameters to which you will assign custom values during deployment:
o vnetName - the name of the virtual network.
o vnetAddressPrefix - the IP address space of the virtual network in CIDR format.
o subnet1Name - the name of the first subnet.
o subnet1Prefix - the IP address range of the first subnet in CIDR notation.
o subnet2Name - the name of the second subnet.

o subnet2Prefix - the IP address range of the second subnet in CIDR notation.
o location - the Azure region where the virtual network will be created.
3. Check the resources section to identify the resources created in Azure Resource Manager and their
properties, including:
o Type - the resource type Microsoft.Network/virtualNetworks.
o Name - the name of the resource.
o Location - the Azure region where the resource will be created.

4. Download the azuredeploy-parameters.json file in RAW format, and then open it in the text editor.
5. Set the parameters to your custom values and save the changes. For example:
Modify the values for the parameters of the Azure Resource Manager template that you will use for
creation of the virtual network:
Modify the azuredepeploy-parameters.json file

{
"location": {
"value": "Central US"
},
"vnetName": {
"value": "AdatumVNet"
},
"vnetAddressPrefix": {
"value": "10.0.0.0/16"
},
"subnet1Name": {
"value": "FrontEnd"
},
"subnet1Prefix": {
"value": "10.0.0.0/24"
},
"subnet2Name": {
"value": "BackEnd"
},
"subnet2Prefix": {
"value": "10.0.1.0/24"
}
}
6. Start Microsoft Azure PowerShell and sign in to your subscription:
Login-AzureRMAccount
7. If there are multiple subscriptions associated with your user account, select the target subscription in
which you are going to create a virtual network:
Set-AzureRmContext –SubscriptionName <Name of your subscription>
9. Run the New-AzureRmResourceGroupDeployment cmdlet to deploy the new virtual network by

using the template and parameter files that you downloaded and modified:
New-AzureRmResourceGroupDeployment -Name AdatumVNetDeployment `

-ResourceGroupName AdatumRG `
-TemplateFile .\azuredeploy.json `
-TemplateParameterFile .\azuredeploy-parameters.json
Note: Note that you could simplify this particular deployment by clicking Deploy to Azure
on the Virtual Network with two Subnets GitHub page. The procedure described in this topic
illustrates an equivalent approach that you can use with custom templates, which are not
available from GitHub.
Demonstration: Deploying a virtual network by using an Azure Resource

Manager template
In this demonstration, you will see how to implement a VNet by using an Azure Resource Manager
template.

Question
Which Azure components support IPv6 connectivity?
Azure internal load balancer
Azure internet-facing load balancer
Network Security Groups
User-defined routes
Lab A: Using a deployment template and Azure

PowerShell to implement Azure virtual networks
Scenario
A. Datum Corporation plans to create several virtual networks in their Azure subscription. They will all
reside in the same Azure region. You want to test the deployment of Azure virtual networks by using both
imperative and declarative methods.
Objectives
• Create a virtual network by using deployment templates.
• Create a virtual network by using PowerShell.
• Create a virtual network by using Azure CLI.
Lab Setup
User name: Student
Password: Pa55w.rd
Before starting this lab, ensure that you have performed the Preparing the Environment demonstration
tasks at the beginning of the first lesson in this module, and that the setup script has completed.
Question: What are the methods that you can use to create an Azure virtual network?
Lesson 3
Configuring an Azure virtual network
An Azure virtual network has many similarities with on-premises infrastructure. You can control name
resolution by deploying your own DNS server and define routes to control network traffic flow. Network
security groups and support for forced tunneling help you address your organization’s security needs.
Lesson Objectives
• Configure name resolution in an Azure virtual network.
• Configure user-defined routes.

• Configure forced tunneling.
• Configure network security groups.
Configuring name resolution in an Azure virtual network

Name resolution is the process by which a
computer name is resolved to an IP address. It
eliminates the need to reference IP addresses
when accessing remote computers. Azure
automatically provides a DNS-based name
resolution service. This service enables Azure VMs
and cloud services web and worker roles to
communicate via their names. However, some
scenarios might require a custom name resolution.
Each of the following DNS-related scenarios has

specific considerations:
• Classic VMs or role instances in the same
cloud service. VMs can resolve the names of all other VMs in the same cloud service automatically by
using Azure-provided name resolution.
• Azure Resource Manager VMs in the same virtual network. VMs deployed by using Azure Resource
Manager that reside in the same virtual network can use either Azure-provided name resolution or a
custom DNS server.
• Classic VMs in different cloud services but within a single virtual network. These VMs can resolve IP
addresses for each other by using the internal Azure name resolution service and their FQDNs.
Alternatively, you can use a custom DNS system to support this scenario.
• Hybrid connectivity between VMs in a virtual network and on-premises computers. To support this
scenario, you must use a custom DNS server.
• VMs in different virtual networks. To support this scenario, you must use a custom DNS server.
• Reverse lookup of private IP addresses. This scenario requires a custom DNS server.
• Name resolution of private domain names. This scenario requires a custom DNS server.
Note: Providing DNS name resolution in an Active Directory domain environment hosted on
Azure VMs requires a custom DNS server.
Azure-provided name resolution

Azure-provided name resolution does not require any custom configuration and is highly-available by
design. For virtual networks that you deployed in the Azure Resource Manager mode, DNS suffix is the
same across all VMs in the virtual network. This means that it is sufficient to specify host names to resolve
them to the corresponding IP addresses.
Note: For Azure-provided DNS-based name resolution of classic VMs that reside on the
same classic virtual network, you must use FQDNs rather than host names.
Name resolution by using a custom DNS server

If you are planning to use a custom DNS server on an Azure virtual network, you must ensure that all
Azure VMs on that virtual network can reach it to register their names and resolve the names of other
VMs. You can either deploy DNS on a VM in the Azure virtual network or use a DNS server residing
outside Azure. Your DNS server should meet the following requirements:
• Supports dynamic registration of resource records in DNS.

• Has record scavenging switched off. DHCP leases in an Azure virtual network are infinite, so record
scavenging might remove records that have not been renewed but are still valid.
• Has DNS recursion enabled.
• Is accessible on TCP/UDP port 53 from all VMs.
Configuring user-defined routes

Routing in Azure virtual networks is handled
automatically by the underlying virtualization
platform. As a result, all VMs connected to the
same virtual network can, by default,
communicate with each other without requiring
configuration of a default gateway for each VM.
Similarly, each VM, by default, can reach the
internet, any directly connected Azure virtual
networks, and on-premises networks, if you have
implemented hybrid connectivity. Azure
accomplishes this by assigning a set of system
routes to every virtual network subnet that you
create. Those system routes contain the following rules:
• Local virtual network rule. This rule facilitates communication between VMs in the same virtual
network.
• On-premises rule. This rule is created when you configure a hybrid connection from your on-premises
environment. The rule directs outbound traffic targeting your on-premises IP address space via a VPN
gateway.
• Internet rule. This rule represents the default route to the internet via a platform-managed internet
gateway.
Routes rely on the following information to determine how to direct traffic flow:
• Address prefix. Specifies the destination IP address range in CIDR notation.
• Next hop type. Specifies the next network node where the packet will be forwarded. Possible
destinations are:
o Virtual Network. Destination is accessible directly within the same virtual network.
o Virtual Network Gateway. Destination is on another virtual network or an on-premises network,
reachable via a VPN gateway.
o Internet. Destination is on the public internet, reachable via the internet gateway that the Azure
infrastructure manages.
o Virtual Appliance. Destination is accessible via an intermediary virtual machine residing on the
local virtual network.
o None. Destination is not accessible. This configuration is useful for preventing the delivery of
packets targeting a particular IP address space.
• Next hop value. Applies to the Virtual Appliance next hop type and contains the IP address of a
virtual appliance, to which packets should be forwarded. The virtual appliance must reside on a
different subnet than the one to which the route applies. In scenarios that involve VNet peering, this
subnet can reside on the peered virtual network.
Note: You must enable the IP Forwarding setting of the NICs of the Azure VM hosting a
virtual appliance. The platform requires IP Forwarding to allow forwarding of network packets to
a VM when the packets’ destination does not match that VM’s IP address.
You have the option of using these routes to customize the default packet flow. For example, your
network policy might state that all internet-bound traffic should pass through an on-premises system for
auditing and packet inspection. In such a case, you would need to configure user-defined routes that
implement forced tunneling. Similarly, you might need to implement an Azure-resident virtual appliance
for packet inspection.
After you create a user-defined route, you must assign it to one or more subnets. The routes will apply to
traffic leaving these subnets. You can assign a route to the gateway subnet, which contains the virtual
gateway. This way, you can control routing of ingress traffic originating from other virtual or on-premises
networks.
You can use the Azure PowerShell, Azure CLI, or Azure Resource Manager templates to create user-
defined routes and to assign them to virtual network subnets. For example, you want to inspect all traffic
that originates from the FrontEnd subnet and targets the BackEnd subnet in the AdatumVNet virtual
network. To accomplish this, you define a route that directs the relevant traffic from FrontEnd to the
virtual appliance named NVA1, which you will deploy to the NVA subnet on the same virtual network.
The following procedure describes how to use Azure PowerShell to implement this scenario:
1. Start Microsoft Azure PowerShell, and sign in to your subscription:
2. If there are multiple subscriptions associated with your account, select the target subscription in
which you are going to create the virtual network and configure user-defined routes:
Set-AzureRMContext –SubscriptionName <Name of your subscription>

4. Create a new virtual network named AdatumVNet with the address space 192.168.0.0/16 and store
a reference to it in a Windows PowerShell variable $vnet:
$vnet = New-AzureRMVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVNet –

5. Add both subnets to the new virtual network:

Add-AzureRmVirtualNetworkSubnetConfig -Name BackEnd -VirtualNetwork $vnet -
Add-AzureRmVirtualNetworkSubnetConfig -Name NVA -VirtualNetwork $vnet -AddressPrefix
192.168.100.0/24
7. Create a route that will route all the traffic from FrontEnd (192.168.0.0/24) to BackEnd
(192.168.1.0/24) via the virtual appliance (192.168.100.4):
$route1 = New-AzureRmRouteConfig –Name AdatumRoutetoNVA1 `

-AddressPrefix 192.168.1.0/24 -NextHopType VirtualAppliance `
-NextHopIpAddress 192.168.100.4
8. Create a route table named Adatum-RTNVA1 that contains the previously created route:
$routeTable1 = New-AzureRmRouteTable -ResourceGroupName AdatumRG `

-Location centralus -Name Adatum-RTNVA1 -Route $route1
9. Associate the previously created route table with the FrontEnd subnet:
Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name FrontEnd `

-AddressPrefix 192.168.0.0/24 -RouteTable $routeTable1
10. Update the configuration of the virtual network:
11. Use a variable to store settings for the NIC that the virtual appliance uses. The name of the NIC for
this scenario is NICNVA1:
$nicNVA1 = Get-AzureRmNetworkInterface -ResourceGroupName AdatumRG -Name NICNVA1
12. Enable IP forwarding:
$nicNVA1.EnableIPForwarding = 1
13. Update the NIC settings:
Set-AzureRmNetworkInterface –NetworkInterface $nicNVA1

Additional Reading: For the equivalent steps when using Azure CLI, refer to: “Create User-
Defined Routes (UDR) using the Azure CLI 2.0” at: https://aka.ms/ic43ns
Regardless of the provisioning method, after deploying the Azure networking components, you need to
provision NVA1 and configure its routing. The configuration specifics are dependent on which product is
providing the routing functionality. You can use a product available from the Azure Marketplace, or you
can use the operating system routing functionality of a Windows or Linux Azure VM.
Configuring forced tunneling

Many companies enforce packet inspection and
auditing policies for traffic that crosses their
internal network boundary. This creates a
challenge when they extend their networks to
Azure, because VMs that reside on an Azure
virtual network have, by default, a direct route to
the internet.
Forced tunneling redirects internet-bound traffic

back to the company’s on-premises infrastructure.
With forced tunneling, you can selectively choose
virtual network subnets from which the traffic
should be routed back to your on-premises
network. At that point, you can apply the same packet inspection and auditing policies to the redirected
traffic as you apply to the traffic originating from your on-premises networks.
You configure forced tunneling by creating a default route for selected subnets in the virtual network that
directs outbound traffic through the VPN gateway residing within the virtual network. For example, if you
plan to use forced tunneling for the traffic that originates from the subnet BackEnd in the virtual network
AdatumVNet, perform the following steps by using Azure PowerShell:
1. Start Microsoft Azure PowerShell, and then sign in to your subscription:
2. Select the subscription in which you are going to create the virtual network and configure forced
tunneling:
Set-AzureRmContext –SubscriptionName <Name of your subscription>
4. Create a new virtual network named AdatumVNet with the address space 192.168.0.0/16 and store
a reference to it in a Windows PowerShell variable $vnet:

5. Add subnets to the new virtual network:

Add-AzureRmVirtualNetworkSubnetConfig -Name BackEnd -VirtualNetwork $vnet -
6. Add a gateway subnet to the new virtual network:
Add-AzureRmVirtualNetworkSubnetConfig -Name GatewaySubnet -VirtualNetwork $vnet -

8. Create the object representing your on-premises VPN gateway and store a reference to it in the
variable $GW (this example assumes that the gateway IP address is 111.111.111.111 and the on-
premises IP address space is 10.0.0.0/16):
$GW = New-AzureRmLocalNetworkGateway -Name "AdatumLocalGW" -ResourceGroupName

"AdatumRG" -Location "centralus" -GatewayIpAddress "111.111.111.111" -AddressPrefix
"10.0.0.0/16"
9. Create a route that will send all the traffic through the VPN gateway:
$route = New-AzureRmRouteConfig -Name DefaultRoute `

-AddressPrefix 0.0.0.0/0 -NextHopType VirtualNetworkGateway
10. Create a route table named Adatum-FT that contains the previously created route:
$routeTable = New-AzureRmRouteTable -ResourceGroupName AdatumRG -Location centralus `

-Name Adatum-FT -Route $route
11. Associate the route table to the BackEnd subnet:
Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name BackEnd `

-AddressPrefix 192.168.1.0/24 -RouteTable $routeTable
13. Create a public IP address resource in the resource group AdatumRG:
$pip = New-AzureRmPublicIpAddress -Name "GatewayIP" -ResourceGroupName "AdatumRG" -

Location "centralus" -AllocationMethod Dynamic
14. Create the IP configuration of the Gateway Subnet:
$gwsubnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -

VirtualNetwork $vnet
$ipconfig = New-AzureRmVirtualNetworkGatewayIpConfig -Name "gwIpConfig" -SubnetId
$gwsubnet.Id -PublicIpAddressId $pip.Id
15. Create a Gateway named Gateway1, and allocate a dynamic public IP address to AdatumGW. From
the previous steps, you already have stored IP configurations of the gateway subnet in the variable
$ipconfig and IP address of the on-premises local network gateway in the variable $GW:
$Gateway1 = New-AzureRmVirtualNetworkGateway -Name "Gateway1" -ResourceGroupName

"AdatumRG" -Location "centralus" -IpConfigurations $ipconfig -GatewayType Vpn -
VpnType RouteBased -GatewayDefaultSite $GW -EnableBgp $false
16. Establish the site-to-site VPN connection between Gateway1 and local gateway AdatumLocalGW by
using the preshared key:
New-AzureRmVirtualNetworkGatewayConnection -Name "Connection1" -ResourceGroupName

"AdatumRG" -Location "centralus" –VirtualNetworkGateway1 $Gateway1 -
LocalNetworkGateway2 $GW -ConnectionType IPsec -SharedKey "preSharedKey"
Note: The configuration described in this topic applies to forced tunneling in scenarios that
do not involve BGP route exchange. BGP is a method of dynamically exchanging routing
configuration when using ExpressRoute for hybrid connectivity. It is also possible to implement
BGP in combination with route-based VPN gateways.
Additional Reading: For more information regarding using BGP with Azure VPN gateways,
refer to: “Overview of BGP with Azure VPN Gateways” at: https://aka.ms/rsmh1y
Configuring network security groups

Network Security Groups (NSGs) provide network-
based protection for Azure VMs. They allow you
to control inbound and outbound traffic on a NIC
or a subnet level. NSGs contain rules that specify
whether to allow or deny traffic. This
determination depends on up to five different
criteria, including a range of source IP addresses, a
range of source ports, a range of destination IP
addresses, a range of destination ports, and a
protocol. In the Azure portal, configuration of an
NSG rule includes the following properties:
• Name. This is a unique identifier for the rule.
• Direction. Direction specifies whether the traffic is inbound or outbound.
• Priority. If multiple rules match the traffic, rules with higher priority take precedence.
• Access. Access specifies whether the traffic is allowed or denied.
• Source. This identifies from where traffic originates. You can choose from three options for this
property: a range of IP addresses in CIDR notation, the Any setting that denotes all IP addresses, or
the Tag setting designating networks of a particular predefined type.
• Source port range. This specifies source ports by using either a single port number from 1-65535, a
range of ports (200-400), or the asterisk (*) wildcard character that denotes all ports.
• Destination. This identifies the traffic destination. Just like the Source property, it can take the form of
a range of IP addresses in CIDR notation, Any that denotes all IP addresses, or a Tag designating
networks of a particular predefined type.
• Destination port range. This specifies destination ports by using either a single port number from
1-65535, a range of ports (200-400), or the asterisk (*) wildcard character that denotes all ports.
• Protocol. Protocol specifies the network protocol used by the incoming or outgoing traffic. You can
set it to UDP, TCP, or the asterisk (*) wildcard character. The wildcard includes ICMP.
Note: To specify a single IP address as the source or destination of a rule, use the /32 subnet
mask in the CIDR notation.
Note: The Azure portal further simplifies rule configuration by providing you with the Basic
view of each rule’s properties. In the Basic view, you do not specify the source port range; instead
you select a predefined protocol, such as HTTP, HTTPS, FTP, or SSH. If you must specify a custom
port configuration, you can switch to the Advanced view.
There are predefined default rules for inbound and outbound traffic. You cannot delete these rules, but
you can override them because they have the lowest priority. Default rules allow all inbound and
outbound traffic within a virtual network, allow outbound traffic towards the internet, and allow inbound
traffic that Azure load-balancer health probes use to determine the state of load-balanced VMs. There is
also a default rule with the lowest priority in both inbound and outbound sets of rules that denies all
network communication.
As mentioned earlier, when you create a rule, you can use predefined tags as the source and destination
to designate the type of network. This eliminates the need to specify a potentially large number of CIDR
blocks. These default tags are:
• Internet. This tag represents all internet IP addresses, including the Azure public IP address ranges.
• Virtual_network. This tag represents all IP addresses included in the IP address space of the virtual
network. It also includes the IP address space of your on-premises networks or other virtual networks
connected to the local virtual network.
• Azure_loadbalancer. This tag represents all IP addresses from which Azure load balancer health
probes originate.
Planning network security groups

You can design NSGs to implement protected subnets that restrict inbound or outbound traffic to a
specific set of IP addresses. With the Azure Resource Manager deployment model, you also have the
option of assigning NSGs to individual NICs, allowing you to configure different security groups
applicable to a single, multi-NIC VM. With the classic deployment model, you are limited to single security
group per VM, since the security groups are associated in this case with the VM, rather than its individual
NICs.
You can associate the same NSG with multiple subnets and, depending on the deployment model, NICs or
VMs. This might help you avoid reaching the restriction on the number of NSGs. By default, you can
create 100 NSGs per region per subscription. You can raise this limit to 400 by contacting Azure support.
There are additional considerations to take into account when implementing network security groups:
• You can apply only one NSG to a VM, subnet, or NIC.

• By default, you can have up to 200 rules in a single NSG. You can raise this limit to 500 by contacting
Azure support.
Creating network security groups and configuring rules

You can use the Azure portal, Azure PowerShell, Azure CLI, or Azure Resource Manager templates to
create and modify NSGs. In Azure PowerShell, to create a new NSG named Adatum-RG, you use the
New-AzureRMNetworkSecurityGroup command. Azure CLI provides the az network nsg create
command that offers the equivalent functionality. The Azure portal offers a convenient, intuitive interface
for creating new NSGs and customizing existing NSGs. For example, to create a custom rule for an existing
NSG in the Azure portal, you can use the following procedure:
1. In the hub menu of the Azure portal, click More services, and then select Network security groups.
2. From the list in the Network security groups blade, select the NSG that you plan to modify.
3. Click either Inbound security rules or Outbound security rules, depending on the type of rule you
want to modify.
4. In the resulting blade, click Add.
5. In the Add inbound security rule blade or Add outbound security rule blade, depending on your
earlier choice, click Advanced to configure the following properties, and then click OK:
o Name. Use a descriptive name.
o Priority. Specify a value to identify the priority of the rule.
o Source. Select Any, CIDR Block, or Tag.

o Protocol. Select either Any or the TCP or UDP protocol.
o Source port range. Specify either a single port or a range of ports to match the rule.
o Destination. Select Any, CIDR Block, or Tag.
o Destination port range. Specify either a single port or a range of ports to match the rule.
o Action. Specify either the Allow or Deny action for the traffic that matches the properties of the
rule.
Note: You can simplify the configuration of network security rule by selecting the Basic
configuration option, rather than Advanced. This allows you to choose from one of the pre-
defined entries in the Service drop down list, rather than specifying the value of the Protocol
and port ranges.
Demonstration: Configuring network security groups

In this demonstration, you will see how to create a network security group and associate it with a subnet
of a virtual network.

Question
Which of the following scenarios require the use of a custom DNS server to provide name
resolution among all networked computers?
Classic VMs or role instances in the same cloud service
Azure Resource Manager VMs in the same virtual network
Hybrid connection via ExpressRoute
VMs residing in two different virtual networks connected via VNet peering
Reverse lookup of private IP addresses within the same virtual network

Lesson 4
Configuring virtual network connectivity
In many cases, you can think of Azure as an extension of your datacenter in the cloud. However,
extending your existing environment to Azure relies on the ability to provide network connectivity
between your on-premises environment and Azure virtual networks, as well as between Azure virtual
networks. In this lesson, you will learn how to establish such connectivity.
Lesson Objectives
• Describe the options for virtual network connectivity.
• Configure a point-to-site VPN.
• Configure site-to-site VPNs.
• Configure VNet peering.

• Connect virtual networks deployed by using the Azure Resource Manager deployment model.
• Connect classic virtual networks to virtual networks deployed by using the Azure Resource Manager
deployment model.
Azure virtual network connectivity options

As briefly described in the first lesson of this
module, to connect to an Azure virtual network,
you can use one of the following methods:
Point-to-site
A point-to-site VPN employs SSTP to allow direct
connectivity to an Azure virtual network from
individual computers running any of the following
Windows operating systems:
• Windows 7 (32-bit and 64-bit versions).

• Windows 8.1 (32-bit and 64-bit versions).
• Windows Server 2008 R2.
• Windows Server 2012.
• Windows Server 2012 R2.
• Windows Server 2016.
SSTP relies on certificates to authenticate and encrypt connections between clients and the Azure VPN
gateway. You can either use an internal or non-Microsoft certification authority (CA) or generate self-
signed certificates. You need to upload the public key of the root (representing your PKI deployment or a
self-signed one) to Azure and associate it with the target virtual network containing the VPN gateway.
You also must generate client certificates (typically one per user) either by relying on the same CA you
requested the root certificate from or by generating self-signed client certificates that reference the self-
signed root certificate. You install the client certificates with their respective private keys in the private
certificate store on client computers. Effectively, the VPN tunnel relies on the implicit trust between the
client certificates on VPN client computers and the root certificate uploaded to the Azure VPN gateway.
This functionality leverages the VPN client software built into the operating system; however, it also
requires the installation of a VPN software package, which is available in a 32-bit and 64-bit version (the
one you choose should match the version of the operating system). The download link is available directly
from the Azure portal. The package installation configures the built-in VPN client software and creates a
new VPN connection entry on client computers. At that point, users can connect to the Azure virtual
network by simply activating the new connection.
From the Azure infrastructure standpoint, a point-to-site VPN requires a VPN gateway associated with the
target Azure virtual network, just like a site-to-site VPN or ExpressRoute. However, in this case, there is no
need for additional on-premises servers or a private connection. You also need to take into account that
there is extra management overhead involved in certificate management. In particular, you need to issue,
install, and maintain the validity of client certificates. You should also keep track of the computers to
which you deployed client certificates, as well as their users. This allows you to revoke certificates in case a
computer gets compromised or stolen, or when a user leaves your organization.
When configuring a point-to-site VPN, you will need to designate an IP address range for VPN client
computers. As part of the VPN connection process, a VPN client automatically receives an IP address from
this range. At that point, the VPN client software automatically updates the local routing table on the
client computer so that any connection targeting the IP address space of the Azure virtual network is
routed via the VPN connection.
Note: Updates to the local routing tables on the client computer require local Administrator
privileges.
The total bandwidth available for the point-to-site connections depends on the SKU of the VPN gateway:
• Basic. Up to 100 Mbps.

• VpnGw1. Up to 500 Mbps.
• VpnGw2. Up to 1 Gbps.
• VpnGw3. Up to 1.25 Gbps.
All point-to-site VPN clients share that bandwidth, so the user experience depends on the total number of
client computers simultaneously accessing the target virtual network. The VPN gateway enforces the limit
of 128 concurrent connections regardless of the SKU.
Just like with a site-to-site VPN, the cost of a point-to-site VPN is comprised of two main components.
The easiest-to-estimate part represents the hourly cost of virtual machines hosting the VPN gateway. This
depends on its SKU. In addition, there is a charge for outbound data transfers at standard data transfer
rates, which depend on the volume of data and the zone in which Azure datacenter hosting the VPN
gateway resides. There is no cost associated with inbound data transfers.
Site-to-site
Site-to-site VPNs rely either on static routes or BGP-based dynamic routing to direct traffic between on-
premises networks and Azure virtual networks. When using static routes, the Azure platform generates its
local routing table when you create the site-to-site VPN connection based on two pieces of data: the IP
address space that you assigned to the Azure virtual network and the local network, which you define in
the process of setting up the VPN connection. The local network represents the IP address space of your
on-premises networks.
Note: Keep in mind that Azure implements the routing configuration of the Azure virtual
network. For cross-premises connectivity to function, you must also update the on-premises
routing configuration.
Additional Reading: The ability to use BGP in Site-to-Site VPN allows you to implement a
number of previously unsupported scenarios, such as transitive routing between your on-
premises locations and multiple Azure virtual networks as well as multiple tunnels between a
virtual network and an on-premises location with automatic failover between them. For more
information, refer to: “Overview of BGP with Azure VPN Gateways” at: https://aka.ms/rsmh1y
The site-to-site VPN method employs the IPSec protocol with a pre-shared key to provide authentication
between the on-premises VPN gateway and the Azure VPN gateway. The key is an alphanumeric string
between 1 and 128 characters.
From the infrastructure standpoint, in addition to a reliable connection to the internet from your on-
premises network, a site-to-site VPN requires a VPN gateway on each end of the VPN tunnel. On the
Azure side, you provision a VPN gateway as part of creating a site-to-site VPN. For more information
regarding VPN gateway characteristics, refer to the first lesson of this module.
Note: The effective throughput of VPN connections might vary, depending on the
bandwidth of the internet connection and impact of encryption associated with the VPN
functionality.
Details of on-premises site-to-site VPN configuration are device specific. Microsoft offers configuration
instructions for each of the validated VPN devices. Non-validated VPN devices may support site-to-site
VPN, but they require independent testing.
Additional Reading For a list of VPN devices that Microsoft has validated in partnership
with their vendors, and their configuration instructions, refer to: “About VPN devices for Site-to-
Site VPN Gateway connections” at: http://aka.ms/Frtaeb
There are additional considerations regarding your on-premises infrastructure. In particular, if your VPN
gateway resides on the perimeter network behind a firewall, you must ensure that the following types of
traffic are allowed to pass through for both the inbound and outbound directions:
• IP protocol 50.
• UDP port 500.
• UDP port 4500.
Just as with point-to-site VPN, two main components determine the cost of site-to-site VPNs. The easiest-
to-estimate part is the hourly cost of virtual machines hosting the VPN gateway. This depends on its SKU.
In addition, there is a charge for outbound data transfers at standard data transfer rates, which depend on
the volume of data and the zone in which the Azure datacenter that is hosting the VPN gateway resides.
There is also no cost associated with inbound data transfers.
Additional Reading For up-to-date site-to-site VPN pricing information, refer to: “VPN
Gateway Pricing” at: http://aka.ms/Y57p7y
There is a 99.9 percent availability Service Level Agreement (SLA) for each VPN gateway. A number of
non-Microsoft vendors of VPN gateway devices support redundant configurations, which increase the
resiliency of the on-premises endpoint of the VPN tunnel.
ExpressRoute
ExpressRoute delivers private, network-layer connectivity between on-premises networks and Microsoft
Cloud, without crossing the internet, in the form of:
• Private peering. This includes connections to Azure virtual machines and Azure cloud services residing
on Azure virtual networks. You can establish connectivity to multiple Azure virtual networks, with up
to 10 virtual networks with the standard ExpressRoute offering and up to 100 virtual networks with
the ExpressRoute Premium add-on.
• Public peering. This includes connections to Azure services not accessible directly via Azure virtual
networks, such as Azure Storage or Microsoft Azure SQL Database. With public peering, you can
ensure that traffic from on-premises locations to Azure public IP addresses does not cross the
internet. It also delivers predictable performance and latency when connecting to these IP addresses.
• Microsoft peering. This includes connections to the Office 365 and Microsoft Dynamics CRM Online
services.
Each of these peering arrangements constitutes a separate routing domain, but all of them are
provisioned over the same physical connection. You have the option of combining them into the same
routing domain, although the recommendation is to implement private peering between the internal
network and Azure virtual networks, while limiting the scope of public peering and Microsoft peering to
on-premises perimeter networks.
Each peering arrangement allows you to connect to all Azure regions in the same geopolitical region as
the location of the ExpressRoute circuit. You can expand the scope of the connectivity globally by
provisioning the ExpressRoute Premium add-on.
Note: The only Azure services not supported by public peering at the time of authoring of
this course include:
• Content Delivery Network (CDN)
• Visual Studio Team Services load testing
• Microsoft Azure Multi-Factor Authentication
• Azure Traffic Manager
From the provisioning standpoint, besides implementing physical connections, you also need to create
one or more logical ExpressRoute circuits. You can identify each individual circuit based on its service key
(s-key), which takes the form of a globally unique identifier (GUID). A single circuit can support up to
three routing domains (private, public, and Microsoft, as listed above). Each circuit has a specific nominal
bandwidth associated with it, which can range between 50 Mbps and 10 Gbps, shared across the routing
domains. You have the option to increase or decrease the amount of provisioned bandwidth without the
need to re-provision the circuit.
In private peering scenarios, establishing a connection to a target virtual network requires creating a link
between the ExpressRoute circuit and the Azure ExpressRoute gateway attached to that virtual network.
As a result, the effective throughput on a per-virtual network basis depends on the SKU of the gateway:
• Basic. Up to 500 Mbps. It does not support the coexistence of a site-to-site VPN and ExpressRoute.
Note: At the time of authoring this course, ExpressRoute Basic SKU is deprecated.
• Standard. Up to 1,000 Mbps. It supports the coexistence of a site-to-site VPN and ExpressRoute.
• HighPerformance. Up to 2,000 Mbps. It supports the coexistence of a site-to-site VPN and

ExpressRoute.
• UltraPerformance. Up to 9,000 Mbps. It supports the coexistence of a site-to-site VPN and

ExpressRoute.
There are three ExpressRoute connectivity models:

• A co-location in a facility hosting an ExpressRoute exchange provider. This facilitates private routing
to Microsoft Cloud by using either Layer 2 or managed Layer 3 cross-connect with the exchange
provider.
• A Layer 2 or managed Layer 3 connection to an ExpressRoute point-to-point provider.

• An any-to-any network (IPVPN) network, implemented commonly as a Multiprotocol Label Switching
(MPLS) cloud, with a wide area network (WAN) provider handling Layer 3 connectivity to the
Microsoft cloud.
Additional Reading: Because ExpressRoute depends on having access to provider services,

its availability depends on the customer location. For up-to-date information, refer to:
“ExpressRoute partners and peering locations” at: https://aka.ms/imjxgy
ExpressRoute routing is dynamic and relies on Border Gateway Protocol (BGP) route exchange between
the on-premises environment and the Microsoft Cloud. You can advertise up to 4,000 prefixes (up to
10,000 with the ExpressRoute Premium add-in) within the private peering routing domain and up to 200
in the case of public peering and Microsoft peering. The prefixes that you advertise via BGP comprise one
or more autonomous systems. Each autonomous system that relies on BGP route exchange has a
corresponding autonomous system number (ASN). There are two types of ASNs: public and private. A
public ASN is globally unique and supports exchanging routing information with any other autonomous
system on the internet. A private ASN is useful in scenarios that involve route exchange with a single
provider only, which eliminates the requirement of global uniqueness. ExpressRoute requires a public ASN
with all three peering scenarios.
To facilitate routing between your on-premises network and the Microsoft internet routers, you will need
to designate several ranges of IP addresses. Specifics of this configuration depend on the peering
arrangement to some extent, but:
• You must choose a pair of /30 subnets or a /29 subnet for each peering type.
• Each of the two /30 subnets will facilitate a separate BGP session. It is necessary to establish two
sessions to qualify for the ExpressRoute availability SLA.
• With private peering, you can use either private or public IP addresses. With public peering and
Microsoft peering, public IP addresses are mandatory.
Some providers manage routing of ExpressRoute traffic as part of their managed services. Usually,
however, when provisioning ExpressRoute via Layer 2 connectivity providers, routing configuration and
management is the customer’s responsibility.
Additional Reading: For more details, refer to: “ExpressRoute routing requirements” at:
http://aka.ms/Bsrgaw
The cost of ExpressRoute depends primarily on the billing model that you choose when provisioning the
service. At the time of authoring this course, there are three billing models:
• Unlimited data. This set monthly fee covers the service as well as an unlimited amount of data
transfers.
• Metered data. This set monthly fee covers the service. There is an additional charge for outbound
data transfers on a per GB basis. Prices depend on the zone where the Azure region resides.
• ExpressRoute Premium add-in. This service extension provides additional ExpressRoute capabilities
including:
o An increased number of routes that can be advertised in public and private peering scenarios, up
to the 10,000-route limits.
o Global connectivity to Microsoft Cloud from a circuit in a single Azure region.

o An increased number of virtual network links from an individual circuit, up to the 100-link limit.
o The ability to implement Microsoft peering.

When you evaluate the total cost of an ExpressRoute-based solution with private peering configuration,
you should also take into account the cost of ExpressRoute gateways that will provide connectivity to
individual virtual networks. As mentioned earlier, the cost of a gateway depends on its SKU.
From the resiliency standpoint, ExpressRoute circuits support a pair of connections between your network
edge devices and Microsoft edge routers via a redundant infrastructure maintained by a connectivity
provider. You must deploy redundant connections on your end of the circuit to qualify for the 99.9
percent circuit availability SLA. In private peering scenarios, each link to an individual virtual network is a
subject to the 99.9 percent availability SLA applicable to the Azure ExpressRoute gateway.
Additional Reading: For more information on ExpressRoute, refer to: “ExpressRoute

technical overview” at: http://aka.ms/B9yy0v
VNet-to-VNet
As mentioned in the first lesson of this module, it is possible to connect virtual networks residing in two
different Azure regions by establishing a VPN tunnel in the manner equivalent to the one applicable when
setting up a site-to-site VPN between an Azure virtual network and an on-premises location.
This involves provisioning a pair of Azure VPN gateways and establishing an IPSec tunnel with shared key
authentication between them. Depending on the specifics of the provisioning process, it is possible to
configure dynamic routing, with BGP route exchange between the two virtual networks. Note that the
connection between two Azure virtual networks is subject to charges associated with running a pair of
VPN gateways, and their throughput limits its bandwidth.
Additional Reading: Just as with Site-to-Site VPN, the ability to use BGP in VNet-to-VNet
connections allows you to implement several previously unsupported scenarios, such as transitive
routing between multiple Azure virtual networks. For more information, refer to: “Overview of
BGP with Azure VPN Gateways” at: https://aka.ms/rsmh1y
VNet Peering
As briefly mentioned in the first lesson of this module, you can connect two virtual networks residing in
the same Azure region by setting up a VNet peering between them. This implements direct connectivity
without using VPN gateways. As a result, you not only avoid the VPN gateway-related charges but the
resulting latency and bandwidth match performance characteristics of connections within the same virtual
network.
Besides pricing and performance benefits, VNet Peering offers some additional advantages by allowing
routing of traffic via virtual appliances and VPN gateways between the peered virtual networks. In
particular, this involves the following capabilities:
• Service chaining facilitates routing from one of two virtual networks via a virtual appliance located on
the other.
• Gateway transit facilitates routing from one Azure virtual network to your on-premises location via
another Azure virtual network configured with site-to-site VPN or ExpressRoute.
These capabilities allow you to minimize cost and management overhead of your Azure-resident virtual
networking components. Rather than having to provision a separate security appliance on each virtual
network and a dedicated virtual gateway to provide hybrid connectivity, you can create a single hub
virtual network providing these services for all other virtual networks functioning as spokes.
You can establish VNet peering between the two virtual networks if you satisfy the following
requirements:
• Both virtual networks reside in the same region.
• The virtual networks do not have overlapping IP address spaces.

• The virtual networks belong either to the same Azure subscription or to separate Azure subscriptions
that are associated with the same Azure Active Directory tenant.
• At least one of the two networks is an Azure Resource Manager resource. It is not possible to establish
VNet peering between two classic virtual networks.
• Your user account has at least read and write permissions on the Virtual Network peering resource
type scoped to the virtual networks that you want to connect via VNet peering. The built-in Network
Contributor role-based access control (RBAC) role includes these permissions.
• You have not reached the limit on the number of VNet peerings per virtual network. The default limit
is 10. You can increase it to 50 by contacting Azure support.
Note: Gateway transit requires that both virtual networks have been provisioned by using
the Azure Resource Manager deployment model.
VNet peering is nontransitive. This means that if you establish VNet peering between VNet1 and VNet2
and between VNet2 and VNet3, VNet peering capabilities do not apply between VNet1 and VNet3.
However, you can leverage user-defined routes and service chaining to implement custom routing that
will provide transitivity. This allows you to implement multi-level hub and spoke architecture and
overcome the limit on the number of VNet peerings per virtual network.
Additional Reading: For information regarding overcoming VNet peering limits, refer to:
“Implement a hub-spoke network topology in Azure” at: https://aka.ms/cto8hx
Direct connectivity between Classic and Azure Resource Manager resources

You cannot attach classic Azure VMs and cloud service web and worker role instances directly to a virtual
network that you used the Azure Resource Manager deployment model to create. Similarly, you cannot
attach Azure VMs that you used the Azure Resource Manager deployment model to create directly to a
classic virtual network. To allow for direct communication between classic and Azure Resource Manager
resources, you can create a VPNet Peering or VNet-to-VNet connection between a classic virtual network
and an Azure Resource Manager-based virtual network. The choice between the two options depends on
whether the two networks reside in the same Azure region or in two different Azure regions.
Configuring point-to-site VPN connectivity

To set up a point-to-site VPN, you must configure
an IP address space, configure a virtual gateway,
create certificates, and then install a client VPN
package. You can accomplish this by using either
the Azure portal or Azure PowerShell.
Creating a point-to-site connection

The following procedure describes how to use
Azure PowerShell commands to create a point-to-
site virtual network VPN.
Configure a Point-to Site connection for

Azure
1. Start Microsoft Azure PowerShell and sign in to your subscription:
which you are going to create a virtual network, and configure a point-to-site VPN:
Set-AzureRmContext –SubscriptionId <Id of your subscription>
4. Create a new VNet named AdatumVNet with the address space of 192.168.0.0/16 (adjust
accordingly to match the IP address space of your virtual network):
New-AzureRMVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVNet –AddressPrefix

192.168.0.0/16 –Location centralus
5. Store a reference to the virtual network object in a variable:
$vnet = Get-AzureRMVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVNet

6. Add a front-end subnet to the new virtual network:

7. Add the gateway subnet to the new virtual network:

8. Create a variable referencing the gateway virtual network subnet for which you will request a public
IP address:
$subnet = Get-AzureRMVirtualNetworkSubnetConfig –Name “GatewaySubnet” –virtualnetwork

$vnet
9. Request a dynamically assigned IP address:
$pip = New-AzureRMPublicIPAddress –Name AdatumPIP –ResourceGroupName AdatumRG
10. Provide IP configuration that is required for the VPN gateway:
$ipconfig= New-AzureRmVirtualNetworkGatewayIPConfig –Name GWIPConfig –Subnet $subnet

–PublicIPAddress= $pip
Set-AzureRMVirtualNetwork –VirtualNetwork $vnet.
Generate root and client certificates

You need to use certificates to authenticate clients as they connect to the VPN and to encrypt the
connection. You have the option of generating self-signed certificates, although, in a production
environment, you will most likely rely on your PKI infrastructure instead. In this walkthrough, we will use
the first of these options.
Start by generating a self-signed root certificate, next upload it to the Azure portal, reference it when
creating a client certificate, and finally install the client certificate on the client computer. To complete
these tasks, use the following steps:
1. On Windows 10 computers, you can use the New-SelfSignedCertificate cmdlet to run the following
from an elevated Windows PowerShell console:
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `

-Subject "CN=AdatumRootCertificate" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign
Additional Reading: In earlier versions of Windows, you can use the makecert tool
available as part of the Windows 10 Software Development Kit (SDK) by following the directions
available at: “Generate and export certificates for point-to-site connections using MakeCert” at:
https://aka.ms/r9weu9
2. To export the public key of the newly generated certificate, run certmgr.msc. Navigate to the
Certificates – Current User\Personal\Certificates store, right-click the certificate, and then click All
Tasks followed by Export. This will start the Certificate Export Wizard.
3. Use the wizard to export the public key in the Base-64 encoded X.509 (.CER) format. Store it as
C:\cert\AdatumRootCertificate.cer.
4. Run the following sequence of cmdlets to convert the certificate to the proper format and store a
reference to it in a variable:
$certFilePath = "C:\cert\AdatumRootCertificate.cer"
$adatumRootCert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2($certFilePath)
$adatumRootCertBase64 = [System.Convert]::ToBase64String($adatumRootCert.RawData)
$adatumVPNRootCert = New-AzureRmVpnClientRootCertificate `
-Name ‘AdatumRootCertificate’ -PublicCertData $adatumRootCertBase64
5. To generate the client certificate, run the following command from the existing elevated Windows
PowerShell console:
New-SelfSignedCertificate -Type Custom -KeySpec Signature `

-Subject "CN=AdatumClientCertificate" -KeyExportPolicy Exportable `
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation "Cert:\CurrentUser\My" `
-Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")
Configure a virtual gateway

Point-to-site connections require a virtual gateway in the virtual network that routes traffic to client on-
premises computers. You also need to prepare a pool of IP addresses that will be allocated to clients
connecting via point-to-site VPN. In the command below you use for this purpose the "172.16.0.0/24" IP
address range. To create the virtual gateway, type the following command, and then press Enter:
New-AzureRmVirtualNetworkGateway -Name AdatumGateway -ResourceGroupName AdatumRG -Location

centralus -IpConfigurations $ipconfig -GatewayType Vpn -VpnType RouteBased -EnableBgp
$false -GatewaySku VpnGw1 -VpnClientAddressPool "172.16.0.0/24" -VpnClientRootCertificates
$adatumVPNRootCert
Create and install the VPN client configuration package

To connect to the VPN, a user must install a VPN client configuration package on the client computer.
1. To retrieve the URL to download a VPN Client Configuration package, type the following command,
and then press Enter:
Get-AzureRmVpnClientPackage -ResourceGroupName AdatumRG -VirtualNetworkGatewayName

AdatumGateway -ProcessorArchitecture Amd64
2. Copy the URL generated from the previous command, paste in a browser, and then download and
install the package.
Connect to the VPN

Now that you have installed both the client certificate and the VPN client configuration package, you can
connect to the virtual network.
1. Navigate to the list of VPN connections and locate the VPN connection that you created as a result of
the installation of the VPN client configuration package. The name of the VPN connection will be the
same as the name of the virtual network in Azure.
2. Right-click the connection, and then click Connect.
3. Click Continue, and then click Connect.

Additional Reading: For information about setting up point-to-site VPN via the Azure
portal, refer to: “Configure a Point-to-Site connection to a VNet using the Azure portal” at:
https://aka.ms/c3vr2o
Configuring a site-to-site VPN

You can use site-to-site VPN for cross-premises
connectivity between Azure virtual networks and
on-premises networks. You can configure a site-
to-site VPN by using the Azure portal, Azure
PowerShell, Azure CLI, or Azure Resource Manager
templates.
Configuring a site-to site VPN

The following procedure describes how to use
Azure PowerShell to configure a site-to site VPN:
Connect to your Azure subscription

1. Start Microsoft Azure PowerShell and sign in
to your subscription:
which you are going to create the virtual network, and then configure a site-to-site VPN:
Create a virtual network and gateway subnet

2. Create a new VNet named AdatumVNet, assign an address space (in this example 192.168.0.0/16),




Add a local site

• Specify the properties of the on-premises network and store them in the variable $local. You must
provide the following values:
o Name. Provide a descriptive name for the on-premises network.
o GatewayIpAddress. Specify the external IP address of your on-premises VPN device.
o Address Prefix. Specify the IP address space of your on-premises network.
$local = New-AzureRmLocalNetworkGateway -Name LocalSite -ResourceGroupName AdatumRG -

Location centralus -GatewayIpAddress '15.21.115.234' -AddressPrefix '10.0.0.0/24'
Request a public IP address for the Azure VPN gateway, and configure the IP
addressing configuration
$gwpip = New-AzureRmPublicIPAddress –Name AdatumGWPIP –ResourceGroupName AdatumRG –

Location centralus –AllocationMethod Dynamic
2. Create a variable referencing the gateway subnet of the VNet:
$gwsubnet = Get-AzureRmVirtualNetworkSubnetConfig –Name “GatewaySubnet” –

virtualnetwork $vnet
3. Create the IP configuration required for the VPN gateway:
$gwipconfig = New-AzureRmVirtualNetworkGatewayIPConfig –Name GWIPConfig –SubnetId

$gwsubnet.Id –PublicIPAddress $gwpip
Create a virtual gateway

• Create a virtual gateway that will be used for the site-to-site VPN connection, and then store a
reference to it in the variable $gateway. Include the following parameters:
o GatewayType: Specify the gateway type to be VPN
o VpnType: Specify RouteBased VPN type or PolicyBased VPN type. The type must match your on-
premises VPN device.
$gateway = New-AzureRmVirtualNetworkGateway -Name AdatumGateway -ResourceGroupName

AdatumRG -Location centralus -IpConfigurations $gwipconfig -GatewayType Vpn -VpnType
RouteBased –GatewaySku VpnGw1
Configure a VPN device

• A site-to-site VPN requires an on-premises VPN device, which routes traffic from the on-premises
network to the virtual network and receives traffic from the virtual gateway.
Additional Reading: As mentioned earlier, for a list of VPN devices that Microsoft has
validated in partnership with their vendors, and their configuration instructions, refer to: “About
VPN devices for Site-to-Site VPN Gateway connections” at: http://aka.ms/Frtaeb
Create a VPN connection

• Create the VPN connection (named here localtoazure) between the on-premises VPN gateway and
the virtual network gateway that you created in your Azure virtual network. You need to provide the
same shared key during on-premises VPN gateway configuration:
New-AzureRmVirtualNetworkGatewayConnection -Name localtoazure -ResourceGroupName

AdatumRG -Location centralus -VirtualNetworkGateway1 $gateway -LocalNetworkGateway2
$local -ConnectionType IPsec -RoutingWeight 10 -SharedKey 'abc123'
Verify the VPN connection

• Use the following command to verify the VPM connection:
Get-AzureRmVirtualNetworkGatewayConnection -Name localtoazure -ResourceGroupName

AdatumRG -Debug
Additional Reading: For information about setting up point-to-site VPN via Azure CLI, refer
to: “Create a virtual network with a Site-to-Site VPN connection using CLI” at:
https://aka.ms/wym5yd
Configuring a VNet-to-VNet VPN

You can use a VNet-to-VNet VPN to connect
virtual networks in two different Azure regions.
They also can be in the same Azure subscription
or different subscriptions. You can configure a
site-to-site VPN by using the Azure portal, Azure
PowerShell, Azure CLI, or Azure Resource Manager
templates.
Configuring a VNet-to-VNet VPN connection is

similar to a site-to-site VPN connection with one
difference: the other side of the connection is not
an on-premises network, but another Azure virtual
network. The following procedure outlines the
high-level steps for creating a VNet-to-VNet VPN connection:
1. Connect to your Azure subscription.
2. Create the first virtual network.
3. Request a public IP address, and create the gateway configuration.
4. Create the gateway.
5. Create the second virtual network and its gateway.
6. Connect the gateways.
Creating a VNet-to-VNet VPN connection

The following procedure lists the steps to use Azure PowerShell to create a VNet-to-VNet VPN
connection.
Connect to Your subscription from Azure PowerShell

1. Start Microsoft Azure PowerShell and sign in to your Azure subscription:
Create a virtual network and gateway subnet

New-AzureRmResourceGroup –Name AdatumRG –Location centralus
2. Create a new VNet named AdatumVNet, assign an address space (in this example 192.168.0.0/16),
$vnet = New-AzureRmVirtualNetwork –ResourceGroupName AdatumRG –Name AdatumVNet –



Set-AzureRmVirtualNetwork –VirtualNetwork $vnet
Request a public IP address for the Azure VPN gateway, and configure the IP
addressing configuration
$gwpip1 = New-AzureRmPublicIPAddress –Name AdatumGWPIP –ResourceGroupName AdatumRG –

Location centralus –AllocationMethod Dynamic
2. Create a variable referencing the gateway subnet of the virtual network:
$gwsubnet1= Get-AzureRmVirtualNetworkSubnetConfig –Name “GatewaySubnet” –

virtualnetwork $vnet
3. Provide the IP configuration required for the VPN gateway:
$gwipconfig1= New-AzureRmVirtualNetworkGatewayIPConfig –Name GWIPConfig –SubnetId

$gwsubnet1.Id –PublicIPAddressId $gwpip1.Id
Create a virtual gateway

• Create a virtual gateway that will be used for site-to-site VPN connection and store a reference to it in
the variable $vnetgw1. You need to specify:
o GatewayType. Define the gateway type as VPN.
o VpnType. Configure RouteBased VPN type.
$vnetgw1 = New-AzureRmVirtualNetworkGateway -Name AdatumGateway -ResourceGroupName

AdatumRG -Location centralus -IpConfigurations $gwipconfig1 -GatewayType Vpn -VpnType
RouteBased –GatewaySku VpnGw1
Create a second virtual network

• Follow the same procedure as described above, to create a second virtual network and its VPN
gateway (which we will refer to here as $vnetgw2).
Connect the VPN gateways

• Create connections to enable communications from both networks, by using the same shared key:
New-AzureRmVirtualNetworkGatewayConnection -Name conn1 -ResourceGroupName AdatumRG -

VirtualNetworkGateway1 $vnetgw1 -VirtualNetworkGateway2 $vnetgw2 -Location centralus
-ConnectionType Vnet2Vnet -SharedKey 'abc123'
New-AzureRmVirtualNetworkGatewayConnection -Name conn2 -ResourceGroupName AdatumRG -
VirtualNetworkGateway1 $vnetgw2 -VirtualNetworkGateway2 $vnetgw1 -Location westus -
ConnectionType Vnet2Vnet -SharedKey 'abc123'
Additional Reading: For information about setting up site-to-site VPN via Azure CLI, refer
to: “Create a virtual network with a Site-to-Site VPN connection using CLI “ at:
https://aka.ms/wym5yd
Configuring VNet peering

You can use VNet peering to connect virtual
networks in the same Azure region. The virtual
networks can be in the same Azure subscription or
in different subscriptions. VNet peering also allows
you to connect two virtual networks created by
using different deployment models.
You can configure VNet peering by using the

Azure portal, Azure PowerShell, Azure CLI, or
Azure Resource Manager templates. The following
procedure outlines the high-level steps for
creating a VNet peering connection between two
Azure Resource Manager–based virtual networks
in the same Azure subscription:
1. Connect to your Azure subscription.
2. Create the first virtual network.
3. Create the second virtual network.
4. Configure VNet peering in the first virtual network.
5. Configure VNet peering with the same settings in the second virtual network.
Creating a VNet-to-VNet VPN connection

The following procedure outlines the steps to use the Azure portal to create a VNet-to-VNet VPN
connection.
Connect to your Azure subscription

1. Start Microsoft Azure PowerShell and sign in to your Azure subscription:
Create the first virtual network

New-AzureRmResourceGroup –Name AdatumRG1 –Location centralus
2. Create a new VNet named AdatumVNet1, assign an address space (in this example 192.168.0.0/24),
$vnet1 = New-AzureRmVirtualNetwork –ResourceGroupName AdatumRG1 –Name AdatumVNet1 –

Add-AzureRmVirtualNetworkSubnetConfig -Name FrontEnd -VirtualNetwork $vnet1 -

Set-AzureRmVirtualNetwork –VirtualNetwork $vnet1
Create the second virtual network

New-AzureRmResourceGroup –Name AdatumRG2 –Location centralus
2. Create a new VNet named AdatumVNet2, assign an address space (in this example 192.168.1.0/24),
and store a reference to the new virtual network in the $vnet2 variable:
$vnet2 = New-AzureRmVirtualNetwork –ResourceGroupName AdatumRG2 –Name AdatumVNet2 –

Add-AzureRmVirtualNetworkSubnetConfig -Name FrontEnd -VirtualNetwork $vnet2 -

Set-AzureRmVirtualNetwork –VirtualNetwork $vnet2

Configure VNet peering in the first virtual network

• Create VNet peering from the first virtual network to the second network:
Add-AzureRmVirtualNetworkPeering `
-Name 'AdatumVnet1ToVnet2' `
-VirtualNetwork $vnet1 `
-RemoteVirtualNetworkId $vnet2.Id
Configure VNet peering in the second virtual network

• Create VNet peering from the second virtual network to the first network:
Add-AzureRmVirtualNetworkPeering `
-Name 'AdatumVnet2ToVnet1' `
-VirtualNetwork $vnet2 `
-RemoteVirtualNetworkId $vnet1.Id
Verify the VNet peering status

• To verify the status of the peering operation, run:
Get-AzureRmVirtualNetworkPeering `
-ResourceGroupName AdatumRG1 `
-VirtualNetworkName AdatumVnet1
followed by:
Get-AzureRmVirtualNetworkPeering `
-ResourceGroupName AdatumRG2 `
-VirtualNetworkName AdatumVnet2
The output of both commands should include Connected as the value of the PeeringState property.
Additional Reading: For information about setting up VNet peering via the Azure portal
and Azure CLI, refer to: “Create a virtual network peering - Resource Manager, same subscription“
at: https://aka.ms/e9b8g6
Connecting classic and Azure Resource Manager-based virtual networks in

different Azure regions
As mentioned earlier in this module, to allow
direct connectivity between classic and Azure
Resource Manager resources residing in different
Azure regions, you must create a VPN connection
between the classic virtual network and the Azure
Resource Manager virtual network.
Connecting a classic virtual network and

an Azure Resource Manager virtual
network
The following procedure lists the steps to create
an Azure Resource Manager–based virtual
network, a classic virtual network, and a VPN
connection between the two by using the Azure portal and Azure PowerShell.
Create a virtual network by using Azure Resource Manager

1. Sign in into Azure portal.
2. In the hub menu on the left, click New, select Networking, and then click Virtual Network.
3. In the Virtual Network blade, verify that the Resource Manager deployment model is selected, and
then click Create.
4. In the Create virtual network blade, in the Name text box, type a descriptive name for the virtual
network—for example, VNetARM.
5. In the Address space text box, type the IP address space by using CIDR notation, for example,
192.168.0.0/16.
7. In the Subnet address range text box, specify the IP address range for the subnet by using CIDR
notation.
8. In the Subscription drop-down list box, select the Azure subscription in which you want to create a
virtual network.
9. In the Resource group text box, either create a new resource group or select an existing one.
10. In the Location drop-down list box, select a location near your users, and then click Create.
Create a virtual network with the Azure classic deployment model

1. In the Azure portal, in the hub menu on the left, click New, select Networking, and then click Virtual
Network.
2. In the Virtual Network blade, select Classic deployment model, and then click Create.
3. In the Create virtual network blade, in the Name text box, type a descriptive name for the virtual
network, for example, VNetClassic.
4. In the Address space drop-down list box, select the IP address range by using CIDR notation, for
example, 172.16.0.0/16.
6. In the Subnet address range text box, choose the IP address range for the subnet using CIDR
notation.
7. In the Subscription drop-down list, select the Azure subscription in which you want to create a
virtual network.
8. In the Resource group section, either create a new resource group or select an existing one.
9. In the Location drop-down list box, select a location near your users, and then click Create.
Connect the classic and the Azure Resource Manager virtual networks
1. To connect two virtual networks that use different deployment models, assign the IP address range of
one virtual network to the local network in the other virtual network. You need do this for both
virtual networks.
2. Create VPN gateways for both virtual networks.
3. Configure both gateways. For an Azure Resource Manager gateway configuration, follow the
procedure described in the earlier topic, Configuring VNet-to-VNet VPN connection, For classic
virtual network, the procedure for creating a VPN gateway is explained in the next Lesson, Overview
of Azure classic networking.
4. Create a pair of PowerShell variables representing the classic VNet gateway and the Azure Resource
Manager VNet gateway (we will call them here $vnet01gateway and $vnet02gateway,
respectively). To create a connection between the gateways, use the following command:
New-AzureRmVirtualNetworkGatewayConnection -Name arm-classic-s2s-connection `

-ResourceGroupName AdatumRG -Location centralus -VirtualNetworkGateway1
$vnet01gateway `
-LocalNetworkGateway2 $vnet02gateway -ConnectionType IPsec `
-RoutingWeight 10 -SharedKey 'abc123'

Question
What is the throughput of High Performance SKU of ExpressRoute gateway?
200 Mbps
500 Mbps
1000 Mbps
2000 Mbps
9000 Mbps
Lesson 5
Overview of Azure classic networking
In this lesson, you will learn about classic virtual networks and identify how they differ from virtual
networks created by using the Azure Resource Manager deployment model.
Lesson Objectives
• Identify the features of classic virtual networks.
• Describe how to implement classic virtual networks.
• Explain how to connect to classic virtual networks.
Overview of classic virtual networks
Virtual networks in Azure classic

deployment model
Most of the core virtual networking principles
described in this module apply to both Azure
Resource Manager and the Azure classic
deployment models. However, there are also
some important differences between them. The
primary one is a dependency on cloud services,
which serve as containers for Azure classic virtual
machines. Cloud services do not exist in the Azure
Resource Manager deployment model.
The Azure classic deployment model defines three types of IP addresses that are used in Azure
networking:
• Dynamic IP (DIP) address. A DIP address is a dynamic internal IP address. VMs in the virtual network
use this address to communicate with other VMs in the same virtual network. When you have
connected a VPN to an Azure virtual network, on-premises clients use DIPs tp communicate with
virtual network VMs. DIPs are equivalent to the private IP addresses in the Azure Resource Manager
deployment model.
• Virtual IP (VIP) address. A VIP address is a virtual IP address that is assigned to a cloud service. This IP
address is a public internet IP address, and external clients use it to communicate with the cloud
service and its VMs. All VMs within a single cloud service have the same VIP address.
• Instance-level public IP (ILPIP) address. An ILPIP address is associated directly with the VM, and
enables direct communication with a VM from the internet without relying on VIP address.
In the Azure classic deployment model, you have the option of creating VMs without connecting them to
virtual networks. However, each VM must belong to a cloud service. You can create each VM in a separate
cloud service, or you can add two or more VMs to a single cloud service. VMs in the same IaaS cloud
service can communicate directly. VMs in different IaaS cloud services which are not part of the same
virtual network can communicate via public endpoints of their cloud services. Each endpoint represents a
combination of the VIP of the cloud service and a TCP port. VMs connected to the same virtual network
can communicate directly, even if they are in different cloud services.
IP addressing in virtual networks

VMs and PaaS cloud service roles in a single virtual network require a unique private IP address (DIPs).
Azure uses the DHCP protocol to assign DIPs. DHCP leases are infinite in duration. However, if you place a
VM in the Stopped (Deallocated) state, a DIP might change once you bring the VM back online.
You can configure the DIP as static to ensure that a VM retains the same one. To accomplish this, start
by verifying that the IP address that you want to reserve is not already in use and then run the Set-
AzureStaticVNetIP cmdlet as in the following example:
Setting a Static Internal IP Address

#Test the IP address for availability
Test-AzureStaticVNetIP -VnetName AdatumHQ -IPAddress 192.168.1.10
#Assign the IP address

Get-AzureVM -ServiceName AdatumWebFrontEnd -Name WebVM1 | Set-AzureStaticVNetIP -
IPAddress 192.168.1.10 | Update-AzureVM
Similarly, you also can use a reserved IP to ensure that the VIP address for a cloud service and the VMs it
contains never changes. To create a reserved IP, run the New-AzureReservedIP cmdlet:
Adding a Reserved IP for a New VM

$ReservedIP = New-AzureReservedIP -ReservedIPName "WebFrontEndIP" -Label "WebFrontEndIP"
-Location "West US"
New-AzureVMConfig -Name "WebFrontEndVM1" -InstanceSize Small -ImageName $imageName | Add-

AzureProvisioningConfig -Windows -AdminUsername Administrator -Password Pa55w.rd | New-
AzureVM -ServiceName "WebFrontEnd" -ReservedIPName $ReservedIP -Location "West US"
Most of the time, you can rely on VIPs to communicate with VMs in an IaaS cloud service via its endpoints.
However, in some cases, you might want to enable external clients to communicate directly with a specific
VM in a cloud service without restricting the communication to a specific port. For example, if you are
using File Transfer Protocol (FTP) in passive mode, the client negotiates the port number to use for
transferring files. In such cases, you should assign an instance-level PIP to the VM.
In this example, the script assigns a PIP to an Azure classic VM:
Assigning an Instance-Level PIP to a VM

Get-AzureVM -ServiceName FTPService -Name FTPVM1 | Set-AzurePublicIP -PublicIPName ftpip
| Update-AzureVM
You also can configure multiple NICs for Azure VMs. In this case, each NIC receives a separate DIP.
Additional Reading: For more information, refer to: “Create a VM with multiple NICs” at:
http://aka.ms/Oqb3ci
Cloud service-based load balancing and internal load balancer

External clients can use a VIP address to communicate with a VM residing within a cloud service. To
accomplish this, you define a unique endpoint mapping to a specific port on the target VMs within the
cloud service. This endpoint is associated with a single VM.
You can also configure an endpoint to represent a custom port on a set of VMs to implement load
balancing across multiple VMs in the same cloud service. In this configuration, multiple VMs share a single
endpoint. As a result, cloud service distributes incoming traffic across those VMs in a load-balanced
manner.
Now consider a scenario where one or more VMs in a virtual network communicate with other VMs in the
same virtual network. For example, a web server might need to access a group of middle-tier servers. You
can use the cloud-service based load balancer in this scenario; however, this would direct the traffic via an
external endpoint. To avoid this, you can implement the internal load balancer (ILB). The internal load
balancer supports traffic distribution between VMs in the same cloud service or within the same virtual
network, without relying on external endpoints.
Implementing a classic virtual network

To create a classic virtual network, you either can
use the classic Azure portal, the Azure portal, or
upload a network configuration file in the XML
format via Azure PowerShell or Azure CLI.
To create an Azure classic virtual network in the

classic portal, perform following the following
steps:
1. In the navigation pane on the left, click

NETWORKS.
2. In the toolbar at the bottom, click NEW, and
then click CUSTOM CREATE.
3. In the Name text box, type a descriptive name for the virtual network.
4. In the Location drop-down list box, select a location near your users, and then click the Next arrow
icon.
5. Under DNS SERVERS, type the name and IP address of the DNS server or servers that VMs on the
virtual network will use. If you want to use Azure internal name resolution, leave this value blank.
6. Click the Next arrow icon.
7. On the Virtual Network Address Spaces page, add the private address spaces and subnets that you
have planned, and then click Complete.
The Azure virtual network configuration is defined in an XML file called a network configuration file. The
network configuration file can include the following settings:
• The name and location of the virtual network
• DNS servers for the virtual network
• IP address spaces of the virtual network
• Subnets within the IP address spaces
• The IP address of the virtual gateway that provides VPN connectivity

The following is an example of an XML network configuration file for a virtual network that includes DNS
servers:
Sample Network Configuration File

<NetworkConfiguration
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://schemas.microsoft.com/ServiceHosting/2011/07/NetworkConfiguration"
<VirtualNetworkConfiguration>
<Dns>
<DnsServers>
<DnsServer name="dns1.adatum.local" IPAddress="192.168.5.1" />
<DnsServer name="dns2.adatum.local" IPAddress="192.168.6.1" />
</DnsServers>
</Dns>
<VirtualNetworkSites>
<VirtualNetworkSite name="AdatumEurope" Location="North Europe">
<AddressSpace>
<AddressPrefix>10.0.0.0/8</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="AdatumEurope">
</Subnet>
<Subnet name="AdatumEuSub2">
</Subnet>
</Subnets>
<DnsServersRef>
<DnsServerRef name="dns1.adatum.local" />
<DnsServerRef name="dns2.adatum.local" />
</DnsServersRef>
</VirtualNetworkSite>
</VirtualNetworkSites>
</VirtualNetworkConfiguration>
</NetworkConfiguration>
In the classic portal, you can download the network configuration file by clicking Export in the toolbar on
the DASHBOARD page. You also can download the file by using the Get-AzureVNetConfig Azure
PowerShell cmdlet. You can make changes to this file and then apply them by uploading the
configuration file with the Set-AzureVNetConfig cmdlet.
The following PowerShell commands export a networking configuration from Azure and then import a
different configuration file:
Exporting and Importing a Network Configuration

#Export the old configuration
Get-AzureVNetConfig -ConfigurationPath C:\backups\OldConfig.xml
#Import the new configuration

Set-AzureVNetConfig -ConfigurationPath C:\configs\UpdatedConfig.xml
Connecting to classic virtual networks

The Azure classic deployment model supports the
following virtual network connectivity options:
• Point-to-site VPN
• Site-to-site VPN
• VNet-to-VNet
• ExpressRoute
You can also configure a VNet Peering between a
classic virtual network and an Azure Resource
Manager-based virtual network. It is not possible
to configure VNet Peering between two Azure
classic virtual networks.
Creating a point-to-site VPN connection

To set up a point-to-site VPN connection, you must configure a VPN client IP address space, configure a
virtual gateway, create certificates, and then install a client VPN package.
Use the following steps to create a point-to-site VPN connection.
Configure an IP address space for clients

When creating a point-to-site VPN connection, start by specifying a range of IP addresses that will be
assigned to clients that connect via VPN. The range must not overlap the existing subnets of the virtual
network or any other range used for Site-to-site or VNet-to-VNet connections. The Azure classic portal
displays a warning if there is such an overlap:
1. In the Azure classic portal, in the navigation bar on the left, click NETWORKS.
2. In the list of available virtual networks, click the name of the virtual network that you want to
configure.
3. Click the CONFIGURE tab.

4. Under point-to-site connectivity, select Configure point-to-site connectivity.
5. In the address space table, select the starting IP address and a CIDR notation subnet mask to specify
and address range. All clients that connect to this point-to-site VPN will receive an IP address from
this range.
6. In the toolbar at the bottom, click SAVE, and then click YES.
Configure a virtual gateway

Point-to-site connections require a virtual gateway in the virtual network that routes traffic to on-
premises client computers. To create the virtual gateway:
1. On the Configuration page, click DASHBOARD.
2. In the toolbar at the bottom, click CREATE GATEWAY, and then click YES.
Note: The gateway creation process can take up to 30 minutes.

Create root and client certificates

You need to use certificates to authenticate clients as they connect to the VPN and to encrypt the
connection. Start by generating a self-signed root certificate, next upload it to the Azure classic portal,
reference it when creating a client certificate, and finally install the client certificate on the client
computer. To complete these tasks, use the following steps:
1. For Windows 10 computers, install the Windows 10 SDK, start the Command Prompt, and change
the current directory to the location where the makecert tool is installed. The default installation
location is C:\Program Files (x86)\Windows Kits\10\bin\X64.
2. To generate the root certificate, type the following command at the command prompt, and then
press Enter:
makecert -sky exchange -r -n "CN=AdatumRootCertificate" -pe -a sha1 -len 2048 -ss My

"AdatumRootCertificate.cer"
3. In the Azure classic portal, in the navigation pane on the left, click NETWORKS.
4. In the list of available virtual networks, click the virtual network that you want to configure, and then
click CERTIFICATES.
5. Click UPLOAD A ROOT CERTIFICATE.
6. Click BROWSE FOR FILE, locate and select the certificate that you generated, and then click Open.
7. Click Complete.
8. At the command prompt, type the following command, and then press Enter:
makecert.exe -n "CN=AdatumClientCertificate" -pe -sky exchange -m 96 -ss My -in

"AdatumRootCertificate" -is my -a sha1
Create and Install the VPN client configuration package

To connect to the VPN, you must install the VPN client configuration package:
1. In the classic portal, click the DASHBOARD tab for the virtual network.
2. Under quick glance, click the VPN package for the appropriate client operating system.
3. Save the configuration .exe file.
4. On the client computer, double-click the configuration file that you just downloaded. If the User
Control dialog box displays, click Yes.
Connect to the VPN

Now that you have installed both the client certificate and the VPN client configuration package, you can
connect to the virtual network.
1. Navigate to the list of available VPN connections, and then locate the VPN connection that you have
created. The name of the VPN connection will be the same as the name of the virtual network in
Azure.
2. Right-click the connection, and then click Connect.
3. Click Continue, and then click Connect.

Configuring a new virtual network and a site-to-site VPN

To configure a new virtual network and a site-to-site VPN, follow these steps:
1. In the classic portal, create a new virtual network.
2. On the Virtual Network Details page, specify the following values:
o Name. Choose a descriptive, unique name.

o Location. Choose the Azure region that is closest to your user base.
3. On the DNS Servers and VPN Connectivity page, specify the following values:
o DNS Servers. Specify the DNS server name and IP address that VMs in the Virtual Network will
use for name resolution.
o Configure Site-to-Site VPN. Ensure that this is selected.
o Local Network. Select or create a local network.

4. On the Site-to-Site Connectivity page, specify the properties of the on-premises network. You must
specify the following values:
o Name. Provide a descriptive name for the local network.

o VPN Device IP Address. Specify the external IP address of your VPN device.
o Address Space. Specify all the IP addresses that are to be found in your on-premises network.
5. On the Virtual Network Address Spaces page, type the IP address spaces and subnets. You must
include a gateway subnet. The virtual gateway will be added to this subnet when you create it.
6. When the virtual network creation is complete, click the DASHBOARD tab.
7. In the toolbar at the bottom, click CREATE GATEWAY, and then click Dynamic Routing.
8. Click Yes.
Configuring the VPN device

A Site-to-Site VPN requires an on-premises VPN device, which routes traffic from the on-premises
network to the virtual network, and receives traffic from the virtual gateway. To configure this device, you
must provide the following information:
1. The IP address of the virtual gateway in the virtual network. This IP address will display on the virtual
network’s Dashboard page.
2. The shared key. This key is used to encrypt the VPN. You can obtain the shared key from the classic
portal by clicking MANAGE KEY on the command bar.
3. The VPN configuration script template. You can obtain the script from the classic portal by clicking
Download VPN Device Script in the quick glance section.

Question
Which of the following statements apply to the Azure classic deployment model only? (Select all
correct answers.)
You can deploy a VM without attaching it to a virtual network
Every VM is part of a cloud service
You can connect to a set of VMs via an internal load balancer
You can ensure that the IP address of a VM does not change even if you place it in stopped
(deallocated) state.
You can connect to a VM via a public IP address.

Lab B: Configuring VNet peering

Scenario
Now that A. Datum Corporation has deployed Azure Resource Manager VNets, the company wants to be
able to provide direct connectivity between them. Your plan is to implement VNet peering to provide the
optimal performance with minimum cost.
Objectives
After completing this lab, you should be able:
• Connect Azure virtual networks using VNet peering.
• Configure VNet peering-based service chaining.
• Validate virtual network connectivity using Azure-based and VM-based tools.
Lab Setup
User name: Student

Password: Pa55w.rd
Before you begin this lab, ensure that you have completed the first lab in this module: Creating virtual
networks.
Question: What do you consider to be the most important advantages of VNet peering?

Review Question
Question: What are the considerations for choosing a name resolution solution for an Azure
virtual network–based deployment?
Best Practice
1. Use Azure Resource Manager templates to simplify virtual network provisioning.
2. Consider optimizing network throughput, especially on Azure VM sizes that include Accelerated
Networking features, by enabling Receive Side Scaling (RSS). For details, refer to: “Optimize network
throughput for Azure virtual machines” at: https://aka.ms/udj3xg
Common Issues and Troubleshooting Tips

Common Issue Troubleshooting Tip
Typical issues can include:

• Site-to-site VPN tunnel failed
• Wrong virtual network configuration
Misconfigured user-defined routes in an

Azure virtual network
Misconfigured network security groups in

an Azure virtual network
3-1
Module 3
Implementing virtual machines
Contents:
Module Overview 3-1
Lesson 1: Overview of Azure VMs 3-2
Lesson 2: Planning deployment of Azure VMs 3-7
Lesson 3: Deploying Azure VMs 3-18

Lab A: Deploying Azure VMs 3-30
Lesson 4: Overview of classic VMs 3-31
Lab B: Deploying Azure VMs by using Azure Resource Manager templates 3-34
Module Overview
Virtual machines (VMs) are the most flexible resources available for deploying your workloads in Microsoft
Azure. You can use Azure VMs to host custom services and applications, implement infrastructure roles, or
serve as a target for lift-and-shift migrations to the cloud. This module introduces the core capabilities of
Azure VMs and presents different ways in which you can provision them.
Objectives
• Describe the main characteristics of Azure VMs.
• Plan for Azure VM deployments.
• Deploy Azure VMs.

• Describe the main characteristics of Azure classic VMs.
3-2 Implementing virtual machines
Lesson 1
Overview of Azure VMs
VMs provide many advantages over physical computers. You can create VMs on physical servers in your IT
environment, or you can create VMs in Azure. In this lesson, you will learn about the differences between
these computing models. You will also learn about the differences between Azure VMs, depending on
their deployment models.
Lesson Objectives
• Use the lab environment.
• Describe Azure VMs.
• Identify differences between classic and Azure Resource Manager VMs.

module
configured while you progress through this module, learning about the Azure services that you will use in
the lab.
This course relies on custom Azure PowerShell modules, including:
• Add-20533DEnvironment to prepare the lab environment for demonstrations and labs.
• Remove-20533DEnvironment to perform clean-up tasks at the end of the module.
What are Azure VMs?

Azure VMs are an infrastructure as a service (IaaS)
compute service offering available in Azure. When
compared with other compute services, Azure
VMs provide the greatest degree of control over
the configuration of the virtual machine and its
operating system. You can configure the
operating system running within a VM by using
Virtual Machine Extensions (VM Extensions),
including methods such as custom Windows
PowerShell scripts, Desired State Configuration
(DSC), Chef, or Puppet.
Azure VMs share most of their characteristics with the Microsoft Hyper-V VMs you deploy in your on-
premises datacenter. However, several important differences exist between them, such as:
• Azure VMs that you can provision are available in specific sizes. You cannot specify arbitrary
processing, memory, or storage parameters when deploying a virtual machine. Instead, you must
select one of the predefined choices. At the time of writing this course, Microsoft offers virtual
machines in two tiers: Basic and Standard. The Basic tier, intended for development and test
workloads, includes five virtual machine sizes, ranging from 1 core with 0.75 gigabytes (GB) of RAM to
8 cores with 14 GB of RAM. The Standard tier has several series, including A, Av2, D, Dv2, Dv3, DS,
DSv2, DSv3, Ev3, ESv3, F, Fs, G, GS, Ms, NV, and NC, for a total of more than 90 virtual machine sizes.
The largest features 128 virtual central processing units (vCPUs), 2048 GB of RAM, and up to 64 disks.
• There is a 4-terabyte (TB) size limit on a virtual disk that you attach to an Azure VM. This does not
imply a limit on the size of data volumes. You can create multiple-disk volumes by using Storage
Spaces in Windows Server or volume managers in Linux. You can create volumes of up to 264 TB by
using this approach. The maximum volume size depends on the size of the virtual machine, which
determines the maximum number of disks you can attach to that virtual machine.
• A limit also exists on the throughput and input/output operations per second (IOPS) that individual
disks support. With Standard storage, you should expect about 60 megabytes per second (MBps) or
500 8-kilobyte (KB) IOPS. With Azure Premium storage, performance depends on the disk size, with
4-TB disks supporting up to 250 MBps and 7,500 256-KB IOPS. You can increase the overall
throughput and IOPS of Azure VMs by creating multiple-disk volumes.
• At the time of writing this course, any virtual disks that you intend to attach to Azure VMs must be in
the .vhd format. There is also no support for Generation 2 Hyper-V virtual machines in Azure.
Additionally, no support exists for dynamically expanding or differencing virtual disks—they all must
be fixed.
Azure VMs, like other cloud-based services, are inherently more agile than on-premises virtual machines.
You can provision and scale them on an as-needed basis, without investing in dedicated hardware. This
makes Azure VMs the most suitable solution in scenarios that must accommodate dynamically changing
workloads. The ease of provisioning and deprovisioning makes Azure VMs ideal for proof-of-concept or
development scenarios, where the need for compute resources is temporary.
In each of these scenarios, you also benefit from the pricing model applicable to Azure VMs. When you
run Azure VMs, you pay for the compute time on a per-minute basis. The price for VMs is calculated
based on their size, the operating system, and any licensed software installed on the VM. A running virtual
machine requires allocation of Azure compute resources. Therefore, to avoid the corresponding charges
whenever you are not using it, you should change its state to Stopped (Deallocated).
Comparing classic and Azure Resource Manager VMs

As described earlier in this course, the choice
of the deployment model determines the
characteristics of the Azure components that you
deploy. The Azure classic deployment model was
originally referred to as the Service Management
model. Introduced in 2009, this model served as
the primary method of deploying and managing
Azure services until the introduction of Azure
Resource Manager.
You can provision Azure VMs by using either the

classic or the Azure Resource Manager
deployment model. Although we recommend
exclusive use of Azure Resource Manager for any future deployments, there might be scenarios where
using the classic deployment model is still necessary.
In comparison to the classic deployment model, the capabilities of Azure Resource Manager offer
significant changes to the implementation and management of Azure VMs, including:
• Support for large scale and parallel deployment of Azure VMs.

• Support for up to three fault domains in an availability set. Each fault domain consists of an
independent set of hardware components, corresponding roughly to a separate datacenter rack. By
enforcing placement of virtual machines in different fault domains, you can provide an additional
level of resiliency. The classic deployment model supports two fault domains in an availability set.
• Integration of the Azure Key Vault with Azure VMs to help secure secret information such as
administrative passwords. Azure Key Vault also facilitates platform-based encryption of VM disks.
• An application programming interface (API) that optimizes creation and configuration of network
resources such as network interfaces, load balancers, and virtual networks. These resources are not
dependent on Azure VMs, and you can reuse them in the deployment process for other Azure VMs.
Azure Resource Manager introduces a new approach to creating and managing IaaS resources. The
following table identifies the primary differences between the classic model and the Azure Resource
Manager model.
Item Classic Azure Resource Manager
Management The classic model uses an Azure Resource Manager handles virtual
model Azure cloud service as a machine resources as independent objects
container for virtual that you can attach to each other. For
machine resources. You example, a virtual network adapter is a
must deploy a virtual separate entity that you use to attach an
machine and its resources Azure VM to a virtual network. You can
into a cloud service. manage these resources individually, or as
logical units, in resource groups. Resource
groups are the primary logical container
used for both the initial deployment and
management of a group of Azure resources.
Azure Cloud A cloud service is a Cloud Services do not exist.

Services mandatory container for
virtual machines and
associated objects.
Availability To implement high Availability sets also are available in Azure

sets availability, you must place Resource Manager. There is support for up
two or more virtual to three fault domains per availability set
machines into the same containing Azure VMs.
availability set. Virtual
machines that you assign to
the same availability set are
automatically placed into
different fault and upgrade
domains. There are two
fault domains per
availability set.
Affinity You have can use affinity Affinity groups do not exist.
groups groups to affect placement
of compute and storage
resources in physical
proximity to each other.
Load The Cloud Service container The load balancer is an independent

balancing provides load-balancing resource. You can attach a network adapter
functionality. of an Azure VM to a load balancer.
Virtual IP The platform automatically You can add a public IP address to a

address (VIP) assigns a VIP to each cloud network adapter of an Azure VM or a load
service upon its creation. balancer.
This address is associated
with the cloud service load
balancer.
Reserved IP You can reserve an IP Static public IP addresses provide the same
address address in Azure, and then capability as reserved IP addresses.
associate it with a cloud
service.
Public IP You can assign public IP You can assign public IP addresses to a
address per addresses to a virtual network interface, which you can then
virtual machine directly. assign to an Azure VM.
machine
Endpoints You can allow inbound You can allow inbound connectivity to an
connectivity from the Azure VM by configuring network address
Internet by configuring translation (NAT) rules on a load balancer
input endpoints for the associated with that VM. Alternatively, you
cloud service in which the can also assign a public IP directly to the
virtual machines reside. network adapter attached to the VM.
Alternatively, you can
assign a public IP address
directly to a virtual
machine.
DNS name Each cloud service must You have the option of assigning a
have a globally unique regionally unique DNS name to the public
Domain Name System IP address of a VM. The fully qualified
(DNS) name, such as: domain name (FQDN) includes the Azure
region, such as:
adatumvm1.cloudapp.net
adatumvm1.eastus.cloudapp.azure.com
Network You define the primary and Network interfaces are independent
interfaces secondary network resources. However, each network interface
interfaces when you is directly associated with the virtual
configure a virtual machine. machine to which it is attached.
Creation and You can use the classic You can use the Azure portal, Azure
management portal, the Azure portal, Resource Manager templates, Azure
Azure PowerShell, Azure PowerShell, Azure CLI 2.0, or the Azure
Command-Line Interface Resource Manager API.
(Azure CLI 1.0), or the Azure
Service Management API.
Question: What are the primary differences between classic and Azure Resource Manager
virtual machines?
Lesson 2
Planning deployment of Azure VMs
There are multiple reasons for deploying Azure VMs. For example, you might be implementing a new
cloud-based application or moving an existing on-premises workload to Azure. This lesson introduces you
to the key considerations for implementing Azure VMs and provides information to help you evaluate
whether a workload is suitable for Azure VMs.
Lesson Objectives
• Identify the workloads for Azure VMs.
• Describe the considerations for Azure VM sizing.
• Describe the considerations for Azure VM availability.
• Describe Azure VM storage options.

• Explain the primary benefits of managed disks.
• Create an availability set.
Identifying workloads for Azure VMs

The following types of workloads can benefit
significantly from the scalability, resiliency, and
agility of Azure VMs:
• Periodic workloads, such as:
o A complex data analysis of sales figures

that an organization needs to run at the
end of each month.
o Seasonal marketing campaigns on an

organization’s website.
o Annual retail sales spurts that might

occur during festive holidays.
• Unpredictable-growth workloads, such as those resulting from an organization’s rapid expansion or
from short-term increases in sales of fad products.
• Spiking workloads, such as those experienced by websites that provide news services or by branch
offices that perform end-of-day reporting for a main office.
• Workloads that require high availability and multiregion resiliency, such as commercial online stores.
• Steady workload scenarios where the operational costs in Azure are lower than the combination of
on-premises capital expenditures and maintenance overhead.
On the other hand, some workloads might not be suitable for Azure VMs. One example is low-volume or
limited-growth workloads that can run on premises on commodity hardware. Other scenarios might
require a highly regulated environment—for example, where a local government restricts the type of data
that organizations or companies can host in the cloud. In such situations, you might consider
implementing a hybrid solution, with workloads split between Azure and an on-premises environment.
Operating system support for Azure VMs

Azure VMs support all the currently supported versions of the Windows Server operating system. A
custom support agreement (CSA) is necessary to obtain support for operating systems that have reached
their end of support. Azure VMs also support a variety of Linux distributions, including CentOS, CoreOS,
Debian, Oracle Linux, Red Hat, SUSE, openSUSE, and Ubuntu.
Software support for Azure IaaS virtual machines

Azure VMs support a wide range of Microsoft server software, including:
• Microsoft BizTalk Server 2013 and newer
• Microsoft Dynamics AX 2012 R3 and newer
• Microsoft Dynamics CRM 2013 and newer
• Microsoft Dynamics GP 2013 and newer
• Microsoft Exchange 2013 and newer
• Microsoft Forefront Identity Manager (FIM) 2010 R2 with Service Pack 1 (SP1) and newer
• Microsoft Identity Manager (MIM)

• Microsoft HPC Pack 2012 and newer
• Microsoft Project Server 2013 and newer
• Microsoft SharePoint Server 2010 and newer
• Microsoft SQL Server 2008 (64-bit) and newer
• Microsoft System Center 2012 SP1 and newer (with the exception of System Center Virtual Machine
Manager)
• Microsoft Team Foundation Server 2012 and newer
The following table shows the Windows Server roles that Azure VMs do and do not support.
Supported Windows Server roles Unsupported server roles
• Active Directory Domain Services (AD DS) • Dynamic Host Configuration Protocol (DHCP)
Server
• Active Directory Federation Services
• Remote Access (Direct Access)
• Active Directory Lightweight Directory Services
• Rights Management Services (RMS)
• Application Server
• Windows Deployment Services (Windows DS)
• DNS Server
• Failover Clustering
• File Services
• Hyper-V (VM series–dependent)
• Network Policy and Access Services
• Print and Document Services
• Remote Access (Web Application Proxy)
• Remote Desktop Services
• Web Server (Internet Information Services)
• Windows Server Update Services
Note: At the time of authoring this course, the Hyper-V role is available on the Dv3 and Ev3
series of Azure VMs, which support nested virtualization.
At the time of this writing, Azure VMs also do not support several Windows Server features:
• Microsoft iSNS Server
• Multipath I/O (MPIO)
• Network Load Balancing (NLB)
• Peer Name Resolution Protocol (PNRP)
• Simple Network Management Protocol (SNMP) service
• Storage Manager for storage area networks (SANs)
• Windows Internet Name Service (WINS)
• Wireless local area network (LAN) service
Virtual machine sizing

Deploying virtual machines in Azure is different
from deploying them in an on-premises Hyper-V
environment. When you manage the hypervisor
platform, you can configure all VM settings any
way you like. In Azure, you select from a range of
predefined configuration options that correspond
to different VM sizes. The VM size determines
characteristics such as the number and speed of
its processors, amount of memory, maximum
number of network adapters or data disks you can
attach to it, and maximum size of a temporary
disk.
Note: An Azure VM’s temporary disk resides on the Hyper-V host where the VM runs. Its
operating system and data disks reside in
Azure Storage.
Note: The significant range of VM sizes can satisfy the requirements of most environments.
At any point, you also can switch between different configurations, if your current configuration
does not violate the constraints of the desired configuration. For example, you might need to
remove an extra virtual network adapter or a data disk attached to your VM before you scale it
down to a smaller size.
Note: Changing the size of a VM requires that you restart it.
In addition to size, the performance and capabilities of a VM also depend on its tier. There are two tiers of
Azure VMs—Basic and Standard. You can choose the Basic tier VMs for any nonproduction workloads that
do not require features such as load balancing, autoscaling, or high availability, and for which you can
tolerate disk I/O in the range of 300 IOPS per disk. Note that the Basic tier VMs do not qualify for any
Service Level Agreements pertaining to availability. On the other hand, the prices of the Basic tier VMs are
lower when compared to the Standard tier VMs. There are only a few VM sizes in the Basic tier–A0 to A4.
A Basic_A0 VM is the smallest in this category. It offers a single central processing unit (CPU) core, 768 MB
of memory, and a single data disk. The largest VM in the Basic tier is the Basic A4 VM with 8 CPU cores, 14
GB of memory, and up to 16 data disks.
Note: Most VMs in Azure are part of the Standard tier offering. The remainder of this topic
will focus on the Standard VM sizes.
Several Standard VM sizes support high-end storage and provide performance that is equivalent to that
of solid-state drives (SSDs). This type of storage is referred to as Microsoft Azure Premium storage. You
can easily distinguish these VM sizes because they include the letter S in the VM size designation. All VM
sizes support Standard storage, which offers performance equivalent to magnetic disks. On the Standard
tier VMs, Standard storage delivers 500 IOPS per disk. On the Basic tier VMs, Standard storage delivers
300 IOPS per disk.
Note: For details regarding Premium storage, refer to Module 6, “Planning and
implementing storage, backup, and recovery services.”
VM sizes in Azure
A combination of one or more letters and numbers represents each VM size. The leading letter (or, in
some cases, letters and a digit) designates a collection of VM sizes referred to as VM series that share
common configuration characteristics such as:
• CPU type
• CPU-to-memory ratio
• Support for SSD-based temporary disks

• Support for Premium storage
Each series includes multiple VM sizes, which differ in the number of CPU cores, amount of memory, size
of the local temporary disk, and the maximum number of network adapters and data disks. For VM sizes
that support Premium storage, an additional difference is the maximum aggregate disk I/O performance.
VM sizes are grouped into the following categories:

• General purpose. This category offers a balanced CPU-to-memory ratio, making it most suitable for
test, proof-of-concept, and development environments. In addition, this category is suitable for
hosting small to medium databases or web servers. This category includes A0-A7, Av2, D, Dv2, Dv3,
DS, DSv2, and DSv3 series VM sizes.
• Compute optimized. This category offers a high CPU-to-memory ratio, making it most suitable for
compute-intensive workloads that do not have extensive memory requirements. Such characteristics
are typical for medium-size traffic web servers or application servers, network appliances, or servers
handling batch processing. This category includes Fs and F series VM sizes.
• Memory optimized. This category offers a high memory-to-CPU ratio, making it most suitable for
memory-intensive workloads that do not have extensive compute requirements. Such characteristics
are typical for workloads that keep the bulk of their operational content in memory, such as database
or caching servers. This category includes D, Dv2, DS, DSv2, Ev3, Esv3, Ms, G, and GS series VM sizes.
• Storage optimized. This category offers high-performance disk I/O, most suitable for big data
processing with both SQL and non-SQL database management systems. This category consists of the
Ls VM sizes.
• GPU. This category offers Graphic Processing Unit support, with thousands of CPU cores, ideal for
implementing workloads such as graphic rendering, video editing, crash simulations, or deep
learning. This category includes NV and NC series VM sizes.
• High performance compute. This category offers VMs with the fastest CPUs and optional high-
throughput Remote Direct Memory Access (RDMA) network interfaces. This category includes H series
VMs and A8-A11 VM sizes.
Note: Dv3, Dsv3, Ev3, and Esv3 series Azure VMs also provide support for nested
virtualization.
Additional Reading: For more information on virtual machine sizes, including any changes
since this course was published, refer to: “Sizes for virtual machines in Azure” at:
http://aka.ms/Iyrbvv
Azure VM availability
It is important that your Azure VM–based
workloads are resilient to hardware failures. They
also must remain online during maintenance
events that might occur occasionally within the
Azure infrastructure. The Azure platform provides
the availability set to help you accomplish these
objectives. The availability set allows for efficient
handling of two types of events that result in
downtime of individual Azure VMs:
• Planned maintenance events that require

restarts of Hyper-V hosts where VMs run.
While most Azure platform updates are
transparent to platform as a service (PaaS) and IaaS services, some might involve reboots of Hyper-V
hosts, which affect the availability of their VM guests.
• Hardware failures. Although Microsoft designed the Azure platform to be highly resilient, a hardware
failure might affect one or more Hyper-V hosts and their VM guests.
Understanding availability sets

To provide resiliency in the two scenarios described above, you should group two or more VMs providing
the same functionality in an availability set. An availability set is an Azure resource that typically contains
two or more VMs. By assigning VMs to the same availability set, you automatically affect their placement
across separate physical racks within an Azure datacenter. The placement provides resiliency against
planned maintenance events by dividing VMs in the same availability set into update domains. Similarly,
the placement improves resiliency against hardware failures by dividing VMs in the same availability set
into fault domains.
Update domains
An availability set consists of up to 20 update domains (you can increase this number from its default of
five). Each update domain represents a set of physical hosts that Azure Service Fabric can update and
restart at the same time without affecting overall availability of VMs grouped in the same availability set.
When you assign more than five VMs to the same availability set (assuming the default settings), the sixth
VM is placed in the same update domain as the first VM, the seventh is placed in the same update domain
as the second VM, and so on. During planned maintenance, only hosts in one of these five update
domains are restarted concurrently, while hosts in the other four remain online.
Fault domains
Fault domains define a group of Hyper-V hosts that a localized hardware failure (such as servers installed
in a rack serviced by the same power source or networking switches) can affect, due to their location. The
platform distributes VMs in the same availability set across either two fault domains (in classic
deployments) or three fault domains (when using Azure Resource Manager).
You can protect each service from individual VM failures by placing VMs hosting applications, such as web
or database servers, in function-based availability sets. You can then use load balancing or a failover
mechanism across VMs in the same availability set.
Configuring availability sets

The Azure platform manages placement of VMs based on their membership in an availability set. You
must ensure that the VMs providing the same functionality belong to the same availability set. To
accomplish this, you can use the Azure portal, Azure PowerShell, Azure CLI, or Azure Resource Manager
templates. When using the Azure portal, you can create a new availability set while deploying a new VM,
or create a new availability set first and then add VMs to it. Note, however, that you must add a VM to an
availability set at the deployment time.
Note: It is critical to understand that you cannot add an existing Azure VM to an availability
set. You need to specify that an Azure VM will be part of an availability set when you provision it.
To create an availability set in the Azure portal, you must specify the following settings:
• Name. A unique sequence of up to 80 characters, starting with either a letter or a number, followed
by letters, numbers, underscores, dashes, or periods, and ending with a letter, a digit, or an
underscore.
• Resource Group. A resource group into which you will deploy the Azure VMs that will become part
of the availability set.
• Location. The Azure region that is hosting the VMs that will be part of the availability set.
• Fault domains. The number of fault domains (up to three) associated with the availability set.
• Update domains. The number of update domains (up to 20) associated with the availability set.
• Managed. An indication that the availability set will host the VMs that use managed disks. With the
introduction of managed disks, it is possible to create two types of availability sets–managed and
unmanaged. In a managed availability set, all VMs use exclusively managed disks. In an unmanaged
availability set, all VMs use exclusively unmanaged disks. A managed availability set automatically
ensures additional resiliency at the Azure Storage level.
Note: You will learn about managed disks later in this lesson.
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
To perform the same tasks via Azure CLI, you would use the following commands:
az vm availability-set create
az vm availability-set update
az vm availability-set delete
Considerations for virtual machine availability

When configuring availability sets for Azure VMs:
• 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 the 99.95% external connectivity Service
Level Agreement (SLA), they must be part of the same availability set (with two or more VMs per set).
• Configure each application tier as a separate availability sets. If 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. This will 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, if the application running on them supports such configuration. In addition to distributing
incoming connections, a load balancer can detect a virtual machine or an application failure and
redirect network traffic to other nodes in the availability set.
Single VM availability
Availability sets provide resiliency for workloads that can run side-by-side on multiple Azure VMs in the
active-active or active-passive modes. However, there are applications and services that do not support
this type of configuration. While you can install them on individual VMs, you forfeit the benefits
associated with availability sets. Fortunately, even in such cases, the Azure platform provides the
availability SLA of 99.9% if you ensure that each VM disk resides in Premium storage.
Virtual machine storage

Azure Storage stores .vhd files representing
operating system and data disks of Azure VMs.
Azure Storage can host different types of objects,
including blobs, tables, queues, and files.
Note: This module focuses on the Azure

Storage capabilities applicable to Azure VMs. You
will learn more about Azure Storage and objects
that are not Azure VM–specific in detail in
Module 6, “Planning and implementing storage,
backup, and recovery services.”
Azure offers two tiers of Azure Storage capable of storing .vhd files—Standard and Premium. In both
cases, Azure VM disks take the form of page blobs because page blobs are optimized for random read-
write access. In general, page blobs can be up to 8 TB in size. However, the maximum size of the VM disk
you can create and attach to an Azure VM is 4 TB.
.vhd files in Azure Storage represent one of two object types—images or disks. The difference between
these two object types might be easy to miss, but it is significant. An image is a generalized copy of an
operating system, which allows you to create any number of VMs, each with its own unique
characteristics. A disk object is either a nongeneralized copy of an operating system or a data disk. You
can use an operating system disk to create a single exact replica of the VM that you used to create it. You
can also attach a data disk to an existing Azure VM to access its content.
Images serve as templates from which you provision disks for an Azure VM during its deployment. There
are numerous ready-to-use images available to you from the Azure Marketplace. You can create your own
images either by uploading .vhd files from your on-premises environment and registering them as
images, or by creating them from existing Azure VMs.
To identify individual images, Azure Resource Manager relies on several parameters, including:
• Publisher name. For example, MicrosoftWindowsServer.
• Offer. For example, WindowsServer.
• SKU. For example, 2012-R2-Datacenter.

• Version. For example, 4.0.20150916.
You can use these parameters to identify available images that match your requirements by running the
Get-AzureRmVMImage cmdlet.
Azure supports three types of disks:
• Operating system disks:
o One per VM
o Maximum size of 4 TB
o Labeled as drive C on Windows VMs and mounted as /dev/sda1 on Linux VMs
o Appears to the operating system in the VM as a Serial Advanced Technology Attachment (SATA)
drive
o Contains the operating system

• Temporary disks:
o One per VM
o The size depends on the VM size
o Labeled as drive D on Windows VMs or mounted as /mnt/resource on Linux VMs (/mnt in case of
Ubuntu)
o Provides temporary, nonpersistent storage (commonly used as the location of a paging file)
o On most VM sizes (with exception of Basic and Standard A0-A7), it uses SSD storage
• Data disks:
o VM determines the maximum number of data disks
o Maximum size of 4 TB
o You can assign any available drive letter starting with F (on Windows VMs) or mount it via a
custom mount point on Linux VMs
o Appears to the operating system in the VM as a small computer system interface (SCSI) drive
o Provides persistent storage for applications and data

Operating system and data disks are implemented as page blobs in Azure Storage. The temporary disk is
implemented as local storage on the Hyper-V host where the VM is running.
Overview of unmanaged and managed disks

An Azure Storage account is a logical namespace
that, depending of its type, is capable of hosting
different types of objects, including blobs, tables,
queues, and files. You can create a storage
account by using a variety of methods, including
the Azure portal, Azure PowerShell, Azure CLI, and
Azure Resource Manager templates. Storage
accounts provide the persistent store for virtual
machine disks in Azure.
When deploying an Azure VM, you must choose

the type of disks to attach. You can use the
unmanaged or managed disk type. Your decision
has important implications in terms of functionality, manageability, and pricing.
With unmanaged disks, you must create Azure Storage accounts where Azure VM disks will reside. You
have to decide how many storage accounts you will create and how you will distribute disk files across
them.
These extra considerations do not constitute a significant overhead if the number of Azure VMs is
relatively small. However, with a larger number of Azure VMs, the management of storage accounts
results in increased complexity for two reasons:
• The maximum number of Azure Storage accounts per region is limited to 200.
• A single Standard Azure Storage account has a performance limit of 20,000 IOPS. Because the Azure
platform allocates 500 IOPS per single Standard storage disk, this creates the practical limit of 40
concurrently active disks per single Azure Storage account.
In addition to capacity and performance, choosing unmanaged or managed disks also affects resiliency.
The Azure platform, by default, synchronously replicates each Azure Storage account across three
locations within a storage cluster consisting of multiple racks of servers. These clusters are referred to as
storage stamps. Clustering protects an Azure VM’s disk against a hardware failure affecting a physical rack.
This type of resiliency is typically sufficient when provisioning storage for a standalone Azure VM.
However, when provisioning two or more VMs into the same availability set, you should ensure that their
respective storage accounts do not reside in the same storage stamp.
Note: You can determine whether two storage accounts reside in the same storage stamp by
resolving their fully qualified DNS names to the corresponding IP addresses. If the IP addresses
are different, then the storage accounts reside in different storage stamps. You cannot explicitly
request the placement of a storage account in a different storage stamp when using standard
Azure management tools such as the Azure portal, Azure PowerShell, or Azure CLI. If this is
necessary, you can submit a request to Azure support for help with this task.
You can bypass all these considerations by using managed disks. In this approach, the Azure platform
controls the placement of VM disk files and hides the complexity associated with managing Azure Storage
accounts. Managed disks provide the following capacity, performance, and resiliency improvements:
• The limit on the number of Azure Storage accounts no longer applies. Instead, there is a limit of
10,000 managed disks per region.
• The performance limits of individual Standard Azure Storage accounts are no longer relevant.
• The Azure platform automatically distributes managed disks across different storage stamps for Azure
VMs in the same availability set.
Managed disks also provide other functional benefits. For example, you can convert a managed disk
between Standard and Premium storage directly from the Azure portal. You can also create an Azure VM
from a custom image stored in any storage account in the same region and the same subscription. With
unmanaged disks, you must store Azure VM disks in the same storage account as the image.
Note: There is an extra monetary cost associated with these benefits. When using Standard
storage with unmanaged disks, you pay only for the space you use. With managed disks, you pay
for the full capacity of a disk, regardless of the disk space that is in use.
The managed disks feature applies in a uniform way to all VMs in the same availability set. You might
recall that an availability set has a Managed property that determines its support for managed disks. This
means that you cannot mix VMs with unmanaged disks and VMs with managed disks in the same
availability set.
Note: If you intend to configure an Azure VM with managed disks, you should choose this
option at the time of deployment. You can convert unmanaged disks to managed disks; however,
this requires stopping and deallocating all VMs in the availability set.
Managed disks are available in the following sizes:
• For Premium storage:
o P4 (32 GB)
o P6 (64 GB)
o P10 (128 GB)

o P20 (512 GB)
o P30 (1 TB)
o P40 (2 TB)
o P50 (4 TB)
• For Standard storage:
o S4 (32 GB)
o S6 (64 GB)
o S10 (128 GB)
o S20 (512 GB)
o S30 (1 TB)
o S40 (2 TB)
o S50 (4 TB)
Additional Reading: For more information about managed disks, refer to: “Azure Managed
Disks Overview” at: https://aka.ms/d9rm4w
When planning for virtual machine disk configuration, you should note that storage-related charges 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, you will incur charges for
data egress. Note that this never applies to an Azure VM and blobs hosting its .vhd files, 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 in your Azure environment.
Demonstration: Creating an availability set by using the Azure portal

In this demonstration, you will see how to create an availability set by using the Azure portal.
Question: What types of workloads running currently in your on-premises environment are
suitable for migration to Azure VMs?
Lesson 3
Deploying Azure VMs
You can deploy Azure VMs by using several methods, including the Azure portal, Azure PowerShell, Azure
CLI, or Azure Resource Manager templates. This lesson explains the primary methods for deploying Azure
VMs and demonstrates the use of these methods.
Lesson Objectives
• Identify the methods of creating Azure VMs.
• Explain how to deploy an Azure VM by using the Azure portal.

• Explain how to deploy an Azure VM by using Azure PowerShell.
• Explain how to deploy an Azure VM by using Azure CLI.
• Explain how to deploy an Azure VM by using an Azure Resource Manager template.
• Create a virtual machine by using the Azure portal.
Determining the deployment method

Azure Resource Manager provides several
methods of deploying Azure VMs, including the
following:
• Azure portal. You can use the Azure portal to
create virtual machines. This method is
straightforward because it automatically
provisions most common configuration
options, including connectivity via a public IP
address and either the Remote Desktop
Protocol (RDP) or Secure Shell (SSH) protocol,
according to your choice of operating system.
On the other hand, this method provides
limited flexibility. For example, you cannot create a virtual machine from a custom image or attach a
data disk or an additional network adapter during provisioning. This method is also not suitable for
deploying a large number of Azure VMs.
• Azure PowerShell. This method offers automation and full flexibility, allowing you to create multi-NIC
and multidisk Azure VMs from either Marketplace-based or custom images. Simultaneous
deployment of multiple Azure VMs is possible, but the speed of deployment is not optimal.
• Azure CLI. This method is equivalent to using Azure PowerShell, in terms of flexibility and automation
capabilities. The choice between the two is dependent primarily on the preference of the person
carrying out the deployment.
• Azure Resource Manager templates. This method provides full flexibility and the best performance for
large deployments of Azure VMs. Note, however, that this method creates all resources in the same
resource group. This limitation does not apply to deployments based on Azure PowerShell or Azure
CLI scripts.
Using images to create virtual machines

As mentioned earlier in this module, you can deploy a new Azure VM by using either an image or a disk.
Creating multiple Azure VMs from a single set of .vhd files requires the use of images. You can choose
between ready-to-use images from the Azure Marketplace and custom images that you generate from
on-premises computers or Azure VMs. The next module will cover the process of uploading on-premises
.vhd files to Azure Storage. This topic focuses on the process of generating images from Azure VMs.
Image generation starts with generalizing the operating system. To generalize an Azure VM’s Windows
operating system, run:
Sysprep /oobe /generalize /shutdown
This will automatically shut down the operating system once the generalization process completes.
To generalize an Azure VM’s Linux operating system, run:
Sudo waagent –deprovision+user -force
The +user command line switch removes the most recently provisioned user account. The remainder of
the process depends on whether you are using unmanaged or managed disks. In the first case, the
process will result in an unmanaged image, and in the second, a managed image. In both cases, the image
will contain all the disks attached to the VM, including any data disks.
Generating an unmanaged image from an Azure VM with unmanaged disks by using

Azure PowerShell
To generate an unmanaged image from an Azure VM with unmanaged disks by using Azure PowerShell,
use the following steps:
1. From Azure PowerShell, authenticate to the Azure subscription where the Azure VM resides.
2. Deallocate the resources of the Azure VM that you are capturing by running:
Stop-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <VMName> -Force
3. Set the status of the virtual machine that you are capturing to Generalize by running:
Set-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <VMName> -Generalized
This will automatically remove the Azure VM, making its .vhd file ready for image generation.
4. Generate an image in the same storage account by running:
Save-AzureRmVMImage -ResourceGroupName <ResourceGroupName> -VMName <VMName> -

DestinationContainerName <ContainerName> -VHDNamePrefix <PrefixName> -Path <JSONFile>
5. This will create an image in the container that you specified within the storage account hosting the
Azure VM disks. The command will also create a file at the location referenced by the –Path
parameter containing JavaScript Objection Notation (JSON) representation of the new image’s
configuration. The file contains the uri parameter of the image. You will need to assign its value to the
–SourceImageUri parameter of Set-AzureRmImageVMOsDisk during provisioning of an Azure VM
based on this image.
Note: When provisioning a new VM with unmanaged disks based on a custom image, the
disks must reside in the same storage account as the image.
Additional Reading: For more information about creating unmanaged VM images, refer to:
“How to create an unmanaged VM image from an Azure VM” at: http://aka.ms/Cey939
Additional Reading: For description of the equivalent procedure when using Azure CLI,
refer to: “How to create an image of a virtual machine or VHD” at: https://aka.ms/ybb17g
Generating a managed image from an Azure VM with managed disks by using

Azure PowerShell
1. From Azure PowerShell, authenticate to the Azure subscription where the Azure VM resides.
2. Deallocate the resources of the Azure VM that you are capturing by running:
Stop-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <VMName> -Force
3. Set the status of the virtual machine that you are capturing to Generalize by running:
Set-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <VMName> -Generalized
This will automatically remove the Azure VM, making its .vhd file ready for image generation.
4. Store a reference to the Azure VM in a variable by running:
$vm = Get-AzureRmVM –ResourceGroupName <ResourceGroupName> -Name <VMName>
5. Create the image configuration by running:
$image = New-AzureRmImageConfig –Location $vm.Location –SourceVirtualMachineId $vm.ID
6. Generate the image in the same Azure region by running:
New-AzureRmImage –Image $image –ImageName <ImageName> -ResourceGroupName

<ResourceGroupName>
7. This will create an image in the same region as the Azure VM. You will need to assign its value to the
–SourceImageUri parameter of the Set-AzureRmImageVMOsDisk command during provisioning of
an Azure VM based on this image.
Additional Reading: For more information about creating managed VM images, refer to:
“Create a managed image of a generalized VM in Azure” at: https://aka.ms/bqmp6g
Using the Azure portal to create virtual machines

Creating a new VM by using the Azure portal is a
relatively straightforward process, although it does
involve several steps. You must be familiar with
these steps to implement the most optimal
configuration. The first step is choosing the Azure
Marketplace image.
The Marketplace contains images of various

Microsoft and Linux operating systems, products,
and even ready-to-use multiserver solutions. For
example, you can select a basic Windows Server
installation or a specific product, which will be
preinstalled with the server. The available
Microsoft products include:
• Microsoft SharePoint
• Microsoft SQL Server

• BizTalk Server
• Microsoft Visual Studio

If you are performing a Linux installation, you can select from multiple versions of the following
distributions:
• CentOS
• CoreOS
• Debian
• Oracle Linux
• Red Hat Enterprise

• SUSE Linux Enterprise
• openSUSE
• Ubuntu
When you create a Windows VM, the portal allows you to specify the following options:
• VM name. This option matches the name assigned to the operating system instance.
• VM disk type. You can choose either SSD or hard disk drive (HDD). The first option provisions the
operating system disk by using Premium storage. The second one provisions the operating system
disk by using Standard storage.
• User name. This option designates the name of the local administrative account that you will use
when you manage the server.
• Password. This option designates the password of the administrative account.
• Subscription. This option determines the subscription to which you deploy the VM.
• Resource group. This option specifies the name of the resource group that will contain the VM and
its resources (such as virtual network adapters). You can create a new resource group when you
deploy the Azure VM or place it in an existing one.
• Location. This option represents the name of the Azure region where the Hyper-V systems hosting
your VM reside.
• VM size. This option identifies the pricing tier, performance, and functional capabilities of the VM (as
described in the previous topic of this lesson).
• Storage. This option allows you to choose between managed and unmanaged disks. If you choose
unmanaged disks, you must specify the name of a new or existing Azure Storage account, and the
name of a container within it that will host the operating system disk of the VM.
• Virtual network. This option identifies the virtual network in Azure to which the VM is automatically
connected. This allows for direct communication with other VMs on the same virtual network or
other, directly connected virtual networks.
Note: Any Azure VM that you provision by using the Azure Resource Manager deployment
model must reside on an Azure virtual network. This is optional in the classic deployment model.
• Subnet. This option identifies the subnet within the virtual network. The private IP address of the VM
is part of the subnet IP address space.
• Public IP address. This option allows you to (optionally) provide an Internet-accessible IP address to
facilitate connectivity to the VM from:
o Outside Azure, including on-premises environments or non-Microsoft cloud providers.
o Other Azure services that are not part of the same virtual network as the VM or any other
network connected to that virtual network.
• Network security group. This option configures the default security that allows connectivity from
the Internet to TCP port 3389 of the Azure VM. The intention of this configuration is to permit
inbound RDP sessions after the VM deployment is complete. You can change the default settings if
they do not suit your requirements.
• Extensions. This option allows you to configure an operating system and applications that run in the
VM after its deployment is complete, providing custom management capabilities.
• Monitoring. Once enabled, this option triggers collection of performance and diagnostics data that
you can use to track and troubleshoot issues affecting VM workload.
• Diagnostics storage account. This option represents an Azure Storage location where the
performance and diagnostics data will reside.
When you create a Linux VM, your options are mostly the same. There are two primary differences:
• You can choose between the password-based and SSH public key–based authentication types.
• The default network security group allows connectivity from the Internet to port 22 on the VM. The
intention of this configuration is to permit SSH sessions after the VM deployment is complete. You
can change the default settings if they do not suit your requirements.
While these options might seem confusing initially, the default settings yield a configuration that is ready
to use (although it might not be optimal, depending on your intentions). In particular, the new VM will
have a public IP address and allow connectivity via either RDP (in the case of a Windows image) or SSH
(for Linux distributions) from any system with Internet access. Obviously, you can only connect successfully
to the VM if you have access to its administrative credentials.
Note: The Azure portal automatically selects the Azure Resource Manager deployment
model when provisioning a new Azure VM.
Using Azure PowerShell to create an Azure VM with managed disks
Using Azure PowerShell to create Azure

VMs with managed disks from a
Windows Server 2016 Azure
Marketplace image
To create an Azure VM with managed disks from a
Windows Server 2016 Azure Marketplace image
by using Azure PowerShell, perform the following
steps:
1. Open the Azure PowerShell console and sign
in to Azure:
2. List the names of Azure subscriptions associated with your account:
Get-AzureRmSubscription | Sort-Object SubscriptionName | Select-Object

SubscriptionName
3. Select the target subscription:
Select-AzureRmSubscription -SubscriptionName "<subscription name>"
where <subscription name> is the name of the subscription that you identified in the list from step 2
and to which you want to deploy the Azure VM.
4. Create a resource group that will contain the Azure VM and all objects associated with it:
$resourceGroup = New-AzureRmResourceGroup -ResourceGroupName <resource group name>

-Location <Azure region>
where <resource group name> is the name you want to assign to the resource group and <Azure
region> is its location.
5. Create a subnet configuration:
$subnetConfig = New-AzureRmVirtualNetworkSubnetConfig `
-Name <subnet name> `
-AddressPrefix <subnet IP address prefix>
where <subnet name> is the name you want to assign to the subnet to which you will deploy the
Azure VM and <subnet IP address prefix> is the IP address range of that subnet.
6. Create a virtual network:
$vnet = New-AzureRmVirtualNetwork `
-ResourceGroupName myResourceGroupVM `
-Location $resourceGroup.location `
-Name <vnet name> `
-AddressPrefix <vnet IP address space> `
-Subnet $subnetConfig
where <vnet name> is the name you want to assign to the virtual network containing the subnet you
created in the previous step and <vnet IP address prefix> is its IP address space.
7. Create a public IP address:
$pip = New-AzureRmPublicIpAddress `
-ResourceGroupName $resourceGroup.Name `
-AllocationMethod Static `
-Name <public IP address name>
where <public IP address name> is the name you want to assign to the public IP address that will be
associated with the Azure VM.
8. Create a network interface card (NIC):
$nic = New-AzureRmNetworkInterface `
-Name <NIC name> `
-SubnetId $vnet.Subnets[0].Id `
-PublicIpAddressId $pip.Id
where <NIC name> is the name you want to assign to the NIC that will be attached to the Azure VM.
9. Create a Network Security Group (NSG) rule allowing inbound RDP traffic:
$nsgRule = New-AzureRmNetworkSecurityRuleConfig `
-Name <NSG rule name> `
-Protocol Tcp `
-Direction Inbound `
-Priority 1000 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389 `
-Access Allow
where <NSG rule name> is the name you want to assign to the NSG rule.
10. Create an NSG:
$nsg = New-AzureRmNetworkSecurityGroup `
-Name <NSG name> `
-SecurityRules $nsgRule
where <NSG name> is the name you want to assign to the NSG.
11. Associate the NSG with the subnet you created:
Set-AzureRmVirtualNetworkSubnetConfig `
-Name <subnet name> `
-VirtualNetwork $vnet `
-NetworkSecurityGroup $nsg `
-AddressPrefix <subnet IP address prefix>
12. Apply the update to the virtual network:
Set-AzureRmVirtualNetwork -VirtualNetwork $vnet

13. Set administrative credentials for the operating system within the Azure VM:
$cred = Get-Credential
This command will prompt you for a user name and password, and will store your response in the
$cred variable.
14. Create an initial configuration of the Azure VM and store it in the variable $vm:
$vm = New-AzureRmVMConfig -VMName <VM name> -VMSize <VM size>
where <VM name> is the name you want to assign to the VM and <VM size> is its intended size.
15. Assign the operating system and credentials to the VM configuration:
$vm = Set-AzureRmVMOperatingSystem `
-VM $vm `
-Windows `
-ComputerName myVM `
-Credential $cred `
-ProvisionVMAgent -EnableAutoUpdate
16. Add the Windows Server 2016 Azure Marketplace image information to the VM configuration:
$vm = Set-AzureRmVMSourceImage `
-VM $vm `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest
17. Add the operating system disk settings to the VM configuration:
$vm = Set-AzureRmVMOSDisk `
-VM $vm `
-Name <OS disk name> `
-DiskSizeInGB <OS disk size> `
-CreateOption FromImage `
-Caching ReadWrite
where <OS disk name> is the name you want to assign to the operating system (OS) disk and
<code>OS disk size> is its intended size.
18. Add the NIC to the VM configuration:
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
19. Finally, create the virtual machine:
New-AzureRmVM -ResourceGroupName $resourceGroup.Name -Location

$resourceGroup.location -VM $vm
Note: If you want to provision an Azure VM quickly, with minimal customization, use the
Quick Start option.
Additional Reading: For more information on creating Azure VMs by using Azure
PowerShell, refer to: “Create and Manage Windows VMs with the Azure PowerShell module” at:
https://aka.ms/og8f5z
Using Azure PowerShell to create an Azure VM with managed disks from a custom
Windows image
To create an Azure VM with managed disks from a custom image by using Azure PowerShell, perform the
following steps:
1. Open the Azure PowerShell console and sign in to Azure:
2. List the names of Azure subscriptions associated with your account:
Get-AzureRmSubscription | Sort-Object SubscriptionName | Select-Object

SubscriptionName
3. Select the target subscription:
Select-AzureRmSubscription -SubscriptionName "<subscription name>"
where <subscription name> is the name of the subscription that you identified in the list from step 2
and to which you want to deploy the Azure VM.
4. Use the steps described earlier in this topic to perform the following tasks:
o Create a virtual network and its subnet
o Create a public IP address
o Create a NIC
o Create an NSG with a rule allowing inbound RDP traffic
o Store OS admin credentials in a variable
o Initiate the VM configuration

5. Collect information about the image:
$rgName = <resource group name>

$location = <Azure region>
$imageName = <image name>
$image = Get-AzureRMImage -ImageName $imageName -ResourceGroupName $rgName
6. Set the VM image as the source image for the new Azure VM by assigning the image ID to the VM
configuration:
$vm = Set-AzureRmVMSourceImage -VM $vm -Id $image.Id
7. Assign the OS disk to the VM configuration:
$vm = Set-AzureRmVMOSDisk -VM $vm `

-StorageAccountType <PremiumLRS or StandardLRS> `
-DiskSizeInGB <disk size in GB> `
-CreateOption FromImage `
-Caching <ReadWrite, ReadOnly, or None>
$vm = Set-AzureRmVMOperatingSystem
-VM $vm `
-Windows `
-ComputerName $computerName `
-Credential $cred `
-ProvisionVMAgent -EnableAutoUpdate
8. Use the steps described earlier in this topic to add the NIC to the VM configuration.
9. Create the VM:
New-AzureRmVM -ResourceGroupName $resourceGroup.Name -Location

$resourceGroup.location -VM $vm
Additional Reading: For more information on creating an Azure VM from a custom

managed image by using Azure PowerShell, refer to: “Create a VM from a managed image” at:
https://aka.ms/yty166
Using Azure CLI to create an Azure VM with managed disks
Using Azure CLI to create Azure VMs

with managed disks from an Azure
Marketplace Linux image
To create an Azure VM with managed disks from
an Azure Marketplace image by using Azure CLI,
perform the following steps:
1. Sign in to Azure:
az login
2. Set your subscription:
az account set –subscription <subscription name>
where <subscription name> is the name of the Azure subscription into which you intend to deploy an
Azure VM.
3. Create a resource group:
az group create --name <resource group name> --location <Azure region>
where <resource group name> is the name of the resource group that will host the Azure VM and
<Azure region> is its location.
4. Create the Azure VM:
az vm create --resource-group <resource group name> --name <VM name> --image <Azure
Marketplace image> --generate-ssh-keys
This command generates SSH keys for subsequent authentication to the Linux OS.
Note: Azure CLI creates managed disks automatically during an image-based deployment.
Note: This process is more straightforward than the one described in the previous topic. This
approach applies a number of defaults regarding, for example, the naming of such objects as the
virtual network and its subnet, in addition to characteristics of these objects, such as the virtual
network’s IP address space and the subnet’s IP address range.
Additional Reading: For more information on a detailed procedure that allows you to
specify custom parameters of all VM-related objects, refer to: “Create a complete Linux virtual
machine with the Azure CLI” at: https://aka.ms/q1ngyt
Additional Reading: For information on creating Azure VMs with managed disks from a
custom image by using Azure CLI, refer to: “Create a custom image of an Azure VM using the
CLI” at: https://aka.ms/d7ymfm
Creating VMs by using a deployment template

You can also create VMs by using Azure Resource
Manager templates, in a relatively straightforward
process. The complexity of the implementation
depends largely on how much you want to
customize the VM configuration. This option relies
on the capabilities of Azure Resource Manager,
which make it possible to describe any
deployment by using an appropriately formatted
text file (referred to as an Azure Resource Manager
template). Such text files follow the JSON syntax
and include definitions of all the Azure Resource
Manager resources that are part of the
deployment. Templates typically contain a number of parameters, which enable you to customize each
deployment, accounting for individual preferences and requirements. Thus, deployments based on the
same template might result in different outcomes, depending on the values of parameters you provide.
Assuming that you have an existing Azure Resource Manager template, you can deploy all its resources by
running the New-AzureRmResourceGroupDeployment Azure PowerShell cmdlet. To reference the
template file, you use the -TemplateFile parameter. This will deploy the resources defined in the template
to the resource group you specify as the value of the -ResourceGroupName parameter. You can
accomplish the same outcome by running the az group deployment create Azure CLI command with
the -template-file and –resource_group parameters. In either case, you should provide the values of the
parameters specified in the template. Alternatively, you might assign default values to these parameters
directly within the template or reference a parameter file that contains their values during deployment.
Note: You can also reference a URL of an existing template in an Internet location by using
the -TemplateURI (Azure PowerShell) or -template_uri (Azure CLI) parameter.
To use Azure PowerShell and Azure CLI, you must be familiar with their syntax and scripting-engine
installation (unless you use Azure Cloud Shell). A more convenient way of deploying Azure Resource
Manager template–based resources is available directly from the Azure portal. When you select the New
> Compute > Template deployment hub menu entries, the Custom deployment blade displays. From
there, you can build your own template in the browser-based template editor, pick one of the common
templates, or load a GitHub quickstart template. The last of these three options leverages the GitHub
repository, where you will find hundreds of ready-to-use templates.
Note: Every template published on GitHub has a corresponding Deploy to Azure link.
When you click the link, it automatically redirects you to the Azure portal and initiates
deployment, prompting you only for the values of the required parameters. The same GitHub
page has also the Visualize link. When you click this link, it opens the template in Azure Resource
Manager Template Visualizer (at http://aka.ms/Fw4rij), displaying a diagram showing resources
defined in the template, including the relationships between them.
Additional Reading: For more information, refer to: “Azure Quickstart Templates” at:
http://aka.ms/Qgh9jn
Additional Reading: For more information, refer to: “Create a Windows virtual machine
from a Resource Manager template” at: http://aka.ms/Bt1gf6
Demonstration: Creating a VM by using the Azure portal

In this demonstration, you will see how to create a VM from the Azure portal by using a Marketplace
image.
Question: Why is an Azure Resource Manager template beneficial for deploying multiple
virtual machines?
Lab A: Deploying Azure VMs

Scenario
As part of the planning for deployment of Azure VMs to Azure, Adatum Corporation has evaluated its
deployment options. You must use the Azure portal and Azure PowerShell to deploy two Microsoft Azure
VMs for the database tier of the Research and Development application. To facilitate resource tracking,
you should ensure that the virtual machines are part of the same resource group. Both VMs should be
part of the same availability set.
Objectives
• Create Azure VMs by using the Azure portal and Azure PowerShell.
• Validate virtual machine creation.
User name: Student
Password: Pa55w.rd
Question: What differences regarding Azure VM storage did you notice when you created a
virtual machine in the Azure portal versus in Azure PowerShell?
Lesson 4
Overview of classic VMs
For any current and future deployments, you should use the Azure Resource Manager deployment model.
However, you might need to manage existing classic Azure VMs in your environment. This lesson provides
basic information about the classic deployment model and describes the process of provisioning and
configuring classic VMs.
Lesson Objectives
• Describe the main characteristics of classic VMs and cloud services
• Explain how to provision and configure classic VMs.
Overview of IaaS Cloud Services

Cloud Services that host classic VMs are similar to
PaaS Cloud Services, which you can use to host
web and worker roles. For more information, refer
to Module 8, “Implementing Azure Cloud
Services.”
Just like cloud services that host web and worker

roles, cloud services that host classic VMs serve as
their logical containers. You cannot create an
Azure classic VM without first specifying a cloud
service to use.
Any VM in a cloud service can communicate

directly with all other VMs in that cloud service.
Besides providing VMs with this ability, a cloud service also facilitates access to the VMs over the Internet.
This is possible because the Azure platform automatically assigns a public IP address and a corresponding,
publicly resolvable DNS name to each cloud service.
Typically, in order to access a VM in the classic deployment model, you create an endpoint by modifying
the cloud service where this VM resides. Each VM exists within boundaries of a cloud service. Cloud
Services also allows for grouping of VMs into availability sets, providing resiliency against hardware
failures and the continuity of service during occasional maintenance events in Azure datacenters.
Hardware failure resiliency relies on placing VMs into two distinct fault domains, with each fault domain
representing separate server racks. Continuity of service involves placing VMs into up to five update
domains. The platform ensures that separate fault domains are never updated at the same time.
Cloud Services also provides load-balancing functionality. By using a load-balanced endpoint, Cloud
Services distributes incoming traffic targeting a specific port across VMs within the same availability set. In
addition, Cloud Services handles NAT, allowing for connectivity to individual VMs via its endpoints.
Optionally, you also can create a virtual network in Azure and deploy VMs in the classic deployment
model into it. This arrangement allows you to provide direct connectivity between VMs that do not reside
within the same cloud service. This also is necessary if you want to establish direct connectivity between
Azure VMs and on-premises networks.
Creating classic VMs

You can create classic VMs from the Azure portal
or by using Azure PowerShell.
Deploying classic VMs by using the

Azure portal
To create an Azure Resource Manager VM from
the Azure portal, perform the following steps:
1. Sign in to the Azure portal at

https://portal.azure.com.
2. On the Hub menu, click Virtual machines

(classic).
3. On the Virtual machines blade, click +Add.
4. On the Compute blade, click Windows Server.

5. On the Windows Server blade, click Windows Server 2016 Datacenter.
6. On the Windows Server 2016 Datacenter page, under Select a deployment model, select Classic,
and then click Create.
7. On the Basics blade, enter the name that you want to give your VM. The name cannot contain
special characters.
8. Enter the Windows administrative user name and password. The password must be between eight
and 123 characters long, and include at least three of the following: one lower-case character, one
upper-case character, one number, and one special character. You will need the user name and
password to sign in to the VM.
9. If you have more than one subscription, specify the one for the new VM, a new or existing resource
group, and an Azure datacenter location.
10. On the Choose a size blade, select an appropriate virtual-machine size for your needs. Each size
specifies the number of compute cores, memory, and other features, such as support for Premium
storage. These all affect the price. Azure recommends certain sizes automatically, depending on the
image that you choose.
11. On the Settings blade, configure storage, networking, extensions, high availability, and monitoring
settings for the new VM. The networking settings include the Cloud service (domain name) and
Endpoints entries.
12. Click Summary to review your configuration choices. When you finish reviewing or updating the
settings, click OK.
These steps use the image based on Windows Server 2016 Datacenter Edition to create a VM.
Deploying classic VMs by using Azure PowerShell

You also can use the Azure PowerShell interface to create classic VMs by using Windows PowerShell
cmdlets.
You can define a virtual-machine configuration, and then create the VM, as the following sample code
shows:
$newVM = New-AzureVMConfig -name $vmname -Instance $instance -ImageName $osimage | Add-

AzureProvisioningConfig -Windows -AdminUsername $adminname -Password $password | Set-
AzureSubnet -SubnetNames $subnet
New-AzureVM -ServiceName $cloudservice -AffinityGroup $affinitygroup -VMs $newVM
-VNetName $vnet -DnsSettings $dns -WaitForBoot
Alternatively, you can create and configure a VM in one step, as the following code sample shows:
New-AzureQuickVM -Windows -ImageName $osimage -Location $location -Name $vmname

-ServiceName $svcName -InstanceSize $size -AdminUserName $adminname -Password $password
There are more configuration options if you use the New-AzureVMConfig and New-AzureVM cmdlets,
such as the ability to use a static internal IP address by using Set-AzureStaticVNetIP. New-
AzureVMConfig enables you to create more complex virtual-machine configurations, and then pass
those configurations to New-AzureVM.
Question: In which situations would you choose to deploy Azure classic VMs instead of
Azure Resource Manager VMs?
Lab B: Deploying Azure VMs by using Azure Resource

Manager templates
Scenario
You must use an Azure Resource Manager template to deploy two additional Linux VMs and two
additional Windows VMs that the ResDev application will use. The virtual machines should be part of the
resource group, to facilitate resource tracking. Linux virtual machines should reside on the virtual
networks’ app subnet, and Windows virtual machines should reside on the web subnet of the
20533D0301-LabVNet virtual network.
Objectives
• Use Visual Studio and an Azure Resource Manager template to deploy Azure Resource Manager
virtual machines.
• Use Azure PowerShell and an Azure Resource Manager template to deploy virtual machines.
Lab Setup

User name: Student
Password: Pa55w.rd
The virtual machine should be running from the previous lab.
Question: Can Microsoft Visual Studio and Azure PowerShell use the same Azure Resource
Manager template to deploy an Azure VM?
Question: How would you configure an Azure Resource Manager template to deploy
multiple Azure VMs with different configurations?

Best Practices
• Use Azure Resource Manager deployment model for new deployments.
• Use Azure Resource Manager resource groups to organize Azure VMs within your subscription.
• Use a consistent naming convention for your Azure IaaS infrastructure.
• Use Azure Resource Manager templates to deploy and modify Azure VMs.
Review Questions
Question: Can you migrate on-premises virtual machines directly to Azure?
Question: What tools can you use to create and modify Azure Resource Manager
templates?
4-1
Module 4
Managing Azure VMs
Contents:
Module Overview 4-1
Lesson 1: Configuring Azure VMs 4-2
Lesson 2: Managing disks of Azure VMs 4-10
Lesson 3: Managing and monitoring Azure VMs 4-17

Lesson 4: Managing classic Azure VMs 4-28
Lab: Managing Azure VMs 4-32
Module Overview
Configuration, management, and monitoring of Azure virtual machines (VMs) are essential in delivering
secure, available, and scalable cloud-based solutions. This module presents some of the most common
techniques that allow you to administer and maintain Azure VMs to better suit your custom requirements.
Objectives
• Configure Azure VMs.
• Manage Azure VM disks.
• Manage and monitor Azure VMs.
• Manage classic Azure VMs.

4-2 Managing Azure VMs
Lesson 1
Configuring Azure VMs
Azure VMs are one of the core components of Microsoft Azure infrastructure as a service (IaaS)
deployments. In this lesson, you will look at the different options for configuring availability, scalability,
and performance of Azure VMs.
Lesson Objectives
• Explain how to connect to an Azure VM.
• Explain how to connect to Linux Azure VMs via Secure Shell (SSH).
• Describe how to scale Azure VMs.
• Configure security of Azure VMs.

module
the lab.
Connecting to an Azure VM
To manage an Azure VM, you can use the same
set of tools that you used to deploy it. However,
you will also want to interact with an operating
system (OS) running within the VM. The methods
you can use to accomplish this are OS-specific and
include the following options:
• Remote Desktop Protocol (RDP) allows you to

establish a graphical user interface (GUI)
session to an Azure VM that runs any
supported version of Windows. The Azure
portal automatically enables the Connect
button on the Azure Windows VM blade if the VM is running and accessible via a public IP address,
and if it accepts inbound traffic on TCP port 3389. After you click this button, the portal will
automatically provision 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-AzureRmRemoteDesktopFile cmdlet provides the same functionality.
Additional Reading: You can connect to an Azure Linux VM via Remote Desktop by using
the functionality provided by xrdp open source RDP server. To accomplish this, you need to
install xrdp on the target Linux VM. For more information, refer to: “Install and configure Remote
Desktop to connect to a Linux VM in Azure” at: https://aka.ms/mt6fpi
• Windows Remote Management (WinRM) allows you to establish a command-line session to an

Azure VM that runs any supported version of Windows. Alternatively, you can use WinRM to run
noninteractive Windows PowerShell scripts remotely. WinRM secures its sessions by using certificates.
You must upload a certificate that you intend to use to Azure Key Vault prior to establishing a session.
The process of setting up WinRM connectivity includes the following, high-level steps:
o Creating a key vault.
o Creating a self-signed certificate.
o Uploading the certificate to the key vault.
o Identifying the URL of the certificate uploaded to the key vault.
o Referencing the URL in the Azure VM configuration.

WinRM uses by TCP port 5986 by default, but you can change it to a custom value. In either case, you
must ensure that no network security groups are blocking inbound traffic on the port that you
choose.
Additional Reading: For more information, refer to: “Setting up WinRM access for Virtual
Machines in Azure Resource Manager” at: https://aka.ms/ljezi1
• SSH allows you to establish a command-line interface session to an Azure VM that runs the Linux OS.
To do so from a Windows computer, you typically use a terminal emulator, such as PuTTY. Most Linux
distributions offer a OpenSSH package. Several open source and non-Microsoft SSH client programs
are available for both Windows and Linux.
• RDP for Linux allows you to establish a GUI session to an Azure VM that runs any supported version
of the Linux OS. This functionality relies on the xfce4 desktop environment and the xrdp Remote
Desktop server. If you configure a Linux VM with SSH authentication, you must also assign a password
to the Linux administrative user account. In addition, you must ensure that no network security
groups are blocking traffic on TCP 3389.
Additional Reading: For more information, refer to: “Install and configure Remote Desktop
to connect to a Linux VM in Azure” at: https://aka.ms/tkvozt
Note: If you forget the OS administrative credentials, you can reset them by using the VM
Access extension. This includes changing an SSH certificate for Linux VMs. You will learn about
VM extensions in lesson 3 of this module.
Note: You can facilitate connectivity to an Azure VM from the internet in two ways:
• Assign a public IP address to one of its network interface cards (NICs).
• Place the VM behind an internet-facing load balancer and configure a network address translation
(NAT) rule that directs incoming traffic on a designated port to the appropriate port of the OS within
the VM.
Demonstration: Connecting to a Linux Azure VM via SSH

In this demonstration, you will see how to connect to a Linux Azure VM via SSH.
Scaling Azure VMs

In general, there are two methods of scaling Azure
VMs:
• Vertically. You scale by changing the VM size.
• Horizontally. You scale by changing the

number of VMs that reside in the same
availability set and share their load through
load balancing.
Vertical scaling
As mentioned in the previous module, you can
change a VM size, if your current configuration
does not violate the constraints of the VM size
that you intend to use. For example, you might need to remove an extra virtual network adapter or a data
disk attached to your VM before you scale it down to a smaller size.
Differences in hardware of Microsoft Hyper-V hosts also limit how you can change VM sizes. Hyper-V
hosts form compute clusters consisting of hundreds of physical servers with matching hardware. To avoid
these limitations, you have two options:
• Provision an Azure VM of the largest size that you anticipate using, and then scale it down to any
smaller size supported on the same hardware.
• Identify the VM size family that the largest intended size belongs to, and provision an Azure VM of
any size within that family.
Additional Reading: For more information, refer to: “Resize virtual machines” at:
https://aka.ms/g7utlw
Note: Changing an Azure VM’s size requires a restart if the new size is part of the same
compute cluster. If that is not the case, resizing will require stopping (deallocating) the Azure VM.
If that VM is part of an availability set, you will need to stop all VMs in the same availability set
and resize them simultaneously.
Horizontal scaling
You implement horizontal scaling of Azure VMs by using Azure virtual machine scale sets (scale sets).
A scale set consists of a group of Windows or Linux VMs that share identical configurations and deliver
the same functionality to support a service or application. With scale sets, you can increase or decrease
the number of VMs dynamically, to adjust to changes in demand for the workload they host. The
workload should be stateless, to smoothly handle deprovisioning of VMs when scaling in. VMs in the
same scale set are automatically distributed across five fault domains and five update domains.
scale sets integrate with Azure load balancers to handle dynamic distribution of network traffic across
multiple VMs. They also support NAT rules, allowing for connectivity to individual VMs in the same scale
set.
From a storage perspective, you can configure scale sets with both managed and unmanaged disks.
Using managed disks offers additional scalability benefits. With managed disks, when using an Azure
Marketplace image to provision a VM scale set, you can scale out up to 1000 VMs. With unmanaged disks,
the upper limit is 100 VMs per scale set. When using custom images, managed disks allow you to scale
out up to 100 VMs. With unmanaged standard storage disks, you should limit your deployment to 20
VMs. You can increase this number to 40 if you set the overprovision property of the VM scale set to
false. This way, you ensure that the aggregate Input/Output Operations Per Second (IOPS) of virtual disks
in the VM scale set stays below the 20,000-IOPS limit of a single standard Microsoft Azure Storage
account.
Note: Scale sets are available only when using the Azure Resource Manager deployment
model. You can implement horizontal scaling in the classic deployment model; however, this
requires preprovisioning additional VMs that you want to bring online to accommodate
increased demand.
Additional Reading: For more information, refer to: “What are virtual machine scale sets in
Azure?” at: http://aka.ms/xl3xw5
Implementing scale sets

To provision a VM scale set, you can use the Azure portal, Azure PowerShell, Azure Command-Line
Interface (CLI), or Azure Resource Manager templates. The templates reference the
Microsoft.Compute/virtualMachineScaleSets resource type. This resource type implements
many scale set properties, including:
• sku.tier. The size of the Azure VMs in the scale set.
• sku.capacity. The number of VM instances that the scale set will autoprovision.
• properties.virtualMachineProfile. The disk, OS, and network settings of the Azure VMs in the
scale set.
To configure Autoscale, the template must reference the Microsoft.Insights/autoscaleSettings resource

type. 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 central processing unit [CPU]).
• metricResourceUri. The resource identifier designating the scale set.
• timeGrain. The frequency with which performance metrics are collected (between one minute and 12
hours).
• Statistic. The method of calculating aggregate metrics from multiple Azure VMs (Average, Minimum,
Maximum).
• timeWindow. Range of time for metrics calculation (between five 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 Azure VMs in the set would increase when the CPU
usage exceeds 50 percent. The details of the method used to evaluate when the threshold is reached
depend on other properties, such as statistic, 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 scaling out or scaling in, respectively).
• Value. The number of Azure VMs added to or removed from the scale set (one or more).
• Cooldown. The amount of time to wait between the most recent scaling event and the next action
(from one minute to one week).
Additional Reading: For more information on scale sets, refer to: “Automatically scale
machines in a virtual machine scale set” at: https://aka.ms/xyo1tw
Configuring security of Azure VMs

Azure offers many technologies that help to keep
customer computing environments secure. In this
topic, you will learn about the additional security
measures that you can implement by leveraging
Azure capabilities.
Restricting access to Azure VMs from

the internet
For security reasons, you might want to prevent
connectivity to an Azure VM from the internet. To
accomplish this, ensure that there is no public IP
address assigned to any of the Azure VM NICs and
there are no NAT rules providing such
connectivity via a load balancer. You will still be able to connect to the OS within the Azure VM if the
computer from which you initiate the connection can reach any of the private IP addresses assigned to
the Azure VM NICs.
If preventing internet connectivity to an Azure VM is not an option, you can reduce the scope of IP
addresses from which a connection to that VM can originate. To do so, modify the network security group
rule that allows incoming traffic via the relevant port. This is feasible if you know the IP address
representing the public endpoint of the computers from which you intend to establish a remote
management session. In addition, you can control both inbound and outbound network traffic by using
an OS-level firewall.
Each Windows VM created by using an Azure Marketplace image has its local firewall enabled. By default,
Windows Firewall has enabled the rule that allows incoming RDP connections. If you want to allow
connectivity for applications or services that listen on a different port, you should configure Windows
Firewall accordingly.
Similarly, Azure network security groups associated with an Azure VM that you create by using the Azure
portal include a rule allowing connectivity via RDP or SSH (depending on the VM’s OS), by default. To
enable connections on other ports, add extra rules to the security group.
Azure offers services that allow you to further secure access to an Azure VM’s OS and disks. These services
include Azure Key Vault and Azure Disk Encryption.
Understanding Key Vault

Key Vault stores cryptographic keys and secrets, such as keys of Azure Storage accounts or passwords of
administrative users on Windows or Linux Azure VMs. The vault maintains its content in encrypted form.
You can make this content more secure by applying hardware security module (HSM)–based protection.
A secret is a small data blob (of up to 10 kilobytes [KB] in size) that authorized users and applications can
retrieve from the vault. To secure access to secrets, you create Azure Active Directory (Azure AD) objects
representing these users or applications, which they subsequently use to authenticate. This reduces the
risk associated with users storing passwords in unsecure locations. It also eliminates the need to hard-code
them into applications.
Unlike secrets, keys stored in a vault do not leave its boundaries. Instead, when you add a key to the vault,
users and applications must invoke cryptographic functions to perform operations that require knowledge
of that key. The ability to complete such invocation is also subject to a successful Azure AD–based
authentication. To access keys and secrets, users and applications must possess valid Azure AD tokens
representing security principals with sufficient permissions to the target vault.
Every object residing in Azure Key Vault has a unique identifier, which you must reference when
attempting to retrieve or access it. In addition, you can assign several additional attributes to both secrets
and keys, to facilitate 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 occurs 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 REST API, Azure PowerShell, or Azure CLI to retrieve secrets and public parts of keys (in
JavaScript Object Notation [JSON] format) from a vault. In addition to performing the GET operation, you
can perform other management tasks targeting keys (create, import, update, delete, list, backup, or
restore) and secrets (set, list, or delete). Similarly, each of these methods allows you to manage the vault
and its properties. The following Windows PowerShell cmdlets facilitate interaction with an Azure Key
Vault:
• New-AzureRmKeyVault. Creates a new Key Vault.
• Add-AzureKeyVaultKey. Creates a new—or imports an existing—key into a Key Vault.
• Get-AzureKeyVaultKey. Retrieves a public part of a key from a Key Vault.
• Get-AzureKeyVaultSecret. Retrieves a secret from a Key Vault.
• Remove-AzureKeyVaultKey. Removes a key from a Key Vault.

To accomplish the same tasks by using Azure CLI, run the following commands:
• az keyvault create
• az keyvault key create
• az keyvault key show
• az keyvault secret show
• az keyvault key delete
Additional Reading: For more information, refer to: “Get started with Azure Key Vault” at:
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 Azure VM disks. Azure Disk Encryption leverages existing file
system–based encryption technologies already available in the guest OS, such as BitLocker in Windows
and DM-Crypt in Linux. It uses these technologies to provide encryption of volumes hosting the OS and
data. The solution integrates with Key Vault to store volume encryption keys securely. You can also
encrypt these keys by utilizing the vault’s key encryption key functionality. The combination of these
features enhances security of Azure VM disks at rest by encrypting their content.
Note: It is possible to encrypt the data (but not the OS) volumes of Azure VMs running
Windows by using BitLocker without relying on Azure Disk Encryption. You can also encrypt any
volume (including the OS volume) by implementing non-Microsoft solutions offered on Azure
Marketplace, such as CloudLink SecureVM. Additionally, you can combine Azure Disk Encryption
with Azure Storage Service Encryption, which encrypts all the content of the storage account.
You would use Azure Disk Encryption in three scenarios, all which are applicable to Azure Resource
Manager deployments of Standard-tier Azure VMs:
• Enabling encryption on new Azure VMs created from a customer-encrypted virtual hard disk (.vhd
file) by using existing encryption keys.
• Enabling encryption on new Azure VMs created from Azure Marketplace images.
• Enabling encryption on existing Azure VMs that are already running in Azure.
Note: Azure Disk Encryption supports both managed and unmanaged disks.
Azure Disk Encryption is not supported for:

• Basic-tier Azure VMs.
• Classic Azure VMs.
• Integration with on-premises Key Management Service.

• Content of Azure Files (Azure file share), network file system (NFS), dynamic volumes, and software-
based Redundant Array of Independent Disks (RAID) volumes on Azure VMs. There is support for
encryption of volumes created by using Storage Spaces on Windows VMs and by using either mdadm
or Logical Volume Manager (LVM) on Linux VMs.
• Disabling encryption on the OS drive for Linux VMs. For Linux VMs, you can disable encryption on
data drives. For Windows VMs, you can disable encryption on both OS and data drives.
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 the Azure platform to read BitLocker encryption keys and DM-Crypt passphrases from
it. When applying encryption to new or existing volumes, you also must set up an Azure AD application
with write permissions to the vault. This application provides a security context for Azure, allowing it to
securely store newly generated cryptographic material. In addition, you must configure the vault access
policy to allow the Microsoft.Compute resource provider and Azure Resource Manager to retrieve its
secrets during VM deployments. Finally, you must enable encryption on new or existing Azure Resource
Manager Azure VMs. Details 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, refer to: “Azure Disk Encryption for Windows
and Linux IaaS VMs” at: http://aka.ms/Jvkb03
Additional Reading: For more information about Azure’s general security practices, refer
to: http://aka.ms/Guhssp

Question
What is the maximum number of fault domains that scale sets support?
Two
Three
Five
20
50
Lesson 2
Managing disks of Azure VMs
Azure VMs use disks for different purposes, including OSs, data, and temporary storage. In this lesson, you
will learn about management and configuration of these disks. You will also learn how to attach new and
existing disks to an Azure VM, and how to configure multi-disk volumes in Windows and Linux VMs.
Lesson Objectives
• Describe different methods of managing Azure VM disks.
• Describe Azure support for VM disk mobility.

• Describe how to manage disk volumes in Azure VMs.
• Configure storage in Windows and Linux VMs.
Managing VM disks
When creating a VM based on an image, the
Azure platform will automatically provision a new
OS disk. Alternatively, you can create a new Azure
VM based on an existing disk. You would do this
when you migrate a VM from your on-premises
environment to Azure. Similarly, you can attach
one or more new or existing data disks to an
Azure VM, up to the limit determined by its size.
Attaching a disk to an Azure VM

To attach a disk to an Azure VM, you can use a
variety of methods, including the Azure portal,
Azure PowerShell, Azure CLI, or Azure Resource
Manager templates.
When using the Azure portal, take the following steps:
1. Navigate to the blade of the Azure VM to which you want to attach new disks.
2. On the VM blade, click Disks, and then click Add data disk. When using managed disks, you will
then be able to select any currently available managed disk in the same region and subscription, or
use the Create disk option.
3. Depending on the type of disks currently attached to the VM, the Azure portal will display either the
Create managed disk or Attach unmanaged disk blade. With unmanaged disks, you will be able to
choose either New (empty disk) or Existing blob as the source type. With managed disks, your
choices are Snapshot, Storage blob, and None (empty disk). With unmanaged disks, when
referencing a new or existing blob, you must provide the storage account and its container. Similarly,
with managed disks, when selecting a source blob, you will need to specify its exact location,
including the storage account and container. In addition, you will have to specify whether the blob is
a data disk or whether it contains the Windows or Linux OS installation. When using a snapshot as the
new disk’s source, you simply select the name of an existing snapshot in the same subscription and
region as the Azure VM.
Note: Managed disks simplify snapshot management. The Azure portal allows you to create
snapshots from existing managed disks and create new disks from an existing snapshot. The
snapshot creation is almost instantaneous. Note that at the time of authoring this content,
managed disks support only full snapshots. Unmanaged disks offer support for incremental
snapshots.
The same functionality is available when using Azure PowerShell or Azure CLI. For example, to attach a
new unmanaged data disk by using Azure PowerShell, you would run the following commands:
Add-AzureRmVMDataDisk –ResourceGroupName <Resource Group name> –VM <VM object> -Name <Disk
name> -VhdUri <URI of the blob representing the disk in the storage account> -CreateOption
Empty –DiskSizeInGB <Disk size in GB> -LUN <LUN number> -Caching <ReadOnly, ReadWrite, or
None>
Update-AzureRmVM –ResourceGroupName <Resource Group name> -VM <VM object>
To attach a new managed disk by using Azure PowerShell, you would run the following commands:
$mdConfig1 = New-AzureRmDiskConfig -AccountType <PremiumLRS or StandardLRS> -Location

<Azure region> -CreateOption Empty -DiskSizeGB <disk size in GB>
$md1 = New-AzureRmDisk -DiskName <Disk name> -Disk $mdConfig1 -ResourceGroupName <Resource
Group name>
Add-AzureRmVMDataDisk -VM <VM object> -Name <Disk name> -CreateOption Attach -
ManagedDiskId $md1.Id -Lun <LUN number> -Caching <ReadOnly, ReadWrite, or
Update-AzureRmVM –ResourceGroupName <Resource Group name> -VM <VM object>
Additional Reading: For more information, refer to: “Attach a data disk to a Windows VM
using PowerShell” at: https://aka.ms/sn9u6r
To create a snapshot by using Azure PowerShell, run the New-AzureRmSnapshot cmdlet. If you prefer
Azure CLI, you can use azure snapshot create instead. Creating snapshots of unmanaged disks requires
programmatic methods.
Additional Reading: For more information, refer to: “Create a blob snapshot” at:
https://aka.ms/qnxnaz
Detaching a disk from an Azure VM

You can use the same tools to detach a disk from an Azure VM as you use to attach a disk, including the
Azure portal, Azure PowerShell, and Azure CLI.
To detach an Azure VM data disk by using the Azure portal, use the following steps:
1. In the Azure portal, navigate to the blade of the VM from which you will detach the disk, and then
click Disks.
2. On the Disks blade, click Edit.
3. Click an icon to the right of the disk that you intend to detach, and then click Save.
Note: You cannot detach the OS disk. To make the OS disk available (for example, to use it
when creating another Azure VM), you must first delete the Azure VM.
To detach a disk by using Azure PowerShell, use the following commands:
Remove-AzureRmVMDataDisk –VM <VM object> -DataDiskNames <Disk name>

Update-AzureRmVM –ResourceGroupName <Resource group name> -Name <VM name> -VM <VM object>
To detach a disk by using Azure CLI, use the following command:
az vm disk detach –name <Disk name> --resource-group <Resource group name> --vm <VM name>
Modifying Azure VM disks

You can modify an existing Azure VM disk configuration by:
• Switching the host caching mode of the disk between None, Read-only, and Read/write.
• Increasing size of the disk (up to the 4-terabyte [TB] limit).

• Switching the storage account type between Standard local redundant storage (LRS), Standard geo-
redundant storage (GRS), or Standard read-access geo-redundant storage (RA-GRS) (unmanaged,
standard storage disks only).
Note: Managed disks support only the Standard_LRS storage account type.
• Switching the performance tier between Standard and Premium (managed disks only, if the VM size
supports Premium storage).
You can change the host caching mode from the Azure VM’s disks blade. You can change the size,
resiliency, and performance tier from the blades of individual disks. To modify disk settings by using Azure
PowerShell, run the Set-AzureRmVMDataDisk cmdlet, followed by the Update-AzureRmVM cmdlet. To
accomplish the same task by using Azure CLI, run az disk update.
Azure VM disk mobility
Cross-premises Azure VM disk

operations
When you create a VM based on an image, the
Azure platform automatically provisions a new OS
disk. Alternatively, you can attach an existing disk
containing an OS to a new Azure VM. This
typically happens when you migrate a VM from
your on-premises environment to Azure. Similarly,
you can attach either new (empty) or existing data
disks to any Azure VM, up to the limit determined
by its size.
When migrating on-premises disks and images to Azure, remember that on-premises Hyper-V virtual
hard disks can use either the .vhd or the the .vhdx format. At the time of authoring this course, Azure does
not support the .vhdx format. Effectively, if you intend to upload an on-premises .vhdx file to Azure and
use it to provision a new Azure VM, you must first convert it to the .vhd format. You use the Edit Virtual
Hard Disk Wizard in the Hyper-V Manager console for this purpose.
Other considerations when migrating .vhd files from your on-premises Hyper-V servers include:
• The 4-TB limit on the size of .vhd files in Azure. If your virtual disks exceed this limit, try compressing
them or splitting them into multiple disks (subsequently, you can create a multidisk volume in an
Azure VM to provide the matching drive size).
• Lack of support for dynamically expanding .vhd files in Azure. Effectively, you will need to make sure
that you convert any virtual disks to a fixed format before you upload them into an Azure Storage
account.
To upload a .vhd file into Azure, you can use the Add-AzureRmVHD Azure PowerShell cmdlets. This will
automatically store the file as a page blob in the target storage account that you specify (as part the
Destination parameter of the cmdlet). Conversely, you can use Save-AzureRmVHD to download .vhd files
from Azure Storage to your on-premises virtualization environment.
In addition to providing robust data transfer functionality, these cmdlets offer many advantages:
• Add-AzureRmVHD automatically converts dynamic disks to fixed format, eliminating the need to
perform this step prior to the transfer.
• Add-AzureRmVHD and Save-AzureRmVHD inspect the content of .vhd files and copy only their
used portion, minimizing the duration of data transfers.
• Add-AzureRmVHD supports uploads of differencing disks when the base image already resides in
Azure Storage. This minimizes the time and bandwidth it takes to upload an updated version of the
image.
• Both cmdlets support multithreading for increased throughput. To apply multithreading, use the
NumberOfUploaderThreads parameter.
• Both cmdlets allow you to access the target Azure Storage account by using a Shared Access
Signature (SAS) token instead of a storage account key. This allows you to restrict the permissions of
the person performing the upload or download to an individual storage account blob container or an
individual blob. You can also specify the time window during which the SAS token is valid.
Additional Reading: For details regarding SAS, refer to Module 6, “Planning and
implementing storage, backup, and recovery services.”
Note: You can accomplish the same outcome by using the az storage blob upload and az
storage blob download Azure CLI commands.
Once the file resides in Azure Storage, you can use the Azure portal, Azure PowerShell, or Azure CLI to
attach disks to a VM. For example, the Add-AzureRmVmDataDisk cmdlet supports attaching an existing
data disk to an Azure VM. Conversely, you can use Remove-AzureRmVmDataDisk cmdlets to detach an
existing data disk from an Azure VM.
Note: The equivalent Azure CLI commands are azure vm disk attach-new and azure vm
disk detach, respectively.
In addition to facilitating upload and download of .vhd files, Azure also offers the Import/Export service.
This service allows you to transfer physical disks between on-premises locations and Azure Storage
whenever the data volume makes it too expensive or unfeasible to rely on network connectivity.
The process involves creating either import or export jobs, depending on the transfer direction:
• You create an import job to copy data from your on-premises 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. When the drives arrive, the Azure datacenter
operations team completes the request and ships the drives back to you.
Azure VMs disk copy and snapshot operations

The concept of disk mobility applies not only to cross-premises uploads and downloads, but also to
operations that involve creating copies and snapshots of .vhd files within Azure. You can use different
methods to copy Azure Storage blobs, including the Start-AzureStorageBlobCopy Azure PowerShell
cmdlet and its Azure CLI equivalent, az storage blob copy that can perform asynchronous copy of a blob
between two Azure Storage accounts. These tools facilitate copy operations of both managed and non-
managed disks and images.
To create a snapshot of a managed disk or an image, you can use the New-AzureRmSnapshot Azure
PowerShell cmdlet or its Azure CLI equivalent, az snapshot create. If you take a snapshot of an image,
you can use it to create a new image. Similarly, a snapshot of a disk allows you to create an exact replica
in the form of a managed snapshot.
You can copy managed snapshots across Azure regions and across Azure subscriptions. When the copy
completes, you can use it to create a managed image, allowing you to provision Azure VMs based on that
image within the target region and subscription. After you create an Azure VM by following this process,
you should delete the intermediate snapshots to avoid Azure Storage charges. At the time of authoring
this course, managed disks support only full snapshots, which means that the cost of each snapshot is
equal to the cost of the disk.
Additional Reading: Unmanaged disks support incremental snapshots via Snapshot Blob
REST API. This course does not cover Azure REST API. For more information, refer to: “Snapshot
Blob” at: https://aka.ms/f4pv4k
Additional Reading: You can perform many Azure Storage operations, including
uploads, downloads, copies, moves, and snapshots, by using the AzCopy tool available from
http://aka.ms/downloadazcopy. For more information, refer to: “Transfer data with the AzCopy
on Windows” at: https://aka.ms/osjyej
Managing disk volumes in Azure VMs

When you attach disks to an Azure VM, you
manage them as you would manage disks on a
physical machine or a VM deployed locally on
your Hyper-V server. On Windows VMs, this
involves using Storage Spaces, which you can
manage via Server Manager or Windows
PowerShell. On Linux VMs, for multidisk
configurations, you can use LVM or the
mdadm tool.
Creating multidisk volumes in Windows

Azure VMs
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 previous versions of Windows).
• Three-way mirroring, offering higher resiliency than two-way mirror or parity configurations.
Note: Azure Storage is highly resilient because it has three synchronously replicated copies
of the same content. However, this benefit does not offer a meaningful advantage in the case of
Azure VMs. Use the simple layout when creating multidisk volumes on Azure VMs.
• Support for volumes larger than the 4-TB limit of a single disk in Azure VMs.
To create a storage space in an Azure Windows VM, follow these steps:
1. Create a new VM running Windows Server 2012 or later. When using lower-tier VMs, remember that
they support fewer data disks.
2. Attach new, empty disks to the VM.
3. Connect to the Windows OS running in the VM by using the RDP client.
4. Ensure that the File Server role service is installed.
5. Open Server Manager, and navigate to File and Storage Services.

6. Click Storage Pools, and then click Tasks.
7. Click New Storage Pool, and then 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 then click Create.
10. The New Volume Wizard appears. Select the virtual disk that you created, choose a drive letter, and
then create the volume.
Creating multidisk volumes in Linux Azure VMs

Linux Azure VMs support the use of LVM and the mdadm tool to create multidisk volumes. The process of
creating such volumes is identical to creating multidisk volumes in on-premises computers running the
matching Linux distributions.
Additional Reading:
• For more information, refer to: “Configure LVM on a Linux VM in Azure” at: https://aka.ms/s665fp
• For more information, refer to: “Configure Software RAID on Linux” at: https://aka.ms/xmcbo6
Demonstration: Configuring Azure VM disks

In this demonstration, you will see how to attach a new data disk to an Azure VM.

Question
You have an Azure VM running Windows Server 2016 with a single 4-TB data disk.
You must create a file system volume of 12 TB in size. What should you do?
Attach two data disks. Create a Storage Spaces–based volume with the simple
layout.
Increase the size of the data disk.
Attach one disk. Convert data disks to dynamic disks and create a stripe.
Attach two disks. Create a Storage Spaces–based volume with the parity layout.
Convert the disk to Premium storage and increase the size of the data disk.
Lesson 3
Managing and monitoring Azure VMs
Azure offers several methods that simplify and enhance management of both Windows and Linux Azure
VMs. In this lesson, you will learn about these methods.
Lesson Objectives
• Explain the role of the VM Agent and VM extensions.
• Describe the VM Agent Custom Script extension.
• Describe the VM Agent Desired State Configuration (DSC) extension.

• Explain how to monitor Azure VMs.
• Configure Azure Resource Manager Windows Azure VMs with DSC.
Overview of VM Agent and VM extensions

When deploying Azure VMs, you implement
platform-specific configurations (such as Azure
Storage or virtual network settings). In addition,
you can configure the OS and workloads running
in the VM by using a software component called
the Azure VM Agent. While the VM Agent
includes its own useful features, one of its most
significant benefits is its support for loading
software components called VM extensions. VM
extensions implement additional functionality,
typically in the areas of management, monitoring,
or security.
Note: On Windows Azure VMs, the VM Agent is highly recommended but optional. On
Linux Azure VMs, the VM Agent is mandatory.
Additional Reading: For more information, refer to: “Understanding and using the Azure
Linux Agent” at: https://aka.ms/betzjc
VM images available from the Azure Marketplace include the VM Agent by default. When creating
custom images, you should install the agent manually, before generalizing the OS. The Windows VM
Agent is available from https://aka.ms/kz1pcf as a Windows Installer package. Linux versions of the VM
Agent are available for download from GitHub at https://aka.ms/hmnq48. On Windows VMs, after the
installation completes, you must set the ProvisionGuestAgent property of the Azure VM by using the
Update-AzureVM Azure PowerShell cmdlets.
After you install the agent, you can proceed with adding VM extensions. Some of the more commonly
used VM extensions include:
• Azure VM Access extension. On Windows VMs, this extension enables you to reset local administrative
credentials and fix misconfigured RDP settings. On Linux VMs, it enables you to reset the admin
password or SSH key, fix misconfigured SSH settings, create a new sudo user account, and check disk
consistency.
• Chef Client and Puppet Enterprise Agent. These extensions integrate Windows and Linux VMs into
cross-platform Chef and Puppet (respectively) enterprise management solutions.
• Custom Script extension for Windows. This extension enables you to run custom Windows PowerShell
scripts within Azure VMs. The most common use of the Custom Script extension involves applying
custom configuration settings during VM provisioning. However, you can also use it to perform any
scriptable action after the initial deployment. Scripts can reside in an Azure Storage or GitHub. If you
are deploying a Windows VM from the Azure portal, you can also provide the script at the
deployment time.
• Custom Script extension for Linux. This extension is equivalent to its Windows counterpart, enabling
you to run custom scripts within Linux Azure VMs. The extension supports any scripting language that
the OS supports, such as Python or Bash. Scripts can reside in Azure Storage or any internet-
accessible location.
• DSC extension for Windows. This extension implements a Windows PowerShell–based configuration
of Windows components and applications, including the ability to modify settings such as files,
folders, registries, services, or an OS feature.
• DSC extension for Linux. This extension implements a template-based configuration of Linux OSs,
equivalent to what Windows PowerShell DSC provides for Windows.
• Azure Diagnostics extension. This extension enables Azure VM diagnostics that collect data from the
OS and its components on both Windows and Linux VMs. The extension copies data to Azure
standard storage, allowing for long-term storage and further analysis by using business intelligence
tools.
• Docker extension. This extension facilitates automatic installation of Docker components, including
the Docker daemon, Docker client, and Docker Compose on Linux VMs. This simplifies the process of
implementing and managing containerized workloads.
• Microsoft Antimalware extension. This extension helps protect against viruses, spyware, and malware
on Windows VMs in real time.
Additional Reading: For more information, refer to: “Virtual machine extensions and
features for Windows” at: http://aka.ms/B8t3pl and “Virtual machine extensions and features for
Linux” at: https://aka.ms/jpzwcw
What is the VM Agent Custom Script extension?

The Custom Script extension for Azure VMs
enables you to invoke local execution of scripts
within a Windows or Linux Azure VM. On the
Windows OS, you can implement scripts by using
Windows PowerShell. The extension for the Linux
OS allows you to run code written in any scripting
language, such as Python or Bash, that the OS
supports.
The most common use of the Custom Script

extension involves applying custom configuration
settings during VM provisioning. However, you
can also use it to perform any scriptable action
after the initial deployment. The script can reside in an Azure Storage account or a GitHub location. You
can also upload it directly from the Azure portal when installing the extension on an Azure VM.
Implementing the Custom Script extension via scripting

To implement the functionality described in this topic, you must install the Custom Script extension in the
OS hosted on an Azure VM that you intend to manage. Then you must assign the script that you want the
extension to execute. You can accomplish this either during VM provisioning or afterward, by running the
Set-AzureRmVMCustomScriptExtension Windows PowerShell cmdlet:
Set-AzureRmVMCustomScriptExtension -ResourceGroupName <Resource Group name> -Location

<Azure region> -VMName <VM name> -Name <Custom Script extension name> -TypeHandlerVersion
"2.3" -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 a combination of the
-StorageAccountName, -ContainerName, and -FileName parameters. To obtain access to the storage
account, you must provide the value of the storage account key (-StorageAccountKey). To specify the
command and the 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 Get-AzureRmVMExtensionImage
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 VM.
Alternatively, you can use the Set-AzureRMVMExtension Azure PowerShell cmdlet and specify
CustomScriptExtension as the value of its -ExtensionType parameter. You can use hash tables to assign
values to its -Settings and -ProtectedSettings parameters, as shown below:
$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 "2.3" –Settings $settings –
ProtectedSettings $protectedSettings
This cmdlet is like Set-AzureRmVMCustomScriptExtension. For example, it also uniquely identifies the
target Azure VM by using the combination of -ResourceGroupName, -Location, and -VMName. On the
other hand, it relies on the two hash tables 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 VMs running the Linux OS, you would set the
-Publisher parameter to Microsoft.OSTCExtension and the -ExtensionType parameter to
CustomScriptForLinux.
Additional Reading: To accomplish the same objective by using Azure CLI, run the az vm
extension set command. For more information, refer to: “Using the Azure Custom Script
Extension with Linux Virtual Machines” at: https://aka.ms/stuho4
Implementing Custom Script extension via Resource Manager templates

You can also use Resource Manager templates to implement the Custom Script extension. The imperative
method (based on the Set-AzureRmExtension cmdlet) and declarative method (based on the Azure
Resource Manager template presented here) are interchangeable. They support the same set of
parameters and allow you to deploy the same types of scripts. As an example, the following template
demonstrates how to apply a script named script1.ps1 to an Azure VM 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": "2.3",
"settings": {
"fileUris": [
"http://storageaccountname.blob.core.windows.net/customscriptfiles/script.ps1"
],
"commandToExecute": "powershell.exe -ExecutionPolicy Unrestricted -File script.ps1"
}
}
}
Additional Reading: For more information, refer to: “Custom Script Extension for
Windows” at: https://aka.ms/rsj60b and “Using the Azure Custom Script Extension with Linux
Virtual Machines” at: https://aka.ms/nvkum3
What is the VM Agent DSC extension?

Windows PowerShell DSC is a technology
introduced in Windows Management Framework
4.0. It implements template-based configuration
of Windows and Linux OSs, both on-premises and
in the cloud. DSC leverages functionality
incorporated into Windows Management
Framework; however, to implement it in Azure
VMs, you rely on the VM Agent DSC extension.
You can apply it to Azure VMs by using the Azure
portal, Azure PowerShell, Azure CLI, and Azure
Resource Manager templates.
DSC relies on the Local Configuration Manager
(LCM) component, which serves as the execution engine of the Windows PowerShell DSC scripts. LCM is
responsible for coordinating implementation of DSC settings and monitoring their ongoing status. Like
DSC, LCM 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 determines how LCM handles
Windows PowerShell DSC scripts:
• ApplyOnly. LCM executes the script only once.
• ApplyAndMonitor. LCM executes the script only once, but then monitors the resulting configuration
and records any configuration drift in logs.
• ApplyAndAutoCorrect. LCM executes the script in regular intervals, automatically correcting any
configuration drift.
DSC relies on software components 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 OS feature. DSC includes a number of built-in 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). This topic covers the push mode. You will find more
information regarding the pull mode in Module 11, “Implementing Azure-based management and
automation.”
Creating Windows PowerShell DSC configuration scripts

DSC scripts utilize syntax that is enclosed in the configuration construct. Windows PowerShell 4.0
(included in Windows Management Framework 4.0) introduced this syntax to define the intended OS
configuration.
Note: In general, you must convert Windows PowerShell DSC scripts into Management
Object Format (MOF) node configuration files by using Windows PowerShell cmdlets to compile
them. However, Azure PowerShell handles the compilation automatically when deploying DSC
extensions to Azure VMs running the Windows OS.
For example, the following .ps1 file instructs the LCM running on the local computer to install the Internet
Information Services (IIS) server role and the ASP.NET 4.5 feature, and to disable the default website. Note
that a custom DCS resource facilitates disabling the default website. You import this resource by adding
the Import-DscResource cmdlet. In addition, as the presence of the DependsOn element demonstrates,
you can control the sequence in which tasks are executed 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 VMs

Applying DSC to an Azure VM running Windows involves a sequence of steps. Here is an example of an
implementation procedure that relies on an Azure Storage account to host a configuration script:
1. Sign in to your Azure subscription by using the Add-AzureRmAccount cmdlet. If you have multiple
subscriptions associated with the same account, ensure that you select the target one by using the
Select-AzureRmSubscription cmdlet:
Add-AzureRmAccount
2. Publish the 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 in the previous section), a Windows
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 that
the configuration references, and then upload this archive into the Azure Storage location that you
specified.
3. Create a Shared Access Signature (SAS) token that will provide access to the archive configuration file
residing in the Azure Storage account. An SAS is a digitally signed string that identifies an Azure
Storage object and determines access permissions to that object. In this case, Read permissions will
suffice. To create an SAS token, you must first establish the security context for access to the target
Azure Storage account. To do so, you must 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 SAS and other Azure Storage–related topics in more detail in
Module 6, “Planning and implementing storage, backup, and recovery services.”
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 SAS 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
VM. 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.9’ -Settings $settingsHashTable
Alternatively, as with the Custom Script extension, you can use the extension-specific Azure
PowerShell cmdlet Set-AzureRmVMDscExtension.
Additional Reading: For more information, refer to: “Azure.Service” at:

http://aka.ms/Cyyypz
Note: As with Custom Script extension scripts, you can reference DSC configuration files
residing in either an Azure Storage account or a GitHub location.
Additional Reading: To accomplish the same objective by using Azure CLI, run the az vm
extension set command. For more information, refer to: https://aka.ms/i3t1rj
You can also deploy the DSC configuration by using the Azure Resource Manager templates.
Additional Reading: For more information, refer to: “Windows VMSS and Desired State
Configuration with Azure Resource Manager templates” at: https://aka.ms/od8t5e
Implementing the AzureDSCForLinux extension

The VM Agent DSC extension extends DSC functionality to Azure VMs running the Windows OS. The
Azure DSCForLinux extension allows you to implement DSC on Azure VMs running the Linux OS. The
extension delivers its capabilities based on Open Management Infrastructure open source software
packages.
Despite obvious differences resulting from distinct OS platforms, DSC on Linux resembles DSC on
Windows in terms of architecture and procedure. They both rely on DSC resources to handle resource-
specific implementation details. They both follow the same syntax of a configuration document describing
the target state of a managed computer. To push configurations to computers running the Linux OS, you
can use the same Windows PowerShell cmdlets. Alternatively, you can use Azure CLI if you prefer.
To implement the DSCForLinux extension, start by creating a configuration document file and then copy
it to either an Azure Storage account or a GitHub location. Next, use Azure PowerShell or Azure CLI to
deploy the configuration to target Azure VMs. This step is similar to how you use the VM Agent DSC
extension for Windows. Note that you will need to adjust the -Publisher, -ExtensionType, and
-TypeHandlerVersion parameters accordingly.
Here is an example of an implementation procedure that relies on an Azure Storage account to host a
configuration script:
1. Sign in to your Azure subscription by running the Login-AzureRmAccount cmdlet. If you have
multiple subscriptions associated with the same account, make sure to select the target subscription
by using the Set-AzureRmSubscription cmdlet:
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.
3. Take 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 retrieve the configuration file when
implementing the DSC configuration.
4. Create variables that will contain values necessary for configuring the AzureDSCForLinux extension. As
with the Azure VM Agent DSC extension for Windows, these variables include two hash tables, which
you can implement as strings, as illustrated 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
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 New-AzureRmVMExtension cmdlet. The

-ResourceGroupName, -VMName, and -Location parameters identify the target Azure VM. 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 ‘2.6’ -SettingString $settings `
-ProtectedSettingString $protectedSettings
Additional Reading: For more information on implementing DSC configurations on Linux,

including template-based deployments, refer to: “DSCForLinux Extension” at:
https://aka.ms/v8aj7t
Monitoring Azure VMs
Like most Azure services, Azure VMs enable you to

track their performance, availability, and usage.
Some of this data is available directly from the
Azure portal. You can also collect Azure VM
metrics and diagnostics via Azure PowerShell and
Azure CLI scripts. In addition, you can collect this
data programmatically via the REST API and Azure
SDKs.
Collecting metrics and diagnostics of

Azure VMs
Azure VM monitoring data can originate from
several sources, including the hypervisor, guest OS, and workloads running within the guest OS. The
default metrics that you can view directly in the Azure portal represent data available to the Hyper-V
hosts where target VMs run. These metrics include the following:
• Percentage CPU
• Network In
• Network Out
• Disk Read Bytes

• Disk Write Bytes
• Disk Read Operations/Sec
• Disk Write Operations/Sec

You can gain more insight into performance and the state of an Azure VM’s OS by enabling diagnostics.
On Azure VMs running Windows, this allows you to collect data representing:
• Basic metrics (CPU, memory, disk, network, ASP.NET, Microsoft SQL Server)
• Performance counters
• Event logs (Application, Security, System)
• IIS logs and failed request logs
• Tracing output generated by Microsoft .NET applications

• Event tracing for Windows (ETW) events
• Crash dumps
• Application Insights data
• Boot diagnostics (recording output displayed on the VM console and providing its screenshots)
On Azure VMs running Linux, the selection is considerably more limited and includes basic metrics and
boot diagnostics.
To enable diagnostics, you must designate a standard storage account where the collected data will
reside. Consequently, there is a cost associated with enabling diagnostics, directly proportional to the
volume of data that you decide to collect.
You can customize the way the Azure portal displays an Azure VM’s metrics from its Metrics blade.
Similarly, to enable and configure collection of an Azure VM’s diagnostics, navigate to its Diagnostics
settings blade. The diagnostics functionality relies on the VM Agent Diagnostics extension, available for
Windows (IaaSDiagnostics) and Linux (LinuxDiagnostics). Enabling diagnostics automatically installs the
extension.
To view and analyze diagnostics and logs, you can use any tool that provides access to tables and blobs in
the Azure Storage account that is hosting collected data. You can export the data into Excel or any
business intelligence application (such as Power BI) for further analysis. In addition, you can stream
diagnostics data by using Event Hubs, which can then pipe it to non-Microsoft logging and telemetry
systems, including custom security information, event management, and analytics solutions.
Additional Reading: For more information, refer to: “Streaming Azure Diagnostics data in
the hot path by using Event Hubs” at: https://aka.ms/x6q8fd
Alerts
Alert rules allow you to trigger notifications according to metrics-based criteria that you specify. Each rule
includes a metric, condition, threshold, and time period that collectively determine when to raise an alert.
You can send an email containing the alert notification to any email address. It is also possible to route
alerts to an arbitrary HTTP or HTTPS endpoint (referred to as a webhook). In addition, you can invoke
execution of an Azure Automation runbook or start an Azure Logic App in response to an alert.
Note: If you are looking for a comprehensive management and monitoring solution for
your Azure VM environment, consider using Microsoft Operations Management Suite. You will
learn about it in Module 11, “Implementing Azure-based management and automation.”
Demonstration: Configuring Azure Resource Manager Azure VMs with DSC

In this demonstration, you will see how to apply DSC to an Azure VM running the Windows OS.

Question
You plan to capture an image of your on-premises Windows Server 2016 VM to

Azure, and then use it to deploy Azure VMs that you will manage by leveraging DSC.
What should you do prior to capturing the image?
On the Windows Server 2016 VM, install the Azure VM Agent.
On the Windows Server 2016 VM, install Windows Management Framework.
On the Windows Server 2016 VM, install the Azure PowerShell module.
Run sysprep with the specialize option.
Run sysprep with the mode:vm option.

Lesson 4
Managing classic Azure VMs
The first three lessons of this module focused on configuring, managing, and monitoring Azure VMs
deployed by using the Azure Resource Manager deployment model. However, it is possible that your
future experiences with Azure services might involve administering classic Azure VMs as well. The two
types of Azure VMs share many common characteristics; however, you should be aware of some
important differences between them. In this lesson, you will learn about some of these differences.
Lesson Objectives
• Configure class Azure VMs.
• Describe how to manage and configure classic VM storage.
• Explain how to monitor classic Azure VMs.
Configuring classic Azure VMs

One of the main distinguishing characteristics of
classic Azure VMs is their inherent dependency on
cloud services. Any VM you create by using the
classic deployment model becomes part of a new
or an existing cloud service. A cloud service
constitutes a logical boundary for Azure VMs it
contains, offering many 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 classic deployment model— a VM
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 a classic VM into a virtual network, you must implement that virtual network by using classic. In
other words, classic VMs require a classic VNet and, conversely, classic VNets support only classic 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.
External connectivity to classic VMs generally (with the exception of instance-level IP addresses, which are
described next) relies on cloud service endpoints. 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 Windows-classic VM automatically creates a
RDP and a WinRM endpoint. Similarly, provisioning a Linux VM results in the creation of an SSH endpoint.
You have the option of disabling any of them at the time of deploying the VM or at any point afterwards.
Keep in mind that disabling the endpoint affects only external connectivity, still allowing you to connect
to the VM from within the same cloud service or virtual network.
You can also create additional, custom 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.
Instance-level Public IP addresses

If you want 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 instance-level 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 classic Azure VMs also relies on the capabilities inherent to cloud services. To
configure Azure Load Balancing across VMs in a cloud service, you must create the load-balanced 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 classic 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 Azure VMs that belong to the same cloud
service. Just as with Azure Resource Manager VM–based availability set, each VM 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 (ACL)

A cloud service facilitates protection of its endpoints by allowing you to associate them with 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 classic VM storage

When managing and configuring disks and
images of classic Azure VMs, you should be aware
of some ways in which these VMs differ from
those deployed by using Azure Resource
Manager:
• Classic Azure VMs do not support managed
disks.
• Classic Azure Storage accounts do not

support many features available in the Azure
Resource Manager deployment model, such
as Storage Service Encryption.
• The classic model supports the default storage account of a subscription. You can use it to store disks
of Azure VMs during their provisioning process, without having to designate a specific storage
account explicitly.
Note that you can store disks of classic Azure VMs in a storage account that was provisioned by using the
Azure Resource Manager deployment model.
You can provision classic storage accounts by using the Azure portal, the Azure classic portal, Azure
PowerShell, and Azure CLI 1.0.
Note that command line management of classic VM disks also differs from managing their Azure
Resource Manager counterparts, because they use a different set of Azure PowerShell cmdlets. Starting
with Azure PowerShell 1.0, Azure Resource Manager-cmdlets 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
classic VM, you would use Add-AzureVMDataDisk, but to apply the same change to an Azure Resource
Manager VM, you would run Add-AzureRmVMDataDisk.
Monitoring and managing classic VMs

Monitoring options of classic VMs do not differ
significantly from the functionality available to
Azure Resource Manager 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.
In terms of OS management, the differences

between the two deployment models result
primarily from their specific set of Azure
PowerShell cmdlets. Another difference is the lack of support for template-based deployments regarding
classic VMs. In addition, Service Management–based Azure PowerShell scripts tend to be simpler. This
allows you, for example, to leverage the default storage account of your Azure subscription for storing not
only VM disks, but also Custom Script extension scripts or DSC configuration archives.
Just as with Azure Resource Manager VMs, Custom Script extension and DSC–based management are
available for classic VMs running both the Windows and Linux OSs.
Additional Reading: For more information, refer to: “Custom Script Extension for Windows
using the classic deployment model” at: http://aka.ms/Pcv1if

Question
Which one of the following tasks can be accomplished when provisioning a classic
VM without deploying it to a virtual network?
Assigning your own custom IP addressing scheme.
Configuring custom DNS name resolution.
Providing direct communication with VMs in the same cloud service.
Providing direct communication with VMs outside of the same cloud service.
Direct communication with on-premises systems by using Site-to-Site VPN.

Lab: Managing Azure VMs

Scenario
Now that you have validated basic deployment options of Azure VMs, you need to start testing more
advanced configuration scenarios. Your plan is to step through a sample configuration a two-tier A.
Datum ResDev application. As part of your tests, you will install IIS by using the VM DSC extension on the
front-end tier. You will also set up a multi-disk volume by using Storage Spaces in a Windows Azure VM in
the back-end tier.
Objectives
• Implement desired state configuration of Azure VMs.
• Implement Storage Space–based simple volumes in Azure VMs.
Note: The lab steps for this course change frequently due to updates to Azure. Microsoft
Learning updates the lab steps frequently, so they are not available in this manual. Your
User name: Student
Password: Pa55w.rd
Question: Why would you use Storage Spaces in an Azure VM considering that Azure
already provides highly available storage built into a storage account?

Review Question
Question: Can you use an OS disk of a VM from an on-premises Hyper-V host to deploy an
Azure VM?
5-1
Module 5
Implementing Azure App Service
Contents:
Module Overview 5-1
Lesson 1: Introduction to App Service 5-2
Lesson 2: Planning app deployment in App Service 5-12
Lesson 3: Implementing and maintaining web apps 5-16

Lesson 4: Configuring web apps 5-24
Lesson 5: Monitoring web apps and WebJobs 5-32
Lesson 6: Implementing mobile apps 5-37
Lesson 7: Implementing Traffic Manager 5-42
Lab: Implementing web apps 5-47
Module Overview
You can use Microsoft Azure virtual machines (VMs) for many purposes, including hosting web apps by
using Microsoft Internet Information Services (IIS) or Apache. However, you can also use the specialized
Azure App Service to host web apps, mobile apps, and application programming interface (API) apps
without deploying a dedicated Azure VM and installing the associated platform software. When you use
App Service, you can create a web app or choose from a wide range of common web applications,
including WordPress, Drupal, Umbraco, and others. Alternatively, you can upload a custom web
application from Microsoft Visual Studio or another web developer tool. In this module, you will learn how
to implement and manage highly scalable app services.
Objectives
• Explain the different types of apps that you can create by using App Service.
• Select an App Service plan and a deployment method for apps in Azure.
• Use Visual Studio, File Transfer Protocol (FTP) clients, and Azure PowerShell to deploy web and mobile
apps to Azure.
• Configure web apps and use the Azure WebJobs feature to schedule tasks.
• Monitor the performance of web apps.

• Create and configure mobile apps.
• Use Azure Traffic Manager to distribute requests between two or more app services.
5-2 Implementing Azure App Service
Lesson 1
Introduction to App Service
There is an increasing demand for organizations to deliver great mobile and web apps that engage and
connect with customers. These apps must work on any device and should consume and integrate with
data from anywhere. App Service provides a powerful platform that enables companies to build web and
mobile apps that can work on any device. These apps can integrate easily with other software as a service
(SaaS) apps, such as Microsoft Office 365, Microsoft OneDrive for Business, and Facebook. They can also
and connect with enterprise on-premises apps, such as SAP, Oracle, and others. In this lesson, you will
learn about the features of App Service.
Lesson Objectives
• Describe the components of App Service.

• Describe the Web Apps feature of App Service.
• Describe the Mobile Apps feature of App Service.
• Describe the Logic Apps feature of App Service.

• Describe the API Apps feature of App Service.
• Describe the functionalities of the App Service Environment for PowerApps.
Demonstration: Preparing the lab environment for this module

Perform the tasks in this demonstration to prepare the lab environment. The Azure services you use in the
lab are described in this module.
Important: The scripts might delete objects that you have in your subscription. Therefore,
you should complete this course by using a new Azure subscription. You should have received
sign-up details and instructions for creating an Azure learning pass for this reason. Alternatively,
you can create a new Azure trial subscription. In both cases, use a new Microsoft account that has
not been associated with any other Azure subscription. This will eliminate the possibility of any
potential confusion when running setup scripts.
This course uses custom Azure PowerShell modules, including Add-20533DEnvironment to prepare the
lab environment for demonstrations and labs, and Remove-20533DEnvironment to perform clean-up
tasks at the end of the module.
Overview of App Service

App Service provides a comprehensive platform
for building cloud-based applications that users
can consume on any device. App Service provides
a hosted service that developers can use to build
mobile and web apps. Additionally, developers
can use this service to develop API apps and logic
apps, which provide integration with SaaS apps.
App Service replaced several separate Azure
services, including Azure Websites, Azure Mobile
Services, and Azure BizTalk Services, with a single
integrated service that offers a wider range of
features than its predecessors.
App Service provides a hosting platform for developing, building, and running the following app types:
• Web apps. Websites and web apps.
• Mobile apps. Backend services of mobile apps.

• API apps. RESTful APIs.
• Logic apps. Automated workflows that integrate SaaS apps.
Overview of Web Apps

The Web Apps feature is a platform of
technologies that enable you to build web apps in
Azure without having to deploy, configure, and
maintain your own Azure VMs. You can build web
apps by using the ASP.NET, PHP, Node.js, Java,
and Python frameworks and a range of
programming languages, such as C#, HTML5,
PHP, Java, Node.js, and Python. They also
integrate with common development
environments such as Visual Studio and GitHub.
Note: With Azure Web App on Linux, you

can also build apps by using Microsoft .Net Core and Ruby. Azure Web App on Linux is in
preview at the time of authoring this content.
Key features of Web Apps include:
• Gallery applications. You can use Azure Marketplace to deploy components of your custom solution,
such as blogging sites, frameworks, and ASP.NET starter apps. You can browse through the available
choices by navigating to https://aka.ms/bbebhj.
• Autoscaling. You can implement multiple instances of a web app to increase capacity and resilience.
Azure Load Balancer automatically distributes incoming requests between these instances. You also
can configure the autoscaling functionality to dynamically accommodate changes in web app usage.
• Continuous integration and deployment. You can deploy the web app code from cloud source-
control systems (such as Microsoft Visual Studio Team Services and GitHub), on-premises source-
control systems (such as Team Foundation Server TFS] and Git), and from on-premises deployment
tools (such as Visual Studio, FTP clients, WebMatrix, and MSBuild). You also can use continuous
integration tools, such as Bitbucket, Hudson, or HP TeamSite, to automate build, test, and integration
tests.
• Deployment slots. If you are using the Standard or Premium App Service plan, you can create multiple
staging environments, also referred to as deployment slots or staging slots, for each web app. For
example, you can create one slot for your production web app, and then deploy your tested and
accepted code there. You then can create a second slot that is your staging environment, and deploy
the new code to it to run acceptance tests. Each staging environment will have a different URL.
• Testing in production. When a new version of your staging-slot web app passes all the tests, you can
redirect a percentage of the traffic targeting the production site to it. This allows you to perform final
validation of the functionality included in the new version of the web app.
• Azure WebJobs. WebJobs run background processes for web apps, allowing you to offload most of
the time-consuming and central processing unit (CPU)–intensive tasks from the web apps. You can
perform common tasks, such as updating a database or moving log files by using WebJobs.
• Hybrid connections. You can implement hybrid connections from web and mobile apps in Azure to
access on-premises resources, such as Microsoft SQL Server databases. By using the Hybrid
Connection Manager, you can share the connection across multiple web apps or mobile apps. This
eliminates the need to open your perimeter network to inbound traffic.
• Azure virtual network integration. When using the Standard or Premium App Service plan, you can
connect your apps to an Azure virtual network. This allows you, for example, to persist content of
your web app in a database running on an Azure VM, without having to expose that virtual machine
to the internet. However, this capability relies on a point-to-site virtual private network (VPN)
connection between an App Service instance and an Azure virtual network, so it is subject to
performance and bandwidth limitations associated with the point-to-site VPN. You can avoid these
limitations by implementing the App Service Environment, which is a premium feature, to deploy
your web app directly into an Azure virtual network.
• Authentication and authorization. App Service can use cloud identity providers to authenticate and
authorize user access. At the time of authoring this course, App Service was offering built-in support
for five identity providers: Azure Active Directory (Azure AD), Facebook, Google, Microsoft accounts,
and Twitter.
Note: A number of key Web Apps features are also available in the other types of App
Service apps. These features include autoscaling, continuous integration, delivery and
deployment, hybrid connections, WebJobs, and support for authentication and authorization.
Web apps often require two supporting services–data storage and file storage. Data that the server-side
code formats into webpages and sends to users often resides in a database. In Azure, you can use the
Azure SQL Database service to host that database. Alternatively, you can provision a database on an Azure
VM or use Azure table storage. Web apps often include media files, such as images, videos, and sound
files. Typically, these media files do not reside in a database. Instead, you can use a storage account for
these types of files. To improve performance of data access, you can implement Azure Content Delivery
Network and Azure Redis Cache.
Overview of Mobile Apps

The Mobile Apps feature is a part of App Service.
It provides a platform for building and hosting
backend services for mobile applications. Mobile
Apps help developers address some of the
challenging requirements for modern mobile-
device apps, including:
• Storing and accessing structured data
• Receiving notifications in response to custom-

defined events
• Authenticating and authorizing users based

on Facebook, Twitter, Microsoft account, or
other identities
• Incorporating business logic
The Mobile Apps feature allows developers to build cross-platform apps that can run on Windows, iOS, or
Android. These apps can operate exclusively in the cloud or connect with your on-premises infrastructure,
for authentication and authorization purposes, for example. Developers can use a wide range of SaaS API
connectors for integration with cloud apps. They can benefit from the built-in push notification engine
that can send personalized push notifications to almost any mobile device that is using iOS, Android, or
Windows.
Mobile Apps is like Azure Mobile Services, which Microsoft will continue to support. However, Mobile
Apps has several advantages when compared to Mobile Services, including integration with Office 365,
Microsoft Dynamics CRM, Salesforce, and other popular SaaS apps. It supports Java and PHP backend
code and has built-in autoscaling and load-balancing capabilities. It also supports multiple deployment
slots for production and testing. Mobile Apps also provides alerts and log files for monitoring and
troubleshooting. Integration of Mobile Apps with New Relic provides deep insight into the performance
and reliability of mobile apps.
You can capitalize on these new features by converting existing solutions that you developed with Mobile
Services to Mobile Apps, in one of two ways:
• Migration. This process changes only the underlying environment without rewriting any code. After
you migrate your mobile apps, you can benefit from all the new features, such as WebJobs, custom
domain names, staging slots, autoscaling, and load balancing.
• Upgrade. This process is more complex because it requires code changes. Typically, you must create a
second mobile app instance, update the project to use the new software development kits (SDKs), and
then release the new mobile app.
Overview of Logic Apps

Logic apps automate business processes by linking
together cloud-based apps, such as
Office 365, Google Services, and Salesforce.
With the Logic Apps feature, you can use a visual
designer to combine connectors available from
Azure Marketplace for different integration
scenarios.
Logic Apps uses a workflow engine to implement

business processes that you designed and relies
on connectors to provide user access. Connectors
also facilitate initiating new workflow instances via
triggers based on events that you define. Each
step in the workflow is an action that accesses data or services through a connector. More advanced
integration scenarios can use rules, transformations, validations, and features that are part of BizTalk
Services.
When you develop your solutions, you can use core and enterprise integration connectors. Some of the
most common core connectors include:
• Office 365 Connector. Use this API to create an action that sends and receives emails, and manages
calendars and contacts in an Office 365 account.
• Microsoft OneDrive Connector. Use this API to create an action that connects to Microsoft OneDrive
to upload, delete, or list files.
• Yammer Connector. Use this API to create an action that connects to Yammer to post or receive new
messages.
• Facebook Connector. Use this API to create an action that connects to a Facebook account to publish
messages and pictures or retrieve comments.
• HTTP Connector. Use this API to initiate an HTTP listener to listen to an incoming HTTP request on
a URL.
Enterprise integration connectors can extend app services and provide integration and connectivity to
SAP, Oracle, DB2, Informix, and other enterprise-grade systems.
When you develop your solution, you can use connectors to implement poll triggers, push triggers, and
recurrence triggers. Triggers designate events that initiate execution of a logic app workflow. A common
poll-trigger scenario involves using an Azure Storage account or an Azure SQL database. You use the poll
trigger to check periodically for data changes and use new data as input for the workflow. Push triggers
listen to events on a designated listener. Recurrence triggers start a new workflow according to a schedule
that you define.
Additional Reading: For a list of supported connectors and API apps that you can use in
your logic apps, refer to: “Connectors list” at: http://aka.ms/Bcinbr
To create a logic app from the Azure portal:
1. Click New, click Web + Mobile, and then click Logic App.
2. On the Create logic app blade, fill in the following information, and then click Create. Configure the
following settings:
o Name. Enter a descriptive name.

o Subscription. Select your Azure subscription.
o Resource Group. Select an existing resource group or create a new resource group.
o Location. Choose the datacenter that is closest to your location.
3. After you create the logic app, the Logic App Designer blade appears, where you will be prompted
to choose a template for the design of your logic app. If you want to design the logic app without
relying on an existing template, click Blank Logic App. Some examples of existing templates include:
o When a new file is created in Dropbox, copy it to SharePoint
o Send an email when an item in a SharePoint list is modified
o Deliver an SMTP email on new tweets
Overview of API Apps

An API is a set of routines, protocols, and tools
that developers use for building software
applications. An API specifies how software
components should interact. APIs make building
blocks for developing apps. Developers often
need to build APIs that they can reuse in their
projects. API Apps is a hosted service that can help
developers build, host, and use APIs by using
popular development platforms, such as ASP.NET,
PHP, and Python. You can create an API app by
using the graphical interface in the Azure portal,
and then integrate it with Visual Studio for
developing, debugging, and managing. When you create a new API app, Azure generates the code that
enables different SaaS applications, such as Office 365 and Salesforce, to use the API app. An API app has
integrated support for Swagger API metadata, which describes the API’s capabilities and generates the
client code for accessing the API by using languages such as, C#, Java, and JavaScript.
Note: Swagger is a popular framework for APIs that provides interactive documentation,
discoverability of created APIs, and the ability to generate client SDKs. For more information,
refer to the Swagger website at: http://aka.ms/R09mma
You also can benefit from support for Cross-Origin Resource Sharing (CORS) by API apps. This allows
JavaScript to make API calls to domains other than the original domain of the JavaScript code. A common
scenario would be a JavaScript client running in a web app–www.adatum.com, for example–calling an API
that is part of an API app associated with a different domain, such as customapi.azurewebsites.net.
You can build an API app that triggers a workflow based on certain events or conditions. For example, you
can configure an app to look for specific data that a SaaS app generates, such as a string in a Yammer
feed. You can then develop a method that automatically initiates a specific action.
To create and configure an API app, perform the following steps:
1. Create an API app:
a. Open the Azure portal, and then sign in to your subscription.
b. Click New, click Web + Mobile, click See all, and then click API App.
c. On the API App blade, click Create.
d. On the API App blade, enter the following information, and then click Create:
 App name. Provide the unique name for your API app that will be appended with the
Microsoft-owned public domain namespace .azurewebsites.net.
 Subscription. Select the subscription in which you will provision the new API app.
 Resource Group. Select an existing resource group or create a new resource group.
 App Service plan/Location. Select an existing service plan or create a new App Service plan.
 Application Insights: Specify whether you want to include Application Insights in your app.
This helps you to detect and diagnose any issues in your app and identify its usage patterns.
2. Configure your API app:
a. In the Azure portal, select your API app.
b. On the API app blade, click Quickstart.
c. On the API app Quickstart blade, click the entry representing the development platform that
you intend to use. In this example, click ASP.Net.
d. On the ASP.Net blade:
 Create a starter backend API. Select this option to generate a sample API app backend.
You will be able to download the resulting project and then open and customize it in Visual
Studio. Once you complete your customizations, you can publish the code to the API app
backend.
 Connect your client. You have two options:
 Select CREATE A NEW APP and then download a personalized Windows project that
you can open in Visual Studio and that is preconfigured to work with your new hosted
API.
 Select CONNECT AN EXISTING APP.
 Get the tools. You can download Visual Studio Community tools for developing APIs
that can run on a variety of platforms and devices.
e. Back on the API App blade, scroll down to the API section, and then click API definition.
f. On the API Definition blade, you can set the endpoint that provides Swagger 2.0 JavaScript
Object Notation (JSON) metadata.
3. Generate the client code:
o Open your API app project in Visual Studio.

o In Solution Explorer, right-click your API app, point to Add, and then click REST API Client.
o In the Add REST API Client dialog box, ensure that the Swagger Url option is selected, and then
click Select Azure Asset.
o In the APP Service dialog box, ensure that you authenticated to the Azure subscription hosting
the API app, expand the resource group that contains the API app, and then click your API app.
o In the Add REST API Client dialog box, click OK. This will create a folder within your project that
includes the yourAPI.cs file. The file contains the REST API client code for your API app.
Overview of the App Service Environment

Business-critical apps often require highly scalable,
isolated, and dedicated environments. You can
use the App Service Environment to
accommodate this requirement. You can use the
App Service Environment to host web apps,
mobile apps, and API apps that require highly
scalable compute resources, isolation, and direct
virtual network connectivity.
At the time of writing this course, App Service

Environment is available in two versions: ASEv1
and ASEv2. Both versions offer the same core
capabilities for hosting highly scalable, multitier
workloads. However, there are several important differences between them, including the following:
1. Deployment model. ASEv1 supports both classic and Azure Resource Management deployment
models. ASEv2 supports only the Azure Resource Manager deployment model.
2. Scaling capabilities. ASEv1 has the default maximum limit of 55 instances. With ASEv2, by default, you
can deploy up to 100 instances per subscription. In both cases, you can request a limit increase by
contacting Azure support.
3. Management model. Management overhead in ASEv1 is higher compared with ASEv2. For example,
you must manage IP addressing of instances and explicitly increase or decrease the number of
instances before you can scale their App Service plan. To scale with ASEv2, you simply change the
number of instances associated with the App Service plan, and the platform automatically handles
provisioning of instances and their IP address assignments.
4. Pricing model. The cost of ASEv1 corresponds directly to the total number of cores. With ASEv2, there
is a flat monthly cost, regardless of the number of instances, in addition to per-core charges.
However, note that the ASEv1 App Service plans use the Premium pricing tier, while the ASEv2 App
Service plans use the Isolated pricing tier.
Note: You will learn more about App Service plans later in this module.
Both ASEv1 and ASEv2 consist of the front-end and worker tiers. The front-end handles incoming HTTP
and HTTPS requests, distributing them to the workers in a load-balanced manner. ASEv2 automatically
adjusts the number of front-end instances based on the number of worker instances that you specify
when scaling the corresponding App Service plan. By default, ASEv2 contains two front-end instances. For
every 15 worker instances, the platform automatically provisions an additional front-end instance. You can
change this ratio, but it will affect pricing.
In both ASEv1 and ASEv2, front-end and worker instances reside in a virtual network within one of its
subnets. Apps that run as part of the App Service Environment communicate with each other within the
virtual network. You can use Network Security Group (NSG) rules assigned to the subnet in which you
provision the App Service Environment to restrict inbound and outbound connectivity.
You can use one of the following methods to create an ASEv2:
• Create a new App Service app with a corresponding service plan and App Service Environment via the
Azure portal.
• Create an App Service Environment without a corresponding App Service app via the Azure portal.
• Create an App Service Environment via an Azure Resource Manager template.

To create an ASEv2 and a corresponding web app via the Azure portal, use the following procedure:
1. Sign in to the Azure portal.
2. In the hub menu, click + New, click Web + Mobile, and then click Web App.
3. On the Web App blade, in the Name box, type the unique name for the web app. The name will be
appended with the Microsoft-owned public domain azurewebsites.net.
4. Select the Azure subscription where you want to create the ASE.
5. In the Resource Group box, select an existing resource group or specify the name of a new resource
group that you want to create.
6. Set OS to either Windows or Linux.

7. Click App Service plan/Location.
8. On the App Service plan blade, click Create New.

9. On the New App Service Plan blade, specify a custom name that you want to assign to the service
plan, select the Azure region where you want to deploy the web app, and then click Pricing tier.
10. On the Choose your pricing tier blade, click one of the Isolated pricing tier stockkeeping units
(SKUs), and then click Select.
11. Back on the New App Service Plan blade, in the App Service Environment Name box, type the
unique name for your App Service Environment. The name will be appended with the Microsoft-
owned public domain p.azurewebsites.net.
12. In the Virtual Network/Location section, select an existing virtual network or create a new virtual
network. If you decide to use an existing virtual network, you will need to specify the name of a new
subnet and its IP address range. If you choose to create a new virtual network, you must specify its
name. The platform will provision it with the IP address space of 192.168.250.0/23 along with a
single subnet named default with the IP address range 192.168.250/0/24.
13. Click OK, and then click Create.
Note: At the time of authoring, you cannot use a pre-created subnet on an existing virtual
network when using the Azure portal to deploy an App Service Environment. Instead, you must
create a new subnet during the deployment.
To create an ASEv2 via the Azure portal without a corresponding App Service app and without assigning
an App Service plan, use the following procedure:
2. In the hub menu, click + New, click Web + Mobile, and then click App Service Environment.
3. On the All Service Environment blade, in the Name box, type the unique name for your App Service
Environment. The name will be appended with the Microsoft-owned public domain
p.azurewebsites.net.
4. Select the Azure subscription where you want to create the ASE.
5. In the Resource Group box, select an existing resource group or specify the name of a new resource
group that you want to create.
6. In the Virtual Network/Location box, select an existing virtual network or create a new virtual
network. If you choose to create a new virtual network, you must provide its location. The new virtual
network will have the IP address space of 192.168.250.0/23 and a single subnet named default with
the IP address range 192.168.250/0/24.
7. As part of the virtual network configuration, specify the VIP Type (External or Internal). For an
external virtual IP (VIP), specify the number of IP addresses that the platform should assign to it. The
number can range between one and 10. You will need more than a single IP address if you intend to
use IP-based Secure Sockets Layer (SSL). For an internal VIP, specify the name of a Domain Name
System (DNS) subdomain. The name of the subdomain, combined with the name you assigned to
App Service Environment in step 3, will form the URL of ASE-hosted apps.
8. Click Create.
Additional Reading: For detail regarding deployment of ASEv2 via an Azure Resource
Manager template, refer to: “Create an ASE by using an Azure Resource Manager template” at:
https://aka.ms/w556u8
Question: You work as a developer for your organization, and management asks you to list
the major benefits of using App Service. How would you answer?
Lesson 2
Planning app deployment in App Service
Architects and developers can choose from a few hosting and deployment options when designing and
implementing web solutions in Azure. This lesson describes these options. You will learn about the App
Service pricing tiers that allow you to scale Web Apps and provide the functionality that you need at
optimal cost. In addition, you will learn how the tools and source-code control systems that developers
use influence the choice of deployment methodology.
Lesson Objectives
• Identify the differences between Web Apps, Azure Cloud Services, and web apps hosted on
Azure VMs.
• Identify the differences between the App Service pricing tiers.

• Describe the different methods of deploying and updating code in App Service.
Comparing Web Apps, Azure Cloud Services, and Azure VMs

To host a web application in Azure, you can use
Azure VMs, Web Apps, or Azure Cloud Services.
When deciding which option to select, you must
consider the level of control, the flexibility with
which the application can scale, and the
programming languages and frameworks that you
want to use.
Note: The Azure Resource Manager

deployment model does not support Azure Cloud
Services.
Azure VMs
Because an Azure VM can host practically any web server, such as IIS or Apache, you can use it to host a
wide range of web applications. This scenario is similar to running a traditional web farm to host your web
application, except that the servers are at Azure datacenters and not in an on-premises environment.
Therefore, you typically use Azure VMs to migrate an on-premises web application into Azure with as little
modification as possible. You can host supporting servers, such as SQL Server instances that host
databases, on other VMs on the same or a directly connected virtual network. You can use Azure VM load
balancing or Azure VM Scale Sets to scale the web application horizontally.
If you choose to host a web application on Azure VMs, you have maximum control over their operating
system and supporting software components. For example, you can connect to them via Remote Desktop
Protocol (RDP) or Secure Shell (SSH), or install a specific version of middleware or a development
framework. On the other hand, maintaining these components will require extra time. In addition, unless
you use Azure VM Scale Sets, scaling out requires you to provision new Azure VMs.
Web Apps
Alternatively, you can choose to host your web application by using the Web Apps feature. After you
create a new web app, you can upload a custom web application code into it or deploy any of the Azure
Marketplace web applications, including Drupal, WordPress, and Umbraco.
You can scale web apps vertically by modifying the pricing tiers of their service plan, which changes the
workload volume that a single web app instance can service. You can also scale web apps horizontally by
changing the number of instances and relying on Azure built-in load balancing to distribute the traffic
across them. However, unless you are using App Service Environment, you cannot scale individual
components of a web app separately. You also cannot establish an RDP or SSH connection to the virtual
machine hosting a web app.
Cloud Services
You also can choose to build a web application as a cloud service. A cloud service consists of a web role,
which serves as the front-end of an application, and a worker role, which is responsible for running
background tasks. You can scale each role independently by specifying the number of role instances,
which gives you more control over scalability compared with web apps. Since role instances run Windows
Server, you can connect to them by using RDP.
Platform as a service (PaaS) cloud services are unique to Azure. Existing web applications might require
significant modification before they can run as a cloud service. You will learn more about Azure Cloud
Services in Module 8, “Implementing Azure Cloud Services.”
Managing App Service plans

App Service provides an abstraction layer between
web apps and virtual machines on which these
web apps are running. An App Service plan
defines the capabilities and capacity of virtual
machine resources available to its apps. It is
associated with a single subscription, an Azure
region, a resource group, a pricing tier, an
instance size, and an instance count. If an App
Service plan contains multiple instances of virtual
machines, then every app that is part of this plan
is running on every instance. You choose how
many App Service plans to create and how to
allocate App Service apps to these plans. You make this decision based on the apps’ resource
requirements and their need to scale independently of each other.
When you create an app in App Service, choose an existing service plan or create a new one. Multiple
web, mobile, and API apps can share a single App Service plan, but they each must belong to one and
only one App Service plan.
When you create a new App Service plan, you must provide a unique name and select an appropriate
pricing tier and Azure region. You can move apps that you create in one service plan into another, should
they require different capacity and scaling options. You can scale an App Service plan to meet the
demands of apps by changing the plan’s pricing tier, instance size, or instance count.
At the time of writing this course, there are seven available pricing tiers: Free, Shared, Basic, Standard,
Premium, Premium v2, and Isolated.
The Free pricing tier

App Service plans in the Free pricing tier allow you to create a maximum of 10 web, mobile, or API apps,
and limits you to 1 gigabyte (GB) of storage. You also can create up to 10 logic apps, free of charge. Plans
in this tier do not support custom domain names, so app DNS names have the azurewebsites.net DNS
suffix. You cannot scale out Free tier apps to multiple instances, and they do not qualify for any service
level agreement (SLA). When using mobile apps, you can facilitate communication and offline sync with
up to 500 devices per day, and with logic apps, you can initiate 200 actions per day. For logic apps that
use connectors, there is a limit of 200 calls per day for core connectors and enterprise connectors.
Additionally, the outbound traffic for apps is limited to 165 megabytes (MB) per day.
The Shared pricing tier

App Service plans in the Shared pricing tier have unlimited outbound data transfer and allow you to use
custom domains, although without Secure Sockets Layer (SSL) support. You cannot scale Shared tier apps
and they do not qualify for any SLAs. You can create up to 100 web, mobile, or API apps, and up to 10
logic apps in the Shared App Service plans. Other limits are the same as in the Free service tier, such as
limits on storage capacity, support for communication with mobile devices, and the number of calls per
day from core and enterprise connectors.
The Basic pricing tier

App Service plans in the Basic pricing tier provide up to 10 GB of storage. Additionally, they allow you to
use custom domains with SSL encryption. The Basic tier apps also qualify for the 99.9 percent uptime SLA,
and you can scale them up to three instances, with Azure load balancers to distribute the load. There are
no restrictions on the number of mobile devices but offline sync has a limit of 1,000 calls per day. The
number of calls per day from core and enterprise connectors can reach 200.
The Standard pricing tier

App Service plans in the Standard pricing tier provide up to 50 GB of storage and you can scale out apps
to 10 dedicated instances. Up to five staged publishing slots are available for Standard tier apps. There is
support for geo-distributed deployments and VPN hybrid connectivity. Apps can handle 10,000 logic
actions per day, and can serve calls from 10,000 core connectors and 200 enterprise connectors.
The Premium pricing tier

In addition to the features available in the Standard pricing tier, Premium App Service plans provide up to
250 GB of storage, support up to 50 instances, and can have up to 20 staging environments. This
facilitates deployment of enterprise-grade workloads that require a high degree of scalability.
The Premium V2 pricing tier

The Premium V2 pricing tier has most of the same characteristics as the Premium pricing tier, but it offers
twice as much memory per instance as the corresponding Premium tier instance sizes. There is also a CPU
performance benefit, since instances are implemented as Dv2 series virtual machines, which feature faster
processors than their Premium pricing tier counterparts.
Note: At the time of authoring this content, Premium V2 pricing tier is in Preview.
The Isolated pricing tier

Isolated pricing tier is available only when deploying apps as part of ASEv2. This provides you with
supreme scalability with up to 100 instances per service plan. Other features include direct connectivity to
Azure virtual networks, 1 terabyte (TB) of storage, and the same CPU and memory characteristics as the
corresponding Premium V2 instance sizes.
Additional Reading: For more information on App Service pricing tiers, refer to: “App
Service Pricing” at: http://aka.ms/Rgjtys
Comparing app deployment methods in App Service

Developers and web app administrators might
choose different approaches for deploying web,
mobile, logic, and API apps. They often make
these decisions based on the location of the
source code. In situations with an individual
developer or a very small team, developers
typically store source code on their computers, on
which they are running an integrated
development environment (IDE) that they use to
write code. For larger teams, the challenges of
working collaboratively often require the use of a
source-control system. Examples of such a system
include Microsoft Team Foundation Server (TFS) in an on-premises environment and Visual Studio Team
Services (VSTS) in the cloud.
Source code on client machines

If developers are not using a source-control system to coordinate development, they can deploy an app
to Azure directly from their chosen IDE, such as Visual Studio or WebMatrix via Web Deploy. They also can
use the command-line MSBuild tool, which integrates with Web Deploy, to script deployment processes. It
is also possible to perform code uploads by using FTP. However, Web Deploy offers extra features,
including the ability to update connection strings and to identify files to exclude from subsequent uploads
if their content has not changed. Another mechanism for deploying code is the Kudu engine. Kudu
supports version control, package restore, and webhooks for continuous deployment.
Source code in an on-premises source-control system

If developers are using a source-control system within their on-premises network, they can configure that
system to perform continuous deployment to an app service. The deployment should target a staging slot
to ensure that developers and testers can validate changes before they reach the production slot. On-
premises source-control systems include TFS, GitHub, and Mercurial repositories.
Source code in a cloud source-control system

If developers are using a cloud-hosted source-control system, such as Team Foundation Version Control
(TFVC) in VSTS, they can configure continuous deployment in a similar way to on-premises source-control
systems. There is a wide range of open-source solutions that extend the development and deployment
capabilities in this scenario. For example, developers can use Git as a distributed source-control system for
VSTS, instead of the centralized TFVC.
Additional Reading: For more information on deployment mechanisms, refer to: “Deploy
your app to Azure App Service” at: http://aka.ms/jyfupy
Question: Given the flexibility that you have when choosing an app-hosting model in Azure,
what key factors will influence your decision?
Lesson 3
Implementing and maintaining web apps
Web designers and developers can create web applications by using a variety of tools, such as graphic
design packages, image-editing packages, web design software, and IDEs, such as Visual Studio. Similarly,
there are many methods for packaging and deploying a web application to Web Apps. In this lesson, you
will learn about those methods. You will find out how to create Azure web apps and how to deploy and
update web application code by relying on Visual Studio and source-control software.
Lesson Objectives
• Explain how to create a new web app in Azure by using the Azure portal, Azure PowerShell, and
Azure Command Line Interface (Azure CLI).
• Explain how to use Web Deploy to deploy a web app to Azure from Visual Studio.
• Explain how to deploy updates to an existing web app.
Creating web apps

If you want to run a web application by using
Web Apps, you must create a new Web Apps
instance. This allows you or the developers to
deploy the web application’s code and content
into it. You can create this instance by using
several methods, including the Azure portal, Azure
PowerShell, Azure CLI, and Azure Resource
Manager templates.
You can also create a new Web Apps instance and

deploy your app into it directly from Visual Studio.
Make sure to include Azure SDK for .NET as part
of your Visual Studio installation. This will provide
you with access to graphical tools, command-line utilities, and client libraries that simplify the process of
deploying apps to Azure.
Creating new web apps in the Azure portal

To create a new web app in the Azure portal, perform the following steps:
1. On the toolbar to the left, click NEW, select the Web + Mobile link, and then click Web App.
2. On the Web App blade, in the App name text box, type a unique and valid name. If the name is
unique and valid, a green check mark appears. This name, along with the azurewebsites.net suffix,
will become the DNS name of the web app.
3. In the Subscription drop-down list, select your subscription.
4. In the Resource Group section, select an existing resource group or specify the name of a new
resource group that you want to create.
5. In the App service plan/Location section, select an existing plan or create a new App Service plan,
and then select the Azure region where you want your web app to run.
6. Specify whether to enable Application Insights.
7. Click Create. Azure then creates the new web app.
Creating new web apps by using Azure PowerShell

You also can create a new web app by using the New-AzureRMWebApp command in Azure PowerShell,
as shown below:
New-AzureRmResourceGroup –Name AdatumRG –Location eastus

New-AzureRmAppServicePlan –Name AdatumStandardPlan –ResourceGroupName AdatumRG –Tier
Standard
New-AzureRmWebApp –ResourceGroupName AdatumRG –Name WebAppName –Location eastus –
AppServicePlan AdatumStandardPlan
Creating new web apps by using Azure CLI

You also can create a new web app by using the az webapp create command in Azure CLI, as shown
below:
az group create –location eastus –name AdatumRG

az appservice plan create –name AdatumStandardPlan –resource-group AdatumRG –sku Standard
az webapp create –resource-group AdatumRG –-name WebAppName –plan AdatumStandardPlan
Creating a web app project and publishing it to a new web app by using Visual
Studio
1. Open Microsoft Visual Studio.
2. On the File menu, click New, and then click Project.
3. In the New Project dialog box, expand Installed > Templates > Visual C# > Web, and then select
the ASP.NET Web Application template.
4. In the New Project dialog box, enter the following information, and then click OK:
o Name. Provide a name for the project.
o Location. Provide a location to store the new project files.

o Solution name. Provide a name for the solution.
5. In the New ASP.Net Web Application dialog box, select the MVC template.
6. On the right side of the dialog box, click Change Authentication.
7. In the Change Authentication dialog box, ensure that No Authentication is selected, and then
click OK.
8. In the New ASP.Net Web Application dialog box, click OK.
9. In Visual Studio, in Solution Explorer, right-click your project, and then click Publish.
10. Ensure that the Microsoft Azure App Service icon and the Create New option are selected, and
then click Publish.
11. In the Create App Service window, click Add an account.
12. When prompted, specify the user name and password of an account with sufficient permissions to
create a new Web Apps instance, and then click Sign in.
13. Back in the Create App Service window, specify the following settings:
o Web App Name. Provide a unique name for your web app that will be appended with the
Microsoft-owned public domain azurewebsites.net.
o Subscription. Select your subscription.

o Resource Group. Select an existing resource group or specify the name of a new resource group
that you want to create.
o App Service Plan. Select an existing plan or create a new service plan by choosing the name of
the Azure region where you want to run your app, the pricing tier, and an instance size.
14. To complete the creation of the web app in your Azure subscription, click Create.
Deploying web apps

You can deploy your web apps by using several
methods, such as copying files manually by using
FTP, or synchronizing files and folders to App
Service from a cloud storage service, such as
OneDrive or Dropbox. App Service also supports
deployments by using the Web Deploy
technology. This approach is available with
Visual Studio, WebMatrix, and Visual Studio Team
Services.
If you want to perform deployments by using
Git or FTP, you must configure deployment
credentials. Knowledge of deployment credentials
will allow you to upload the web app’s code and content to the new web app, to make it available for
browsing.
Web Deploy
Web Deploy is a technology with client-side and server-side components. It allows you to synchronize
content and configuration metadata of web apps residing on IIS servers. You can use Web Deploy to
migrate content from one IIS web server to another, or you can use it to deploy web apps from
development environments to staging and production web servers.
The server-side components of Web Deploy require the IIS web platform. The client-side components are
available with a few Microsoft development tools, including Visual Studio and WebMatrix. Web Deploy
offers several advantages, including the following:
• Uploading only files that have changed. This minimizes upload times and the volume of network
traffic.
• Support for HTTPS protocol. This eliminates the need to open additional ports on a web server’s
firewall.
• Support for access control lists (ACLs). This further secures the target web server.
• Support for SQL scripts. This makes it possible to set up a database as part of a deployment
• Controlling web app configuration by modifying its web.config file. This allows you, for example, to
replace a database-connection string so that the web app that you deploy connects to a production
database, rather than a development database.
To use Visual Studio to deploy your project as an Azure web app, follow these steps:
1. In Visual Studio, open your project that contains the MVC application that you plan to deploy in
Azure.
2. In Visual Studio, in Solution Explorer, right-click your project, and then select Publish.
3. Ensure that the Microsoft Azure App Service icon and the Select Existing option are selected, and
then click Publish.
4. In the Publish Web dialog box, follow the Publish Web Wizard.
5. On the Profile tab, in the Select a publish target section, select Microsoft Azure App Service.
6. In the App Service dialog box, sign in to your Azure subscription, select your subscription, the
resource group containing the Azure web app, and the web app, and then click OK.
7. Verify that the autogenerated publish profile contains correct settings, including the Configuration
set to Release. To alter the default values, click Settings. This displays the Publish window.
8. On the Connection tab, ensure that the publishing method is set to Web Deploy, and then verify the
server, site name, user name, and destination URL. You can click Validate Connection to verify the
connectivity to App Service. Click Next to proceed.
9. On the Settings tab, verify that Release appears in the Configuration drop-down menu, and then
click Save.
10. Click Preview to identify the list of files that the deployment will contain.
11. Click Publish to begin the process of copying files to the Azure web app.
12. Upon a successful deployment, the updated web app will appear on a new tab within the Visual
Studio interface.
MSDeploy.exe
The Web Deploy client is available as a command-line tool, MSDeploy.exe. Visual Studio, WebMatrix, and
PowerShell cmdlets use this tool to execute Web Deploy operations. You can run MSDeploy.exe at the
command prompt manually or as part of a batch file.
Additional Reading: To download the MSDeploy.exe tool, refer to: “Web Deploy 3.6” at:
http://aka.ms/Fir58l
Setting up deployment credentials

If you use FTP or Git to deploy a web application’s content and code to an Azure web app, you cannot use
your Azure account credentials to authenticate. Instead, you must set up deployment credentials. To do
this in the Azure portal, perform the following steps:
1. In the hub menu on the left side, click More services, and then click App Services.
2. Click the web app for which you want to set up deployment credentials.
3. On the web app blade, click Deployment credentials.

4. On the Deployment credentials blade, in the FTP/deployment username text box, type the name
of the user you intend to create.
5. In the Password text box, type the password.

6. In the Confirm password text box, type the same password, and then click Save.
Downloading a publishing profile

You can generate a publishing profile for each web app that you create. This profile is an XML file with the
.publishsettings extension, which you can download from the Azure portal. It includes all the credentials,
connection strings, and other settings that are required to publish a web app from an IDE such as Visual
Studio.
Automating web app deployment by using Azure PowerShell, Azure CLI, and Git
You can use a variety of scripting techniques to automate the deployment process. For example, to
publish a web application project from a local Git repository to myWebApp in a resource group named
myResourceGroup, you could run the following Windows PowerShell script:
$gitRepoPath = ‘E:\Repos\myWebApp’
$webAppName = ‘myWebApp’
$propertiesObject = @{
scmType = ‘LocalGit’;
}
Set-AzureRmResource -PropertyObject $propertiesObject -ResourceGroupName myResourceGroup `
-ResourceType Microsoft.Web/sites/config -ResourceName $webAppName/web `
-ApiVersion 2015-08-01 -Force
$xml = [xml](Get-AzureRmWebAppPublishingProfile -Name $webAppName `
-ResourceGroupName myResourceGroup -OutputFile null)
$username =
$xml.SelectNodes("//publishProfile[@publishMethod=`"MSDeploy`"]/@userName").value
$password =
$xml.SelectNodes("//publishProfile[@publishMethod=`"MSDeploy`"]/@userPWD").value
git remote add azure "https://${username}:$password@$webappname.scm.azurewebsites.net"
git push azure master
You can accomplish the same objective by using Azure CLI:
gitrepopath = E:\Repos\myWebApp
username = myWebAppUser
password = Pa55w.rd1234
webappname = myWebApp
az webapp deployment user set --user-name $username --password $password
url = $(az webapp deployment source config-local-git --name $webappname \
--resource-group myResourceGroup --query url --output tsv)
cd $gitrepopath
git remote add azure $url
git push azure master
Deploying a web app by using FTP

FTP is an older protocol that is commonly used for uploading web applications to web servers.
FTP clients
Available FTP clients include:
• Web browsers. Many web browsers support FTP and HTTP. This means that you can use your web
browser to browse FTP sites and upload content. However, advanced features, such as automatic
retries in case of dropped connections, are not available in most browsers.
• Dedicated FTP clients. Several dedicated FTP clients are available as free downloads. The most
popular ones include FileZilla, SmartFTP, and Core FTP. Their advanced features, such as the ability to
handle hundreds of files, make them suitable for web app deployment.
• IDEs. Visual Studio and other IDEs support FTP for web app deployment.
Configuring an FTP transfer

To deploy a web app by using FTP, you must configure your client with the destination URL of the remote
FTP server and the credentials that FTP can use to authenticate. These are the Azure web app deployment
credentials. In addition, you must choose either the active or the passive FTP mode.
By default, FTP uses active mode. In this mode, the client initiates the session and issues commands from a
random port (N) targeting a command port on the server (usually TCP port 21). The client also starts
listening on the next consecutive port (N+1) for the server’s response. The FTP server initiates a
connection to the client from its data port (usually TCP port 20) targeting port N+1. The client uses this
new connection to perform an upload. The primary issue with active mode is that client-side firewalls
typically block inbound connections to random ports. In passive mode, the first part of the
communication between the client and the server is the same as in the active mode. However, in this case,
the server responds with a random port and the client initiates an outbound connection to that port. This
addresses the problem with client-side firewall restrictions on inbound connections.
Limitations of FTP
The main advantage of FTP is its wide use and broad compatibility. However, because FTP is an older
technology, not designed for uploading web apps’ code, it does not offer advanced features that are
available with Web Deploy. For example:
• FTP only transfers files. It cannot modify files or distinguish their use as part of the transfer. Therefore,
it cannot automatically alter the database connection strings in web.config.
• FTP always transfers all files that you select, regardless of whether they have been modified.
Updating web apps

App development typically continues even after
you deploy an app to Azure. Developers add new
features and fix bugs to improve the app and
optimize the user experience. How you implement
these changes depends on the location of the web
app source code and the deployment tool that
you choose.
If you use FTP for deployment, you should upload

new files, overwriting their older versions at the
destination. Since FTP cannot automatically detect
file changes, you must either identify the files to
update yourself or upload all files that a web app
includes. If you take the second approach, even a small update requires a lengthy upload operation.
However, if you use Web Deploy, MSDeploy.exe compares the files in the source and destination, and
then uploads only the modified files.
Continuous deployment and delivery

The continuous delivery model is a set of procedures and practices that optimize the process of
implementing development changes to code in a production environment. It does so while minimizing
risks associated with these changes. Continuous deployment is part of the continuous delivery model. It
involves regular and automatic builds and deployments of a project to a staging environment. If you
develop a web app by using a centralized source-control system, such as TFS or GitHub, you can
configure continuous deployment of that web app to Azure, on an automated schedule or in response to
any committed changes.
To enable and use continuous deployment, you must:
1. Connect the project to a web app. In the Azure portal, you must configure the location of your
source-code repository and provide credentials that the Azure web app can use to authenticate with
the repository.
2. Make one or more changes to the source code, and then commit them to the repository.
3. Trigger a build and deploy operation.
The precise steps involved in this configuration depend on the repository that you are using.
Additional Reading: For more information regarding continuous deployment to Azure

App Services, refer to: “Continuous Deployment to Azure App Service” at: https://aka.ms/worjdb
Staging and production slots

Before you deploy an updated code to an Azure web app, you should ensure its integrity and reliability.
Therefore, it is important to implement a strict testing and quality assurance regime that identifies any
issues before the update takes effect in the production environment. You can perform much of this
testing in the development environment. For example, you can run unit tests on developers’ computers.
However, the final testing location should be the staging environment. The staging environment should
match the production environment as closely as possible.
If you are using the Standard tier web apps, you can create up to five slots for each app. With the
Premium tier, this number increases to 20. You can create one slot for the production web app and
deploy the tested and accepted code there. You can create a second slot as the staging environment. You
can deploy the new code to this staging slot, and then use it to run acceptance tests. The staging slot has
a different URL than the production slot.
When the new version in the staging slot passes all tests, you can deploy it to production safely by
swapping the slots. This also provides a simple rollback path. If the new version causes unexpected
problems, you can swap the slots again to return the web app to its original state.
Best Practice: If you are using continuous deployment, you should never configure it to
deploy the code to a production web app. This results in insufficiently tested code in a user-
facing environment. Instead, you can configure deployment to a staging slot or a separate web
app, where you can run tests before final deployment.
When you swap a production and staging slot, by default, the values of the following settings in the
staging slot replace the values of the same settings in the production slot:
• General settings such as framework version and web sockets
• App settings
• Connection strings
• Handler mappings
• Monitoring and diagnostic settings
• WebJobs content
You can designate individual app settings and connection strings for a specific slot. This ensures that these
settings do not change following a slot swap. You can enable this functionality directly from the Azure
portal by selecting the Slot setting check box that appears next to each app setting and connection
string entry on the Application settings blade.
The following production slot settings do not change when you swap a staging slot into a production slot:
• Publishing endpoints
• Custom domain names
• SSL certificates and bindings
• Scale settings
• WebJob schedulers
Staging slots are available publicly, but because very few people know their URLs, internet users are
unlikely to connect to your web apps in their staging state. However, there are scenarios where you might
want to restrict access to your staging slot so that only your developers and the testing team can access it.
You can do this by adding the IP address white lists to the web.config file of the web app.
Note: You can perform a swap with preview. This applies slot-specific configuration from
the destination slot to the source slot but does not perform the swap right away. Instead, you
must complete the swap explicitly. This allows you to ensure that the swap takes place after the
source slot is fully operational. This approach eliminates the impact on web app responsiveness
during a short period in which compute resources are allocated to the source slot. This delay is
referred to as the warm-up period.
Demonstration: Deploying web apps by using Web Deploy

• Create a new web app in the Azure portal.
• Browse the new web app in the Azure portal.
• Obtain a publish profile.
• Deploy a web application to an Azure web app.
Demonstration Steps
Question: What are the benefits of deployments slots and how can you move your web app
between different slots?
Lesson 4
Configuring web apps
After you create and deploy a web app, you can customize the way it operates by modifying its
configuration. For example, you can configure SSL certificates to support encryption, link databases and
storage accounts to provide persistent storage, and scale the web app to address changing demand. In
this lesson, you will learn how to configure a web app for optimal performance and cost efficiency. You
will also find out how to use WebJobs to implement scripts that process web app background tasks.
Lesson Objectives
• Configure a web app’s application and authentication settings.
• Configure virtual networks and hybrid connectivity for web apps.
• Scale web apps.

• Create WebJobs to run background tasks.
Configuring a web app’s application and authentication settings

After you create your web app, you can configure
the following settings on the application settings
blade of the web app in the Azure portal:
• Framework versions. Use this setting to
select from the supported development-
framework version. Server-side code that
executes to render webpages requires a
framework, which developers select when
developing a web app. Azure web apps
running on Windows instances support the
ASP.NET, PHP, Java, and Python frameworks.
With Azure Web App on Linux, you can also
build apps by using .Net Core and Ruby.
• Platform. Use this setting to control whether to run the server code in 32-bit or 64-bit mode. The 64-
bit mode is available only for Basic, Standard, and Premium tier web apps.
• Web Sockets. Use this setting to enable web sockets, which allow for two-way communication
between a server and a client. Developers can build chat rooms, games, and support tools by using
web sockets.
• AlwaysOn. Use this setting to retain the app’s code in memory even if the web app is idle. This
eliminates the need to recompile and reload this code in response to new requests, following a period
of inactivity. This improves web app responsiveness, resulting in an improved user experience. The
AlwaysOn feature is available only for web apps in the Standard and Premium tiers.
• Managed Pipeline Version. Use this setting to assign either the integrated or classic mode to the
web app. An application pool that is running in the integrated mode benefits from the integrated
request-processing architecture of IIS and ASP.NET, so this is the default mode for new web apps.
Legacy apps that run in the classic mode, which is equivalent to the IIS 6.0 worker-process isolation
mode, use separate processes for IIS and ASP.NET, with duplicate processes for authentication and
authorization.
• ARR Affinity. Use this setting to improve load balancing of stateless web apps. Turning it off disables
the Application Request Routing (ARR)–based affinity cookie mechanism. When dealing with stateful
web apps, you should turn on this setting.
• Auto Swap. Use this setting to enable automatic swap between the production and staging
environments each time you upload new updates to the staging slot.
• Debugging. Use this setting to enable remote debugging and select the version of Visual Studio that
you intend to use during debugging sessions.
• App Settings. Use this setting to pass custom name/value pairs to your application at runtime. Work
with your development team to determine what settings the web app’s code requires. For example,
you can use an app setting to specify an administrator’s email address. The web app’s code could use
this setting to dynamically generate the site’s content.
• Connection Strings. Use this setting to enable the web app to connect to a data service, such as a
database, a caching server, an event hub, or a notification hub. Most web apps use an external data
service to store or consume data. You can use this setting to override static connection strings defined
in configuration files such as web.config.
• Default Documents. Use this setting to specify the pages that display by default when users connect
to your web app by using its DNS name. Work with your developers to ensure that the web app’s
home page appears in the default documents list. Optimize the web app by ensuring that the home
page is at the top of the list.
• Handler mappings. Use this setting to designate custom script processors that handle processing of
files with specific extensions, such as .php or .asp. To add a custom script processor, provide its path
and any additional command-line switches.
• Virtual applications and directories. Use this setting to add additional virtual applications and
directories to your web app by specifying their physical paths.
Diagnostics logs
You can access the diagnostics settings for a web app by clicking Diagnostics logs on the web app blade.
On the resulting blade, you can configure application logging by using either the file system or a blob to
collect the logs from the configured storage account. You also can configure collection of web server logs,
detailed error messages, and traces of failed requests.
Custom domain names

If you have registered a custom DNS domain name, such as adatumcorp.com, with a domain registrar,
you can assign that name to your Azure web app. All Azure web apps have default names in the
azurewebsites.net namespace. Custom domain names are available starting with the Shared pricing tier.
To assign a custom domain name to your Azure web app, in your DNS registrar, create a canonical name
(CNAME) resource record mapping to the web app’s default name. Alternatively, you can create an A
resource record that maps the custom domain name to the public IP address of the web app. If you are
migrating an existing web app to Azure, either option will result in temporary downtime corresponding to
the time it takes to assign a custom domain DNS record to an Azure Web app. To avoid this, you can
verify your domain ownership ahead of time by creating a domain verification record in the format
awverify.yourdomain, which maps to awverify.yourwebapp.azurewebsites.net.
Additional Reading: For details regarding migrating active DNS names to Azure App
Service, refer to: “Migrate an active DNS name to Azure App Service” at: https://aka.ms/gzgvjd
Certificates
If you want to use SSL to encrypt communications between the web browser and an Azure web app, you
must obtain and upload a certificate from a publicly recognized certificate authority. Use the web app’s
SSL certificates blade in the Azure portal to perform an upload. To use SSL with a custom domain, you
must ensure that the custom domain name matches either the Subject Name of the certificate or one of
the entries of its Subject Alternative Name property. After you upload the certificate, you can bind it to
the custom domain by using the SSL bindings section of the web app’s SSL certificates blade.
The following is the process for enabling HTTPS for a custom domain:
1. Create your SSL certificate that includes your custom domain name as the value of the Subject Name
or Subject Alternative Name property of the certificate. You also can use a wildcard certificate for this
purpose.
2. Assign either the Standard or Premium pricing tier to the service plan of the web app, because only
these tiers allow the usage of HTTPS with a custom domain.
3. Configure SSL for the web app by uploading the certificate and adding a corresponding SSL binding.
4. Enforce HTTPS for the web app (optionally) by configuring the URL Rewrite module, which is part of
App Service. URL Rewrite redirects incoming HTTP requests via an HTTPS connection.
Note: For more information on how to enable HTTPS for an app in App Service, refer to:
“Bind an existing custom SSL certificate to Azure Web Apps” at: http://aka.ms/X0xh9y
Configuring authentication and authorization in App Service

You can integrate web apps that require authentication and authorization with Azure AD or with on-
premises Active Directory Domain Services (AD DS) by using Active Directory Federation Services (AD FS).
Azure AD authentication supports the following authentication protocols, OAuth 2.0, OpenID Connect,
and SAML 2.0. If you configure your Azure AD to synchronize directories with your on-premises AD DS,
you can achieve a single sign-on (SSO) experience for AD DS users when they access your web app in
Azure. Furthermore, for authentication, you can configure other cloud authentication providers, such as
Microsoft accounts, Facebook, Twitter, or Google.
Advanced configuration of web apps by using ApplicationHost.config

You can use XML Document Transformation (Xdt) declaration in the ApplicationHost.config file to
control additional configuration for your web app. For example, you can configure custom environment
variables, add additional applications, define the runtime environment, and configure Azure site
extensions.
Additional Reading: For more information on how to use Xdt transform samples, refer to:
“Xdt transform samples” at: http://aka.ms/Rkzucb
Configuring virtual network connectivity and hybrid connectivity

Web apps and mobile apps might require a
connection to services that you implemented by
using Azure VMs. In such cases, you can integrate
App Service with the virtual network to which the
Azure VMs are connected. With virtual network
integration in place, apps can communicate with
Azure VMs that contain databases and web
services by using private IP addresses, eliminating
the need to expose Azure VMs to the internet.
The first lesson of this module presented the App

Service Environment feature, which allows you to
deploy App Service apps directly into a virtual
network. This is a high-end solution that requires an Isolated pricing tier, in the case of ASEv2. With
Standard, Premium, and Premium V2 pricing tiers, you can also connect App Service apps to a virtual
network via Point-to-Site (P2S) VPN. You can use this option if your bandwidth and latency requirements
fall within the performance range of a P2S VPN gateway. You must deploy a P2S VPN gateway into the
virtual network to support this solution.
To enable virtual network integration for your app, perform the following steps:
1. Sign in to the Azure portal, and then select the web app for which you want to configure virtual
network integration.
2. On the web app blade, click the Networking link.

3. In the VNET Integration section, click the Setup link.
4. On the Virtual Network blade, select an existing virtual network or create a new virtual network.
Note that the virtual network must have a virtual gateway to support P2S VPN. If you choose to
create a new virtual network, the platform will automatically provision a new gateway.
If you plan to connect App Service apps to on-premises resources, you can use hybrid connections. This is
possible without opening any inbound ports on the perimeter network, as long as the target resource
listens on a specific IP address and TCP port combination. One common scenario that leverages this
capability is connectivity to on-premises SQL Server instances.
From the architectural standpoint, a hybrid connection relies on the Azure Service Bus Relay residing in
Azure and a Hybrid Connection Manager (HCM) that you must install in your on-premises environment.
HCM requires direct connectivity to the resource you want to make accessible from App Service apps.
HCM also must be able to reach Azure via TCP ports 80 and 443.
To create a hybrid connection with your apps, perform the following steps:
1. Sign in to the Azure portal, and then select the web app for which you want to configure hybrid
integration.
2. On the web app blade, click the Networking link.
3. In the Hybrid Connections section, click the Configure your hybrid connection endpoints link.
4. On the Hybrid connections blade, click Add hybrid connection.
5. On the Add hybrid connection blade, click Create new hybrid connection.
6. On the Create hybrid connection blade, in the Hybrid connection Name text box, type a name
that will uniquely identify this connection.
7. In the Endpoint Host text box, type the fully qualified domain name (FQDN) of the on-premises
resource.
8. In the Endpoint Port text box, enter the static port for the on-premises resource to which you want
connect.
9. In the Service Bus namespace, select either the Create new or Select existing option.
10. In either case, you will need to provide the name and the Azure region of the Service Bus
namespace.
11. Click OK to confirm the creation of the hybrid connection.
12. After the hybrid connection is created, click it to configure connectivity.
13. On the Hybrid connection blade, click Download connection manager.
14. Follow the setup to install Hybrid Connection Manager on the on-premises Windows computer with
direct connectivity to the resource that you want to make available to your App Service apps.
Configuring availability and scalability

The scaling options for Azure web apps depend
on the pricing tier of their service plan. For the
Basic tier, you can increase only the size of an
individual instance or the number of instances. For
the Standard and Premium tiers, you can also
configure automatic scaling. This involves
specifying a metric that will trigger an increase or
decrease in the number of instances when it
reaches a threshold that you define. You can also
scale Standard or Premium service plan web apps
based on a schedule, which can be helpful if you
know when to expect fluctuations in demand. Free
and Shared pricing tiers do not offer support for horizontal scaling.
Additional Reading: For more information on scaling web apps, refer to: “Scale up an app
in Azure” at: http://aka.ms/Vaut94
To configure scaling for a web app, perform the following steps:
1. In the Azure portal, click the web app that you want to configure.
2. On the web app blade, click Scale Up (App Service plan).
3. In the Choose your pricing tier box, select Basic to configure simple static scaling. If you want to use
automatic scaling, select Standard or Premium.
4. On the web app blade, click the Scale Out (App Service plan) link.
5. On the Scale out blade, you can scale out by selecting a larger Instance Count.
6. For Standard and Premium tier web apps, you can configure automatic scaling. To start, click Enable
autoscale, and then configure one or more scale conditions. There are two types of scale conditions:
o Scale based on a metric. This involves specifying the following parameters:

 One or more rules. Each rule relates to a specific metric, such as CPU Percentage, Memory
Percentage, Disk Queue Length, Http Queue Length, Data In, and Data Out. You provide
additional criteria, such as time aggregation, threshold, and duration, that determine when
the rule takes effect.
 Instance limits. The limits dictate the minimum, maximum, and default number of instances.
 Schedule. This determines when evaluation of the rule should occur.
o Scale to a specific instance count. This involves specifying the following parameters:
 Instance count. This represents the number of instances that should be active when the scale
condition is in effect.
 Schedule. This determines when the scale condition should apply.
Best Practice: When using schedule for scaling instances, be aware that it can take several
minutes for each instance to start and become available to users. Therefore, ensure that you
allocate enough time between the schedule’s start and the point when you expect a change in
the utilization of web apps that are part of the same service plan.
Implementing WebJobs
The WebJobs feature of App Service enables you
to run automated background tasks in two
different ways:
• Continuously. Tasks continuously re-execute
their main method. For example, a task might
continuously check for the presence of new
files to process.
• Triggered. Tasks execute in two ways:
• Scheduled. Tasks run at times that you

specify.
• Manual. Tasks run whenever you decide to

execute them.
You can use WebJobs for maintenance tasks that do not involve web app content delivery to users and
that you can schedule outside of web app peak usage times. For example, these tasks might include
image processing, file maintenance, or aggregation of Really Simple Syndication (RSS) feeds.
Best Practice: By default, web apps unload and stop after prolonged periods of inactivity.
This also interrupts any WebJobs in progress. To avoid these interruptions, enable the AlwaysOn
feature.
You specify the operations that a WebJob performs by creating a script file. This file can be a:
• Windows batch file
• Windows PowerShell script
• Bash shell script
• PHP script
• Python script
• Node.js script
The type of script that you create depends on your own preferences. For example, if you are a Windows
administrator with little web development experience, you might want to code WebJob operations as an
Azure PowerShell script, rather than as a Node.js script.
Creating a WebJob
To create a WebJob, first compress your script file and any supporting files that it requires into a .zip file,
and then perform the following steps:
1. In the Azure portal, click the web app that you want to configure with a WebJob.
2. On the web app blade, click the WebJobs link.
3. On the WebJobs blade, click Add.
4. On the Add WebJob blade, in the Name text box, type a name that will identify the new WebJob.
5. Click the folder icon next to the File Upload text box.
6. In the Open dialog box, browse to the script file that you created, and then click Open.
7. In the Type drop-down list, select Continuous or Triggered. If you select Triggered, you can specify
the type of trigger as either Scheduled or Manual. For scheduled triggers, you must provide a Cron
expression that defines your schedule.
8. If you selected the Scheduled type, then in the Scale drop-down list, select Multi Instance or Single
Instance. The multi-instance option will scale your WebJob across all instances of the web app. The
single-instance option will result in a single WebJob.
9. To finish creation of the WebJob, click OK.
Viewing the WebJob history

The WebJob history provides information about when the WebJob was run and the result of the script
execution. To access the history, perform the following steps:
1. In the Azure portal, click the web app that runs the WebJob, and then click WebJobs.
2. Select the relevant WebJob, and then click Logs. This will open a web browser window displaying the
WebJob page. This page contains the name of the WebJob, the execution status, its duration, and
the last time the job was run.
3. To see further details, click the name of the WebJob, click the entry in the TIMING column, and then
click Toggle output. This displays individual events throughout the execution of the WebJob.
4. To download a text file containing the output, click the download link.
Demonstration: Configuring web app settings and autoscaling and

creating a WebJob
• Configure web app settings.
• Configure autoscaling.
• Create a WebJob.
Question: In what ways can you configure WebJobs to run?

Lesson 5
Monitoring web apps and WebJobs
Running web apps consume resources, incur costs, and can generate errors. For example, a web app
might display an error in response to users’ requests for webpages that do not exist. Azure provides
insight into your web app’s behavior by making available a range of diagnostic logs, troubleshooting
tools, and monitoring tools. In this lesson, you will see how to configure logging for your web app, and
how to use the most popular troubleshooting and monitoring tools.
Lesson Objectives
• Configure site diagnostics and application diagnostics to track a web app’s behavior.
• Identify the different ways to monitor web apps.
• Use the Kudu user interface to access further information about your web app.
Configuring application and site diagnostics

To troubleshoot a web app’s errors or identify
ways to improve its performance, you must gather
information about its behavior. One way to gain
better understanding of the way a web app
operates is to collect application diagnostics and
site diagnostics data.
Best Practice: Enable site diagnostics and

application diagnostics to record detailed
information only when you are investigating a
web app’s behavior. When you complete your
investigation and want to tune your web app for
optimal performance, minimize the amount of information the diagnostic tools log, because
logging has a small but measurable performance impact.
Application logging
Application logging makes it possible to capture individual events that occur as the web app code
executes. To record such an event, developers include references to the System.Diagnostics.Trace class
in the web app code. Developers frequently use this approach to generate trace messages, helpful in error
handling or verifying a successful operation.
Application logging is turned off by default, which means that trace messages are not recorded. If you
switch on application logging, you must configure the following settings by clicking the Diagnostics logs
link on the web app blade:
• Log storage location. Choose whether to store the application diagnostic log in the file system of
the web app instance or a blob container in an Azure Storage account. You can choose to enable
either one or both locations.
• Logging level. Choose whether to record informational, warning, error, or verbose messages in the
log. The verbose logging level records all messages that the application sends. You can configure a
different logging level for each log storage location.
• Retention period. When using an Azure Storage account, you can specify the number of days after
which logs should be automatically deleted. By default, the storage account retains them indefinitely.
Site diagnostics
You can use site diagnostics to record information about HTTP requests and responses, which represent
the communications between the web server hosting the web app and clients accessing the web app. The
following are the site diagnostic settings that you can enable or disable:
• Web server logging. This option controls the standard World Wide Web Consortium (W3C)
extended log for your web app’s server. This type of log shows all requests and responses, client IP
addresses, and timestamps for each event. You can use it to assess server load, identify malicious
attacks, and study client behavior.
• Detailed error messages. In HTTP, any response with a status code of 400 or greater indicates an
error. This log gathers detailed messages representing these errors, which should help you to
diagnose an underlying problem.
• Failed request tracing. This option enables you to log rich-tracing information when an error occurs.
Because the trace includes a list of all the IIS components that processed the request along with the
corresponding timestamps, you can use this trace to isolate problematic components.
Additional Reading: For more information on diagnostic logging, refer to: “Enable
diagnostics logging for web apps in Azure App Service” at: http://aka.ms/A42xut
Monitoring web apps

After you enable application and site-diagnostic
logs, you can download the logs to examine
their content. Additionally, you can use the
Monitoring tile in the Azure portal to profile a
web app’s performance.
Accessing diagnostic logs

When storing logs in the file system of a web
app’s instances, you can retrieve them by using
FTP. You can find the FTP link in the Essentials
section of each web app’s blade in the Azure
portal. You can use this link in your web browser
or in a dedicated FTP client, such as Core_FTP. To
access the logs, you must authenticate with deployment credentials that you configured for the FTP server
and Git.
The logs are in the following folders:
• Application logs: /LogFiles/Application
• Detailed error logs: /LogFiles/DetailedErrors
• Failed request traces: /LogFiles/W3SVC#########/
• Web Server logs: /LogFiles/http/RawLogs
• Deployment logs: /LogFiles/Git

To examine the failed request traces, ensure that you download both XML and XSL files to the same
location. You can then open the XML files in Microsoft Edge.
Instead of using FTP, you also can download the logs by using the Save-AzureWebsiteLog Windows
PowerShell cmdlet, as follows:
Save-AzureWebsiteLog -Name MyWebapp -Output .\LogFiles.zip
Alternatively, you can use the Azure CLI to download logs:
az webapp log download –name MyWebapp –log-file .\LogFiles.zip –resource-group

MyResourceGroup
For better filtering and search capabilities, you can view the application logs in Visual Studio, which
integrates with Application Insights. To take advantage of this functionality, install the Application Insight
SDK and add it to your project in Visual Studio. Then add Trace Listener to your project by selecting
Manage NuGet Packages and then Microsoft.ApplicationInsights.TraceListener. Finally, upload the
project to Azure, and then monitor the log data, together with requests, usage, and other statistical
information.
For useful, real-time logging information, developers can stream the logs into the development
environment. To do this, they can run the following Azure PowerShell cmdlet:
Get-AzureWebSiteLog -Name webappname -Tail
They can accomplish the same results by using the az webapp log tail Azure CLI command.
Monitoring web apps in the Azure portal

The Azure portal also includes a monitoring pane within the web app blade. The pane consists of
customizable graphs displaying performance counters of web app resources, such as CPU Time and
network traffic. Some of the most interesting counters include:
• CPU Time
• Data In
• Data Out
• HTTP Server Errors
• Requests
• Memory working set
Other metrics that you can add to the graph include:
• Average memory working set
• Average Response Time
• Various HTTP error types
• HTTP successful responses
By displaying these metrics in a graph format, you can quickly determine how demand and the web app
response have varied over an hour, 24 hours, or seven days.
You can also configure alerts that are raised when a counter reaches a custom threshold that you define.
You can configure an alert to trigger email notifications to owners, contributors, readers of the web app,
and email addresses that you provide. You also can specify a webhook, which represents an HTTP or
HTTPS endpoint where the alert should be routed. In addition, it is possible to remediate the issue that is
causing an alert. To accomplish this, as part of alert definition, specify a logic app that should run
automatically when an alert is raised and configure the logic app to perform the remediating action.
To add an alert, perform the following steps:
1. In the Azure portal, click the web app that you want to monitor.
2. In the monitoring pane, click any of its graphs.
3. On the Metrics blade, click Add metric alert.
4. On the Add rule blade, in the Name text box, type a unique name.
5. In the Description text box, type a description of the alert.
6. Ensure that Metrics appears in the Alert on drop-down list. Note that you can also generate alerts
based on events.
7. Leave the default entries in the Subscription, Resource group, and Resource drop-down lists.
8. In the Metric drop-down list, select the metric to which you would like to add an alert.
9. In the Condition drop-down list, select a condition, such as Greater than.
10. In the Threshold text box, type the value that should trigger the alert.
11. In the Period drop-down list, select the period during which the value should exceed the threshold.
12. Select Email owners, contributors, and readers.

13. Optionally, specify the email addresses of additional notification recipients.
14. Optionally, in the Webhook text box, type the HTTP/HTTPS endpoint to which you want to route the
alert.
15. If you intend to trigger execution of a logic app in response to the alert, click Run a logic app from
this alert. On the Select a logic app, blade click Enabled, in the Logic app drop-down list, select the
logic app you want to run, and then click OK.
16. Click OK to finish the creation of the alert.
Using Kudu
Project Kudu is an open-source component of
Web Apps that provides several functional
enhancements, such as support for continuous
deployment from Git and Mercurial source-code
control systems. It also includes the code that
implements WebJobs. Kudu offers a user interface
that facilitates access to diagnostics and
troubleshooting tools.
Accessing the Kudu user interface

Every web app includes a hidden Kudu site. To
access this, add the scm subdomain to the
azurewebsites.net FQDN for your web app. For
example, if your web app is accessible via http://mywebapp.azurewebsites.net, you can access the
corresponding Kudu user interface at: https://mywebapp.scm.azurewebsites.net.
To access the Kudu interface, you must connect via HTTPS and authenticate with an account that has
administrative privileges to the web app. The default page displays information about the IIS environment
that is hosting the web app. You also can run commands, either from a Windows command prompt or a
Windows PowerShell console, by using the links on the Debug console menu. Both options include a
browser view of the file system folders available to the web app.
The Process explorer tab shows a list of all the processes within the web app and includes information
such as their memory usage and uptime. For each process, you can find out what dynamic link library files
(.dll files) it has loaded, the threads it runs, and the environment variables that are in place.
Other Kudu interface elements provide access to diagnostics dumps, log stream WebJobs dashboard,
webhoooks, and deployment scripts. There is also the option of adding NuGet extensions to the web app.
Demonstration: Using Kudu to monitor a WebJob

In this demonstration, you will see how to use Kudu to monitor the status of a WebJob.
Question: How can you access the Kudu interface for a web app that you created in Azure?
Lesson 6
Implementing mobile apps
Mobile Apps provide features that deliver backend services for mobile apps that run on client devices,
such as phones or tablets. The Mobile Apps service also considerably simplifies development of mobile
apps. In this lesson, you will learn how to create and administer a mobile app backend in Azure and use it
to facilitate mobile app development.
Lesson Objectives
• Explain how to create and configure a new mobile app by using the Azure portal.
• Explain how to configure external authentication providers in a mobile app.
• Describe how to deploy a mobile app by using a publish profile and by using continuous deployment.
• Describe how to implement a mobile app by using the Azure portal.
Creating and configuring mobile apps

The Mobile Apps feature provides a complete
platform for developing mobile apps. You can
develop mobile apps with commonly used tools
and SDKs, and then deploy them by using the
same deployment methods that you use for web
apps. The following are the most important
features of Mobile Apps:
• Single sign-on. You can implement

authentication of mobile apps that relies on
popular cloud identity providers, including
Azure AD, Facebook, Google, Twitter, and
Microsoft account service.
• Offline synchronization. You can build apps that can work offline and then synchronize the data when
a connection to the online service becomes available.
• Push notifications. You can benefit from the push notification engine that delivers notifications to
devices in response to custom events.
• Autoscaling. When using the Standard or Premium pricing tier service plans, you can configure
autoscaling of a mobile app’s instances based on the changing demand for its services.
• WebJobs. You can implement WebJobs to process background tasks.
• Connect to a SaaS API. You can integrate your mobile app with cloud applications, such as Office 365,
Salesforce, and Dropbox.
• Virtual network and hybrid integration. You can connect mobile apps to services running on Azure
VMs or on-premises servers.
• Staging environment. You can create multiple staging environments to test mobile apps before you
move them to the production environment.
To create a new mobile app, perform the following steps:
2. On the toolbar to the left, click New, select the Web + Mobile link, and then click Mobile App.
3. On the Mobile App blade, in the App name text box, type a unique valid name for the mobile app.
The mobile app must be unique within the azurewebsites.net domain.
4. In the Resource Group section, select an existing resource group or specify the name of a new
resource group that you want to create.
5. In the App Service plan/location drop-down list, select an existing plan or create a new App Service
plan.
6. Specify whether to enable Application Insights.
7. Click Create to finish the creation of the mobile app.
8. After creation of the backend for the mobile app is complete, on its blade, click Quickstart.
9. On the Quickstart blade, select the language for the mobile app code. Work with your development
team to determine which language to choose. This example uses the Windows (C#) option.
10. After selecting Windows (C#), click Connect a database.
11. On the Data connections blade, click Add.
12. On the Add data connection blade, select SQL Database, and then click the SQL Database link.
13. On the SQL Database blade, type a unique database name, select Pricing tier, and then click Target
server to configure the required settings for the server.
14. On the New Server blade, in the Server name text box, type the unique name for the server. The
server name must be unique in the database.windows.net DNS namespace.
15. In the Server admin login text box, type the administrator account, and then in the Password and
Confirm Password text boxes, type the administrator password.
16. Note that Allow azure services to access server is selected by default, and then click Select to
confirm the creation of the server.
17. On the SQL database blade, click Select.
18. On the Add data connection blade, click MS_TableConnectionString.
19. On the Connection string blade, click OK.
20. On the Add data connection blade, click OK.
21. On the Windows (C#), blade under the Create a table API section, select the backend language as
C# or Node.js.
22. Click the Download link, and save the compressed files on your computer. These files contain the
startup project, which you can open in Visual Studio, customize, and then publish into the Azure
mobile app that you provisioned.
You can develop a mobile app for iOS, Windows, or Android by using the same development
environment that you use for web apps. Microsoft provides SDKs for these platforms that you can
integrate with Visual Studio.
Best Practice: You can download sample code for developing your mobile apps for the
platform you choose. The sample code is preconfigured to work with the mobile app that you
provisioned in Azure.
Configuring authentication
Due to the popularity of Azure and social-
networking sites, you can assume that most of
your app’s prospective users already have Azure
AD, Microsoft, Facebook, Twitter, or Google user
accounts. You can integrate your mobile apps
with each of these cloud identity providers,
allowing these users to authenticate with their
existing credentials.
To configure your mobile app to use Azure AD as

an identity provider, perform the following steps:
1. In the Azure portal, click the mobile app that

you want to configure.
2. On the mobile app blade, click the Authentication/Authorization link.
3. To configure authentication and authorization for your mobile app, on the

Authentication/Authorization blade, under the App Service Authentication section, click On.
4. In the Authentication Provider section, click Azure Active Directory.
5. On the Azure Active Directory Settings blade, under the Management mode section, click
Express. This will create a new registration for the mobile app. You also can use existing Active
Directory app registration.
6. Click OK to confirm Azure AD registration.
7. On the Authentication/Authorization blade, click Save to register the authentication provider.
Note: You can also provide configuration settings manually by creating a registration in
Azure AD, and then referencing that information in App Service. This corresponds to the
Advanced option on the Azure Active Directory Settings blade.
For mobile apps that require an increased level of security, you can prevent users from invoking APIs
anonymously. Based on the platform that you choose to develop your mobile app, you can configure this
in one of two ways:
• Node.js. Add the following line to the Node.js server script:
table.access =”authenticated”
• .NET (C#). Add the Authorize attribute to the controller class.
The next step is to configure the mobile app to authenticate users before providing access to its resources.
You can do that by referencing the authentication provider in the mobile app code. For example, to add
an authentication provider such as Facebook, use the following section in the code in your MainPage.cs
project file:
user = await App.MobileService

.LoginAsync(MobileServiceAuthenticationProvider.Facebook);
You also can configure caching of the authentication token on a mobile device. This can improve the
performance of a mobile app, because the authentication token can be retrieved from the local cache
instead of from the authentication provider.
Deploying a mobile app

Deploying Azure mobile apps is no different from
deploying Azure web apps. You can copy the
mobile app files by using FTP or you can
synchronize the files and folders from a cloud
storage service, such as OneDrive or Dropbox.
App Service also supports deployment from Web
Deploy (included in Visual Studio), WebMatrix,
and Visual Studio Team Services.
As explained in the first topic of this lesson,

developers can download a starter project for
your mobile app from the Azure portal. Next, they
can import this project into Visual Studio and
customize it. When development is complete, you can provide them with a publish profile that will allow
them to deploy the mobile app code into Azure.
To use Visual Studio to deploy your project to an Azure mobile app, perform the following steps:
1. In Visual Studio, open your project containing the mobile app that you plan to deploy in Azure.
2. In Visual Studio, in Solution Explorer, right-click your project, and then select Publish.
3. Ensure that the Microsoft Azure App Service icon and the Select Existing option are selected, and
then click Publish.
4. In the Publish Web dialog box, follow the Publish Web Wizard.
5. On the Profile tab, in the Select a publish target section, select Microsoft Azure App Service.
6. In the App Service dialog box, sign in to your Azure subscription, select your subscription, the
resource group containing the Azure mobile app, and the mobile app, and then click OK.
7. Verify that the publish profile contains correct settings, including Configuration set to Release. To
alter the default values, click Settings. This will display the Publish window.
8. On the Connection tab, ensure that the publishing method is set to Web Deploy, and then verify the
server, site name, user name, and destination URL. You can click Validate Connection to verify
connectivity to App Service. Click Next to proceed.
9. On the Settings tab, verify that Release appears in the Configuration drop-down menu, and then
click Save.
10. Click Preview to identify the list of files that the deployment will contain.
11. Click Publish to begin the process of copying files to the Azure mobile app.
You can use many other methods to deploy mobile app code to Azure. One popular approach involves
setting up a local Git repository. This procedure is the same as what you would use for Git-based
deployment of Azure web apps. It involves the following steps:
1. On the development computer, install Git and create a local repository.
2. Configure the Local Git Depository deployment option of the Azure mobile app. This includes
setting up deployment credentials.
3. On the development computer, add the remote Git URL and push mobile app files to the Azure App
Service mobile app.
Additional Reading: For details regarding Git-based deployment, refer to: “Local Git
Deployment to Azure App Service” at: https://aka.ms/k8zqbh
Demonstration: Implementing a mobile app

In this demonstration, you will see how to create a new mobile app.
Question: Your company is developing a mobile app. You have been asked to host data and
notification hubs in Azure. What are the advantages of using a mobile app in Azure instead
of creating separate SQL databases and notification hubs?
Lesson 7
Implementing Traffic Manager
If you provide web services with clients spread across multiple locations, you must be able to run your
apps in a load-balanced manner across many datacenters. This enables you to handle requests from users
by using the closest web app instance to their physical location. Geographically distributed load balancing
also increases the availability of a web app by facilitating failover between its instances. You can
implement this load balancing by using Azure Traffic Manager. In this lesson, you will learn how to
configure and use Traffic Manager to improve responsiveness and availability of Azure App Service apps.
Lesson Objectives
• Describe how Traffic Manager distributes requests to multiple App Service apps.
• Explain how to configure Traffic Manager endpoints.

• Describe the best practices for a Traffic Manager configuration.
• Configure Traffic Manager.
Overview of Traffic Manager

When you create an app, you must choose an
Azure region where the app will be hosted. If you
choose a Basic, Standard, or Premium tier service
plan, you can create multiple instances of your
app to increase capacity and resilience to failure.
These instances will be in the same Azure region.
The Azure load balancer will automatically
distribute the requests.
However, you might want to distribute the load

across web apps that are in different Azure
regions. You can implement this functionality by
using Traffic Manager. Traffic Manager provides
load balancing by relying exclusively on DNS name resolution. Traffic Manager supports any endpoints
with DNS names resolvable to public IP addresses, regardless of their location. Traffic Manager
periodically checks all endpoints. If an endpoint fails the checks, Traffic Manager removes it from the
distribution until checks are successful again.
How Traffic Manager works

Through Traffic Manager, a client resolves an FQDN to an IP address in the following way:
1. The user attempts to connect to a specific service by using its FQDN, by typing it into a browser
address bar or by clicking a link, for example. In this example, the user attempts a connection to
www.adatum.com. From the DNS standpoint, this name takes the form of a CNAME record, which
resolves to an A record in the Traffic Manager DNS namespace trafficmanager.net.
2. The DNS server handling the name resolution for the DNS resolver of the user’s computer submits a
query to the Traffic Manager DNS servers.
3. Traffic Manager accepts the query and attempts to find the optimal endpoint, based on its
configuration. It returns the DNS name of one endpoint to the DNS server, which, in turn, forwards it
to the DNS resolver on the user’s computer.
4. The DNS resolver on the user’s computer submits a request for resolving the endpoint’s DNS name to
its IP address.
5. Following successful DNS name resolution, the user connects to the endpoint via its IP address.
Note: You can use Traffic Manager to distribute loads across mobile apps, Azure Cloud
Services, Azure VMs with public IP addresses, and external endpoints, in addition to web apps.
You can use it to increase responsiveness and availability for many endpoints within and outside
of Azure.
How to implement Traffic Manager

Follow these steps to implement Traffic Manager:
1. Deploy endpoints that represent the same content and apps across different Azure regions and,
optionally, to locations outside of Azure.
2. Choose a unique domain prefix for your Traffic Manager profile.
3. Create a Traffic Manager profile with an appropriate routing method.
4. Add endpoints to your Traffic Manager profile to load-balance the client requests.
5. Configure monitoring for your endpoints to verify whether they are online and can serve client
requests.
6. Configure your company DNS domain records to point to your Traffic Manager profile.
Traffic Manager supports the following routing methods:
• Performance. Traffic Manager evaluates which application instance is closest to the end user (in terms
of network latency) and provides the corresponding DNS name.
• Failover. Traffic Manager provides the DNS name corresponding to the application instance
designated as the primary, unless that instance does not pass Traffic Manager health checks. In that
case, Traffic Manager returns the DNS name of the next application instance (in the prioritized list of
instances that you define) to end users.
• Weighted. Traffic Manager provides the DNS names of every application instance (alternating among
them). The distribution pattern depends on the value of the weight parameter that you define. The
volume of traffic requests that Traffic Manager directs to a particular instance is directly proportional
to its weight. You can specify weights between 1 and 1,000. All endpoints have a default weight of 1.
• Geographic. Traffic Manager directs traffic to a specific location based on the geographical area from
which an access request originates. This enables you to provide localized user experience or to restrict
access to comply with data sovereignty rules.
You can configure three types of Traffic Manager endpoints:

• Azure endpoints that represent services hosted in Azure, such as App Service apps, cloud services, or
public IP addresses. Traffic Manager also supports routing to nonproduction slots of App Service
apps.
• External endpoints that identify the services hosted outside of Azure, such as your web app running at
an ISP. This provides a convenient way to maintain continuity of your services in migration scenarios.
• Nested profiles that you use to implement nested hierarchies of Traffic Manager profiles. You can use
this technique to increase the flexibility of load balancing. For example, you could set up a parent
profile that uses performance load balancing to distribute the load over several endpoints around the
world. Traffic Manager sends client requests to the endpoint that is closest to the user. Within one of
those endpoints, you could use round-robin load balancing in a child profile to distribute the load
equally between two web apps.
Configuring Traffic Manager

Before you can use Traffic Manager to load-
balance traffic to two or more app services apps,
you must create those apps in different Azure
regions and deploy matching content to each. In
most cases, content and configuration should be
identical on every app you use in a Traffic
Manager profile. After you complete the
deployment, perform the following tasks to
configure Traffic Manager:
2. On the hub menu to the left, click New, click

Networking, click See all, click Traffic
Manager profile, and then click Create.
3. On the Create Traffic Manager profile blade, in the Name text box, type the unique name in the
trafficmanager.net DNS namespace that will identify the profile.
4. In the Routing method drop-down list, select one of the following entries:
o Performance
o Weighted
o Priority
o Geographic
5. Create a new resource group or use an existing resource group for the Traffic Manager profile.
6. Specify the Azure region where the Traffic Manager profile will be hosted.
7. Click Create.
8. After you have created the Traffic Manager profile, navigate to it in the Azure portal.
9. On the Traffic Manager profile blade, click Endpoints.
10. On the endpoints blade, click Add to add an endpoint to the Traffic Manager profile. Each endpoint
can reside in a different location.
11. On the Traffic Manager profile blade, click Configuration.
12. On the Configuration blade, you can change the routing method, define the Time to Live (TTL)
parameter for the Traffic Manager DNS records, and configure endpoint monitoring. Traffic Manager
polls each endpoint in the profile to confirm that it is online. You can use HTTP or HTTPS for this
monitoring. You can designate a specific page on the endpoints that Traffic Manager will use to
evaluate the health status. You must ensure that this page exists for each endpoint in the Traffic
Manager profile.
You can also use Azure PowerShell to configure Traffic Manager by performing the following steps:
1. Start Azure PowerShell, and then sign in to your subscription:
2. If you have multiple subscriptions, select the one in which you are going to create the Traffic
Manager profile:
Set-AzureRmContext SubscriptionName “Name of your subscription”
4. Create the Traffic Manager profile with the name Myprofile. Use the Performance routing method
with the DNS name adatum. Provide a TTL value of 30 seconds and HTTP as the monitoring protocol:
$profile = New-AzureRmTrafficManagerProfile –Name MyProfile -ResourceGroupName

AdatumRG -TrafficRoutingMethod Performance -RelativeDnsName adatum -Ttl 30 -
MonitorProtocol HTTP -MonitorPort 80 -MonitorPath "/"
5. Add the first endpoint to the Traffic Manager profile:
$webapp1 = Get-AzureRmWebApp -Name webapp1

Add-AzureRmTrafficManagerEndpointConfig –EndpointName webapp1ep –
TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp1.Id –
EndpointStatus Enabled
6. Add the second endpoint to the Traffic Manager profile:
$webapp2 = Get-AzureRmWebApp -Name webapp1

Add-AzureRmTrafficManagerEndpointConfig –EndpointName webapp2ep –
TrafficManagerProfile $profile –Type AzureEndpoints -TargetResourceId $webapp2.Id –
EndpointStatus Enabled
7. Update the Traffic Manager profile so that the changes take effect:
Set-AzureRmTrafficManagerProfile –TrafficManagerProfile $profile
Enabling and disabling endpoints and profiles

In some scenarios, you might need to temporarily disable individual endpoints or even the entire
Traffic Manager profile. You can use the Enable-AzureRMTrafficManagerProfile or Disable-
AzureRMTrafficManagerProfile command to enable or disable a Traffic Manager profile. For example:
Enable-AzureRmTrafficManagerProfile -Name MyProfile -ResourceGroupName AdarumRG

Disable-AzureRmTrafficManagerProfile -Name MyProfile -ResourceGroupName AdarumRG
To enable or disable a Traffic Manager endpoint, use the Enable-AzureRMTrafficManagerEndpoint and

Disable-AzureRMTrafficManagerEndpoint commands.
Traffic Manager best practices

Follow these rules and best practices to ensure the
best resilience from Traffic Manager:
Best Practices:
• Consider the implications of changing the

DNS TTL value. This value determines how
often DNS servers and DNS clients keep
entries representing resolved DNS queries in
their local cache. This affects the time it takes
for changes to endpoints in a Traffic Manager
profile to propagate to all DNS servers and
DNS clients.
• Remember that you can add staging slots to a Traffic Manager profile. This allows you to implement
testing in production.
• Make content of endpoints consistent. If the content and configuration of all endpoints in the Traffic
Manager profile are not identical, the response sent to users might be unpredictable. This might not
apply when implementing the Geographic routing method.
• Take advantage of the ability to disable endpoints during web app maintenance. You can perform
maintenance operations on an endpoint, such as updating a deployment, without causing any service
interruptions by redirecting the traffic to other endpoints. To do this, disable the endpoint you want
to maintain before you begin your administrative actions. Traffic Manager will forward all traffic to
other endpoints until you finish and re-enable this endpoint.
Demonstration: Configuring Traffic Manager

• Create a new Traffic Manager profile.
• Add an endpoint to a Traffic Manager profile by using the Azure portal.
• Test Traffic Manager.
Question: How does the load-balancer solution of Traffic Manager differ from similar
solutions that you can implement in Azure?
Lab: Implementing web apps

Scenario
A. Datum Corporation’s public-facing web app currently runs on an IIS web server at the company’s
chosen ISP. A. Datum wants to migrate this web app into Azure. You must test the Web Apps functionality
by setting up a test A. Datum web app. The A. Datum development team has provided you with web app
content to deploy. You must ensure that the team will be able to stage changes to the test web app
before you deploy these changes to the public-facing web app. A. Datum is a global company, so you also
want to test Azure Traffic Manager, and demonstrate how it distributes traffic across multiple instances of
the web app.
Objectives
• Create a new web app.
• Deploy a web app.

• Manage web apps.
• Implement Traffic Manager to load-balance web apps.
Lab Setup
User name: Student
Password: Pa55w.rd
Before you begin this lab, ensure that you have performed the “Preparing the lab environment for this
module” demonstration tasks at the beginning of this module’s first lesson, and that the setup script is
complete.
Question: In Exercise 2, you deployed the A. Datum production web app to Azure. In
Exercise 3, you deployed a new version of the site to a staging slot. Within Microsoft Edge,
how can you tell which is the production site and which is the staging site?
Question: At the end of Exercise 4, you used an FQDN within the trafficmanager.net
domain to access your web app. How can you use your own registered domain name to
access this web app?

Review Question
Question: What are the advantages of deploying a web app to Web Apps versus deploying
a web app to an Azure VM?
6-1
Module 6
Planning and implementing storage, backup, and recovery
services
Contents:
Module Overview 6-1
Lesson 1: Planning storage 6-2
Lesson 2: Implementing and managing Azure Storage 6-12
Lesson 3: Implementing Azure CDNs 6-25

Lesson 4: Implementing Azure Backup 6-31
Lesson 5: Planning and implementing Azure Site Recovery 6-38
Lab: Planning and implementing Azure Storage 6-46
Module Overview
Microsoft Azure Storage services provide a range of options for storing and accessing data. The core
services consist of four storage types: blobs, tables, queues, and files. Additionally, Microsoft Azure offers
storage capabilities to facilitate recovery and to assist customers with implementing their business
continuity and disaster recovery objectives. These services include Azure Backup and Azure Site Recovery.
Azure Content Delivery Network (CDN) is another storage-related service whose primary goal is to
improve the performance of web applications and services by hosting data in locations that are close to
consumers.
IT professionals can provision and manage Azure Storage services by using several tools and interfaces,
including the Azure portal, Azure PowerShell, Azure Command-Line Interface (Azure CLI), and open
source and third-party command-line and graphical utilities. In this module, you will learn about the
available data storage options and their management.
Objectives
• Choose appropriate Azure Storage options to address business needs.
• Implement and manage Azure Storage.
• Improve web application performance by implementing Azure CDNs.
• Protect on-premises systems and Azure virtual machines (VMs) by using Azure Backup.
• Describe Azure Site Recovery capabilities.
6-2 Planning and implementing storage, backup, and recovery services
Lesson 1
Planning storage
Azure Storage Azure Backup, and Azure Site Recovery enable you to store and protect business data in
the cloud. With several different available storage options, it is important to understand not only how to
implement them, but also how to identify the one that is most appropriate for your storage needs.
Because storage is a billable service, you also need to be aware of its cost implications to deploy the most
cost-efficient solutions. This lesson discusses the various data services that are available in Azure, and it
outlines factors to consider when choosing between them.
Lesson Objectives
• Explain how to plan storage.
• Explain how to implement and manage Azure Storage.

• Explain how to implement Azure CDNs.
• Explain how to implement Azure Backup.
• Describe how to plan and implement Azure Site Recovery.

module
Perform the tasks in this demonstration to prepare the lab environment. The Azure services you will use in
the lab will be described in this module while the environment is being configured.
Storage as an Azure component

Azure Storage is part of Azure data management
services. Several Azure services use Azure Storage,
including Azure Virtual Machines and Azure Cloud
Services. Other modules of this course cover these
Azure services in detail.
Azure Storage is available in both the classic and
Azure Resource Manager deployment models.
This means that you can create two types of
storage accounts, depending on the deployment
model that you choose. To some extent, the
deployment model that you choose affects the
functionality that storage provides. For example,
classic storage accounts do not support some of more recently introduced features, such as Azure Storage
Service Encryption for data at rest or Hot and Cool access tiers.
App Service, Cloud Services, and web applications running on Azure virtual machines can benefit from
CDN, which provides globally distributed storage for their static content. This improves the customer
experience when accessing these services from remote locations by minimizing the time it takes to
download that static content.
The content can include text files, script libraries, downloadable software, and media such as video and
audio files. CDN replicates and caches this content to a large number of servers, which reside in a number
of locations around the world. When a user submits a request that references this content, CDN forwards
the request to a CDN server that is closest to the user’s location.
You configure CDN by using the Azure Content Delivery Network service. This service can cache content
from Azure blob storage, Virtual Machines, Cloud Services, Azure App Service, Azure Media Services, or a
custom origin with any web address that is accessible from the internet.
Overview of Azure Storage

Azure Storage is a service that you can use to
store unstructured and partially structured data.
Developers and cloud architects commonly
choose it to host data that App Service or Cloud
Services use. IT professionals who deploy Azure
virtual machines rely on Azure Storage for storing
virtual machine operating system and data disks,
and for hosting network file share contents.
In general, Azure Storage offers four types of

storage services, depending on the type of data
that they are designed to store:
• Blobs. These typically represent unstructured
files such as media content, virtual machine disks, backups, or logs. Blobs facilitate locking
mechanism, ensuring exclusive file access that IaaS virtual machines require. There are three types of
blobs. The first one, known as a block blob, is optimized for sequential access, which is ideal for media
content. The second one, referred to as a page blob, offers superior random access capabilities, which
is best suited for virtual machine disks. The third one, referred to as an append blob, applies to data
append operations, without the need to modify existing content. This works best with logging and
auditing activities.
• Tables. These host nonrelational and partially structured content, which consists of multiple rows of
data with different sets of properties. In the context of Azure Table storage, these rows are referred to
as entities. Developers frequently implement table storage as the backend data store for App Service
or PaaS cloud services.
• Queues. These are temporary storage for messages that Azure services commonly use to
asynchronously communicate with each other. In particular, in distributed applications, a source
component sends a message by placing it in a queue. The destination component works though the
messages in the queue one at a time.
• Files. Similar to blobs, these provide storage for unstructured files, but they offer support for file
sharing in the same manner as traditional on-premises Windows file shares.
There are two tiers of page blob storage: Standard and Premium. Premium Storage offers superior
performance, equivalent to what the solid-state drive (SSD) technology provides. A standard storage
account provides performance similar to commodity magnetic disks.
Storage accounts
To use Azure Storage, you first need to create a storage account. Premium storage accounts are strictly for
page blob storage.
By default, you can create up to 200 storage accounts in a single Azure subscription; however, you can
increase this soft limit by opening a service ticket with Azure support. Each standard storage account is
capable of hosting up to 500 terabytes (TB) of data, while the maximum size of a premium storage
account is 35 TB. For each storage account, you must specify:
• Name. This defines the unique URL that other services and applications use to access a storage
account’s content. All such URLs include the “core.windows.net” domain suffix. The fully qualified
domain name (FQDN) depends on the type of storage that you want to use. For example, if you
designate the “mystorageaccount” storage account name, you can access its blob service via
http://mystorageaccount.blob.core.windows.net.
• Deployment model. You have the choice between Azure Resource Manager and classic. As mentioned
earlier, this affects the functionality that the storage account will support.
• Performance. This determines performance characteristics of the provisioned storage and directly
impacts the storage service that the account supports. You can choose between Standard and
Premium performance. A Premium performance storage account provides I/O throughput and
latency characteristics equivalent to those delivered by SSDs, but its usage is limited to page blobs.
Effectively, its main purpose is to host virtual disk files of Azure VMs that require superior I/O
performance, typical for enterprise-level workloads. A Standard performance storage account can
host any type of content (blobs, tables, queues, and files), including virtual disk files of Azure VMs. In
this case, though, the resulting virtual disk throughput and latency characteristics are equivalent to
those delivered by commodity hard disk drives (HDDs).
• Kind. This determines the type of content that you will be able to store in the storage account, in
addition to support for access tiers. More specifically, Azure Storage supports two kinds of accounts:
o General purpose. Provides the ability to host blobs, tables, queues, and files.
o Blob. Offers optimized support for block and append blobs. This optimization relies on the ability
to set the access tier of the storage account. The choice of access tier, which can be either Cool or
Hot, affects the way the storage-related charges are calculated. By choosing a specific access tier,
you can minimize the corresponding cost of storage based on its usage patterns. More
specifically, for the Hot access tier, the price per gigabyte (GB) is higher but charges associated
with the number of storage transactions are lower. In addition, you do not pay for the amount of
data that you write to or read from the storage account. For the Cool access tier, the price per GB
is more than 50 percent lower, but transactional charges are higher and you do pay for the data
that you write to or read from a storage account.
Although it is possible to switch between the two access tiers, you should consider the potential cost
implications. Changing the Hot access tier to Cool does not introduce any extra cost. However, the
opposite could potentially result in a significant one-time charge. This is because such an operation
requires reading the entire content of the storage account, which is priced separately with the Cool
access tier.
• The replication settings. To ensure resiliency and availability, Azure automatically replicates your data
across multiple physical servers functioning as storage nodes. The number of replicas and the scope
of replication depend on your choice of replication scheme. You can choose from four replication
schemes:
o Locally redundant. Your data replicates synchronously across three copies within a cluster of
storage nodes referred to a storage scale unit. A single storage scale unit contains multiple
physical racks of storage nodes. Each copy of a single storage account resides in a different
physical rack within a separate fault domain and upgrade domain. This provides resiliency and
availability equivalent to that of compute nodes.
Note: For more information regarding fault and upgrade domains, refer to Module 3 of this
course, “Implementing virtual machines.”
Locally redundant storage (LRS) protects your data against server hardware failures but not
against a failure that affects the entire Azure region. This is the only option available for Premium
Storage accounts.
o Zone-redundant. Your data replicates synchronously across three copies that reside in the same
storage scale unit. In addition, your data replicates asynchronously across datacenters within the
same Azure region or across two Azure regions. Zone-redundant storage (ZRS) offers more
durability than LRS. However, ZRS can contain only block blobs, which makes it unsuitable for
hosting IaaS virtual machine disk files, tables, queues, or file shares.
o Geo-redundant. Your data replicates asynchronously from the primary region to a secondary
region. Predefined pairing between the two regions ensures that data stays within the same
geographical area. Data also replicates synchronously across three replicas in each of the regions,
resulting in six copies of storage account content. If failure occurs in the primary region and
Microsoft initiates a failover to the secondary region, the content of the Azure Storage account
becomes available in the secondary location. Effectively, geo-redundant storage (GRS) offers
improved durability over LRS and ZRS.
o Read-access geo-redundant. As with GRS, your data replicates asynchronously across two regions
and synchronously within each region, yielding six copies of a storage account. However, with
read-access geographically redundant storage (RA-GRS), the storage account in the secondary
region is available for read-only access regardless of the primary’s status. This allows you to
perform near real-time data analysis and reporting tasks without affecting your production
workload performance.
Additional Reading: The Azure platform determines the location of the secondary region
automatically, based on the concept of Azure region pairing. For a list of secondary regions for
each of the Azure regions, refer to: “Azure Storage replication” at: https://aka.ms/r3h0wc
• Storage service encryption. For accounts deployed by using the Azure Resource Manager deployment
model, you can enable this setting to ensure that the content of the storage account is encrypted at
rest. Once you enable it, Azure Storage services automatically encrypt any data during storage
account write operations and decrypt it during read operations. Microsoft manages the encryption
keys.
• Secure transfer required. Azure Storage supports both secure and nonsecure connections. You can
enforce secure connections by enabling this setting. This will result in rejection of any access requests
that do not apply encryption at the protocol level, such as HTTP or Server Message Block (SMB) 2.1.
• Location. This designates the Azure region where the primary instance of your storage account
resides. In general, you should choose a region that is close to users, applications, or services that are
consuming the storage account’s content.
Note: The general purpose standard storage accounts are capable of hosting any storage
service type, including three types of blobs, in addition to tables, queues, and files, unless you
designate them as ZRS. If you designate a storage account as ZRS, it supports only block blobs.
Premium Storage accounts support only the LRS scheme and are limited to storing page blobs
only.
Planning for standard Azure Storage

If you use Azure Storage to host information for a
custom solution, such as a mobile app or a web
app, cloud architects or developers must select
the appropriate storage type for each functional
requirement. To assist with this process, you
should understand the characteristics of each
storage type.
Blob storage
The Azure blob storage service stores large
amounts of unstructured data in the form of files,
which typically reside in containers. Containers are
similar to file folders, helping you to organize
blobs logically in a storage account and providing extra security, although, they support single-level
hierarchy only. Each blob can be hundreds of gigabytes in size, and users can access them through a
unique URL. For example, subject to access control restrictions, users can access a blob named
“myblob.jpg” in a container named “mycontainer” in a storage account named “myaccount” by using the
http://myaccount.blob.core.windows.net/mycontainer/myblob.jpg URL.
Each blob has a specific type. It is not possible to change an existing blob’s type. The three types of blobs
are:
• Block blobs. Block blobs are optimized for uploads and downloads. To accomplish this optimization,
Azure divides data into smaller blocks of up to 100 megabytes (MB) in size, which subsequently
upload or download in parallel. Individual block blobs can be up to 4.75 terabytes (TB) in size.
• Page blobs. Page blobs are optimized for random read and write operations. Blobs are accessed as
pages, each of which is up to 512 bytes in size. When you create a page blob, you specify the
maximum size to which it might grow, up to the limit of 8 TB. Each standard storage account page
blob offers throughput of up to 60 MB per second or 500 (8 KB in size) I/O operations per second
(IOPS).
Note: At the time of authoring this course, the maximum size of a virtual disk file is 4 TB.
• Append blobs. Append blobs are strictly for append operations because they do not support
modifications to their existing content. Appending takes place in up to 4 MB blocks—the same size as
the individual blocks of block blobs—with up to 50,000 blocks per append blob, which translates
roughly into 195 GB.
Note: Generally, the Azure platform assigns the appropriate blob type automatically, based
on the intended purpose. For example, when you create an Azure virtual machine from the Azure
portal, the platform will automatically create a container in the target storage account and a
page blob containing the virtual machine disk files.
Table storage
You can use the Azure Table storage service to store partially structured data in tables without the
constraints of traditional relational databases. Within each storage account, you can create multiple tables,
and each table can contain multiple entities. Because table storage does not mandate a schema, the
entities in a single table do not need to have the same set of properties. For example, one Product entity
might have a Size property, while another Product entity in the same table might have no Size property at
all. Each property consists of a name and a value. For example, the Size property might have the value 50
for a particular product.
Similar to blobs, applications can access each table through a URL. For example, to access a table named
“mytable” in a storage account named “myaccount”, applications would use the following URL:
http://myaccount.table.core.windows.net/mytable URL.
The number of tables in a storage account is limited only by the maximum storage account size. Similarly,
besides the limit on the size of the storage account, there are no restrictions on the maximum number of
entities in a table. Each entity can be up to 1 MB in size and possess up to 252 custom properties. Every
entity also has three designated properties: a partition key, a row key, and a timestamp. The platform
generates the timestamp value automatically, but the table designer chooses the partition key and row
key.
It is important to choose these two properties carefully because Azure uses their combination to create a
clustered index for the table. The clustered index can considerably improve the speed of table searches,
which otherwise would result in a full table scan. You can use the partition key to group similar entities
based on their common characteristic, but with unique row key values. Proper selection of the partition
key can also improve performance when adding entities to a table, by making it possible to insert them in
batches.
Queue storage
The Azure Queue storage service provides temporary messaging store. Developers frequently use queues
to facilitate reliable exchange of messages between individual components of multitier or distributed
systems. These components add and remove messages from a queue by issuing commands over the HTTP
or HTTPS protocols.
Similar to other Azure storage service types, each queue is accessible from a URL. For example, to access a
queue named “myqueue” in a storage account named “myaccount”, applications would use the following
URL: http://myaccount.queue.core.windows.net/myqueue.
You can create any number of queues in a storage account and any number of messages in each queue
up to the 500 TB limit for all the data in the storage account. Each message can be up to 64 kilobytes (KB)
in size.
Another frequently used Azure service that offers message storage functionality is Service Bus. However,
Service Bus queues differ from Azure Storage queues in many aspects.
Additional Reading: For more information, refer to: “Azure Queues and Service Bus queues
- compared and contrasted” at: http://aka.ms/Ve4qo0
File storage
The Azure File storage service allows you to create SMB file shares in Azure just as you would with an on-
premises file server. Within each file share, you can create multiple levels of folders to categorize content.
Each directory can contain multiple files and folders. Files can be up to 1 TB in size. The maximum size of
a file share is 5 TB.
The Azure File storage service is available via both SMB 2.1 and SMB 3.x protocols. Starting with
Windows 8 and Windows Server 2012, the operating system includes SMB 3.x. Linux distributions also
provide support for SMB 3.x by using the cifs-utils package from the Samba project.
The Windows server and client-based version of SMB 3.X offers several advantages over SMB 2.1,
including built-in encryption. As the result, you can establish mapping to Azure File storage shares from
locations outside the Azure region where the Azure Storage account that is hosting the shares resides.
This includes other Azure regions and your on-premises environment, as long as you allow outbound
traffic on TCP port 445. With SMB 2.1, mappings to file shares are available only from the same Azure
region.
Note: At the time of authoring of this course, the SMB 3.x version in the cifs-utils package in
the Samba project does not support encryption.
Azure storage pricing

The cost associated with Azure storage depends on a number of factors, including:
• Storage account kind. The choice between the general purpose and blob storage accounts has several
implications, as described below.
• Storage account performance level. The choice between the Standard and Premium performance
levels also significantly affects the pricing model, as described below.
• Access tier. This applies to blob storage accounts, which allow you to choose between Cool and Hot
access tiers. This, in turn, affects charges associated with such storage-related characteristics such as
space in use, volume of storage transactions, or volume of data reads and writes.
• Replication settings. LRS storage accounts are cheaper than ZRS accounts, which are cheaper than
GRS accounts; RA-GRS storage accounts are the most expensive.
Note: The Premium performance level implies the use of LRS, because Premium storage
accounts do not support zone and geo-replication.
• Volume of storage transactions (for blob storage accounts and general accounts with Standard
performance level). A transaction represents an individual operation (an individual representational
state transfer application programming interface [REST API] call) targeting a storage account. Pricing
is provided in a currency amount per 10,000 transactions. In case of Premium performance level
storage accounts, there are no transaction-related charges.
• Volume of egress traffic (out of the Azure region where the storage account resides). Inbound data
transfers to Azure are free, and outbound data transfers from Azure datacenters are free for the first 5
GB per month. Banded pricing applies above this level. Effectively, when services or applications co-
locate with their storage, Azure does not impose charges for bandwidth usage between compute and
storage resources. Data transfers incur extra cost with compute and storage spanning regions or with
compute residing in an on-premises environment.
• Amount of storage space in use (for blob storage accounts and general storage accounts with
Standard performance level). Charges are on a per-GB basis. In the case of page blobs, for example,
this means that if you create a new 100-GB virtual hard disk file but use only 10 GB of its total
volume, you are charged for that amount regardless of how much space was provisioned.
• Amount of storage space provisioned (for general purpose storage accounts with Premium
performance only). You calculate Azure Premium Storage pricing based on the size of the disks that
you provision.
Note: If you implement managed disks, pricing also depends on the size of the disks you
provision rather than the amount of disk space in use, even when using the Standard
performance level.
• Volume of data reads and writes (for blob storage accounts with Cool access tier only).
• Type of storage (for general purpose storage accounts). Pricing varies depending on whether you use
a storage account to host page blobs, block blobs, tables, queues, or files.
Additional Reading: For more information, refer to: “Azure Blobs Storage Pricing” at:
http://aka.ms/Mzo4x7
Azure storage partitioning

When designing Azure Storage–based solutions, you should keep in mind that the recommended
approach for load balancing and scaling them out involves partitioning. In this context, a partition
represents a unit of storage that can be updated in an atomic manner as a single transaction.
Each storage service type has its own partitioning mechanism. In the case of blob storage, each blob
represents a separate partition. With table storage, the partition encompasses all entities with the same
partition key. Queue storage designates each queue as a distinct partition. File storage uses individual
shares for this purpose.
Additional Reading: For more information about Azure Storage partitions, refer to: “Azure
Storage Scalability and Performance Targets” at: http://aka.ms/E73svf
Planning for Azure Premium Storage

While it is possible to aggregate the throughput
of Azure-hosted virtual disks with Standard
storage accounts by creating multi-disk volumes,
this approach might not be sufficient to satisfy the
I/O needs of the most demanding Azure VM
workloads. To account for these needs, Microsoft
offers a high performance storage service known
as Premium Storage.
Virtual machines that use Premium Storage are

capable of delivering throughput exceeding
100,000 IOPS by combining the benefits that two
separate components offer. The first one is the
storage account with the Premium performance level, where virtual machine operating system and data
disk files reside. The second one, known as Blobcache, is part of the virtual machine configuration,
available on any VM size that supports Premium Storage. Blobcache is a relatively complex caching
mechanism, which benefits from SSD storage on the Hyper-V host where the Azure VM is running.
Note: For more information about Azure VM sizes, refer to Module 3 in this course.
There are separate limits applicable to the volume of I/O transfers between a virtual machine and a
Premium Storage account, and between a virtual machine and a local cache. As a result, the effective
throughput limit of a virtual machine is determined by combining the two limits. In case of the largest
virtual machine sizes, this cumulative limit exceeds 100,000 IOPS (with the 256 KB size of a single IOP), or
1 GB per second, whichever is lower. Keep in mind that the ability to benefit from caching is highly
dependent on I/O usage patterns. For example, read caching would yield no advantages on disks that
Microsoft SQL Server transaction logs use, but it would likely provide some improvement for disks that
SQL Server database files use.
However, virtual machine I/O throughput is only the first of two factors that determine the overall
maximum I/O throughput. The throughput of virtual machine disks also affects effective throughput. In
the case of Premium Storage, this throughput depends on the disk size, and it is assigned one of the
following performance levels:
• P4. Disk sizes of up to 32 GB, offering 120 IOPS or 25 MB per second.

• P20. Disk sizes of up to 512 GB, offering 2,300 IOPS or 150 MB per second.
• P30. Disk sizes of up to 1 TB, offering 5,000 IOPS or 200 MB per second.
Azure Premium Storage pricing

Azure Premium Storage pricing is calculated based on the size of the disks that you provision, rounded up
to the nearest performance level.
Note: In this case, there are no transaction-related charges. Additionally, no extra costs are
associated with geographic replication, because Premium Storage accounts only support LRS. The
pricing of managed and non-managed Premium Storage disks of the matching size is the same.

Question
Which type of storage does a zone-redundant storage account support?
Page blob
Block blob
Tables
Queues
Files
Lesson 2
Implementing and managing Azure Storage
In this lesson, you will see how to implement the most common storage options in Azure. You will also get
familiar with the tools and utilities that are available to manage Azure Storage.
Lesson Objectives
• Explain how to use the most common Azure Storage tools.
• Explain how to create a storage account.
• Explain how to implement blobs.

• Explain how to implement Azure file storage.
• Explain how to implement Azure table and queue storage.
• Explain how to control access to storage.
• Explain how to configure Azure Storage monitoring.
• Implement Azure Storage.
Storage access tools

Microsoft designed Azure Storage services to
support custom applications and solutions.
Frequently, storage access operations occur via
programmatic methods invoked from custom
code. These methods might use the Azure SDK
libraries or the representational state transfer
(REST) interfaces that developers communicate
with via HTTP and HTTPS-based requests.
However, several tools allow you to examine and
manage content of Azure storage accounts
without resorting to writing custom code.
Examples of such tools include Windows
PowerShell cmdlets, Azure CLI commands, the AzCopy.exe command-line tool, the Azure Storage Explorer
app, and Microsoft Visual Studio.
Azure PowerShell storage cmdlets

You can perform several Azure Storage management tasks by using Azure PowerShell cmdlets. For
example, these cmdlets allow you to explore the content of an Azure storage account:
• Get-AzureStorageBlob. Lists the blobs in a specified container and storage account.
• Get-AzureStorageBlobContent. Downloads a specified storage blob.
• Get-AzureStorageContainer. Lists the containers in a specified storage account.
• Get-AzureStorageShare. Lists the file shares in a storage account.
• Get-AzureStorageFile. Lists the files and directories in a specified storage account.
• Get-AzureStorageFileContent. Downloads a specified file from Azure file storage.

• Get-AzureStorageQueue. Lists the queues in a storage account.
• Get-AzureStorageTable. Lists the tables in a storage account.
Azure CLI storage commands

Azure CLI offers the same features as Azure PowerShell for managing Azure Storage. You can use the
following commands in Azure CLI to perform the same tasks accomplished by using the Azure PowerShell
commands listed above:
• az storage blob list. Lists the blobs in a specified container and storage account.
• az storage blob download. Downloads a specified storage blob.
• az storage container list. Lists the containers in a specified storage account.
• az storage share list. Lists the file shares in a storage account.
• az storage file list. Lists the files and directories in a specified storage account.
• az storage file download. Downloads a specified file from Azure file storage.
• az storage queue list. Lists the queues in a storage account.
• az storage table list. Lists the tables in a storage account.
Note: You can perform the operations listed above from the Azure portal.
AzCopy.exe
AzCopy.exe is a Windows command-line tool that optimizes data transfer operations within the same
storage account, between storage accounts, and between on-premises locations and Azure Storage.
Additional Reading: For a detailed description of AzCopy.exe, including its command-line

switches and example commands, refer to: “Transfer data with the AzCopy Command-Line tool”
at: http://aka.ms/dc878m
Storage Explorer
Storage Explorer is an app available for Windows, Linux, and Mac OS, which provides a graphical interface
for managing several advanced operations on Azure Storage blobs, tables, queues, and files. At the time
of authoring this course, Storage Explorer 0.8 is the most recent version of Storage Explorer.
Additional Reading: To download Storage Explorer, refer to: https://aka.ms/dgfs2c
Visual Studio
Starting with Azure SDK 2.7, you can use Server Explorer and Cloud Explorer from within the Visual Studio
interface to access Azure storage accounts and to manage their content. Both tools allow you to create
storage accounts and manage individual storage services.
Additional Reading: For more information about using Cloud Explorer, refer to: “Manage
the resources associated with your Azure accounts in Visual Studio Cloud Explorer” at:
https://aka.ms/rxh4s5
Creating a storage account

You can create a storage account by using
the Azure portal, the New-
AzureRmStorageAccount Azure PowerShell
cmdlet, or the az storage account create Azure
CLI command. A storage account name must be
globally unique, contain between three and 24
characters, and include only lowercase letters and
digits.
When you create a general purpose storage

account, Azure generates the following endpoints
for access to four respective storage types:
• https://account_name.blob.core.windows.net/
• https://account_name.table.core.windows.net/
• https://account_name.queue.core.windows.net/
• https://account_name.file.core.windows.net/
To create a storage account on the Azure portal, follow these steps:
1. On the Azure portal, on the Hub menu on the left, click +New, and then click Storage.
2. In the Storage blade, click Storage account – blob, file, table, queue.
3. In the Create storage account blade, type a unique Name within the core.windows.net domain. If
the name that you choose is unique, a green check mark appears.
4. Click Resource manager or Classic depending on the type of deployment model you want to use.
5. In the Account kind drop-down list, select either General purpose or Blob storage.
6. Choose storage performance by clicking either Premium or Standard.

7. In the Replication drop-down list, select Locally-redundant storage (LRS), Geo-redundant
storage (GRS), Read-access geo-redundant storage (RA-GRS), or Zone- redundant storage
(ZRS).
8. Specify whether you want to use Storage service encryption for blobs and files by clicking Disabled
or Enabled.
9. Specify whether you want to require secure transfer by clicking Disabled or Enabled.
10. Choose a target subscription or accept the default one.
11. Select an existing resource group or create a new one.
12. In the Location drop-down list, click an Azure region where the storage account will be created.
13. Select or clear the Pin to dashboard check box.
14. Click Create.
Note: The availability of some of these options depends on the deployment model, account
kind, and performance that you choose. For example, as mentioned earlier, Premium storage
accounts support only locally redundant replication.
In Azure PowerShell, you can create a new Azure Resource Manager storage account by issuing the
following command:
Creating a new Azure Resource Manager storage account in Azure PowerShell

New-AzureRmStorageAccount –ResourceGroupName ‘MyResourceGroup’ -AccountName
mystorageaccount –Location ‘Central US’ –Type ‘Standard_GRS’
In Azure CLI, you can create a new Azure Resource Manager storage account by using the following
command:
Creating a new Azure Resource Manager storage account in Azure CLI

az storage account create –-resource-group MyResourceGroup --name mystorageaccount –
location centralus –-sku Standard_GRS
During creation of a storage account, Azure automatically generates two account access keys. For a
general-purpose storage account, Azure also generates four endpoints, one for each storage services type.
Implementing blobs
You can store blobs directly in the root container
of the storage account or create custom
containers in which to store blobs. You can create
blob containers by using any of the tools that this
lesson previously described.
Creating blob containers

When you create a container, you must give it a
name and choose the level of access that you
want to allow from the following options:
• Private. This is the default option. The

container does not allow anonymous access.
This lesson later reviews the available authentication methods.
• Public Blob. This option allows anonymous access to each blob within the container; however, it
prevents browsing the content of the container. In other words, it is necessary to know the full path to
the target blob to access it.
• Public Container. This option allows anonymous access to each blob within the container, with the
ability to browse the container’s content.
Use either of the following methods to create a new container. Before you can create the container, you
must obtain a storage context object by passing the storage account’s primary key:
Creating a blob container in Azure PowerShell

$storageKey = (Get-AzureRmStorageAccountKey –ResourceGroup ‘myResourceGroup’ -
StorageAccountName ‘mystorageaccount).Value[0]
$storeContext = New-AzureStorageContext -StorageAccountName ‘mystorageaccount’ -
StorageAccountKey $storeKey
$container = New-AzureStorageContainer –Name ‘mycontainer’ -Permission Container -Context
$storeContext
Creating a blob container in Azure CLI

az storage account keys list –account-name mystorageaccount –resource-group
myResoureGroup
export AZURE_STORAGE_ACCOUNT=mystorageaccount
export AZURE_STORAGE_ACCESS_KEY=<storage_account_key>
az storage container create –name mycontainer –public-access container
Administrators can view and modify containers, in addition to uploading and copying blobs by using tools
such as AzCopy and Storage Explorer. They can also use the following Azure PowerShell cmdlets:
• Remove-AzureStorageBlob. Remove the specified storage blob.
• Set-AzureStorageBlobContent. Upload a local file to the blob container.
• Start-AzureStorageBlobCopy. Copy to a blob.
• Stop-AzureStorageBlobCopy. Stop copying to a blob.

• Get-AzureStorageBlobCopyState. Get the copy state of a specified storage blob.
You can perform the same tasks by using the following Azure CLI commands:
• az storage blob delete. Remove the specified storage blob.

• az storage blob upload. Upload a local file to the blob container.
• az storage blob copy start. Copy to a blob.
• az storage blob copy stop. Stop copying to a blob.
• az storage blob show. Get the copy state of a specified storage blob.
Implementing Azure file storage

You use the Azure File service to create file shares
in an Azure storage account that are accessible
through the SMB 2.1 or SMB 3.x protocol. Because
you can access on-premises file servers by using
the same protocols, Azure file shares can be
particularly helpful when you migrate on-premises
applications to Azure. If these applications store
configuration or data files on SMB shares,
migration typically will not require any changes to
the application code.
Creating file shares

Within a storage account, you can create multiple
file shares. To create a file share, you can use the Azure portal, Azure PowerShell, Azure CLI, the REST API,
or the storage access tools that this lesson described earlier. You can create a folder hierarchy to organize
the content of each share. You can manage folders by using the same Windows tools that apply to on-
premises environments, including File Explorer or the command prompt.
Use the following commands to create a file share, to create a folder, and to upload a file:
Managing an Azure file share by using Azure PowerShell

$storageAccount = ‘mystorageaccount’
StorageAccountName $storageAccount).Value[0]
$context = New-AzureStorageContext -StorageAccountName $storageAccount -StorageAccountKey
$storageKey
#Create the new share

$share = New-AzureStorageShare -Name ‘myshare’ -Context $context
#Create a directory in the new share

New-AzureStorageDirectory -Share $share -Path ‘mydirectory’
#Upload a file
Set-AzureStorageFileContent -Share $share -Source ‘.\instructions.txt’ -Path
‘mydirectory’
Managing an Azure file share by using Azure CLI

myResoureGroup
#Create the new share

az storage share create –name myshare
#Create a directory in the new share

az storage directory create –name mydirectory –share-name myshare
#Upload a file
az storage file upload –source ./instructions.txt –share-name myshare –path mydirectory
Using file shares

To access an Azure file share from an Azure VM running Windows or from an on-premises Windows
computer, run the net use command. The following command will map drive Z to the reports share,
where the storage account is called “adatum12345” and the storage access key is
PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==:
Mapping a drive to an Azure file share from Windows

net use z: \\adatum12345.file.core.windows.net\reports /u:adatum12345
PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==
If you want a drive mapping to persist across reboots, then you need to store the credentials you used to
map the drive, including the storage account name and its key in Windows Credential Manager. You can
use for this purpose either the graphical interface of Credential Manager or the cmdkey command-line
tool.
To mount an Azure file share from a Linux Azure VM, run the mount –t cifs command. The following
command creates a mount point, /mnt/mountpoint, and uses it to mount the reports share, where the
storage account is called adatum12345 and the storage access key is
PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==:
Mapping a drive to an Azure file share from Linux

mkdir -p /mnt/mymountpoint
sudo mount -t cifs //adatum12345.file.core.windows.net\reports -o vers=3.0,username=
adatum12345,password=PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==,dir_mode=0777,file_mode=0777
If you want the mount to persist across reboots, you need to add the following line to the /etc/fstab file:
Persisting a mount to an Azure file share from Linux

//adatum12345.file.core.windows.net/reports /mymountpoint cifs
vers=3.0,username=adatum12345,password=PlsDTS0oEJWWQ8YOiVbL5kvow0/yg==,dir_mode=0777,file
_mode=0777
Implementing Azure table and queue storage

Typically, applications create tables and queues
programmatically. Applications also are
responsible for populating tables with entities and
writing messages to queues, and for reading and
processing that content afterward. As a storage
administrator, you can also view and manage
tables and queues with tools such as Storage
Explorer. The Azure portal, Azure PowerShell, and
Azure CLI also provide a basic method for
managing tables and queues.
For example, you could use the following Azure

PowerShell script to create a table:
Creating a storage table by using Azure PowerShell

StorageAccountName $storageAccount).Primary
$storageKey
New-AzureStorageTable -Name ‘MyTable’ -Context $context
You could achieve the same outcome by using the following Azure CLI commands:
Creating a storage table by using Azure CLI

myResoureGroup
az storage table create –name MyTable
To create a new messaging queue by using Azure PowerShell, run the following commands:
Creating a storage queue in Azure PowerShell

StorageAccountName $storageAccount).Primary
$storageKey
New-AzureStorageQueue -Name myqueue -Context $context
To achieve the same outcome by using Azure CLI, you could use the following commands:
Creating a storage table by using Azure CLI

myResoureGroup
az storage queue create –name myqueue
Controlling access to storage

Security is vitally important in any cloud solution.
Azure Storage offers a number of mechanisms
that protects its content from unauthorized
access. These mechanisms include storage
account keys, shared access signatures, stored
access policies, and role-based access control
(RBAC). In this topic, you will see how to
implement and manage each of them.
Storage access keys

Azure automatically generates a primary and
secondary access key for each storage account.
The knowledge of either of them provides full
control over the storage account from management utilities and client applications. The Azure portal
offers a convenient way to copy both keys to the Clipboard. Alternatively, you can retrieve them by
invoking the Get-AzureRmStorageAccountKey Azure PowerShell cmdlet or az storage account keys
list Azure CLI command.
For example, the following Azure PowerShell cmdlet retrieves the storage keys for a storage account
named “myaccount” in the resource group named “myResourceGroup” in the current Azure subscription:
Obtaining storage keys by using Azure PowerShell

Get-AzureRmStorageAccountKey –ResourceGroupName ‘myResourceGroup’ StorageAccountName
‘myaccount’
To achieve the same outcome by using Azure CLI, you would run the following command:
Obtaining storage keys by using Azure CLI

az storage account keys list–-resource-group myResourceGroup –account-name myaccount
Having two storage keys allows you to regenerate one of them without disrupting applications that
require continuous access to the storage account. For example, if you regenerate the primary key,
applications can still successfully authenticate if they reference the secondary key. Next, you can repeat
this process to regenerate the secondary key, starting with modifying your applications by pointing them
to the new primary key.
To regenerate the primary access key, use the Azure portal or run the
New-AzureRmStorageAccountKey cmdlet:
Regenerating the primary key by using Azure PowerShell

New-AzureRmStorageAccountKey -KeyType Primary –ResourceGroupName ‘myResourceGroup’ -
StorageAccountName myaccount
To achieve the same outcome by using Azure CLI, run the az storage account keys renew command:
Regenerating the primary key by using Azure CLI

az storage account keys renew –account-name myaccount –key primary –resource-group
myResourceGroup
Shared access signatures

The automatically generated primary and secondary access keys provide full administrative access to their
respective storage account, which is not suitable for scenarios that necessitate more restrictive privileges.
To answer this need, Azure Storage also supports the Shared Access Signature (SAS) authentication
mechanism. SAS-based authentication allows you to limit access to designated blob containers, tables,
queues, and file shares only, or even to narrow it down to individual resources such as blobs, ranges of
table entities, and files. Shared access signatures also offer the ability to specify the set of operations that
are permitted on these resources. Additionally, you can limit the validity of shared access signatures
authentication tokens by assigning a start and end date, and the time of the delegated access. SAS also
allows you to restrict access to one or more IP addresses from which a request originates. Finally, by
adjusting SAS parameters, you can enforce the use of HTTPS, rejecting any HTTP requests.
Microsoft also supports account-level shared access signatures. This functionality allows you to delegate
permissions to perform service-level operations, such as creating blob containers or file shares.
A shared access signature takes the form of a Uniform Resource Identifier (URI), which is signed with the
storage account key. An application or a user with the knowledge of that URI can connect to the
corresponding storage account resources and perform delegated actions within the period that the token
validity parameters defined.
Most commonly, applications rely on the REST API to generate shared access signature URIs. However,
you can also create them by using the Azure portal, Azure PowerShell, or Azure CLI. For example, the
New-AzureStorageRmContainerSASToken Azure PowerShell cmdlet and the az storage container
generate-sas command generate a shared access signature token for a blob container in a storage
account.
Stored access policies

While shared access signatures allow you to narrow down the scope of privileges and duration of access
to content for an Azure storage account, their management presents some challenges. In particular,
revoking access that was granted directly through a shared access signature requires replacing the storage
account keys with which its URI was signed. Unfortunately, such an approach is disruptive because it
invalidates any currently configured connections to the storage account.
To address this challenge, Azure Storage supports stored access policies. You define such policies on the
resource container level, including blob containers, tables, queues, or file shares, by specifying the same
parameters that you would otherwise assign directly to a shared access signature, such as the level of
permissions or start and end of the token validity. After a shared access policy is in place, you can
generate shared access signature URIs that inherit its properties. Revoking policy-based shared access
signature tokens requires modifying or deleting the corresponding policy only, without affecting access
granted via storage account keys or shared access signature URIs that are associated with other policies.
Additional Reading: For more information about using shared access signatures and stored
access policies, refer to: “Shared Access Signatures, Part 1: Understanding the shared access
signature model” at: http://aka.ms/R96g60
RBAC
In order to control delegated management of Azure Storage resources you can use RBAC. This can serve a
supplemental role to the storage access control mechanisms described above. However, note that RBAC
applies to managing storage accounts, while the other methods presented in this topic, are applicable to
controlling access to storage account content.
RBAC includes a few predefined roles that provide delegated access to Azure storage accounts, including
Reader, Contributor, Storage Account Contributor, and Virtual Machine Contributor. If these roles are not
flexible enough, you can define custom ones. Their definitions consist of a list of permitted and prohibited
operations and assignable scopes to which these operations apply.
Additional Reading: For more information about RBAC, refer to: “Azure Role-based Access
Control” at: http://aka.ms/Jq63oa
Note: Managed disks provide more granular control over access to virtual machine disk files
by using RBAC. Module 3 of this course, “Implementing virtual machines,” covers managed disks
in more detail.
Monitoring storage
Monitoring and diagnostics features are built into
the functionality of any standard Azure storage
account, allowing you to view, record, and analyze
its performance and utilization levels so that you
can adjust your storage design according to your
workloads’ demands.
Note: Monitoring and diagnostics are not

available for Azure Premium Storage accounts.
Managing diagnostics
By default, storage account diagnostics collect aggregate and per-API metrics for blob, table, and queue
storage, and retain them for seven days. The diagnostics configuration settings are accessible from the
Diagnostics blade in the Azure portal. From there, you can perform the following actions:
• Set the retention period to a value between 1 and 365 days.
• Selectively disable or enable aggregate metrics for each type of storage service. This includes data
such as the volume of ingress and egress traffic, availability, latency, or percentage of successful
access requests aggregated for the Blob, Table, Queue, and File services.
• Selectively disable or enable per-API metrics. This provides more granular control, allowing you to
decide if you should collect aggregates of individual types of storage API operations.
• Selectively disable or enable logs for the Blob, Table, and Queue services. This allows you to view the
details of each operation and is helpful in diagnosing the causes of poor performance or identifying
unauthorized access attempts.
Note: At the time of authoring this course, logs are not available for the Azure Storage File
service. Metrics and logging are also disabled for the ZRS storage accounts.
Note: To view logs, you can use any of the Azure Storage tools described earlier in this
lesson. Logs reside in the $logs blob container of the storage account.
To modify diagnostics settings for an existing storage account by using the Azure portal, follow these
steps:
1. In the Azure portal, on the Hub menu, click More services.
2. In the list of services, click Storage accounts.
3. On the Storage accounts blade, click the storage account that you want to configure.
4. On the storage account blade, click the Monitoring lens.

5. On the Metric blade, click Diagnostic settings.
6. If diagnostics are disabled, on the Diagnostics blade, click On below the Status label.
7. Select the check boxes next to the metrics or logs that you want to collect.
8. Use the slider at the bottom of the blade to set the number of days (from 1 through 365) to retain
diagnostics data.
9. Click Save.
Note: Enabling diagnostics incurs a cost, because collected data resides in tables and blobs
in the same storage account.
Additional Reading: You can configure diagnostics settings automatically when you
provision a storage account by using a Resource Manager template. For details, refer to:
“Automatically enable Diagnostic Settings at resource creation using a Resource Manager
template” at: https://aka.ms/pil2av
After you enable diagnostics for a storage account, you can display collected data in the Monitoring lens
in the storage account’s blade on the Azure portal.
To add a metric to the monitoring chart, follow these steps:

1. On the Azure portal, click the Monitoring lens of the account’s blade, and then click Edit chart.
2. On the Edit Chart blade, select the Time Range (past hour, today, past week, or custom).
3. In the drop-down list box below the Time Range section, select the storage service type for which
you want to display metrics (blob, queue, table, or file).
4. Select check boxes next to the individual metrics that you want to display in the chart.
5. Click OK.
Managing alerts
You can configure alerts for any storage resource based on the metrics that you are collecting. An alert
indicates when the value of a metric that you designated satisfies a set of criteria that you defined. The
criteria include a condition (such as greater than), a threshold value that depends on the type of metric,
and a time period during which the condition must be satisfied. You can configure an alert to send an
email to owners, contributors, or readers of the target resource, in addition to sending an email to an
arbitrary email address. Additionally, as part of the alert definition, you can specify a Webhook, which
designates an HTTP or HTTPS endpoint to which the alert would be routed.
Perform the following steps to set up an alert:
1. On the storage account’s blade on the Azure portal, click the Monitoring lens.
2. On the Metric blade, click Add alert.
3. In the Add an alert rule blade, specify the:
o Resource. This is the name of the target resource (storage account and service type).
o Name. This is the name of the alert.
o Description. This is the description of the alert.
o Metric. This is the metric on which the alert is based.
o Condition. This is greater than, greater than or equal to, less than, less than or equal to.
o Threshold. This value corresponds to the condition that you specified.
o Period. This is the period during which a condition is evaluated (from 5 minutes through 6 hours).
o Email owners, contributors, and readers. This is a check box that needs to be enabled or disabled.
o Additional administrator emails. This is a text box in which you can specify one or more email
accounts.
o Webhook. This is the HTTP or HTTPS endpoint to which the alert will route.
4. Click OK.
Monitoring performance of Azure Premium storage accounts

If you want to monitor an Azure Premium Storage account, you should use the monitoring utilities
available from a virtual machine that contains the virtual hard disk files that are stored in that storage
account. Such utilities include Performance Monitor in Windows operating systems or iostat in the Linux
operating system. You can also gather diagnostics data by using the Azure VM Diagnostics extension.
Demonstration: Implementing storage

• Use Windows PowerShell to upload blobs.
• View blob storage in Visual Studio.
• Configure monitoring and logging.


Question
You need to provide a customer with time-limited access to the content of a blob container in an
Azure Storage account. You must ensure that you can revoke the access without affecting other
customers who might access the same storage account. What should you do?
Give the customer the primary access key.
Give the customer the secondary access key.
Configure the container as public.
Give the customer a shared access signature.
Configure a stored access policy. Give the customer a shared access signature based on the
stored access policy.
Lesson 3
Implementing Azure CDNs
Azure provides the CDN service, which decreases the time it takes to download web content by first
distributing it across multiple locations around the world and then delivering it from the location that is
closest to the consumer of that content. This lesson presents the concept and architecture of CDNs and
describes the process of implementing Azure CDNs.
Lesson Objectives
• Describe the purpose and functionality of CDNs.
• Describe CDN architecture.
• Explain how to cache blob content by using Azure CDNs.
• Explain how to cache cloud services content by using Azure CDNs.

• Explain how to use custom domain addresses with Azure CDNs.
Overview of CDNs
The delivery speed of internet-resident content is
a key factor in satisfying consumers of media and
web-based applications. Content Delivery
Network represents a collection of globally
distributed servers at locations referred to as
points of presence (POP), whose purpose is to
maximize this speed. Content Delivery Network
accomplishes this objective by caching web and
media content across its servers and then
delivering it from the server that is closest to the
consumer of that content. More specifically, by
default, when a user or app requests content
configured for integration with Content Delivery Network, Azure attempts to retrieve such content from
the nearest Content Delivery Network server. If the content is not available, Azure retrieves it from the
origin, and the Content Delivery Network servers cache it to make it available for subsequent requests.
CDNs offer a number of advantages:
• Improved user-experience, especially if users reside in areas distant from the original content location.
• Protection of published content from distributed denial of service attacks. Azure CDNs include
functionality that detects such attacks. Providing multiple copies of content serves as an additional
mitigating factor.
• Improved scalability by eliminating performance bottlenecks that are associated with hosting content
in a single location.
• Increased resiliency by eliminating a single point of failure. In particular, if one CDN node becomes
unavailable, the service transparently redirects requests to the nearest node.
Note: CDNs are intended primarily for static content. Dynamic content needs to be
refreshed constantly from the content provider, minimizing and potentially eliminating any
associated CDN benefits. You can, however, provide efficient caching in some scenarios that
involve serving different content depending on input values incorporated into the web request.
Additional Reading: For more information, refer to: “Using CDN for Azure” at:
http://aka.ms/Aaa7h4
Additional Reading: For the latest POP list, refer to: “Azure Content Delivery Network (CDN)
POP Locations” at: http://aka.ms/P70n6a
CDN architecture
CDN caches content from a range of Azure
services, including Azure Storage blobs, Azure
Web Apps, and Azure Cloud Services. Additionally,
Content Delivery Network can cache content from
web apps residing in on-premises datacenters or
hosted by third-party cloud providers.
To improve your web app’s responsiveness by
leveraging CDN, you must create a CDN profile,
which serves as a logical grouping of endpoints,
representing the origins of cached content. When
a user requests the web app’s content, Azure
attempts to retrieve it from the nearest available
endpoint. If the content is not available, Azure retrieves it from the origin, and subsequently CDN
endpoints cache it.
A CDN profile constitutes an administrative and billing unit. The cost depends on the pricing tier of the
profile, the volume of outbound data transfers associated with transferring content to the CDN endpoints,
and, in the case of Azure Storage blobs, the amount of storage transactions. Within the profile, you can
manage additional features, such as:
• Geo-filtering. This includes blocking or allowing access to cached content from designated
countries/regions.
• Analytics and reporting. Core analytics include information about CDN usage patterns, including such
parameters as bandwidth, data transferred, or cache hit ratio. Advanced HTTP reports provide similar
information in an easy-to-review format. For example, geography reports show regions from which
requests for your content originate. Daily Summary reports aggregate such statistics as number of hits
or amount of data transferred from your points of origin.
• Delivery rules. By using the delivery rules, you can alter default processing of HTTP requests, allowing
you to block different types of content or return customized HTTP headers. You can also enforce
different caching policies depending on properties of incoming requests, such as client IP address or
the request header.
• Asset preloading. By default, content is copied from its origin into the cache on CDN servers only in
response to incoming requests. The first request for such content will likely incur extra latency. By
preloading content (referred to in this case as assets), you can eliminate this initial delay.
• Purging. By default, cached content remains in the cache until its Time to Live (TTL) expires. However,
there might be situations where cache is out of sync with the origin. In such cases, you can use the
purge capability to remove outdated content from the cache. As a result, the subsequent request will
trigger retrieval of up-to-date content from the origin.
Availability of these features depends on the CDN product. At the time of authoring of this course, there
are three CDN products: Azure CDN Standard from Akamai, Azure CDN Standard from Verizon, and Azure
CDN Premium from Verizon.
Additional Reading: For more information regarding features available with each CDN
product, refer to: “Overview of the Azure Content Delivery Network (CDN)” at:
https://aka.ms/ke4fqv
A CDN profile can contain up to ten endpoints, and there is a limit of eight CDN profiles per Azure
subscription. Each endpoint designates an origin of cached content and can point to an:
• Azure Storage blob.
• Azure Web app that is associated with a Standard or Premium App Service plan.
• Azure cloud service.
• Azure Media Services streaming endpoint.
• Custom origin. A custom origin can represent any web location accessible via HTTP or HTTPS,
including your web apps hosted in perimeter networks of on-premises datacenters.
For every endpoint, you can configure a number of settings, such as:
• Compression. You can enable or disable this setting.
• Query string caching behavior. You use this setting to customize caching behavior, depending on
whether the request to the endpoint includes a query string. For example, by selecting the Cache
every unique URL option, CDN will cache content from a URL ending with “page1.ashx?q=one”
separately from content from a URL ending with “page1.ashx?q=two”. Alternatively, you can cache
the same content for both of these requests by choosing the Ignore query strings option, or ignore
caching altogether when you choose the Bypass caching for query string option.
• Protocols. You use this setting to enable an endpoint for HTTP and HTTPS.
Creating CDN profiles and endpoints

To provision a CDN, you first need to create a CDN profile. To create a CDN profile, use the following
steps:
1. In the Azure portal, click New on the Hub menu on the left side.
2. On the New blade, click Web + Mobile.
3. On the Web + Mobile blade, click CDN.
4. On the CDN profile blade, specify the following:
o Name. Use a unique name in your current subscription and resource group.
o Subscription. This is your current subscription that should host the profile.
o Resource group. This is a new or existing resource group.
o Location. This Azure region will host the profile.

o Pricing tier. Choose between Premium Verizon, Standard Verizon, and Standard Akamai.
o Pin to dashboard. Enable this if you want the CDN profile to appear directly on the dashboard.
5. Click Create.
To create a CDN endpoint within a CDN profile, follow these steps:
1. On the CDN profile blade, click + Endpoint.
2. On the Add an endpoint blade, specify the following:
o Name. This is a unique name in the azureedge.net Domain Name System (DNS) namespace.
o Origin type. This can be Storage, Cloud service, Web App, or Custom origin.
o Origin hostname. This is the name of the service that represents the origin type that you selected.
o Origin path. This designates the directory path of the content that CDN should retrieve from the
origin.
o Origin host header. This designates the host header value that should be sent to the origin with
each request. This is applicable if you host multiple virtual domains on a single target server.
o Protocol and origin port. This allows you to selectively enable or disable HTTP and HTTPS and
specify their respective ports.
o Optimized for. The values available for this setting depend on the pricing tier. They include
general web delivery, general media streaming, video on demand media streaming, large file
download, and dynamic site acceleration.
3. Click Add.
Caching content from Azure blobs, Azure Web apps, and Azure cloud
services
For a CDN to cache blobs, they must be accessible
anonymously. This effectively means that blobs
should reside in containers with an access type
property of either Blob or Container.
When you configure a CDN endpoint that points

to a public container in an Azure storage account
as its origin, you effectively define a new URL to
access blobs in the container via CDN. For
example, if you have a storage account named
”mystorageaccount” with a public container
named “public”, then the origin would be
designated by the combination of the origin
hostname and the origin path, yielding the URL http://mystorageaccount.blob.core.windows.net/public.
When you create an endpoint, you need to choose a unique name in the azureedge.net DNS namespace,
which represents the CDN cached content that is available at http://uniquename.azureedge.net/public.
A blob stays in the CDN cache for a period referred to as the Time to Live (TTL), which is seven days by
default. You can modify this by assigning a custom TTL value to a blob. In such cases, Azure Storage
returns the TTL value as part of a Cache-Control header in response to a CDN caching request. To assign a
custom value to an Azure Storage blob, you can use Azure PowerShell, Azure CLI, Azure Storage Client
Library for .NET, REST APIs, or the Azure storage management tools described earlier in this module.
Similar to blob-based endpoints, cached content from Azure Web apps and Azure cloud services has a
seven-day TTL by default. The TTL is determined by the value of the Cache-Control header in the HTTP
response from the origin. For Azure Web apps and Azure cloud services, you can set this value by
specifying the system.webServer\staticContent\clientCache element in the applicationHost.config
file for your site or web.config files for your individual web apps. The setting dictates a custom TTL value
for all objects within the site or within the web app. Web app–level settings take precedence over site-
level settings. For ASP.NET applications, you can further customize TTL by assigning CDN caching
properties programmatically by setting the HttpResponse.Cache property.
Additional Reading: For more information about TTL with cloud services, refer to: “How to
Manage Expiration of Cloud Service Content in the Azure Content Delivery Network (CDN)” at:
http://aka.ms/Vx0qfy
Using custom domains to access CDNs

In many scenarios, you might want to point to
CDN–cached content by using names that belong
to your own custom DNS namespace, rather than
referencing names in the default azureedge.net
namespace that CDN assigns.
To accomplish this, you first need to create a DNS
canonical name record (CNAME record) at your
domain registrar, which represents an alias of the
CDN endpoint’s FQDN. Next, you must include
the custom domain in the configuration of the
endpoint’s settings. During the second part of this
process, CDN verifies whether the CNAME record
actually exists.
Note: Remember that, by default, the CDN endpoint is not accessible via the newly
registered CNAME record for up to 90 minutes following the verification step. This is because of
the time it takes to propagate custom domain settings across all CDN nodes. To avoid this delay,
you can preregister the asverify subdomain within your custom domain and use it for
verification.
Additional Reading: For details regarding using the asverify subdomain, refer to: “How to
map Custom Domain to Content Delivery Network (CDN) endpoint” at: https://aka.ms/ivysl3

Question
What is the default period during which content remains cached by a CDN?
One day
Two days
Five days
Seven days
14 days
Lesson 4
Implementing Azure Backup
Azure offers several different options that you can use to take advantage of its services for backup of on-
premises and cloud-based systems. Some Azure backup options integrate seamlessly with existing
Microsoft backup products, including built-in Windows Backup software and Microsoft System Center
2016 Data Protection Manager (DPM). Other options such as Azure VM-level backup or Microsoft Azure
Backup Server can enhance or even replace existing backup solutions. This lesson details characteristics
and functionality of various Azure backup options.
Lesson Objectives
• Describe the available Azure Backup options.
• Explain how to perform file and folder backups with the Azure Recovery Services Agent.
• Explain how to protect Azure IaaS virtual machines by using Azure Backup VM extensions.
• Describe how to integrate Azure Backup with Data Protection Manager and Azure Backup Server.
• Integrate Azure Backup with System Center 2016 Data Protection Manager.
Overview of Azure Backup

The Azure Backup service uses Azure resources for
short-term and long-term storage to minimize or
even eliminate the need for maintaining physical
backup media such as tapes, hard drives, and
DVDs. Since its introduction, the service has
evolved from its original form, which relied
exclusively on a Windows Server backup agent
that was downloadable on the Azure portal, into a
much more diverse offering. The Azure Backup
service includes:
• A Windows 64-bit Server and Client file,

folder-level backups with the Recovery
Services Agent, and the Online Backup integration module for Windows Server Essentials.
• Long-term storage for backups with Data Protection Manager and Recovery Services Agent.
• Long-term storage for backups with Microsoft Azure Backup Server and Recovery Services Agent.
• Windows-based and Linux-based Azure IaaS VM-level backups with the Azure VM extensions
(VMSnapshot and VMSnapshotLinux, respectively).
Recovery Services vault

Regardless of the backup functionality that you intend to implement, to use Azure Backup to protect your
data, you must first create a Recovery Services vault in Azure. A vault is the virtual destination of your
backups, which also contains configuration information about the systems that Azure Backup protects. To
protect a system, you must register it with a vault. The vault should reside in an Azure region that is close
to the physical location of the data, and in the case of Azure IaaS virtual machines, in the same region.
Two resiliency options are available when creating an Azure Recovery Services vault: locally redundant and
geo-redundant. The first option is based on locally redundant Azure Storage, consisting of three copies of
backed-up content in the same Azure region. The second option is based on geo-redundant Azure
Storage, including three additional copies in another Azure region, providing an additional level of
protection.
Note: You should set this option as soon as you create the vault, since will not be able to
change it once you register the first of your systems with the vault.
An Azure subscription can host up to 25 vaults. Each vault can protect up to 50 computers that run the
Recovery Services Agent or the Online Backup integration module. Alternatively, if you back up Azure IaaS
virtual machines by relying on the Azure IaaS VM Backup extension, the vault can protect up to 200
computers.
Note that there is no limit on the amount of data in the vault for each protected computer. There also is
no limit on the maximum retention time of backed up content. However, there is a restriction on the size
of each data source: about 54,000 GB for Windows 8, Windows Server 2012, and newer operating systems.
The maximum backup frequency depends on the backup approach, with up to three backups per day
with Windows Server and Client Recovery Services Agent, up to two backups with Data Protection
Manager or the Microsoft Azure Backup Server, and a single backup when using VM extension–based
setup.
All backups are encrypted at the source with a passphrase that the customer chooses and maintains.
There are no additional charges for the traffic generated during backup, both ingress, into Azure and
during restore, egress, out of Azure.
Note: Azure Backup relies on the same agent as Azure Site Recovery, which later topics in
this module will discuss. This is the reason for the references to the Recovery Services Agent in
this lesson. Both Azure Backup and Azure Site Recovery also store data from systems they protect
by using an Azure Recovery Services vault. A single vault can simultaneously serve as the
repository for Azure Backup and Azure Site Recovery.
File and folder backups with the Recovery Services Agent

Azure Backup’s most basic functionality allows you
to protect folders and files on 64-bit Windows
Server and client operating systems, both on-
premises and in Azure. This functionality relies on
the Recovery Services Agent, which is available for
download on the Azure Recovery Services vault
interface in the Azure portal. You must install the
agent on every system that you want to protect,
and you must register it with the target vault.
To set up Recovery Services Agent –based protection for an on-premises Windows computer from the
Azure portal, perform the following steps:
1. Create a Recovery Services vault.
2. Configure the Backup Infrastructure storage replication type, by choosing either the Locally-
redundant option or the Geo-redundant option on the Backup Configuration blade.
3. Specify Backup Goal settings, including the:
o Location of the workload: On-premises
o Workload type: Files and folders
4. Download the vault credentials from the Prepare infrastructure blade of the Azure Recovery
Services vault. The Recovery Services Agent uses vault credentials to register with the vault during the
installation process.
5. Download the Recovery Services Agent from the Prepare infrastructure blade. Choose the
appropriate option for the system that you want to protect. In this case, you need to select the
Download Agent for Windows Server or Windows Client option.
6. Install the Recovery Services Agent and register it with the vault. When registering with the vault,
you specify a custom passphrase for encrypting backups.
7. Use the Azure Backup console to configure and schedule backups. After installing the agent, the new
console, whose interface closely matches the native Windows backup console, becomes available. This
allows you to select files and folders to back up and to schedule a backup directly to the Azure
Recovery Services vault. You can also use Azure PowerShell to configure and initiate backup
operations. After you schedule a backup, you also have the option to run an on-demand backup.
Note: If the computer that you want to protect contains a large amount of data and you
have limited bandwidth in your internet connection to Azure, consider using the Azure
Import/Export service to perform the initial backup. In this approach, you copy the data to back
up locally to a physical disk, encrypt it, and then ship the disk to the Azure datacenter where the
vault is located. Azure then restores the content directly to the vault, which allows you to perform
an incremental rather than full backup following the registration.
Additional Reading: For more information, refer to: “Back up a Windows Server or client to
Azure using the Resource Manager deployment model” at: http://aka.ms/Aabdfe
VM-level backup by using the Azure Backup VM extension

If the systems that you want to protect are
running the Windows or Linux operating systems
on Azure VMs, you can perform a VM-level
backup. This process uses the Azure VMSnapshot
(on Windows) or Azure VMSnapshotLinux (on
Linux) extension. A VM-level backup offers
application consistency for Windows virtual
machines. It also offers a higher limit for the
number of protected systems per vault, which is
200 Azure VMs instead of 50 protected systems
with the Recovery Services Agent. On the other
hand, the backup frequency in this case is limited
to once per day.
You should also keep in mind that the restore process available from the Azure portal creates a new
virtual machine. As a result, an Azure VM–level backup does not facilitate restoring individual files or
folders. In addition, the restore does not include such VM-level settings as network configuration, which
means that you must recreate them after the restore. However, you can overcome these shortcomings by
using Azure PowerShell to perform a restore. This allows you, for example, to restore individual disks. You
should use scripting when recovering Azure VMs that host Active Directory domain controllers or that
have complicated network configuration, including such characteristics as load balancing, multiple
reserved IP addresses, or multiple network adapters.
Setting up an Azure IaaS VM-level backup by using the Azure portal involves the following steps:
1. If you do not already have an available Recovery Services vault, create a new one. Note that the vault
must reside in the same Azure region as the Azure IaaS virtual machines.
2. Specify the vault’s storage replication type.
3. Specify Backup goal settings, including the:
o Location of the workload: Azure

o Workload type: Virtual machine
4. Choose the backup policy. The policy determines backup frequency and retention range. The default,
predefined policy triggers the backup daily at 6:30 PM and has the 30-day retention period. You can
create a custom policy to modify these values, by scheduling backup to take place on specific days
and setting the retention period on a daily, weekly, monthly, and yearly basis.
5. Specify the virtual machines to back up. The Azure portal will automatically detect the Azure VMs
which satisfy Azure VM–level backup requirements. When you click Items to backup on the Getting
started with backup blade, the Azure portal will display these virtual machines on the Select virtual
machines blade. This will automatically deploy the Azure VM backup extension to the virtual
machines you that select and register them with the vault.
6. At this point, you can identify the Azure VMs that are backed up to the vault by viewing the content
of the Backup Items blade.
Integrating Azure Backup with Data Protection Manager and Microsoft

Azure Backup Server
If your environment contains a large number of
systems that require protection, you might want
to consider implementing Microsoft Azure Backup
Server. Alternatively, if you have an existing
implementation of DPM, you will likely benefit
from integrating it with Azure Backup by installing
the Recovery Services Agent on the DPM server.
These two methods generally yield equivalent

results. Microsoft Azure Backup Server provides
the same set of features as DPM, except support
for tape backups and integration with other
System Center products. Azure Backup Server also
offers the same management interface as DPM. Effectively, by implementing Microsoft Azure Backup
Server, you gain enterprise-grade protection without requiring System Center licenses.
With both of these products, you can provide recovery for Linux and Windows operating systems that run
on-premises or in Azure, as long as an Azure Backup Server or DPM server resides in the same location.
DPM and Azure Backup Server support consistent application backups of the most common Windows
server workloads, including SQL Server, Office SharePoint Server, and Microsoft Exchange Server. They
also deliver superior efficiency and disk space savings because of built-in deduplication capabilities.
It is important to remember that unlike the other Recovery Services Agent–based methods, neither DPM
nor Azure Backup Server can back up data directly to an Azure Recovery Services vault. Instead, they
operate as disk-to-disk-to-cloud solutions, using their local disks as the immediate backup target, and
afterward, copying data to Azure from the newly created backup.
To integrate System Center DPM with Azure Backup by using the Azure portal, you must perform the
following steps:
1. If you do not already have an available Recovery Services vault, create a new one.
Note: You can use the same vault for protecting Azure VMs with the Azure Backup VM
extension and systems that run the Recovery Services Agent, including System Center DPM.

o Workload type: any combination of Hyper-V Virtual Machines, VMware Virtual Machines,
Microsoft SQL Server, Microsoft SharePoint, Microsoft Exchange, System State, or Bare
Metal Recovery
4. On the Prepare infrastructure blade of the Azure Recovery Services vault, select the Already using
System Center Data Protection Manager or any other System Center product check box.
5. Download the vault credentials from the Prepare infrastructure blade. The Recovery Services Agent
uses vault credentials to register with the vault during the installation process.
6. Download and install the Recovery Services Agent from the Prepare infrastructure blade. Start by
clicking the Download link. Once the download completes, run the installation and register the local
computer running System Center Data Protection Manager with the vault. As part of the registration,
designate a passphrase for encrypting backups.
7. From the Protection workspace of the DPM Administrator Console, create a new protection group
or modify an existing one. Within the protection group settings, enable the Online Protection
option.
Note: You must enable short-term protection by using local disks. While you cannot use
tapes for this purpose, you can additionally enable long-term protection to tape. As part of the
protection group configuration, specify an online backup schedule, online protection data, online
retention policy, and initial online backup methodology. Similar to the Azure Backup consoles,
you can choose between performing initial backup over the internet and using the Azure
Import/Export service to copy it offline.
Deploying Microsoft Azure Backup Server by using the Azure portal requires that you perform the
following steps:
1. If you do not already have an existing, available Recovery Services vault, create a new one.
Note: You can use the same vault for protecting Azure VMs with the Azure Backup VM
extension and systems that run the Recovery Services Agent, including System Center DPM.

o Workload type: any combination of Hyper-V Virtual Machines, VMware Virtual Machines,
Microsoft SQL Server, Microsoft SharePoint, Microsoft Exchange, System State, or Bare
Metal Recovery
4. On the Prepare infrastructure blade of the Azure Recovery Services vault, make sure that the
Already using System Center Data Protection Manager or any other System Center product
check box is cleared.
5. Use the Download link on the Prepare infrastructure blade to download the Microsoft Azure
Backup Server installation media, which are over 3 GB in size.
6. Download the vault credentials from the Prepare infrastructure blade. The Microsoft Azure Backup
Server setup uses vault credentials to register with the vault during the installation process.
7. Once the download of the Microsoft Azure Backup Server installation media completes, extract the
download package content by running MicrosoftAzureBackupInstaller.exe, and then start the
setup process.
Note: Azure Backup Server requires a local instance of SQL Server. You have the option of
using the SQL Server installation media in the package or deploying an instance prior to running
the setup.
8. When prompted, provide the path to the vault credentials that you downloaded earlier. When
registering the Microsoft Azure Backup Server with the vault, you must provide a passphrase for
encrypting backups.
9. Because Microsoft Azure Backup Server has the same administrative interface as the System Center
DPM, after the setup completes, the remaining configuration is the same as described above for
System Center DPM, with the exception of tape backup–related settings.
Demonstration: Implementing Azure IaaS virtual machine backups

In this demonstration, you will see how to implement Azure IaaS virtual machine backups:
• Create a Recovery Services vault.
• Create a custom backup policy.
• Register an Azure VM in the Azure Recovery Services vault.


Question
You need to perform an application-level backup and restore of an Azure VM running Windows.
What solution can you use?
Install the Recovery Services Agent on the virtual machine.
Install the Recovery Services Agent on a Microsoft System Center 2016 Data Protection Manager
(Data Protection Manager) server. Install the DPM agent on the Azure VM.
Install Azure Backup Server. Install the DPM agent on the Azure VM.
Install the Azure VMSnapshot extension on the Azure VM.
Use the built-in Windows Backup feature.

Lesson 5
Planning and implementing Azure Site Recovery
By using Azure Backup, you can protect your servers, clients, and applications, and you can considerably
simplify maintaining backups and performing restores. However, restores typically are time-consuming
and, depending on their frequency, backups might not sufficiently minimize data loss. You should
consider two factors when planning your recovery strategy. The first is the recovery time objective (RTO),
which specifies the acceptable amount of time it takes to restore the original functionality of your systems.
The second is the recovery point objective (RPO), which dictates the acceptable amount of data loss. If
you cannot deliver your RTO and RPO by relying on Azure Backup alone, you should consider
implementing Azure Site Recovery.
In this lesson, you will learn about different types of environments that you can protect by using Azure
Site Recovery. You will also learn about the process of planning an Azure Site Recovery deployment, in
addition to reviewing the steps of a sample deployment.
Lesson Objectives
• Describe different scenarios that Azure Site Recovery supports.
• Identify the factors to consider when planning for Azure Site Recovery.
• Describe how to implement Azure Site Recovery.
Overview of Azure Site Recovery

Azure Site Recovery is a disaster recovery and
business continuity service that provides two types
of functionality: replication and orchestration.
Replication handles synchronization of designated
systems between a primary site that hosts your
production workloads and a secondary site that
activates if a disaster occurs. Orchestration
provides orderly failover and failback between
these two locations.
From an architectural standpoint, Azure Site

Recovery provides support for the following three
disaster recovery scenarios, depending on the
location of the primary and secondary site:
• Failover and failback between two on-premises sites
• Failover and failback between an on-premises site and an Azure region
• Failover and failback between two Azure regions
Note: At the time of authoring this course, failback functionality between two Azure regions
is in preview.
In addition, you can use Site Recovery to migrate virtual machines to an Azure region by performing
failover only. This capability is available for Linux and Windows operating system instances running in on-
premises locations, in Azure, or in the Amazon Web Services environment.
Site Recovery allows you to protect both physical and virtual machines, including support for Hyper-V and
VMware virtualization platforms. How you implement this protection depends on several factors,
including the:
• Location of the recovery site (on-premises or Azure).
• Type of computer to protect (physical or virtual).
• Virtualization platform (Microsoft Hyper-V or VMware vSphere).
• Virtualization management software (Microsoft System Center Virtual Machine Manager [VMM] or
VMware vCenter).
• Replication mechanism (Azure Site Recovery Agent, Hyper-V replica, or the combination of Mobility
service and process server specific to VMware VMs and physical servers).
Note: This summary and the information that follows do not apply to scenarios specific to
the classic deployment model, which, supports storage area network (SAN)–based replication
between two on-premises locations.
Additional Reading: At the time of authoring this course, replication of VMware VMs or
physical servers from one on-premises site to another requires the use of the Azure classic portal.
In Microsoft documentation, you will see references to InMage Scout, which uses Mobility service
as its agent. For more information, refer to: “Replicate on-premises VMware virtual machines or
physical servers to a secondary site in the classic Azure portal” at: https://aka.ms/jz9n1k
Taking into account these factors, the different types of Site Recovery deployments includes the following:
• Disaster recovery of Hyper-V virtual machines managed by VMM from one on-premises location to
another with Hyper-V–based replication.
• Disaster recovery of Hyper-V virtual machines managed by VMM from an on-premises location to
Azure with Site Recovery–based replication.
• Disaster recovery of Hyper-V virtual machines not managed by VMM from an on-premises location to
Azure with Site Recovery–based replication.
• Disaster recovery of VMware virtual machines from one on-premises location to another with
Mobility service–based replication.
• Disaster recovery of VMware virtual machines from an on-premises location to Azure with Mobility
service–based replication.
• Disaster recovery of physical servers running Windows and Linux operating systems from an on-
premises location to Azure with Mobility service–based replication.
• Disaster recovery of physical servers running Windows and Linux operating systems from one on-
premises location to another with Mobility service–based replication.
• Disaster recovery of virtual machines from one Azure region to another with Site Recovery–based
replication.
• Migration of virtual machines from a non-Microsoft cloud-hosting provider to Azure with Mobility
service–based replication.
Replication of Hyper-V virtual machines across two on-premises sites leverages Hyper-V Replica, a
component of the Hyper-V role of the Windows Server operating system. When replicating Hyper-V
virtual machines in cross-premises scenarios, Site Recovery utilizes the Azure Recovery Services Agent. The
agent is a Site Recovery component that you must install on Hyper-V servers that are hosting protected
virtual machines. For replication of physical servers and VMware virtual machines, Site Recovery relies on a
combination of the Mobility service–a Site Recovery component that you must install directly on
computers that you want to protect– and one or more process servers. Process servers function as
replication gateways between one or more instances of Mobility service and storage in the secondary site.
Process servers implement performance optimization and security tasks, such as compression, caching,
and encryption.
Note: The process server is part of VMware-specific Azure Site Recovery infrastructure, which
also includes a configuration server and a master target server. The configuration server
coordinates communication between the on-premises environment and Azure in a production
environment. The master target server is responsible for coordinating communication and
replication during failback.
Site Recovery provides a number of capabilities that help you reach your business continuity goals. These
capabilities include:
• Storage replication. Storage replication maintains the synchronization of disks between your
production and disaster recovery computers. Hyper-V Replica and the Azure Site Recovery Services
agent offer replication frequency in 30-second, 15-minute, or 30-minute intervals. They also allow
you to generate application-consistent snapshots for single-tier apps or multiple-tier apps. With the
Mobility service, replication is continuous.
• Orchestration of planned failover and failback. With planned failover and failback, orchestration
delivers an orderly transition process between your production and disaster recovery environments
without any data loss.
• Orchestration of unplanned failover and failback. In this case, orchestration also allows you to enforce
the sequence of individual steps during failover and failback. However, with unplanned failover and
failback, there is a potential for data loss.
• Orchestration of test failover. Test failover typically takes place in an isolated network, making it
possible to evaluate your disaster recovery approach without affecting the production environment.
Recovery plan
To implement orchestrated failover and failback, you need to create a recovery plan. A recovery plan
identifies protected physical machines and virtual machines, and dictates the order in which Site Recovery
performs individual steps during failover and failback. Recovery plans support Azure Automation scripts
and workflows in addition to manual steps. This provides a sufficient level of flexibility for more complex
disaster recovery scenarios and also helps you achieve your RTO.
Planning for Azure Site Recovery

Planning for Azure Site Recovery is highly
dependent on the location of the disaster
recovery environment that you want to
implement and on the type of systems that you
intend to protect. In particular, you will need to
consider different sets of criteria in each of the
following scenarios:
• Replicating Hyper-V VMs to Azure with

Virtual Machine Manager. On-premises
components to consider include the Virtual
Machine Manager server, Hyper-V servers,
and Hyper-V-hosted VMs. Azure components
to consider include the Azure Site Recovery vault, Azure virtual networks, and Azure Storage.
• Replicating Hyper-V VMs to Azure without Virtual Machine Manager. On-premises components to
consider include Hyper-V servers and Hyper-V-hosted VMs. Azure components to consider include
the Azure Site Recovery vault, Azure virtual networks, and Azure Storage.
• Replicating VMware virtual machines and physical servers to Azure. On-premises components to
consider include one or more process servers, a configuration server, a VMware vCenter Server, ESX
servers, and VMware-managed virtual machines with Mobility service. Azure components that you
must consider include the configuration server, the master target server, the Azure Site Recovery
vault, Azure virtual networks, and Azure Storage.
• Replicating Hyper-V virtual machines to a secondary datacenter. On-premises components to
consider include the Virtual Machine Manager server, Hyper-V servers, and Hyper-V–hosted VMs. The
only Azure component to consider in this case is the Azure Site Recovery vault.
Note: To implement Azure Site Recovery to protect Hyper-V virtual machines by using an
on-premises secondary site, your Hyper-V hosts must be part of a Virtual Machine Manager
environment.
• Replicating between on-premises physical servers or VMware virtual machines in primary and
secondary datacenters. On-premises components in the primary datacenter to consider include one
or more process servers, a configuration server, a VMware vCenter Server, ESX servers, and VMware-
managed virtual machines with Mobility service. On-premises components in the secondary
datacenter to consider include the configuration server, and the master target server. The only Azure
component to consider in this case is the Azure Site Recovery vault.
• Replicating Azure VMs between two Azure regions. In this case, there are no on-premises
components to consider. Azure components to consider include the Azure Site Recovery vault, Azure
virtual networks, and Azure Storage.
Additional Reading: For more information about various Azure Site Recovery architectural
designs, refer to: “How does Azure Site Recovery work?” at: http://aka.ms/Fmx868
The choice of architecture will dictate additional network considerations. In general, you need to keep in
mind that users of your applications and services must be able to connect and authenticate to them
following a planned failover. Similarly, you typically need to facilitate client connectivity (for the testing
purposes) and core infrastructure support following a test failover. This necessitates the availability of
Active Directory Domain Services and DNS to provide authentication and name resolution in both
planned and test failover scenarios.
Additional Reading: For more information, refer to: “Designing your network for disaster
recovery” at: http://aka.ms/Idi9ib
Capacity planning
Capacity planning is often challenging, especially with Azure as the recovery site. To simplify the planning
process, Microsoft offers the Azure Site Recovery Capacity Planner, which is available at: http://aka.ms/asr-
capacity-planner-excel. This Microsoft Excel–based tool evaluates the existing workloads that you intend
to protect, and based on this analysis, it provides recommendations regarding compute, storage, and
network resources that are required to implement their protection.
The tool operates in two modes:

• Quick Planner. This mode requires you to provide general statistics representing the current capacity
and utilization of your production site. These statistics could include the total number of virtual
machines, average number of disks per virtual machine, average size of a virtual machine disk,
average disk utilization, total amount of data that needs replication, and average daily data change
rate.
• Detailed Planner. This mode requires you to provide capacity and utilization data for each virtual
machine that you intend to protect. This data could include the number of processors, memory
allocation, number of network adapters, number of disks, total storage, disk utilization, and the
operating system that is running in the virtual machine.
Note: You are responsible for collecting relevant data; the tool simply handles the relevant
calculations afterward. To determine the amount of changes, use the Capacity Planner for
Hyper-V Replica tool, which is available at: http://aka.ms/Emd537, assuming that Hyper-V hosts
your workloads. If you operate in a VMware environment, use the vSphere Replication Capacity
Planning Appliance, which is available at: http://aka.ms/O5c871.
Additional Reading: For more information, refer to: “Plan capacity for virtual machine and
physical server protection in Azure Site Recovery” at: http://aka.ms/Ht4m7g
Supported workloads
Azure Site Recovery can integrate with a number of Windows server applications, such as Exchange
Server, database availability groups, SharePoint, SQL Server (including AlwaysOn Availability Groups),
Microsoft Dynamics CRM, in addition to third-party server software from vendors such as Oracle, SAP,
IBM, and Red Hat. This integration considerably simplifies building recovery plans, which protect the
systems that host these products. Similarly, you can configure servers that host core infrastructure
components, such as AD DS or DNS, to replicate from a primary site to a secondary site, either on-
premises or in Azure.
Additional Reading: For more information, refer to: “What workloads can you protect with
Azure Site Recovery?” at: http://aka.ms/Ut2weu
Azure VM requirements
When hosting your production systems in a Hyper-V environment, you might want to keep in mind
differences between on-premises Hyper-V and virtualization platform characteristics in Azure. Fortunately,
because of continuous enhancements to Azure Site Recovery, these differences have less impact than in
the past. For example, Azure Site Recovery automatically converts Windows-based Generation 2 on-
premises Hyper-V virtual machines to Generation 1 when replicating them to Azure storage. Similarly, it
automatically converts .vhdx files to the .vhd format.
Note: At the time of authoring this content, Site Recovery does not support Generation 2
virtual machines that are running Linux.
Additional Reading: For more information about additional Azure Site Recovery
requirements, refer to: “Prepare for Azure Site Recovery deployment” at: http://aka.ms/Jobhgk
Implementing Azure Site Recovery

Implementing Azure Site Recovery is a relatively
involved process. The implementation steps
obviously depend on the design, which in turn is
determined by the recovery scenario that you
chose as most suitable for your organization’s
business continuity needs.
For example, consider the traditional Azure Site
Recovery deployment with the primary site
running in an on-premises Virtual Machine
Manager environment and a secondary site
hosted in Azure. In such a case, your
implementation would consist of the following
tasks:
1. Creating one or more Azure virtual networks in your Azure subscription in the Azure region that
meets your disaster recovery objectives.
2. Creating an Azure storage account in the same subscription and the same region as the Azure virtual
network.
3. Creating a Recovery Services vault in the same subscription and the same region as the storage
account and the virtual network.
4. Preparing for the mapping of on-premises networks to the Azure virtual networks. You need to make
sure that all virtual machines that you intend to protect are connected to the virtual networks that
you will be mapping to the Azure virtual networks.
5. Specifying the protection goal of your implementation. When using the Azure portal, this is the first
task in Step 1: Prepare Infrastructure of the GETTING STARTED Wizard. It involves answering the
following four questions:
o Where do you want to replicate your machines? Select To Azure.
o Are your machines virtualized? Select Yes, with Hyper-V.
o Are you using System Center VMM to manage your Hyper-V hosts? Select Yes.
o Are you managing the recovery site with another System Center VMM? Select No.
6. Setting up the source environment. This consists of the following steps:
o Adding a System Center VMM server entry representing your on-premises VMM environment
and selecting the VMM cloud that is hosting the virtual machines that you intend to protect.
o Downloading the Azure Site Recovery Provider setup file and Recovery Services vault registration
key to the VMM server.
o Running the installation by using the newly downloaded setup file and providing the vault
registration key. As part of this step, you will receive a prompt to accept or modify a Secure
Sockets Layer (SSL) certificate for encryption of disks uploaded to the Recovery Services vault. In
addition, you will need to designate the VMM clouds that contain VMs that you want to protect.
o Downloading the setup file for the Azure Recovery Services agent.
o Installing the agent on each Hyper-V host in the VMM cloud that is associated with the virtual
machine network you will be mapping to the Azure virtual network.
7. Setting up the target environment. As part of this step, you must specify the post-failover deployment
model. You will have a chance to verify that you can use the virtual network and the storage account
you created earlier to host replicas of protected virtual machines and their disks. You have the option
to create the virtual network and the storage account if this is not the case. Finally, you must also
configure network mapping between the on-premises networks and the Azure virtual network.
8. Setting up replication settings. This step involves configuring a replication policy and associating it
with the VMM cloud you selected in step 6a. The policy includes settings such as copy frequency,
recovery point retention, app-consistent snapshot frequency, and initial replication start time.
9. Confirming that you have run the Capacity Planner. The wizard will include a drop-down list from
which you need to select Yes, I have done it to successfully complete the Preparing infrastructure
step.
10. Selecting the VMM cloud and enabling its replication. This is part of Step 2: Replicate Applications
in the GETTING STARTED Wizard. As part of this step, you will need to perform the following tasks:
o Specify the VMM cloud that you selected in step 6a.

o Select the target Azure virtual network and its subnet.
o Select the storage account that you want to use to host replicas of protected virtual machine
disks.
o Assign the names to the target virtual machines and choose their operating system.
o Choose a replication policy.
Additional Reading: : For full details about each of these steps, refer to: “Replicate Hyper-V
virtual machines in VMM clouds to Azure using the Azure portal” at: http://aka.ms/S5ozj3.
Microsoft online documentation also provides detailed guidance regarding other implementation
scenarios at: https://aka.ms/tdcmp6.
After you configure protection of virtual machines, you should create a recovery plan, which allows you to
control the order of failover of virtual machines. To accomplish this, you divide protected virtual machines
into groups and assign a number to each group. Virtual machines in the same group fail over in parallel
while those in different groups fail over according to their group number. The sequence should account
for virtual machine dependencies.
You can use recovery plans to specify the scope of planned, unplanned, and test failovers. Additionally,
you can further extend and automate recovery plans by incorporating Azure Automation runbooks.
Additional Reading: For more information, refer to: “Create recovery plans” at:
http://aka.ms/Oegdsj

Question
Which components do you have to implement to facilitate Azure Site Recovery between a Virtual
Machine Manager environment on-premises and Azure?
An Azure Site Recovery vault
An Azure storage account
An Azure virtual network
A Configuration server
A Master target server

Lab: Planning and implementing Azure Storage

Scenario
The IT department at A. Datum Corporation uses an asset management application to track IT assets such
as computer hardware and peripherals. The application stores images of asset types and invoices for
purchases of specific assets. As part of A. Datum’s evaluation of Azure, you need to test Azure storage
features as part of your plan to migrate the storage of these images and invoice documents to Azure.
A. Datum also wants to evaluate Azure File storage for providing SMB 3.0 shared access to installation
media for the asset management application client software. Currently, corporate file servers host the
media. Additionally, A. Datum wants to evaluate the ability of Azure Backup to protect the content of on-
premises computers and Azure IaaS virtual machines.
Objectives
• Create and configure Azure Storage.

• Use Azure file storage.
• Protect data with Azure Backup.
Lab Setup
User name: Student
Password: Pa55w.rd
Before starting this lab, ensure that you have performed the “Preparing the environment” demonstration
tasks at the beginning of the first lesson in this module and that the setup script has completed.
Question: The asset management application stores images of hardware components as blobs
and invoices as files. If the application also needed to search the location of each asset by using
an asset type, a unique asset number, and a text description of the location, what storage options
should you consider?

In this module, you have learned how to use Azure Storage, Azure Backup and Azure Site Recovery.
Review Question
Question: Why should you co-locate storage accounts and the Azure services that use them?
Best Practices
When using Azure Storage, consider the following best practices:
• Choose the most appropriate storage type based on your application requirements and the format of
the data to store.
• Co-locate storage accounts and the services that use them in the same region.
7-1
Module 7
Implementing containers in Azure
Contents:
Module Overview 7-1
Lesson 1: Implementing Windows and Linux containers in Azure 7-2
Lab A: Implementing containers on Azure VMs 7-14

Lesson 2: Implementing ACS 7-15
Lab B: Implementing Azure Container Service 7-28
Module Overview
Hardware virtualization has drastically changed the IT landscape in recent years. The emergence of cloud
computing is one consequence of this trend. However, a new virtualization approach promises to bring
even more significant changes to the way you develop, deploy, and manage compute workloads. This
approach is based on the concept of containers.
In this module, you will learn about containers and how you can implement them in Microsoft Azure. You
will also learn about deploying and managing clusters of containers by using Azure Container Service
(ACS) along with open-source and non-Microsoft container orchestration solutions. These solutions
include Docker Swarm, Kubernetes, and Datacenter Operating System (DC/OS).
Objectives
• Implement Windows and Linux containers in Azure.

• Implement ACS.
7-2 Implementing containers in Azure
Lesson 1
Implementing Windows and Linux containers in Azure
Azure provides a hosting platform for implementing Linux and Windows containers. This platform
provides the scalability, resiliency, and agility of the underlying infrastructure. At the same time, you can
use the same container management techniques that you use in your on-premises environment. In this
lesson, you will learn about the basic concepts related to containerization and its most prominent format,
which Docker offers. You will also learn how to deploy single and multicontainer workloads to Microsoft
Azure virtual machines (VMs) and implement an Azure-based registry of Docker images.
Lesson Objectives
• Explain the concept of containers.
• Explain the basic characteristics of Docker.

• Implement Docker hosts in Azure.
• Implement Docker containers in Azure.
• Create and deploy multicontainer workloads in Azure.
• Implement Azure Container Registry.

module
the lab.
Introduction to containers
To a large extent, the development of hardware
virtualization eliminated the constraints of
physical hardware. It made it possible to run
multiple isolated instances of operating systems
concurrently on the same physical hardware.
Containers are the next stage in the virtualization
of computing resources. Container-based
virtualization allows you to virtualize the
operating system. This way, you can run multiple
applications within the same instance of the
operating system, while maintaining isolation
between them. This means that containers within
a VM provide functionality similar to that of VMs within a physical server. To better understand this
analogy, it is helpful to compare the VMs and containers.
The following table lists the high-level differences between VMs and containers.
Feature VMs Containers
Isolation Built into the hypervisor Relies on the operating-system support

mechanism
Required amount Includes the operating system and Includes containerized apps’ requirements
of memory app requirements only
Startup time Includes the time it takes to start Includes only the time it takes to start the
the operating system, services, apps and app dependencies, as the operating
apps, and app dependencies system is already running
Portability Portable, but the image is larger More portable, because the image includes
because it includes the operating only apps and their dependencies
system
Image Depends on the operating system Based on a registry

automation and apps
Additional Reading: For more information about containers, refer to: “Virtual machines and
containers in Azure” at: https://aka.ms/jzuvd2
When compared with physical and virtual machines, containers offer a number of advantages, including:
• Increased flexibility and speed when developing and sharing the application code.
• Simplified application testing.
• Streamlined and accelerated application deployment.
• Higher workload density, resulting in improved resource utilization.

Support for containers relies on two capabilities that are part of the operating system kernel:
• Namespace isolation. Each container operates in its own isolated namespace, which provides the
resources necessary to run containerized applications, including files or network ports, for example.
These resources map to the resources of the host operating system. When an application makes a
change to a file that is part of its namespace, the container performs a copy-on-write operation.
From that point on, the container keeps track of the differences between its version of the modified
file and the underlying file system resource.
• Resource governance. The host operating system controls the amount of resources, such as central
processing unit (CPU), random access memory (RAM), or network, that each of its containers can use.
This prevents any container from affecting the performance and stability of other containers.
Linux supports containers by relying on its cgroups functionality. Windows Server 2016 provides two
methods for hosting containers, each offering different degrees of isolation with different requirements:
• Windows Server containers. These containers provide app isolation through process and namespace
isolation technology. Windows Server containers share the operating system kernel with the container
host and with all other containers that run on the host. Although this provides a faster startup
experience, it does not provide complete isolation of the containers.
• Microsoft Hyper-V containers. These containers expand on the isolation that Windows Server
containers provide by running each container in a highly optimized VM. However, in this
configuration, the Hyper-V containers do not share the operating system kernel of the container host.
Note: With the introduction of Ev3 and Dv3 Azure VM series, which include support for
nested virtualization, you can implement Hyper-V containers in Azure.
Introduction to Docker
At the time of authoring this course, the most
popular containerization technology is available
from Docker. Docker is a collection of open-
source tools, solutions, and cloud-based services
that provide a common model for packaging, or
containerizing, app code into a standardized unit
for software development. This standardized unit,
also called a Docker container, is software
wrapped in a complete file system that includes
everything it needs to run: code, runtime, system
tools, and system libraries, or anything you can
install on a server.
Supporting the Docker container is the core of the Docker platform, called the Docker Engine. This in-host
daemon is a lightweight runtime environment that communicates with the Docker client to run
commands to build, ship, and run Docker containers. This guarantees that the app always runs the same
way, regardless of the environment from which it is running.
Docker containers and VMs have similar resource isolation and allocation benefits, but Docker containers
use a different architectural approach that improves portability and efficiency. These containers include
the app and all of its dependencies, but share the kernel with other containers. Each Docker container
runs as an isolated process in the user space on the host operating system.
Docker containers are based on open standards that allow them to run on all major Linux distributions
and Windows Server 2016. Because they are not tied to any specific infrastructure, Docker containers can
run on any computer, on any infrastructure, and in any cloud.
To ensure that the packaging format remains universal, Docker recently organized the Open Container
Initiative, aiming to ensure that container packaging remains an open industry standard, with Microsoft as
one of the founding members. Microsoft is collaborating with Docker to enable developers to create,
manage, and deploy both Windows Server and Linux containers by using the same Docker tool set.
Developers who target Windows Server will no longer have to choose between using the vast range of
Windows Server technologies and building containerized apps.
To understand how Docker works, you should be familiar with some basic Docker terminology, including
the following definitions:
• Image. A read-only collection of files and execution parameters representing a containerized

workload.
• Container. A runtime instance of an image, consisting of the image, its execution environment, and a
standard set of instructions.
• Dockerfile. A text file that contains the commands that need to run to build a Docker image.
• Build. The process of building Docker images from a Dockerfile and any other files in the directory
where the image is being built.
Docker toolbox
The Docker toolbox is a collection of Docker platform tools that developers can use to build, test, deploy,
and run Docker containers. These tools include:
• Docker client. This command shell–based management software allows you to create, start, and
administer containers.
• Docker Engine. This is a lightweight runtime environment for building and running Docker containers.
The Docker Engine includes an in-host service that you communicate with by using the Docker client
when building, deploying, and running containers. It takes the form of a daemon on a Linux
operating system and a service on a Windows Server operating system.
• Docker Compose. This tool enables you to build and run Docker apps that contain multiple
containers.
• Docker Machine. This enables you to provision Docker hosts by installing the Docker Engine on a
target computer in your datacenter or at a cloud provider. Docker Machine also installs and
configures the Docker client so that it can communicate with the Docker Engine.
• Docker Registry. This is a repository of container images accessible via the Docker application
programming interface (API). Docker offers a public repository, known as Docker Hub, but you can
create your own private repository, referred to as Docker Trusted Registry.
• Kitematic. This graphical user interface can help you to quickly build and run Docker containers and
to find and pull images from the Docker Hub.
• Docker Swarm. This is a Docker native clustering technology that allows you to run and manage
multiple Docker Engines as a single entity.
You can download and install Docker tools on various platforms, including Windows, Linux, and Mac
OS X. After you install the Docker software, you can build images and tags and push or pull them to the
Docker Hub.
Note: When you use Docker containers on Windows Server 2016, you must consider the
following points:
• Restrictions on cross-platform containerization. Windows Subsystem for Linux in Windows Server

2016 makes it possible to run Linux containers on a Windows Server Hyper-V container host, with the
Linux kernel of your choice. However, at the time of authoring this content, there is no support for
running Windows containers on Linux.
• Two ways to manage containers in the Windows Server operating system. You can create and
manage Windows containers by using the Docker tools or the Windows PowerShell module for the
Docker Engine.
Additional Reading: For more information about the Windows PowerShell module for
Docker, refer to: “Microsoft/Docker-PowerShell” at: https://aka.ms/hrk0t9
Implementing Docker hosts in Azure

Azure offers several ways to provision Azure VMs
that automatically include support for Docker
containers:
• Install the Docker VM extension. You can add
the extension to an existing Azure VM
running a Docker-supported distribution of
Linux, or include it when deploying a new
Azure VM via an Azure Resource Manager
template or a command-line script. The
extension installs the Docker Engine, the
Docker client, and Docker Compose. An Azure
VM requires the Docker Engine to function as
a Docker host.
Additional Reading: For details about installing the Docker VM extension, refer to: “Create
a Docker environment in Azure using the Docker VM extension” at: https://aka.ms/ead7wx
• Deploy a Docker Azure VM based on images available from Azure Marketplace. At the time of
authoring this course, Windows Server 2016 Datacenter with Containers and Docker on Ubuntu
Server images are available on Azure Marketplace. On Azure VMs based on Windows Server 2016
Datacenter with Containers, the deployment process automatically adds the Containers feature. Both
images also contain all core Docker components.
• Use the Docker Machine Azure driver to deploy an Azure VM with support for Docker containers.
Docker Machine is a command-line tool that allows you to perform Docker-related administrative
tasks, including provisioning new Docker hosts. This tool includes support for deploying Docker hosts
on Azure VMs. To perform such deployment, you need to include the –driver azure parameter when
running the docker-machine create command. For example, the following command deploys a new
Azure VM named dockervm1 in the Azure subscription that you specify, creates an administrative
user account named dockeruser, and allows connectivity on TCP port 80. With the default settings,
the VM has the Standard_A2 size, uses Canonical Ubuntu Server 16.04.0-LTS image, and resides on an
Azure virtual network Docker Machine in a Docker Machine resource group in the West US region. A
default network security group associated with the network interface of the VM allows inbound
connectivity on TCP port 22, for Secure Shell (SSH) connections, and on TCP port 2376, for remote
connections from the Docker client. The command also generates self-signed certificates that secure
subsequent communication from the computer where you ran Docker Machine and stores the
corresponding private key in your user’s account profile:
docker-machine create -d azure \

--azure-ssh-user dockeruser \
--azure-subscription-id your_Azure_subscription_ID \
--azure-open-port 80 \
dockervm1
Additional Reading: You can modify the default settings described above by including
additional command-line parameters and assigning custom values to them. For example, to
deploy a different image, use the --azure-image parameter. For the full syntax of the docker-
machine create –d azure command, refer to: “Microsoft Azure” at: https://aka.ms/mrs5mc
Additional Reading: Docker Machine is available on Windows, Linux, and Mac OS X

operating systems. For installation instructions and links to download locations, refer to: “Install
Docker Machine” at: https://aka.ms/rwfvoc
• Use the NuGet provider Windows PowerShell module to install Docker Engine and Docker tools on a
Windows Server Azure VM by completing the following tasks from a Windows PowerShell console:
1. Install the Docker module from PSGallery:
Install-Module –Name DockerMsftProvider –Repository PSGallery -Force
2. Install the latest version of the Docker installer package:
Install-Package –Name docker –ProviderName DockerMsftProvider -Force
3. Restart the computer by running the following command:
Restart-Computer -Force
• Deploy an ACS cluster. This allows you to provision and manage multiple instances of Docker
containers residing on clustered Docker hosts. The second lesson of this module covers this approach
in detail.
Deploying containers on Azure VMs

The most common method of deploying
individual containers to Azure VMs relies on the
Docker client. You can connect to a Docker host
operating system within an Azure VM to run the
Docker client in the following ways:
• A Docker Machine session

• A Remote Desktop Protocol (RDP) session
• An SSH session
For information about connecting to Azure VMs

via RDP and SSH, refer to Module 4, “Managing
Azure VMs.” In this topic, you will learn about the
process of running containers by using the Windows-based Docker Machine. Keep in mind that Docker
Machine is also available for the Linux and Mac OS operating systems.
During the Azure VM–provisioning process, Docker Machine generates a self-signed certificate that you
can use to establish a secure SSH session to the Docker host. It also stores the private key of the certificate
in the profile of your user account. This allows you to deploy and manage Docker containers from the
same computer on which you initiated the Docker host deployment. To simplify this management, you
should configure environment variables within your Windows command-prompt session. To identify these
environment variables, run the following at the command prompt:
docker-machine env dockervm1
dockervm1 is the name of the Azure VM that you deployed by running the docker-machine create
command. The above command should return output similar to the following:
SET DOCKER_TLS_VERIFY=”1”
SET DOCKER_HOST=”tcp://191.237.46.90:2376”
SET DOCKER_CERT_PATH=”C:\Users\Admin\.docker\dockervm1\certs”
SET DOCKER_MACHINE_NAME=”dockervm1”
@FOR /f "tokens=*" %i IN ('docker-machine env dockervm1) DO @%i
At this point, you can start a container on the Azure VM by running the following command:
docker run -d -p 80:80 --restart=always container_name
This command automatically locates the container with the name container_name, publishes it on port 80,
initiates its execution in the detached mode, and ensures that the container always restarts after it
terminates, regardless of the exit status. With the detached mode, the command-prompt session is not
attached to the container process, so you can use it to run other commands. In the attached mode, the
command-prompt session displays any messages that the Docker container generates.
Additional Reading: For the full syntax of the docker run command, refer to: “docker run”
at: https://aka.ms/rnaxx2
Additional Reading: For more details regarding running containers on Azure VMs by using
Docker Machine, refer to: “How to use Docker Machine to create hosts in Azure“ at:
https://aka.ms/e373fj
The docker run command first attempts to locate the latest version of the container locally on the Docker
host. If it finds one, it checks its version against the Docker Hub at https://aka.ms/llyb6d. This is a central,
Docker-managed repository of Docker images available publicly via the internet. If there is no locally
cached container image or its version is out of date, the Docker Engine automatically downloads the latest
version from the Docker Hub.
When you run docker run, you must specify an image from which to derive the container. The creator of
the image might have applied a number of default settings, including:
• Detached or attached mode
• Network settings
• Runtime constraints on CPU and memory

With docker run, you can add to or override the image defaults that were configured during image
creation. Additionally, you can override nearly all the defaults of the Docker runtime.
The Docker client includes other command-line options, including:
• docker images. This lists the images available on the local Docker host.
• docker stop. This stops a running container.
• docker rm. This removes an existing container.

The Docker client also includes tools for automating the creation of container images. Although you can
create container images manually, using an automated image-creation process provides many benefits,
including:
• The ability to store container images as code.
• The rapid and precise re-creation of container images for maintenance and upgrade purposes.
• Continuous integration between container images and the development cycle.
Three Docker components drive this automation:
• Dockerfile. This text file contains the instructions needed to create a new container image from a
base image. These instructions include the identifier of the base image, commands to run during the
image creation process, and a command that will run when new instances of the container image
deploy.
Additional Reading: For information about the Dockerfile syntax, refer to: “Dockerfile
reference” at: http://aka.ms/wrccuy
• docker build. This Docker Engine command uses a Dockerfile and then triggers the image creation
process.
Additional Reading: For more information on docker build, including a list of all the build
options, refer to: “docker build” at: http://aka.ms/u29exr
• docker commit. This command commits the changes that you made to the container and creates a
new container image.
Azure Container Instances

Another method of implementing containers in Azure relies on the Azure Container Instances service. This
service allows you to deploy individual containers without having to explicitly provision Azure VMs that
will serve as their Docker hosts. Azure Container Instances serves as an abstraction layer that automatically
manages virtual machine provisioning. To deploy a container, you must specify its name, its resource
group, the Azure region where it should reside, its Docker image and the corresponding operating system
type, and its resources, such as the number of CPU cores, amount of memory, and a public IP address, if
the container needs to be accessible from the internet. You can accomplish this either by using an Azure
Resource Manager template or by running the az container create Azure Command-Line Interface (CLI)
2.0 command.
Additional Reading: At the time of authoring this content, Azure Container Instances is in
preview. For more information about its functionality, refer to: “Azure Container Instances
Documentation” at: https://aka.ms/qjr9w8
Demonstration: Installing a Docker host and containers on an Azure VM

In this demonstration, you will learn how to install a Docker host and containers on an Azure VM.
Creating multicontainer applications with Docker Compose

The Docker Compose tool allows you to define
and implement multicontainer applications. To
define an application consisting of multiple
containers, you use a Compose file, which
identifies all the containers, their parameters, and
their interdependencies. To implement the
application, you run the docker-compose up
command.
Note: When using Docker Compose to

develop multicontainer applications, it is common
to include Dockerfile in the development process.
This allows you to control the build and assembly of images via a Compose file.
Before you attempt to create a multicontainer application by using Docker Compose, verify its installation
by running the following command from a Windows command prompt or a Linux SSH session:
docker-compose --version
By default, Docker Compose is present on Azure VMs that you deploy from Azure Marketplace Docker
images or by using Docker Machine. If it is not present, you can follow the installation instructions
available on the Installing Compose page on GitHub at https://aka.ms/mjbwks.
Next, you need to create a docker-compose.yml file. The file format follows YAML (a recursive acronym
that stands for YAML Ain’t Markup Language) specifications. YAML is a data serialization language that is
a superset of the JavaScript Object Notation (JSON) file format. A docker-compose.yml file is a text file,
so you can create and modify it by using any text editor, such as Notepad on a Windows Server or Vi on
Linux Server.
For example, the following file defines an application that consists of two containers. The first one hosts a
WordPress instance serving as a front end and the second one hosts a MariaDB SQL database serving as a
back end:
wordpress:
image: wordpress
links:
- db:mysql
ports:
- 80:80
db:
image: mariadb
environment:
MYSQL_ROOT_PASSWORD: <root password>
The links entry represents a dependency between the two containers. The docker-compose.yml file also
includes references to container images and deployment parameters, such as network ports via which the
front end will be available or secrets necessary to protect access to the back-end database.
To start the application in the detached mode, you run the following command:
docker-compose up -d
This will start both containers in the proper sequence. After the WordPress container is running, you will
be able to connect to it via TCP port 80 of the Azure VM, assuming that the port is not blocked by the
operating system firewall or an Azure network security group.
Additional Reading: For details about the Docker Compose syntax, refer to: “Compose file
version 3 reference” at: https://aka.ms/k44zyt
Additional Reading: For more information about Docker Compose, refer to: “Get started
with Docker and Compose to define and run a multi-container application in Azure” at:
https://aka.ms/dhn0yb
Implementing Azure Container Registry

You can implement your own private registry of
containers by using the Container Registry service.
This allows you create and maintain your own
collection of Docker container images, while
benefiting from the availability, performance, and
resiliency of the Azure platform.
You can create a container registry directly from

the Azure portal, by using Azure CLI, or via an
Azure Resource Manager template–based
deployment. You will need to assign a unique
name in the azurecr.io Domain Name System
(DNS) namespace, and specify an Azure subscription, an Azure region, and either an existing or a new
resource group where the registry will reside. You also will have to choose between the classic and
managed registry stock keeping units (SKUs). This decision will depend on whether you need support
capabilities, such as support for Azure Active Directory (Azure AD) authentication or webhook integration,
which sends notifications about Docker events to a custom URI. If you choose the classic SKU, you also
have to either create a new Azure Storage account or provide an existing one. There are three managed
registry SKUs: Basic, Standard, and Premium.
Note: You cannot use Azure CLI 2.0 or Azure Resource Manager templates to provision a
classic container registry.
Note: Basic, Standard, and Premium SKUs are in preview at the time of authoring this
content.
In addition, you must decide which authentication and authorization model you will use. The most basic
approach involves the use of the Admin user account with two passwords. Having two passwords allows
you to regenerate one of them without affecting authentication attempts with the other. By default, the
account is disabled. You can enable it, which allows you to authenticate from the Docker client by
providing the unique registry name and one of the two passwords. The admin user has full permissions to
the registry. You should limit the use of the Admin user account to single-user scenarios. Otherwise,
multiple users will be using the same set of credentials, which is a problem in terms of auditing.
In multiuser scenarios, you should create one or more service principals in the Azure AD instance
associated with your Azure subscription and then assign them to your registry. At that point, you will be
able to authenticate when accessing the registry by using a service principal name and its password. In
addition, with this approach, you can implement Role-Based Access Control (RBAC) and grant the Reader,
Contributor, or Owner role to the service principals that you created.
The following sequence of steps illustrates how to push images to and pull images from a container
registry named adatumregistry by using the Docker client:
• Log in to the registry from your local computer with the Docker client installed by using an Azure AD
service principal and its password:
docker login adatumregistry.azurecr.io –u xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx –p

Pa55w.rd1234
The value of the –u switch represents the ApplicationID property of the service principal and the
value of the –p switch represents the corresponding password.
• Use the docker pull command to download a public image from Docker Hub to the local computer
(image_name represents the name of the image):
docker pull image_name
• Next, use the docker tag command to create an alias of the image that you downloaded in the
previous step. The alias contains a fully qualified path to the registry, with an additional namespace
(optionally):
docker tag nginx adatumregistry.azurecr.io/lab/image_name
• To upload the newly tagged image to the container registry, run the docker push command:
docker push adatumregistry.azurecr.io/lab/image_name

• To download the newly uploaded image, run:
docker pull adatumregistry.azurecr.io/lab/image_name
• To run a container based on this image and make it accessible via port 8080 on the local computer,
use the docker run command in the following manner:
docker run –it --rm –p 8080:80 adatumregistry.azurecr.io/lab/image_name
• To remove the image from the container registry, run the docker rmi command:
docker rmi adatumregistry.azurecr.io/lab/image_name

Question
What is the default image that Docker Machine deploys?
Windows Server 2016
Ubuntu Server
Red Hat Enterprise Linux
SUSE Linux Enterprise Server
CoreOS Linux
Lab A: Implementing containers on Azure VMs

Scenario
A. Datum Corporation plans to implement some of its applications as Docker containers on Azure VMs.
To optimize this implementation, you intend to combine multiple containers by using Docker Compose.
A. Datum would also like to deploy its own private Docker registry in Azure to store containerized images.
Your task is to test the functionality of tools that facilitate deployment of Docker hosts and Docker
containers. You also need to evaluate Azure Container Registry.
Objectives
• Implement Docker hosts on Azure VMs.
• Deploy containers to Azure VMs.

• Deploy multicontainer applications with Docker Compose.
• Implement Azure Container Registry.
Lab Setup

User name: Admin
Password: Pa55w.rd
Question: Which method would you use when deploying Docker hosts on Azure VMs?
Question: What authentication and authorization method do you intend to use when
implementing Azure Container Registry?
Lesson 2
Implementing ACS
Implementing individual containers allows you to optimize your existing Azure VM workloads by
minimizing the resources that they require and enhancing their portability. However, to facilitate
scalability and resiliency, you need to run tens, hundreds, or even thousands of containers across multiple
container hosts. To accomplish this, you need a technology that simplifies the management of container
clusters. ACS provides this functionality by integrating with open-source container orchestrators such as
Docker Swarm, Kubernetes, and Marathon of Mesosphere’s DC/OS. In this lesson, you will learn about
open-source container orchestrators and their implementation in Azure.
Lesson Objectives
• Describe the container-clustering solutions available in Azure.

• Create and manage an ACS Docker Swarm cluster.
• Create and manage an ACS Kubernetes cluster.
• Create and manage an ACS DC/OS cluster.
Overview of container-clustering solutions in Azure

ACS allows you to manage clusters of multiple
Docker hosts running Docker containers. It
provides orchestration and scaling of
containerized apps to tens of thousands of
containers through integration with the following
open-source orchestrators:
• Docker Swarm
• Kubernetes
• Mesosphere DC/OS–based Marathon
Based on this integration, you can interact with

the orchestrators by using their standard
management and programming interfaces. For example, with Docker Swarm, you can continue using the
Docker client. Similarly, ACS-based implementation of DC/OS supports the DC/OS CLI and management
of Kubernetes is available via the kubectl command-line tool. At the same time, you benefit from the ease
of provisioning and optimized configuration that ACS provides. You can provision an ACS cluster directly
from the Azure portal. Alternatively, you can use an Azure Resource Manager template or Azure CLI.
Orchestrators are vital to managing clusters of containers. They provide automated provisioning and
maintenance of infrastructure capabilities necessary for cluster operations. These cluster operations
include load balancing, service discovery, authentication and authorization, resource allocation, and
workload failover.
Choosing an orchestrator can be challenging. It is difficult to compare orchestrators, because their

features and architecture can be quite different. Rather than focusing on these individual features, it is
helpful to understand their design principles and primary objectives.
Docker Swarm
Docker is the leader in containerization. It developed a standardized approach to packaging applications
into containers, running these containers on host computers, and providing management capabilities via
its API. However, its offering did not initially include orchestration of these containers across multiple
hosts. That changed with the introduction of Docker Swarm, a separate product that facilitated creation
and administration of clusters of Docker containers. Subsequently, Docker incorporated this functionality
directly into the Docker Engine, starting with release 1.12, in the form of Swarm mode.
The primary advantage of Swarm mode is its support for the standard Docker API. This ensures a
consistent programming and command-line interface when managing individual containers and their
clusters. This considerably minimizes the learning curve when transitioning to container orchestration.
However, Docker Swarm is not as mature as the other two orchestrators presented here. This makes it
more challenging to implement some of the advanced orchestration features, such as autoscaling. This is
likely to change soon, considering the pace at which Docker enhances its offering.
Note: At the time of authoring this content, the Docker Swarm implementation in ACS uses
the legacy standalone product. To implement the Swarm mode, you can use the open-source
ACS Engine available on GitHub at: https://aka.ms/s4oeec
Note: Docker, along with other container technology vendors, formed the Cloud Native
Computing Foundation (CNCF) and Open Container Initiative (OCI) to promote interoperability
and open standards. One of Docker’s objectives is to ensure that its containers can integrate with
any container orchestration products, regardless of the underlying infrastructure.
Kubernetes
Google released Kubernetes in February 2015 to implement orchestration of Docker containers. It
included a product-specific programming and management interface but allowed for extensibility
through its modular architecture, enabling integration with third-party and open-source code. In March
2016, Google made Kubernetes open source and donated it to CNCF, but continues to contribute to its
development.
Since its introduction, Kubernetes experienced impressive growth in popularity due to a number of
features it supports. It also extends its support to other containerization technologies, such as CoreOS rkt
runtime engine. However, implementing Kubernetes clusters requires a new set of skills, different from
those that you use to manage individual Docker containers.
Note: Kubernetes is available in a wide range of distributions and deployment options,

including fully managed platform as a service (PaaS) offerings.
Mesosphere DC/OS–based Marathon

Mesosphere DC/OS is the most feature rich of the three products presented here. Companies such as
Twitter, Apple, Yelp, Uber, and Netflix have adopted it for its ability to orchestrate tens of thousands of
nodes. However, as its name indicates, Mesosphere DC/OS is a datacenter operating system, which
supports orchestration of not only containers, but other workloads such as microservices, big data,
machine learning, and real-time analytics. One of its primary strengths is the ability to abstract underlying
private or public cloud resources and run different types of workloads on the same infrastructure. It also
allows you to manage each type of workload independently, accounting for their individual requirements.
These capabilities result from a unique two-tier architecture. Its first tier relies on the Apache Mesos
distributed system kernel to oversee an underlying infrastructure and maintain isolation between different
types of workloads running on that infrastructure. The second tier consists of individual frameworks, each
handling a specific workload type. One of these frameworks is Marathon, which is responsible for
managing Docker containers.
Note: Marathon was one of the first products that provided orchestration for Docker
containers.
The primary strength of Mesosphere DC/OS is its maturity and well-proven ability to run mission-critical
applications on a very large scale.
Note: Note that Docker, Kubernetes, and Mesosphere DC/OS are not the only container
technologies available in Azure. For example, you can deploy the Deis PaaS-based solution for
running clusters of containerized applications or implement the CoreOS-based rkt container
system.
Despite their differences, the three container orchestrators share a number of common features. In
particular, they all support separation between the management layer and the layer responsible for
hosting application containers. The management layer consists of master nodes, whose names vary
depending on the orchestrator. Containerized applications run on agent nodes, referred to also as
minions or workers. Each orchestrator also supports some form of load balancing, service discovery, which
helps locate containers that need to communicate with one another, and container scheduling. Container
scheduling automatically starts failed containers and rebalances them if the number of agent nodes
changes. All the orchestrators isolate their master and agent nodes, while facilitating direct
communication between containers running on the same or different hosts. In addition, each orchestrator
implements high availability, although the level of resiliency tends to increase with product maturity. For
example, Mesosphere supports rack awareness, which helps ensure that two instances of the same
containerized application are not running on the same physical hardware. The management interfaces of
each orchestrator product differ, with Docker limited to command-line tools and DC/OS providing a
feature-rich, web-based front end.
Note: ACS compensates for some orchestrators’ lack of built-in support for some features.
For example, it automatically implements Azure load balancers to provide connectivity from the
internet to containerized applications.
Creating and managing an ACS Docker Swarm cluster

You can use ACS to implement Docker Swarm by
performing these tasks:
1. Creating a Swarm cluster by using ACS.
2. Connecting to the Swarm cluster.
3. Deploying containers to the Swarm cluster.
Creating a Docker Swarm cluster by

using ACS
You can complete this task by using several
methods, including the Azure portal, an Azure
Resource Manager template, Azure CLI 2.0, or ACS
APIs. This topic will describe the first of these methods. Before you start, make sure that you have created
the following:
• An Azure subscription where you intend to deploy the cluster.
• An SSH RSA public key that you will use to authenticate against ACS VMs.
Additional Reading: For instructions regarding generating SSH RSA keys on a Windows
computer, refer to: “How to Use SSH keys with Windows on Azure” at: https://aka.ms/hhh8pq
For equivalent instructions applicable to Linux and Mac OS X computers, refer to: “How to create
and use an SSH public and private key pair for Linux VMs in Azure” at: https://aka.ms/csgnqn
After you create the two prerequisites, use the following procedure to create an ACS Docker Swarm
cluster:
1. In the Azure portal, click New.

2. On the New blade, in the Search the Marketplace text box, type Azure Container Services.
3. On the Everything blade, click Azure Container Service.
4. On the Azure Container Service blade, click Create.
5. On the Basics blade, in the Name text box, type a unique name of the ACS cluster that you want to
create, select the target Azure subscription, create a new resource group or select an existing one,
and then choose the target Azure region where the cluster will reside. Click OK.
6. On the Master configuration blade, in the Orchestrator drop-down list, select Swarm.
7. In the DNS name prefix text box, provide a unique name that will be part of the fully
qualified domain name (FQDN) of the cluster master. The FQDN will take the form
prefixmgmt.location.cloudapp.azure.com, where location represents the Azure region you
chose in step 5.
8. In the User name text box, type the name of the Administrator account of the ACS VMs that will host
the Docker containers.
9. In the SSH public keys text box, paste the SSH RSA public key that you generated earlier.
10. In the Master count dialog box, type the number of master nodes in the cluster.
11. Select or clear VM diagnostics.
12. Click OK.

13. On the Agent configuration blade, in the Agent count text box, type the number of agent nodes.
14. Click Agent virtual machine size, on the Choose a size blade, click the Azure VM size you want to
use for the agent nodes, click Select, and then click OK.
15. On the Summary blade, click OK to start the deployment.
Additional Reading: For information about creating a Swarm cluster in ACS via Azure CLI
2.0, refer to: “Deploy a Docker container hosting solution using the Azure CLI 2.0” at:
https://aka.ms/ws4qpr
Connecting to a Swarm cluster

After the deployment completes, you can connect to the load balancer in front of the master node tier by
using its DNS name, in the format prefixmgmt.location.cloudapp.azure.com, where location represents the
Azure region hosting the cluster. To establish a connection, use the following steps:
1. To identify the DNS name, go to the cluster blade in the Azure portal, and then copy the value of the
MasterFQDN entry in the Overview section of the cluster blade.
2. Use the ssh command-line tool to establish an SSH tunnel-based connection to the first master node
by running the following command:
ssh -L 2375:localhost:2375 -p 2200 demouser@<MasterFQDN> -i <privateKeyfile>
<MasterFQDN> is the value that you copied from the Azure portal in step 1 and <privateKeyfile> is
the full path to the file containing the private key corresponding to the public key that you provided
during cluster deployment.
3. Once connected, you can identify the agent configuration by running the following command:
docker –H 172.16.0.5:2375 info
4. To eliminate the need to specify the target socket when running Docker client commands, set the
value of the DOCKER_HOST environment variable to the value referenced above by running the
following command:
export DOCKER_HOST=172.16.0.5:2375
Additional Reading: The ssh tool is part of Git for Windows, which is available at
https://aka.ms/u48oog. Alternatively, you can connect to a master node via an SSH tunnel by
using the PuTTY tool. For details about this procedure, refer to: “Make a remote connection to a
Kubernetes, DC/OS, or Docker Swarm cluster” at: https://aka.ms/nzlg31
Deploying containers to a Swarm cluster

Once you establish an SSH tunnel to a Swarm cluster, you can manage it by using the Docker client. For
example, to deploy a new container, you can use the docker run command, as in the following example:
docker –H 172.16.0.5:2375 run -d -p 80:80 nginx
If you want to accomplish the same outcome as the export command listed above, you can run the
following command:
docker run -d -p 80:80 nginx

To deploy multiple containers, you can rerun the same command multiple times. Swarm will automatically
distribute them across the agent nodes. To determine their distribution, you can use the docker ps
command and view the entries in the NAMES column in the resulting output. Deploying multicontainer
applications is the same as the Docker Compose–based procedure that you followed in the first lesson of
this module.
Architecture of a Docker Swarm–based ACS cluster

When you provision a Docker Swarm–based ASC cluster, the Azure platform automatically creates several
additional resources. These resources include a VM scale set containing agent nodes and a master
availability set containing master Azure VMs and master and agent load balancers along with their
respective public IP addresses.
Note: All these resources are part of the automatically generated resource group, whose
name starts with the name of the resource group that you specified when creating the Docker
Swarm cluster.
The agent load balancer handles distribution of incoming traffic across agent nodes and containers
running within them. If you intend to make your containerized applications available via ports other than
the ones predefined as part of the load-balancer configuration, you must modify the load-balancing rules.
Additional Reading: For more information about container management with Docker
Swarm, refer to: “Container management with Docker Swarm” at: https://aka.ms/jtkhxc
Creating and managing an ACS Kubernetes cluster

You can use ACS to implement Kubernetes by
performing these tasks:
1. Creating a Kubernetes cluster by using ACS.
2. Connecting to the Kubernetes cluster.

3. Deploying containers to the Kubernetes
cluster.
Creating a Kubernetes cluster by using

ACS
You can complete this task by using the Azure
portal, an Azure Resource Manager template, or
Azure CLI 2.0. Alternatively, you can use the open-source GitHub project named acs-engine to define the
cluster, and then deploy it by using Azure CLI 2.0.
Additional Reading: To find out more information about the acs-engine project, refer to:
“Azure/acs-engine” at: https://aka.ms/n70ubu
This topic will describe how to use the Azure portal to create a Kubernetes cluster. Before you start, make
sure that you have created the following:
• An Azure AD service principal client ID and the corresponding secret. The service principal is
necessary to allow the cluster to dynamically manage Azure resources that are part of cluster
networking infrastructure, including user-defined routes and Azure load balancers. To create the
service principal by using Azure CLI 2.0, use the following steps:
1. Authenticate to your Azure subscription:
az login
2. If there are multiple subscriptions associated with your credentials, select the target subscription:
az account set --subscription <subscription ID>
<subscription ID> is the ID of the target subscription.
3. Create a resource group that will contain cluster networking infrastructure resources:
az group create –n <resource group name> -l <Azure region>
<resource group name> is the name of the resource group and <Azure region> is the Azure
region where your cluster will reside.
4. Create a service principal in the Azure AD tenant associated with your Azure subscription and
assign the Contributor role to it, with the scope set to the newly created resource group:
az ad sp create-for-rbac --role=”Contributor” --
scopes=”/subscriptions/<subscription ID>/resourceGroups/<resource group name>
This will return several attributes of the service principal, including appId and password. You will
use their values when creating the cluster.
Additional Reading: For instructions about generating SSH RSA keys on Windows and Linux
computers, refer to the information provided in the first topic of this lesson. For more
information about setting up an Azure AD service principal for a Kubernetes cluster when using
ACS, refer to: “Deploy Kubernetes cluster for Linux containers” at: https://aka.ms/yi5qri
After you create the three prerequisites, use the following procedure to create an ACS Kubernetes cluster:

create, select the target Azure subscription, select the resource group that you created earlier, and
then choose the target Azure region where the cluster will reside. Click OK.
6. On the Master configuration blade, in the Orchestrator drop-down list, select Kubernetes.
7. In the DNS name prefix text box, provide a unique name that will be part of the cluster master’s
FQDN. The FQDN will take the form prefixmgmt.location.cloudapp.azure.com, where location
represents the Azure region that you chose in step 5.
Docker containers.
10. In the Service principal client ID text box, type the value of the appID attribute that displayed in the
output of the az ad sp create-for-rbac command that you ran earlier.
11. In the Service principal client secret text box, type the value of the password attribute that
displayed in the output of the az ad sp create-for-rbac command that you ran earlier.
13. Click OK.
15. Click Agent virtual machine size, on the Choose a size blade, click the Azure VM size that you want
to use for the agent nodes, and then click Select.
16. In the Operating system drop-down list, select either the Linux or Windows operating system.
Note: At the time of authoring this content, Windows-based deployment is in preview.
17. Click OK.
Additional Reading: For information about creating a Kubernetes cluster in ACS by using
Azure CLI 2.0, refer to: “Deploy Kubernetes cluster for Linux containers” at: https://aka.ms/toica5
Connecting to a Kubernetes cluster in ACS

Once the deployment completes, connect to the cluster by using the Kubernetes command-line client
kubectl, following these steps:
1. If necessary, start by installing Azure CLI 2.0. Follow with the installation of kubectl by running the
following command at a command prompt:
az acs kubernetes install-cli
Alternatively, you can use Azure Cloud Shell, which has both Azure CLI 2.0 and kubectl preinstalled.
2. Next, retrieve the credentials necessary to authenticate successfully to the target cluster:
az acs kubernetes get-credentials --resource-group=myResourceGroup --

name=myK8sCluster --ssh-key-file <privateKeyfile>
<privateKeyfile> is the full path to the file containing the private key corresponding to the public key
you provided during cluster deployment.
3. To verify that the connection was successful, you can list the cluster nodes by running the following
command:
kubectl get nodes
You might need to reference kubectl.exe by its full path if its current location is not referenced in
the PATH system environment variable.
Deploying applications to a Kubernetes cluster

Deploying containerized applications to a Kubernetes cluster requires the usage of YAML-formatted
manifest files. A manifest file describes a desired cluster state, including container images that should be
running on its agent nodes. The following illustrates a sample manifest file:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: azure-vote-back
spec:
replicas: 1
template:
metadata:
labels:
app: azure-vote-back
spec:
containers:
- name: azure-vote-back
image: redis
ports:
- containerPort: 6379
name: redis
---
apiVersion: v1
kind: Service
metadata:
name: azure-vote-back
spec:
ports:
- port: 6379
selector:
app: azure-vote-back
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: azure-vote-front
spec:
replicas: 1
template:
metadata:
labels:
app: azure-vote-front
spec:
containers:
- name: azure-vote-front
image: microsoft/azure-vote-front:redis-v1
ports:
- containerPort: 80
env:
- name: REDIS
value: "azure-vote-back"
---
apiVersion: v1
kind: Service
metadata:
name: azure-vote-front
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: azure-vote-front
To apply the manifest file to the cluster, save it to a text file, and then run the kubectl create command
with the –f parameter followed by the file name. To monitor the progress of a deployment, you can use
the kubectl get service command referencing the name of the containers, followed by the –watch
parameter. For example, with the sample YAML file listed above, you would run:
kubectl get service azure-vote-front --watch
This command would periodically display the status of the containers, including their external IP
addresses. Once an IP address becomes available, you will be able to connect to it from the internet.
Architecture of a Kubernetes-based ACS cluster

Just as Docker Swarm, when you provision a Kubernetes-based ASC cluster, the Azure platform
automatically creates a number of additional resources. The primary difference in this case is that
Kubernetes does not use Azure VM scale sets for agent nodes. Its network configuration is more complex,
relying on user-defined routes to facilitate resilient communication between master and agent nodes.
However, ACS and Kubernetes automatically handle details of this configuration, so this extra complexity
does not increase management overhead.
Note: All these resources are part of the same resource group, to which you deployed the
Kubernetes-based ACS cluster.
Additional Reading: For more information about container management with Kubernetes,
refer to: “Deploy Kubernetes cluster for Linux containers” at: https://aka.ms/toica5
Creating and managing an ACS DC/OS cluster

You can use ACS to implement Marathon of
Mesosphere DC/OS by performing these tasks:
1. Creating a DC/OS cluster by using ACS.

2. Connecting to the DC/OS cluster.
3. Deploying containers to the DC/OS cluster.
Creating a DC/OS cluster by using ACS

You can complete this task by using several
methods, including the Azure portal, an Azure
Resource Manager template, Azure CLI 2.0, or ACS
APIs. This topic will describe the first of these
methods. Before you start, make sure that you have created the following:

Note: For instructions about generating SSH RSA keys on Windows and Linux computers,
refer to the information provided in the first topic of this lesson.
After you create the two prerequisites, use the following procedure to create a DC/OS cluster:
create, select the target Azure subscription, create a new resource group or select an existing one,
and then choose the target Azure region where the cluster will reside. Click OK.
6. On the Master configuration blade, in the Orchestrator drop-down list, select DC/OS.
7. In the DNS name prefix text box, provide a unique name that will be part of the cluster master’s
FQDN. The FQDN will take the form prefixmgmt.location.cloudapp.azure.com, where location
represents the Azure region that you chose in step 5.
Docker containers.
11. Select or clear VM diagnostics.
12. Click OK.
14. Click Agent virtual machine size, on the Choose a size blade, click the Azure VM size you want to
use for the agent nodes, click Select, and then click OK.
Additional Reading: For information about creating a DC/OS cluster in ACS by using Azure
CLI 2.0, refer to: “Deploy a DC/OS cluster” at: https://aka.ms/wyod2m
Connecting to a DC/OS cluster

After the deployment completes, you can connect to the load balancer in front of the master node tier by
using its DNS name, in the format prefixmgmt.location.cloudapp.azure.com, where location represents the
Azure region hosting the cluster. To establish a connection, use the following steps:
1. To identify the DNS name, go to the cluster blade in the Azure portal, and then copy the value of the
MasterFQDN entry in the Overview section.
2. Use the ssh command-line tool to establish an SSH tunnel-based connection to the first master node
by running the following command:
ssh -L 80:localhost:80 -p 2200 demouser@<MasterFQDN> -i <privateKeyfile>
<MasterFQDN> is the value that you copied from the Azure portal in step 1 and <privateKeyfile> is
the full path to the file containing the private key corresponding to the public key that you provided
during cluster deployment.
Note: For instructions about using SSH on Windows, refer to the second topic of this lesson.
3. After you are connected, you can use a web browser to go to http://localhost, which will display the
DC/OS portal. This allows you to view and manage cluster configuration and resources.
4. To manage the cluster via command line, install DC/OS CLI. If necessary, install Azure CLI 2.0, and
then run the following command at the command prompt:
az acs dcos install-cli
5. Next, configure the dcos tool to use the existing SSH tunnel by running:
dcos config set core.dcos_url http://localhost
Deploying containers to a DC/OS cluster

Deploying containerized applications to a DC/OS cluster requires configuring Marathon, which serves as
the container orchestrator. You control this configuration by using YAML-formatted files. The following
listing illustrates a sample configuration file that deploys a single instance of a Docker container based on
the nginx image, makes it available from the internet on port 80, and then allocates CPU, memory, and
disk resources to it:
{
"id": "nginx-demo",
"cmd": null,
"cpus": 1,
"mem": 32,
"disk": 0,
"instances": 1,
"container": {
"docker": {
"image": "nginx",
"network": "BRIDGE",
"portMappings": [
{
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp",
"name": "80",
"labels": null
}
]
},
"type": "DOCKER"
},
"acceptedResourceRoles": [
"slave_public"
]
}
To apply the manifest file to the cluster, save it to a text file and then run the dcos marathon app add
command followed by the file name. To monitor the progress of a deployment, you can use the dcos
marathon app list command. The command displays the status of the containerized applications. After
the value of the WAITING column for the application in the command output displays True, you will be
able to connect to it from the internet. To identify the external IP address, switch to the cluster blade in
the Azure portal, and then copy the value of the entry in the FQDN column in the row displaying the
agentpool configuration.
You can also view the status of the application in the DC/OS portal by navigating to the Services node.
Architecture of a DC/OS-based ACS cluster

When you provision a DC/OS-based ASC cluster, the Azure platform automatically creates several
additional resources, including a VM scale set containing private and public agents and a master
availability set containing master Azure VMs and master and agent load balancers along with their
respective public IP addresses.
Note: All these resources are part of an automatically generated resource group, whose
name starts with the name of the resource group that you specified when creating the DC/OS
cluster.
The public agent load balancer handles distribution of incoming traffic across public agent nodes and
containers running within them. If you intend to make your containerized applications available via ports
other than the ones predefined as part of the load balancer configuration, you must modify the load-
balancing rules.
Additional Reading: For more information about container management with DC/OS, refer
to: “Deploy a DC/OS cluster” at: https://aka.ms/wyod2m
Demonstration: Creating an ACS DC/OS cluster

In this demonstration, you will see how to implement a DC/OS cluster.

Question
What are the primary characteristics of Docker Swarm–based ACS deployments?
Support for Docker APIs
YAML-based container deployments
Cluster management via a web-based interface
Cluster management via a command-line interface
Requirement to create an Azure AD service principal

Lab B: Implementing Azure Container Service

Scenario
A. Datum is considering implementing containers on a larger scale by leveraging the capabilities that ACS
offers. You intend to choose one of the three orchestrators available and test its functionality. You want to
test load balancing and scaling of a sample containerized application.
Objectives
• Create an ACS cluster.
• Manage the ACS cluster.
Lab Setup
User name: Admin

Password: Pa55w.rd
Question: What deployment methodology would you choose when deploying ACS clusters?
Question: What are the primary advantages of using ACS for deploying container clusters?

Review Question
Question: Which container orchestration approach would you implement in your

environment?
8-1
Module 8
Implementing Azure Cloud Services
Contents:
Module Overview 8-1
Lesson 1: Planning and deploying Azure Cloud Services 8-2
Lesson 2: Managing and maintaining Azure Cloud Services 8-10
Lab: Implementing Azure Cloud Services 8-18

Module Overview
Azure Cloud Services constitute another hosting model you can use to run web applications and web
services in Microsoft Azure. These cloud services use a modular architecture that allows you to scale your
application to very large sizes while minimizing costs. In this module, you will see how to create,
configure, manage, and monitor cloud services.
Objectives
• Plan and deploy Azure Cloud Services.
• Explain how to manage and maintain Azure Cloud Services.

8-2 Implementing Azure Cloud Services
Lesson 1
Planning and deploying Azure Cloud Services
Azure provides two main categories of hosting options for applications: infrastructure as a service (IaaS)
and platform as a service (PaaS). So far, this course has covered IaaS-based Azure VMs and PaaS-based
App Service. In this lesson, you will see how PaaS-based Azure Cloud Services differ from Azure App
Service and Azure VMs and how Azure Cloud Services allow you to create a modular, flexible, and highly
scalable application architecture. You will also see how to configure Azure Cloud Services and deploy
cloud service packages created by developers.
Lesson Objectives
• Describe how Azure Cloud Services integrate with other Azure services to support applications.
• Explain how to create and deploy Azure Cloud Services.

• Describe how to manage Azure Cloud Services deployment environments.
• Explain how to update Azure Cloud Services.

module
the lab.
Azure Cloud Services as components of Azure

Azure VMs is an IaaS execution model that allows
you to install and configure servers to run both
stateful and stateless applications in the cloud.
Azure App Service is a PaaS execution model that
you can use to run stateless applications and
services without maintaining underlying hardware,
operating systems, and web servers. You have
learned about these services earlier in this course. In
this module, you will learn about another hosting
model currently available in Azure, which is referred
to as Azure Cloud Services.
Note: In Azure, the term cloud service refers

to either a cloud service that hosts classic Azure VMs or a cloud service that hosts web roles and
worker roles. Both service types are specific to the classic deployment model. In this module, the
term Cloud Services refers to the Azure service that contains web and worker roles. Any
references to instances of this service will use the noncapitalized notation (cloud service).
You can use the Azure Cloud Services hosting model to host websites or web services. You can build these
web services with a more modular architecture than Azure App Service provides. In particular, Azure
Cloud Services can divide the workload into web roles and worker roles. A web role provides front-end
functionality, whereas a worker role typically handles background tasks.
Just like Azure App Service, Azure Cloud Services allow you to scale out your applications to help ensure
fault tolerance and provide scalability. However, you have extra flexibility with Azure Cloud Services,
because you can scale each role independently of other roles in the same application. Note that despite
this modularity, you can configure virtual machines hosting different roles to directly communicate with
each other within the same cloud service.
Azure Cloud Services closely integrate with other Azure PaaS services and with services deployed by using
the classic deployment model. For example, you can deploy a PaaS cloud service into a classic virtual
network to allow direct communication with other Azure Cloud Services or classic Azure VMs. This also
allows Azure Cloud Services to communicate directly with Azure VMs deployed by using the Azure
Resource Manager deployment model, as long as the classic VNET is connected to the virtual network
hosting these virtual machines through a VNET-to-VNET connection or VNET Peering.
You can use a storage account or an Azure SQL Database instance to provide persistent storage for virtual
machines running web and worker roles. This, in turn, allows you to facilitate scenarios that require
preserving the session state, which should not be stored directly within Azure Cloud Services because of
their stateless nature. Temporary storage services (such as Azure Storage queues or Azure Service Bus
queues) also provide a means of asynchronous messaging between web and worker roles.
Azure Cloud Services can also use Azure services such as Content Delivery Network, Azure Traffic
Manager, and Azure Active Directory, which enhance the capabilities of web applications and services.
You implement these services to interact with Azure Cloud Services in a similar way as in virtual machines
or App Service.
Azure Cloud Services are not fully compatible with services deployed by using the Azure Resource
Manager deployment model. In particular, you cannot deploy a PaaS cloud service to a virtual network
created by using the Azure Resource Manager deployment model.
Azure Cloud Services overview

Traditionally, you could use three hosting models
for running applications in Azure:
• IaaS-based Azure VMs. This model involves

running applications on Windows and Linux
virtual machines. It offers the highest degree of
control of the operating system, allowing you
to install, customize, and run almost any
application, providing that the resulting
configuration does not rely on network or
storage infrastructure functionality that is not
currently supported in Azure. Such flexibility,
however, comes with management overhead,
because you, as the owner of the virtual machines, are responsible for the maintenance and updates
of the operating system, the application, and any of its software dependencies.
• PaaS-based Azure App Service. This model eliminates the management overhead associated with
IaaS-based Azure VMs. It delivers a fully managed platform designed specifically to optimize the
development, deployment, and running of web and mobile applications. These optimizations, along
with the stateless nature of applications that this model supports, result in superior agility. App
Service also considerably simplifies the integration and automation of business processes in addition
to the building, publishing, and consuming of cloud application programming interfaces (APIs).
However, this simplicity and ease of use limit your flexibility to some extent. For example, this affects
your ability to use App Service to implement multitier applications, where the compute and web tiers
must operate and scale independently. Your access to the virtual machines hosting App Service
applications is also considerably more limited. For example, you cannot connect to them through
Remote Desktop.
• PaaS-based Azure Cloud Services. This model combines the advantages of IaaS-based Azure VMs and
PaaS-based App Service. It gives you direct access to the virtual machines hosting your applications,
but at the same time, it relies on the platform to handle their maintenance and updates. It is well
suited for supporting multi-tier applications by facilitating distinct roles, with the web role providing
front-end services and the worker role handling background tasks. Because the Azure platform must
provision virtual machines automatically for each tier, the entire configuration of the virtual machines
must be defined by using a combination of compiled code and configuration files. Consequently,
they are stateless and should not be used to store any data.
Note: The differences among the hosting models just listed become less distinct as Azure
services evolve. For example, Azure App Service includes the Premium service plan option called
Azure App Service Environment, intended for multi-tier applications. This is possible because of
its ability to host multiple resource pools, with one of them providing front-end services and up
to three handling background tasks.
Similarly, Azure Resource Manager–based Virtual Machine Scale Set service, with its elasticity and
superior scale-out capabilities, resembles Azure Cloud Services in many aspects.
This traditional arrangement is changing with the advent of microservices, which represent small, self-
contained components of individual applications. In particular, Azure Service Fabric is quickly emerging as
a new PaaS hosting model along with other compute platforms, such as containers or Azure Container
Services. For example, Service Fabric is frequently referred to as PaaS 2.0 because of its support for both
stateful and stateless services and its improved use of computing resources. The latter results from the
more efficient distribution of application components across multiple virtual machines.
Containers provide another way to host applications in Azure. They enable running multiple applications
fully isolated from each other on the same Azure virtual machine, further increasing resource utilization. In
addition, containerization based on Docker and Windows Server Containers offers a standardized
approach to application packaging and deployment, best exemplified by Azure Container Service. You
can also use containers in combination with the microservices-based application hosting model. This
allows you to capitalize on the benefits offered by each, including hyperscaling and increased density as
well as isolation and standardized application management.
Note: For a more comprehensive overview of compute hosting models in Azure, refer to
the topic “Understanding compute hosting options provided by Azure” in Module 1,
“Introduction to Microsoft Azure.”
Roles in Azure Cloud Services

As mentioned earlier, in Azure Cloud Services, developers can divide the expected workload and the
corresponding code into separate roles. Two types of roles exist:
• Web roles. A web role serves as the front end of a cloud service and runs on one or more virtual
machines, with each one hosting a Microsoft Internet Information Services (IIS) web server. For
example, in a web site based on Microsoft .NET, the web role contains the web pages that make up
the user interface for the web application.
• Worker roles. A worker role typically handles asynchronous background processes. It also commonly
runs on one or more dedicated virtual machines. A web role commonly uses a worker role to
complete resource-intensive, long-running, or continuous tasks.
You can configure each role to have multiple instances. By creating multiple instances for each role, you
can scale out the cloud service and increase its resilience to failures.
Web roles and worker roles enable flexible and efficient scaling. For example, if an application has one
processor-intensive task, such as video processing, developers can separate that code into a worker role.
When you deploy the cloud service, you can scale the processor-intensive task independently without
having to scale out the entire application, which would unnecessarily increase the overall cost.
Note: Create at least two instances of each role in your Azure cloud service. This helps
ensure that an instance is available to respond to users if a single failure occurs. You need to
create at least two instances of each role to qualify for the 99.95 percent uptime guarantee
stipulated in the Azure service level agreements (SLAs). Instances of the same role run in separate
fault domains and separate upgrade domains.
Because virtual machines hosting role instances are stateless, it is common to configure Azure Cloud
Services to use a database to store any content that needs to be preserved. To implement such a
database, you can run Microsoft SQL Server in an Azure virtual machine or deploy an Azure SQL Database
instance.
You can create a cloud service by using a configuration file and an application package containing
compiled code and a cloud service definition file. The next lesson explores the structure of Azure Cloud
Service in more detail.
Creating and deploying Azure Cloud Services

Developers typically define the structure and
applications that an Azure cloud service will host by
using an Integrated Development Environment
(IDE) such as Microsoft Visual Studio. The Azure
software development kit (SDK) includes emulators
that can run web roles and worker roles on
developers’ computers in an environment that
closely matches Azure. After a cloud service code is
complete, the next step involves creating a cloud
service in Azure and deploying the code into it.
Creating a PaaS cloud service

To create a PaaS cloud service in the Azure portal,
complete the following steps:
1. On the hub menu, click +New.
2. On the New blade, click Compute.

3. On the Compute blade, click Cloud service.
4. On the Cloud service (classic) blade, specify the following settings:
o DNS name: Any unique name

o Subscription: The name of your Azure subscription
o Resource group: The resource group where the cloud service will reside
o Location: The Azure region that will host cloud service instances
5. At this point, you have the option to upload the cloud service package file and the configuration file,
and specify the production or staging environment where the cloud service instances will be
deployed.
Alternatively, you can create a PaaS cloud service by using the New-AzureService Azure PowerShell
cmdlet, as shown in the following example. Note that this method does not allow you to specify the
resource group or upload the package and configuration files when you create a cloud service.
New-AzureService -ServiceName ‘MyNewService’ -Location ‘East US’
Deploying service code

After you create a cloud service, you also need to deploy the compiled service code and the service
configuration file that define the settings of web and worker roles. Three common ways to perform this
deployment are:
• From Visual Studio, by using the Publishing Wizard. To ease this deployment method, you can obtain
a publish profile from Azure and import it into Visual Studio. This method uses Web Deploy to create
and configure web roles.
• From the Azure portal, by uploading a cloud service package and configuration file. Developers can
create these files by using the Packaging Wizard in Visual Studio. Administrators can use these files to
upload the service code and start the application.
• From Visual Studio Team Services, by configuring continuous deployment. If you choose this option,
take care to ensure that untested code is not accidentally deployed to the production environment.
Frequently, Visual Studio Team Services is configured to deploy code to a staging environment. After
the staged code has been tested, administrators can move it to the production environment.
Note: In the lab, you will see how to deploy a cloud service by using the Azure portal.
Managing deployment environments for Azure Cloud Services

A cloud service runs in different locations during
development, testing, and production. In each
organization, development teams work based on
different project models. However, the following
divisions are commonly used.
During development
Most developers run informal tests on their code as
they develop it. These tests, which all the
developers on the team run repeatedly as they
modify code, are considered essential in many
organizations. Because developers run these tests
frequently, they code and run them in the IDE. At
this stage, the code runs on the developers’ computers.
For an Azure Cloud Service project, developers need an environment on their local computers that closely
matches Azure. The Azure SDK provides such an environment. This SDK has two important components,
both of which start on the developer’s computer in debugging mode:
• The Azure compute emulator. Web roles and worker roles run within this emulator.
• The Azure storage emulator. The emulator provides Blob storage, Queue storage, and Table storage
services.
During staging
Staging is the last opportunity to test a project before it is deployed to production. The following tests are
commonly performed at this stage:
• Acceptance testing. These tests check that the completed project satisfies the functional and
nonfunctional requirements.
• Performance testing. These tests simulate user demand and determine the CPU, memory, and other
resources that might be required to cope with the expected load.
• Beta testing. A limited number of the final users of the project are granted access to the staging
environment to try out the software and identify issues.
For an Azure Cloud Service project, the staging environment should be in Azure itself—so you must
deploy the project. You can use a staging slot for this deployment. A staging slot is a deployment of a
cloud service with the following characteristics:
• In the Azure portal, it appears within a single cloud service, together with the production slot.
• To access the cloud service in the staging slot, you use a URL that includes the GUID. For example, if
your cloud service is found at http://myservice.cloudapp.net, the staging slot is found at
http://GUID.cloudapp.net. You can determine the GUID by browsing the service’s dashboard in the
Azure portal.
Alternatively, you can create a separate cloud service for staging.
By using a staging slot, when all the tests have passed, you can deploy the service to production by using
a virtual IP (VIP) swap. In this operation, the staging and production slots are swapped, which means that
the accepted new version is moved to production without a new deployment of the code.
During production
The production environment is the final destination for the cloud service code. This environment runs
thoroughly tested and debugged code that your team has complete confidence in and services real user
requests based on live data and configuration settings.
Demonstration: Creating and deploying Azure Cloud Services

• Create a new PaaS cloud service by using Azure PowerShell.

• Configure and package a cloud service project in Visual Studio.
• Deploy a packaged cloud service project by using the Azure portal.
Updating Azure Cloud Services

After deploying the first version of a cloud service,
developers tend to continue modifying the code.
Changes can include new features, bug fixes,
efficiency improvements, code that utilizes new
features of the Azure platform, or code that
implements user feedback.
To deploy a new version of a cloud service to Azure,

you must upload the compiled package file and
configuration file in the same way that you did
when deploying the first version. You can do this by
using the Publishing Wizard in Visual Studio, by
manually uploading the files in the Azure portal, or
by using continuous deployment in Visual Studio Team Services. Regardless of the approach, you should
use a staging slot to evaluate the functionality and performance of the new version before promoting it to
production.
Staging slots provide an extra advantage when deploying updated services. When you move the staged
code into the production slot by performing a VIP swap, the older version of the service is automatically
moved into the staging slot and not overwritten. In the event of any problem with the new version, you
can easily roll back the deployment to the old version by swapping again. In addition, the VIP swap does
not take a significant amount of time, eliminating potential downtime associated with the staging process.
Note that unlike with App Service, staging functionality is implemented by using dedicated virtual
machines, which means you have the option to test deployments without affecting the performance of
the production services.
Question: Now that you understand the development, staging, and production
environments that the Azure SDK and Azure itself provide, you can consider how your own
organization might use them. The instructor will lead a discussion based on the following
questions. Contribute to the discussion by describing how development, staging, and
production environments are currently built in your company, and consider how your testing
policies can be implemented in Azure. Here are the questions:
How are on-premises applications separated for testing, staging, and production
deployments in your organization?
How are cloud applications separated for testing, staging, and production deployments
in your organization?
How will Azure modify your approach to testing, staging, and production deployment?
Lesson 2
Managing and maintaining Azure Cloud Services
Developers create and modify code that defines Azure Cloud Services, but Azure administrators must be
able to configure and manage their deployments. For example, administrators must ensure that a cloud
service is able to accommodate expected and unexpected peaks in demand. In this lesson, you will see
how to configure a cloud service by using configuration files and the Azure portal.
Lesson Objectives
At the end of this lesson, you will be able to:
• Modify a cloud service by making changes to the service configuration file.
• Explain how to manage endpoints and queues.
• Describe how to add a cloud service to an Azure virtual network.
• Explain how to configure the monitoring of Azure Cloud Services.

• Describe how to monitor Azure Cloud Services.
Modifying configuration files

When you deploy a cloud service to Azure, you
upload two files:
• The package file. This file contains the compiled

code for web roles and worker roles.
• The configuration file. This file contains

configuration settings that Azure uses when it
starts instances of the roles of the cloud service.
The configuration file that is used in development is

typically not appropriate for staging or production.
Visual Studio automatically generates two versions
of the file: ServiceConfiguration.Local.cscfg is for
local development and ServiceConfiguration.Cloud.cscfg is for deployment to Azure. If you need to
modify the configuration settings after development is completed, you can accomplish this in several
ways:
• Edit the file directly. The configuration file is an .xml file, so you can use any text editor to make
changes.
• Edit many values in the Azure portal after deployment.
• Use the Visual Studio Publishing Wizard. Its friendly interface helps to simplify adjusting the
parameters of connection strings.
The following code shows a simple cloud service configuration file:
Example Service Configuration File

<ServiceConfiguration serviceName="AdatumAdsCloudService"
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"
osFamily="4"
osVersion="*"
schemaVersion="2014-01.2.3">
<Role name="AdatumAdsWeb">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
value="UseDevelopmentStorage=true" />
<Setting name="StorageConnectionString"
</ConfigurationSettings>
</Role>
<Role name="AdatumAdsWorker">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
<Setting name="StorageConnectionString"
<Setting name="AdatumAdsDbConnectionString"
value="Data Source=(localdb)\v11.0; Initial Catalog=AdatumAds;
Integrated Security=True; MultipleActiveResultSets=True;" />
</ConfigurationSettings>
</Role>
</ServiceConfiguration>
The preceding example shows a typical configuration file used in the development environment. Only one
instance of each role is configured, and connection strings use the Azure storage emulator and a local
database.
A configuration file used for an Azure deployment commonly includes custom values for the following
parameters:
• Instance count. You should always use two or more instances of every role in the production
environment. This considerably improves resilience and qualifies the service for the 99.95 percent
uptime guarantee stipulated in the Azure availability SLAs. Use the Count attribute of the
<Instances> tag to specify the number of instances for each role.
• Database connection strings. You must ensure that the database connection strings point the cloud
service to the production database. This database can be an Azure SQL Database instance or a SQL
Server instance running in an IaaS virtual machine. When using an Azure SQL Database instance, you
can copy its connection string from its settings displayed in the Azure portal.
• Storage connection strings. If the service uses an Azure storage account, you must ensure that the
storage connection strings point the cloud service to the production storage account. You can copy
the connection string designating a storage account from its settings displayed in the Azure portal.
Managing endpoints and queues

Although web roles and worker roles in an Azure
cloud service run on different virtual machines, you
must ensure that they can reliably communicate.
One way to accomplish this objective is to allow for
direct connectivity, where one role calls an
endpoint of another role. Another commonly used
approach involves indirect communication through
a queue. Software architects and developers
typically choose the most-appropriate connectivity
mechanism. However, as an administrator, you
should be familiar with the different options
available when configuring Azure Cloud Services.
Direct communication
Roles can communicate directly. For example, a web role can service a user request by calling a method in
a worker role. To enable this type of communication, you must create an endpoint in the destination role.
There are three types of endpoints:
• Input endpoints. These external, load-balanced endpoints enable Azure services and any internet-
connected clients outside of the cloud service to call the role using a designated protocol (TCP, UDP,
HTTP, or HTTPS) on a specific port.
• Internal endpoints. These endpoints enable roles within the same cloud service to directly
communicate using a designated protocol (TCP, UDP, HTTP, or combination of these) on a specific
port.
• Instance input endpoints. These endpoints enable Azure services and any internet-connected clients
outside of the cloud service to call a specific instance of a role using a designated protocol (TCP or
UDP) on a specific port.
You can administer endpoints in the cloud service configuration file. For example, the following XML code
defines an internal endpoint for a worker role:
Worker Role Endpoint Definition

<WorkerRole name="ImageProcessorRole">
<Endpoints>
<InternalEndpoint name="InternalImageIn" protocol="tcp" port="1000"/>
</Endpoints>
</WorkerRole>
The following XML code defines an external endpoint for a web role:
Web Role Endpoint Definition

<WebRole name="FrontEndRole">
<Endpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" localPort="80" />
</Endpoints>
</WebRole>
Using Storage queues and Service Bus queues

Instead of using direct communication, developers and software architects might use a queue to
temporarily store messages that roles send to each other. By using a queue, you can ensure that all
messages reach their destination, because each role processes its respective messages in the queue
asynchronously. You can also limit the possibility that the message processing task will consume all the
resources of the role instances. For these reasons, a queue is a popular communication method.
Two commonly used types of queues that Azure offers are Azure Storage queues and Service Bus queues.
Typically, developers and software architects decide which queuing mechanism to use in a scenario.
However, IT professionals should be aware of differences between these two options and be able to
configure them in combination with a cloud service. The following table lists basic differences between
Azure Storage queues and Service Bus queues.
Characteristic Storage queue Service Bus queue
Maximum message size 64 kilobytes (KB) 256 KB or 1 megabyte (MB), depending on the
service tier
Maximum queue size 500 terabytes (TB) 1 gigabyte (GB) to 80 GB, depending on
partitioning settings
Maximum message Seven days Unlimited

Time to Live (TTL)
Additional Reading: For more information about the differences between Storage queues
and Service Bus queues, refer to: “Azure Queues and Service Bus queues - compared and
contrasted” at: http://aka.ms/Wgyq5f
Adding a cloud service to an Azure virtual network

By default, a cloud service is not directly accessible
from any Azure VM or other cloud services in your
Azure subscription. Instead, Azure VMs and other
cloud services can access a cloud service in the
same way that external clients can—by using a
public endpoint.
You can enable direct communication between an
Azure cloud service, Azure VMs, and other Azure
cloud services by deploying them into the same
classic virtual network or across multiple, connected
virtual networks. To learn more about Azure virtual
networks, refer to Module 2, “Implementing and
managing Azure networking.” Keep in mind that you cannot deploy an Azure cloud service into a virtual
network provisioned by using the Azure Resource Manager deployment model.
By deploying a cloud service into a virtual network, you can:
• Reduce the latency of communication between Azure cloud services and Azure VMs, because
communication is direct and does not traverse public endpoints and an Azure load balancer.
• Enable on-premises clients to connect directly to a cloud service. This is possible if the virtual network
has connectivity to your on-premises network through a site-to-site virtual private network (VPN) or
ExpressRoute.
To add a cloud service to a virtual network, you must add a <NetworkConfiguration> section to the
service configuration file. You must insert this section after all the roles have been defined in the file.
In the following example, the service configuration file determines that the current cloud service will be
added to the A. Datum HQ virtual network:
Adding a PaaS Cloud Service to a virtual network

<NetworkConfiguration>
<VirtualNetworkSite name="AdatumHQ" />
<AddressAssignments>
<InstanceAddress roleName="SimpleWebRole">
<Subnets>
<Subnet name="HQSubnet1" />
</Subnets>
</InstanceAddress>
</AddressAssignments>
</NetworkConfiguration>
Note: You must add one <InstanceAddress> element to the <NetworkConfiguration>

element for every role in your cloud service.
Demonstration: Scaling Azure Cloud Services

• Set the default instance count for a cloud service.
• Schedule a larger instance count for an expected load peak.
Note: The scheduled scaling technique allows you to adjust the number of instances of
cloud service roles that are available during an expected increase in demand for the services
provided by the cloud service. After the peak period passes, instances are automatically de-
provisioned to avoid any extra cost. When you set the schedule, bear in mind that it can take a
few minutes for each new instance to become available. Start your schedule before the expected
peak period to ensure that the full capacity is reached in a timely manner.
Configuring monitoring for Azure Cloud Services

Cloud services might need to support large
numbers of users and continue to respond quickly
even during increased demand. You should be able
to monitor the performance of your service to help
ensure that users have a satisfactory experience.
Azure provides built-in basic monitoring
functionality for Cloud Services. You can use this to
determine how a cloud service is using the
resources of virtual machines hosting its role
instances.
Basic monitoring
By default, Azure Cloud Services collect performance data that includes the following counters on a per-
role basis:
• CPU (percentage)
• Disk read throughput (bytes/second)

• Disk write throughput (bytes/second)
• Network in (bytes)
• Network out (bytes)

You configure monitoring separately for the production and staging deployments.
Diagnostics monitoring
When you enable diagnostics monitoring, you can collect a much larger range of counters. This allows
you to gain a more detailed picture of the performance of instances and roles. Verbose monitoring stores
data in table storage. Therefore, you must create a new storage account or designate an existing account
that will store verbose monitoring data.
To configure diagnostics monitoring, you must enable and configure Azure Diagnostics for the cloud
service. You can accomplish this by using the following methods:
• When developing a new cloud service, apply the intended configuration in the Diagnostics
Configuration interface in Visual Studio. To implement this change, start by navigating to that role in
Solution Explorer and displaying the role’s Properties window. In the Properties window, in the
Diagnostics section, select the Enable Diagnostics check box. Specify the storage account that
should host the diagnostics data. Click Configure to display the Diagnostics configuration dialog
box. From here, you can specify individual sources of collected data, including application logs,
Windows Event Logs, performance counters, infrastructure logs, Event Tracing for Windows (ETW)
logs, and crash dumps. Other settings available within this dialog box include Disk Quota in MB,
which designates the maximum amount of space that diagnostics data should occupy. Visual Studio
saves the changes you make in the diagnostics.wadcfgx configuration file. Alternatively, you can
modify the diagnostics.wadcfgx configuration file directly.
In either case, your changes take effect the next time you run your project from within Visual Studio.
The changes also apply to the target Azure cloud service once you deploy your code into Azure.
• When modifying an existing cloud service, in Solution Explorer, right-click the target role, and then
click Update Diagnostics Settings. You will then see the same Diagnostics configuration dialog
box that is available when configuring diagnostics prior to a deployment.
Starting with Azure SDK 2.6, you can use the service configuration file to specify the diagnostics
storage account. This makes it simpler to assign different storage accounts for separate deployments
of the same cloud service.
Additional Reading: You will configure Azure Cloud Services diagnostics differently
depending on the version of Azure SDK that you use to develop a Cloud Services project. For
more information regarding this topic, refer to: “Configuring Diagnostics for Azure Cloud Services
and Virtual Machines” at: https://aka.ms/aznxvo
Note: Basic monitoring does not incur additional charges. However, because diagnostics
monitoring stores data in a storage account, it incurs extra costs for using the Azure Storage
service.
Monitoring Azure Cloud Services

You can view basic metrics representing your
monitoring configuration in the Azure portal. This
allows you to quickly determine the state of a
deployment over the last hour, day, week, or a
custom-defined time range. You can also add alerts
to metrics that the portal displays. As part of the
alert rule configuration, you can automatically send
an email to arbitrary recipients or route an alert to a
custom HTTP or HTTPS endpoint through a
webhook.
To add a metric to the monitoring table:
1. In the Azure portal, navigate to the cloud

service that you want to monitor.
2. On the cloud service blade, click the Monitoring pane.
3. On the Metric blade, click Edit chart.
4. On the Edit Chart blade, specify the monitoring time range.
5. On the Edit Chart blade, select the check boxes next to the metrics that you want to view on the
monitoring chart.
To configure an alert, use the following steps:

1. On the cloud service blade, click the Monitoring pane.
2. On the Metric blade, click Add alert.
3. On the Add an alert rule blade, specify the following settings:
o Resource. The resource that you want to monitor.
o Name. A custom name that you want to assign to the alert.
o Description. A custom description of the alert.

o Metric. The metric that you want to monitor.
o Condition. Select from the greater than, greater than or equal to, less than, or less than or
equal to options.
o Threshold. A value to which the platform applies the condition over the period of time that you
specify to determine whether to trigger the alert.
o Period. The period of time during which the condition that you specified must be true in order
for the alert to be triggered.
o Email owners, contributors, and readers. Recipients of an email that the alert automatically
generates.
o Additional administrator email(s). Email addresses that you can include as the recipients of the
autogenerated email.
o Webhook. An HTTP or HTTPS endpoint to which the alert should be routed.
You can view diagnostics data directly from within Visual Studio. For a high-level overview, in Server
Explorer, navigate to the role for which you enabled diagnostics, right-click the role, and then click View
Diagnostics Data. This will display the Diagnostics Summary window, in which you can review the list of
collected events. This option also allows you to export data from individual sources into a comma-
separated values (CSV) file.
To access each log directly, in Server Explorer, navigate to the storage account that you designated when
configuring diagnostics. Use the table viewer to explore diagnostics tables. To view IIS logs and custom
logs, browse to the corresponding blob containers in the same storage account.

Question
What should you do to deploy a cloud service into an existing virtual network?
Modify the cloud service package file (.cspkg file).
Modify the cloud service configuration file (.cscfg file).
Add an internal endpoint to the cloud service roles.
Add an instance input endpoint to instances of cloud service roles.
Add an input endpoint to the cloud service.

Lab: Implementing Azure Cloud Services

Scenario
You want to evaluate the capabilities of Azure Cloud Services to host A. Datum web applications. Your
development team has provided a simple cloud service project that you can use to test its functionality in
Azure. You want to show how staging and production slots can be used to simplify the deployment of
new versions of the cloud service. You also want to determine whether you can monitor the service to get
clear information on resource usage.
Objectives
At the end of this lab, you will be able to:
• Configure and deploy a cloud service to Azure.
• Deploy a cloud service for staging and enable Remote Desktop Protocol (RDP) access.
• Configure metrics and alerts to monitor the cloud service state.
User name: Student
Password: Pa55w.rd
Question: In the lab, you enabled RDP access and used the RDP client to connect to an
instance of a web role. Why would administrators connect to cloud service role instances
with RDP?
Question: You want to ensure you can identify the volume of network traffic your cloud
service has received over the last hour. Should you configure a monitoring metric or an alert?

In the module, you learned about:
• Planning, creating, and deploying Azure Cloud Services.
• Configuring cloud services by using configuration files or the Azure portal.
Review Question
Question: Your organization plans to develop a new multi-tier IIS-based application and
deploy it to Azure. The application must be able to scale each tier independently. You need
to minimize the ongoing maintenance of the operating system. You also want to be able to
choose arbitrary virtual machine sizes for each tier. In addition, the application must operate
within a virtual network to allow communication with IaaS virtual machines. What host
application model should you use?
9-1
Module 9
Implementing Azure Active Directory
Contents:
Module Overview 9-1
Lesson 1: Creating and managing Azure AD tenants 9-2
Lesson 2: Configuring application and resource access with Azure AD 9-16
Lesson 3: Overview of Azure AD Premium 9-23

Lab: Implementing Azure AD 9-30
Module Overview
Microsoft Azure Active Directory (Azure AD) is a cloud-based identity and access management solution.
By using Azure AD, you can provide secure access to sensitive services and data with multi-factor
authentication and single sign-on (SSO). This makes application access more convenient for the end users.
In this module, you will learn how to create an Azure AD tenant, assign a custom domain to it, integrate
applications with Azure AD, and use Azure AD Premium features. You will also implement Azure Role-
Based Access Control (RBAC) to users, groups, and applications at the right scope.
Objectives
• Create and manage Azure AD tenants.
• Configure SSO for cloud applications and resources, and implement RBAC for cloud resources.
• Explain the functionality of Azure AD Premium, and implement Azure Multi-Factor Authentication.
9-2 Implementing Azure Active Directory
Lesson 1
Creating and managing Azure AD tenants
Azure AD is the service in Azure that provides cloud-based identity and access management, in addition
to directory services. You can use Azure AD to provide secure access to cloud-based and on-premises
applications and services.
In this lesson, you will learn about the basic features of the Azure AD identity management and directory
services. The lesson starts by introducing these services in relation to Active Directory Domain Services
(AD DS) and comparing these two technologies.
Lesson Objectives
• Explain the role of Azure AD.

• Identify the similarities and differences between Active Directory Domain Services (AD DS) and
Azure AD.
• Manage users, groups, and devices by using the Azure portal and Microsoft Azure PowerShell.
• Explain how to manage multiple Azure AD tenants.

• Explain how to implement Azure AD Business-to-Business (B2B) and Azure AD Business-to-Consumer
(B2C) services.

module
the lab.
Active Directory as a component of Azure

Azure AD is a cloud-based identity and access
management service that provides SSO
functionality to thousands of Software as a Service
(SaaS) applications. Azure AD is, by design, highly
scalable and highly available. Organizations can
use Azure AD to improve employee productivity,
streamline IT processes, and improve security
when adopting cloud services or integrating their
on-premises environments with the cloud.
Employees can access online applications without
having to maintain multiple user accounts.
Azure AD supports multi-factor authentication for
both on-premises and cloud-resident resources. Role-Based Access Control (RBAC), self-service password
and group management, and device registration provide additional capabilities that play a significant role
in enterprise identity management solutions.
Many applications built on different platforms such as .Net, Java, Node.js, and PHP can use industry
standard protocols such as Security Assertion Markup Language (SAML) 2.0, Web Services Federation
(WS-Federation), and OpenID Connect to integrate with the identity management provided by Azure AD.
With the support of Open Authorization (OAuth 2.0), developers can develop mobile and web service
applications that leverage Azure AD for cloud authentication and access management. They can also take
advantage of the support for Azure AD across a number of PaaS services, such as Azure SQL Database or
Azure Automation.
Organizations that use AD DS can synchronize users and groups from their Active Directory domains with
Azure AD to enable a SSO experience for their users accessing both on-premises and cloud-based
applications.
Overview of Azure AD
Azure AD is a Microsoft managed, cloud-based,
PaaS identity and access management solution.
You can use it to provide secure access for
organizations and individuals to variety of on-
premises and cloud-resident services, including
Azure, Office 365, Microsoft Dynamics CRM
Online, and Microsoft Intune. You can use
Azure AD to:
• Configure access to applications.

• Configure SSO to cloud-based SaaS
applications.
• Provision and manage users and groups.
• Enable federation between organizations.
• Provide an identity management solution.
• Implement identity protection.

• Configure Multi-Factor Authentication.

• Integrate with existing on-premises Active Directory deployments.
As a cloud-based service, Azure AD offers multitenancy and scalability:
• Multitenancy. Azure AD is multitenant by design and it specifically ensures isolation between its
individual directory instances. The term tenant in this context typically represents a company or
organization that signed up for a subscription to a Microsoft cloud-based service such as Office 365,
Windows Intune, or Microsoft Azure, each of which leverages Azure AD. However, from a technical
standpoint, the term tenant represents an individual Azure AD instance. As an Azure customer, you
can create multiple Azure AD tenants. This is useful if you want to test Azure AD functionality in one
without affecting the others. Each Azure AD tenant serves as a security boundary and a container for
Azure AD objects such as users, groups, and applications.
• Scalability. Azure AD is the world’s largest multitenant directory, hosting over a million directory
services instances, with billions of authentication requests per week.
Azure AD editions
To meet a wide range of customers' needs, Azure AD is available in three main editions:
• The Free edition provides user and group management, device registration, self-service password
change for cloud users, and synchronization with on-premises directories. It is limited to 10
applications per user configured for SSO and 500,000 objects.
• The Basic edition extends the free edition’s capabilities by combining group-based access
management, self-service password reset for cloud users, and support for application proxy.
Additionally, this edition offers a 99.9% uptime service level agreement (SLA). The Basic edition does
not impose limits on the number of directory objects, but has a limit of 10 apps per user configured
for SSO, just as the Free edition does.
• The Premium edition is designed to accommodate organizations with more demanding identity and
access management needs. It supports dynamic groups and self-service group management, self-
service password reset with password writeback for on-premises users, the Cloud App Discovery
feature of Azure AD, Azure Active Directory Connect Health, and advanced reports for security and
usage information. It offers support for an unlimited number of objects and unlimited number of
apps per user configured for SSO.
Note: Azure AD Premium is available in two tiers – P1 and P2. Both tiers include all the
features described above. Azure AD Premium P2 however, offers additional Identity Protection
and Privileged Identity Management features.
Additional Reading: For a detailed comparison between editions of Azure AD, refer to:
“Azure Active Directory features and capabilities” at: https://aka.ms/einkzq
AD DS
Active Directory Domain Services (AD DS) is a directory service and an identity management solution.
AD DS forms the foundation of enterprise networks that run Windows operating systems. As a directory
service, AD DS hosts a distributed database, residing on servers referred to as domain controllers and
storing identity data about users, computers, and applications.
Most commonly, access to the database requires successful authentication. Authentication requires the
user, computer, or application that is attempting to authenticate to provide credentials to the
authenticating domain controller. The domain controller then grants that user, computer, or application a
token that represents its status and privileges to other domain members. Through this authorization
process, the token provides access to resources such as file shares, applications, or databases that domain
computers are hosting. The basis of authorization is the implicit trust that each domain-member
computer maintains with domain controllers. You establish this trust by joining computers to the domain,
which adds an account that represents your computer to the AD DS database.
A range of Windows Server roles, such as Active Directory Certificate Services (AD CS), Active Directory
Rights Management Services (AD RMS), and Active Directory Federation Services (AD FS), leverage the
same functionality. The AD DS database also stores management data, which is critical for administering
user and computer settings through Group Policy processing.
When comparing AD DS with Azure AD, it is important to note the following characteristics of AD DS:
• AD DS is by design single-tenant.
• AD DS is a directory service with a hierarchical X.500-based structure.
• AD DS uses Domain Name System (DNS) for locating services such as domain controllers.
• AD DS relies on protocols such as Lightweight Directory Access Protocol (LDAP) for directory lookups
and Kerberos for authentication, which were designed to operate within secure, isolated networks.
• AD DS facilitate Group Policy Objects (GPOs)–based management.
• AD DS supports users, groups, and AD-aware applications.

• AD DS supports computer objects, representing computers that join an Active Directory domain.
• AD DS supports multi-domain forests.

You can deploy an AD DS domain controller on an Azure VM to provide the same functionality as an on-
premises AD DS. Such deployment typically requires one or more additional Azure data disks because you
should not use the C drive for storing AD DS database, logs, and SYSVOL. You must set the Host Cache
Preference setting for these disks to None.
Note: It is important to understand that using Azure AD is not the same as deploying an
Active Directory domain controller on an Azure VM.
Azure AD
Although Azure AD is somewhat similar to AD DS, there are some fundamental differences between them.
The following are some of the characteristics that make Azure AD distinct:
• Azure AD is multitenant by design.
• Azure AD object hierarchy is flat, with no support for custom containers or organizational units (OUs).
• Azure AD implementation does not rely on domain controllers.
• Azure AD supports protocols that facilitate secure communication over the internet.
• Azure AD does not support Kerberos authentication; instead, it uses protocols such as SAML,
WS-Federation, and OpenID Connect for authentication (and OAuth for authorization).
• Azure AD does not support LDAP; instead, it relies on Graph application programming interface (API)
for directory lookups.
• Azure AD is primarily an identity and access management solution. It does not provide management
capabilities equivalent to those in AD DS. For example, it does not support GPOs, although it
integrates with device management products such as Microsoft Intune.
• AD DS supports users, groups, and web-based applications.

Note: When you register a new application in an Azure AD tenant, besides creating an
application object which represents an actual software application, you also automatically
generate a security principal object. Security principal provides the security and authentication
context for the corresponding application. This allows you, for example, to grant permission to
this application through RBAC, as you would grant permissions to Azure AD users or groups.
If you register the same application in another Azure AD tenant, that tenant would contain only
the corresponding security principal. The application object exists only in the first Azure AD
tenant where you registered the application.
• Azure AD supports device objects representing devices that register or join an Azure AD tenant.
• Azure AD offers federation services, and many third-party services (such as Facebook) are federated
with and trust Azure AD. You can also federate AD DS with Azure AD. However, you cannot create
Azure AD forests.
Custom domain names

Each Azure AD tenant is assigned the default DNS domain name, consisting of a unique prefix, followed
by the onmicrosoft.com suffix. The prefix is either derived from the name of the Microsoft account you
use to create an Azure subscription or provided explicitly when you create an Azure AD tenant. It is
common to add at least one custom domain name to the same Azure AD tenant. This name utilizes the
DNS domain namespace that the tenant’s company or organization owns.
To add a custom domain name to your Azure AD tenant, you can use:
• A Microsoft cloud service portal, such as the Azure portal, Office 365 admin center, or Microsoft
Intune admin console.
• Azure Active Directory PowerShell.

To add a custom domain name to an Azure AD tenant by using one of the Microsoft cloud service portals,
1. In the portal, specify the custom domain name.
2. In the portal, note the DNS records that you need to create at your domain registrar or DNS-hosting
provider.
3. Sign in to your domain registrar or DNS-hosting provider, and create the DNS records.
4. Back in the portal, verify that the Microsoft cloud service can resolve the newly created DNS records
for the custom domain.
Before you can verify a custom domain, the domain name must already be registered with a domain
name registrar, and you must have appropriate sign-in credentials to be able to create DNS records for
this domain. You can create either TXT records, which are preferable, or MX (mail exchange) records, if
your DNS provider does not support TXT records.
The following is an example of a TXT record used for custom domain verification:
Alias or Host name: @
Destination or Points to Address: MS=ms96744744
TTL: 1 hour
After verification, the administrator can designate the newly verified domain to be the primary domain for
the Azure AD tenant. For example, you can replace adatum12345.onmicrosoft.com with adatum.com.
Managing Azure AD users, groups, and devices

You can manage Azure AD users, groups, and
devices by using the Azure portal, the Azure
classic portal, Azure Active Directory PowerShell,
Microsoft Intune admin console, or Office 365
admin center. There are three basic ways to create
users, groups, and devices in Azure AD:
• As cloud identities defined directly in the

Azure AD tenant.
• As directory-synchronized identities
generated through synchronization between
on-premises Active Directory and an Azure
AD tenant. This method requires installing
and configuring specialized software that synchronizes directory objects between the two directories.
You also have the option of creating guest users, which represent users defined in other Azure AD tenants
or other, federated identity providers.
Note: If you created an Azure subscription by using a Microsoft account, then the
corresponding user account you see in the Default Directory Azure AD tenant associated with
your subscription is a guest user. The actual user account resides in the Microsoft consumer
identity store. It becomes available in your Azure AD tenant through a federation relationship,
where the tenant trusts the Microsoft consumer identity provider to authenticate the guest user.
The Azure portal provides an intuitive web interface for creating and managing users, groups, and
devices.
Creating users with the Azure portal

Using the Azure portal is the most straightforward method for creating individual user accounts. To create
a user by using the Azure portal, perform the following steps:
1. In the Azure portal, in the hub menu, click Azure Active Directory.
2. Click the Users and groups tile.
3. On the Users and groups blade, click All users.
4. On the All users blade, click + New user.
5. On the User blade, enter the following user information:
o Name: the display name
o User name: unique name within the default domain name or a custom domain name associated
with the current Azure AD tenant that the user will provide when signing in
o Profile: first name, last name, job title, and department
o Properties: Source of authority (Azure Active Directory)

o Groups: groups of which the user should be a member
o Directory role: User, Global administrator, or Limited administrator. If you choose Limited
administrators, you will have the option to delegate any of the directory roles, including
Password administrator, Service administrator, Billing administrator, Exchange administrator,
Skype for Business administrator, User administrator, SharePoint administrator, Compliance
administrator, Security reader, Security administrator, Privileged role administrator, Intune Service
administrator, Guest inviter, and Conditional Access Administrator.
6. To display the temporary, automatically generated password, select the Show Password check box.
7. Click Create to finalize the user creation.
Note: After creating a user via the Azure portal, make sure to assign the usage location
property available on the User profile blade. You must set this property if you want to assign a
license for a paid edition of Azure AD to that user.
Creating guest users with the Azure portal

To create a guest user by using the Azure portal, perform the following steps:
1. In the Azure portal, in the hub menu, click Azure Active Directory.
2. Click the Users and groups tile.
3. On the Users and groups blade, click All users.
4. On the All users blade, click + New guest user.

5. On the Invite a guest blade, enter the following user information:
o Enter email address of the external user: user name (in the username@FQDN format)
representing a user in another Azure AD tenant or a different identity provider.
o Include a personal message with the invitation: a custom message that the guest user will receive
as part of the guest user provisioning process.
6. Click Invite to finalize the guest user creation.

As the result, the guest user receives an invitation email. The email includes a link that directs the guest
user to its identity provider. Once the authentication completes successfully, the user is redirected to a
web portal, which provides access to Azure AD–registered applications that you make available to the
guest user.
Note: The web portal to which the user is redirected is the Azure AD Access Panel. You will
learn about it in lesson 3 of this module.
Additional Reading: You can reach Azure AD Access Panel directly by browsing to:
https://myapps.microsoft.com
Managing devices in the Azure portal

Users can join their Windows 10 devices to Azure AD either during the first-run experience or from the
system settings. If users use their Azure AD credentials to sign in to Windows 10, they can benefit from
SSO functionality when accessing Office 365 and any other applications that use Azure AD for
authentication, including the Azure AD Access Panel.
You can disable the ability to join devices to Azure AD or restrict it to specific Azure AD users or groups.
You can also limit the maximum number of devices per user and enforce multi-factor authentication when
joining devices in Azure AD. These options are available from the Users and groups – Device settings
blade in the Azure portal.
After a user registers a device in Azure AD, you can control its usage. For example, if you determine that
the device has been lost or compromised, you can delete its Azure AD object or block its ability to
authenticate. If Microsoft Intune or another mobile device management (MDM) system manages the
device, you can implement additional capabilities such as policy-based configuration and software
deployment.
Managing users, groups, and devices by using Windows PowerShell

You can also manage users, groups, and devices by using Microsoft Azure Active Directory PowerShell
module version 2. The module is available on Windows 7 or newer and Windows Server 2008 R2 or newer
operating systems, with the default versions of Microsoft .NET Framework and Windows PowerShell. You
can find it in the PowerShell Gallery at https://aka.ms/Ofa6p0. To install it, you can leverage the
functionality available via the PowerShellGet module, which allows you to run the following command:
Install-Module -Name AzureAD
The installation requires the Windows PowerShell NuGet provider, which you can install separately by
running the following command:
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Alternatively, you can allow PowerShellGet to include it in the installation of the module automatically.
Once you have installed the module, you can connect to Azure AD by running the following command
from the Windows PowerShell prompt:
$AzureAdCred = Get-Credential
Connect-AzureAD -Credential $AzureAdCred
The first cmdlet will prompt you for the credentials of an Azure AD user. To proceed, specify an account
that is a member of the Global administrator role (or another role that grants permissions sufficient to
create user and group accounts).
To create a new user account and force the user to change the temporary password during the first sign-
in, run the following sequence of commands:
$passwordProfile = "" | Select-Object Password,ForceChangePasswordNextLogin

$passwordProfile.ForceChangePasswordNextLogin = $true
$passwordProfile.Password = 'Pa55w.rd1234'
New-AzureADUser -UserPrincipalName 'mledford@adatum.com'`
-DisplayName 'Mario Ledford' `
-GivenName 'Mario' `
-Surname 'Ledford' `
-PasswordProfile $passwordProfile `
-UsageLocation 'US' `
-AccountEnabled $true `
-MailNickName 'mledford'
To create a security group, run the following cmdlet:
New-AzureADGroup -Description 'Adatum Azure Team Users' `

-DisplayName 'Azure Team' `
-MailEnabled $false `
-MailNickName 'AzureTeam' `
-SecurityEnabled $true
To identify all devices registered in Azure AD along with their users, run the following cmdlet:
Get-AzureADDevice –All $true | Get-AzureADDeviceRegisteredUser
To enable or disable registered devices, run the following cmdlet:
Get-AzureADDevice –All $true | Set-AzureADDevice –AccountEnabled $false
To remove a device from Azure AD management, run the following cmdlet:
Remove-AzureADDevice -DeviceId a7892334-730b-4d49-bd13-54c2a4928009
You can also manage users, groups, and devices by using Microsoft Azure Active Directory module for
Windows PowerShell.
Additional Reading: You can download Microsoft Azure Active Directory module for
Windows PowerShell from the Azure Active Directory Connection Home at:
https://aka.ms/Cqkq8t
To connect to Azure AD, at the Microsoft Azure Active Directory module for Windows PowerShell prompt,
type the following command, and then press Enter:
Connect-MsolService
The first cmdlet will prompt you for the credentials of an Azure AD user. To proceed, specify an account
that is a member of the Global administrator role (or another role that grants permissions sufficient to
create user and group accounts).
To create a user account by using Microsoft Azure Active Directory Module for Windows PowerShell, run
the following cmdlet:
New-MsolUser -UserPrincipalName mledford@adatum.com -DisplayName "Mario Ledford" -

FirstName "Mario" -LastName "Ledford" -Password 'Pa55w.rd123' -ForceChangePassword $false
-UsageLocation "US"
To create a group by using Microsoft Azure Active Directory Module for Windows PowerShell commands,
run the following cmdlet:
New-MsolGroup -DisplayName "Azure team" -Description "Adatum Azure team users"
Microsoft Azure Active Directory module for Windows PowerShell also provides cmdlets for managing
devices registered in Azure AD. For example, to query all the devices that a specific user owns, run the
following cmdlet:
Get-MsolDevice –RegisteredOwnerUpn 'mledford@adatum.com’

Note: At the time of authoring this course, Microsoft Azure Active Directory PowerShell
module version 2 does not include a cmdlet that would allow you to identify devices associated
with a specific user. You can, however, use a combination of its existing cmdlets (e.g. Get-
AzureADDevice and Get-AzureADDeviceRegisteredUser) and parse their output to obtain this
information.
To enable or disable registered devices, run the following cmdlet:
Enable-MsolDevice/Disable-MsolDevice
To remove a device from Azure AD management, run the following cmdlet:
Remove-MsolDevice -DeviceId a7892334-730b-4d49-bd13-54c2a4928009
Creating users by using bulk import

To create multiple Azure AD users in bulk, you can use Azure PowerShell scripting or import a comma-
separated value file (CSV file) containing account information. For example, you can export a CSV file from
an existing on-premises Active Directory instance. To perform a bulk import, you first must collect user
information. The following example illustrates a sample collection of user details that you could use to test
this functionality.
Display
UserName FirstName LastName JobTitle Department Country
Name
AnneW@adatum.com Anne Wallace Anne President Management United

Wallace States
FabriceC@adatum.com Fabrice Canel Fabrice Attorney Legal United

Canel States
GarretV@adatum.com Garret Vargas Garret Operations Operations United

Vargas States
Given this data set, you would need to create a CSV file in the following format:
UserName,FirstName,LastName,DisplayName,JobTitle,Department,Country
AnneW@adatum.com,Anne,Wallace,Anne Wallace,President,Management,United States
FabriceC@adatum.com,Fabrice,Canel,Fabrice Canel,Attorney,Legal,United States
GarretV@adatum.com,Garret,Vargas,Garret Vargas,Operations,Operations,United States
You could then use Microsoft Azure Active Directory Module for Windows PowerShell commands to
process this CSV file and create the user accounts as shown below:
$users = Import-Csv C:\Users.csv

$users | ForEach-Object {
New-MsolUser -UserPrincipalName $_.UserName `
-FirstName $_.FirstName `
-LastName $_.LastName `
-DisplayName $_.DisplayName `
-Title $_.JobTitle `
-Department $_.Department `
-Country $_.Country
}
Note: You can use the same approach when using the New-AzureADUser cmdlet.
Managing Azure AD tenants

By default, you automatically get an Azure AD
tenant when you sign up for an Azure, Office 365,
Microsoft Dynamics CRM Online, or Microsoft
Intune subscription. That tenant authenticates
users defined in its directory. You can also create
additional tenants as needed.
Note: The terms tenant and directory in the

context of Azure AD are equivalent and
interchangeable.
Note: At any given time, an Azure subscription must be associated with one, and only one,
Azure AD tenant. This association allows you to grant permissions to resources in the Azure
subscription (via RBAC) to users, groups, and security principals that exist in that particular Azure
AD tenant. Note that you can associate the same Azure AD tenant with multiple Azure
subscriptions. This allows you to use the same users, groups, and security principals to access and
manage resources across multiple Azure subscriptions.
Support for multiple Azure AD tenants facilitates the following scenarios:
• Creating separate directories for testing or other non-production purposes.

• Managing multiple Azure AD tenants by using the same user credentials—as long as the
corresponding user account is a Global administrator in each of them.
• Adding existing users as guests to multiple Azure AD tenants, eliminating the need to maintain
multiple credentials for the same user.
Adding a new Azure AD tenant

To add an Azure AD teanant, sign in to the Azure portal, click + New, click Security + Identity, and click
Azure Active Directory. On the Create Directory blade, specify the following settings and click Create:
• Organization name: any custom name you want to assign to the new tenant
• Initial domain name: a unique, valid DNS host name in the .onmicrosoft.com namespace
• Country or region: the geopolitical area where the Azure AD tenant will reside
Changing the association between an Azure subscription and an Azure AD tenant

At the time of authoring of this content, in order to change the association between an Azure subscription
and an Azure AD tenant, you have to sign in as the Service Administrator of the subscription to the Azure
classic portal. Your account needs to be also a Global administrator in both the current and the target
Azure AD tenant.
Once you sign in to the Azure classic portal, in the navigation bar on the left hand side of the portal, click
SETTINGS. On the settings page, on the SUBSCRIPTIONS tab, select the Azure subscription, click EDIT
DIRECTORY. In the Change the associated directory window, select the target Azure AD tenant and
click Next. On the Confirm directory mapping note any Co-administrators that might be affected by the
change and click OK confirm.
Deleting an Azure AD tenant

By using a guest user account with the Global administrator role, you can delete an Azure AD tenant if the
following conditions are met:
• You deleted all users except the guest account you are using.
• You deleted all registered applications.
• The directory is not associated with any of the cloud services such as Azure, Office 365, or Azure AD
Premium.
• No multi-factor authentication providers are linked to the directory.
To delete an Azure AD directory from the Azure portal, navigate to its blade and click Delete directory.
Review the list of requirements, verify that all of them are satisfied, and click Delete.
Implementing Azure AD B2B and Azure AD B2C
Azure AD B2B
Azure AD Business-to-Business (B2B) is a
collaboration functionality available in any Azure
AD tenant that is intended for sharing resources
with a partner organization. In a typical Azure AD
B2B scenario, the tenant contains two types of
user accounts:
1. User accounts of employees of the host

organization that owns the resources and the
tenant.
2. Guest accounts representing user accounts in the partner organization.
Partner user accounts can be either work or school accounts from the partner’s organization Azure AD
tenant. They can also originate from any identity provider, including social identities.
Azure AD B2B uses an invitation model to provide partner users with access to your applications. This is
the same mechanism that we described earlier, in the “Creating guest users with the Azure portal” section
of the “Managing Azure AD users, groups, and devices” topic of this lesson.
Azure AD B2B is highly customizable and offers a range of enhancements, including the following:
1. Support for SSO to all Azure AD–connected apps registered in the tenant of the host organization,
including Office 365, non-Microsoft SaaS apps, and on-premises apps.
2. Multi-factor authentication to hosted apps, on the tenant, app, or individual user level.
3. Support for delegation, allowing designated information workers to invite partner users.
4. Development of custom sign-in pages and invitation emails for partner users.
5. Bulk partner user provisioning by using CSV file uploads.
Additional Reading: For more information about Azure AD B2B, refer to: “What is Azure AD
B2B collaboration?” at: https://aka.ms/nlxzsb
Azure AD B2C
Azure AD Business-to-Consumer (B2C) is a dedicated Azure AD tenant intended for providing individual,
institutional, and organizational customers with access to any publicly accessible cloud and on-premises
apps. In a typical Azure AD B2C scenario, the tenant contains customer user accounts only. These accounts
can be defined directly in the tenant or can originate from any identity provider, including social
identities.
Note: Azure B2C is a distinct product offering, separate from the Azure AD tenant that is
provisioned as part of your Azure subscription. Support for federating an Azure B2C tenant with
an Azure AD tenant is in preview at the time of authoring this content. This support would allow
Azure AD users to access Azure B2C applications.
Azure AD B2C offers Identity as a Service (IDaaS) for your applications by supporting two industry
standard protocols, OpenID Connect and OAuth 2.0. Azure AD B2C eliminates the requirements for
developers to write a code for identity management and for storing identities in on-premises databases or
systems. It simplifies and standardizes consumer identity management by allowing your consumers to sign
up for and sign in to your applications by using their social accounts. These accounts can be from identity
providers such as Facebook, Google, Amazon, LinkedIn, and Microsoft account. A number of other
identity providers, including Twitter, WeChat, Weibo, and QQ, are in preview at the time of authoring this
content. Users can create their accounts directly in the Azure B2C tenant.
To start using Azure AD B2C, you must create a new tenant by performing the following steps:

2. In the hub menu, click New. On the New blade, in the search text box, type Azure Active Directory
B2C, and then press Enter.
3. On the Azure Active Directory B2C blade, click Create.

4. On the Create new B2C Tenant or Link to existing Tenant blade, select the first of the following
two options:
o Create a new Azure AD B2C Tenant
o Link an existing Azure AD B2C Tenant to my Azure subscription
5. On the Azure AD B2C Create Tenant blade, specify the following, and then click Create:
o Organization name: any custom name you want to assign to the new tenant
o Initial domain name: a unique, valid DNS host name in the .onmicrosoft.com namespace
o Country or region: the geopolitical area where the Azure AD tenant will reside
6. Once the provisioning completes, click the Click here, to manage your new directory link. This will
open the Azure AD B2C blade in the Azure portal.
Note: To use a B2C tenant in a production environment, you must link it to an Azure
subscription for communication, billing, and support purposes. To accomplish this, repeat the
procedure described above, but select the second of the two options listed in step 4.
You must register applications that are integrated with Azure AD B2C in your B2C directory. You can
complete this registration in the Azure portal. During the registration process, each application gets a
unique Application ID and Redirect Uniform Resource Identifier (URI) or Package Identifier. Currently, B2C
supports native apps, mobile apps, web apps, and web APIs that are using the App Model 2.0 registration
model. Developers use Application ID and Redirect URI to configure authentication for their applications.
To register an application in an Azure AD B2C tenant, perform the following steps:
1. On the Azure AD B2C blade, click Applications.
2. Click +Add.
3. On the New application blade, type the name of the application:
o If you are registering a web application, toggle the Include web app/web API switch to Yes.
Allow or disallow implicit flow by using another switch and type the value as Reply URL. This
designates an endpoint where Azure AD B2C will send authentication tokens. Optionally, provide
an App ID URI. This value serves as a unique identifier of the web API.
o If you are deploying a native client app, such as a mobile or a desktop app, toggle the Include
native client switch to Yes. Copy the autogenerated Redirect URI and provide a Custom
Redirect URI.
4. Click Create to register your application.
5. On the Azure AD B2C – Applications blade, click the application that you just created, and copy the
globally unique Application ID that your developers will need to reference in the application code.
6. If you want to facilitate secure communication between the application and the web API that Azure
AD B2C provides, generate application keys from the application Keys blade.
The next step in providing access to applications available via Azure AD B2C is to define policies. Policies
define consumer experience during actions related to identity management that AD B2C provides, such as
sign-up, sign-in, or password resets. For example, policies can restrict identity providers, specify the
information that prospective users must provide when signing up, or enforce the use of multi-factor
authentication. You can define multiple policies and apply each of them to any application registered with
the tenant. You can accomplish this task directly from the policy blade in the Azure portal.
Additional Reading: For more information about Azure AD B2C, refer to: “Azure AD B2C:
Focus on your app, let us worry about sign-up and sign-in” at: https://aka.ms/nlxzsb
Demonstration: Managing Azure AD users, groups, and devices

In this demonstration, you will learn how to:
• Create a new directory called Adatum.
• Create a new Global Administrator user account.
• Join a Windows 10–based computer to Azure AD.
Question: What are the similarities between AD DS and Azure AD?
Question: Can you use Group Policy in Azure AD?

Lesson 2
Configuring application and resource access with
Azure AD
As the number of cloud-based applications grow, their management becomes increasingly challenging.
Administrators must ensure that they provide end users with secured application access. However, a focus
on security should not affect negatively users’ sign-in experience.
Azure AD addresses these challenges by allowing you to implement SSO for authenticating to cloud and
on-premises applications. Additionally, Azure AD allows you to restrict access to Azure-based resources
through RBAC.
Lesson Objectives
• Describe how to add publicly-accessible applications to Azure AD.
• Describe how to add on-premises applications to Azure AD.
• Describe how to configure access to Azure AD-integrated applications.

• Implement RBAC.
Adding publicly accessible applications to Azure AD
Azure Marketplace Azure AD apps

Azure Marketplace Azure AD apps support
integration with Azure AD. The integration offers
such features as Single Sign-On (SSO) and
automatic user provisioning. Examples of gallery
applications include Office 365, Dropbox for
Business, and Salesforce.
Additional Reading: To view all currently

available commercial Azure AD applications, go to
the Azure Marketplace at: http://aka.ms/Htfnef
and then click Azure Active Directory apps.
At the time of authoring of this course, more than 2,800 SaaS applications are integrated with Azure AD
for authentication and authorization. You can configure and manage applications from the Enterprise
Application blade of the Azure AD tenant in the Azure portal. To add an application from the gallery,
1. Sign in to the Azure portal with an account that has the Global administrator role.
2. Navigate to the blade of your Azure AD tenant.
3. Click Enterprise Applications.
4. On the Enterprise Application – All applications blade, click +Add.
5. On the Categories blade, click All or click the category in which you are interested.
6. On the Add an application blade, select the application which you want to add to your Azure AD
tenant.
7. Once you added the app, from the app blade, you will be able to assign app access to individual
Azure AD users or, with Basic and Premium Azure AD editions, groups.
8. From the app blade, you will be able also to configure the single sign-on settings for the app.
SaaS applications not listed in the gallery

If a web-based, publicly accessible application is not available via Azure Marketplace, you can still
integrate it with Azure AD if the SaaS application supports Azure AD authentication protocols or if the
application has an HTML-based sign-in page with a password SSO.
For SaaS applications that support SAML, WS-Federation, or OpenID Connect, authentication with Azure
AD is established by using a signing certificate that is generated by the Azure AD tenant. For SaaS
applications that feature HTML-based sign-in page, authentication is enabled by leveraging Azure AD
support for password-based SSO.
To add a SaaS application that is not listed in the gallery, perform the following steps:
1. Sign in to the Azure portal with the account that has the Global administrator role.

6. On the Add an application blade, select the application which you want to add to your Azure AD
tenant.
7. On the Enterprise Application blade, click Non-gallery application.
8. On the Add your own application blade, type the name you want to assign to your application. This
name will be visible to your users after you grant them access to the application.
9. Click Add.
10. From the Quick start blade of the application, configure its properties.
For SAML–based applications, authentication requires you to configure the following settings:
• Identifier. A unique identifier for the application for which SSO is being set up.
• Reply URL. The URL where the application expects to receive the authentication token.
Based on this information, Azure AD will generate a certificate and the following three URLs that need to
be configured with the SaaS application:
• Issuer URL. This is the value that appears as the Issuer inside the SAML token issued to the
application.
• Single Sign-On Service URL. This is the endpoint that is used for sign-in request.
• Single Sign-Out Service URL. This is the endpoint that is used for sign-out request.
Adding on-premises applications to Azure AD

Azure AD Application Proxy is a cloud service that
facilitates integration of on-premises, web
browser-based applications (such as SharePoint
sites, Outlook Web Access, and IIS-based
applications) with Azure AD. The Azure AD
Application Proxy relies on reverse-proxy
mechanism to provide access from internet to
HTTP and HTTPS endpoints within your internal
network.
To implement such access via Azure AD

Application Proxy, you must install a software-
based connector on an on-premises server with
direct access to the web application. The connector establishes a persistent, outbound connection to the
Application Proxy service over TCP ports 80 and 443.
Azure AD Application Proxy provides access to AD DS-based applications by using the following
procedure:
1. The user attempts to access the Azure AD Application Proxy-published application via a web browser
from a device outside the company perimeter network.
2. The Application Proxy redirects the user sign-in to Azure AD for authentication.
3. The user obtains the token from Azure AD and presents it to the Application Proxy, which retrieves
the user principal name (UPN) and security principal name (SPN).
4. The connector installed in the internal network retrieves the user attributes via the outbound
connection to the Application Proxy and requests a Kerberos ticket on behalf of the user from AD DS.
This process relies on Kerberos Constrained Delegation.
5. AD DS returns the Kerberos ticket to the connector.
6. The connector presents that ticket to the application.
7. The application verifies the access, and responds to the client request through the Application Proxy.
The Azure AD Application Proxy requires either Basic or Premium edition of Azure AD. You can enable it
from the Application proxy blade of the Azure AD tenant in the Azure portal. From the same blade, you
can download the connector software and install it on your on-premises computers. This install process
sets up two Windows services, Microsoft AAD Application Proxy Connector and Microsoft AAD
Application Connector Proxy Connector Updater.
To publish an internal application and make it accessible to users outside your private network, perform
the following steps:
1. Sign in to the Azure portal with the account that has the Global administrator role.
6. On the Add an application blade, select the application that you want to add to your Azure AD
tenant.
7. On the Enterprise Application blade, click On-premises applications.

8. On the Add your own on-premises application blade, configure Application proxy settings,
including:
o Specifying Internal Url for access to the application from inside your on-premises network.
o Specifying External Url for access to the application from internet.
o Setting Pre Authentication to either Azure Active Directory or Passthrough authentication.

o Disabling or enabling the Translate URLs in Headers and Translate URLs in Application Body
settings depending on whether the application requires the original host header in the request.
o Assigning Connector Group to isolate applications on per connector basis.
Configuring access to Azure AD–integrated applications

There are several ways to make Azure AD–
integrated applications available to end users. The
most common approach involves using the Access
Panel, which is a web-based portal accessible at:
https://myapps.microsoft.com.
A user must successfully authenticate to view the

portal interface. The portal interface contains the
applications tab, which automatically displays a
list of applications to which the user is entitled.
You manage this entitlement by assigning
applications to individual users or to groups of
users.
Users sign in to the Access Panel by providing their Azure AD credentials. To avoid additional
authentication prompts when launching applications from the panel, you should configure SSO.
SSO allows users to run Azure AD–registered applications without providing a user name and password if
they have already successfully authenticated. Such applications might include software as a service (SaaS)
applications available from the Azure AD application gallery and custom applications developed in-house,
which reside on-premises or are registered in Azure AD. SSO eliminates the need to provision and
maintain separate user accounts for each SaaS application. SaaS SSO also means that users do not have to
remember the credentials for each SaaS application.
SSO accomplishes this by leveraging one of two distinct abilities of Azure AD: Azure AD provides secure
storage of user credentials, and provides support for federated trusts with other cloud services and
identity providers. Several commercial applications with SSO capabilities, such as Microsoft Office 365,
Box, or Salesforce, are preconfigured for integration with Azure AD and published in its application
gallery.
You can use the following three mechanisms to implement application SSO support:
• Password-based SSO with Azure AD storing credentials for each user of a password-based SSO
application. When Azure AD administrators assign a password-based SSO app to an individual user,
they can enter app credentials on the user's behalf. Alternatively, users can enter and store credentials
themselves directly from the Access Panel. In either case, when accessing a password-based SSO app,
users first rely on their Azure AD credentials to authenticate to the Access Panel. Next, when they
open an app, Azure AD transparently extracts the corresponding app-specific stored credentials and
securely relays them to its provider within the browser's session.
• Azure AD SSO, with Azure AD leveraging federated trusts with providers of SSO applications. In this
case, an application provider relies on Azure AD to handle users’ authentication, and accepts an
Azure AD–generated authentication token when granting access to the application.
• Linked SSO, with Azure AD leveraging a federated trust between the application and an SSO provider,
established by using an existing security token service (STS) implementation such as AD FS. This is
similar to the second mechanism because it does not involve separate application credentials.
However, in this case, when users access the Access Panel application, your current SSO solution
handles their authentication requests.
Note: In each of these cases, Azure AD serves as a central point of managing application
authentication and authorization.
You can also use Azure AD SSO functionality to control access to on-premises applications or applications
developed in-house but deployed to Azure. The Azure portal facilitates both of these scenarios by
allowing you to create required application-related objects in Azure AD. On-premises applications require
additional configuration, which includes installing an on-premises application proxy connector and
enabling application proxy in Azure AD.
Besides providing access to applications, the Access Panel also allows users to edit their profile settings,
change their password, and provide information needed for password reset. Users can also edit multi-
factor authentication settings and view their account details such as their user ID, alternative email, and
phone numbers. In addition, if you implement self-service group management, delegated users will be
able to view and modify group membership from the groups tab within the Access Panel interface.
Internet Explorer 8 and newer versions, Chrome, and Firefox all support the Azure AD Access Panel. You
can also use it on browsers that support JavaScript and CSS. To do so, you must install the Access Panel
extension software for your browser. You will be prompted to install it the first time you attempt to start
an application via the Application Access Panel interface.
Implementing RBAC
RBAC enables fine-grained access management
for resources that exist in an Azure subscription.
This mechanism relies on predefined and custom-
defined roles to grant or deny users and groups
that reside in Azure AD permissions necessary to
conduct role-specific actions on a subscription,
resource group, or resource level.
Note: When assigning permissions via RBAC,

you have to choose users and groups from the
Azure AD tenant that is associated with your
subscription.
By using RBAC, you can implement delegated management of cloud resources. For example, you can
allow your development team to create their own virtual machines, but limit virtual networks to which
those machines can be connected.
RBAC built-in roles

RBAC has three basic built-in roles that apply to all resource types:
• Owner. This role provides full access to all the resources and can delegate access to others.
• Contributor. This role allows you to create and manage all types of resources, without the ability to
grant these resources access to users or groups.
• Reader. This role provides view-only access to existing Azure resources.

In addition, there is a large number of resource type-specific built-in RBAC roles with predefined
permissions that further narrow access to resources. Examples of built-in, resource type-specific roles
include virtual machine contributor or SQL database contributor.
Additional Reading: For the list of built-in roles, refer to: http://aka.ms/Cge87w
To configure RBAC, you can use the Azure portal, Azure PowerShell, and Azure CLI. Permissions granted
through RBAC are inherited from the parent scope by child scopes. This means that the RBAC-based
permissions you assign on the subscription level will apply to all of its resource groups and resources.
Similarly, the RBAC-based permissions you assign to a resource group will apply to all of its resource
Note: The Owner role at the subscription level has permissions to subscription resources that
are equivalent to permissions of the Service administrator. However, you still must be the Service
administrator or a Co-administrator in order to sign in to the Azure classic portal. In addition,
only the Service administrator have the ability to change the association between the Azure
subscription and an Azure AD tenant.
Azure RBAC allows you to manage permissions at the management plane of Azure resources, such as
creating a SQL database, However, you cannot use RBAC for delegating management of data plane
operations within Azure resources such as creating a table within a SQL database.
If predefined built-in roles do not meet your expectations, you can create custom roles by using Azure
PowerShell or Azure CLI. Custom roles you define get stored in the Azure AD tenant associated with your
subscription, allowing you to share them across multiple subscriptions.
Additional Reading: For more information regarding creating custom roles, refer to the list
of built-in roles at: https://aka.ms/Fivzy4
Managing RBAC by using the Azure portal

To manage RBAC by using the Azure portal, perform the following steps:
1. In the Azure portal, navigate to the Access control (IAM) blade of the resource, resource group, or
subscription to which you intend to grant permissions via RBAC.
2. Click + Add.
3. On the Add permissions blade, in the Role drop-down list, select the role that you want to assign.
4. In the Select text box, type full or partial name of the user, group, or service principal to which you
want to assign the role. Alternatively, you can pick one or more entries from the list of Azure AD
identities appearing below the text box.
5. Click Save to confirm the selection.

You can remove the permission by using a similar procedure, but you cannot remove inherited
permissions at the child level.
Manage RBAC by using Azure PowerShell

You can manage RBAC by using Azure PowerShell. Azure PowerShell includes the following cmdlets to
manage role assignments:
• Get-AzureRmRoleAssignment. Retrieves the roles assigned to a user.
• Get-AzureRmRoleDefinition. Lists the definition for a role.
• New-AzureRmRoleAssignment. Assigns a role assignment to a user or a group.

• Remove-AzureRmRoleAssignment. Removes a role assignment from a user or a group.
For example, the following command adds a user to the Reader role at the specified scope:
New-AzureRmRoleAssignment -UserPrincipalName user@somedomain.com -RoleDefinitionName

Reader -Scope /subscriptions/GUID/resourceGroups/ResourceGroupName
Manage RBAC by using Azure CLI

You can manage RBAC by using the Azure CLI. Azure CLI includes the following commands to manage
role assignments:
• az role assignment list. Retrieves the roles assigned to a user.
• az role show. Lists the definition for a role.
• az role assignment create. Assigns a role assignment to a user or a group.
• az role assignment delete. Removes a role assignment from a user or a group.
Demonstration: Integrating SaaS apps with Azure AD and configuring

RBAC
• Add a directory application and configure SSO.
• Implement RBAC.
Question: How can you centrally manage identities, and access to applications and resources
in the cloud?
Lesson 3
Overview of Azure AD Premium
Features, such as password write-back or group self-service management increase overall user
productivity and reduce administrative overhead for enterprises. These features and other, more advanced
capabilities such as enhanced auditing, reporting, monitoring, and multi-factor authentication for non-
privileged users require Azure AD Premium licensing.
Lesson Objectives
• Identify the features of Azure AD Premium.
• Describe the purpose of Azure Multi-Factor Authentication.
• Explain how to configure advanced Azure Multi-Factor Authentication settings.
• Explain the purpose of Azure AD Privileged Identity Management and Identity Protection
Introducing Azure AD Premium

The Azure AD Premium edition provides
additional functionality beyond the features
available in the Free and Basic editions. However,
this edition introduces additional licensing cost
per user. Microsoft provides a free trial that covers
100 user licenses that you can use to become
familiar with the full functionality of the Azure AD
Premium edition.
The following features are available with the

Azure AD Premium edition:
• Self-service group and application

management. This feature minimizes
administrative overhead by delegating permissions to create and manage Azure AD groups and to
provide access to Azure AD-registered applications. Users can create requests to join groups and
obtain access to apps. Delegated admins can approve requests, maintain group membership, and
assign users to applications.
• Dynamic groups. In addition to creating groups and assigning their members explicitly, you can also
create dynamic groups, in which membership changes occur automatically, according to the rules you
define. These rules contain Azure AD object attribute–based criteria, which determine whether a user
or a device should be a member of a particular group.
• Conditional access. With this feature, you can implement conditional access to your applications.
Conditions can include the following criteria:
o Group membership. The user must belong to a group you designate.
o Location. The user must reside in a specific location; for example, a trusted network.
o Device platform. The user must use a device running a specific operating system, such as iOS,
Android, Windows 10 Mobile, or Windows.
o Device status. The device must be compliant at the time when the user attempts access. For
example, you might want to ensure that the device is registered in Azure AD or enrolled into
your mobile device management solution.
o Risk policy. Azure AD Identity Protection determines the acceptable risk level associated with
users attempting access.
If a user or device does not meet the criteria you choose, you can block access or enforce multi-factor
authentication.
• Advanced security reports and alerts. You can monitor access to your cloud applications by viewing
detailed logs that show anomalies and inconsistent access patterns. Advanced reports are machine
learning based and help you improve access control and detect potential threats.
• Multi-Factor Authentication. Full Multi-Factor Authentication works with on-premises applications

(using VPN, RADIUS, and others), Azure, Office 365, Dynamics CRM Online, and third-party Azure AD
gallery applications. Multi-Factor Authentication is covered in more details later in this lesson.
• Microsoft Identity Manager (MIM) licensing. MIM integrates with Azure AD Premium to provide
hybrid identity solutions. MIM can seamlessly bridge multiple on-premises authentication stores such
as AD DS, LDAP, or Oracle with Azure AD. This provides consistent end user experience when
accessing on-premises LOB applications and SaaS solutions.
• Enterprise SLA of 99.9%. You are guaranteed 99.9% availability of the Azure AD Premium service. The
same SLA applies to Azure AD Basic.
• Password reset and account unlock with writeback. Users have the ability to unlock their on-premises
accounts and reset their passwords by leveraging Azure AD functionality.
• Cloud App Discovery. This feature allows you to discover cloud-based applications used by on-
premises users. It provides you with information about usage of cloud apps, including number of
users per app, number of web requests per app, and the time spent working with each app. Cloud
App Discovery uses software agents that must be installed on users' computers. You can deploy the
agents by using Group Policy deployment or Microsoft System Center Configuration Manager. Agents
monitor cloud app access and then send collected data to the Cloud App Discovery service by using
an encrypted channel. You can view reports based on this data in the Azure portal.
• Azure AD Connect Health. You can use this tool to gain insight into operational aspects of Azure AD
Connect, which implements directory synchronization between AD DS and Azure AD. It collects alerts,
performance counters, and usage patterns, and presents the collected data in the Azure portal. You
will learn more about Azure AD Connect in module 10 of this course.
• Azure AD Identity Protection and Privileged Identity Management (PIM). This functionality offers
enhanced control and monitoring of Azure AD privileged users. Identity Protection and Privileged
identity Management are covered in more details later in this lesson.
• Windows 10 Azure AD Join related features. The features in this category include support for auto-
enrollment into a Mobile Device Management solution, such as Microsoft Intune, self-service
BitLocker recovery, or Enterprise State Roaming.
Azure Multi-Factor Authentication

Azure Multi-Factor Authentication adds an
additional security layer in the authentication
process by requiring more than one method of
authentication to identify user identity. Usernames
and passwords are still required to sign in to
access data and applications, but an additional
access method can be added as a second factor of
authentication. Multi-factor authentication
combines something that you know, such as a
password or a PIN, with something that you have,
such as your phone or a token, and/or something
that you are (biometric technologies).
You can implement Azure Multi-Factor Authentication in several ways, based on users’ demands and the
level of additional security that they need. From the user experience standpoint, your options include:
• You can use a mobile app to provide one-time passwords or to receive push notifications from the
application.
• You can authenticate via a phone call.

• You can authenticate via a text message, which is very similar to the mobile app authentication
method, but push notifications or authentication codes are delivered via text messages.
• You can authenticate using a third-party OAuth token.
Depending on your licensing arrangements and the services your users access, you have the following
options to implement Azure Multi-Factor Authentication when authenticating against Azure AD:
• Complementary Multi-Factor Authentication for administrators. The Global Administrator accounts

can be protected with multi-factor authentication free of charge.
• Multi-factor authentication included in Azure AD Premium, Azure MFA, or Enterprise Mobility +

Security (EMS). These offers cover the MFA functionality for every licensed user. You simply have to
assign a license to a user and configure the corresponding MFA settings.
• Azure Multi-Factor Authentication Provider. This allows you to extend the multi-factor authentication
functionality to non-administrators without purchasing Azure AD Premium, Azure MFA, or EMS
licenses. The MFA-related charges become part of the Azure subscription billing. You have the choice
of per-authentication or per-user provider, which affects the pricing model. The first one of them is
more beneficial if you have a larger number of users who authenticate via MFA only occasionally. The
second of them will be more cost-effective if there are few users who use MFA frequently.
• A subset of the Azure Multi-Factor Authentication functionality is included in Office 365. Multi-factor
authentication for Office 365 does not incur additional cost besides an Office 365 subscription license.
However, this works only with Office 365 applications.
Note: Only the second and the third of these options offer a number of advanced MFA
features. You will learn more about these features in the next topic of this lesson.
Another consideration when choosing the MFA approach is the location of user accounts and resources
you want to protect (on-premises or in the cloud). Based on this consideration, you can:
• Deploy Multi-factor authentication in the cloud. This is used mostly if the main goal is to secure
access to first-party Microsoft apps, SaaS apps from the Azure Marketplace, and applications
published through Azure AD Application Proxy. This option is viable as long as user accounts are
available in Azure AD. It is not relevant whether they were created in Azure AD directly or they
represent synchronized or federated AD DS users.
• Deploy Multi-factor authentication on-premises. This option is applicable when user accounts reside
in AD DS, including scenarios where the user accounts are federated with Azure AD. From the
resource standpoint, the intention is to protect remote access solutions, such as VPN or Remote
Desktop Gateway. In addition, this approach is applicable to IIS applications not published through
Azure AD App Proxy.
The implementation details depend on the version of the operating system hosting the AD FS role. With
Windows Server 2012 R2 or older, you need to install the Multi-Factor Authentication server and
configure it with an on-premises Active Directory. With Windows Server 2016, you can leverage the Azure
MFA adapter, built into the operating system.
Additional Reading: For more information on configuring MFA with Windows Server 2016-
based AD FS, refer to: “Configure AD FS 2016 and Azure MFA” at: https://aka.ms/xxj3y4
Additional Reading: For detailed comparison between these options refer to:
https://aka.ms/Cmtwvs
Exploring advanced Multi-Factor Authentication settings

Azure MFA included in Azure AD Premium,
Azure MFA, or Enterprise Mobility + Security
(EMS) and implemented via Azure Multi-Factor
Authentication Provider offers a number of the
following advanced features:
Fraud Alert
The Fraud Alert feature allows users to report
fraudulent attempts to sign in by using their
credentials. If a user receives an unexpected multi-
factor authentication request, the user can
respond with the fraud alert code (0# by default)
to report an attempt to gain unauthorized access.
The fraud alert automatically blocks the authentication request. You can also enable the option to block
the user's account, so that subsequent authentication attempts are automatically denied. Additionally, it is
also possible to configure email notifications to a custom email address, facilitating notifications to
administrative or security teams. After appropriate remediation action has been taken, including changing
the user's password, an administrator can then unblock the user's account.
One-Time Bypass
One-Time Bypass is a setting that allows a user to sign in temporarily without using Multi-Factor
Authentication. The bypass expires after the specified number of seconds. This can be useful if a user
needs to use an Azure MFA protected resource or application, but is not able to access a phone for text
messaging or automated calls, or the Multi-Factor Authentication app. The default one-time bypass
period is five minutes.
Custom Voice Messages

Custom Voice Messages allow administrators to customize the messages that Multi-Factor Authentication
process uses during automated voice calls to an office phone. This replaces standard recordings that are
supplied with Multi-Factor Authentication.
Trusted IPs
Trusted IP addresses allow administrators to bypass Multi-Factor Authentication for users who sign in
from a specific location, such as the company’s local intranet. You configure this option by specifying a
range of IP addresses corresponding to this location. In federated scenarios, you have the option of using
the All Federated Users instead.
App Passwords
App Passwords allow users that have been enabled for multi-factor authentication to use non-browser
clients that do not support modern authentication to access Azure AD protected apps or resources.
Examples of such clients include, for example, Outlook 2010.
Remember Multi-Factor Authentication for devices that users trust

The Remember Multi-Factor Authentication for devices that users trust setting allows users to suspend
enforcement of Multi-Factor Authentication for a defined period of time on a specific device. This requires
at least one successful authentication on that device. The default period of time is 14 days but you can
extend it to 60 days.
In addition to the above settings, there are some user-specific MFA settings that enhance security in case
of a stolen or lost device:
Require selected users to provide contact methods again

This setting will require users to complete the MFA registration process. This automatically invalidates the
current Remember Multi-Factor Authentication for devices that users trust and One-time bypass options.
Delete all existing app passwords generated by the selected users

This setting will invalidate existing app password for non-browser applications which do not support
modern authentication.
Restore multi-factor authentication on all remembered devices

In case a user loses a device configured with the Remember Multi-Factor Authentication for devices that
users trust, this setting reinstates Multi-Factor Authentication for that device.
Additional Reading: For more information regarding advanced MFA settings, refer to:
https://aka.ms/Ed7eot
Demonstration: Configuring and using Azure AD Premium Multi-Factor

Authentication
• Create a Multi-Factor Authentication provider.
• Configure fraud alerts.
• View fraud alert reports.
• Configure one-time bypass settings.
• Create a one-time bypass.
• Configure trusted IP addresses.
• Enable users to create app passwords.
Azure AD Privileged Identity Management and Identity Protection

Azure AD Privileged Identity Management
facilitates identifying and controlling privileged
identities and their access to Azure AD-protected
resources, including Microsoft Azure, Office 365,
and Microsoft Intune. You can use Azure AD
Privileged Identity Management to discover the
users who have Azure AD administrative roles, get
alerts on the usage of privilege roles, and
generate reports for administrative access. In
addition, Azure AD Privileged Identity
Management allows you to delegate on-demand
administrative access, minimizing risks associated
with permanent access security model. You restrict the delegation to a subset of users by designating
them as eligible admins for a particular role. Eligible admins have to request a role activation to gain
corresponding privileges. Depending on your preferences, requests might require approvals. You also
have the option delegating approvals to other users.
You can enable Privileged Identity Management in the Azure portal by using an account that is a Global
Administrator of the target Azure AD tenant. After you enable Privileged Identity Management, you can
use the privileged identity management dashboard to monitor the number of users that are assigned
privileged roles, and the number of temporary or permanent administrators. You also have the option of
generating reports detailing administrator access history and configuring alerts triggered when a
privileged role is assigned.
Note: Azure Privileged Identity Management does not control or monitor the usage of
Service Administrator or co-Administrators of an Azure subscription.
Azure AD Identity Protection offers a comprehensive insight into the usage of privileged identities in your
Azure AD tenant. It continuously monitors usage patterns and uses adaptive machine learning to identify
unauthorized authentication attempts. It evaluates risk events and assigns risk levels for each user. This
allows you to configure risk-based policies that mitigate potential threats. For example, if there are two
consecutive sign-in attempts from two different parts of the world by using the same user account, a
policy can block that user or temporarily enforce multi-factor authentication.
Note: Azure AD Privileged Identity Management and Identity Protection require Azure AD
Premium P2.
Additional Reading: For more information regarding Azure AD Privileged Identity

Management and Identity Protection, refer to: https://aka.ms/Is724e
Question: Which features of Azure AD Premium would you consider to be most useful for
your organization?
Question: A. Datum requires that their applications use multi-factor authentication. The
company has implemented this technology in its on-premises infrastructure, and wants to
extend it for applications and resources that reside in Azure. A. Datum wants to use the
authentication methods that are similar to what they are currently using in the on-premises
infrastructure. Can A. Datum use Azure Multi-Factor Authentication for this, and if so, why?
Lab: Implementing Azure AD

Scenario
The IT department at A. Datum Corporation currently uses AD DS, and a range of Active Directory-aware
applications. While preparing for synchronizing its AD DS to Azure AD, A. Datum wants you to test some
of the features of Azure AD. The company wants you to control access to third-party SaaS apps by using
Azure AD users and groups. A. Datum also wants you to configure SSO to these apps and protect them by
using Multi-Factor Authentication.
In addition to these tasks, A. Datum wants you to evaluate some of the advanced features Azure AD
Premium offers. In particular, you will need to test joining a Windows 10–based computer to an Azure AD
tenant to prepare for implementing this configuration on all the Windows 10–based computers in the
Research department.
Objectives
• Administer Azure AD.
• Configure SSO for Azure Marketplace apps.
• Configure multi-factor authentication for administrators.

• Use the advanced features offered by Azure AD Premium.
• Configure SSO from a Windows 10–based computer that is joined to Azure AD.
Lab Setup
Username: Student
Password: Pa55w.rd
Before you start this lab, ensure that you complete the tasks in the Preparing the environment
demonstration, which is in the first lesson of this module. Also, ensure that the setup script is complete.
Exercise 1: Administering Azure AD

Scenario
You want to test the functionality of Azure AD by first creating a new Azure directory and enabling the
Premium functionality. You then want to create some pilot users and groups in Azure AD. You plan to use
both the Azure portal and Microsoft Azure Active Directory module for Windows PowerShell.
Exercise 2: Configuring SSO

Scenario
Because A. Datum is planning to deploy cloud-based applications, and requires users to use SSO for these
applications, you now want to install and configure a test application, and then validate the SSO
experience.
Exercise 3: Configuring Multi-Factor Authentication

Scenario
Because A. Datum requires applications to use Multi-Factor Authentication, you now want to configure
and test Multi-Factor Authentication for Global Administrators.
Exercise 4: Configuring SSO from a Windows 10–based computer

Scenario
A. Datum has an increasing demand to provide its remote and mobile users, who are using Windows 10–
based devices, with secure access to the cloud resources. The company plans to join Windows 10 devices
to Azure AD in order to simplify access to cloud resources by leveraging SSO. You want to test this
functionality by joining a Windows 10–based computer to Azure AD.
Question: What is the major benefit of joining Windows 10–based devices to Azure AD?
Question: What is the requirement for Delegated Group Management in Azure AD?

Best Practice
Use RBAC to provide users and groups with permissions to Azure resources based on their job
requirements.

You don't receive a text or voice call that

contains the verification code for Azure
Multi-Factor Authentication
Review Question
Question: What would you consider to be primary differences between Azure AD and
AD DS?
Tools
• Azure Active Directory PowerShell Version 2. Provides necessary Windows PowerShell cmdlets for user
management, domain management and for configuring SSO: https://aka.ms/qqxznd
• Microsoft Azure Active Directory module for Windows PowerShell (64-bit version). An older version
of Azure AD module for Windows PowerShell. Its functionality overlaps to large extent with the
functionality provided by Azure Active Directory PowerShell Version 2, however, its device
management capabilities offer some unique capabilities (such as identifying devices registered by a
given user with a single cmdlet): http://aka.ms/Cuedhw
10-1
Module 10
Managing an Active Directory infrastructure in a hybrid
environment
Contents:
Lesson 1: Extending an on-premises Active Directory domain to Azure IaaS 10-2
Lesson 2: Implementing directory synchronization by using Azure AD Connect 10-8
Lesson 3: Implementing SSO in hybrid scenarios 10-27

Lab: Implementing and managing Azure AD synchronization 10-36
Module Overview
You have several distinct choices for integrating Active Directory Domain Services (AD DS) with Microsoft
cloud technologies. These options include:
• Deploying AD DS domain controllers on Microsoft Azure virtual machines (VMs).
• Implementing directory synchronization and optional password synchronization between AD DS and

Azure Active Directory (Azure AD).
• Implementing directory synchronization and pass-through authentication between AD DS and

Azure AD.
• Implementing directory synchronization and federation between AD DS and Azure AD.
In this module, you will learn about these options and how to implement them.
Objectives
After completing this module, students will be able to:
• Extend an on-premises Active Directory domain to Azure infrastructure as a service (IaaS)

environments.
• Synchronize user, group, and computer accounts between on-premises AD DS and Azure AD.
• Set up single sign-on (SSO) by using federation and pass-through authentication between
on-premises Active Directory and Azure AD.
10-2 Managing an Active Directory infrastructure in a hybrid environment
Lesson 1
Extending an on-premises Active Directory domain to
Azure IaaS
You can deploy one or more domain controllers on Azure VMs to facilitate the deployment of workloads
that depend on AD DS into an Azure IaaS environment. These domain controllers provide the same
authentication services as they would in an on-premises environment. Their provisioning process does not
differ significantly from the process you would follow in your own datacenter. However, there are some
differences due to the unique characteristics of Azure VMs. This lesson focuses on factors that you need to
consider when you deploy AD DS on Azure VMs.
Lesson Objectives
• Prepare the Azure environment for the demonstration and the lab in this module.
• Describe the options for integrating AD DS and Azure IaaS.
• Plan the deployment of Active Directory domain controllers on Azure VMs.

• Implement Active Directory domain controllers on Azure VMs.

module
Perform the tasks in this demonstration to prepare the lab environment. The Azure services that you will
use in the lab will be described in this module while the environment is being configured.
Overview of AD DS and Azure integration options

AD DS offers a wide range of business-related and
technological benefits. However, by design, its
primary purpose is to serve as an identity and
access management solution for on-premises,
independently managed, isolated environments,
and most of its characteristics reflect this
underlying premise. The authentication
mechanisms of AD DS rely largely on having
domain-member computers permanently joined
to the domain. The communication with domain
controllers involves protocols such as Lightweight
Directory Access Protocol (LDAP) for directory
services lookups, Kerberos for authentication, and Server Message Block (SMB) for Group Policy–based
interaction with AD DS domain controllers. Note that none of these protocols is suitable for internet
environments.
If you want to provide an equivalent functionality in Azure, you can deploy AD DS domain controllers as
Azure VMs. You might use this type of deployment to build a disaster recovery solution for an existing on-
premises AD DS environment or to implement a test environment. You could also use it to provide local
authentication to AD DS–dependent workloads running on Azure VMs on the same or a directly
connected Azure virtual network.
Azure AD DS
If you need to deploy AD DS–dependent workloads in Azure, but you want to minimize the overhead
associated with deploying and managing Active Directory domain controllers hosted on Azure VMs, you
should consider implementing Azure AD DS instead. Azure AD DS is a Microsoft-managed AD DS service
that provides the standard Active Directory features such as Group Policy, domain join, and support for
protocols such as Kerberos, NTLM, and LDAP. You will learn about this solution in the second lesson of
this module.
Planning to deploy Active Directory domain controllers on Azure virtual

machines
Because Azure offers IaaS capabilities, including
support for virtual machines, you can use Azure
VMs to host domain controllers to extend your
on-premises Active Directory domains to the
cloud. Hosting domain controllers in Azure can
provide a range of benefits for on-premises users
and users who connect to on-premises and Azure-
based services remotely.
Reasons for placing domain controllers in Azure

include:
• Providing authentication to AD DS–aware

Azure-based applications and services within
the Azure environment.
• Extending the scope of the on-premises AD DS to one or more Azure regions for disaster recovery
purposes.
• Implementing additional AD DS domain controllers in Azure to enhance the resiliency of the directory
synchronization and federation deployments.
Deployment scenarios
There are three main scenarios that involve AD DS and Azure VMs:
• AD DS deployed to Azure VMs without cross-premises connectivity. This deployment results in the
creation of a new forest, with all domain controllers residing in Azure. Use this approach if you plan to
implement Azure-resident workloads hosted on Azure VMs that rely on Kerberos authentication or
Group Policy but have no dependencies on your on-premises infrastructure.
• Existing on-premises AD DS deployment with cross-premises connectivity to an Azure virtual network.

This scenario uses an existing on-premises Active Directory environment to provide authentication for
Azure-resident workloads. When considering this design, you should take into account the latency
associated with cross-premises network traffic.
• Existing on-premises AD DS deployment with cross-premises connectivity to an Azure virtual network
hosting additional domain controllers on Azure VMs. The primary objective of this scenario is to
optimize workload performance by localizing authentication traffic.
Planning for deploying Active Directory domain controllers in Azure

When planning the deployment of AD DS domain controllers to Azure VMs, you should consider the
following:
• Inter-site connectivity. A key design element is inter-site connectivity between your on-premises
environment and the Azure virtual network where you will deploy domain controllers. You must set
up either a site-to-site virtual private network (VPN) or Microsoft Azure ExpressRoute. For more
information regarding this topic, refer to Module 2, “Implementing and manage Azure networking.”
• Active Directory topology. You should configure AD DS sites to reflect your cross-premises network
infrastructure. This will allow you to localize the authentication traffic and control the replication
traffic between on-premises and Azure-based domain controllers. Intra-site replication assumes high
bandwidth and permanently available connections. By contrast, inter-site replication allows for
scheduling and throttling replication traffic. In addition, a proper site design ensures that domain
controllers in a given site handle authentication requests originating from that site.
• Read-only domain controllers (RODCs). Some customers are wary about deploying writeable domain
controllers to Azure VMs. One way to mitigate this concern is to deploy RODCs instead. RODCs and
writeable domain controllers provide similar user experiences. However, RODCs lower the volume of
egress traffic and the corresponding charges. This is a good option if an Azure-resident workload
does not require frequent write access to AD DS.
• Global catalog placement. Regardless of your domain topology, you should configure all your Azure-
based domain controllers as global catalog servers. This arrangement prevents global catalog lookups
from traversing cross-premises network links, which would result in egress network traffic charges.
Implementing Active Directory domain controllers on Azure VMs

When planning for the deployment of AD DS to
Azure VMs, you must decide whether you want to
install an additional domain controller in an
existing on-premises Active Directory
environment or the first domain controller in a
new Active Directory forest. The two scenarios
have similar requirements. The primary difference
is that the first scenario requires a cross-premises
connection through a site-to-site VPN or
ExpressRoute.
Install an additional Active Directory

domain controller in an Azure VM
To implement a replica domain controller on an Azure VM:
1. Create an Azure virtual network with cross-premises connectivity.
2. Create an Azure Storage account.
Note: Note that if you decide to use managed disks for the operating system on the Azure
VM and data disks, there is no need to provision a storage account. However, you will need a
storage account if you want to collect Azure VM diagnostics.
3. Create an Azure VM and assign it a static IP address.
4. Install the AD DS and Doman Name System (DNS) server roles in the operating system of the
Azure VM.
The following sections explain these steps in detail.
Create an Azure virtual network with cross-premises connectivity

When you create an Azure virtual network in this scenario, you need to specify:
• The name of the virtual network.
• An IP address space that does not overlap with the IP address space of your on-premises network.
• One or more subnets within the virtual network, with the IP address ranges within its IP address space.
• The DNS server settings that point to one or more of your on-premises DNS servers.
In addition, you need to provision cross-premises connectivity, either through a site-to-site VPN or
ExpressRoute. For details regarding these procedures, refer to Module 2, “Implementing and managing
Azure networking.”
Create an Azure Storage account

If you are using unmanaged disks, you need a storage account to host the virtual hard disks of the Azure
VM operating as an additional AD DS domain controller. You can create an account as a separate step or,
if you are using the Azure portal, you can create an account when you deploy the virtual machine. If you
are using managed disks, you might want to create a storage account to host diagnostics data.
Regardless of the type of disks you use, you should ensure that you allocate a separate data disk or disks
for the Active Directory database, log files, and SYSVOL. For details about managed and unmanaged disks,
refer to Module 3, “Implementing virtual machines.”
Create an Azure VM and assign an IP address

Next, you need to create an Azure VM with a static IP address on one of the virtual network subnets. For
this purpose, you can use any of the methods described in Module 3, “Implementing virtual machines.”
You also need to attach virtual disks that will host the database, logs, and SYSVOL files. Make sure to set
caching to None on the data and log disks.
Note: Choose the virtual machine size with sufficient memory to fully cache the entire AD DS
database. This should considerably improve its performance.
Install and configure DNS and AD DS server roles

To promote the server to a domain controller, you need to add the AD DS server role. You can accomplish
this by using Add Roles and Features in Server Manager or by running the following Windows
PowerShell cmdlet:
Install-WindowsFeature ADDS-Domain-Controller
In addition, add the DNS server role. You can install it by using Add Roles and Features in Server
Manager or by running the following Windows PowerShell cmdlet:
Install-WindowsFeature DNS
After the server role installation completes, promote the server running Windows Server to a domain
controller. After the new domain controller is fully operational, update the DNS server settings of the
Azure virtual network to point to the static IP address you assigned to the Azure VM. These settings will
apply automatically to every new Azure VM you deploy to the same virtual network.
Note: To ensure resiliency and to qualify for the 99.95% availability service level agreement
(SLA), consider deploying the Azure VM into an availability set. After the deployment is complete,
deploy another VM into the same availability set and configure it as an additional domain
controller in the same domain as the first Azure VM.
Install a new Active Directory forest on an Azure virtual network

To implement a new Active Directory forest in Azure, perform the following steps:
1. Create an Azure virtual network by specifying:
o The name of the virtual network.
o An IP address space.
o One or more subnets within the virtual network, with the IP address ranges within its IP address
space.
o The DNS server addresses that point to the IP address you will assign to the Azure VM that will
host the AD DS domain controller.
2. Create a storage account. Be sure to follow the guidance about storage accounts provided earlier in
this topic.
3. Deploy an Azure VM to host the domain controller and DNS server roles.
4. Install the AD DS and DNS server roles.

To avoid direct access to the domain controller from the internet, do not assign a public IP address to its
network adapter. Instead, consider deploying another Azure VM on the same virtual network and
configuring it as a jump host. By assigning a public IP address to that virtual machine, you will be able to
connect to it by using Remote Desktop Protocol (RDP). From the RDP session, you can manage the AD DS
domain controller on the first virtual machine.

Question
How should you configure caching on Azure virtual machines hosting AD DS domain controllers?
Set the caching to None on the disks hosting the database, SYSVOL, and log files.
Set the caching to ReadOnly on the disks hosting the database, SYSVOL, and log files.
Set the caching to ReadWrite on the disks hosting the database, SYSVOL, and log files.
Set the caching to ReadWrite on the disks hosting the database and SYSVOL files, and set it to
None for the disk hosting log files.
Set the caching to ReadWrite on the disks hosting the database and SYSVOL files, and set it to
ReadOnly for the disk hosting log files.
Lesson 2
Implementing directory synchronization by using
Azure AD Connect
Azure AD supports integration with AD DS, which considerably simplifies the management of identities in
hybrid environments. There are two main integration options: the same sign-on and the SSO.
Both these options rely on the Azure AD Connect tool to provide synchronization between AD DS and
Azure AD. This lesson describes the principles of directory synchronization and its implementation by
using Azure AD Connect. It also introduces the Azure AD Connect Health tool, which facilitates
monitoring of the Azure AD Connect operational status.
Lesson Objectives
• Describe directory synchronization.
• Compare the different directory synchronization options.
• Identify the directory synchronization option that is best for a given scenario.
• Prepare on-premises Active Directory for directory synchronization.
• Install and configure Azure AD Connect.
• Manage and monitor directory synchronization.
• Implement Azure AD Domain Services.
• Implement directory synchronization by using Azure AD Connect.
Overview of directory synchronization

Directory synchronization involves copying
selected user, group, contact, and Windows 10
device objects and their attributes between on-
premises Active Directory and Azure AD. In its
simplest form, you install a directory
synchronization component on a server with
direct connectivity to your AD DS domain
controllers, provide an account with AD DS
Enterprise Admin privileges and another account
with Global Admin privileges to Azure AD, and
then let the directory synchronization component
run. After the initial synchronization completes,
objects representing all on-premises user accounts, groups, contacts that are not built-in, and, optionally,
Windows 10 devices from AD DS will then automatically appear in Azure AD. By default, the
synchronization process includes password hashes. This way, AD DS users can authenticate and, if
permitted, access Azure resources by using the same credentials as those they use to sign in to their on-
premises computers. This mechanism is known as same sign-on and requires that users provide their
credentials the first time they authenticate to Azure AD. Alternatively, you have the option of
implementing SSO, which relies on either pass-through authentication or federation between AD DS and
Azure AD to provide access to Azure resources without the need to reauthenticate.
Azure AD Connect
To implement the synchronization process, use Azure AD Connect. This tool automatically synchronizes
objects–such as users, groups, devices, and contacts–and their attributes from on-premises AD DS to
Azure AD. The synchronization process includes the user principal name (UPN) attribute, which usually
matches the name that Active Directory users use to sign in to their on-premises computers. You can use
this attribute to represent a replica of each user in Azure AD. Matching the UPN across the two
environments simplifies the sign-in experience because users can authenticate with the same user name
they use when they access cloud services. In addition, you can synchronize password hashes, which results
in a matching set of credentials in both directories.
Note: To be able to use the same name to sign in to AD DS and Azure AD, the domain
names of Azure AD and AD DS must match. This, in turn, requires configuring and validating a
custom domain name in the Azure AD tenant with which the on-premises Active Directory
synchronizes.
Azure AD Connect provides a wide range of capabilities, including:
• Support for multiple forest scenarios.
• Filtering based on the domain, organizational unit, and individual object attribute.
• Synchronization of password hashes to Azure AD.

Azure AD Connect provides an installation wizard that allows you to select the connectivity model that
matches your environment. You choose your topology and requirements such as single or multiple
forests, Microsoft Exchange hybrid deployment, password synchronization or federation, password reset
write-back, or device write-back. The wizard deploys and configures all specified settings.
Azure AD Connect includes three components that deliver the following features:
• Synchronization. This is the primary component of Azure AD Connect responsible for synchronizing
users, groups, contacts, and device objects. Its functionality uses a subset of Microsoft Identity
Manager features, including AD DS and Azure AD connectors for communication between the two
identity providers. It facilitates the import and export of objects at regular intervals and implements
scope filtering.
• Active Directory Federation Services (AD FS). Provides the functionality necessary to implement
federation between AD DS and Azure AD. This enables the system to handle all authentication
requests within the AD DS environment, eliminating the requirement for password hash
synchronization.
• Health monitoring. Azure AD Connect Health monitors the status of your Azure AD Connect
deployment.
Note: Azure AD Connect includes and enhances the functionality available in earlier versions
of Microsoft Azure AD synchronization tools, including DirSync and Azure AD Sync.
Comparing Azure AD integration scenarios

When implementing Azure AD Connect, you can
choose from the following integration scenarios:
• Directory synchronization
• Directory synchronization with password hash

synchronization (same sign-on)
• Directory synchronization with password hash

synchronization and Seamless SSO
• Directory synchronization with pass-through

authentication and same sign-on
• Directory synchronization with pass-through
authentication and Seamless SSO
• Directory synchronization with federation (SSO)
Note: The acronym SSO that you might see in Microsoft documentation and throughout this
module represents the term SSO.
Note: At the time of authoring this content, Azure AD pass-through authentication is in

preview.
Directory synchronization
In this scenario, directory synchronization synchronizes user account information to Azure AD but
excludes password hashes. Any changes to Active Directory users’ passwords do not affect passwords for
the corresponding Azure AD user objects. This confuses users, because the passwords that they need
depend on the resources that they are attempting to access. This results in an increased number of help
desk calls.
Note: If you intend to implement this scenario, do not select any options on the User sign-
in page when installing Azure AD Connect.
Directory synchronization with password hash synchronization (same sign-on)

In this scenario, directory synchronization synchronizes user account attributes and password hashes to
Azure AD. This method ensures that passwords for any user in the scope of synchronization are the same
in Azure AD and in on-premises AD DS. This eliminates the problem associated with the first scenario,
although users will typically need to provide their password more than once.
During an initial attempt to access an Azure AD–authenticated resource, each user must provide
Azure AD credentials. The sign-in process converts the user’s password into a hash and passes it to
Azure AD. Azure AD compares the hash with the one stored in its local data store. If these two match,
the authentication attempt succeeds.
The dialog box includes the option to save the credentials in the user’s credential store so that subsequent
authentication attempts do not trigger a prompt. However, it is important to understand that this is the
same sign-on, not SSO. The user authenticates separately against two distinct directory services, albeit by
using the same user name and password. However, for many organizations, the simplicity of this solution
compensates for the lack of true SSO.
Note: If you intend to implement this scenario, select the Password Synchronization
option on the User sign-in page when installing Azure AD Connect.
Directory synchronization with password hash synchronization and Seamless SSO

Enabling the Seamless SSO feature during the installation of Azure AD Connect facilitates SSO
functionality without relying on federation. To enable this option, select the Password Synchronization
and the Enable single sign-on options on the User sign-in page when installing Azure AD Connect. The
installation process will then include the following additional tasks:
1. Create a new computer account named AZUREADSSOACCT in the Active Directory domain that you
configure for synchronization.
2. Store the computer account’s Kerberos decryption key in the target Azure AD tenant.
3. Associate the autologon.microsoftazuread-sso.com and aadg.windows.net.nsatc.net service
principal names (SPNs) with the AZUREADSSOACCT computer account in the Active Directory
domain.
Note: You must configure the two SPNs to be part of the intranet zone for the web browsers
of all Active Directory users. You can apply this configuration by using Group Policy.
Implementation details depend on the type of web browser.
With these changes in place, users who successfully sign in to their Active Directory domain–based client
computers will be able to authenticate to cloud-based resources without providing their passwords.
However, users will need to provide their user name when accessing a cloud resource for the first time.
Azure AD relies on the AZUREADSSOACCT computer account to facilitate secure communication of the
Kerberos ticket for the authenticating user.
Note: The requirement to provide user names does not apply if the access request
identifies the target Azure AD tenant or the name of the user. For example, this is the case
when browsing to the Access Panel with the URL in the format https://myapps.microsoft.com
/contoso.onmicrosoft.com or https://myapps.microsoft.com/contoso.com, where
contoso.onmicrosoft.com and contoso.com are the Azure AD tenant name and its verified
DNS domain name, respectively.
Additional Reading: For more information, refer to: “Azure AD Seamless Single Sign-On” at:
https://aka.ms/wz4wvq
This scenario applies if users access cloud applications via a web browser or from Microsoft Office
programs that support modern authentication. This includes Office 2013 and newer versions.
Directory synchronization with pass-through authentication and same sign-on

In this scenario, directory synchronization synchronizes user account attributes to Azure AD. When a user
attempts to access a cloud-based resource, Azure AD passes through the user’s password to AD DS for
verification. To implement this, select the Pass-through authentication option on the User sign-in page
when installing Azure AD Connect. After the installation completes, you will need to perform the following
additional tasks:
1. Download the AADApplicationProxyConnectorInstaller.exe Authentication Agent installer from

https://aka.ms/ri8d07. Install it on one or more on-premises servers with direct connectivity to Active
Directory domain controllers and connectivity to Azure AD on TCP ports 80 and 443. To install the
agent, run the following from an elevated Windows PowerShell prompt:
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
2. Register each instance of the Authentication Agent with your Azure AD tenant. At the Windows
PowerShell prompt, change the current directory to the C:\Program Files\Microsoft AAD App
Proxy Connector folder, and then run the following command:
.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy

Connector\Modules\" -ModuleName "AppProxyPSModule" -Feature PassthroughAuthentication
When prompted, provide the credentials of a Global Administrator account of your Azure AD tenant.
By implementing Azure AD pass-through authentication, you provide the same sign-on user experience,
but without the need to synchronize password hashes to Azure AD. Some organizations prefer this option
because they are reluctant to store copies of users’ password hashes outside their on-premises Active
Directory.
This scenario applies if users access cloud applications from on-premises Active Directory–joined
computers and Azure AD–joined computers. Users must access these applications either from a web
browser or from Office 365 client applications that support modern authentication, such as Office 2013
and newer.
Additional Reading: For more information about pass-through authentication, refer to:
“User sign-in with Azure Active Directory Pass-through Authentication” at:
https://aka.ms/e6w1t5
Directory synchronization with pass-through authentication and Seamless SSO

This scenario combines the benefits of pass-through authentication, which eliminates the need to
synchronize passwords hashes to Azure AD, with the benefits of Seamless SSO, which eliminates the need
to provide a password when authenticating to Azure AD. To implement it, select the Pass-through
authentication and Enable single sign-on options on the User sign-in page when installing Azure AD
Connect. In addition, you must perform the following post-installation steps:
1. Download the AADApplicationProxyConnectorInstaller.exe Authentication Agent installer from
https://aka.ms/ri8d07.
2. Install it on one or more on-premises servers with direct connectivity to Active Directory domain
controllers and connectivity to Azure AD on TCP ports 80 and 443. To install the agent, run the
following from an elevated Windows PowerShell prompt:
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
3. Register each instance of the Authentication Agent with your Azure AD tenant. At the Windows
PowerShell prompt, change the current directory at the Windows PowerShell prompt to the
C:\Program Files\Microsoft AAD App Proxy Connector folder, and then run the following
command:
.\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy

Connector\Modules\" -ModuleName "AppProxyPSModule" -Feature PassthroughAuthentication
4. Configure autologon.microsoftazuread-sso.com and aadg.windows.net.nsatc.net SPNs to be

part of the intranet zone for the web browsers of all Active Directory users. You can apply this
configuration by using Group Policy. Implementation details depend on the type of web browser.
This scenario applies if users access cloud applications from on-premises Active Directory–joined
computers and Azure AD–joined computers. Users must access these applications either from a web
browser or from Office 365 client applications that support modern authentication.
Note: Azure AD pass-through authentication automatically enables a feature called Smart

Lockout. It protects AD DS and Azure AD identities from brute force attacks and prevents account
lockouts resulting from these attacks. With Smart Lockout in place, Azure AD keeps track of failed
sign-in attempts. If these attempts reach the value of the Lockout Threshold property before
the amount of time specified in the Lockout Counter After property passes, Azure AD rejects
any subsequent sign-in attempts for the duration of the lockout. You can retrieve and modify the
values of the Lockout Threshold, Lockout Counter After, and Lockout Duration Azure AD
properties by using the Graph application programming interface (API). Modifying these values
requires Azure AD Premium P2.
You should ensure that the value of the Azure AD Lockout Threshold property is smaller than
the value of the AD DS Lockout Threshold property. Conversely, you should ensure that the
value of the Azure AD Lockout Duration property is larger than the value of the AD DS Lockout
Duration property.
Additional Reading: The Graph API provides programmatic access to Azure AD via REST API
endpoints. If you want to learn about accessing Azure AD resources programmatically, you
should consider focusing on Microsoft Graph instead. At the time of authoring this content, this is
the approach that Microsoft recommends. For more information, refer to: "Microsoft Graph or
the Azure AD Graph” at: https://aka.ms/gxb1ch
Additional Reading: For more information about Smart Lockout, refer to: “Azure Active
Directory Pass-through Authentication: Smart Lockout” at: https://aka.ms/o3akoi
Directory synchronization with federation (SSO)

In this scenario, directory synchronization synchronizes user account information to Azure AD. Azure AD
uses the synchronized information to identify authenticating users and redirect their requests to a security
token service (STS), such as AD FS. The STS contacts AD DS to perform authentication and, if the attempt
is successful, it returns the corresponding token to Azure AD. Users need to authenticate only once during
the initial sign-in to their domain-joined computers, even when accessing cloud-based resources.
SSO relies on a federated trust between Azure AD and AD DS. This trust enables users to authenticate to
obtain access to cloud applications and resources by using their domain accounts in AD DS.
Azure AD Connect supports a range of federation solutions. However, it is particularly helpful when using
AD FS because Azure AD Connect includes a wizard that guides you through deployment and
configuration of AD FS, automating most of the intermediary tasks.
It is important to understand that, by default, if AD FS becomes unavailable, users will not be able to
authenticate when accessing cloud-based resources. Deploying a reliable and highly available federation
infrastructure requires more resources and management than other scenarios described above.
Feature comparison
The following table lists the features that each Azure AD integration option supports.
Directory
synchron- Directory Directory
ization Directory
synchroni- synchroni-
with synchroni-
zation with zation with Directory
Directory password zation with
pass- pass- synchroni-
synchron- hash password
Feature through through zation with
ization synchron- synchroni-
authentica- authentica- federation
only ization zation and
tion and tion and (SSO)
(same Seamless
same sign- Seamless
sign-on) SSO
on SSO
Sync users, Yes Yes Yes Yes Yes Yes

groups, and
contacts to
Azure
Sync password Yes Yes Yes No No No

hashes to Azure
Enable hybrid Yes, Yes, Yes (web Yes (web Yes (web Yes, full
Office 365 limited limited browsers browsers browsers support
scenarios integratio integratio and and and
n n modern modern modern
authentica authenticati authenticati
tion apps) on apps) on apps)
Users can sign No Yes Yes Yes Yes Yes

in with Active
Directory
credentials
Reduce No Yes Yes Yes Yes Yes

password
administration
costs
Control No Yes Yes Yes Yes Yes

password
policies from
AD DS
Enable Azure Yes Yes Yes Yes Yes Yes

Multi-Factor
Authentication
Directory
synchron- Directory Directory
ization Directory
synchroni- synchroni-
with synchroni-
zation with zation with Directory
Directory password zation with
pass- pass- synchroni-
synchron- hash password
Feature through through zation with
ization synchron- synchroni-
authentica- authentica- federation
only ization zation and
tion and tion and (SSO)
(same Seamless
same sign- Seamless
sign-on) SSO
on SSO
Enable on- No No No No No Yes

premises multi-
factor
authentication
Authenticate No No No Yes Yes Yes

against AD DS
Implement SSO No No Yes No Yes Yes

with Active
Directory
credentials
Federation No No No No No Yes
infrastructure
Discussion: Which directory synchronization option would be optimal for

your organization?
Discuss which directory synchronization option
would be most appropriate for your organization.
Use the table from the previous topic to identify
which features you might need.
Preparing on-premises Active Directory for directory synchronization

When you prepare for directory synchronization,
you should consider a range of factors. The
following sections describe these considerations in
detail.
Review domain controller requirements

To work with Azure AD Connect, domain and
forest functional levels must be Windows Server
2003 or later. For the password write-back feature,
domain controllers must be running at least
Windows Server 2008 with the latest service pack.
Review Azure AD Connect computer requirements

The computer that is running Azure AD Connect must be running Windows Server 2008 or newer, and it
must have the latest hotfixes and updates. To implement password synchronization, you must use
Windows Server 2008 R2 service pack 1 (SP1) or newer. For express settings, the computer must be a
member server of a domain or a domain controller, but for custom setting installation, the computer can
be a workgroup computer. If you plan to use Azure AD Connect with AD FS, servers where AD FS and
Web Application Proxy are deployed must be running Windows Server 2012 R2 or later.
In addition, Azure AD Connect requires Microsoft .NET Framework 4.5.1 or later and Windows PowerShell
3.0 or later. For deploying AD FS and Web Application Proxy, you must enable Windows Remote
Management on the servers where you will install these components.
Review hardware recommendations

Deployments with more than 50,000 objects in AD DS require a significant increase in memory—from 4
gigabytes (GB) of RAM to 16 GB. Therefore, it is important to implement adequate hardware resources
when transitioning from the pilot to production phase.
If you implemented Azure AD Connect on a virtual machine that is running in Azure, you can scale up the
virtual machine if your synchronization requirements increase.
The following table provides guidance on hardware sizing based on the number of objects in AD DS.
Central processing unit

Number of objects in AD DS Memory Hard disk size
(CPU)
Fewer than 10,000 1.6 gigahertz (GHz) 4 GB 70 GB
10,000–50,000 1.6 GHz 4 GB 70 GB
50,000–100,000 1.6 GHz 16 GB 100 GB
100,000–300,000 1.6 GHz 32 GB 300 GB
300,000–600,000 1.6 GHz 32 GB 450 GB
More than 600,000 1.6 GHz 32 GB 500 GB

Review accounts and required permissions

Installing and configuring Azure AD Connect requires the following accounts:
• An Azure AD work or school account with the Global Administrator role. Create this account in the
Azure AD tenant that you plan to integrate with AD DS.
• An on-premises AD DS account. Required privileges depend on whether you choose the express or
custom installation settings. With the express installation settings, you must use an account that is a
member of the Enterprise Admins group in the AD DS forest you plan to synchronize with Azure AD.
This account is responsible for creating the synchronization user account in AD DS and granting it the
necessary permissions to perform read and write operations during synchronization. With custom
installation settings, you can precreate the synchronization user account with the appropriate level of
permissions.
Additional Reading: For more information about Azure AD Connect synchronization

features and their requirements, refer to: “Azure AD Connect: Accounts and permissions” at:
https://aka.ms/f4bysk
Azure AD Connect uses an Azure Global Administrator account to implement directory integration and
create the Azure AD service account. This account will provision and update Azure AD objects when the
Azure AD Connect setup wizard runs. The name of the Azure AD service account has the prefix Sync_,
followed by the name of the server that is hosting Azure AD Connect.
Directory synchronization process creates an AAD_id user account in the Users container of the root
domain of a synchronized forest. This is the account for the synchronization engine running as the
Microsoft Azure AD Sync service on the server where you installed the Azure AD Connect software,
assuming you used a domain-member server for this purpose. The account has a randomly generated
complex password configured to never expire. When the directory synchronization service runs, it uses the
service account credentials to read from on-premises Active Directory and then write the contents of the
synchronization database to the Azure AD tenant.
Review network connectivity requirements

Synchronization with Azure AD occurs over Secure Sockets Layer (SSL). This synchronization is outbound
because Azure AD Connect initiates it, and it uses port 443. Internal network communication uses
standard Active Directory–related ports.
The following table provides the required information to plan which ports to enable on the firewall for
successful directory synchronization.
Service Protocol Port
LDAP TCP/User Datagram Protocol (UDP) 389
Kerberos TCP/UDP 88
DNS TCP/UDP 53
Kerberos change password TCP/UDP 464
Remote procedure call TCP 135

(RPC)
RPC randomly allocated TCP 1024–65535

high-TCP ports 49152–65535
Service Protocol Port
SMB TCP 445
SSL TCP 443
Microsoft SQL Server TCP 1433
Review certificate requirements

All AD FS servers must use the same HTTPS certificate. The AD FS configuration, including the SSL
certificate thumbprint, replicates through a Windows Internal Database (WID) or through a SQL Server
database across all the members of the AD FS server farm. You need to use a certificate that you obtain
from a public certification authority (CA).
Review Azure AD Connect supporting components

Azure AD Connect installs the following components on the server:
• Microsoft SQL Server 2012 Command Line Utilities
• SQL Server 2012 Native Client

• SQL Server 2012 Express LocalDB
• Microsoft Online Services Sign-In Assistant
• Microsoft Visual C++ 2013 Redistributable Package
If you specify during setup that you will use an existing SQL Server instance, the setup process excludes
the SQL Server 2012 Express LocalDB from the list of components to install.
Review UPN requirements

Azure AD Connect automatically assigns the UPN suffix to AD DS user accounts synchronized to
Azure AD. If you want to implement same sign-on or SSO, you must ensure that the values of the UPN
attribute of Azure AD users match the values of the UPN attribute of the corresponding AD DS users. To
accomplish this, you must add the domain name matching the UPN suffix to your Azure AD tenant and
verify its ownership. For example, if your organization uses @contoso.com as its AD DS UPN suffix, you
need to add and verify contoso.com as a domain name in Azure AD. This ensures that
userb@contoso.com in the on-premises AD DS maps to the userb@contoso.com account in Azure AD
after you enable directory synchronization.
If your on-premises AD DS domain uses a UPN that is not routable, such as Contoso.local, you must
replace this UPN with a publicly resolvable DNS name that matches a verified domain in your Azure AD
tenant. Otherwise, synchronization will generate Azure AD user accounts with the name in the format
@usernamedomain.onmicrosoft.com, where usernamedomain is unique per Azure AD tenant. To maintain
your organizational identity, you should ensure that you have UPNs for AD DS users set up correctly, with
the matching domains added to Azure AD, before you synchronize.
Prepare AD DS
Before deploying Azure AD Connect, it is essential that you review and remediate any issues in the on-
premises Active Directory. Your review should include identifying:
• Invalid characters in attribute values
• Non-unique attributes
• Schema extensions
During your review, remember the following requirements and rules applicable to invalid characters.
Attribute Characters Requirements Invalid characters
proxyAddress 256 Must be unique )(;><][\
sAMAccountName 20 !#$%^&{}\{`~"/[]:@<>+=;
?*
givenName 64 ?@\+
surname 64 ?@\+
displayName 256 ?@\+
Mail 256 Must be unique [!#$%&*+/=?^`{}]
mailNickname 64 "\[]:><;
userPrincipalName 64/256 • Must be unique }{#‗$%~*+)(><!/\=?`

in the forest
• @ character
must exist
• Must not include
a space, end in a
space, a period,
&, or @
• Must be internet
routable
After you complete your review, perform the following remediation tasks:
• Remove duplicate proxyAddress and userPrincipalName attributes.
• Update blank and invalid userPrincipalName attributes, and replace with valid userPrincipalName
attributes.
• Remove invalid characters in the following attributes: givenName, surname, sAMAccountName,
displayName, mail, proxyAddress, mailNickname, and userPrincipalName.
UPNs for same sign-on and SSO can contain letters, numbers, periods, dashes, and underscores. No other
characters are allowed.
IdFix
The IdFix tool enables you to identify and remediate most object synchronization issues in AD DS,
including common ones such as duplicate or malformed proxyAddress and userPrincipalName
attributes. You can limit its scope to individual organizational units (OUs).
Installing and configuring Azure AD Connect

You can install the Azure AD Connect tool by
using express setup, which is sufficient for simple
integration scenarios. Alternatively, you can use
custom setup if you have more complex
requirements.
Additional Reading: Download Microsoft

Azure Active Directory Connect from Microsoft
Downloads at: http://aka.ms/Jlpj42
Azure AD Connect express setup

You can use Azure AD Connect express setup to implement directory synchronization with password
synchronization for a single Active Directory forest. Express setup creates a LocalDB instance, which is a
lightweight version of SQL Express. Express setup offers the option to enable Exchange hybrid
deployment, which will configure the required attribute write-back option.
Azure AD Connect with express settings will:
1. Install the synchronization engine.
2. Configure the Azure AD connector.
3. Configure the on-premises AD DS connector.
4. Enable password synchronization.

5. Configure synchronization services.
6. Configure synchronization services for an Exchange hybrid deployment (optional).
To install Azure AD Connect by using the express settings, perform the following steps:
1. Sign in to the server on which you wish to install Azure AD Connect by using an account with local
administrative privileges.
2. Run the Microsoft Azure AD Connect Setup program (AzureADConnect.msi).
3. On the Welcome to Azure AD Connect page, select I agree to the license terms and privacy
notice, and then click Continue.
4. On the Express Settings page, click Use express settings.

5. On the Connect to Azure AD page, type the user name and password of an Azure AD account with
the Global Administrator role, and then click Next.
6. On the Connect to AD DS page, type the user name and password of an AD DS Enterprise
Administrator account, and then click Next.
7. On the Azure AD sign-in configuration page, identify whether your Azure AD tenant has an existing
verified domain with a name that matches the Active Directory UPN suffix. If it does not, but you
want to proceed with the installation, select the Continue without any verified domain check box.
At this point, you can also specify the on-premises attribute that you want to use as the Azure AD
user name. By default, Azure AD Connect uses userPrincipalName for this purpose.
Note: If you decide to proceed without the matching verified domain name, the following
message appears: Users will not be able to sign-in to Azure AD using their existing on-
premises credentials.
8. On the Ready to configure page, review the settings, and then click Install.
9. On the Configuration complete page, click Exit.
Custom installation of Azure AD Connect

You will need to use the Azure AD Connect custom setup for more complex scenarios. These scenarios
include modifying the scope of synchronization, merging identities from multiple AD DS forests, and
AD FS deployments. To install Azure AD Connect with password synchronization by using custom settings
in a single AD DS forest environment, perform the followings steps:
1. Sign in to the server on which you wish to install Azure AD Connect by using an account with local
administrative privileges.
2. Run the Microsoft Azure AD Connect Setup program (AzureAdConnect.msi).

3. On the Welcome to Azure AD Connect page, select I agree to the license terms and privacy
notice, and then click Continue.
4. On the Express Settings page, click Customize.
5. On the Install required components page, you can optionally select one of the following:
o Specify a custom installation location. You can specify a different location to install Azure AD
Connect.
o Use an existing SQL Server. This allows you to use an existing SQL Server instance, preventing
the installation of SQL Server Express LocalDB.
o Use an existing service account. You must use this option when using a remote SQL Server
instance or when your internet proxy requires authentication. By default, Azure AD Connect
generates and uses a virtual service account for its synchronization services.
o Specify custom sync groups. By default, Azure AD Connect creates four local admin groups on
the server where you install it. They allow you to delegate synchronization-related administrative
tasks to others. You can pre-create your own groups instead and specify them at this point.
6. Click Install.
7. On the User sign-in page, select one of the following:
o Password Synchronization. This option synchronizes user password hashes to Azure AD.
o Pass-through authentication. This option synchronizes user password hashes to Azure AD and
allows you to configure your on-premises Active Directory forest to accept passwords hashes
from Azure AD during user authentication.
o Federation with AD FS. This option assists you with deployment of the AD FS infrastructure,
following the setup of the synchronization component.
o Do not configure. Select this option if you already have an existing federation solution in place.
o Enable single sign-on. Select this option if you want to combine Password Synchronization or
Pass-through authentication with SSO.
8. On the Connect to Azure AD page, type the user name and password of an Azure AD Global
Administrator account, and then click Next.
9. On the Connect your directories page, specify the Active Directory forest, and then click Add
Directory. When prompted, in the AD Forest Account window, ensure that the Use existing
account option is selected, and then enter the name of a pre-created account that you intend to use
for synchronization. Alternatively, you can select the Create new account option, provide the
credentials of an AD DS Enterprise Administrator account, and then click OK. This will create the
synchronization account for you.
10. On the Connect your directories page, click Next.
11. On the Azure AD sign-in configuration page, identify whether your Azure AD tenant has an existing
verified domain with a name that matches the Active Directory UPN suffix. If it does not, and you
want to proceed with the installation, select the Continue without any verified domain check box.
At this point, you also can specify which on-premises attribute you want to use as the Azure AD user
name. By default, Azure AD Connect uses userPrincipalName for this purpose.
Note: If you decide to proceed without the matching verified domain name, the following
message appears: “Users will not be able to sign-in to Azure AD using their existing on-premises
credentials.”
12. On the Domain and OU filtering page, specify which domains and organizational units to
synchronize and then click Next.
13. On the Uniquely identifying your users page, select the default Users are represented only once
across all directories option, and then click Next.
Note: On the Uniquely identifying your users page, you can alter how directory
synchronization behaves in multiple-forest environments.
14. On the Filter users and devices page, you can use synchronization filtering based on Active
Directory group membership.
15. On the Optional Feature page, review the following options, and then click Next:
o Exchange Hybrid Deployment. Enable this option in Microsoft Exchange coexistence scenarios.
o Exchange Mail Public Folders. Enable this option to synchronize a subset of attributes of mail-
enabled public folders.
o Azure AD app and attribute filtering. Enable this option to filter the attributes that will
synchronize in Azure AD based on the cloud applications that you intend to use.
o Password synchronization. Enable this option if you selected pass-through authentication. You
might consider enabling this option if you selected federation as the SSO solution.
o Password writeback. Enable this option to synchronize changes to account passwords in the
cloud back to AD DS.
o Group writeback. Enable this option if you have Office 365 groups that you want to replicate to
on-premises Active Directory as distribution groups.
o Device writeback. Enable this option to replicate devices registered in or joined to Azure AD to
AD DS. This is useful when implementing conditional access scenarios.
o Directory extension attribute sync. Enable this option to synchronize AD DS custom attributes
to Azure AD.
16. If you enabled the Azure AD app and attribute filtering option in the previous step, on the Azure
AD Apps page, you can restrict attributes to synchronize based on your choice of Azure AD apps,
such as Exchange Online or Microsoft SharePoint Online.
17. The Azure AD attributes page also appears only if you select the Azure AD app and attribute
filtering option on the Optional Feature page. On the Azure AD attributes page, you can select
individual AD DS attributes that you want to synchronize with Azure AD.
18. If you selected Directory extension attribute sync, then on the Directory extension page, you can
extend the schema in Azure AD with custom attributes that exist in your AD DS.
19. On the Ready to configure page, click Install to complete the custom installation of Azure AD
Connect.
Note: A later topic, “Deploying AD FS,” discusses custom AD FS installation.
Configure filtering options

You can customize the scope of synchronization by configuring filtering based on:
• Domains. You might have a domain with resources that you do not want to synchronize with AD DS.
• OUs. This is a frequent filtering option. You use it to select objects from specific OUs that will
synchronize with Azure AD.
• Attributes. Attribute-based filtering provides a much more granular level of control. By using this type
of filtering, you can specify individual objects from on-premises AD DS that should or should not
synchronize with Azure AD.
You can configure filtering for domains and OUs in on-premises AD DS by rerunning Azure AD Connect.
To do this, use the following procedure:
1. Start Azure AD Connect.
2. On the Welcome to Azure AD Connect page, click Configure.
3. On the Additional tasks page, select Customize synchronization options, and then click Next.
4. When prompted, provide the credentials for an Azure AD Global Administrator and an AD DS
Enterprise Admin. You will be able to modify domain and OU filtering settings from the Domain/OU
Filtering page.
To configure attribute-based filtering in on-premises AD DS, perform the following steps:
1. Start Synchronization Rules Editor.
2. Modify inbound or outbound synchronization rules.

Synchronize directories
After you define filtering for the objects that you plan to synchronize with Azure AD, you can configure
scheduled or manual synchronization. You can perform manual synchronization from the Synchronization
Service Manager or by using Windows PowerShell. In the Synchronization Service Manager, you can
manage Run Profiles that define the process of synchronization. You can configure the following Run
Profiles:
• Full Import
• Full Synchronization
• Delta Import
• Delta Synchronization
• Export
To synchronize objects from AD DS, you need to run the appropriate profile from the Synchronization
Service Manager. Alternatively, for manual synchronization, you can use the Azure AD Connect PowerShell
cmdlet Start-ADSyncSyncCycle.
Managing and monitoring directory synchronization

Directory synchronization relies on built-in
schedulers to carry out synchronization tasks.
Azure AD Connect includes two schedulers:
• A scheduler that handles password sync.

• A scheduler that handles object and attribute
sync.
The password sync scheduler initiates

synchronization in response to password change
and reset events, so typically there is no reason to
customize its behavior. By default, the object and
attribute sync scheduler performs synchronization
every 30 minutes. You can modify its behavior by using the Set-ADSyncScheduler Windows PowerShell
cmdlet. This allows you, for example, to set the next synchronization run to take the form of a full import
and sync rather than a delta-based synchronization only. The Start-ADSyncCycle cmdlet allows you to
run synchronization outside of the scheduled sync cycle. For example, to initiate a delta synchronization,
you can run Start-ADSyncCycle –PolicyType Delta.
You can use Azure AD Connect Health to monitor and gain insight into your on-premises identity
infrastructure and the synchronization services that Azure AD Connect provides. Azure AD Connect Health
is an Azure AD Premium feature, and it uses agents that reside on the directory synchronization
infrastructure. This infrastructure includes the server where you installed Azure AD Connect and, if you
implemented a federation between AD DS and Azure AD, it also includes the servers hosting AD FS, AD FS
proxy servers, and Web Application Proxy components. These agents collect information about events,
configuration settings, and performance of the synchronization operations, and then send the collected
information to the Azure AD Connect Health service.
Azure AD Connect Health for Sync monitors and provides information on the synchronizations that occur
between your on-premises AD DS and Azure AD. Azure AD Connect Health for Sync includes the
following key capabilities:
• Customizable alerts in response to changes in the synchronization status. For critical alerts, you can
subscribe to receive email notifications. Every alert contains suggested resolution steps, links to
documentation describing potential causes, and a history of previously resolved, matching alerts.
• Sync insight. The information available to you includes latency of sync operations and object change
trends. Information about synchronization latency originates from the Azure AD Connect server. The
synchronization objects change trend provides a graphical representation of the number of successful
and failed synchronizations.
To start Azure AD Connect Health, perform the following steps:

2. Locate Azure AD Connect Health by searching for it in the Azure Marketplace or by selecting
Marketplace, and then selecting Security + Identity.
3. On the introductory blade, click Create. This opens another blade with your directory information.
4. On the directory blade, click Create.
Implementing Azure AD DS
Azure AD DS is a Microsoft-managed AD DS
service. The service consists of two Active
Directory domain controllers in a new, single-
domain forest. When you enable the service, the
Azure platform automatically deploys these two
domain controllers to an Azure virtual network
that you designate. In addition, AD DS
automatically synchronizes its users and groups
with the Azure AD tenant associated with the
Azure subscription. Effectively, the Azure AD DS
domain will contain the same users and groups as
its Azure AD counterpart. This provides the
following capabilities:
• You can join Azure VMs to the Microsoft-managed Active Directory domain if they reside on the
same virtual network or another virtual network connected to it.
• Azure AD users can use their existing credentials to sign in to these Azure VMs.
If you have an on-premises Active Directory domain, you can also use Azure AD Connect to synchronize it
with an Azure AD tenant. This means that if you configure synchronization with same sign-on or SSO and
enable Azure AD DS in that Azure AD tenant, your on-premises users will be able sign in to the Azure
AD DS domain by using their existing credentials.
It is important to note that, in this scenario, the on-premises Active Directory domain is separate from the
Active Directory domain that Azure AD DS implements. The two Active Directory domains have different
domain names and separate sets of user, group, and computer objects, although the user and group
objects within the scope of Azure AD Connect synchronization have matching attributes.
Note: At the time of authoring this course, to enable Azure AD DS, you must use the Azure
classic portal. In addition, you must associate the two domain controllers with an Azure classic
virtual network. To provide Azure AD DS services to Azure VMs residing on virtual networks that
you provisioned by using the Azure Resource Manager deployment model, you must connect
these networks to the classic virtual network via VNet peering (in the same Azure region) or a
VNet-to-VNet connection (between the Azure regions).
Azure AD DS offers support for the same set of protocols and APIs as on-premises AD DS. With Azure AD
DS, you can migrate applications that depend on AD DS to Azure VMs without having to deploy and
maintain additional domain controllers or establish connectivity with the on-premises infrastructure.
Note: There are some differences between AD DS and Azure AD DS. For example, Azure
AD DS does not allow you to create trust relationships or extend the schema. Its user and group
objects are read-only. It also offers relatively limited support for Group Policy, with only two
built-in Group Policy Objects—one containing computer settings and another containing user
settings.
Additional Reading: For more information about Azure AD DS, refer to: “Azure AD Domain
Services” at: https://aka.ms/kzye0f
Demonstration: Implementing directory synchronization by using

Azure AD Connect
• Enable directory synchronization.
• Install Azure AD Connect by using custom settings.
• Synchronize users from on-premises AD DS.
Question: Is there a way to install Azure AD Connect unattended?
Question: Can you rename a server after you install Azure AD Connect on it?
Lesson 3
Implementing SSO in hybrid scenarios
AD FS can federate AD DS with Azure AD. This allows organizations to benefit from federation features
while accessing cloud resources and maintaining full control of organizational identities in their on-
premises environments.
Lesson Objectives
• Explain how AD FS and the Web Application Proxy roles interoperate.
• Prepare for deploying AD FS by using Azure VMs.

• Deploy AD FS by using Azure AD Connect.
• Perform basic AD FS management and maintenance tasks.
Overview of AD FS and Web Application Proxy

You can use Windows Server to provide a
federation-based SSO experience to on-premises
users across various cloud-based platforms. After
authenticating with AD DS credentials, users can
access Azure-based resources, Microsoft online
services (such as Exchange Online or SharePoint
Online) that rely on Azure AD authentication, and
software as a service (SaaS) applications
integrated with Azure AD.
This functionality requires directory

synchronization between the on-premises Active
Directory and the corresponding Azure AD tenant,
as did the Azure AD integration methods described earlier in this module. However, you must also deploy
a STS infrastructure, such as AD FS servers. Because such servers need be able to communicate directly
with the AD DS infrastructure, they must reside on the same internal network as AD DS domain
controllers. To provide the ability to authenticate via AD FS from the internet, you must also deploy
additional servers in your perimeter network that function as communication proxies of the AD FS servers.
You can use servers running the Web Application Proxy role service for this purpose.
AD FS provides the infrastructure that enables users to authenticate in one environment and use that
authentication to obtain access to resources in another. AD FS works seamlessly with AD DS to relay
tokens that contain information about users in on-premises AD to resource providers.
If a user initiates an authentication request through AD FS by using an AD FS client such as a supported

internet browser, AD FS first forwards the request to AD DS. If the Active Directory authentication is
successful, the STS component of the AD FS server issues an appropriately formed security token. The user
can then present this token as the authentication proof to another service such as Azure, Office 365, or a
non-Microsoft cloud or application provider.
How AD FS works with Azure AD

The steps listed below describe the process of signing in to a browser-based SaaS application integrated
with Azure AD when using AD FS:
1. The user opens a web browser and sends an HTTPS request to the SaaS application.
2. The SaaS application determines if the user belongs to an Azure AD tenant. The SaaS application
provider then redirects the user to the user’s Azure AD tenant.
3. The user’s browser sends an HTTPS authentication request to the Azure AD tenant.
4. If the user’s Azure AD account represents a federated identity, the user’s browser is redirected to the
on-premises federation server.
5. The user’s browser sends an HTTPS request to the on-premises federation server.
6. If the user has signed in to the on-premises AD DS domain, the federation server requests the AD DS
authentication, based on the user’s existing Kerberos ticket. Otherwise, the user receives a prompt to
authenticate with the AD DS credentials, which the federation server relays to an AD DS domain
controller.
7. The AD DS domain controller verifies the authentication request and then sends the successful
authentication message back to the federation server.
8. The federation server creates the claim for the user based on the rules defined in the AD FS
configuration. The federation server places the claims data in a digitally signed security token and
forwards it to the user’s browser.
9. The user’s browser forwards the security token containing claims to Azure AD.
10. Azure AD verifies the validity of the AD FS security token based on the existing federation trust. It
creates a new token for the purpose of accessing the SaaS application and sends it back to the user’s
browser.
11. The user uses the Azure AD–issued token to access the SaaS application.
AD FS supports authentication based on the Web Services Federation (WS-Federation) and Security
Assertion Markup Language (SAML) protocols. AD FS enables organizations to implement advanced
identity management solutions, such as account provisioning and deactivation, or credential mapping.
Authentication occurs through one of several methods. AD FS supports:
• Forms authentication, which is the default for internet-based access.
• Certificate authentication, such as smart card or client certificates.
• Windows authentication, which is the default for intranet-based requests. Forms authentication serves
as the fallback, because many browsers might not support Windows authentication.
• Device authentication, which leverages the device registration capabilities.
• Azure Multi-Factor Authentication, which allows you to take advantage of the multi-factor
authentication capabilities of Azure AD.
In the AD FS architecture, the AD FS servers communicate directly with AD DS. Because of this direct
connectivity, AD FS servers need the same levels of protection as domain controllers. To facilitate external
authentication requests crossing public internet, AD FS supports a separate set of servers serving as
proxies. AD FS proxy servers typically reside in a perimeter network, accept authentication requests, and
then forward them to AD FS servers through port 443 (SSL). This is the only port that needs to be open
between the proxy and the AD FS servers.
There have been several versions of AD FS since the initial release, including:
• AD FS 1.0, originally released as a Windows component with Windows Server 2003 R2.
• AD FS 1.1, released with Windows Server 2008 and Windows Server 2008 R2 as an installable server
role.
• AD FS 2.0, released as an installable download for Windows Server 2008 Service Pack 2 and later.
• AD FS 2.1, released with Windows Server 2012 as an installable server role.
• AD FS 3.0, is an installable server role on Windows Server 2012 R2. AD FS 3.0 does not require a
separate Internet Information Services (IIS) installation, and it includes a new AD FS proxy role called
Web Application Proxy.
• AD FS 4.0, is an installable server role on Windows Server 2016. Similar to its predecessor, AD FS 4.0
does not require a separate IIS installation and includes the Web Application Proxy role.
AD FS on Windows Server 2012 R2 and Windows Server 2016

In Windows Server 2012 R2, AD FS includes a federation service role service that acts as an identity
provider or federation provider. It supports device Workplace Join for SSO and seamless multi-factor
authentication. Devices register in AD DS through a Device Registration Service (DRS) and use an X509
certificate bound to the user context on that machine for device authentication. In a default configuration,
users sign in through AD FS to initiate the join process by using their Active Directory credentials.
AD FS can provide conditional access control based on user attributes, such as UPN, email or security
group membership, device attributes such as Workplace Join, and request attributes such as network
location or IP address.
Since the introduction of Windows Server 2012 R2, device registration capabilities have been steadily
shifting to Azure AD. Similarly, Azure AD became a full-fledged authentication provider for on-premises
environments. AD FS included in Windows Server 2016 takes full advantage of these trends. This allows
you to use AD FS to implement functionality such as:
• Sign-in with Azure Multi-Factor Authentication. This allows you to configure Azure Multi-Factor
Authentication as either the primary or an additional authentication method. It is important to note
that the Multi-Factor Authentication adapter included in AD FS in Windows Server 2016 can protect
access to on-premises resources without an on-premises Azure Multi-Factor Authentication server.
This was necessary in Windows Server 2012 R2.
Additional Reading: For more information regarding configuring AD FS 2016 and Azure
Multi-Factor Authentication, refer to: “Configure AD FS 2016 and Azure MFA” at:
https://aka.ms/azrhs6
• Password-less access from compliant devices. This feature leverages Azure AD device registration to
configure policies that enforce conditional access to on-premises resources based on the status of a
user’s devices.
• Support for sign-in with Windows Hello for Business. AD FS allows users with Windows 10 devices to
sign in to AD FS–protected applications on-premises or from the internet by relying on Windows
Hello, without requiring a password.
Planning for the deployment of AD FS with Azure

When planning for AD FS, you should consider a
range of factors that the following section
describes.
Plan server placement

The most critical components of an AD FS
deployment are federation servers, typically
operating as a server farm. Therefore, it is
important to consider the proper server
placement. AD FS servers must be domain
members, and you should place them behind a
firewall on the organization’s internal network. AD
FS proxies should not be domain members, and
you should install them in a perimeter network.
Plan network connectivity

Firewall configuration is relatively simple because external clients only need the TCP 443 port to connect
to the AD FS Proxy or the Web Application Proxy endpoint. The proxy then communicates with AD FS by
using the same port TCP 443.
Note: When implementing certificate authentication, you must also allow connectivity on
TCP port 49433 between external clients and the proxy servers.
Plan DNS name resolution

DNS domain names must match between on-premises Active Directory and Azure AD. This means that
the Active Directory UPN suffix is the same as a registered domain name in Azure.
In addition, you must ensure that all client requests targeting AD FS resolve to the intended access point
of the AD FS service, depending on whether the clients are on the internal network or on the internet.
Internal clients should connect directly to the AD FS server and external clients should connect to the
federation proxy (AD FS Proxy or Web Application Proxy). This means that the same DNS name should
resolve to different IP addresses depending on the origin of the name resolution query. To achieve this,
you can implement an internal and an external DNS server and create AD FS–specific records on each
server. For example, if the host name to connect to your AD FS infrastructure is adfs.contoso.com, you
would create the DNS records displayed below.
Internal DNS
Contoso.com internal DNS zone would contain the following record.
Host name Address
Adfs 192.168.0.12
Where 192.168.10.12 is the IP address of the AD FS server farm.

External DNS
Contoso.com external DNS zone would contain the following record.
Host name Address
Adfs 131.107.21.65
Where 131.107.21.65 is the IP address of the proxy array.
Additional Reading: Starting with Windows Server 2016, you can implement this
functionality on a single DNS server by using Windows DNS Server policies. For more information
regarding this feature, refer to: “Split-Brain DNS Deployment Using Windows DNS Server Policies”
at: https://aka.ms/lxcb1o
Plan certificates
AD FS uses certificates for two main purposes:
• Token exchange
• SSL encryption
For token exchange, AD FS can use self-signed certificates. These certificates only validate that content
has not been modified in transit, so they typically do not have to be issued by a trusted certification
authority (CA). AD FS automatically renews self-signed certificates.
For SSL encryption, certificates must come from a public CA that AD FS clients trust. All AD FS servers
must use the same SSL certificate. The AD FS configuration, including the SSL certificate thumbprint,
replicates through a Windows Internal Database (WID) or is shared across SQL Server databases on all the
members of the AD FS server farm. AD FS proxies do not need to use the same public certificate as
internal AD FS servers, because AD FS proxies do not share configuration information. Additionally, each
AD FS proxy server can use a different SSL certificate, if the common name (CN) on each certificate
matches the service name of the internal AD FS servers. However, it is possible for all AD FS servers and
AD FS proxy servers to use the same certificates.
Plan capacity
When determining how many AD FS servers to deploy in an organization, you should consider several
factors. These factors include the number of users issuing authentication requests, the server hardware,
and the type of AD FS configuration database. To determine the optimal configuration, use the AD FS
Capacity Planning Spreadsheet for Windows Server 2016 available at: https://aka.ms/lh5a7w. You will find
the Windows Server 2012 R2 version of the spreadsheet at: https://aka.ms/owotvp.
Plan availability
You can implement AD FS as a standalone server or as a server farm. We recommend always using an
AD FS server farm, even if the farm consists initially of just one server, because this provides the option to
add more AD FS servers later for load balancing or fault tolerance. If you deploy AD FS as a standalone
federation server, then you cannot add additional servers later.
To provide high availability, AD FS servers typically operate as a server farm, with client requests load-
balanced by using software or hardware load balancers. A load balancer exposes a single IP address for
the load-balancing array that you must then associate with the DNS name representing your AD FS
endpoint. You also must include the same name as the CN or subject alternative name of the SSL
certificate. The proxy servers, including Web Application Proxy servers also require load balancing. Note
that Azure AD Connect does not automate the configuration of load balancers.
Plan database servers

AD FS servers require a database, which you can implement as a WID or a SQL Server instance. If using
WID, then you must configure AD FS servers in a farm as either primary or secondary. The primary
federation server is initially the first federation server in the farm, and it has a read/write copy of the
AD FS configuration database. All other federation servers in the farm (the secondary servers) regularly
poll the primary server and synchronize any changes to a locally stored, read-only copy of the AD FS
configuration database. By default, the poll interval is five minutes. You can change its value by using the
Set-AdfsSyncProperties Windows PowerShell cmdlet. To force immediate synchronization, restart the
AD FS service.
Secondary servers provide fault tolerance for the primary server, and with appropriate server placement,
they can load-balance access requests across network sites. If the primary federation server is offline, all
secondary federation servers continue to process requests as normal. However, you cannot make changes
to the AD FS database until the primary federation server is back online or a secondary server is promoted
to the primary role. You can use the Set-AdfsSyncProperties Windows PowerShell cmdlet to manage
primary and secondary role assignment. If SQL Server stores AD FS information, all servers in the farm are
considered primaries because they all have read/write access to the database.
Plan AD FS service accounts

You must provide an account that will provide a security context for the AD FS service accounts. You can
use a domain user account or a Group Managed Service Account (gMSA) for this purpose. The latter
requires domain controllers that run Windows Server 2012 or newer. The advantage of a gMSA is that its
password changes are automatic, which lowers management overhead and increases security.
Plan conditional access

You might want to implement conditional access. For example, you might restrict the ability to
authenticate to users residing in a particular location or force users to provide a second form of
authentication.
Plan for devices and browsers

Any current web browser with JavaScript enabled can work as an AD FS client. However, Microsoft has
only tested Internet Explorer, Microsoft Edge, Mozilla Firefox, and Safari on Mac.
To allow SSO, you need to enable cookies when interacting with federation servers and their proxies.
Cookies prevent repeating prompts for sign-ins within the same session. The authentication cookie is
signed but not encrypted. AD FS provides encryption by ensuring SSL-based communication.
Deploying AD FS
Azure AD Connect simplifies the AD FS installation
process. After you ensure that your environment
meets the prerequisites described in the previous
topic, the process of installing Windows roles and
features and their dependencies is automated. For
deploying AD FS by using Azure AD Connect, you
need:
• One or more computer running Windows
Server 2012 R2 or newer to host AD FS.
• One or more computers running Windows
Server 2012 R2 or newer to host Web
Application Proxy.
• An SSL certificate for the federation service name that you intend to use.
To install AD FS by using Azure AD Connect, perform the following steps:
1. Start Azure AD Connect setup.
2. On the Express Settings page, click Customize.
3. On the Install Required Components page, click Install.
4. On the User Sign-in page, select Federation with AD FS, and then click Next.
5. On the Connect to Azure AD page, type the credentials for the account that has the Global
Administrator role in the Azure AD tenant with which you want to establish federation.
6. On the Connect your directories page, specify the Active Directory forest and click Add Directory.
When prompted, in the AD Forest Account window, ensure that the Use existing account option is
selected, and then type a pre-created account you intend to use for synchronization. Alternatively,
you can select the Create new account option, provide the credentials of an AD DS Enterprise
Administrator account, and then click OK. This will create the synchronization account for you.
7. On the Connect your directories page, click Next.

8. On the Azure AD sign-in configuration page, verify that your Azure AD tenant has an existing
custom domain. The name of the custom domain should match the Active Directory UPN suffix. Note
that, at this point, your custom domain does not have to be verified yet. If a custom domain does not
exist, create a new custom domain and refresh the page.
9. On the same page, you will also find the option to specify which on-premises attribute you want to
use as the Azure AD user name. By default, Azure AD Connect uses userPrincipalName for this
purpose.
10. Click Next.
11. On the Domain and OU filtering page, specify any custom filtering settings.
12. On the Uniquely identifying your users page, select the criteria to use when merging multiple
accounts of individual users that exist in more than a single AD DS forest.
13. On the Filter users and devices page, specify whether to limit the scope of synchronization to
members of an individual group.
14. On the Optional Features page, select additional synchronization features that you intend to
implement.
15. On the AD DS Farm page, select Configure a new AD FS farm. Browse to and select the certificate
for SSL, and then provide the password for the certificate. Alternatively, you can use a certificate
installed on servers that will host the AD FS server role. After you provide the certificate, you will also
need to select the certificate subject name and prefix that you intend to use for the federation
servers.
16. Click Next.
17. On the AD FS servers page, add one or more domain-joined servers that will host AD FS by
specifying their names or IP addresses.
18. On the Web Application Proxy servers page, add one or more servers that will provide the AD FS
proxy functionality. When prompted, type the credentials for the user account that has local
administrator privileges on the proxy servers. That account will establish connectivity with Web
Application Proxy.
Note: All servers must be accessible from the Azure AD Connect server via Windows Remote
Management (WinRM).
19. On the Domain Administrator credentials page, specify the user name and the password of a
domain administrator account.
20. On the AD FS service account page, create a new gMSA, specify an existing one, or provide an
existing domain user account.
21. On the Azure AD Domain page, select the Azure AD domain that you want to federate with AD DS.
If the domain is not verified, you will have to perform verification at this point before proceeding.
22. On the Ready to configure page, review the installation steps, ensure that the Start the
synchronization process as soon as the configuration completes check box is selected, and then
click Install.
23. After the installation completes, you can verify AD FS functionality by clicking Verify.
Managing and maintaining AD FS

After you deploy AD FS, you will occasionally need
to perform various management and maintenance
tasks.
Manage the certificate life cycle

As mentioned earlier, the self-signed certificates
that AD FS generates for signing purposes support
automatic rollover, resulting in automatic renewal
once per year. You must manage renewal of all
other certificates that an internal or external CA
issued, and use them to replace the existing ones.
You can view certificate expiration dates for the
service communication, token-decrypting, and
token-signing certificates by using the AD FS Management console. In the console tree, expand Service,
and then click Certificates. You can also use the Get-ADFSCertificate Azure AD PowerShell cmdlet to
view certificate details.
Convert domains to federated

Configuring an on-premises Active Directory forest as federated creates a relying party trust between
Azure AD and the on-premises AD DS domain. After conversion, synchronized on-premises users become
federated users, making it possible for them to use their organizational credentials to authenticate when
accessing Azure resources. If you have an additional existing Active Directory domain that you need to
implement as a federated domain, you can run Azure AD Connect again.
Monitor AD FS with Azure AD Connect Health

You can monitor AD FS functionality by relying on Azure AD Connect Health, which uses agents that
reside on AD FS servers and proxy servers. These agents collect events, configuration settings, and
performance metrics, and forward them to the cloud-based Azure AD Connect Health service. The Azure
portal displays the collected data, presenting it in the following autogenerated views:
• The Alerts view shows information about active alerts that represent events, configuration
information, and synchronization status of AD FS. For critical alerts, you can subscribe to email
notifications. Every alert contains resolution steps, links to additional documentation, and a history of
the previously resolved alerts.
• The Usage Analytics view shows information about successful logins, the authentication method,
and the number of users who are accessing AD FS–protected applications. You can also generate
audit reports from AD FS servers.
• The Monitoring view shows a summary of performance counters that are collected from AD FS
servers, such as CPU utilization, memory, and latency.
To install the Azure AD Connect Health agent on the AD FS server, perform the following steps:
1. Sign in to the Azure portal with the global administrative account.
2. In the Azure Marketplace, locate the Azure AD Connect Health extension.

3. Download the Azure AD Connect Health agent for AD FS.
4. Double-click the .exe file that you downloaded.
5. Click Install, and then follow the installation procedure.

6. After the installation completes, click Configure Now.
7. This opens Windows PowerShell with elevated privileges. Run the Register-
AzureADConnectHealthADFSAgent cmdlet.
8. Sign in to Azure to complete the agent configuration.
Question: What are AD FS deployment options that provide resiliency and scalability?
Lab: Implementing and managing Azure AD

synchronization
Scenario
A. Datum Corporation users access on-premises applications by authenticating once, during initial sign-in
to their client computers. While evaluating Azure for A. Datum, you must verify that A. Datum users can
continue using their existing credentials to access Azure resources. In addition, you must verify that
attribute changes to Active Directory user and group accounts in on-premises Active Directory
automatically replicate to Azure AD.
Objectives
• Configure directory synchronization.
• Synchronize on-premises Active Directory with Azure Active Directory.
Lab Setup
User name: Student

Password: Pa55w.rd
Before starting this lab, ensure that you have performed the “Preparing the Azure environment”
demonstration tasks at the beginning of the first lesson in this module, and that the setup script has
completed.
Question: How would you implement OU–level filtering for directory synchronization?
Question: When would you use Azure AD Connect custom setup?


Review Question
Question: What Azure AD integration option would you consider to be optimal in your
environment?
Tools
The following section lists the tools that this module references.
• Azure Active Directory PowerShell module version 2. Provides necessary Windows PowerShell cmdlets
for user management, domain management and configuring SSO. You can find more details at
https://aka.ms/qqxznd.
• Microsoft Azure Active Directory module for Windows PowerShell (64-bit version). An older version of
Azure AD module for Windows PowerShell. Its functionality overlaps with the functionality that Azure
Active Directory PowerShell module version 2.0 provides. However, it offers some unique device-
management capabilities (such as identifying devices registered by a given user with a single cmdlet).
It is available from: http://aka.ms/Cuedhw.
• Microsoft Azure Active Directory Connect. Enables directory synchronization, password pass-through
with SSO, or federation of on-premises AD DS with Azure AD. It is available from: http://aka.ms/Jlpj42.

Typical problems that affect Azure AD

Connect–based synchronization include:
• Connectivity issues
• Errors during synchronization
• Password synchronization issues
11-1
Module 11
Implementing Azure-based management and automation
Contents:
Lesson 1: Implementing OMS 11-2
Lesson 2: Implementing Azure Automation 11-9
Lesson 3: Implementing Automation runbooks 11-15

Lesson 4: Implementing Azure Automation–based management 11-22
Lab: Implementing Automation 11-26
Module Overview
Microsoft Operations Management Suite (OMS) and Microsoft Azure Automation are services that you
can use to monitor and manage Microsoft Azure and on-premises resources. In this module, you will learn
about these services, their architecture, and their main characteristics. You will also step through the
process of implementing the most common OMS solutions. This module also describes the different types
of runbooks that Azure Automation supports, and how you can publish and execute these runbooks.
Objectives
• Implement OMS solutions.
• Implement the core components of Azure Automation.
• Implement different types of Azure Automation runbooks.

• Implement Azure automation-based management.
11-2 Implementing Azure-based management and automation
Lesson 1
Implementing OMS
OMS is a service that provides monitoring, analytics, and management capabilities for both on-premises
and cloud resources. You can derive significant benefits from these capabilities in a variety of business
scenarios, including tracking, auditing, or troubleshooting past events, optimizing administration of your
current environment, and forecasting and capacity planning for your future deployments.
This lesson describes the level of integration between OMS and other Azure services. It also describes the
architecture and extensibility of OMS, and the steps you need to follow to implement it.
Lesson Objectives
• Describe the role of OMS in the context of overall Microsoft Azure offerings.
• Describe the architectural components of OMS.

• Implement an OMS workspace and populate it with solutions and data connection sources.

module
the lab.
Important: The scripts that you use in this course might delete objects that you have in
your subscription. Therefore, you should complete this course by using a new Azure subscription.
You should have received sign-up details and instructions for creating an Azure learning pass for
this reason. Alternatively, you can create a new Azure trial subscription. In both cases, use a new
the environment for demonstrations and labs, and Remove-20533DEnvironment to perform clean-up
tasks at the end of the module.
Introducing OMS
OMS extends the functionality originally
implemented in Azure Operational Insights, which,
in turn, superseded Microsoft System Center
Advisor. Knowing the lineage of the service might
help you understand references to Operational
Insights that you might encounter in some of the
earlier product documentation. The core
component of OMS is Log Analytics, which
handles log collection, facilitates analyzing log
content, and provides extensive search
capabilities. OMS also offers a range of
management features by integrating with a
number of Azure services such as Automation, Backup, and Recovery Services.
Architecture
From the architectural standpoint, OMS operates as a web service, which interacts with a number of
distinct components that facilitate data collection, analysis, and visualization. The OMS architecture
consists of the following components:
• Connected data sources represent monitored systems, which belong to one of five main categories:
o Windows or Linux server or Windows client operating system running the Microsoft Monitoring
Agent connected to the OMS service (the agent is available for Windows 32-bit and 64-bit
systems, in addition to Linux).
Note: These systems can reside on-premises, in Azure, or in datacenters that other cloud
providers manage.
o System Center Operations Manager (SCOM) management groups, including all systems that are
part of these groups. Considering that SCOM is supported on-premises and in Azure, the
integration with OMS is available in each of these scenarios.
o Azure Storage accounts used by Azure VMs configured with the Windows Azure Diagnostic VM
extension or the Linux Azure Diagnostic VM extension, or by Cloud Service worker and web roles
with the Windows Diagnostic VM extension.
o Azure Activity Log that the Azure platform uses to record all write operations. These operations
include PUT, POST, and DELETE actions targeting any of the Azure Resource Manager resources
in your subscriptions.
o Azure service diagnostics, logs, and metrics generated by a wide range of Azure services.
Depending on the service type, you can:
 Write service diagnostics directly to Log Analytics.
 Collect diagnostics data that services store in an Azure Storage account.
 Rely on Log Analytics connectors to provide a communication path between services and
Log Analytics.
 Use scripts to collect and post service data to Log Analytics.
• OMS repository designates Azure-based storage for data that OMS collects from connected sources.
• OMS workspace represents the administrative and security boundary of the OMS environment. It also
defines the scope of data collection, analysis, and visualization. Each workspace has a unique
Workspace ID and is associated with the primary and secondary keys that serve as its authentication
mechanism. Knowledge of these parameters (the ID and at least one of the two keys) is necessary to
join a system to the workspace (this is equivalent to the way of controlling access to an Azure Storage
account). You can create multiple workspaces in the same Azure subscription.
• OMS solutions build on the core functionality of the service by implementing log processing and
analytics rules. These rules derive meaningful information from raw data collected from connected
data sources. Some of the OMS solutions also extend the scope of collected data. All currently
available solutions appear in the OMS Solutions Gallery. You can browse through this list and add
them directly to your workspace.
• OMS portal provides a web-based interface for configuring OMS data collection, managing OMS
solutions, and viewing results of OMS-based analytics for the solutions that you added to the
workspace.
Note: If data sources do not have direct connectivity to Azure, you need to implement
OMS Gateway. OMS Gateway serves as a proxy and relays collected data to the OMS repository.
Solutions
OMS solutions constitute the primary method of extending the core capabilities of the service. Due to this
extensibility, you can easily add to the workspace any solution that is available in the OMS Solutions
Gallery. However, it is important to keep in mind that adding solutions impacts pricing and the volume of
the collected data, which has bandwidth and storage implications.
Note: Third-party developers can create their own management solutions that integrate
with OMS and make them available via Azure Marketplace.
Some of the most commonly used solutions include:
• AD Assessment. Assesses health and vulnerabilities of your AD DS deployment.
• AD Replication Status. Identifies the AD DS replication status and helps you discover and troubleshoot
any replication issues.
• Alert Management. Keeps track of the alerts that OMS generates. Additionally, in integration
scenarios, it keeps track of the alerts that Operations Manager generates, to help you triage issues
and perform root cause analysis.
• Change Tracking. Keeps track of changes to your managed environment.
• Key Vault. Monitors Azure Key Vault logs, allowing you to determine its usage patterns.
• Malware Assessment. Checks the status of antivirus and antimalware scans on monitored systems.
• Networking Performance Monitor. Performs near real-time network monitoring to help you evaluate
network performance and reliability.
• Security and Audit. Collects security-related events so that you can respond promptly or even prevent
any security exploits.
• Service Fabric. Monitors operational status of Service Fabric clusters.
• Service Map. Discovers dependencies between software components across all monitored servers.
• SQL Assessment. Assesses health and vulnerabilities of your Microsoft SQL Server deployments.
• System Update Assessment. Identifies missing system updates on monitored systems.
• Wire Data. Gives you the ability to analyze network traffic based on collected metadata.
• Automation. Integrates with Azure Automation and delivers its status and statistical data and
simplifies management by providing links to automation-related features in the Azure portal.
• Azure Site Recovery. Monitors replication status of systems protected by an Azure Site Recovery vault.
• Backup. Oversees the status of backups that Azure VM Backup and Windows Server Backup perform
to an Azure Backup vault. It also integrates with the Azure portal, thereby simplifying management.
Service pricing
The cost of OMS services depends on the pricing model you choose. The first model includes functionally
related solutions grouped into four categories:
• Insight & Analytics. Includes Log Analytics, application and server dependency mapping, network
performance monitoring, and rights to use System Center 2016 Operations Manager.
• Automation & Control. Includes Azure Automation, desired state configuration, change tracking, and
update management, and rights to use System Center 2016 Configuration Manager, Service Manager,
and Orchestrator.
• Security & Compliance. Includes advanced security and audit, malware threat analysis, and Azure
Security Center.
• Protection & Recovery. Includes Azure Backup, Azure Site Recovery, and rights to use System Center
2016 Virtual Machine Manager and Data Protection Manager.
This model is priced per node, per category, and per month, and includes all solutions in one or more
categories that you choose.
The second model, referred to as the OMS subscription, requires annual commitment and consists of two
service offerings:
• E1. Includes Insight & Analytics and Automation & Control, along with full System Center 2016 usage
rights.
• E2. Includes all four service offerings, along with full System Center 2016 usage rights.
The third model is available to existing System Center customers. It allows them to either obtain access to
OMS services via an add-on for System Center or by applying OMS subscription for System Center
conversion, depending on whether they are in the middle of a multi-year System Center agreement or if
they are near its renewal date.
The fourth model, known as the standalone service tier, gives you the pay-as-you-go option without the
daily data upload limits, with data retention of 30 days, and with individually selected management
solutions.
Finally, you also have the ability to use Log Analytics or Azure Automation for free, with 500 MB daily
upload limit, 7-day data retention, and 500 minutes per month of Azure Automation runbook runtime.
Additional Reading: To determine the estimated cost of your OMS implementation, refer
to: “Operations Management Suite Calculator” at: https://aka.ms/jxiesu
OMS as a component of Azure

OMS has a unique role in the range of Azure
services. Its primary purpose is to facilitate the
monitoring and analysis of your existing on-
premises and cloud-based environments. It also
offers some management capabilities through
integration with other Azure services such as
Azure Automation, Azure Backup, or Azure Site
Recovery. You can implement its functionality
through extensions known as solution packs,
which you can easily add after provisioning the
core service.
OMS supports Azure VMs and platform as a
service (PaaS) Cloud Services. It also allows you to collect and analyze Azure VM diagnostics data residing
in Azure Storage accounts. Its scope extends to on-premises locations and third-party cloud
environments, by relying on agents deployed to monitored computers, or by leveraging integration with
Operations Manager.
Introduction to implementing OMS solutions

To implement OMS solutions, perform the
following steps:
1. From the Azure portal, create an OMS

workspace by adding the Log Analytics
service to your subscription. When you create
the workspace, you will need to specify:
o A unique name, in the

portal.mms.microsoft.com DNS
namespace
o The service tier—Free, Per GB

(standalone), or Per Node (OMS)
o The Azure region to host the workspace

o The resource group where the workspace will reside
Alternatively, you have the option to sign up for OMS and, at the same time, create a new Azure
subscription by going to the OMS website at: https://aka.ms/ugbt8t.
2. After you have activated the workspace, you can connect to it. To do so from the Azure portal, on the
Log analytics blade, click OMS Portal.
3. In the OMS portal, select the solutions that you want to use from Solutions Gallery. Alternatively,
you can add solutions from the Azure Marketplace via the Azure portal.
4. To collect data, you also need to add connected data sources. The method you need to use depends
on the location and type of target systems. For example:
o To add Azure VMs that reside in the same subscription as the OMS workspace, use the Connect
option available from the OMS workspace in the Azure portal. Alternatively, you can use Azure
PowerShell or Azure Resource Manager templates. To add servers or clients that are running
Windows, are not SCOM clients, and are not part of your Azure subscription, download and
install the Microsoft Monitoring Agent on each server or client. The download link is available
directly from the OMS portal. The installation will require you to provide the workspace ID and
one of two workspace keys (primary or secondary).
o To add servers running the Windows Server operating system, or clients running the Windows
operating system, which are SCOM clients, use the Operations Management Suite Connection
from the Operations Manager console. You can install the Microsoft Monitoring Agent manually
and specify the management group that the local computer is part of, but this approach is less
efficient.
o To add diagnostics data from Azure VMs (Windows or Linux) and Azure Cloud Services web and
worker roles configured with the Azure Diagnostic VM extension, specify the Azure Storage
account that stores the data.
o To add Azure service logs and metrics that other Azure services generate, you can:
 Write service diagnostics directly to Log Analytics. This option is available with any service
that supports the Azure Monitor functionality. To implement it, you can use the Set-
AzureRmDiagnosticsSetting cmdlet. Alternatively, you can apply an Azure Resource
Manager template that configures the workspaceId property of the service.
 Collect diagnostics data that services store in an Azure Storage account.
 Configure connectors to provide a communication path between services and Log Analytics.
This approach allows you to collect data that Application Insights generates.
 Use scripts to collect and post service data to Log Analytics.
Additional Reading: For details regarding collecting Azure service logs and metrics for use
in Log Analytics, refer to: “Collect Azure service logs and metrics for use in Log Analytics” at:
https://aka.ms/uyup65
5. Specify one or more logs from which you want to upload content to the OMS repository. You have
the option to enable data collection for Windows Event logs, Windows performance counters, Linux
performance counters, Internet Information Services (IIS) logs, Syslog, and custom logs.
Once data is uploaded to the OMS Repository, the service analyzes its content by applying logic defined
by the solutions you added to the workspace. The portal displays the outcome of this analysis on its home
page. From here, you can perform log searches and view information generated by individual solution
packs.
Note: By default, whenever you add a solution to your OMS workspace, that solution is
automatically deployed to all managed computers that support it. In some cases, you can
implement Solution Targeting which limits the scope of a deployment by allowing you to specify
a computer group as its target. To create a computer group, you can use Analysis Log search
results or use an import from Active Directory Domain Services or Windows Software Update
Services. Solution Targeting is not available for solutions that do not deploy to agents. It is also
not supported in scenarios where agents are part of an Operations Manager management group.
Note: At the time of authoring this content, Solution Targeting is in preview.
Demonstration: Implementing OMS solutions

• Create an OMS workspace.
• Install the Microsoft Monitoring Agent on an Azure VM.
• Add solutions to OMS.
• Perform searches of collected data.
• Configure log collection.

Question
For which of the following Azure services can you send log data directly to an OMS
workspace, without using an Azure Storage account as intermediary storage?
An Azure VM running Linux
An Azure Cloud Services worker role
An Azure web app
An Azure VM running Windows Server
An Azure Automation account

Lesson 2
Implementing Azure Automation
In this lesson, you will learn about the architecture, capabilities, and main components of Azure
Automation. You will learn about the process of creating an Azure Automation account and its assets. In
addition, you will become familiar with extending the scope of Azure Automation to on-premises systems
by leveraging Hybrid Runbook Workers.
Lesson Objectives
After completing this lesson, you should be able to:
• Identify the role of Azure Automation in the context of the overall Azure offering.
• Describe the architecture of Azure Automation and list its components.
• Explain how to create an Azure Automation account and its assets.
• Describe how to use Automation runbooks on-premises.

• Create an Azure Automation account and its assets.
Introducing Azure Automation

Azure Automation has undergone significant
enhancements since its introduction as a cloud-
based service. Initially, its capabilities were limited
to managing Azure-resident services. It relied
exclusively on Azure PowerShell workflows, which
you could typically create via the Azure classic
portal–based textual editor. Since then, not only
has Azure Automation become available on-
premises, but you can also use it with Windows
PowerShell scripts, which are considerably more
familiar to a typical information technology (IT)
professional. You can now mitigate the challenges
of creating workflows by using a graphical editor to create them, directly from the Azure portal. In
addition, both Azure VMs and on-premises systems can benefit from the support for Desired State
Configuration (DSC). DSC integrates with Azure Automation, ensuring that the state of managed
resources does not change over time in an uncontrolled manner.
The core component of Azure Automation is an account. An Automation account serves as a container of
automation components, such as Azure PowerShell modules, scripts, and workflows, or credentials and
certificates used to connect to other Azure services. You can create multiple Automation accounts per
Azure subscription. For example, you might want to separate management of your development and
production environments, with each of them containing different settings. You can define these settings
by creating Automation assets, which include Windows PowerShell modules, credentials, certificates,
connections, schedules, and variables.
When working with Azure Automation, another term that you will encounter often is activity. You might
find this term confusing, because it appears in two distinct contexts. The first one refers specifically to
Windows PowerShell workflow activities. It is important to realize that, while you express activities by
using the same verb-noun combination as Windows PowerShell cmdlets, you implement them differently
(by using Windows Workflow Foundation). As a result, there are some unique rules that dictate how you
use Windows PowerShell workflow activities. We will explore these rules in the next lesson of this module.
The second meaning of the term activity is generic and represents an individual automation task that you
implement, which typically refers to either a Windows PowerShell cmdlet or a Windows PowerShell
workflow activity.
Additional Reading: For more information, refer to: “Azure Automation in Depth:
Runbook Authoring” at: http://aka.ms/B9r14h
Assets and activities become building blocks of PowerShell workflows and scripts, which result in the
creation of Automation runbooks. Runbooks deliver the core functionality of the Azure Automation
service, executing your custom scripts either on demand or according to your chosen schedule. Each unit
of runbook execution is referred to as a job.
Another approach to delivering the equivalent functionality of runbooks relies on Windows PowerShell
DSC. This technology, introduced in Windows PowerShell 4.0, allows you to define a configuration that
you want to apply to managed computers and then deliver this configuration to them in the push or pull
manner. Push indicates that you actively deploy the configuration to target computers. With the pull
approach, target computers periodically copy the configuration from a designated location, known as a
pull server. Azure Automation allows you to create such configurations, store them on an Azure-resident
DSC pull server, and apply them to Azure VMs.
Automation runbooks run in Azure, so, by default, they cannot directly target your on-premises resources.
However, it is possible to accomplish this by deploying intermediary systems known as Hybrid Runbook
Workers. These systems, operating typically in groups for resiliency reasons, reside on your local network
and communicate with Azure Automation to execute its runbooks against local computers.
Azure Automation as a component of Azure

Azure Automation is an Azure service with the
primary objective of automating a variety of
repetitive and long-running tasks, both in Azure
and on-premises. With the introduction of the
Desired State Configuration component, Azure
Automation also allows you to maintain consistent
configuration of managed resources.
Azure Automation relies on Windows PowerShell
and PowerShell workflows to provide the
automating functionality. As a result, you can
implement any noninteractive procedure, as long
as it is possible to script it with Windows
PowerShell. Your inventiveness and scripting skills play a significant role in determining the scope of
application for Azure Automation. Among the more common uses of Azure Automation are scheduled
provisioning and deprovisioning of Azure VMs. Workflows provide additional resiliency, automatically
resuming any interrupted tasks.
Creating Azure Automation accounts and assets

To configure Azure Automation, you must first
create an Automation account. As the previous
topic mentioned, the Automation account defines
the scope for other Automation components,
including assets and runbooks.
You can create an Automation account by using
one of the following methods:
• Automation & Control from the Azure

Marketplace. This method creates a new
Azure Automation account and a new OMS
workspace, and automatically links them to
each other. Log Analytics then collects
automation-related logs and diagnostics data, simplifying its analysis.
• Automation service from the Azure Marketplace. This method creates a new Azure Automation
account without a corresponding OMS workspace. You can link the Automation account to an OMS
workspace afterwards, if both of them reside in the same region and are part of the same Azure
subscription.
• OMS Management solutions. With this method, you first select an Azure Marketplace solution, such
as Update Management, Start/Stop VMs during off hours, or Change Tracking. Your selection
will trigger a prompt, asking you to either specify an existing Azure Automation account and OMS
workspace or create new ones, if preferred.
After you create an Automation account, you can start populating it with Automation assets. Assets
represent configurable components that you can use to build Automation runbooks. The assets are
grouped into the following six categories:
• Modules. Windows PowerShell modules imported into an Automation account. Modules determine
the sets of cmdlets and activities that are available when you create Windows PowerShell scripts and
workflows. By default, any newly created account contains a number of Windows PowerShell
modules, including Azure, Azure.Storage, AzureRM.Automation, AzureRM.Compute, AzureRM.Profile,
AzureRM.Resources, AzureRM.Sql, AzureRM.Storage, Microsoft.PowerShell.Core,
Microsoft.PowerShell.Diagnostics, Microsoft.PowerShell.Management, Microsoft.PowerShell.Security,
Microsoft.PowerShell.Utility, Microsoft.WSMan.Management, and
Orchestrator.AssetManagement.Cmdlets.
Note: Both Service Management and Azure Resource Management modules are available,
which means that Automation supports both deployment models.
In the context of Azure Automation, Windows PowerShell modules are referred to as integration
modules, which indicate one important distinction. While both types of modules must contain at least
one .psd1, .psm1, or .dll file (which implements the actual cmdlets), an integration module might also
contain a metadata .json file. This JavaScript Object Notation (JSON) file defines the Azure connection
type that Automation should use when accessing resources that the cmdlets included in the module
target.
• Schedules. By using schedules, you can execute runbooks automatically (rather than on demand),
either once at a designated date and time, or in a recurring manner.
• Certificates. This category consists of certificates uploaded to an Azure Automation account. One
common reason for using them is to facilitate certificate-based authentication. To retrieve the value
of a certificate asset, use the Get-AutomationCertificate activity.
• Connections. Connections contain the information required for a runbook to authenticate to an Azure
subscription or an external service or application. The type of information depends on the
authentication mechanism. You can access connection properties in the runbook with the Get-
AutomationConnection activity. Connection type definitions are included in the integration
modules that deliver related Windows PowerShell functionality. To make a specific connection type
available, you need to import the module that contains the connection type definition.
• Variables. This category contains values that you need to reference in your scripts. By using variables,
you avoid the need to modify your runbooks directly (potentially multiple times) if the referenced
value changes. Variables are also useful for sharing values between runbooks or sharing values
between multiple jobs executing the same runbook. To retrieve variables, use the Get-
AutomationVariable activity.
• Credentials. Credentials consist of a user name and password combination. To retrieve a credential
within a runbook, you can use the Get-AutomationPSCredential activity. The credential must
represent a Microsoft Azure Active Directory (Azure AD) account, because Azure Automation does
not support Microsoft accounts.
It is possible to encrypt content related to some of the Automation assets, including credentials,
connections, and variables. Once the encryption takes place, to retrieve the protected content, you must
use runbook activities rather than the corresponding Windows PowerShell cmdlets.
Using Automation runbooks on-premises

Azure Automation has direct access to
Azure-hosted services. For Azure Automation to
manage on-premises resources in the same way,
you would have to open internal networks to
inbound traffic originating from Azure. Because
almost no customer would consider this approach,
Azure Automation offers an alternative solution
that does not jeopardize security. To implement it,
you must deploy on-premises agents referred to
as Hybrid Runbook Workers. These establish
outbound, persistent connections to Azure.
Hybrid Runbook Workers require servers running

Windows Server 2012 or newer and use Microsoft Management Agent to communicate with both Azure
Automation and Microsoft OMS. The former delivers core automation components, which include
runbooks and the execution parameters and instructions associated with them. The latter handles
monitoring and agent maintenance.
To ensure resiliency and scalability, you typically deploy Hybrid Runbook Workers in groups, though it is
possible to have a single worker in a group. You reference the group name when you start a runbook.
Azure Automation automatically designates one of the group members to execute the corresponding job.
The process of deploying a Hybrid Runbook Worker consists of the following tasks:
1. Create an OMS workspace, assuming that one does not already exist.
2. Add the Automation solution to the OMS workspace.
3. Install the Microsoft Management Agent on the on-premises computer running Windows Server 2012
or newer, which will be serving the Hybrid Runbook Worker role.
Note: Refer to the first lesson of this module for more information regarding the above
steps.
4. Run the Add-HybridRunbookWorker PowerShell cmdlet on the Hybrid Runbook Worker computer
to establish its communication with the Azure Automation workspace. The cmdlet is part of the
HybridRegistration PowerShell module, which Hybrid Runbook Worker downloads automatically
once you add the Automation solution to the OMS workspace. The cmdlet includes, as one of its
parameters, the name of the group of which the Hybrid Runbook Worker will become a member. If
the group does not exist, it is created at this point. The remaining parameters are the Automation
account URL and its access key, which you can retrieve from the Automation account blade in the
Azure portal.
To run an Azure Automation runbook on-premises, you must specify the Run on option (either
via the Azure portal interface or by including the –RunOn parameter when invoking the Start-
AzureAutomationRunbook cmdlet) and specify the name of the target Hybrid Runbook Worker Group
as its value. In addition, you will likely need to install Windows PowerShell modules that the runbook relies
on during its execution, because these are not automatically deployed to the worker computer.
Additional Reading: To manage Hybrid Runbook Worker Group systems by using Azure
Automation DSC, you need to configure them as DSC nodes. For details regarding this
configuration, refer to: “Onboarding machines for management by Azure Automation DSC” at:
https://aka.ms/qtdos6
Demonstration: Creating an Azure Automation account and assets

• Create an Azure Automation account.
• Create an Azure Automation Variable asset.
• Create an Azure Automation Schedule asset.


Question
You need to be able to execute Azure Automation runbooks on your on-premises

computers. What additional Azure service do you need to configure?
ExpressRoute
OMS
Service Bus
Cloud service
App Service
Lesson 3
Implementing Automation runbooks
In this lesson, you will learn about implementing Azure Automation runbooks. In particular, you will learn
about three types of Automation runbooks, and the process of authoring each of them. In addition, you
will become familiar with the implementation of DSC, which relies on Azure Automation.
Lesson Objectives
After completing this lesson, you should be able to:
• Describe the different types of runbooks that Azure Automation supports.
• Explain how to create Automation runbooks by using the graphical authoring functionality in the
Azure portal.
• Explain how to create basic PowerShell workflows by using sequences, checkpoints, and parallel
processing.
• Explain how to author PowerShell workflow runbooks textually.
• Explain how to author PowerShell runbooks textually.
• Explain how to implement DSC that leverages Azure Automation.
• Author Azure Automation runbooks by using the graphical interface.
Introduction to Azure Automation runbooks

Runbooks deliver the core functionality of Azure
Automation by serving as containers for your
custom scripts and workflows. In addition,
runbooks typically reference Automation assets,
such as credentials, variables, connections, and
certificates. They also can contain other runbooks,
thereby allowing you to build more complex
workflows in a modular manner. You can invoke
and run runbooks either on demand or according
to your chosen schedule by leveraging
Automation Schedule assets.
In general, there are two types of Azure

Automation runbooks, based on how you create and edit their content:
• Graphical. You can create and edit graphical runbooks only by using the graphical editor interface
available in the Azure portal.
• Textual. You can create and edit textual runbooks either by using the textual editor available in the
Azure portal, or by using any Windows PowerShell or text editor and importing the runbooks into
Azure.
You can also categorize Automation runbooks by whether they contain Windows PowerShell scripts or
workflows. You can implement both by using either textual or graphical runbooks.
Your choice of a runbook type is important, because it is not possible to perform conversion between the
graphical and textual types. You can, however, convert between graphical PowerShell runbooks and
graphical PowerShell workflows when importing them into an Automation account. Other considerations
include:
• Graphical runbooks simplify implementing PowerShell runbooks and workflows. For workflows, they
offer built-in visual elements representing checkpoints and parallel processing.
• PowerShell workflow–based runbooks take longer to start because they must be compiled first.
In addition to authoring, you also have the option to export and import runbooks, which provides a
relatively convenient method of copying them across Automation accounts. This approach is available for
both graphical and textual runbooks.
Graphical authoring of Automation runbooks

Graphical authoring of Azure Automation
runbooks simplifies the creation of Windows
PowerShell–based code. In fact, it can sometimes
eliminate the need for scripting entirely.
Authoring relies on the graphical editor available
in the Azure portal. It involves selecting visual
elements representing different graphical library
items and arranging them on the canvas within
the editor window.
The Library control displays all available library

items, which are grouped into four sections:
• Cmdlets. Lists all the available PowerShell
cmdlets organized according to the PowerShell module to which they belong. In this section, you will
find all PowerShell modules that will be available to you during runbook creation, including custom
ones that you imported into the Automation account.
• Runbooks. Includes all runbooks within the current Automation account. You have the option of
adding these runbooks to the canvas as child runbooks.
• Assets. Provides easy access to all automation assets in the current Automation account.
• Runbook Control. Allows you to incorporate custom code within the current runbook and add
junctions that dictate the flow of execution, combining multiple, parallel execution paths into one.
Custom code gives you the ability to implement functionality that built-in library items do not offer.
Once you drop a library item onto the canvas, you can use the Configuration pane to configure its
individual settings, such as its label, retry behavior, or, in case of custom code, the actual Windows
PowerShell script or workflow. The editor interface also includes the Test control, which gives you the
ability to test the execution of the runbook that you are currently editing.
Overview of PowerShell workflows

A workflow is a sequence of steps optimized for
long-running tasks, or multiple steps across
multiple managed nodes, such as Azure VMs. In
the context of PowerShell, you implement
workflows by using Windows Workflow
Foundation.
PowerShell workflows largely resemble traditional

Windows PowerShell scripts, because they use the
same verb-noun syntax for their activities. There is
an identically named Windows PowerShell cmdlet
for most activities. However, there are also
significant differences between PowerShell
workflows and scripts.
One of the unique characteristics of workflows is the ability to recover automatically from failures that
could be the result of, for example, reboots of managed nodes. Checkpoints make this automatic recovery
possible. Checkpoints designate points in the workflow where the workflow engine should save the
current status of the execution. In addition, workflows can perform groups of commands in parallel,
instead of sequentially, as in typical PowerShell scripts. This is useful for runbooks that perform multiple
actions that take a significant time to complete, such as provisioning a collection of virtual machines.
Checkpoints also address the side effects of the Azure Automation throttling mechanism known as Fair
Share. This mechanism temporarily unloads any executing runbook, interrupting its execution after it has
been running for three hours. When Fair Share restarts the runbook afterwards, it resumes its execution
from its most recent checkpoint or, if one does not exist, from the beginning. The latter would likely result
in the runbook execution being interrupted again after three hours. If a runbook restarts from the same
checkpoint or from the beginning three consecutive times, Fair Share terminates it permanently with the
failed status. You should consider this behavior when authoring your automation runbooks.
Additional Reading: For more information, refer to: “PowerShell Workflows: The Basics” at:
http://aka.ms/Wlt7zp
Textual authoring of PowerShell workflow runbooks

PowerShell workflows start with the keyword
Workflow, followed by the script body enclosed
in braces, as follows:
Workflow Test-Workflow1
{
<Activities>
}
The keyword Parallel creates a script block

containing multiple activities that run concurrently
(enclosed in braces). The keyword ForEach –
Parallel implements concurrent processing of
items in a collection. This allows you to ensure
that a sequence of activities in a script block that follows ForEach –Parallel runs in parallel for each item
in the collection. The keyword Sequence enforces sequential processing of arbitrarily chosen activities
(enclosed in braces) if they reside within a parallel script block.
In the following example, activities A and B (and the sequence C-D) will execute in parallel, and there is no
way to know in advance which of these activities will complete first. Activities C and D will always execute
in order (first C, then D), but might execute before activity A or activity B:
Workflow Test-Workflow2 {
Parallel {
Activity A
Activity B
Sequence {
Activity C
Activity D
}
}
In general, it is likely that you will not be able to copy an existing Windows PowerShell script and
implement it directly as a PowerShell workflow without making any modifications. It might be necessary
to perform some level of conversion, by translating PowerShell cmdlets into their corresponding Windows
PowerShell workflow activities and accounting for differences between the two technologies. For
Windows PowerShell cmdlets that you cannot easily map to workflow activities, you can use the
InlineScript construct, which is effectively a Windows PowerShell script block inside your workflow. The
keyword InlineScript designates a block of PowerShell cmdlets that run in a separate, non-workflow
session, returning the final result to the workflow. Windows PowerShell, not Windows Workflow
Foundation, processes the content of an InlineScript block:
InlineScript {
Non-mapped cmdlets
}
Checkpoints are snapshots of the current state of the workflow, including the current values for runbook
variable assets. Checkpoints are saved to the Automation database, so that workflows can resume after an
interruption or outage. You set checkpoints with the Checkpoint-Workflow activity. You can use the
Suspend-Workflow activity to force a runbook to suspend, and set a checkpoint. This is useful for
runbooks that need some intermediate manual steps.
To create a new PowerShell workflow–based runbook from the Azure portal, navigate to the Add
Runbook blade within your Automation account, click the Create a new runbook option, and then
specify the runbook name (which must start with a letter, but might include numbers, underscores, and
dashes). Depending on whether you want to create a textual or graphical runbook, select PowerShell
Workflow or Graphical PowerShell Workflow as the runbook type.
When authoring PowerShell workflow–based textual runbooks, you have several options:
• Write code directly in the textual editor window within the Azure portal.
• Add Windows PowerShell cmdlets contained in the PowerShell modules imported into your
Automation account.
• Reference Automation assets (including variables, connections, credentials, or certificates) by using

either Get or Set activities. For example, to reference a value of an Automation variable asset, you
would right-click it, and then click either Add “Get Variable” to canvas or Add “Set Variable” to
canvas. This would automatically add the Get-AutomationVariable activity to the canvas, with the
–Name parameter set to the value of this variable.
• Add runbooks of the same type (meaning either graphical or PowerShell workflow textual) to the
canvas. This adds the reference to this runbook within the editor window, which results in invoking
the imported runbook during execution of the currently edited one. For example, if you add a
PowerShell workflow runbook named Runbook1 to the canvas, it would appear in the editor window
as a separate line in the format Runbook1.ps1.
Textual authoring of PowerShell runbooks

When authoring PowerShell runbooks, you have
several options:
• Write code directly in the textual editor

window within the Azure portal.
• Add PowerShell cmdlets contained in the

integration modules imported into your
Automation account.
• Reference Automation assets, including
variables, connections, credentials, or
certificates, by using either Get or Set
activities. For example, to reference a value of
an Automation variable asset, you would right-click it, and then click either Add “Get Variable”
to canvas or Add “Set Variable” to canvas. This would automatically add the Get-
AutomationVariable activity to the canvas, with the –Name parameter set to the value of
this variable.
• Add runbooks of the same type to the canvas. This adds the reference to the runbook within the
editor window, which results in invoking the imported runbook during execution of the currently
edited one. For example, if you add a PowerShell runbook named Runbook1 to the canvas, it would
appear in the editor window as a separate line in the format .\Runbook1.ps1.
To create a new textual PowerShell runbook from the Azure portal, navigate to the Add Runbook blade
within your Automation account. Click the Create a new runbook option, specify the runbook name
(which must start with a letter, but might include numbers, underscores, and dashes), and ensure that you
select PowerShell as the runbook type.
Implementing Automation DSC

DSC allows you to define an operating system or
application state in a declarative manner. It then
allows you to enforce this state by applying this
definition to one or more managed computers via
the push or the pull method. The push method is
initiated from a central management point,
whereas the pull method is initiated from
managed computers. With the pull method, the
definition is first copied to a pull server that
managed systems point to as their configuration
source.
Azure Automation leverages the Windows PowerShell DSC in the pull mode, implementing all of its
components in the cloud. It is capable of managing both Windows and Linux systems running on Azure
VMs, on-premises computers, or virtual machines hosted by other cloud providers.
The Azure DSC implementation process starts with creating a configuration script (a .ps1 file) that
represents the desired state of managed computers. Configuration contains one or more nodes, which
represent individual roles that you want to manage. You must add the configuration to the Automation
account, by using either the Azure portal or Windows PowerShell. Just like PowerShell scripts and
workflows, the configuration script can reference Automation assets.
The scope of functionality that you are able to manage with Azure Automation DSC depends on the DSC
resources that the Automation account includes. While there is a set of built-in resources that match those
in the standard PowerShell DSC, it is possible to import additional resources if needed, by uploading
PowerShell integration modules containing their definitions. The upload functionality is available from the
Azure portal and by using Azure PowerShell.
Next, you need to compile DSC configuration by clicking the Compile link in the configuration blade in
the Azure portal, or by invoking the Start-AzureRmAutomationDscCompliationJob cmdlet. When
using PowerShell, you have the option to specify configuration data during compilation. This allows you
to assign different configurations, depending on the targeted computers. For example, you can enforce
one set of settings on the production system and another in a test environment.
Compilation generates one or more Managed Object Format (MOF) files containing node configurations,
which are uploaded to a DSC pull server residing in Azure (along with non-default DSC resources). For
these configurations to take effect, you need to add (or onboard, in the DSC nomenclature) target
computers as DSC-managed nodes into your Automation account. You can perform the onboarding
process from the Azure portal or by using Azure PowerShell. Azure PowerShell is your only option for
onboarding Azure VMs that are running Linux.
As part of onboarding, you will need to specify registration settings, including:

• Registration URL. This setting is available from the Manage Keys blade in the Automation account in
the Azure portal.
• Automation account registration primary or secondary key. This setting is available from the Manage
Keys blade in the Automation account in the Azure portal.
• Node configuration name. This setting specifies the name of the configuration node.
• Refresh frequency. Its value determines how often the nodes communicate with their DSC pull server.
• Configuration mode frequency. Its value determines how often nodes apply configuration mode to
their local resources.
• Configuration mode. It can take one of the following values:

o ApplyAndMonitor. Applies the configuration and monitors any subsequent inconsistencies,
recording them in logs.
o ApplyOnly. Applies the configuration once.
o ApplyAndAutoCorrect. Applies the configuration and fixes any subsequent inconsistencies.
Additional Reading: For more information, refer to: “DSC Configurations” at:
http://aka.ms/Vy5n2q
Additional Reading: For more information, refer to: “Onboarding machines for
management by Azure Automation DSC: The Basics” at: http://aka.ms/Lmsccl
Demonstration: Graphical authoring of Automation runbooks

• Create a graphical Automation runbook.
• Configure authentication in a graphical Automation runbook.

• Add an activity to start an Azure VM.

Question
You plan to author an Automation runbook that, according to your estimates, will
take seven hours to complete. What should you do to ensure that the runbook
successfully executes?
Create a PowerShell script–based runbook
Create a PowerShell workflow–based runbook with a single checkpoint
Create a PowerShell workflow–based runbook with two checkpoints
Create a PowerShell workflow–based runbook with a single InlineScript element
Create a PowerShell workflow–based runbook with two InlineScript elements

Lesson 4
Implementing Azure Automation–based management
In this lesson, you will learn about the most common Azure Automation management tasks, focusing on
runbook lifecycle management. This lesson will cover testing, publishing, and scheduling automation
runbooks, in addition to monitoring and troubleshooting Automation jobs. The lesson concludes with an
overview of the most common troubleshooting techniques and different methods to ensure resiliency of
your Azure Automation environment.
Lesson Objectives
• Describe the lifecycle of Azure Automation runbooks.
• Describe the process of testing, publishing, and executing Automation runbooks.
• Explain how to monitor and troubleshoot runbook execution.

• Explain how to protect the Azure Automation environment.
• Test, publish, execute, and monitor an Automation runbook.
Automation runbook lifecycle

Any runbook residing in an Automation account
has a specific authoring status, depending on its
stage of development:
• A newly created runbook that you have not

yet published is assigned the New authoring
status automatically. In this stage, you can
modify and test it, but you cannot schedule
its execution. You also do not have the option
to revert any changes that you save.
• Once you successfully complete testing on a

runbook, you can publish it, which
automatically assigns the Published
authoring status. This is a typical, production-ready runbook status. At this point, you can schedule its
execution. In addition, it is possible to start a published runbook by submitting an HTTP POST request
to a URL referred to as webhook. You can create a webhook via the Azure portal or Azure PowerShell.
• If you decide to make changes to an existing, published runbook and open it in the textual or
graphical editor, it will be assigned the In edit status. This allows you to modify and test it. Any
changes that you save do not affect the published version. In addition, you have the option to revert
the edited version back to the published one.
You can easily identify the current status of any runbook from the Runbooks blade in the Azure portal, by
reviewing the AUTHORING STATUS column.
Testing, publishing, and executing Automation runbooks

To test a runbook, in the Azure portal, click Test
pane in the toolbar of the graphical or textual
editor blade. Testing allows you to validate
runbook operation before making the runbook
available for production use. This is possible
without overwriting an existing, published version.
Depending on the runbook type, you can initiate
testing from the graphical or textual editor, and
monitor results of its execution in the Output
blade. It is important to note that, during a test,
the edited runbook runs against the target
environment that you specify, so you should
evaluate the risk of such an action. In other words, testing is not functionally equivalent to the –WhatIf
Windows PowerShell switch.
Note: Because, by default, runbook tests run against a live environment, you might want to
consider creating a dedicated test subscription or an on-premises Hybrid Runbook Workers
group. When you have the final version of a runbook, you can then export it, and import it into
your production subscription.
To publish a runbook that you validated through testing, in the Azure portal, click Publish in the toolbar
of the graphical or textual editor blade. Once you publish a runbook, you can link it to one or more
schedules, with different recurrence settings (one time, hourly, and daily) and an expiration date. You have
the option of enabling or disabling individual schedules without affecting others linked to the same
runbook. You can also modify input parameters if the runbook accepts them, and run settings. By default,
runbooks run in Azure, but if you deploy a Hybrid Runbook Worker group, you can also run them on-
premises. You also have the option to execute a published runbook on demand. You can do this by
clicking Start in the toolbar of the runbook blade in the Azure portal.
Regardless of the method, invoking execution of a runbook creates an automation job. A runbook job
represents a single execution of a runbook. You can run multiple instances of the same runbook
simultaneously or according to overlapping schedules.
Monitoring and troubleshooting Automation jobs

You can control and monitor each automation job
by using its blade in the Azure portal. The
interface provides you with the ability to stop,
resume, and suspend the job’s execution,
depending on its current status. From here, you
also have access to job summary information, the
job’s output, and errors, warnings, exceptions, and
logs that it generates. Alternatively, you can
retrieve job status information by using the Get-
AzureAutomationJob PowerShell cmdlet.
When monitoring and troubleshooting jobs, you should be familiar with their possible states, which
include:
• Completed. Designates successful completion of the job.
• Failed. For PowerShell workflow–based runbooks, which includes all graphical runbooks, this indicates
a compilation failure. For PowerShell script–based runbooks, this typically is a result of an exception in
the script execution.
• Failed, waiting for resources. Implies that the job has failed because it has reached the limit of three
consecutive restarts following the Fair Share–based unload.
Note: The previous lesson in this module described the Fair Share mechanism.
• Queued. Designates the state of waiting for resources necessary to initiate job execution.
• Starting. Follows the Queued state, once the platform has assigned necessary resources to the job.
• Running. Designates the job actively performing activities included in the runbook.
• Running, waiting for resources. Indicates that the job has been unloaded because it reached the Fair
Share limit by running for three hours. The job will resume from the most recent checkpoint.
• Stopped. Indicates that a stop request by the owner of the Automation account has stopped the job
prior to its completion.
• Stopping. Describes a job in the process of stopping prior to its completion, following the stop
request by an administrative user with sufficient permissions to the Automation account.
• Suspended. Results from the request to suspend the job. Such request can be initiated by an
administrative user with sufficient permissions to the Automation account, by the Azure platform (in
case of an exception), or by a command in the runbook.
• Suspending. Indicates that the platform is attempting to suspend the job following a request from an
administrative user with sufficient permissions to the Automation account. Note that the job will have
to reach its next checkpoint, or complete if a checkpoint does not exist, before it changes its status to
Suspended.
• Resuming. Follows the Suspended state and is typically a result of an administrative action.
Protecting the Azure Automation environment

It is important to consider protecting your Azure
Automation configuration beyond the built-in
resiliency mechanisms that the cloud platform
provides. By default, Azure geo-replicates the
content of each Automation account to a
secondary region, automatically paired up with
the primary region of your choice. Both regions
reside in the same geopolitical area. The
secondary replica becomes available in case of a
disaster affecting the region that hosts the
primary.
Azure also offers a 90-day default data retention period, which designates the length of time during
which you can view and audit past jobs. This period also determines the time after which the platform
permanently removes administratively deleted automation objects, such as accounts, assets, modules,
runbooks, or DSC components.
If these built-in provisions do not satisfy your requirements, you have the option of backing up your
Automation environment by using the following methods:
• Export runbooks from the Azure portal or by running the

Get-AzureAutomationRunbookDefinition PowerShell cmdlet.
• Maintain integration modules outside of an Automation account, because it is not possible to export
them.
• Extract and store definitions of unencrypted assets by running Azure PowerShell cmdlets,
because assets also are not exportable. To retrieve encrypted values of Automation variable
and credential assets, use the equivalent Automation activities (Get-AutomationVariable and
Get-AutomationPSCredential).
• Export DSC configurations by using the Azure portal and

Export-AzureRmAutomationDscConfiguration.
Demonstration: Testing, publishing, executing, and monitoring execution

of an Automation runbook
• Test a runbook.
• Publish a runbook.
• Execute a runbook and monitor the corresponding job.
Demonstration Steps
Question
What actions are available for a runbook in the New authoring status?
Testing
Scheduling
Creating a webhook
Reverting to the published version
Editing
Lab: Implementing Automation

Scenario
A. Datum Corporation wishes to minimize administrative overhead as much as possible, especially for
tasks such as deploying and deprovisioning VMs. For this reason, as part of A. Datum’s evaluation of
Microsoft Azure, you have been asked to test the new Azure Automation features and, as part of your
tests, to deploy Azure VMs by using runbook automation.
Objectives
• Configure Automation accounts.
• Create runbooks.
Lab Setup

User name: Student
Password: Pa55w.rd
Before starting this lab, ensure that you have performed the “Preparing the lab environment”
demonstration tasks at the beginning of the first lesson in this module, and that the setup script has
completed.
Question: What should you consider when testing the execution of an Automation
runbook?
Question: Why did you have to create an Azure Automation Run As account in the lab?

Review Question
Question: What are the potential benefits and challenges of running PowerShell workflows
from an on-premises computer as compared to running them as Azure Automation
runbooks?
Course Evaluation
Your evaluation of this course will help Microsoft understand the quality of your learning experience.
Please work with your training provider to access the course evaluation form.
Microsoft will keep your answers to this survey private and confidential and will use your responses to
improve your future learning experience. Your open and honest feedback is valuable and appreciated.

20533D ENU TrainerHandbook PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

20533D ENU TrainerHandbook PDF

Uploaded by

Copyright:

Available Formats

MCT USE ONLY.

STUDENT USE PROHIBITED

Microsoft and the trademarks listed at https://www.microsoft.com/en-us/legal/intellectualproperty

Product Number: 20533D

Part Number: X21-56544

a. If you are a Microsoft IT Academy Program Member:

b. If you are a Microsoft Learning Competency Member:

d. If you are an End User:

e. If you are a Trainer.

3. LICENSED CONTENT BASED ON PRE-RELEASE TECHNOLOGY. If the Licensed Content’s subject

11. APPLICABLE LAW.

This limitation applies to

LIMITATION DES DOMMAGES-INTÉRÊTS ET EXCLUSION DE RESPONSABILITÉ POUR LES

Revised July 2013

Marcin Policht: Content Developer

Telmo Sampaio: Technical Reviewer

Lesson 2: Overview of Azure 1-6

Lesson 3: Managing Azure with the Azure portal 1-22

Lesson 5: Managing Azure with Azure CLI 1-33

Lesson 6: Overview of Azure deployment models 1-37

Lab: Managing Microsoft Azure 1-55

Module Review and Takeaways 1-56

Module 2: Implementing and managing Azure networking

Lesson 1: Overview of Azure networking 2-2

Lesson 2: Implementing and managing virtual networks 2-21

Lab A: Using a deployment template and Azure PowerShell to implement

Lesson 3: Configuring an Azure virtual network 2-29

Lesson 4: Configuring virtual network connectivity 2-39

Lesson 5: Overview of Azure classic networking 2-58

Lab B: Configuring VNet peering 2-66

Module Review and Takeaways 2-67

Module 3: Implementing virtual machines

Lesson 1: Overview of Azure VMs 3-2

Lesson 2: Planning deployment of Azure VMs 3-7

Lesson 3: Deploying Azure VMs 3-18

Lab A: Deploying Azure VMs 3-30

Lesson 4: Overview of classic VMs 3-31

Module Review and Takeaways 3-35

Module 4: Managing Azure VMs

Lesson 1: Configuring Azure VMs 4-2

Lesson 3: Managing and monitoring Azure VMs 4-17

Lesson 4: Managing classic Azure VMs 4-28

Module Review and Takeaways 4-33

Module 5: Implementing Azure App Service

Lesson 2: Planning app deployment in App Service 5-12

Lesson 3: Implementing and maintaining web apps 5-16

Lesson 4: Configuring web apps 5-24

Lesson 5: Monitoring web apps and WebJobs 5-32

Lesson 6: Implementing mobile apps 5-37

Lesson 7: Implementing Traffic Manager 5-42

Lab: Implementing web apps 5-47

Module Review and Takeaways 5-48

Module 6: Planning and implementing storage, backup, and recovery services

Lesson 1: Planning storage 6-2

Lesson 2: Implementing and managing Azure Storage 6-12

Lesson 3: Implementing Azure CDNs 6-25

Lesson 4: Implementing Azure Backup 6-31

Lesson 5: Planning and implementing Azure Site Recovery 6-38

Lab: Planning and implementing Azure Storage 6-46

Module Review and Takeaways 6-47

Module 7: Implementing containers in Azure

Lesson 1: Implementing Windows and Linux containers in Azure 7-2

Lab A: Implementing containers on Azure VMs 7-14